Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Securing Your Linux Servers

Thomas Cameron, RHCE, RHCI, CNE, MCSE, MCT
Lead Solutions Architect, Central Region
Red Hat
[email protected]
http://people.redhat.com/tcameron

Thomas Cameron: Securing Your Linux Servers

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Outline

Introduction

Vectors of attack
External – network services
Internal – trusted and non-trusted users

Installation time – trim your package list

Pre-production – port scan, process scan &
harden your server
Firewalls (iptables)
tcp_wrappers

Thomas Cameron: Securing Your Linux Servers Slide 2

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Outline
xinetd
Security Enhanced Linux (SELinux)

Production
Periodically port scan and check for unknown
processes against baseline

Thomas Cameron: Securing Your Linux Servers Slide 3

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Introduction

Welcome!

Today we will only be talking about hardening a
single Linux host – 90 minutes is not enough
time to go too terribly deep into security

For security training, consider courses like:
 RHS333, Red Hat Enterprise Security: Network
Services
 RHS429, Red Hat Enterprise SELinux Policy
Administration

For additional security information, see
https://www.redhat.com/security/updates/

Thomas Cameron: Securing Your Linux Servers Slide 4

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Vectors of Attack

External
Most commonly considered attack vector.
Includes buffer overflows, dictionary/brute
force attacks, malformed URLs and the like

Internal
Attacks from within areas considered to be
secure. More and more sensitive data is lost
to internal attacks than external. Can be
trusted staff who abuse privileges or non-
trusted staff who exploit weaknesses of interal
networks. Also consider social engineering -
combination internal/external.

Thomas Cameron: Securing Your Linux Servers Slide 5

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Installation Time

Install only the minimum necessary software to
do the job for which the system is designed.
 A web server probably doesn't need gcc and friends
installed.

You can get a good handle on what software
groups to install by looking at the various
comps*.xml files
 egrep "<name>|packagereq" /path/to/comps.xml

Note that each channel will have its own comps
file
 Server, Cluster, ClusterStorage, VT

Thomas Cameron: Securing Your Linux Servers Slide 6

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Installation Time

Once you've determined the package list,
generate a kickstart file.
Automated installs increase security by
decreasing variance.
Automated installs decrease recovery time if
compromised. If you know exactly how all
your systems are configured, you know exactly
what to fix on all of them.

Thomas Cameron: Securing Your Linux Servers Slide 7

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Installation Time

You can define the following in %packages:
Individual packages (package)
Package groups (@Group Name)
Packages to skip (-package)

Thomas Cameron: Securing Your Linux Servers Slide 8

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Installation Time

Use %post to:
Turn off unnecessary services (better you
should not install any)
Fix settings like ipv6 or authentication
Add any user accounts (use /sbin/grub-md5-
crypt to generate passwords)
Run any shell code needed to tighten things up
Install any packages outside the Red Hat
install tree

Thomas Cameron: Securing Your Linux Servers Slide 9

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Installation Time
install
url --url http://ml110.redhat.com/ty/gWwGX8y4
key 014fce2d4495830d
lang en_US.UTF-8
keyboard us
skipx
network --device eth0 --bootproto dhcp
rootpw --iscrypted $1$agkorjqJ$KeeFnItYAS.l.uUcjxrxR1
firewall --disabled
authconfig --enablemd5 --enableshadow
selinux --disabled
timezone America/Chicago
bootloader --location=mbr --driveorder=sda --append="rhgb quiet"
clearpart --all
part /boot --fstype ext3 --size=100
part swap --size=1024
part / --fstype ext3 --size=1000 --grow

%packages
@base
@Web Server
-tux

%post
/sbin/chkconfig foo off
/bin/rpm -Uvh http://ml110.redhat.com/pub/packages/mypackage-1.0-1.i386.rpm
/bin/echo install ipv6 /bin/true > /etc/modprobe.conf
/usr/sbin/groupadd admins
/usr/sbin/useradd -G admins -p '$1$uWyP9$RRM.DRsYpNcAUF6/KD/WV/' -c “Thomas Cameron” tcameron

