Beginner's guide to armoring Linux

From: Subject: Beginner's guide to armoring Linux Date: Sun, 17 Jun 2001 12:27:20 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Location: http://www.enteract.com/~lspitz/linux.html X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Beginner's guide to armoring Linux Preparing=20 your linux box for the Internet
Armoring=20 Linux=20

Lance=20 Spitzner
http://www.enteract.com/~lspitz<= /A>=20
Last Modified: 19 September, 2000

Organizations throughout the world are adopting Linux as their = production=20 platform. By connecting to the Internet to provide critical=20 services, they also become targets of opportunity. To help protect = these=20 Linux systems, this article covers the basics of securing a Linux = box. The=20 examples provided here are based on Red Hat 6.0, but should apply to = most Linux=20 distributions.=20

Installation
The best place to start in = armoring=20 your system is at the beginning, OS installation. Since this is a = production=20 system, you cannot trust any previous installations. You want to start = with a=20 clean installation, where you can guarantee the system integrity. Place = your=20 system in an isolated network. At no time do you want to connect this = box to an=20 active network nor the Internet, exposing the system to a possible = compromise. I=20 personally witnessed a system hacked by a script kiddie = within 15=20 minutes of connecting to the Internet. To get critical files and = patches=20 later, you will need a second box that acts as a go between. This second = box=20 will download files from the Internet, then connect to your isolated,=20 configuration "network" to transfer critical files or burn the patches = to a=20 CDROM.=20

Once you have placed your future Linux box in an isolated network, = you are=20 ready to begin. The first step is selecting what OS package to load. As = of RH=20 6.0, you have three options, Workstation, Server, and Custom = (default). I=20 highly recommend Custom, as this allows you to choose what services are = added=20 and how the system is partitioned. The idea is to load the minimum = packages, while maintaining maximum efficiency. The less = software=20 that resides on the box, the fewer potential security exploits or = holes. =20 This means if you do not need a News or Real Audio Server, don't install = it. The nice thing about Linux is, if you change your mind, it is = easy to=20 add packages later. Regardless of which installation you choose, I = would=20 add the manual pages and HOWTO docs. I find the on-line man pages = and docs=20 to be a critical resource that add little risk to your system.=20

If you selected Custom, you will be asked to partition your = system. I=20 always like to make root as big as possible and just throw everything in = there,=20 then you do not run out of room in the future. However, we do need = several=20 partitions to protect the root drive. If we were to fill the root=20 partition with data, such as logging or email, we would cause a denial = of=20 service, potentially crashing the system.=20

Therefore, I always recommend a separate partition for /var, this is = where=20 all the system logging and email goes. By isolating the /var = partition,=20 you protect your root partition from overfilling. I've found = 400 MB=20 to be more then enough for /var (increase this if your system will have = alot of=20 mail) . You may also consider making a separate partition for = specific=20 application purposes, especially applications that store extensive = logging. If=20 you are going to have users on your system you do not trust, you may = also want=20 to create a seperate /home directory, so malicious users cannot fille = the /=20 partition. For a standalone server, your partitions may look as follows: =

/        - everything=20 else
/var     - 400 MB
swap     - (I=20 normally go with 256 MB)
=20

Once the system has rebooted after the installation, be sure to = install the=20 recommend security patches. For Red Hat, you can find these security = patches at=20 Red Hat's = errata=20 support site. Patches are critical to armoring a system and = should=20 always be updated. bugtraq@s= ecurityfocus.com=20 or redhat-watch-list-req= uest@redhat.com=20 are excellent sources for following bugs and system patches. = Without these=20 patches, your system can be easily compromised. Be sure to use = your go=20 between box to get the patches, the Linux box should always remain on an = isolated network. . For Red Hat, once you download the rpm, you can = easily=20 update your system using the following syntax. An excellent = example of=20 this is the security update for wu-ftpd=20

rpm -Uvh=20 wu-ftpd-2.6.0-14.6x.i386.rpm=20

For systems that are already on-line, you can ftp the rpm and install = it at=20 the same time, using the following syntax.=20

rpm -Uvh=20 ftp://updates.redhat.com/6.1/i386/wu-ftpd-2.6.0-14.6x.i386.rpm=20

