Linux Security

As the hacking attempts and tools have become more prevalent and automated, so has the need for security.  Many unix/linux systems come with too loose of security.

The following measures I've come up with will help to close most known entry points and probably lock out 95% of most hackers (if implemented correctly).  If you need me to run a security audit, contact me.  This is just the tip of the iceberg... you can consult with me for further in-depth security.  If installing Linux from scratch, choose the "Workstation" option, which will (by default) not even install most services needed to get into the machine.

• 1st line of defense:    Disable all unneeded services
• 2nd line of defense:   Limit services to local domain
• 3rd line of defense:    Intrusion Detection - Department Tripwire Script
• 4th line of defense:    additional Linux Security Suggestions
• Request a security scan of your system
• Intrusion Detection Checklist
• Further reading:    Implementing Linux Security (Article)

1st line of defense - disable unneeded services:

edit your /etc/inetd.conf file and put a # at the beginning of ALL services that you don't specifically need.

On newer releases of linux, this file may not exist, in that case the services are probably in the /etc/xinetd.d directory.
go to /etc/xinetd.d and make a new directory called "disabled".
Then move any services you dont need into that directory.

Especially: gopher, imap, pop-2, pop-3, talk, ntalk, finger.  I also suggest doing this for shell, login, rsh, rexec, rlogin (which will only disable rsh and rlogin, not telnet) and do this for ftp (which will only shut off ftp TO your machine, you'll still be able to ftp out)

Then do a "killall -HUP inetd"
or if running xinetd... execute: /etc/rc.d/init.d/xinetd restart

Also take a look in the rc startup files (RedHat linux stores these in /etc/rc.d/init.d).  Rename services you dont want running, such as innd, news*, httpd, nfs, portmap, smb, etc.  Just rename these to something like innd.disabled in case you may need to turn them back on.  If you do any "updates" to the version of linux, you need to re-do several of these security measures.

2nd line of defense - limit enabled services to local domain

Here are some sample files to begin with:
/etc/hosts.deny
/etc/hosts.allow
and be sure to put them in /etc, "  chown root.root hosts.*  "  and  "  chmod 644 hosts.*  "
 

Some explanation about the hosts.allow and hosts.deny files:

To disallow ALL access from outside the .syr.edu domain, you should do the following:
add an entry in your /etc/hosts.deny to include:
ALL: ALL

and add an entry in your /etc/hosts.allow to include:
ALL: LOCAL, .syr.edu

If you access your machine from somewhere different, perhaps a different internet provider which uses dynamic ip's, you can also add an entry such as ALL: .twcny.rr.com to allow access from roadrunner.  Granted, this will allow access from anyone on these domains, but at least you've locked out 99% of the internet.

If you want to be more cautious, change it to ALL: physics.syr.edu
This sets up sort of a firewall, where you must login to our main server (preferrably using ssh), then to your machine.  Yes, it adds an extra step, but may well be worth the added security.

And if you really want to setup booby traps... put the following in /etc/hosts.deny (instead of the ALL: ALL):
ALL: ALL: spawn (/usr/sbin/safe_finger -l @%h | /bin/mail -s %d-%h <insert_users_address_here>) &
 
 

Since you're using Linux, you really should use ssh! and also disable telnetd in /etc/inetd.conf
If you need to find the package or need help on installing it, please let me know!

3rd line of defense:  Intrusion Detection - Department Tripwire Script:

This is key!  I was able to detect and shut down a hacker within 1.5 hours using this method!

Easier installation:  physicstripwire1.5.tar
 

• Just untar (tar xvf physicstripwire1.4.tar),
• read the "README",
• change the email address of "owneremail" in the file "srch"
• run "install"
• add the entry as stated to root's crontab
• that should be it!

edit the "srch" file and enter YOUR email address

then run the "install"

finally, add an entry to root's crontab (`crontab -e`)
add these lines:

# check every 30 min
30 * * * * /usr/sbin/.srch
 

Hopefully that should do it and we'll both get a "system clear" email
If not... email me... it's always in need of improvement.
 

#last modified by DCK April 2, 2001
#
# This script is still in rough draft but should work
# It's NOT elegant, so email me for help
#
# save in a non-descript location to run from that a hacker
# wont typically find (perhaps /usr/sbin/.srch)
#
# put your email address in the $owneremail below
#
# run the .srch_setup > /root/.srchcksums to initialize the files to watch
#
# when completed, try running it
# Once you have it successfully running with no alerts,
# add it to root's crontab (`crontab -e`)
# with a separate line of:   30 * * * * /usr/sbin/.srch
#
# I'm not sure if this format matches Linux other than RedHat (like Mandrake)... let me know!
# it appears that Mandrake says root can't edit through "crontab -e"
# in this case, edit the /etc/crontab file
#
# Please keep my email in there as another person to alert
#
 

If you have any questions or suggestions on this script, let me know.
 

4th line of defense - further Linux Security Suggestions:

---If you need to log IN to your machine, we strongly suggest disabling telnet and use ssh.

---Keep your release up to date!  If you're running an older version, it's quite easy to put in a new cd, click "upgrade" and less than an hour later, you're updated!  If not, you should frequently check for errata, especially security related errata (updates).  RedHat Linux security errata can be found here: https://www.redhat.com/apps/support/updates.html
 
 
 
 
 
 
 

Additional information and tools:

To implement some additional procedures, I also suggest:

PortSentry:  http://www.psionic.com/abacus/portsentry/
A great way to find and stop sniffers and those who hit direct ports.
This tool will drop a rule into tcp-wrappers, host.deny and ipfwadm./ipchains for anyone touching your system in an inappropriate fashion.

Tripwire: http://www.tripwiresecurity.com/products/TWUnix.cfml
Tripwire software enables system administrators to verify the integrity of file systems, directories or registry keys on protected machines.  Tripwire empowers the user to determine exactly what has changed on a system over time.

Saint: http://www.wwdsi.com/saint/index.html
In its simplest mode, it gathers as much information about remote hosts and networks as possible by examining various network information services as well as potential security flaws, and reports on potential security problems.
 

List of Unix System Monitoring Tools:  http://ciac.llnl.gov/ciac/ToolsUnixSysMon.html
 

Request a Security Scan

Intrusion Detection Checklist

If you are suspicious of a hacker, these are some things to check:
try a top (or ps aux|more) and see if anything is running high percentage that you don't recognize

 run /sbin/ifconfig | grep PROMISC ... if it results in ANY output, your network card is sniffing passwords!

Check the dates and file sizes of /bin/login (usually around 15284 for RedHat 5.x, 20164 for RedHat 6.0) and /usr/sbin/tcpd (usually around 19640 for RedHat 5.2, 25284 for RedHat 6.0)... if they are much larger, they could have been replaced with backdoors.

Check your /var/log/secure* files for any strange logins.  If you do not have /var/log/secure files, then either you didn't install linux with tcpwrappers (bad!) or your /usr/sbin/tcpd has been tampered with.

Search for ... or *snif* or tcp.log or linsniffer
use "find / -name "*snif*" -print
(I have seen these under /, /etc/rd.c/init.d, and home directories)

Check in /root for anything suspicious

Check your /etc/passwd file for any unknown entries that may have been added.

Some hackers are smart in that they will erase or disable the logs, hiding their access.  They almost always try to replace /bin/login /bin/ls and /bin/ps, trying to hide their programs.  And the better ones will try masquerading the fact they changed anything by keeping the size and date the same.
Then again, many are not so smart, having recent dates for the replaced files, different owner/group than root, and sometimes even leaving their tracks in the logs and .bash_history!

Also....
Make sure you are running the latest version available, and have all patches and updates available.  Checking for new patches should be done at LEAST every quarter.  Especially in the case of Linux, vulnerabilities spread quickly so you must keep updated.  Red Hat Linux updates can be found at http://www.redhat.com/support/errata/
 

(Add more information here on homemade tripwires or get tripwire at www.cert.org for intrusion detection)

This is by far NOT complete... nothing is 100% and intrusion detection needs to be implemented as well as locking doors.

See the following links for much more detailed information:

http://www.cert.org/

Security Improvement
http://www.cert.org/security-improvement/

Security Tools
http://www.cert.org/tech_tips/security_tools.html

Intruder Detection Checklist
http://www.cert.org/tech_tips/intruder_detection_checklist.html

Recovering from an Incident
http://www.cert.org/nav/recovering.html

Steps for Recovering from a UNIX Root Compromise
http://www.cert.org/tech_tips/root_compromise.html

Implementing Security on Linux

Security is never a luxury. It can save money, time, and frustration. The Linux operating system, a UNIX clone created in 1991, has several built-in security mechanisms, which are unfortunately rarely used. This article explores the basic aspects of securing a Linux server.

 Start with a fresh install. Any security expert will tell you that there is no use securing a system when you don't know whether break-ins and backdoors already have been created. Any Linux distribution will work fine, because they all contain the required security tools. You should install and configure the Linux system before connecting it to the Internet. Linux installation is relatively simple regardless of the distribution you pick -- the security configuration happens after the installation.

 Basic security on a Linux system is very similar to other UNIX systems. Areas to configure include user security, network security, and kernel parameters. This article reviews all of these areas, including more advanced ways to add security to Linux and some sites that contain more information.

 Initial Security

 After initial system setup, you can see how to make it cracker-proof. First, secure the root account. For example, edit the file /etc/securetty, which contains a list of pseudo-terminals from which root can logon. Disable telnet(ttyp0-ttyp9), so the root user can only be used on the console or over a secure link such as ssh. Also, configure the ftp daemon to refuse root logins. The file /etc/ftpusers lists the users that cannot use ftp and the root user should be part of that list.

 Securing normal user accounts depends on which actions you want to allow them to do. For example, with a mail account the shell should be set to /dev/null when you create the user account. A last thing to do from the shell is disable suid programs. Programs that are set uid root (suid) can be executed by any user, and the program will run with root permissions. This is very dangerous, and only necessary programs should be left suid. Type the following command to find out which binaries are suid on your system:
 
 

 find / -perm -4000 -print

 Networking

 When connected to the Internet, your server acts as a playground for crackers who wish to crack in to destroy data or steal property, especially if your site is high profile. You must know which Internet services are running, and disable all those that aren't necessary. Services are started from two places: The Internet daemon, configured in the file /etc/inetd.conf, and the startup files, in the directory /etc/rc.d. Go over each of them and see if you need these services. Although services like finger, echo, or daytime have their uses, you probably don't need them and if you leave them running, they create possible security holes in your system. A good way to see what is currently running from the startup files is by issuing this command:
 
 

 ps -ax

• kerneld -- This process is unrelated to networking and may cause you to wonder what this is, especially since older versions of Linux did not have it. The kerneld process is a way for the kernel to perform action in user space. It is, for example, used for loading kernel modules.

 • inetd -- This is the super-server, the Internet process that controls other services such as ftp, telnet, and finger. It is needed most of the time and should be left alone. You can configure inetd from the /etc/inetd.conf file, where each specific running service is listed.

 • lpd -- This is the line printer daemon. It controls the spooling system and the printing. Using a daemon allows your system to receive print jobs over the network from authorized systems. You can firewall it if you do not expect printing requests to come from other hosts. We will talk about firewalling later.

 • portmap -- The portmap process converts TCP/IP calls into RPC numbers and is needed to run RPC processes. You need it, for example, to share directories between hosts, using the NFS protocol.

 • rpc.mountd, rpc.nfsd -- These are the necessary processes for allowing other hosts to mount shared directories on your system, using the NFS protocol.
 
 

Here are the most popular services run from inetd, which you need to configure in the /etc/inetd.conf file:
 
 

• telnet -- telnet is an unsecure protocol. It transmits data over an uncrypted connection. It should not be used for administration purposes and should be disabled on servers with sensitive data.

 • ftp -- The File Transfer Protocol is a widely used service to transmit files over the Internet. There are two ways to use ftp -- for user login, and for public purposes. If you allow the special user "anonymous" to log in on your ftp server, this may have serious implications. Avoid it, if possible, because we often see security announcements regarding possible buffer overflows in ftp servers allowing unauthorized users to gain root access.

 • smtp -- The SMTP server is the Internet mail server. It could be Sendmail, Qmail, or an other program. Keep your email server up to date, because most systems need an email server to participate in the widely used email system.
 
 

Once you are familiar with every service that is running, make sure that you have the latest stable versions, and that they contain no known bug. You can run Sendmail, the email server, as well as Apache for Web serving, and ftpd for anonymous ftp, but first understand each of these services and how they handle clients so you can configure them properly. Sendmail, for example, runs as root and does everything with superuser privileges. This means if any bug is found in any part of Sendmail, then root is vulnerable. This was a big problem in past versions, but now it is much more secure. Another solution to try is Qmail, which is also an email server, but runs multiple processes, and only a minimal part runs as root. If a bug is discovered in another part of the program, root will not be vulnerable.

 Also consider the ftp daemon. The most popular ftp daemon on Linux, and the one that comes by default, is wu.ftpd. Bugs are sometimes found and not fixed right away in the main wu.ftpd distribution. Look for the VR series -- the wu.ftpd(VR) distribution is a package that does everything the normal ftp daemon does, plus various bug fixes and enhancements. Always run the latest VR version, since the ftp daemon must run as root in order to assign users their proper permissions. Note that allowing anonymous users on your server is another possible security hole. Read the man page for precise information on how to set up the anonymous account to be secure.

 Apache was designed in a completely different way. As soon as you start httpd, the Apache binary, it sets itself as another user. It does everything as a normal user, with no special privileges. This is why Apache can't allow someone to break into a system. Note that this only applies to the server itself, not the CGI scripts you may allow users to run.

 Also consider the way people log on. By default, telnet and ftp are not encrypted, and passwords are sent as clear text. Never log in as root over telnet. Install sshd, which allows you to log in using an encrypted connection. With ssh you can log in, and with scp you can copy files to and from the server. Another option is to disable ftp and telnet completely and let your users use only ssh and scp.

 Firewalling and Kernel Parameters

 The Linux kernel comes with advanced packet filtering and accounting. This is the next area to work on. Configure your kernel with IP Firewalling and IP Accounting on. To configure your firewall, use the ipfwadm utility for kernels 2.0.x and ipchains for kernels 2.2.x. Basic firewalling rules to add are blocks for address spoofing. For example, if your server is a gateway for a local LAN (with the eth0 network interface connected to the Internet and the eth1 interface linked to a local network with IPs in the 192.168.1.x class), it makes no sense for packets from an IP in the 192.168.1.x class to come in from eth0. This would certainly be a spoofing attempt.

 These rules, entered by the ipfwadm or ipchains commands, are then set up in the kernel's firewalling rules. For example, here are rules commands to block packets from an address spoofer trying to appear as an internal system, assuming the external IP of your system is 254.23.45.5.
 
 

For kernels 2.0.x:

 ipfwadm -I -i deny -P all -W eth0 -S 192.168.1.0/24 -D 254.23.45.5/32

 ipchains -I input -p all -i eth0 -s 192.168.1.0/24 -d 254.23.45.5/32  -j DENY

 You can also use the TCP wrappers package, which does the same thing as IP firewalling, but on a per service basis. Configure /etc/hosts.deny to deny everyone except your local domain from accessing ftpd. For example:
 
 

 in.ftpd: ALL EXCEPT 192.168.1., 127.0.0.1

 ulimit -a

 ulimit -c 50

 Advanced Topics

 An interesting concept that is becoming more popular is encryption. There are two ways to encrypt files -- a program that can encrypt a file with a key, and a kernel module that can encrypt a file system. The default Linux file system is ext2, and it is a bare bones file system, with no ACL or encryption capabilities. To encrypt files on a file system, install a file system that is capable of handling encryption. One such file system is TCFS. It is a transparent file system that installs itself as a kernel module and provides files to clients in a way similar to NFS. The client requests files, and the server handles the requests, and provides decrypted files to the client. To encrypt only a few files, use a program like PGP or IDEA. PGP uses a public/private key scheme, while IDEA only uses one key on the command line.

 Final Thoughts

 I have only scratched the surface of security issues for Linux systems. In reality, security is a complex, continuous task. At a minimum, you must do two things on a regular basis to ensure security on your server. First, check your logs often. Several tools are available to help you monitor logs. (I created my own small program that would parse the log, put in bold and issue a beep on important lines like password failure or su login.) Second, read CERT notices, the BUGTRAQ mailing list, and the sites of the authors of the various programs you are running (like Sendmail and Apache) for updated versions.

 Resources

http://metalab.unc.edu/LDP -- The Linux Documentation Project provides various documents for administrators on various Linux issues.

 http://www.seifried.org/lasg -- This is the Linux Administration and Security Guide, which provides much more in-depth coverage of various security tools and lists the common services and ways to secure them.

 http://www.cert.org -- The CERT Coordination Center is the central place for security issues in all kinds of UNIX programs. They publish advisories on new-found security holes.

 http://www.geek-girl.com/bugtraq -- BUGTRAQ mailing list archives.

 http://metalab.unc.edu/LDP/HOWTO/IPCHAINS-HOWTO.html -- ipchains how-to.

 http://tipoftheweek.darkelf.net -- The Tip Of The Week Web site lists Linux tips on various issues that can arise while configuring a Linux system.

 http://tcfs.dia.unisa.it -- The TCFS encrypted file system home page.

 http://www.pgpi.com -- PGP international Web site.

 ftp://idea.sec.dsi.unimi.it/pub/crypt/code -- Contains IDEA and other encryption programs.

About the Author