Thomas Cameron: Securing Your Linux Servers Slide 10

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Pre-production

Before your system goes into production:
port scan
process scan
harden your server

Thomas Cameron: Securing Your Linux Servers Slide 11

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Pre-production

Port scan your server
nmap, nmapfe
Scan the host from another machine or
machines

Thomas Cameron: Securing Your Linux Servers Slide 12

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Pre-production

nmap, nmapfe
Command line or GUI driven tools to do
portscans
Don't portscan servers unless you know it is
OK to do so!
• Your systems
• You have documented permission to scan them

Thomas Cameron: Securing Your Linux Servers Slide 13

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Thomas Cameron: Securing Your Linux Servers Slide 14

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Pre-production

Determine which services are supposed to
be listening and make sure that those ports
are open. If anything else is open,
determine the service which is running and
remove it.
lsof -i :[port] can help you determine which
service is listening on what port

Record what is listening – capture a
baseline reading

Thomas Cameron: Securing Your Linux Servers Slide 15

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Thomas Cameron: Securing Your Linux Servers Slide 16

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Pre-production

Process Scanning
Do a process scan to see what is running and
who is running it.
• ps -aux
• ps -ef

Thomas Cameron: Securing Your Linux Servers Slide 17

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 2036 600 ? Ss 13:44 0:02 init [3]
root 2 0.0 0.0 0 0 ? S 13:44 0:00 [migration/0]
root 3 0.0 0.0 0 0 ? SN 13:44 0:00 [ksoftirqd/0]
root 4 0.0 0.0 0 0 ? S 13:44 0:00 [watchdog/0]
root 5 0.0 0.0 0 0 ? S< 13:44 0:00 [events/0]
root 6 0.0 0.0 0 0 ? S< 13:44 0:00 [khelper]
root 7 0.0 0.0 0 0 ? S< 13:44 0:00 [kthread]
root 10 0.0 0.0 0 0 ? S< 13:44 0:00 \_ [kblockd/0]
root 11 0.0 0.0 0 0 ? S< 13:44 0:00 \_ [kacpid]
root 67 0.0 0.0 0 0 ? S< 13:44 0:00 \_ [cqueue/0]
root 70 0.0 0.0 0 0 ? S< 13:44 0:00 \_ [khubd]
root 72 0.0 0.0 0 0 ? S< 13:44 0:00 \_ [kseriod]
root 135 0.0 0.0 0 0 ? S 13:44 0:00 \_ [pdflush]
root 136 0.0 0.0 0 0 ? S 13:44 0:00 \_ [pdflush]
root 137 0.0 0.0 0 0 ? S< 13:44 0:00 \_ [kswapd0]
root 138 0.0 0.0 0 0 ? S< 13:44 0:00 \_ [aio/0]
root 290 0.0 0.0 0 0 ? S< 13:44 0:00 \_ [kpsmoused]
root 321 0.0 0.0 0 0 ? S< 13:44 0:00 \_ [scsi_eh_0]
root 322 0.0 0.0 0 0 ? S< 13:44 0:03 \_ [kjournald]
root 355 0.0 0.0 0 0 ? S< 13:44 0:00 \_ [kauditd]
root 1005 0.0 0.0 0 0 ? S< 13:44 0:00 \_ [kmirrord]
root 1026 0.0 0.0 0 0 ? S< 13:44 0:00 \_ [kjournald]
root 389 0.0 0.3 2912 1400 ? S<s 13:44 0:01 /sbin/udevd -d
root 1615 0.0 0.1 2276 696 ? Ss 13:45 0:00 /sbin/dhclient -1 -q -cf /etc/dhclient-eth0.conf -lf /var/lib/dhclient/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid eth0
root 1717 0.0 2.0 9668 8076 ? Ss 13:45 0:00 /usr/sbin/restorecond
root 1734 0.0 0.1 12048 636 ? S<sl 13:45 0:00 auditd
root 1736 0.0 0.9 9612 3852 ? S<s 13:45 0:00 \_ python /sbin/audispd
root 1755 0.0 0.1 1692 588 ? Ss 13:45 0:00 syslogd -m 0
root 1758 0.0 0.1 1644 400 ? Ss 13:45 0:00 klogd -x
root 1795 0.0 0.1 2128 512 ? Ss 13:45 0:02 mcstransd
rpc 1818 0.0 0.1 1772 544 ? Ss 13:45 0:00 portmap
root 1836 0.0 2.4 40764 9588 ? Ssl 13:45 0:07 /usr/bin/python -E /usr/sbin/setroubleshootd
root 1862 0.0 0.1 1788 720 ? Ss 13:45 0:00 rpc.statd
root 1907 0.0 0.1 4932 556 ? Ss 13:45 0:00 rpc.idmapd
dbus 1936 0.0 0.2 12952 1072 ? Ssl 13:45 0:00 dbus-daemon --system
root 1953 0.0 0.1 2120 744 ? Ss 13:45 0:00 /usr/sbin/hcid
root 1965 0.0 0.1 1712 504 ? Ss 13:45 0:00 /usr/sbin/sdpd
root 1978 0.0 0.0 0 0 ? S< 13:45 0:00 [krfcommd]
root 2026 0.0 0.3 12688 1296 ? Ssl 13:45 0:00 pcscd
root 2051 0.0 0.1 1876 448 ? Ss 13:45 0:00 /usr/bin/hidd --server
root 2071 0.0 0.2 9328 1104 ? Ssl 13:45 0:01 automount
root 2095 0.0 0.1 1640 536 ? Ss 13:45 0:00 /usr/sbin/acpid
root 2111 0.0 0.1 5036 740 ? Ss 13:45 0:00 ./hpiod
root 2116 0.0 1.2 12720 4668 ? S 13:45 0:01 python ./hpssd.py
root 2133 0.0 0.5 9580 1960 ? Ss 13:45 0:00 cupsd
root 2152 0.0 0.2 5176 948 ? Ss 13:45 0:00 /usr/sbin/sshd
root 11756 0.1 0.6 8268 2608 ? Ss 16:58 0:03 \_ sshd: root@pts/0
root 11759 0.0 0.3 4488 1396 pts/0 Ss 16:58 0:01 \_ -bash
root 12096 0.0 0.2 4184 884 pts/0 R+ 17:42 0:00 \_ ps axufww
root 2178 0.0 0.4 8500 1812 ? Ss 13:45 0:02 sendmail: accepting connections
smmsp 2187 0.0 0.3 7540 1444 ? Ss 13:45 0:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
root 2204 0.0 0.1 1864 468 ? Ss 13:45 0:00 gpm -m /dev/input/mice -t exps2
root 2220 0.0 0.3 5220 1176 ? Ss 13:45 0:00 crond
xfs 2258 0.0 0.4 3776 1596 ? Ss 13:45 0:00 xfs -droppriv -daemon
root 2289 0.0 0.1 2204 428 ? Ss 13:45 0:00 /usr/sbin/atd
root 2313 0.0 3.1 25224 12112 ? S 13:45 0:11 /usr/bin/python /usr/sbin/yum-updatesd
avahi 2330 0.0 0.3 2532 1368 ? Ss 13:45 0:00 avahi-daemon: running [vm1.local]
avahi 2331 0.0 0.1 2532 424 ? Ss 13:45 0:00 \_ avahi-daemon: chroot helper
68 2347 0.0 0.9 5360 3544 ? Ss 13:45 0:04 hald
root 2348 0.0 0.2 3100 1080 ? S 13:45 0:00 \_ hald-runner
68 2354 0.0 0.2 1964 816 ? S 13:45 0:00 \_ hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
68 2359 0.0 0.2 1968 808 ? S 13:45 0:00 \_ hald-addon-keyboard: listening on /dev/input/event0
root 2371 0.2 0.1 1924 656 ? S 13:45 0:39 \_ hald-addon-storage: polling /dev/hdc
root 2414 0.0 0.0 1904 344 ? S 13:45 0:00 /usr/sbin/smartd -q never
root 2418 0.0 0.1 1628 460 tty1 Ss+ 13:45 0:00 /sbin/mingetty tty1
root 2419 0.0 0.1 1624 460 tty2 Ss+ 13:45 0:00 /sbin/mingetty tty2
root 2422 0.0 0.1 1628 460 tty3 Ss+ 13:45 0:00 /sbin/mingetty tty3
root 2425 0.0 0.1 1628 464 tty4 Ss+ 13:45 0:00 /sbin/mingetty tty4
root 2426 0.0 0.1 1628 460 tty5 Ss+ 13:45 0:00 /sbin/mingetty tty5
root 2448 0.0 0.1 1628 464 tty6 Ss+ 13:45 0:00 /sbin/mingetty tty6
Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Pre-production