To maintain your patches, I highly recommend the utility autorpm. This command line = utility=20 determines which .rpm's need to be updated, gets those rpm's from Red = Hats's web=20 site, and then downloads and installs the updated files (if you so = desire). This=20 tool is highly customizable and easy to use. The best thing is it can = run out of=20 cron, so your file system gets checked every night, then emails you the = next day=20 that you should update your system.=20

Eliminating=20 Services
Once you have loaded the installation = package,=20 patches, and rebooted, we are now ready to armor the operating system. = Armoring=20 consists mainly of turning off services, adding logging, tweaking = several files,=20 and configuring TCP Wrappers. First we will begin with turning off = services.=20

By default, Linux is a powerful operating system that executes many = useful=20 services. However, most of these services are unneeded and pose a = potential=20 security risk. The first place to start is /etc/inetd.conf. This file = specifies=20 which services the /usr/sbin/inetd daemon will listen for. By default,=20 /etc/inetd.conf is configured for a variety of services, you most likely = only=20 need two, ftp and telnet. You eliminate the remaining unnecessary = services by=20 commenting them out (example = A). =20 This is critical, as many of the services run by inetd pose serious = security=20 threats, such as popd, imapd, and rsh. Confirm what you have = commented out=20 with the following command (this will show you all the services that = were left=20 uncommented)=20

grep -v "^#" = /etc/inetd.conf=20

The next place to start are the .rc scripts, these scripts determine = what=20 services are started by the init process. For Red Hat, you will find = these=20 scripts in /etc/rc.d/rc3.d (or /etc/rc.d/rc5.d if you automatically boot = to a=20 GUI, such as Gnome or KDE). To stop a script from starting, = replace the=20 capital S with a small s. That way you can easily start the script again = just by=20 replacing the small s with a capital S. Or, if you prefer, Red Hat comes = with a=20 great utility for turning off these services. Just type "/usr/sbin/setup" at the=20 command prompt, and select "System Services", from there you can select what = scripts=20 are started during the boot up process. Another option is chkconfig, = which you will=20 find on most distributions. The following startup scripts may be = installed=20 by default but are not critical to system functioning. If you = don't need=20 them, turn these scripts off. The numbers in the names determine = the=20 sequence of initialization, they may vary based on your distribution and = version. Scripts that start with a capital K instead of a = captial=20 S are used to kill services that are already running.=20

