|
LDP Mirror
Forums RSS 
Past club events:
UHACC @ Penguicon
LinuxFest 2004
SCO-B-Q
UHACC @ Flatcon
Club Pages:
ISU chapter: ISUnix
Member's Sites
Projects:
UHACC CVS
Club Documents:
Our Guiding Principles
UHACC Constitution
Operating Code
Membership App
AUP
|
Securing Linux in a Nutshell
C. Geigner - President, UHACC.org. 9 Jan 2004
Intro
This document will discuss common security procedures and concepts
for "out-of-the-box" Linux installations. This document
will illustrate our main points with Red Hat Linux examples,
however most concepts are not specific to any distro.
This document is being geared towards those performing a more common
server setup. That is, the assumption is that you're not trying to
do anything other than Secure Shell, Samba, Sendmail and/or perhaps an Apache web server.
If you are setting up something else, be sure to investigate proper security precautions before going live.
Part 1: What're you serving? 'ps' 'netstat' & 'nmap' are your eyes.
It really doesn't matter what you think you are running, after install you have to verify.
To whit: We haven't installed a system yet that didn't start some network daemon that wasn't asked for during setup.
Wouldn't it be a shame if you worked hard to secure your web server just to discover intruders gained access via an unsecured e-mail server daemon that your didn't even know about?
ps
The most rudimentary check is to use the ps -ef command.
This will give you a listing of processes, their process IDs, parent process IDs, process ownership and so forth.
Your task here is to sift through the returns and look for processes that match those you intended.
Once that is done, what is left is for you to evaluate.
But, what is left will also contain non-networked services such as kernel processes, mingetty, cron, init and so forth.
Another obstacle here is the that your system may be running one or more superdaemons such as xinitd, which
might be running several network services out of itself (see Part II for more information on xinetd).
The ps -ef command may not give the fullest picture of your network services,
but it might show a process that oughtn't be running and is an overall decent place to start.
netstat
For another 'inside look' at your linux box, use netstat -a.
This shows you every open network and UNIX domain socket on this computer.
The report generated starts with a list of the open
TCP and UDP sockets. The goal here is to make this list as short
as possible and showing only those services that you intend.
Why? Because every open UDP port, and every TCP port in a LISTEN state,
is a potential point of entry for an intruder.
Use this command liberally throughout setup to see what is changing.
If you want, you can pipe the output to a file (netstat
-a > filename).
NOTE: For now, don't be concerned
with UNIX domain sockets (the lower parts of the generated report) as they
are only accessible to users/software running on the computer (and we're
here to prevent that).
nmap
To get the "outside look" of your Linux box, use Fyodor's nmap utility.
In addition to OS fingerprinting, version detection, and ping sweeping, nmap allows
system administrators to portscan network hosts to reveal what TCP and UDP services they offer.
Nmap results usually show a list of interesting ports on the target machine.
Nmap always gives a port's "well known" service name (as listed in /etc/services), number, state, and
protocol. The state can be either open, filtered, or unfiltered. Open means
that the target machine will accept connections on that port.
Filtered means
that a firewall, filter, or other network obstacle is covering the port and preventing nmap from determining whether the port is open.
Unfiltered means that the port is known by nmap to be closed and no firewall/filter seems to be interfering
with nmap's attempts to determine this.
Unfiltered ports are the common case and are only shown when most of the
scanned ports are in the filtered state.
Once you finish your install and at anytime thereafter, you can use nmap to reconcile your list of services intended to nmpa's list of services offered. If you detect a service running that you didn't want, use that info to fix your box.
Part 2: The xinetd/inetd Superdaemon
Security concerns and Inet
Inet superdaemons serve as a one-stop internet daemon launching pad.
It comes preconfigured usually, and usally it is set to start something that you don't want or need.
Traditionally it has been the place to configure and launch such services as telnetd, ftpd, rexecd, rlogin, and timed I (and over 100 more configurable inet-compatible daemons possible)
More discussion on inetd
Determining Inet Type
On Linux systems, there has been a shift away from running the traditional UNIX-style inetd superdaemon.
To determine which type of inet superdaemon you run, check your process listing (run ps -ef.
If neither inetd or xinetd are found running, check for the existence of /etc/inetd.conf, which would indicate a possible inetd implementation.
Otherwise, check for an /etc/xinetd.d directory, which would point towards a xinetd setup.
inetd
To secure or start services in inetd, you must first edit the /etc/inetd.conf file.
Start by commenting out lines listing services that you do not wish to host.
Be liberal and when in doubt, comment it out. Minimalism is the goal here.
In short, if you don't know what it is, or you don't know if you use it, turn it off.
After you're done you'll need to send the inetd process a SIGHUP (kill -HUP PID), which will force it to read and execute its new (and hopefully improved) configuration.
xinetd
To edit xinetd services, go to the /etc/xinetd.d directory and list its contents.
This is a list of all the service configurations that xinetd will read when started.
You have two options: the
easy/more permanent route, or the harder/more proper route.
If you chose the easy way, you simply delete the files in the folder
that correspond to services you don't want offered. Yup. Just nuke away to
your heart's content.
The other way is to edit the files corresponding to the services
you want to disable, and add a "disable = yes" line somewhere applicable
(between the curly braces configuring the service).
Example:
service ftp
{
flags = REUSE
socket_type = stream
instances = 25
wait = no
user = ftp-nobody
server = /usr/local/sbin/proftpd
bind = 10.0.0.1
log_on_success += HOST PID USERID DURATION
log_on_failure += HOST RECORD ATTEMPT
disable = yes
}
To find the run state of all xinitd services, you can simply run the following command:
find /etc/xinetd.d -type f|xargs grep disable
Regardless of which method you choose, you will need to restart
xinetd (it doesn't as of this writing support the HUP signal). This is
accomplished by issuing
service xinitd restart as root.
Part 3: Check Run-level Services
At boot, your system will run init, which in turn runs a set of scripts referenced in an "rc" directory.
There are several of these directories, each one corresponding to a different run profile, called a runlevel.
Common runlevels are 3 and 5, three being console mode (normal for servers) and five being graphical mode (normal for desktops).
The scripts run to start services are all located in /etc/rc.d/init.d/, but are called by symbolic links located in each runlevel folder; /etc/rc.d/rc3.d/ for runlevel 3 and /etc/rc.d/rc5.d/ for runlevel 5.
These symlinks are named [SK]nnname - For example, we have S10network and K87portmap, the first link running the script that starts our network interfaces and the second being a disabled call to the portmap service (used by nfs and other yp services). A "K" at the beginning of the symlink name means that service is not set to start;
an "S" at the beginning of the symlink name means that the run script for that service will be invoked
at startup for that runlevel.
The following slot numbers are simply elementary ordering. A lower numbered service (say "network") gets started before a higher numbered service (say "Samba").
Now that we all can decipher these symlinks in the rc directories, don't mess with them!
No, really. It is easy to start deleting symlinks in the name of security and some documents even recommend that practice, but we will not. Why? Well (A) it is easy to nuke something crucial (like local) and (B), there is a runlevel editor that you can use: chkconfig
To list all services in all runlevels, run: chkconfig --list
To narrow down to started services in a specific runlevel (in this case, runlevel 3):
chkconfig --list|egrep '3:on'
To turn off a service, run: chkconfig --level 3 servicename off
You'll probably want to keep things like "network",
"syslog" and "crond".
After messing with your runlevels, you might want to reboot if you are new at this - just to
see if the system comes up correctly.
Do a netstat -a to see what's listening.
You shouldn't have anything except the things you consciously decided to run.
Part 4: Wrap it!
TCP Wrappers are a very useful tool in any sysadmin's defense scheme.
It consists of a wrapper library, libwrap.a and a daemon, tcpd.
What it does is allow any service built with it configured in to utilize an access scheme, limiting access to only those defined.
It is already automatically used by the xinetd superdaemon, and many services outside xinetd can be built from source against the libwrap.a library.
Once you have identified services that you can wrap, edit or create your tcpd access profiles.
These are contained in 2 files: /etc/hosts.allow and /etc/hosts.deny.
The first thing you should do is set your deny profile.
This is easy.
What is desirable is to deny everything, unless specifically allowed in /etc/hosts.allow.
With this in mind, your /etc/hosts.deny file should take one of the 2 following formats:
ALL : ALL : spawn (/bin/mail root -s "%d - denied connect from %u@%h (%a)") & : deny
OR
ALL : PARANOID : spawn (/bin/mail root -s "%d - paranoid denied connect from %u@%h (%a)") & : deny
These profiles are basically the same;
both, if the source is not specifically allowed, will reject all sources for all protocols, while also mailing the root user upon each triggering of the rule.
The second version uses the PARANOID directive to also reject all sources where the forward and reverse DNS lookups do not match.
(NOTE: This sounds really secure, but should be used with caution, as many legitimate hosts may have broken reverse lookups)
The second thing you will want to do is to define what hosts or ip addresses may access your services.
Your /etc/hosts.allow file can be configured as follows:
servicename : 10.0.0.1 <--- 1 IP address allowed
sshd : 10.0.0. <--- All IP addresses beginning in 10.0.0 allowed access to sshd
ftpd : host.example.com <--- Host allowed access to ftpd
sshd : .example.com <-- All hosts on example.com allowed
imapd : 10.0.0.0/255.255.255.0 <--- All hosts within netmask allowed access to imapd
Part 5: Firewall or Turn Off Plain Text Protocols When Possible
Like mentioned earlier, plaintext protocols like telnet and ftp are not ideal in an environment where unknown elements stand between a clent and server.
Here's why: anybody running a sniffer such as Ethereal can record
everything in the session.
This includes usernames, passwords, data, and session activity.
To see this for yourself, try setting up plaintext protocols on a private network and sniffing the traffic..
Fortunately there is SSL encryption available for many common network services.
Start by seeing if your users can use ssh and sftp instead of telnet and ftp. If your users are popping
their mail down, see if they can use secure pop instead of pop3. Same goes for imapd - try imaps.
If users use http for sensitive activities, use https.
Now, if you can't turn any of these services off, at least consider limiting access via iptables and/or TCP wrappers so that noone outside your intended sphere of access can get to it.
Heck, even if you are running encrypted services, firewalling and wrapping is still a good idea.
Part 6: Do Routine Security Maintenance
Update & Patch Your System
As a rule of thumb, always consider a networked computer as insecure, especially
one that hasn't been updated in a while. Any and all networked services
you're offering should be upgraded when bugfixes, maintenance and security patches become available.
It is a good idea to subscribe to any security bug mailing lists for your services in order to learn about security
problems. By doing so, you can take the necessary actions to upgrade or patch. Vigilance is important; it doesn't
take long after an exploit hits Bugtraq or a number of other full-disclosure
security lists before malicious types with much spare time and
real talent are probing the Internet (and you) for exploitable services.
Read Your Logs!
You must make sure syslogd is active and that you monitor your logs on a regular basis.
Now the sheer amount of data contained in many of the logs may make reviewing them punctually seem like an impossible task, but remember you are really only interested in the more interesting events.
Instaed of just reading each of your detailed, long logs every day, you can use a tool such as Logwatch to prepare a daily digest from your logs containing only the info that you've configured it to give.
That removes the burden of scanning through some of the detail-y, unremarkable, mundane and often unimportant multitude of entries.
One thing you will have to check at the outset here is your syslog configuration (/etc/syslog.conf) to ensure that you are in fact logging everything that you need to be, and at the level of detail that you need.
Pay particular attention to your secure log and your mail logs (contains a suprising amount of security info).
last updated January 9, 2004
|
|
Upcoming Events
UHACC Pre-Meeting
Wednesday Evenings, ~5:15-6:30pm - Lunker's
Officially unofficial pre-meeting meeting.
Come. Eat. Geek.
UHACC Meeting
Every Wednesday - 7:00-9:00pm
IWU Center for Natural Science Learning and Research, Fishbowl, floor 2.
[Directions]
Join us every Wednesday for our usual gratuitous display of geekiness. Meetings are free and attendance is open.
Hope to see you there!
|