In the previous output, does it make sense
to have hpiod running on, say, a web
server?

Thomas Cameron: Securing Your Linux Servers Slide 19

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Thomas Cameron: Securing Your Linux Servers Slide 20

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Pre-production

Probably not. Remove it or at least disable
it.
/sbin/chkconfig hplip off
/sbin/service hplip stop
yum remove hplip

Note that hplip is not necessarily a
dangerous service to have running. It's
just that it is not needed, and as such,
should be removed.

Thomas Cameron: Securing Your Linux Servers Slide 21

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Pre-production

As with external ports, create a baseline of
known acceptable running processes

Don't rely on your memory. Document
listening ports and running processes.
Easy for you to reference months or years later
Easy for other staff to reference should you not
be available

Thomas Cameron: Securing Your Linux Servers Slide 22

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Pre-production

Harden Your Systems
iptables
xinetd
pluggable authentication modules (PAM)
Security Enhanced Linux (SELinux)
Application Specific
• sendmail
• NFS

Thomas Cameron: Securing Your Linux Servers Slide 23

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Harden Your Systems

iptables
kernel-level stateful packet filter
Can be incredibly granular or very broad
/usr/bin/system-config-securitylevel great for
basic host-based firewalls
/sbin/iptables, /sbin/iptables-save, and
/sbin/service iptables
{start|stop|restart|condrestart|status|panic|sa
ve} for more advanced configurations

