1. Only run the services that you need to run for the services provided by the machine. For instance if the server is a database server you most likely don't need the same box to run apache, ftp and sendmail. every extra service running on a box steals performance from the systems primary function and possibly opens up new security vulnerabilities.
2. you can use lsof or a similar tool to determine what ports are listening on the computer.
ns003:~# lsof -i
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
named 17829 root 4u IPv6 12689530 UDP *:34327
named 17829 root 6u IPv4 12689531 UDP *:34329
named 17829 root 20u IPv4 12689526 UDP ns003.psi.net:domain
named 17829 root 21u IPv4 12689527 TCP ns003.psi.net:domain (LISTEN)
named 17829 root 22u IPv4 12689528 UDP 10.4.20.46:domain
named 17829 root 23u IPv4 12689529 TCP 10.4.20.46:domain (LISTEN)
lighttpd 17841 www-data 4u IPv4 12689564 TCP *:www (LISTEN)
sshd 17860 root 3u IPv6 12689580 TCP *:ssh (LISTEN)
sshd 17880 root 3u IPv6 12689629 TCP *:8899 (LISTEN)
sshd 30435 root 4u IPv6 74368139 TCP 10.4.20.46:8872 10.4.20.1:3262 (ESTABLISHED)
3. Shut down any unknown or unneeded services, using the appropriate tools for your Linux distribution, such as update-rc.d on Debian systems, or in some cases editing the /etc/inetd.conf or /etc/xinetd.d/* files.
4. Don't allow root logins on your primary sshd port 22 (set PermitRootLogin to "no"); many automated tools run brute-force attacks on that. Set up a secondary port for root access that only works by shared keys, disallowing passwords:
* Copy the sshd_config file to root_sshd_config, and change the following items in the new file:
o Port from 22 to some other number, say 8899 (don't use this! make up your own!)
o PermitRootLogin from "no" (you were supposed to set it to "no" for port 22, remember?) to "yes"
o AllowUsers root add this line, or if it exists, change it to allow only root logins on this port
o ChallengeResponseAuthentication no uncomment this line if it's commented out, and make sure it says "no" instead of "yes"
* Test this command:
sshd -D -f /etc/ssh/root_sshd_config
and see if it works correctly -- try logging in from another computer (you must have already set up shared-key authentication between the two computers) using:
ssh -p8899 root@my.remote.server
and if so, control-C at the above (sshd) command to stop the sshd daemon, then add this to the end of /etc/inittab:
rssh:2345:respawn:sshd -D -f /etc/ssh/root_sshd_config
* Restart the init task: # init q This will run your "root ssh daemon" as a background task, automatically restarting it in case of failure.
Thursday, December 3, 2009
Wednesday, November 18, 2009
Monitoring Processes
top - Process Activity Command
The top program provides a real-time view of the processes running on a system. it displays the most CPU-intensive tasks running on the server and updates the list every five seconds.
The top command has several useful hot keys:
-t Displays summary information.
-m Displays memory information.
-A Sorts the display by top consumers of various system resources.
- f interactive configuration screen.
- o select the ordering within top.
- r Issues renice command.
- k Issues kill command.
- z color/mono
vmstat -
vmstat reports information about processes, memory, paging, block IO, traps, and cpu activity.
Sample Outputs:
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 2540988 522188 5130400 0 0 2 32 4 2 4 1 96 0 0
1 0 0 2540988 522188 5130400 0 0 0 720 1199 665 1 0 99 0 0
0 0 0 2540956 522188 5130400 0 0 0 0 1151 1569 4 1 95 0 0
0 0 0 2540956 522188 5130500 0 0 0 6 1117 439 1 0 99 0 0
0 0 0 2540940 522188 5130512 0 0 0 536 1189 932 1 0 98 0 0
0 0 0 2538444 522188 5130588 0 0 0 0 1187 1417 4 1 96 0 0
0 0 0 2490060 522188 5130640 0 0 0 18 1253 1123 5 1 94 0 0
Display Memory Utilization Slabinfo
# vmstat -m
Get Information About Active / Inactive Memory Pages
# vmstat -a
ps
ps command will display a listing of running processes. with no switches it will display the listing of processes owned by the current user using the short display.
to display processes for all users you can use the -a or -e switch.
# ps -A
PID TTY TIME CMD
1 ? 00:00:02 init
2 ? 00:00:02 migration/0
3 ? 00:00:01 ksoftirqd/0
4 ? 00:00:00 watchdog/0
5 ? 00:00:00 migration/1
6 ? 00:00:15 ksoftirqd/1
....
.....
4881 ? 00:53:28 java
4885 tty1 00:00:00 mingetty
4886 tty2 00:00:00 mingetty
4887 tty3 00:00:00 mingetty
4888 tty4 00:00:00 mingetty
4891 tty5 00:00:00 mingetty
4892 tty6 00:00:00 mingetty
4893 ttyS1 00:00:00 agetty
12853 ? 00:00:00 cifsoplockd
12854 ? 00:00:00 cifsdnotifyd
14231 ? 00:10:34 lighttpd
14232 ? 00:00:00 php-cgi
54981 pts/0 00:00:00 vim
55465 ? 00:00:00 php-cgi
55546 ? 00:00:00 bind9-snmp-stat
55704 pts/1 00:00:00 ps
ps is just like top but provides more information.
The long format displays more detailed information about the processes. You get the long format by adding the -l switch. The command below will list processes for all users using the long format.
# ps -Al
To turn on extra full mode (it will show command line arguments passed to process):
# ps -AlF
To See Threads ( LWP and NLWP)
# ps -AlFH
To See Threads After Processes
# ps -AlLm
Print All Process On The Server
# ps ax
# ps axu
Print A Process Tree
# ps -ejH
# ps axjf
# pstree
Print Security Information
# ps -eo euser,ruser,suser,fuser,f,comm,label
# ps axZ
# ps -eM
See Every Process Running As User smith
# ps -U smith -u smith u
Set Output In a User-Defined Format
# ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm
# ps axo stat,euid,ruid,tty,tpgid,sess,pgrp,ppid,pid,pcpu,comm
# ps -eopid,tt,user,fname,tmout,f,wchan
Display Only The Process IDs of Lighttpd
# ps -C lighttpd -o pid=
OR
# pgrep lighttpd
OR
# pgrep -u vivek php-cgi
Display The Name of PID 55977
# ps -p 55977 -o comm=
Find Out The Top 10 Memory Consuming Process
# ps -auxf | sort -nr -k 4 | head -10
Find Out top 10 CPU Consuming Process
# ps -auxf | sort -nr -k 3 | head -10
free - Memory Usage
the command 'free' displays the total amount of free and used physical and swap memory in the system, as well as the buffers used by the kernel.
# free
Sample Output:
total used free shared buffers cached
Mem: 12302896 9739664 2563232 0 523124 5154740
-/+ buffers/cache: 4061800 8241096
Swap: 1052248 0 1052248
iostat - Average CPU Load, Disk Activity
The command iostat report Central Processing Unit (CPU) statistics and input/output statistics for devices, partitions and network filesystems (NFS).
# iostat
Sample Outputs:
avg-cpu: %user %nice %system %iowait %steal %idle
3.50 0.09 0.51 0.03 0.00 95.86
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 22.04 31.88 512.03 16193351 260102868
sda1 0.00 0.00 0.00 2166 180
sda2 22.04 31.87 512.03 16189010 260102688
sda3 0.00 0.00 0.00 1615 0
sar - Collect and Report System Activity
The sar command is used to collect, report, and save system activity information.
To see network counter, enter:
# sar -n DEV | more
To display the network counters from the 24th:
# sar -n DEV -f /var/log/sa/sa24 | more
You can also display real time usage using sar:
# sar 4 5
Sample Outputs:
06:45:12 PM CPU %user %nice %system %iowait %steal %idle
06:45:16 PM all 2.00 0.00 0.22 0.00 0.00 97.78
06:45:20 PM all 2.07 0.00 0.38 0.03 0.00 97.52
06:45:24 PM all 0.94 0.00 0.28 0.00 0.00 98.78
06:45:28 PM all 1.56 0.00 0.22 0.00 0.00 98.22
06:45:32 PM all 3.53 0.00 0.25 0.03 0.00 96.19
Average: all 2.02 0.00 0.27 0.01 0.00 97.70
mpstat - Multiprocessor Usage
Multi Processor Statistics - The mpstat command displays processor statistics for each available processor, processor 0 being the first. It also reports statistics about the overall activity of all processors combined. The mpstat command can be used both on SMP and UP machines.
# mpstat -P ALL.
Where, -P cpu | ALL option indicate the processor number for which statistics are to be reported. cpu is the processor number. Note that processor 0 is the first processor. The ALL keyword indicates that statistics are to be reported for all processors.
Output:
04:13:29 PM CPU %user %nice %system %iowait %irq %soft %idle intr/s
04:13:29 PM all 5.63 0.01 2.33 0.85 0.01 0.10 91.06 2255.03
04:13:29 PM 0 5.74 0.00 2.17 0.88 0.01 0.15 91.05 1170.16
04:13:29 PM 1 5.53 0.01 2.49 0.83 0.01 0.06 91.07 1084.87
Understanding mpstat output
* CPU: Processor number. This is the logical cpu number (0 being the first) and "all" is a global average for all processors.
* %user: Shows the percentage of CPU utilization used for executing user level applications.
* %nice: Shows the percentage of CPU utilization used for executing at the user level with nice priority.
* %system: Shows the percentage of CPU utilization used for system level (kernel) processes. Note this does not include time spent servicing
interrupts or softirqs.
* %iowait: Shows the percentage of time that the CPU was idle while waiting on an outstanding I/O request.
* %irq: Shows the percentage of time spent servicing hardware interrupts.
* %soft: Shows the percentage of time spent servicing softirqs. A softirq (software interrupt) is one of up to 32 enumerated software interrupts
which can run on multiple CPUs at once.
* %idle: Show the percentage of time the processor was idle and the system did not have an outstanding disk I/O request.
* intr/s: Show the total number of interrupts received per second by the CPU or CPUs.
Note that %iowait has historically indicated a problem in I/O performance. However CPU performance has increased at a much greater rate than disk i/p so a high %iowait indication may be a misleading indication. %iowait measures CPU performance, not I/O. To be precise, %iowait measures the percent of time the CPU is idle, but waiting for an I/O to complete. As such, it is only indirectly related to I/O performance, which can result in false conclusions. It is possible to have healthy system with nearly 100% iowait, or have a disk bottleneck with 0% iowait.
pmap - Process Memory Usage
The command pmap report memory map of a process. Use this command to find out causes of memory bottlenecks.
# pmap -d PID
To display process memory information for pid # 47394, enter:
# pmap -d 47394
Sample Outputs:
47394: /usr/bin/php-cgi
Address Kbytes Mode Offset Device Mapping
0000000000400000 2584 r-x-- 0000000000000000 008:00002 php-cgi
0000000000886000 140 rw--- 0000000000286000 008:00002 php-cgi
00000000008a9000 52 rw--- 00000000008a9000 000:00000 [ anon ]
0000000000aa8000 76 rw--- 00000000002a8000 008:00002 php-cgi
000000000f678000 1980 rw--- 000000000f678000 000:00000 [ anon ]
000000314a600000 112 r-x-- 0000000000000000 008:00002 ld-2.5.so
000000314a81b000 4 r---- 000000000001b000 008:00002 ld-2.5.so
000000314a81c000 4 rw--- 000000000001c000 008:00002 ld-2.5.so
000000314aa00000 1328 r-x-- 0000000000000000 008:00002 libc-2.5.so
000000314ab4c000 2048 ----- 000000000014c000 008:00002 libc-2.5.so
.....
......
..
00002af8d48fd000 4 rw--- 0000000000006000 008:00002 xsl.so
00002af8d490c000 40 r-x-- 0000000000000000 008:00002 libnss_files-2.5.so
00002af8d4916000 2044 ----- 000000000000a000 008:00002 libnss_files-2.5.so
00002af8d4b15000 4 r---- 0000000000009000 008:00002 libnss_files-2.5.so
00002af8d4b16000 4 rw--- 000000000000a000 008:00002 libnss_files-2.5.so
00002af8d4b17000 768000 rw-s- 0000000000000000 000:00009 zero (deleted)
00007fffc95fe000 84 rw--- 00007ffffffea000 000:00000 [ stack ]
ffffffffff600000 8192 ----- 0000000000000000 000:00000 [ anon ]
mapped: 933712K writeable/private: 4304K shared: 768000K
The last line is very important:
mapped: 933712K total amount of memory mapped to files
writeable/private: 4304K the amount of private address space
shared: 768000K the amount of address space this process is sharing with others
htop
htop is an interactive process viewer for Linux. It is a text-mode application and has a few enhancements over the top command. htop is not in all distributions but should work in any linux distro using kernels above 2.4
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=058dc6e0-6854-4fd4-8ef8-ddd07faaf633)
The top program provides a real-time view of the processes running on a system. it displays the most CPU-intensive tasks running on the server and updates the list every five seconds.
The top command has several useful hot keys:
-t Displays summary information.
-m Displays memory information.
-A Sorts the display by top consumers of various system resources.
- f interactive configuration screen.
- o select the ordering within top.
- r Issues renice command.
- k Issues kill command.
- z color/mono
vmstat -
vmstat reports information about processes, memory, paging, block IO, traps, and cpu activity.
Sample Outputs:
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 2540988 522188 5130400 0 0 2 32 4 2 4 1 96 0 0
1 0 0 2540988 522188 5130400 0 0 0 720 1199 665 1 0 99 0 0
0 0 0 2540956 522188 5130400 0 0 0 0 1151 1569 4 1 95 0 0
0 0 0 2540956 522188 5130500 0 0 0 6 1117 439 1 0 99 0 0
0 0 0 2540940 522188 5130512 0 0 0 536 1189 932 1 0 98 0 0
0 0 0 2538444 522188 5130588 0 0 0 0 1187 1417 4 1 96 0 0
0 0 0 2490060 522188 5130640 0 0 0 18 1253 1123 5 1 94 0 0
Display Memory Utilization Slabinfo
# vmstat -m
Get Information About Active / Inactive Memory Pages
# vmstat -a
ps
ps command will display a listing of running processes. with no switches it will display the listing of processes owned by the current user using the short display.
to display processes for all users you can use the -a or -e switch.
# ps -A
PID TTY TIME CMD
1 ? 00:00:02 init
2 ? 00:00:02 migration/0
3 ? 00:00:01 ksoftirqd/0
4 ? 00:00:00 watchdog/0
5 ? 00:00:00 migration/1
6 ? 00:00:15 ksoftirqd/1
....
.....
4881 ? 00:53:28 java
4885 tty1 00:00:00 mingetty
4886 tty2 00:00:00 mingetty
4887 tty3 00:00:00 mingetty
4888 tty4 00:00:00 mingetty
4891 tty5 00:00:00 mingetty
4892 tty6 00:00:00 mingetty
4893 ttyS1 00:00:00 agetty
12853 ? 00:00:00 cifsoplockd
12854 ? 00:00:00 cifsdnotifyd
14231 ? 00:10:34 lighttpd
14232 ? 00:00:00 php-cgi
54981 pts/0 00:00:00 vim
55465 ? 00:00:00 php-cgi
55546 ? 00:00:00 bind9-snmp-stat
55704 pts/1 00:00:00 ps
ps is just like top but provides more information.
The long format displays more detailed information about the processes. You get the long format by adding the -l switch. The command below will list processes for all users using the long format.
# ps -Al
To turn on extra full mode (it will show command line arguments passed to process):
# ps -AlF
To See Threads ( LWP and NLWP)
# ps -AlFH
To See Threads After Processes
# ps -AlLm
Print All Process On The Server
# ps ax
# ps axu
Print A Process Tree
# ps -ejH
# ps axjf
# pstree
Print Security Information
# ps -eo euser,ruser,suser,fuser,f,comm,label
# ps axZ
# ps -eM
See Every Process Running As User smith
# ps -U smith -u smith u
Set Output In a User-Defined Format
# ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm
# ps axo stat,euid,ruid,tty,tpgid,sess,pgrp,ppid,pid,pcpu,comm
# ps -eopid,tt,user,fname,tmout,f,wchan
Display Only The Process IDs of Lighttpd
# ps -C lighttpd -o pid=
OR
# pgrep lighttpd
OR
# pgrep -u vivek php-cgi
Display The Name of PID 55977
# ps -p 55977 -o comm=
Find Out The Top 10 Memory Consuming Process
# ps -auxf | sort -nr -k 4 | head -10
Find Out top 10 CPU Consuming Process
# ps -auxf | sort -nr -k 3 | head -10
free - Memory Usage
the command 'free' displays the total amount of free and used physical and swap memory in the system, as well as the buffers used by the kernel.
# free
Sample Output:
total used free shared buffers cached
Mem: 12302896 9739664 2563232 0 523124 5154740
-/+ buffers/cache: 4061800 8241096
Swap: 1052248 0 1052248
iostat - Average CPU Load, Disk Activity
The command iostat report Central Processing Unit (CPU) statistics and input/output statistics for devices, partitions and network filesystems (NFS).
# iostat
Sample Outputs:
avg-cpu: %user %nice %system %iowait %steal %idle
3.50 0.09 0.51 0.03 0.00 95.86
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 22.04 31.88 512.03 16193351 260102868
sda1 0.00 0.00 0.00 2166 180
sda2 22.04 31.87 512.03 16189010 260102688
sda3 0.00 0.00 0.00 1615 0
sar - Collect and Report System Activity
The sar command is used to collect, report, and save system activity information.
To see network counter, enter:
# sar -n DEV | more
To display the network counters from the 24th:
# sar -n DEV -f /var/log/sa/sa24 | more
You can also display real time usage using sar:
# sar 4 5
Sample Outputs:
06:45:12 PM CPU %user %nice %system %iowait %steal %idle
06:45:16 PM all 2.00 0.00 0.22 0.00 0.00 97.78
06:45:20 PM all 2.07 0.00 0.38 0.03 0.00 97.52
06:45:24 PM all 0.94 0.00 0.28 0.00 0.00 98.78
06:45:28 PM all 1.56 0.00 0.22 0.00 0.00 98.22
06:45:32 PM all 3.53 0.00 0.25 0.03 0.00 96.19
Average: all 2.02 0.00 0.27 0.01 0.00 97.70
mpstat - Multiprocessor Usage
Multi Processor Statistics - The mpstat command displays processor statistics for each available processor, processor 0 being the first. It also reports statistics about the overall activity of all processors combined. The mpstat command can be used both on SMP and UP machines.
# mpstat -P ALL.
Where, -P cpu | ALL option indicate the processor number for which statistics are to be reported. cpu is the processor number. Note that processor 0 is the first processor. The ALL keyword indicates that statistics are to be reported for all processors.
Output:
04:13:29 PM CPU %user %nice %system %iowait %irq %soft %idle intr/s
04:13:29 PM all 5.63 0.01 2.33 0.85 0.01 0.10 91.06 2255.03
04:13:29 PM 0 5.74 0.00 2.17 0.88 0.01 0.15 91.05 1170.16
04:13:29 PM 1 5.53 0.01 2.49 0.83 0.01 0.06 91.07 1084.87
Understanding mpstat output
* CPU: Processor number. This is the logical cpu number (0 being the first) and "all" is a global average for all processors.
* %user: Shows the percentage of CPU utilization used for executing user level applications.
* %nice: Shows the percentage of CPU utilization used for executing at the user level with nice priority.
* %system: Shows the percentage of CPU utilization used for system level (kernel) processes. Note this does not include time spent servicing
interrupts or softirqs.
* %iowait: Shows the percentage of time that the CPU was idle while waiting on an outstanding I/O request.
* %irq: Shows the percentage of time spent servicing hardware interrupts.
* %soft: Shows the percentage of time spent servicing softirqs. A softirq (software interrupt) is one of up to 32 enumerated software interrupts
which can run on multiple CPUs at once.
* %idle: Show the percentage of time the processor was idle and the system did not have an outstanding disk I/O request.
* intr/s: Show the total number of interrupts received per second by the CPU or CPUs.
Note that %iowait has historically indicated a problem in I/O performance. However CPU performance has increased at a much greater rate than disk i/p so a high %iowait indication may be a misleading indication. %iowait measures CPU performance, not I/O. To be precise, %iowait measures the percent of time the CPU is idle, but waiting for an I/O to complete. As such, it is only indirectly related to I/O performance, which can result in false conclusions. It is possible to have healthy system with nearly 100% iowait, or have a disk bottleneck with 0% iowait.
pmap - Process Memory Usage
The command pmap report memory map of a process. Use this command to find out causes of memory bottlenecks.
# pmap -d PID
To display process memory information for pid # 47394, enter:
# pmap -d 47394
Sample Outputs:
47394: /usr/bin/php-cgi
Address Kbytes Mode Offset Device Mapping
0000000000400000 2584 r-x-- 0000000000000000 008:00002 php-cgi
0000000000886000 140 rw--- 0000000000286000 008:00002 php-cgi
00000000008a9000 52 rw--- 00000000008a9000 000:00000 [ anon ]
0000000000aa8000 76 rw--- 00000000002a8000 008:00002 php-cgi
000000000f678000 1980 rw--- 000000000f678000 000:00000 [ anon ]
000000314a600000 112 r-x-- 0000000000000000 008:00002 ld-2.5.so
000000314a81b000 4 r---- 000000000001b000 008:00002 ld-2.5.so
000000314a81c000 4 rw--- 000000000001c000 008:00002 ld-2.5.so
000000314aa00000 1328 r-x-- 0000000000000000 008:00002 libc-2.5.so
000000314ab4c000 2048 ----- 000000000014c000 008:00002 libc-2.5.so
.....
......
..
00002af8d48fd000 4 rw--- 0000000000006000 008:00002 xsl.so
00002af8d490c000 40 r-x-- 0000000000000000 008:00002 libnss_files-2.5.so
00002af8d4916000 2044 ----- 000000000000a000 008:00002 libnss_files-2.5.so
00002af8d4b15000 4 r---- 0000000000009000 008:00002 libnss_files-2.5.so
00002af8d4b16000 4 rw--- 000000000000a000 008:00002 libnss_files-2.5.so
00002af8d4b17000 768000 rw-s- 0000000000000000 000:00009 zero (deleted)
00007fffc95fe000 84 rw--- 00007ffffffea000 000:00000 [ stack ]
ffffffffff600000 8192 ----- 0000000000000000 000:00000 [ anon ]
mapped: 933712K writeable/private: 4304K shared: 768000K
The last line is very important:
mapped: 933712K total amount of memory mapped to files
writeable/private: 4304K the amount of private address space
shared: 768000K the amount of address space this process is sharing with others
htop
htop is an interactive process viewer for Linux. It is a text-mode application and has a few enhancements over the top command. htop is not in all distributions but should work in any linux distro using kernels above 2.4
- In 'htop' you can scroll the list vertically and horizontally to see all processes and complete command lines.
- In 'top' you are subject to a delay for each unassigned key you press (especially annoying when multi-key escape sequences are triggered by accident).
- 'htop' starts faster ('top' seems to collect data for a while before displaying anything).
- In 'htop' you don't need to type the process number to kill a process, in 'top' you do.
- In 'htop' you don't need to type the process number or the priority value to renice a process, in 'top' you do.
- 'htop' supports mouse operation, 'top' doesn't
Analyzing SELinux AVC Messages
- AVC Messages refering to files labeled *:file_t
This indicates you have a major Labeling problem. When the SELinux kernel discovers a file that has no security context, it sets it label to file_t. Ordinarly no confined domain has access to file_t. The only way that this file would get created is if the system was booted with selinux=0 (or SELINUX=disabled in /etc/selinux/config). Or if you added a new disk to a machine that was not labeled via SELinux. In the case of the machine was running with selinux=0, it is safest to relabel the system.
This command must be run as root:
touch /.autorelabel
reboot
If you are adding a new disk, you can restorecon -R -v /MOUNTPOINT to fix the labels.
- AVC Messages containing default_t:
This can also indicate a labeling problem, especially if the file being referred to is not a top level file. IE everything under /usr, /var. /dev, /tmp, ... should not be labeled default_t. default_t is the label for files who do not have a label on a parent directory. So if you create a new directory in / you might legitimately get this label. If you want a confined domain to use these files you will probably need to relabel the directory with chcon. In some cases it is just easier to use the autorelabel command above.
- AVC Messages indicate that a sharing domain failed to access certain files:
a. Confined sharing domains are httpd, smbd, ftpd, and rsync a. If the files are in a users home dir, user_home_t, then you probably need to turn on a boolean to allow this access. setsebool -P httpd_enable_homedirs=1 would turn on httpd's access to the homedirs. a. If the file context is another location on the disk, you might be able to get it working by using chcon. Each domain has file context that they are able to read and/or write. So if you created a directory like /src and you wanted samba to share it, you would chcon -R -t samba_share_t /src. a. Finally if you want multiple "sharing" domains to have access to the same files you can set the file context to public_context_t, if you want multiple daemons to be able to write the content you can set the context to public_context_rw_t and then set the boolean for all domains that need to write. setsebool -P allow_DOMAIN_anon_write=1 a. Please refer to the selinux man page for most confined domains. man httpd_selinux or man ftpd_selinux...
Tuesday, November 17, 2009
Melchora Nunez
This has nothing to do with Linux Security but it's my blog so I'll post it anyway for purely selfish reasons...
many years ago I lived in the Philippines; The base where I was stationed was closed on very short notice due to the eruption of Mount Pinatubo and I lost contact with Melchora Nunez.
She had been living in Pampanga. I think she said she was in Mabalacat the last time we spoke but she was possibly living in balibago, angeles city or dau.
------------
she was originally from somewhere in Cebu.I think she was from somewhere near Caridad or Cabalawan. Her nickname was Juna or Junha or Jona (the inconsistent spelling was her doing - i saw her write it several different ways). We lived for 2 years on 6th Ave. in Plaridel II near Clark AB in Angeles City.
------------
The pictures are from 1988 or 1989. She will certainly be older now. If anyone knows where she might be please let me know or let her know that I am looking for her.
-------------
Melchora Nunez -
nonay
Barbary Coast
pampanga
Balibago
Carl Larson
Ernie Amador
Ernest Amador
((copying her note from August 2003 on usaf.com)) "
Lost Friend: Kieth Basten - Clark Airbase Philippines
Im Melchora Nunez Im looking for my friend Keith Basten a US Airforce before in Clark Airbase Philippines in 1987 -1988 he live in 4830 Sphinx Wy # 1090 Las Vegas i dont know if he is still leaving in this address right now i am hoping that you can help me to find more information about him. Thank you very much, Mechora Nunez"-- Hint: i'm easy to find if you spell my name right :P and i replied to this message in December 2003 but the Yahoo ID you listed in your message had already expired from inactivity which means you didn't get back to check messages and they closed the account.
Open Source Security Testing Methodology Manual - Updated 11/11/09
Latest Revision "Open Source Security Testing Methodology Manual" is available for review at ISECOM -
Monday, November 16, 2009
SELinux Troubleshooting - Part one -
SELinux Troubleshooting Part 1
Overview:
SELinux is “Security-Enhanced Linux” and is a set of mechanisms within the kernel that provides layers of security using Mandatory Access Controls.
Mandatory Access Controls (MAC) defines a framework where every process (which SELinux refers to as “subjects”) interacts with other parts of the system (including files, devices, sockets, ports and other processes (which SELinux refers to as “objects”). SELinux allows you to define a set of rules that state at a very granular level what level of permission a subject has to an object.
By default in an SELinux environment everything is blocked and has to be granted permissions to allow anything to work. This is a philosophy in security referred to as “least permission” or “Allow by exception”.
Vendor implementation varies widely and in most cases the installation of the operating system will automatically grant the necessary permissions for those services and processes that are installed by default however you should review the policy set after installation to ensure against inappropriate privileges that may exceed (or not provide) what your individual needs are.
“Type Enforcement” defines a “type” for every 'subject' (process) on th system and the SELinux policy defines these Types and places “security labels” on the files using “xattrs” or “Extended Attributes”.
Directories and Files:
/etc/selinux/
/etc/selinux/
/etc/selinux/config - The SELinux Configuration file - (Note that this file defines which policy is currently in use. i.e. you may have a “test” policy and a “production” policy with very different rules.
/etc/syslog.conf – may be used to redirect messages from the /var/log/messages to some other destination.
/etc/selinux/booleans
/etc/selinux/contexts
/etc/selinux/targeted/policy/policy.## (the ## represents a two digig policy version number.
Logging:
messages from SELinux are logged to /var/log/messages which you can access using dmesg or using grep to filter on “selinux_messages”
There are two primary places to get messages from SELinux. The “WebTool” and the console.
To get messages from the console you need to be connected as root and then change roles to become the sysadm_r users
you can also use the tool “audit2allow” which will read the 'selinux_messages” lines from your /var/log/messages file and interpret them into an allow list that you can use either to determine what is being blocked. Keep in mind of course that just because something is being blocked doesn't mean you should allow it through.
auditd daemon) is running, SELinux denials are logged into the audit log file. The default audit log file is /var/log/audit/audit.log. In a situation where the auditd daemon is not running, AVC denials are logged in /var/log/messages.Thursday, November 12, 2009
Microsoft tries to patent code they didn't even create (again)
Microsoft has filed for and received from the US Patent and Trademark office a patent for SUDO which Microsoft did not create and they do not own. the sudo command has been around for 29 years before Microsoft had the audacity to attempt to claim a patent on the concept.
http://www.groklaw.net/article.php?story=20091111094923390
They truly know no shame in Redmond.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=217840bd-190c-4a9c-aec0-199f5e39bcc5)
http://www.groklaw.net/article.php?story=20091111094923390
They truly know no shame in Redmond.
new DOD security certification standards
The US DOD (Department of Defense) has approved a set of base credentials that will lead to certification requirements for information security professionals. The (ISC) 2 Certification and Accreditation Professional (CAP) will be required for all DOD information assurance workers under the global ANSI/ISO/IEC Standard 17024.
This certificate requirement will ensure that the holder has deep knowledge of the Certification and Accreditation requirements including a formalized process for assessing IS risks and security requirements and ensuring that the systems have adequate security in place and compliance with regulatory data protection standards.
(ISC)2 is the same organization that maintains the "Certified Information Systems Security Professional" (CISSP) and the "Systems Security Certified Practitioner" (SSCP) certifications.
It also provides certifications for several concentrations of the CISSP, including the Information Systems Security Engineering Professional (ISSEP), the Information Systems Security Architecture Professional (ISSAP); and the Information Security Systems Management Professional (ISSMP).
In addition, recently NIST released a draft contingency planning guide for federal information systems, draft SP 800-34, Revision 1, for public comment. The draft is an upgrade to the original guide published in 2002. Comments are due by Jan. 6, 2010.![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=dfabf913-5512-424c-8dcb-021d79403803)
This certificate requirement will ensure that the holder has deep knowledge of the Certification and Accreditation requirements including a formalized process for assessing IS risks and security requirements and ensuring that the systems have adequate security in place and compliance with regulatory data protection standards.
(ISC)2 is the same organization that maintains the "Certified Information Systems Security Professional" (CISSP) and the "Systems Security Certified Practitioner" (SSCP) certifications.
It also provides certifications for several concentrations of the CISSP, including the Information Systems Security Engineering Professional (ISSEP), the Information Systems Security Architecture Professional (ISSAP); and the Information Security Systems Management Professional (ISSMP).
In addition, recently NIST released a draft contingency planning guide for federal information systems, draft SP 800-34, Revision 1, for public comment. The draft is an upgrade to the original guide published in 2002. Comments are due by Jan. 6, 2010.
Exploring OpenSUSE 11.2 Security Features
These notes are from a posting on OpenSUSE.org/Security
Compiler and Toolchain
* glibc malloc heap corruption checking to avoid double-free and similar attacks. These checks have existed in glibc for several years now and are active for all our distributions starting with SUSE Linux Enterprise Server 9.
* The "Fortify Source" extensions in gcc and glibc are enabled for all packages by default (using -D_FORTIFY_SOURCE=2) since SUSE Linux 10.0 and SUSE Linux Enterprise 10. This extension brings:
o Compile buffer overflow checking for various C string / memory functions. On a overflow of a buffer that is already provable at compile time a warning is emitted by the compiler and caught by our build processes.
o Runtime buffer overflow checking for the C string / memory functions for destination buffers whose size is known at compile time. An overflow here triggers a controlled abort of the program.
o Exploitation of format string problems trigger a controlled abort of the program.
o Specific warnings on missing return value checks of dangerous library functions.
* Runtime stack overflow checking using -fstack-protector is used in some critical packages in SUSE Linux 10.1 and SUSE Linux Enterprise 10 and enabled by default for all packages starting with openSUSE 10.2.
* Marking stack and heap non-executable to make NX possible is done for nearly all packages for some time now.
* -z relro is enabled by default since SUSE Linux 10.1, which makes attacks on specific ELF sections no longer work.
Kernel
* Hardware based NX (No eXecute, also known as DEP) support is enabled for Stack and Heap since SUSE Linux Enterprise Server 9 on:
o all AMD64/EM64T processors.
o on x86 machines using the "bigsmp" or "pae" kernel and the processor being able to support the NX bit.
* We do not include Software NX at this time, since it is not in the mainline kernel and likely never will be.
* Address Space Randomization is used for the stack and library mappings since SUSE Linux Enterprise 10 and SUSE Linux 10.1.
* Address Space Randomization for PIE binaries and their heaps since openSUSE 11.1 and SUSE Linux Enterprise 11.
* "ExecShield" and "PAX" contain several features including the ones listed above. This means that we implement parts of the "ExecShield" and "PAX" functions already at this time.
AppArmor
We included the Mandatory Access Control System AppArmor to confine potentially endangered applications.
Firewall
Since SUSE Linux 9.3 the iptables based SuSEfirewall2 is enabled by default, including a very restrictive inbound filtering.
Software Choice
We chose to run only a minimal set of daemons in the default configuration. Only the following are listening to the network:
* SSH daemon
* portmap daemon
* avahi/mDNSResponder
* cups print server
All of them are blocked by the firewall by default though.
setuid binaries
Setuid/setgid binaries are:
* kept to a minimum. We try to replace them by more secure methods of user - root privilege passing or even get rid of them at all.
* new ones are required to be source audited by the Security Team, old ones are audited again after some time.
Source code audits
System services, setuid binaries and other security relevant software is audited by the security team and the findings reported to the upstream maintainers and fixed.
Compiler and Toolchain
* glibc malloc heap corruption checking to avoid double-free and similar attacks. These checks have existed in glibc for several years now and are active for all our distributions starting with SUSE Linux Enterprise Server 9.
* The "Fortify Source" extensions in gcc and glibc are enabled for all packages by default (using -D_FORTIFY_SOURCE=2) since SUSE Linux 10.0 and SUSE Linux Enterprise 10. This extension brings:
o Compile buffer overflow checking for various C string / memory functions. On a overflow of a buffer that is already provable at compile time a warning is emitted by the compiler and caught by our build processes.
o Runtime buffer overflow checking for the C string / memory functions for destination buffers whose size is known at compile time. An overflow here triggers a controlled abort of the program.
o Exploitation of format string problems trigger a controlled abort of the program.
o Specific warnings on missing return value checks of dangerous library functions.
* Runtime stack overflow checking using -fstack-protector is used in some critical packages in SUSE Linux 10.1 and SUSE Linux Enterprise 10 and enabled by default for all packages starting with openSUSE 10.2.
* Marking stack and heap non-executable to make NX possible is done for nearly all packages for some time now.
* -z relro is enabled by default since SUSE Linux 10.1, which makes attacks on specific ELF sections no longer work.
Kernel
* Hardware based NX (No eXecute, also known as DEP) support is enabled for Stack and Heap since SUSE Linux Enterprise Server 9 on:
o all AMD64/EM64T processors.
o on x86 machines using the "bigsmp" or "pae" kernel and the processor being able to support the NX bit.
* We do not include Software NX at this time, since it is not in the mainline kernel and likely never will be.
* Address Space Randomization is used for the stack and library mappings since SUSE Linux Enterprise 10 and SUSE Linux 10.1.
* Address Space Randomization for PIE binaries and their heaps since openSUSE 11.1 and SUSE Linux Enterprise 11.
* "ExecShield" and "PAX" contain several features including the ones listed above. This means that we implement parts of the "ExecShield" and "PAX" functions already at this time.
AppArmor
We included the Mandatory Access Control System AppArmor to confine potentially endangered applications.
Firewall
Since SUSE Linux 9.3 the iptables based SuSEfirewall2 is enabled by default, including a very restrictive inbound filtering.
Software Choice
We chose to run only a minimal set of daemons in the default configuration. Only the following are listening to the network:
* SSH daemon
* portmap daemon
* avahi/mDNSResponder
* cups print server
All of them are blocked by the firewall by default though.
setuid binaries
Setuid/setgid binaries are:
* kept to a minimum. We try to replace them by more secure methods of user - root privilege passing or even get rid of them at all.
* new ones are required to be source audited by the Security Team, old ones are audited again after some time.
Source code audits
System services, setuid binaries and other security relevant software is audited by the security team and the findings reported to the upstream maintainers and fixed.
OpenSUSE 11.2 ships today -
November 12th, 2009 by Joe Brockmeier
openSUSE 11.2 features two GNOME releases worth of updates over 11.1. Because of the lengthy release cycle, openSUSE skipped the 2.26 release and jumped to GNOME 2.28, which was made available in September.
Nautilus now has a plugin to allow quick and easy file sharing. Just right-click on the folder you’d like to share and select “Sharing Options.” This makes use of Samba, so you need to enable directory sharing under the Samba Server module in YaST.
New and Improved Cheese
The Webcam application for GNOME, Cheese, includes some enhancements for 2.28, including a redesigned interface that’s better suited for netbooks.
Not only does openSUSE feature the goodness from upstream GNOME, but also some home-grown improvements as well. For instance, the Sonar theme that is the default in 11.2. It’s a slightly darker, but still green, theme that’s pleasant to look at and show off to users new to Linux!
Vincent Untz, a member of the openSUSE Booster team and member of the GNOME Foundation Board, says that part of the main focus for 11.2 was “to be a better upstream citizen” with GNOME. So, for the most part, openSUSE does not diverge greatly from upstream GNOME — but there are some differences.
For example, GNOME 2.28 ships Empathy as the default instant messaging client. Untz says that it’s likely openSUSE will switch to Empathy in 11.3, but due to issues with some protocols and proxies, it was decided to keep Pidgin as the default client for one more release. Empathy is, of course, available via the repositories, so users who want to start with Empathy now can do so.
Want to get a preview of GNOME 3.0? The final GNOME 3.0 release isn’t due until September 2010, but openSUSE 11.2 has an early build of GNOME Shell in the repositories and users can see what all the fuss is about (or will be about), early on.
And, of course, you’ll find Firefox as the default Web browser for openSUSE instead of Epiphany. openSUSE users will find the most recent stable version of Firefox (3.5) on their GNOME desktop, though Epiphany and its new Webkit backend are available in the openSUSE 11.2 repositories.
Wednesday, November 11, 2009
introduction to SELinux
This article is a slightly cleaned up port from Wikipedia; I am not the author but I am including this as a introduction to SELinux as I will be posting some articles over the next few days with various SELinux configuration examples. I will also soon have an AppArmor series that showcases the differences between the two systems - This following content was brought over as it appeared on 11/10/2009 from - http://en.wikipedia.org/wiki/Selinux
Security-Enhanced Linux (SELinux) is a Linux feature that provides a mechanism for supporting access control security policies, including U.S. Department of Defense style mandatory access controls, through the use of Linux Security Modules (LSM) in the Linux kernel. It is not a Linux distribution, but rather a set of modifications that can be applied to Unix-like operating systems, such as Linux and BSD. Its architecture strives to streamline the volume of software charged with security policy enforcement, which is closely aligned with the Trusted Computer System Evaluation Criteria (TCSEC, referred to as Orange Book) requirement for trusted computing base (TCB) minimization (applicable to evaluation classes B3 and A1). The germinal concepts underlying SELinux can be traced to several earlier projects by the U.S. National Security Agency.
Overview
Primarily developed by the US National Security Agency, it was released to the open source development community under the GNU GPL on December 22, 2000 and merged into the mainline kernel 2.6.0-test3, released on 8 August 2003. Other significant contributors include Network Associates, Secure Computing Corporation, Trusted Computer Solutions, and Tresys. Experimental ports of the FLASK/TE implementation have been made available via the TrustedBSD Project for the FreeBSD and Darwin operating systems.
From NSA Security-enhanced Linux Team:
"NSA Security-enhanced Linux is a set of patches to the Linux kernel and some utilities to incorporate a strong, flexible mandatory access control (MAC) architecture into the major subsystems of the kernel. It provides an enhanced mechanism to enforce the separation of information based on confidentiality and integrity requirements, which allows threats of tampering and bypassing of application security mechanisms to be addressed and enables the confinement of damage that can be caused by malicious or flawed applications. It includes a set of sample security policy configuration files designed to meet common, general-purpose security goals."
Security-Enhanced Linux is a FLASK implementation integrated in some versions of the Linux kernel with a number of utilities designed to demonstrate the value of mandatory access controls to the Linux community and how such controls could be added to Linux. Such a kernel contains architectural components prototyped in the Fluke operating system. These provide general support for enforcing many kinds of mandatory access control policies, including those based on the concepts of type enforcement, role-based access control, and multi-level security. Observers of operating system security research may recall DTOS, a Mach-derived Distributed Trusted Operating System, on which Flask was based, as well as Trusted Mach, a research project from Trusted Information Systems that was influential in the design and implementation of DTOS.
A Linux kernel integrating SELinux enforces mandatory access control policies that confine user programs and system servers to the minimum amount of privilege they require to do their jobs. This reduces or eliminates the ability of these programs and daemons to cause harm when compromised (via buffer overflows or misconfigurations, for example). This confinement mechanism operates independently of the traditional Linux access control mechanisms. It has no concept of a "root" super-user, and does not share the well-known shortcomings of the traditional Linux security mechanisms (such as a dependence on setuid/setgid binaries).
The security of an unmodified Linux system depends on the correctness of the kernel, all the privileged applications, and each of their configurations. A problem in any one of these areas may allow the compromise of the entire system. In contrast, the security of a modified system based on an SELinux kernel depends primarily on the correctness of the kernel and its security policy configuration. While problems with the correctness or configuration of applications may allow the limited compromise of individual user programs and system daemons, they do not pose a threat to the security of other user programs and system daemons or to the security of the system as a whole.
From a puristic perspective, SELinux provides a hybrid of concepts and capabilities drawn from mandatory access controls, mandatory integrity controls, role-based access control (RBAC), and type enforcement architecture. Third-party tools enable one to build a variety of security policies.
Features
* Clean separation of policy from enforcement
* Well-defined policy interfaces
* Support for applications querying the policy and enforcing access control (for example, crond running jobs in the correct context)
* Independent of specific policies and policy languages
* Independent of specific security label formats and contents
* Individual labels and controls for kernel objects and services
* Caching of access decisions for efficiency
* Support for policy changes
* Separate measures for protecting system integrity (domain-type) and data confidentiality (multilevel security)
* Very flexible policy
* Controls over process initialization and inheritance and program execution
* Controls over file systems, directories, files, and open file descriptors
* Controls over sockets, messages, and network interfaces
* Controls over use of "capabilities"
Implementations
SELinux is available with commercial support as part of Red Hat Enterprise Linux (RHEL) version 4 and all future releases. This presence is also reflected in corresponding versions of CentOS. The supported policy in RHEL4 is the targeted policy which aims for maximum ease of use and thus is not as restrictive as it might be. Future versions of RHEL will have more targets in the targeted policy which will mean more restrictive policies.
In free community supported Linux distributions, SELinux is supported in Debian as of the etch release, Ubuntu as of 8.04, Fedora since version 2, Hardened Gentoo, and Yellow Dog Linux.
It is also supported in EnGarde Secure Linux which requires registration to download.
As of version 11.1, openSUSE contains SELinux 'basic enablement'.SUSE Linux Enterprise 11 will feature SELinux as a 'technology preview'.
The earliest work directed toward standardizing an approach toward provision of mandatory and discretionary access controls (MAC & DAC) within a UNIX (more precisely, POSIX) computing environment can be attributed to the National Security Agency's Trusted UNIX (TRUSIX) Working Group, which met from 1987 to 1991 and published one Rainbow Book (#020A) and produced a formal model and associated evaluation evidence prototype (#020B) that—courtesy of its profound creativity and resultant opacity to typically technically junior NCSC staff—was ultimately unpublished. Sponsored by Chet Coates and Mario Tinto of the NSA's National Computer Security Center, and managed by Dr. Charles Testa and Bruce Wilner of Infosystems Technology (Greenbelt, MD; later, Falls Church, VA), the crucial architects of the TRUSIX project — and members of its Modelling Subcommittee — were Steve Bunch, Dr. Frank Knowles, Dr. J. Eric Roskos, Larry Wehr, and Bruce Wilner. (Testa and Wilner also, under NSA auspices, briefly chaired the joint DoD/DOE Labeling Working Group — which counted among its membership such early TCSEC luminaries as David Bell, Marvin Schaefer [former chief scientist, DoD Computer Security Center], and Willis Ware — as well as building Trusted RUBIX, the only relational database management system to offer B2 functionality and assurance atop a B2 POSIX platform, partially under the auspices of the United States Air Force Rome Laboratory.) Their efforts, particularly as critics of the less technically profound work of the TRUSIX Access Control List (ACL) Subcommittee, survive in the IEEE POSIX 1003.6 "security extensions for portable operating systems environments" specification.
[edit] Other systems
SELinux represents one of several possible approaches to the problem of restricting the actions that installed software can take.
Novell's AppArmor takes a similar approach to SELinux; One important difference is that it identifies file system objects by path name instead of inode. This means that, for example, a file that is inaccessible may become accessible under AppArmor when a hard link is created to it, while SELinux would deny access through the newly created hard link. On the other hand, data that is inaccessible may become accessible when applications update the file by replacing it with a new version (a frequently used technique), while AppArmor would continue to deny access to the data. Also AppArmor can make use of filesystems with no support for extended file attributes, such as NFS while SELinux cannot.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=6f9f0128-75d2-4af2-bb1f-fd0b35549092)
Security-Enhanced Linux (SELinux) is a Linux feature that provides a mechanism for supporting access control security policies, including U.S. Department of Defense style mandatory access controls, through the use of Linux Security Modules (LSM) in the Linux kernel. It is not a Linux distribution, but rather a set of modifications that can be applied to Unix-like operating systems, such as Linux and BSD. Its architecture strives to streamline the volume of software charged with security policy enforcement, which is closely aligned with the Trusted Computer System Evaluation Criteria (TCSEC, referred to as Orange Book) requirement for trusted computing base (TCB) minimization (applicable to evaluation classes B3 and A1). The germinal concepts underlying SELinux can be traced to several earlier projects by the U.S. National Security Agency.
Overview
Primarily developed by the US National Security Agency, it was released to the open source development community under the GNU GPL on December 22, 2000 and merged into the mainline kernel 2.6.0-test3, released on 8 August 2003. Other significant contributors include Network Associates, Secure Computing Corporation, Trusted Computer Solutions, and Tresys. Experimental ports of the FLASK/TE implementation have been made available via the TrustedBSD Project for the FreeBSD and Darwin operating systems.
From NSA Security-enhanced Linux Team:
"NSA Security-enhanced Linux is a set of patches to the Linux kernel and some utilities to incorporate a strong, flexible mandatory access control (MAC) architecture into the major subsystems of the kernel. It provides an enhanced mechanism to enforce the separation of information based on confidentiality and integrity requirements, which allows threats of tampering and bypassing of application security mechanisms to be addressed and enables the confinement of damage that can be caused by malicious or flawed applications. It includes a set of sample security policy configuration files designed to meet common, general-purpose security goals."
Security-Enhanced Linux is a FLASK implementation integrated in some versions of the Linux kernel with a number of utilities designed to demonstrate the value of mandatory access controls to the Linux community and how such controls could be added to Linux. Such a kernel contains architectural components prototyped in the Fluke operating system. These provide general support for enforcing many kinds of mandatory access control policies, including those based on the concepts of type enforcement, role-based access control, and multi-level security. Observers of operating system security research may recall DTOS, a Mach-derived Distributed Trusted Operating System, on which Flask was based, as well as Trusted Mach, a research project from Trusted Information Systems that was influential in the design and implementation of DTOS.
A Linux kernel integrating SELinux enforces mandatory access control policies that confine user programs and system servers to the minimum amount of privilege they require to do their jobs. This reduces or eliminates the ability of these programs and daemons to cause harm when compromised (via buffer overflows or misconfigurations, for example). This confinement mechanism operates independently of the traditional Linux access control mechanisms. It has no concept of a "root" super-user, and does not share the well-known shortcomings of the traditional Linux security mechanisms (such as a dependence on setuid/setgid binaries).
The security of an unmodified Linux system depends on the correctness of the kernel, all the privileged applications, and each of their configurations. A problem in any one of these areas may allow the compromise of the entire system. In contrast, the security of a modified system based on an SELinux kernel depends primarily on the correctness of the kernel and its security policy configuration. While problems with the correctness or configuration of applications may allow the limited compromise of individual user programs and system daemons, they do not pose a threat to the security of other user programs and system daemons or to the security of the system as a whole.
From a puristic perspective, SELinux provides a hybrid of concepts and capabilities drawn from mandatory access controls, mandatory integrity controls, role-based access control (RBAC), and type enforcement architecture. Third-party tools enable one to build a variety of security policies.
Features
* Clean separation of policy from enforcement
* Well-defined policy interfaces
* Support for applications querying the policy and enforcing access control (for example, crond running jobs in the correct context)
* Independent of specific policies and policy languages
* Independent of specific security label formats and contents
* Individual labels and controls for kernel objects and services
* Caching of access decisions for efficiency
* Support for policy changes
* Separate measures for protecting system integrity (domain-type) and data confidentiality (multilevel security)
* Very flexible policy
* Controls over process initialization and inheritance and program execution
* Controls over file systems, directories, files, and open file descriptors
* Controls over sockets, messages, and network interfaces
* Controls over use of "capabilities"
Implementations
SELinux is available with commercial support as part of Red Hat Enterprise Linux (RHEL) version 4 and all future releases. This presence is also reflected in corresponding versions of CentOS. The supported policy in RHEL4 is the targeted policy which aims for maximum ease of use and thus is not as restrictive as it might be. Future versions of RHEL will have more targets in the targeted policy which will mean more restrictive policies.
In free community supported Linux distributions, SELinux is supported in Debian as of the etch release, Ubuntu as of 8.04, Fedora since version 2, Hardened Gentoo, and Yellow Dog Linux.
It is also supported in EnGarde Secure Linux which requires registration to download.
As of version 11.1, openSUSE contains SELinux 'basic enablement'.SUSE Linux Enterprise 11 will feature SELinux as a 'technology preview'.
The earliest work directed toward standardizing an approach toward provision of mandatory and discretionary access controls (MAC & DAC) within a UNIX (more precisely, POSIX) computing environment can be attributed to the National Security Agency's Trusted UNIX (TRUSIX) Working Group, which met from 1987 to 1991 and published one Rainbow Book (#020A) and produced a formal model and associated evaluation evidence prototype (#020B) that—courtesy of its profound creativity and resultant opacity to typically technically junior NCSC staff—was ultimately unpublished. Sponsored by Chet Coates and Mario Tinto of the NSA's National Computer Security Center, and managed by Dr. Charles Testa and Bruce Wilner of Infosystems Technology (Greenbelt, MD; later, Falls Church, VA), the crucial architects of the TRUSIX project — and members of its Modelling Subcommittee — were Steve Bunch, Dr. Frank Knowles, Dr. J. Eric Roskos, Larry Wehr, and Bruce Wilner. (Testa and Wilner also, under NSA auspices, briefly chaired the joint DoD/DOE Labeling Working Group — which counted among its membership such early TCSEC luminaries as David Bell, Marvin Schaefer [former chief scientist, DoD Computer Security Center], and Willis Ware — as well as building Trusted RUBIX, the only relational database management system to offer B2 functionality and assurance atop a B2 POSIX platform, partially under the auspices of the United States Air Force Rome Laboratory.) Their efforts, particularly as critics of the less technically profound work of the TRUSIX Access Control List (ACL) Subcommittee, survive in the IEEE POSIX 1003.6 "security extensions for portable operating systems environments" specification.
[edit] Other systems
SELinux represents one of several possible approaches to the problem of restricting the actions that installed software can take.
Novell's AppArmor takes a similar approach to SELinux; One important difference is that it identifies file system objects by path name instead of inode. This means that, for example, a file that is inaccessible may become accessible under AppArmor when a hard link is created to it, while SELinux would deny access through the newly created hard link. On the other hand, data that is inaccessible may become accessible when applications update the file by replacing it with a new version (a frequently used technique), while AppArmor would continue to deny access to the data. Also AppArmor can make use of filesystems with no support for extended file attributes, such as NFS while SELinux cannot.
Darl McBride is outta there....
how did I miss this? - Darl McBride has been terminated from SCO effective October 14th, 2009. For those that don't know McBride was the CEO of SCO and the architect of the entirely discredited patent infringement lawsuits against Novell and IBM.
With McBride out of the picture and the SCO lawsuits little more than a laughing stock I hope to see those illegitimate claims brought to quick cloture.
With McBride out of the picture and the SCO lawsuits little more than a laughing stock I hope to see those illegitimate claims brought to quick cloture.
Tuning Linux Page Cache and pdflush for improved disk i/o
I've used this document often when tuning disk performance on Database and mail servers. It's not related to security but It is very helpful for getting better disk performance out of systems with heavy disk i/o.
http://www.westnet.com/~gsmith/content/linux-pdflush.htm
http://www.westnet.com/~gsmith/content/linux-pdflush.htm
changing root password in Ubuntu 9.10
After I installed Ubuntu 9.10 I tried to change the root password but after I unlocked and set password for the root account, i can’t login (via terminal) as root. I even tried to set password three times just to make sure i typed it correctly. after poking around for a bit I found some similar reports on Ubuntu's Forums and a link to “Policy on log-in-as-root tutorials” with an explanation about Ubuntu’s RootSudo policy. Apparently if you really need to login as root you can either use the “sudo -i” to simulate the root login (this will ask for your password and log you in as root), or enable the root account “sudo passwd root” (this will ask for your password and will prompt you to enter new root password).
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=6fc129de-2a96-4a19-991e-830a280e0499)
Ubuntu v9.10 Server is out
http://www.ubuntu.com/getubuntu/download-server
press release below:
press release below:
Ubuntu 9.10 Desktop Edition puts the user at the heart of its new design
Integrates dozens of new features and improvements to take user experience to next level
LONDON, October 26, 2009: Canonical announced today the upcoming release of Ubuntu 9.10 Desktop Edition, the latest version of the popular Linux desktop distribution. Ubuntu 9.10 will be available for free download on Thursday 29 October. Ubuntu 9.10 brings changes small and large that all have a common purpose - to make Ubuntu the most user-friendly operating system available. Ubuntu 9.10 features a redesigned, faster boot and login experience, a revamped audio framework, and improved 3G broadband connectivity, all of which contribute to a first-class user experience.
Furthermore, the innovative '100 Paper Cuts' initiative organised with the Ubuntu Community allowed users to nominate minor annoyances that impacted their enjoyment of the platform. So far over 50 fixes have been committed, removing minor irritants such as inconsistent naming or poorly organised application choices. Larger scale user experience improvements include a refreshed Ubuntu Software Center, giving users better and more easily understood information about the software they have available - bringing the world of open source applications closer to the user. These improvements, in combination, have a transformative effect on the user experience.
Ubuntu 9.10 also includes the integration of 'Ubuntu One' as a standard component of the desktop. Ubuntu One is an umbrella name for an exciting suite of online services, which were released in beta in May 2009. Ubuntu One provides an enhanced desktop experience, simplifies backup, synchronisation, and sharing of files with an expanded set of features including Tomboy Notes and contacts synchronisation.
Ubuntu 9.10 also welcomes a host of features that make it the best platform for developers, whether professional or casual. Developers interested in writing applications that run on Ubuntu now have a simplified toolset called 'Quickly' which makes it fun and easy by automating many of the mundane tasks involved in programming. Quickly also helps users 'package' the code and distribute it through the Ubuntu software repositories. Ubuntu developers will now find all code hosted in the Bazaar version control system, which is part of the fully open source Launchpad collaboration website. It's never been easier to develop on or for Ubuntu.
Netbook and smartbook users will be delighted by improvements to the Ubuntu 9.10 Netbook Remix (UNR) interface which continues to raise the bar in delivering the easiest, most discoverable and most useful user experience on small form machines. Common with Ubuntu 9.10 for desktops, UNR will integrate the Empathy instant messaging program for text, voice, video, and file transfers which will make communication more enjoyable then ever.
“Ubuntu 9.10 gives users more reasons than ever to seriously consider Linux at a time when many are thinking again about their operating system options. We are delivering a platform for users interested in an easy-to-use, great-looking, web-friendly operating system," says Jane Silber, COO at Canonical. “A faster, more beautiful boot and login sequence, file and contact synchronisation through online services and great experiences on the most popular notebook, desktop and netbook models continue to drive Ubuntu into the mainstream of computing choices."
More Ubuntu 9.10 Desktop Edition release highlights:
-
Faster, simplified, better-looking boot experience for most users
-
Audio revamp allowing improved sound control across multiple applications
-
Firefox 3.5: latest, fastest, most secure web browser yet from Mozilla
Useful links
-
Ubuntu Desktop Edition is entirely free of charge and can be downloaded from www.ubuntu.com as of Thursday 29 October
-
Ubuntu Netbook Remix is entirely free of charge and can be downloaded from www.ubuntu.com
-
Ubuntu One offers 2 GB storage for free, and 50 GB for $10 per month. See one.ubuntu.com
-
Canonical provides support products for desktop and notebook users priced from $55 per year. It can be purchased at www.ubuntu.com/support/services
-
The 100 Paper Cuts project can be found here (open ID required): https://launchpad.net/hundredpapercuts
-
The list of supported netbooks can be found here: https://wiki.ubuntu.com/HardwareSupport/Machines/Netbooks
-
The new feature tour with screen shots can be found at http://www.ubuntu.com/products/whatisubuntu/910features/
-
The list of supported languages in Ubuntu 9.10 can be found here: https://wiki.ubuntu.com/Translations/ReleaseLanguages/9.10
About Canonical
Canonical provides engineering, online and professional services to Ubuntu partners and customers worldwide. As the company behind the Ubuntu project, Canonical is committed to the production and support of Ubuntu – an ever-popular and fast-growing open-source operating system. It aims to ensure that Ubuntu is available to every organisation and individual on servers, desktops, laptops and netbooks.
Canonical partners with computer hardware manufacturers to certify Ubuntu, provides migration, deployment, support and training services to businesses, and offers online services direct to end users. Canonical also builds and maintains collaborative, open-source development tools to ensure that organisations and individuals can participate fully in innovations within the open-source community. For more information, please visit www.canonical.com.
Mandriva 2010 is out
http://wiki.mandriva.com/en/2010.0_Tour
download from - http://wiki.mandriva.com/en/Bittorrent
download from - http://wiki.mandriva.com/en/Bittorrent
IPTABLES
Introduction
A firewall is one of many components necessary to protect your computer. A “Firewall” is basically a system that is intended to be a gatekeeper that allows only traffic of a certain type to pass into the network. It is basically like a guard that checks everyone entering or leaving a building to make certain that they are allowed to pass his post.
There are a lot of types of firewalls as well; This article covers one in particular. “iptables” is a packet filter that has been part of the Linux kernel since version 2.4. It inspects every packet transferred to every network connection from that computer. Iptables replaced the older product known as “ipchains” and added the capability of doing “stateful inspection”. Stateful inspection means that the firewall is able to distinguish legitimate packets for different types of connections. Only packets matching a known connection state will be allowed by the firewall; others will be rejected.
Definitions
iptables follows a set of rules to decide how to handle each packet that tries to pass between the network and the linux system. Those rules basically dictate whether traffic will be allowed to pass or not. When writing rules for iptables there are a few terms and concepts you'll need to understand. The term “Target” basically asks “what action do I do with the packet when this rule is matched.” The most common are
ACCEPT
Allow the packet through the firewall.
DROP
Drops the packet; the packet is not allowed through the firewall and the sender of the packet is not notified.
QUEUE
Pass the packet to the userspace
RETURN
“stop traversing this chain and resume at the next rule in the previous chain
Rules are grouped into chains which in turn are contained in tables. There are three default tables which the packets may traverse; we are only concerned with one of these right now: the filter table. This is the default table and contains three chains:
OUTPUT
For packets generated by and leaving your computer; for example
when you connected to the Linux Gazette's web site your browser
created a packet and sent it out of your computer to the Gazette's
server.
INPUT
Any packets coming into your computer; for example the packets
containing the Gazette's web page sent back by its server to your
browser.
FORWARD
For packets being routed through your computer; for example
entering one network card and leaving through the other. We will
cover this in more detail later.
There are some different table definitions in different kernel versions however the main table types are:
raw
low level alteration of packets
nat
changes on packet headers (network address translation)
mangle
used to make specialized modifications to packets
filter
packet filtering
Packets can be inspected based on their state within a particular packet stream. Rules can be written to address various stateful conditions.
NEW
The packet is trying to start a new connection; for example when
you first connected to a website your browser attempts to create a new connection to the web server.
ESTABLISHED
A connection that has seen packets travel in both directions; once
the web server replies to your browser the connection is established.
RELATED
A packet that is starting a new connection but is related to an
existing connection. An example of this is downloading a file over
FTP. When you first connect to an FTP server you are creating a new
connection to its FTP port. However, when you download a file from
the FTP server using this connection a second new connection is
made between your computer and the FTP server for the file
download. Although it is a new connection it is related to the
first. This stateful packet filtering is useful as this new
connection does not use the same FTP port and simple port based rules
are not appropriate for this.
INVALID
This packet is associated with no known connection. These packets
should be dropped.
Creating Rules
Rules can be appended to the chains directly by using the iptables command. For example, to add a new rule to allow new connections to a web server running on your computer from anywhere we would execute the following:
$ iptables -A INPUT -s 0/0 -d 1.2.3.4 -m state --state NEW -p tcp --dport 80 -i eth0 -j ACCEPT
where:
-s (or --src or --source) and -d (or --dst or --destination)
is the source and destination specification of the packet. It is
usually an IP address with an optional mask.
0/0 is shorthand for 0.0.0.0/0.0.0.0 meaning that the source can be any IP address.
1.2.3.4 is the IP our your machine and is equivalent to writing 1.2.3.4/32
or 1.2.3.4/255.255.255.255 meaning the destination must be this and only
this IP. Other examples include:
1.2.3.0/24
Any IP in the range 1.2.3.0 to 1.2.3.255 (256 possible IPs). Could also
have been written as 1.2.3.0/255.255.255.0
1.2.0.0/16
Any IP in the range 1.2.0.0 to 1.2.255.255 (65536 possible IPs). Could
also have been written as 1.2.0.0/255.255.0.0
! 1.2.3.0/24
The exclamation mark inverts the match so this will result is a
match if the IP is anything except one in the given range 1.2.3.0
to 1.2.3.255.
-m state --state NEW
matches only packets that have a status of NEW. This can be anyone
of or a comma separated list of the four possible states.
-p tcp
apply this rule to packets using the TCP protocol only. This can be
anyone of tcp, udp, icmp or all (default). The exclamation mark can
be used to invert the match.
--dport 80 (or --destination-port)
matches a packet trying to connect to port 80. The exclamation mark
can be used to invert this match also. A range of ports can be
given in the format begin:end.
-i eth0 (or --in-interface eth0)
name of an interface via which a packet is going to be received.
Possible interfaces on your computer can be found using the command
'ifconfig'. In this example your computer is connected to
the Internet through the first (or only) ethernet card.
-j ACCEPT
the target. In this case, if the incoming packet is creating a new
TCP connection from anywhere to port 80 on your computer through
the first ethernet card, we will allow it through.
Note that these are examples using eth0 and an assumed ip address of 1.2.3.4; you would of course need to use the appropriate network interface name and ip address for your situation
the rules themselves are stored in a file named “iptables” that file may be in different locations depending on your distribution. On my RHEL server it is in /etc/sysconfig/iptables.
The essential elements of this file are:
(I have added the line numbers below for purposes of the comments below; in the actual iptables file there would not be line numbers)
1 # Firewall configuration
2 *filter
3 :INPUT [0:0]
4 :FORWARD [0:0]
5 :OUTPUT [0:0]
6
7 # your rules here
8
9 COMMIT
Line 2 of this file tells iptables that the following rules apply to the filter table. The next three lines (3-5) define the default targets for the three chains. We place our rules after these and before COMMIT, which does just that; commits our rules to the firewall.
Each packet traverses the rules of the appropriate chain from the first to the last. If a packet matches a rule then it stops traversing the chain at that rule and its fate is decided by that rule's target. If the packet does not match any rule then its fate is the default target of its chain.
I would recommend using the following skeleton configuration for all your firewalls:
1 *filter
2 :INPUT DROP [0:0]
3 :FORWARD DROP [0:0]
4 :OUTPUT ACCEPT [0:0]
5
6 # allow local loopback connections
7 -A INPUT -i lo -j ACCEPT
8
9 # drop INVALID connections
10 -A INPUT -m state --state INVALID -j DROP
11 -A OUTPUT -m state --state INVALID -j DROP
12 -A FORWARD -m state --state INVALID -j DROP
13
14 # allow all established and related
15 -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
16
17 # add anymore rules here
18
19 COMMIT
In lines 2-4 you will see that the default target for INPUT and FORWARD chains is set to DROP, while outgoing connections are set to accept. In most cases for home, personal or workstation use you want to start by denying anything from coming in from outside and establishing a new connection. On my systems I default to blocking everything and then add exceptions for specifically those things I want to allow. This does mean you have to determine what traffic each individual application requires but it is far more secure to default to the “allow by exception” rather than “block by exception” model. Now in this example I allow all outgoing connections from the computer which is my default for end user computers as their usage tends to be a lot more random but in server environments I lock down outbound packets as well and allow only those things that are specifically needed by the server.
In line 7 you will see a rule that tells iptables to allow all connections originating from the local loopback network interface. Many applications use the loopback address for communication to the local computer; In most cases you will find that you need to permit these connections.
Lines 10-12 drop all connections with a state of INVALID.
Line 15 should allows all incoming previously established or related connections through the firewall. For a connection to become established or related it must have already had a previous packet that went through the rules and passed with a state of NEW and been allowed though the firewall via a matching rule (If it had not been allowed through it would have been dropped by default and could not result in a established or related connection state).
Example 2 shows an example of a situation from a higher risk environment.
1 *filter
2 :INPUT DROP [0:0]
3 :FORWARD DROP [0:0]
4 :OUTPUT DROP [0:0]
5
6 # allow local loopback connections
7 -A INPUT -i lo -j ACCEPT
8
9 # drop INVALID connections
10 -A INPUT -m state --state INVALID -j DROP
11 -A OUTPUT -m state --state INVALID -j DROP
12 -A FORWARD -m state --state INVALID -j DROP
13
14 # allow all established and related
15 -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
16 -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
17
18 # allow connections to my ISP's DNS servers
19 -A OUTPUT -d 2.3.4.10 -m state --state NEW -p udp --dport 53 -o eth0 -j ACCEPT
20 -A OUTPUT -d 2.3.4.11 -m state --state NEW -p udp --dport 53 -o eth0 -j ACCEPT
21
22 # allow outgoing connections to web servers
23 -A OUTPUT -d 0/0 -m state --state NEW -p tcp --dport http -o eth0 -j ACCEPT
24 -A OUTPUT -m state --state NEW -p tcp --dport https -o eth0 -j ACCEPT
25
26 # allow outgoing mail connections to my ISP's SMTP and POP3 server only
27 -A OUTPUT -d 2.3.4.5 -m state --state NEW -p tcp --dport smtp -o eth0 -j ACCEPT
28 -A OUTPUT -d 2.3.4.5 -m state --state NEW -p tcp --dport pop3 -o eth0 -j ACCEPT
29
30 # log all other attempted out going connections
31 -A OUTPUT -o eth0 -j LOG
32 # default is to DROP out-going connections
33
34 COMMIT
This example defaults to the “Deny everything” principle and only allows those specific exceptions that we explicitly define rules for. Line 16 for instance adds a second rule very similar to the one in line 15 but it is on the OUTPUT chain instead. This is necessary as the default rule of the OUTPUT chain is DROP. Also note that when we specifying the interface for the OUTPUT chain rules we use -o (or --out-interface) as opposed to -i.
The first rules new rules we have added (lines 19 and 20) allow outbound connections to your ISP's DNS server; (This example assumes that your ISP uses '2.3.4.10' and '2.3.4.11' for the DNS servers. DNS lookups are usually done via the UDP protocol. Unless you are doing anything out of the ordinary this should be sufficient.
Lines 23 and 24 allow your browser to connect to any website using both the normal and the encrypted protocols. You'll notice that I have used http and https to specify the ports here instead of 80 and 443. This makes the rules more readable and you can substitute the service name for any port so long as it appears in the file /etc/services. You may also notice that in the second rule I did not mention the destination IP mask; this is equivalent to writing 'match any destination IP' (-d 0/0). In my real examples I normally include that for readability but in this example I left it off for instructional purposes.
Also I could have combined these two rules into a single line using :
-A OUTPUT -m state --state NEW -p tcp -m multiport --dport http,https -o eth0 -j ACCEPT
E-mail requires two services: SMTP (port 25) to send mail and POP3 (port 110) (or IMAP in some cases) to receive mail. Lines 27 and 28 show the rules to allow those services. Note that I use an assumed ip address for the mail server of 2.3.4.5 however most ISPs expect you to use the mail servers host name and they may have multiple hosts providing that mail so a better way to write that rules would be like this example below:
-A OUTPUT -d mail.isp.com -m state --state NEW -p tcp --dport smtp -o eth0 -j ACCEPT
-A OUTPUT -d mail.isp.com -m state --state NEW -p tcp --dport pop3 -o eth0 -j ACCEPT
line 31 shows a rule with “LOG” as the target. This results in any packet that has not matched a previous rule to get logged The log target does not terminate the processing of rules, it simply logs the packet and continues processing rules. As there are no further rules then the packet would end up 'dropped' since that is the default target. You can review the log with the dmesg command or via syslogd. There is also a called logwatch that is in some distro's but also available from sourceforge which will format these reports into an e-mail and send it to the root account.
If you use any other services, such as Jabber, IRC, file sharing clients, etc., you will have to add rules for these also. Just follow the above example. If you don't know what ports to open and you can't find it in /etc/services, then add a logging rule at the beginning of the rules, e.g.
-A OUTPUT -i eth0 -j LOG
and examine the output of the command dmesg (look for the destination port, DPT=???).
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=6bedb441-371f-4dc4-9308-335778d45647)
And a good video on the use of iptables
A firewall is one of many components necessary to protect your computer. A “Firewall” is basically a system that is intended to be a gatekeeper that allows only traffic of a certain type to pass into the network. It is basically like a guard that checks everyone entering or leaving a building to make certain that they are allowed to pass his post.
There are a lot of types of firewalls as well; This article covers one in particular. “iptables” is a packet filter that has been part of the Linux kernel since version 2.4. It inspects every packet transferred to every network connection from that computer. Iptables replaced the older product known as “ipchains” and added the capability of doing “stateful inspection”. Stateful inspection means that the firewall is able to distinguish legitimate packets for different types of connections. Only packets matching a known connection state will be allowed by the firewall; others will be rejected.
Definitions
iptables follows a set of rules to decide how to handle each packet that tries to pass between the network and the linux system. Those rules basically dictate whether traffic will be allowed to pass or not. When writing rules for iptables there are a few terms and concepts you'll need to understand. The term “Target” basically asks “what action do I do with the packet when this rule is matched.” The most common are
ACCEPT
Allow the packet through the firewall.
DROP
Drops the packet; the packet is not allowed through the firewall and the sender of the packet is not notified.
QUEUE
Pass the packet to the userspace
RETURN
“stop traversing this chain and resume at the next rule in the previous chain
Rules are grouped into chains which in turn are contained in tables. There are three default tables which the packets may traverse; we are only concerned with one of these right now: the filter table. This is the default table and contains three chains:
OUTPUT
For packets generated by and leaving your computer; for example
when you connected to the Linux Gazette's web site your browser
created a packet and sent it out of your computer to the Gazette's
server.
INPUT
Any packets coming into your computer; for example the packets
containing the Gazette's web page sent back by its server to your
browser.
FORWARD
For packets being routed through your computer; for example
entering one network card and leaving through the other. We will
cover this in more detail later.
There are some different table definitions in different kernel versions however the main table types are:
raw
low level alteration of packets
nat
changes on packet headers (network address translation)
mangle
used to make specialized modifications to packets
filter
packet filtering
Packets can be inspected based on their state within a particular packet stream. Rules can be written to address various stateful conditions.
NEW
The packet is trying to start a new connection; for example when
you first connected to a website your browser attempts to create a new connection to the web server.
ESTABLISHED
A connection that has seen packets travel in both directions; once
the web server replies to your browser the connection is established.
RELATED
A packet that is starting a new connection but is related to an
existing connection. An example of this is downloading a file over
FTP. When you first connect to an FTP server you are creating a new
connection to its FTP port. However, when you download a file from
the FTP server using this connection a second new connection is
made between your computer and the FTP server for the file
download. Although it is a new connection it is related to the
first. This stateful packet filtering is useful as this new
connection does not use the same FTP port and simple port based rules
are not appropriate for this.
INVALID
This packet is associated with no known connection. These packets
should be dropped.
Creating Rules
Rules can be appended to the chains directly by using the iptables command. For example, to add a new rule to allow new connections to a web server running on your computer from anywhere we would execute the following:
$ iptables -A INPUT -s 0/0 -d 1.2.3.4 -m state --state NEW -p tcp --dport 80 -i eth0 -j ACCEPT
where:
-s (or --src or --source) and -d (or --dst or --destination)
is the source and destination specification of the packet. It is
usually an IP address with an optional mask.
0/0 is shorthand for 0.0.0.0/0.0.0.0 meaning that the source can be any IP address.
1.2.3.4 is the IP our your machine and is equivalent to writing 1.2.3.4/32
or 1.2.3.4/255.255.255.255 meaning the destination must be this and only
this IP. Other examples include:
1.2.3.0/24
Any IP in the range 1.2.3.0 to 1.2.3.255 (256 possible IPs). Could also
have been written as 1.2.3.0/255.255.255.0
1.2.0.0/16
Any IP in the range 1.2.0.0 to 1.2.255.255 (65536 possible IPs). Could
also have been written as 1.2.0.0/255.255.0.0
! 1.2.3.0/24
The exclamation mark inverts the match so this will result is a
match if the IP is anything except one in the given range 1.2.3.0
to 1.2.3.255.
-m state --state NEW
matches only packets that have a status of NEW. This can be anyone
of or a comma separated list of the four possible states.
-p tcp
apply this rule to packets using the TCP protocol only. This can be
anyone of tcp, udp, icmp or all (default). The exclamation mark can
be used to invert the match.
--dport 80 (or --destination-port)
matches a packet trying to connect to port 80. The exclamation mark
can be used to invert this match also. A range of ports can be
given in the format begin:end.
-i eth0 (or --in-interface eth0)
name of an interface via which a packet is going to be received.
Possible interfaces on your computer can be found using the command
'ifconfig'. In this example your computer is connected to
the Internet through the first (or only) ethernet card.
-j ACCEPT
the target. In this case, if the incoming packet is creating a new
TCP connection from anywhere to port 80 on your computer through
the first ethernet card, we will allow it through.
Note that these are examples using eth0 and an assumed ip address of 1.2.3.4; you would of course need to use the appropriate network interface name and ip address for your situation
the rules themselves are stored in a file named “iptables” that file may be in different locations depending on your distribution. On my RHEL server it is in /etc/sysconfig/iptables.
The essential elements of this file are:
(I have added the line numbers below for purposes of the comments below; in the actual iptables file there would not be line numbers)
1 # Firewall configuration
2 *filter
3 :INPUT
4 :FORWARD
5 :OUTPUT
6
7 # your rules here
8
9 COMMIT
Line 2 of this file tells iptables that the following rules apply to the filter table. The next three lines (3-5) define the default targets for the three chains. We place our rules after these and before COMMIT, which does just that; commits our rules to the firewall.
Each packet traverses the rules of the appropriate chain from the first to the last. If a packet matches a rule then it stops traversing the chain at that rule and its fate is decided by that rule's target. If the packet does not match any rule then its fate is the default target of its chain.
I would recommend using the following skeleton configuration for all your firewalls:
1 *filter
2 :INPUT DROP [0:0]
3 :FORWARD DROP [0:0]
4 :OUTPUT ACCEPT [0:0]
5
6 # allow local loopback connections
7 -A INPUT -i lo -j ACCEPT
8
9 # drop INVALID connections
10 -A INPUT -m state --state INVALID -j DROP
11 -A OUTPUT -m state --state INVALID -j DROP
12 -A FORWARD -m state --state INVALID -j DROP
13
14 # allow all established and related
15 -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
16
17 # add anymore rules here
18
19 COMMIT
In lines 2-4 you will see that the default target for INPUT and FORWARD chains is set to DROP, while outgoing connections are set to accept. In most cases for home, personal or workstation use you want to start by denying anything from coming in from outside and establishing a new connection. On my systems I default to blocking everything and then add exceptions for specifically those things I want to allow. This does mean you have to determine what traffic each individual application requires but it is far more secure to default to the “allow by exception” rather than “block by exception” model. Now in this example I allow all outgoing connections from the computer which is my default for end user computers as their usage tends to be a lot more random but in server environments I lock down outbound packets as well and allow only those things that are specifically needed by the server.
In line 7 you will see a rule that tells iptables to allow all connections originating from the local loopback network interface. Many applications use the loopback address for communication to the local computer; In most cases you will find that you need to permit these connections.
Lines 10-12 drop all connections with a state of INVALID.
Line 15 should allows all incoming previously established or related connections through the firewall. For a connection to become established or related it must have already had a previous packet that went through the rules and passed with a state of NEW and been allowed though the firewall via a matching rule (If it had not been allowed through it would have been dropped by default and could not result in a established or related connection state).
Example 2 shows an example of a situation from a higher risk environment.
1 *filter
2 :INPUT DROP [0:0]
3 :FORWARD DROP [0:0]
4 :OUTPUT DROP [0:0]
5
6 # allow local loopback connections
7 -A INPUT -i lo -j ACCEPT
8
9 # drop INVALID connections
10 -A INPUT -m state --state INVALID -j DROP
11 -A OUTPUT -m state --state INVALID -j DROP
12 -A FORWARD -m state --state INVALID -j DROP
13
14 # allow all established and related
15 -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
16 -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
17
18 # allow connections to my ISP's DNS servers
19 -A OUTPUT -d 2.3.4.10 -m state --state NEW -p udp --dport 53 -o eth0 -j ACCEPT
20 -A OUTPUT -d 2.3.4.11 -m state --state NEW -p udp --dport 53 -o eth0 -j ACCEPT
21
22 # allow outgoing connections to web servers
23 -A OUTPUT -d 0/0 -m state --state NEW -p tcp --dport http -o eth0 -j ACCEPT
24 -A OUTPUT -m state --state NEW -p tcp --dport https -o eth0 -j ACCEPT
25
26 # allow outgoing mail connections to my ISP's SMTP and POP3 server only
27 -A OUTPUT -d 2.3.4.5 -m state --state NEW -p tcp --dport smtp -o eth0 -j ACCEPT
28 -A OUTPUT -d 2.3.4.5 -m state --state NEW -p tcp --dport pop3 -o eth0 -j ACCEPT
29
30 # log all other attempted out going connections
31 -A OUTPUT -o eth0 -j LOG
32 # default is to DROP out-going connections
33
34 COMMIT
This example defaults to the “Deny everything” principle and only allows those specific exceptions that we explicitly define rules for. Line 16 for instance adds a second rule very similar to the one in line 15 but it is on the OUTPUT chain instead. This is necessary as the default rule of the OUTPUT chain is DROP. Also note that when we specifying the interface for the OUTPUT chain rules we use -o (or --out-interface) as opposed to -i.
The first rules new rules we have added (lines 19 and 20) allow outbound connections to your ISP's DNS server; (This example assumes that your ISP uses '2.3.4.10' and '2.3.4.11' for the DNS servers. DNS lookups are usually done via the UDP protocol. Unless you are doing anything out of the ordinary this should be sufficient.
Lines 23 and 24 allow your browser to connect to any website using both the normal and the encrypted protocols. You'll notice that I have used http and https to specify the ports here instead of 80 and 443. This makes the rules more readable and you can substitute the service name for any port so long as it appears in the file /etc/services. You may also notice that in the second rule I did not mention the destination IP mask; this is equivalent to writing 'match any destination IP' (-d 0/0). In my real examples I normally include that for readability but in this example I left it off for instructional purposes.
Also I could have combined these two rules into a single line using :
-A OUTPUT -m state --state NEW -p tcp -m multiport --dport http,https -o eth0 -j ACCEPT
E-mail requires two services: SMTP (port 25) to send mail and POP3 (port 110) (or IMAP in some cases) to receive mail. Lines 27 and 28 show the rules to allow those services. Note that I use an assumed ip address for the mail server of 2.3.4.5 however most ISPs expect you to use the mail servers host name and they may have multiple hosts providing that mail so a better way to write that rules would be like this example below:
-A OUTPUT -d mail.isp.com -m state --state NEW -p tcp --dport smtp -o eth0 -j ACCEPT
-A OUTPUT -d mail.isp.com -m state --state NEW -p tcp --dport pop3 -o eth0 -j ACCEPT
line 31 shows a rule with “LOG” as the target. This results in any packet that has not matched a previous rule to get logged The log target does not terminate the processing of rules, it simply logs the packet and continues processing rules. As there are no further rules then the packet would end up 'dropped' since that is the default target. You can review the log with the dmesg command or via syslogd. There is also a called logwatch that is in some distro's but also available from sourceforge which will format these reports into an e-mail and send it to the root account.
If you use any other services, such as Jabber, IRC, file sharing clients, etc., you will have to add rules for these also. Just follow the above example. If you don't know what ports to open and you can't find it in /etc/services, then add a logging rule at the beginning of the rules, e.g.
-A OUTPUT -i eth0 -j LOG
and examine the output of the command dmesg (look for the destination port, DPT=???).
And a good video on the use of iptables
I've been involved in various capacities in the field of Data Security since 1985; The past 10 years as a field engineer for a Major Software Manufacturer. I began working with Unix and later Linux in 1994.
I started this blog with the intent of focusing on Security with the Linux Framework however as I do security and messaging work in other environments I will most certainly stray off topic a bit.
Bear with me as I develop the site. I have so many things to write about. Suggestions and constructive feedback are always welcome. One important lesson in security work is that you have to always consider new ways that the enemy can attack. Some are clever but most rely on well known tools and exploit well known vulnerabilities so my first efforts here will focus on the basics of securing and hardening your systems against known security threats.
I'll never be able to cover 'everything' myself so anyone wishing to submit relevant content for this blog; links to relevant sites or anything of widespread interest to those interested in Linux Security feel free to contact kbastin@mindspring.com
I started this blog with the intent of focusing on Security with the Linux Framework however as I do security and messaging work in other environments I will most certainly stray off topic a bit.
Bear with me as I develop the site. I have so many things to write about. Suggestions and constructive feedback are always welcome. One important lesson in security work is that you have to always consider new ways that the enemy can attack. Some are clever but most rely on well known tools and exploit well known vulnerabilities so my first efforts here will focus on the basics of securing and hardening your systems against known security threats.
I'll never be able to cover 'everything' myself so anyone wishing to submit relevant content for this blog; links to relevant sites or anything of widespread interest to those interested in Linux Security feel free to contact kbastin@mindspring.com
Subscribe to:
Posts (Atom)