S05apmd       (You only = need this=20 for laptops)
S10xntpd     (Network time=20 protocol)
S11portmap   (Required if you have any rpc = services,=20 such as NIS or NFS)
S15sound     (Saves sound cared=20 settings)
S15netfs     (This is the nfs = client, used=20 for mounting filesystems from a nfs server)
S20rstatd    (Try=20 to avoid running any r services, they provide too much = information to=20 remote users)
S20rusersd
S20rwhod =
S20rwalld =
S20bootparamd (Used = for diskless=20 clients, you probably don't need this vulnerable = service)=20
S25squid     (Proxy = server)=20
S34yppasswdd = (Required=20 if you are a NIS server, this is an extremely vulnerable = service)=20
S35ypserv    (Required if you are a NIS = server,=20 this is an extremely vulnerable service)
S35dhcpd    =20 (Starts dhcp server daemon)
S40atd       (Used for = the at=20 service, similar to cron, by not required by the system) =
S45pcmcia    (You=20 only need this script for laptops)
S50snmpd    =20 (SNMP daemon, can give remote users detailed information about your=20 system)
S55named     (DNS server. If = you are=20 setting up DNS, upgrade to the latest version of BIND, http://www.isc.org/bind.html)=20
S55routed    (RIP, don't run this unless = you=20 REALLY need it)
S60lpd       (Printing=20 services)
S60mars-nwe   (Netware file and print=20 server)
S60nfs       (Use for NFS = server,=20 do not run unless you absolutely have to).
S72amd        = (AutoMount=20 daemon, used to mount remote file systems)
S75gated      (used to run = other routing=20 protocols, such as OSPF)
S80sendmail = (You can still=20 send email if you turn this script off, you just will not be able to = receive or=20 relay)
S85httpd     (Apache webserver, I = recommend=20 you upgrade to the latest version, http://www.apache.org/)= =20
S87ypbind     (Required if you are = a NIS=20 client)
S90xfs       (X font=20 server)
S95innd      (News = server)=20
S99linuxconf =20 (Used to remotely configure Linux systems via browser, every black-hat's = dream=20 :)=20

To see how many services are running before you change the startup = scripts,=20 type=20

ps aux | wc = -l=20

Once you are done with the installation and have turned off the = startup=20 scripts, type the command again and compare how the number of services = have=20 decreased. The fewer services running, the better. Also, confirm which = are left=20 running by executing the following command:=20

netstat -na --ip=20

Logging and=20 Tweaking
Once you have eliminated as many services = as=20 possible, we want to enable logging. All system logging occurs in=20 /var/log. By default, Linux has excellent logging, except = for=20 ftp. You have two options for logging for ftp, configure = /etc/ftpaccess=20 file or edit /etc/inetd.conf. I prefer to edit /etc/inetd.conf, as = it is=20 simpler (i.e. harder to mess up :). Edit /etc/inetd.conf as = follows to=20 ensure full logging of all FTP sessions.=20

ftp =20 stream tcp nowait = root =20 /usr/sbin/tcpd in.ftpd -l -L -i -o=20

--- From the man = pages=20 ---=20

If the -l option = is specified,=20 each ftp session is logged in the syslog
If the -L flag is used, = command logging=20 will be on by default as soon as the ftp server is invoked. This = will=20 cause the server to log all USER commands, which if a = user=20 accidentally enters a password for that command instead of the username, = will=20 cause passwords to be logged via syslog.
If the -i option is = specified, files=20 received by the ftpd(8) server will be logged to the = xferlog(5).=20
If the -o option = is=20 specified, files transmitted by the ftpd(8) server will be logged to the = xferlog(5).=20

--- snip snip=20 ---=20

Next comes tweaking. This involves various file administration. The = first=20 thing we want to do is secure our /etc/passwd file (this is the database = file=20 that holds your user accounts and passwords). First, we want to = ensure our=20 system is using /etc/shadow, this securely stores everyone's password as = hashes=20 in a file only root can access. This protects your passwords from = being=20 easily accessed and cracked (one of the first exploits a hacker looks=20 for). The use of shadow passwords is default as of RH 6.0, however = it=20 never hurts to be sure. All you have to do is type the following command = as=20 root. This automatically converts your passwords to the = /etc/shadow=20 file. Of all the actions you can take to secure your system, I consider = this to=20 be one of the most important.=20

pwconv=20

The second step is to remove most of the default system accounts in=20 /etc/passwd. Linux provides these accounts for various system = activities=20 which you may not need. If you do not need the accounts, remove=20 them. The more accounts you have, the easier it is to access your=20 system. An example is the "news" account. If you are not = running=20 nntp, a news group server, you do not need the account (be sure to = update=20 /etc/cron.hourly, as this looks for the user "news"). Also, make sure = you remove=20 the "ftp" account, as this is the account used for anonymous ftp. = From the=20 man pages.=20

man = ftpd:=20

Ftpd authenticates users = according=20 to four rules.=20

= 4) If =20 the user name is ``anonymous'' or ``ftp'', an anonymous ftp = account must=20 be pre-sent in the password file (user ``ftp''). In this case the = user is=20 allowed to log in by specifying any password (by convention this is = given as the=20 client host's name).=20

For an example of my /etc/passwd file, check out example = C.=20

We also want to modify the file /etc/ftpusers (example = D). Any=20 account listed in this file cannot ftp to the system. This restricts = common=20 system accounts, such as root or bin, from attempting ftp sessions. = Linux has=20 the file by default. Ensure that root stays in this file, you = never want=20 root to be able to ftp to this system. Ensure that any accounts = that need=20 to ftp to the box are NOT in the file /etc/ftpusers.=20

Also, ensure that root cannot telnet to the system. This forces users = to=20 login to the system as themselves and then su to root. The file = /etc/securetty=20 lists what ttys root can connect to. List only tty1, tty2, etc in = this=20 file, this restricts root logins to local access only. ttyp1, = ttyp2, are=20 pseudo terminals, they allow root to telnet to the system remotely (example = E).=20

Last, create the file /etc/issue. This file is an ASCII text banner = that=20 appears for all telnet logins (example = B). This=20 legal warning will appear whenever someone attempts to login to your = system. If=20 you want to continue using the same /etc/issue file, you will have to = modify=20 /etc/rc.d/init.d/S99local. By default, Linux creates a new = /etc/issue file=20 on every reboot.
=20

Connecting to=20 your server
For those of you who will be doing = remote=20 administration, it is critical that you develop a secured, controlled = way to=20 connect to the server. Often, you need remote access to your = server for=20 administration or the uploading of files, these communications need to = be=20 secured I will discuss two options here, ssh and TCP Wrappers.=20

I prefer ssh, as it encrypts all communication between you and the=20 firewall. TCP Wrappers will NOT protect your network traffic from=20 sniffing. Users can still capture all of your keystrokes&nb= sp;=20 (including passwords) on the network. If you are concerned about = users=20 capturing communications to your firewall, I recommend you replace = telnet/ftp=20 with ssh. ssh will encrypt all communications to your server, = allowing you=20 both to upload files and administer the server in a secure manner. = ssh is=20 similar to TCP wrappers in that it has its own layer of logging, and can = limit=20 what systems can connect to it. For more information on ssh, you = can find=20 ssh here, including = source for=20 both ssh clients and server daemon. I recommend you use ssh = version 1.2.x,=20 as version 2.x has a limiting license. Another ssh option is Openssh.=20

TCP Wrappers, while it does not encrypt, it does log and control who = can=20 access your system. It is a binary that wraps itself around inetd=20 services, such as telnet or ftp. With TCP Wrappers, the system launches = the=20 wrapper for inetd connections, logs all attempts and then verifies the = attempt=20 against a access control list. If the connection is permitted, TCP = Wrappers=20 hands the connection to the proper binary, such as telnet. If the = connection is=20 rejected by the access control list, then the connection is = dropped. =20 Fortunately for us Linux users, TCP Wrappers is already installed, the = only=20 thing left for us to do is edit the /etc/hosts.allow and /etc/hosts.deny = file. These files determine who can and cannot access our = systems. =20 Also, TCP Wrappers allows us to do fancy things, such as banners or = spawn=20 additional programs, such as safe_finger. The syntax is relatively = simple. Put the IP address or networks in /etc/hosts.allow that = you want=20 to permit connections from. Put IP addresses or networks in=20 /etc/hosts.deny that you do not want to permit access. By default, = Linux=20 allows connections from everyone, so you will need to modify these = files. =20 2 recommendations when working with TCP Wrappers.=20

Use IP addresses instead of system or domain names.=20
Set up /etc/hosts.deny to deny everything (ALL), then permit only = specific=20 sites with /etc/hosts.allow.

For examples on how to setup=20 /etc/hosts.allow and /etc/hosts.deny, see example = F. =20 For more ideas on how to use TCPWrappers, check out Intrusion = Detection.=20

=20

For = the Truly=20 Paranoid
I consider the measures discussed above=20 absolutely essential. By following these steps, you have greatly = improved=20 your system's security, congratulations! Unfortunately, your = system is not=20 100% secure, nor will it ever be. So, for the truly paranoid, I = have added=20 some additional steps you can take.=20

First we will create the wheel group. The wheel group is a = group of=20 select individuals that can execute powerful commands, such as /bin/su. = By=20 limiting the people that can access these commands, you enhance the = system=20 security. To create the group, vi the file /etc/group, create the = group=20 wheel, and add the system admins to the group. Then identify = critical=20 system binaries, such as /bin/su. Change the group ownership to = wheel, and=20 the permissions to owner and group executable only (be sure to maintain = the suid=20 or guid bit for specific binaries). For /bin/su, the commands = would be:=20

/bin/chgrp wheel=20 /bin/su
/bin/chmod 4750 /bin/su=20

Second, we will lock down the files .rhosts, .netrc, and=20 /etc/hosts.equiv. The r commands use these files to access = systems. =20 To lock them down, touch the files, then change the permissions to zero, = locking=20 them down. This way no one can create or alter the files. For example,=20

/bin/touch = /root/.rhosts=20 /root/.netrc /etc/hosts.equiv
/bin/chmod 0 /root/.rhosts = /root/.netrc=20 /etc/hosts.equiv=20

Third, we configure /etc/shadow to use MD5 hashes instead = of the=20 crypt(3) function. This makes the encrypted password file far more = difficult to crack. This is done by modifying the PAM = modules. PAM=20 (Pluggable Authentication Modules) is a suite of shared libraries that = enable=20 you to choose how applications authenticate users. To learn more = about=20 PAM, check out ftp://ftp.us.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html= =20

In the old days, you had to manually modify the PAM modules to use = MD5=20 hashes. However, with Red Hat 6.0 or greater, you can select MD5 = hashes=20 with the setup utility. Just type "setup" at the command prompt, = then=20 select "authentication configuration". From there, you can choose = to use=20 MD5 hashes. However, the MD5 hashes will not take effect until the = user=20 re-enters their password. For those of you who do not have the = setup=20 utility (or have Red Hat 5.2 or earlier), you can still modify the PAM = modules=20 manually (example=20 G).=20

For us bash users, I'm not a big fan of the .bash_history file. = I do=20 not want people (including root) to know my command history. So, = in my=20 .bash_profile, I export the following entry:=20

HISTFILESIZE=3D0=20

This means that nothing will be logged to my .bash_history = file. I will=20 still have keystroke history and recall, the HISTSIZE env variable, but = command=20 history will not be written to the .bash_history file.=20

Last thing we can do is protect our system from physical = access. This=20 mainly consists of setting up a password for our BIOS. Also, you = can=20 password protect your system during boot-up by configuring = /etc/lilo.conf with a=20 password (password=3Dxxx) where xxx is your = password. =20 However, keep in mind, once someone has physical access to your system, = there is=20 no guaranteed way to protect it.=20

IPChains
No discussion about Linux = security would=20 be complete without covering IPChains. IPChains is packet = filtering=20 software that comes with the 2.2.x kernel and above. This means if you = are=20 running Red Hat 6.0 or later, you have it as part of your Linux = installation=20 kit. IPChains is similar to Cisco Access Control Lists, it can = control=20 what packets can come in and out of your Linux box. Primarly used = as a=20 firewall application, IPChains can also be used to armor your standalone = Linux=20 box. To armor a standalone system, I configure = IPChains to=20 allow only TCP connections I initiate. If anyone attempts to = initate any=20 TCP connections to me, the connection is denied. Since IPChains is = not=20 stateful, I do allow all UDP and ICMP connections. Last, I log all = denied=20 connections, this lets me know if someone out there is being naughty = :) =20 However, I drop but do not log all the broadcat/multicast traffic, as = this would=20 quickly fill up the system logs. A simple IPChains configuration to = armor a=20 standalone system would look something like this.=20

bash# ipchains=20 -L
Chain input=20 (policy DENY):
target prot opt source destination ports =
DENY all ------ 0.0.0.0 = anywhere=20 n/a
DENY all=20 ------ anywhere 255.255.255.255 n/a
DENY all ------ anywhere=20 BASE-ADDRESS.MCAST.NET/8 n/a
ACCEPT tcp !y---- anywhere = anywhere any=20 -> any
ACCEPT udp ----l- anywhere anywhere any -> = any=20
ACCEPT icmp = ----l- anywhere=20 anywhere any -> any
DENY all ----l- anywhere anywhere n/a
Chain forward (policy=20 ACCEPT):
Chain=20 output (policy ACCEPT):=20

To see the config files for this, see example = H. To learn=20 more about using IPChains as a firewall or for a standalone system, = check out=20 the IPCha= ins=20 HOWTO.=20

Conclusion
We have covered some of the = more basic=20 steps involved in armoring a Linux box (Red Hat distribution). The key = to a=20 secure system is having the minimal software installed, with protection = in=20 layers, such as TCP Wrappers, IPChains, and shadowed passwords. There = are many=20 additional steps that can be taken, such as tripwir= e=20 (monitor changes in system binaries) and swatch = (automated log=20 monitoring and alerts). I also recommend that new Linux users check out = Bastille Linux, a PERL = script that can=20 automatically secure your new Linux system, step by step. Remember, no = system is=20 truly 100% secure. However, with the steps outlined above, you greatly = reduce=20 the security risks.

Author's = bio=20
Lance Spitzner is currently an active member of the Honeynet Project. He enjoys = learning by=20 blowing up systems in his home lab. Before this, he was a tanker in the = Rapid=20 Deployment Force, where he blew up things of a different nature. You = can=20 reach him at lance@honeynet.org .=20

=20

Whitepapers = =