Thomas Cameron: Securing Your Linux Servers Slide 24

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Harden Your Systems

/usr/bin/system-config-securitylevel

Thomas Cameron: Securing Your Linux Servers Slide 25

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Harden Your Systems

/sbin/iptables

Thomas Cameron: Securing Your Linux Servers Slide 26

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

iptables (netfilter)

Kernel-based traffic filter/firewall toolkit

Traffic is managed through rules, called
“chains:”
INPUT
FORWARD
OUTPUT

Those packets can be sent to a target,
including
ACCEPT
DROP
REJECT
Thomas Cameron: Securing Your Linux Servers Slide 27
Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

iptables (netfilter)

Additionally, packets can be modified using
Network Address Translation
-t nat
• DNAT (PREROUTING)
• SNAT (POSTROUTING)
• MASQUERADE (POSTROUTING)

Thomas Cameron: Securing Your Linux Servers Slide 28

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

iptables (netfilter)

Some benefits of iptables:
Works at layers 2 and 3 – the application is
never even aware that the traffic has hit the
box. Lessens the chance of a buffer overflow
or other malformed traffic attack.
Very low performance impact

Thomas Cameron: Securing Your Linux Servers Slide 29

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

iptables examples

First allow traffic to and from localhost:
iptables -A INPUT -i lo -j ACCEPT

Next allow icmp (ping and friends):
iptables -A INPUT -p icmp -j ACCEPT

To allow ssh from
station101.example.com:
iptables -A INPUT -s station101 -p tcp \
--dport 22 -j ACCEPT

Thomas Cameron: Securing Your Linux Servers Slide 30

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

iptables examples

To allow traffic from the world to the web
server:
iptables -A INPUT -p tcp --dport http -j ACCEPT
iptables -A INPUT -p tcp --dport https -j ACCEPT

To allow all traffic from a trusted subnet:
iptables
-I INPUT -s 192.168.1.0/24 -j ACCEPT

Now log any other traffic:
iptables -A INPUT -m state --state NEW -j LOG \
--log-prefix="Blocked Traffic "

Thomas Cameron: Securing Your Linux Servers Slide 31

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

iptables examples

Finally, block any other traffic:
iptables -A INPUT -m state --state NEW -j DROP

Thomas Cameron: Securing Your Linux Servers Slide 32

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

iptables examples

Note that REJECT sends back an icmp port
unreachable message, where DROP silently
discards (and slows down the attacker)

Thomas Cameron: Securing Your Linux Servers Slide 33

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

iptables examples

Don't forget to make your changes permanent!

Thomas Cameron: Securing Your Linux Servers Slide 34

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

tcp_wrappers

Applications can be compiled against
libwrap

That application is going to check
connections against /etc/hosts.allow first
and then and /etc/hosts.deny
If a connection is allowed in hosts.allow then
the connection will succeed. BE AWARE OF
THIS!!!

These files are configured in this format:
<daemon list>: <client list> [: <option>: <option>: ...]

Thomas Cameron: Securing Your Linux Servers Slide 35

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

tcp_wrappers

Where daemon is something like
vsftpd
sshd
in.telnetd

And client list is something like:
192.168.1. or 192.168.1.0/24
ALL
*.cracker.lan

Thomas Cameron: Securing Your Linux Servers Slide 36

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

tcp_wrappers

And option is something like:
allow
deny
twist
spawn
except

options can be added
sshd: 192.168.2. : spawn /usr/bin/logger
“Access denied on $(/bin/date)”: deny
vsftpd : .example.com : twist /bin/echo "421
This domain has been black-listed. Access
denied!"
Thomas Cameron: Securing Your Linux Servers Slide 37
Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

tcp_wrappers

Example of hosts.deny with a spawn
directive to log:

Thomas Cameron: Securing Your Linux Servers Slide 38

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

tcp_wrappers

Example of hosts.deny with a twist:

Thomas Cameron: Securing Your Linux Servers Slide 39

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

xinetd

xinetd is the internet “super-server,” a
replacement for the old inetd service.
A single service which listens on several ports.
When a connection is made to a port, xinetd
decides what service to start in response to
that connection
Rules are stored in /etc/xinetd.d/[service]

Thomas Cameron: Securing Your Linux Servers Slide 40

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

xinetd

Some security features for the service files
only_from = 192.168.0.0/24
no_access = 192.168.1.10
access_times = 09:00-18:00

Thomas Cameron: Securing Your Linux Servers Slide 41

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

xinetd

Logging options:
 ATTEMPT — Logs the fact that a failed attempt was
made (log_on_failure).
 DURATION — Logs the length of time the service is
used by a remote system (log_on_success).
 EXIT — Logs the exit status or termination signal of
the service (log_on_success).
 HOST — Logs the remote host's IP address
(log_on_failure and log_on_success).
 PID — Logs the process ID of the server receiving the
request (log_on_success).
 USERID — Logs the remote user using the method
defined in RFC 1413 for all multi-threaded stream
services (log_on_failure and log_on_success).

Thomas Cameron: Securing Your Linux Servers Slide 42

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

xinetd

Example configuration file for the kerberos-
enabled telnet service, /etc/xinetd.d/krb5-telnet:

service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/kerberos/sbin/telnetd
log_on_failure += USERID
disable = yes
}

Thomas Cameron: Securing Your Linux Servers Slide 43

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

xinetd

Using the SENSOR attribute with xinetd-
managed services
SENSOR is a sort of “honeypot” tool
• Once an unauthorized system attempts to connect,
xinetd locks the entire system down for that system

Thomas Cameron: Securing Your Linux Servers Slide 44

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

xinetd

Using SENSOR:

service telnet
{
flags = SENSOR
deny_time = 1
socket_type = stream
wait = no
user = root
server = /usr/kerberos/sbin/telnetd
log_on_failure += USERID
disable = no
}

Thomas Cameron: Securing Your Linux Servers Slide 45

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

xinetd

Using SENSOR:
Sep 25 01:13:50 station100 xinetd[2437]: START: login pid=2442
from=192.168.1.101
Sep 25 01:13:54 station100 xinetd[2437]: EXIT: login status=0
pid=2442 duration=4(sec)
Sep 25 01:13:58 station100 xinetd[2437]: 2437 {process_sensor}
Adding 192.168.1.101 to the global_no_access list for 1 minutes
Sep 25 01:13:58 station100 xinetd[2437]: FAIL: telnet address
from=192.168.1.101
Sep 25 01:14:02 station100 xinetd[2471]: FAIL: login address
from=192.168.1.101

Sep 25 01:14:58 station100 xinetd[2437]: At least 1 DENY_TIME has

expired, global_no_access list updated
Sep 25 01:14:58 station100 xinetd[2437]: global_no_access list is
empty.

Thomas Cameron: Securing Your Linux Servers Slide 46

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

xinetd

Another important feature of xinetd is its ability
to control the amount of resources which services
under its control can utilize.

It does this by way of the following directives:
 cps = <number_of_connections> <wait_period> —
Dictates the connections allowed to the service per
second. This directive accepts only integer values.
 instances = <number_of_connections> — Dictates the
total number of connections allowed to a service. This
directive accepts either an integer value or
UNLIMITED.

Thomas Cameron: Securing Your Linux Servers Slide 47

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

xinetd

It does this by way of the following
directives (Continued):
per_source = <number_of_connections> —
Dictates the connections allowed to a service
by each host. This directive accepts either an
integer value or UNLIMITED.
rlimit_as = <number[K|M]> — Dictates the
amount of memory address space the service
can occupy in kilobytes or megabytes. This
directive accepts either an integer value or
UNLIMITED.

Thomas Cameron: Securing Your Linux Servers Slide 48

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

xinetd

It does this by way of the following
directives (Continued):
rlimit_cpu = <number_of_seconds> —
Dictates the amount of time in seconds that a
service may occupy the CPU. This directive
accepts either an integer value or UNLIMITED.

Thomas Cameron: Securing Your Linux Servers Slide 49

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

Security-Enhanced Linux (SELinux) is a
security architecture integrated into the
2.6.x kernel using the Linux Security
Modules (LSM). It is a project of the United
States National Security Agency (NSA) and
the SELinux community. SELinux
integration into Red Hat Enterprise Linux
was a joint effort between the NSA and
Red Hat.

Thomas Cameron: Securing Your Linux Servers Slide 50

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

SELinux provides a flexible Mandatory
Access Control (MAC) system built into the
Linux kernel. Under standard Linux
Discretionary Access Control (DAC), an
application or process running as a user
(UID or SUID) has the user's permissions
to objects such as files, sockets, and other
processes. Running a MAC kernel protects
the system from malicious or flawed
applications that can damage or destroy
the system.
Thomas Cameron: Securing Your Linux Servers Slide 51
Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

Refer to the following diagram:

Thomas Cameron: Securing Your Linux Servers Slide 54

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

SELinux Operating Modes
Instead of running in enforcing mode, SELinux
can run in permissive mode, where the AVC is
checked and denials are logged, but SELinux
does not enforce the policy. This can be useful
for troubleshooting and for developing or fine-
tuning SELinux policy.

Thomas Cameron: Securing Your Linux Servers Slide 55

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

Files Related to SELinux
The /selinux/ pseudo-file system contains
commands that are most commonly used by
the kernel subsystem. This type of file system
is similar to the /proc/ pseudo-file system.
Administrators and users do not normally need
to manipulate this component.

Thomas Cameron: Securing Your Linux Servers Slide 56

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

Files Related to SELinux (cont'd)
 The following example shows sample contents of the
/selinux/ directory:
-rw-rw-rw- 1 root root 0 Sep 22 13:14 access
dr-xr-xr-x 1 root root 0 Sep 22 13:14 booleans
--w------- 1 root root 0 Sep 22 13:14 commit_pending_bools
-rw-rw-rw- 1 root root 0 Sep 22 13:14 context
-rw-rw-rw- 1 root root 0 Sep 22 13:14 create
--w------- 1 root root 0 Sep 22 13:14 disable
-rw-r--r-- 1 root root 0 Sep 22 13:14 enforce
-rw------- 1 root root 0 Sep 22 13:14 load
-r--r--r-- 1 root root 0 Sep 22 13:14 mls
-r--r--r-- 1 root root 0 Sep 22 13:14 policyvers
-rw-rw-rw- 1 root root 0 Sep 22 13:14 relabel
-rw-rw-rw- 1 root root 0 Sep 22 13:14 user

 For example, running the cat command on the enforce

file reveals either a 1 for enforcing mode or 0 for
permissive mode.
Thomas Cameron: Securing Your Linux Servers Slide 57
Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

SELinux Configuration Files
The following sections describe SELinux
configuration and policy files, and related file
systems located in the /etc/ directory.

Thomas Cameron: Securing Your Linux Servers Slide 58

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

SELinux Configuration Files
The /etc/sysconfig/selinux Configuration File
• There are two ways to configure SELinux under Red
Hat Enterprise Linux: using the Security Level
Configuration Tool (system-config-selinux), or
manually editing the configuration file
(/etc/sysconfig/selinux).

Thomas Cameron: Securing Your Linux Servers Slide 59

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

SELinux Configuration Files
The /etc/sysconfig/selinux file is the primary
configuration file for enabling or disabling
SELinux, as well as for setting which policy to
enforce on the system and how to enforce it.
Note:
• The /etc/sysconfig/selinux is a symbolic link to the
actual configuration file, /etc/selinux/config.

Thomas Cameron: Securing Your Linux Servers Slide 60

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

SELinux Configuration Files
 The following explains the full subset of
options available for configuration:
SELINUX=enforcing|permissive|disabled —
Defines the top-level state of SELinux on a
system.
• enforcing — The SELinux security policy is enforced.

Thomas Cameron: Securing Your Linux Servers Slide 61

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)
 SELinux Configuration Files
• permissive — The SELinux system prints warnings
but does not enforce policy.

This is useful for debugging and troubleshooting purposes.
In permissive mode, more denials are logged because
subjects can continue with actions that would otherwise be
denied in enforcing mode. For example, traversing a
directory tree in permissive mode produces avc: denied
messages for every directory level read. In enforcing
mode, SELinux would have stopped the initial traversal
and kept further denial messages from occurring.

Thomas Cameron: Securing Your Linux Servers Slide 62

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

SELinux Configuration Files
• disabled — SELinux is fully disabled. SELinux hooks
are disengaged from the kernel and the pseudo-file
system is unregistered.

Thomas Cameron: Securing Your Linux Servers Slide 63

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

Tip
 Actions made while SELinux is disabled may result in the file
system no longer having the correct security context. That is, the
security context defined by the policy. The best way to relabel the
file system is to create the flag file /.autorelabel and reboot the
machine. This causes the relabel to occur very early in the boot
process, before any processes are running on the system. Using
this procedure means that processes can not accidentally create
files in the wrong context or start up in the wrong context. It is
possible to use the fixfiles relabel command prior to enabling
SELinux to relabel the file system. This method is not
recommended, however, because after it is complete, it is still
possible to have processes potentially running on the system in
the wrong context. These processes could create files that would
also be in the wrong context.

Thomas Cameron: Securing Your Linux Servers Slide 64

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

SELINUXTYPE=targeted|strict — Specifies
which policy SELinux should enforce.
targeted — Only targeted network daemons
are protected.
strict – covers everything (use with caution
only if you really understand what you are
doing)

Thomas Cameron: Securing Your Linux Servers Slide 65

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

Important
 The following daemons are protected in the default
targeted policy: dhcpd, httpd (apache.te), named,
nscd, ntpd, portmap, snmpd, squid, and syslogd. The
rest of the system runs in the unconfined_t domain.
This domain allows subjects and objects with that
security context to operate using standard Linux
security. The policy files for these daemons are
located in
/etc/selinux/targeted/src/policy/domains/program.
These files are subject to change as newer versions of
Red Hat Enterprise Linux are released.

Thomas Cameron: Securing Your Linux Servers Slide 66

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

Policy enforcement for these daemons can
be turned on or off, using Boolean values
controlled by the Security Level
Configuration Tool (system-config-selinux).

Setting a Boolean value for a targeted
daemon to 0 (zero) disables policy
transition for the daemon. For example,
you can set dhcpd_disable_trans to 0 to
prevent init from transitioning dhcpd from
the unconfined_t domain to the domain
specified in dhcpd.te.

Thomas Cameron: Securing Your Linux Servers Slide 67

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

Use the getsebool -a command to list all SELinux
booleans. The following is an example of using
the setsebool command to set an SELinux
boolean. The -P option makes the change
permanent. Without this option, the boolean
would be reset to 1 at reboot.
setsebool -P dhcpd_disable_trans=0

strict — Full SELinux protection, for all daemons.
Security contexts are defined for all subjects and
objects, and every action is processed by the
policy enforcement server.

Thomas Cameron: Securing Your Linux Servers Slide 68

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)
 SELinux Utilities
/usr/sbin/setenforce — Modifies in real-time
the mode in which SELinux runs.
• For example:

setenforce 1 — SELinux runs in enforcing mode.

setenforce 0 — SELinux runs in permissive mode.
• To actually disable SELinux, you need to either
specify the appropriate setenforce parameter in
/etc/sysconfig/selinux or pass the parameter
selinux=0 to the kernel, either in /etc/grub.conf or
at boot time.

Thomas Cameron: Securing Your Linux Servers Slide 71

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

SELinux Utilities
 /usr/sbin/sestatus -v — Displays the detailed status of
a system running SELinux. The following example
shows an excerpt of sestatus -v output:

SELinux status: enabled

SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 21
Policy from config file: targeted

Process contexts:
Current context: user_u:system_r:unconfined_t:s0
Init context: system_u:system_r:init_t:s0
/sbin/mingetty system_u:system_r:getty_t:s0

Thomas Cameron: Securing Your Linux Servers Slide 72

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

SELinux Utilities
/sbin/restorecon — Sets the security context of
one or more files by marking the extended
attributes with the appropriate file or security
context.
/sbin/fixfiles — Checks or corrects the security
context database on the file system.
/usr/bin/chcon – changes the security context
on the filesystem

Thomas Cameron: Securing Your Linux Servers Slide 74

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

SELinux Examples
If an application is being blocked, the first
thing you can do is use restorecon -vR against
the directory
If you have installed an app which does not
have an associated policy, you can use chcon
to set the context of the application

Thomas Cameron: Securing Your Linux Servers Slide 75

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

Example – you've downloaded the newest
version of Firefox and installed it in
/usr/local
restorecon -vR /usr/local

Thomas Cameron: Securing Your Linux Servers Slide 76

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

Example – to demonstrate how MAC can
override DAC
A bad guy gets control of an application like
Apache and instructs Apache to read a
sensitive file like /etc/shadow
chcon --reference /etc/shadow \
/home/moe/public_html/secret.txt

Thomas Cameron: Securing Your Linux Servers Slide 77

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Security Enhanced Linux

(SELinux)

Example – to demonstrate how booleans
can be used to turn on or off access
To turn off home directory access:
setsebool httpd_enable_homedirs off

Thomas Cameron: Securing Your Linux Servers Slide 78

Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Production

Once the server is in place, use utilities such as
aide to check system integrity.
 rpm -Va is another useful utility, but since the RPM
database is stored on the local filesystem, it is not
reliable

Periodically check for any open ports or
processes which were not there during the build
and hardening process

Set up remote logging - see the
/etc/sysconfig/syslog file for details, it's very well
documented.

Use logwatch to monitor your logs, it's included
and active by default
Thomas Cameron: Securing Your Linux Servers Slide 79
Colorado Software Summit: October 21 – 26, 2007 © Copyright 2007, Red Hat

Questions?

Thomas Cameron: Securing Your Linux Servers Slide 80