A Unix Security Tutorial By: Christopher Pace ares@armory.com INTRO This tutorial is for those of you out there who have a *NIX (Linux, Unix, and all flavors) system, and who wish to secure it against the threat of a remote attack or vunerabliliy. This tutorial assumes that you already have a *NIX system running, if not, then check out http://www.freeos.com. This tutorial also assumes you have a basic *NIX knowledge (basic shell commands will suffice, and also how to install rpms or tarballs). Now then, why do we require security? Some security sources want you to believe that running *NIX and having a good password system is the only important part of security. These people are WRONG. *NIX is not perfect, it has occasional flaws, which lead to exploits, and a system must be thorougly checked for flaws in security. Now, why do you require security? If you run any services, or if your system is a server, then you need it like you need Mountain Dew and Twinkies to finish a program at 3 a.m. If you don't, and you have no problem with having your system annexed, with all the passwords for your various online accounts taken, and with getting a knock on your door by the FBI, who claim that your computer assisted in a co-ordinated DoS attack on a Microsoft server, then you don't need to read this tutorial. Just live your life annexed, if it suits you. However, if you would like to have a secure, stable system, then read on. THREAT/SERVICE ASESSMENT The first step towards a secure system is to asess the threats and services running on the system. The most important are the threat asessments. You should look at your system from a cracker/hacker's point of view. How important is your system to the average cracker? Does it have any sensitive information on it? Does it have accounts of other users on it? What will motivate someone to try to crack or "hack" their way into your soon-to-be secured *NIX box? Always assume that the cracker is smarter, quicker, and more skilled than you are. Assume that this cracker is interested in the most mundane aspects of your *NIX system, and assume that the cracker wishes to bring the system to its knees. Now, with all of this information, you can take important pre-configuaration steps, such as to remove any disk utilities from the system and place them on a cd (why would you need these to begin with, unless there was something wrong?). Disk utilities are utilities such as fdisk and fdformat, etc. Also, you can take important physical security precautions, such as having a locking system between the cracker and the system (keypads are nice, but be reminded that they are easy to crack, given enough time). Nothing is too paranoid, all network cables should be tucked away in the ceiling, not exposed, where a cracker could decide to damage them, resulting in a frustrating primitive attack. Basically you should think of any possible primitve way (by primitive I mean physical) that a cracker could damage or impair your system. Once this is completed, and you have a general awareness of problems, fix these first, then asess the services running on your system. Make a list of what this system will do, or is currently doing. In other words, make a list of what it is legitimately used for, such as if it is a SSH server, a web server, etc. Once you have a list of all its duties, we are ready to fine-tune the services. Go through each and every service that you do not have written down, and kill them all. If you have a SSH server, why do you need the FTP daemon running? The reason you are doing this is because once this system is up and running, nine times out of ten, you will forget about the other services. Also, who needs the extra worry of having too many services running, and updating them all? If your server is a POP3 server, then a POP3 server it should ONLY be. While you're at it, once you have killed the daemons, uninstall the packages. That way, not only will you free up some disk space, but if you are rooted, they cant as easily copy other exploits (with FTP), or they cant as easily send a bunch of spam (SMTP). I cannot stress this enough, make yourself aware of the versions of all the daemons running on a system, to do otherwise is foolish. One of the most common security problems, however, is caused by the users themselves, or others pretending to be legitimate users. USERS Do you have any users on your system? To find out, check out /etc/passwd. Here will be a list of users in following format: user:x:UID:GUID:account name:home path:shell There may be other fields, depending on whether you have shadowed passwords installed, but this will suffice. The UID is the User ID, a unique number that means basically that user, while GUID is Group ID, the same as UID, only with a group of users. The account name is something like John Doe, home is usually /u/user or /home/user, which is their home path. The shell depends on what shell the user selected, or was assigned, /bin/bash is the most common, which is the Bourne Again Shell. Now then, I suggest you look at this file every few weeks or so, to see if new users are made, but more importantly, if any UIDs or GUIDs are set to 0. This means root, and if you don't know who root is, root is the super user, the one who makes any changes he/she desires. If you see a user with UID and GUID set to 0, and you didn't do it, then you've got a problem. This means that another user, probably after breaking into your system, made a user with root privileges, and thus the same as root. Delete that line immediately, and pull the system off the network while you do a security audit. Now then, if instead of seeing x, you see a password, you're into some trouble. You didn't install shadow passwords, a basic must with *NIX systems. Check the distro you run as to which packages to install, and whether they are on the CD, or however you installed *NIX. Now that we've checked out /etc/passwd and verified that only the users that are necessary for *NIX operation (there are some default pwd/users there, I suggest deleting ones such as games, and nobody (assuming anonymous FTP is disabled, as well as the httpd), etc. Normally you don't have to worry about these, as most default accountnts don't have shells. We now should concentrate on the users themselves. Login as root (you should already be), and look at each and every users' home directory, as specified in /etc/passwd. (I suggest printing this file, to use as a reference, in case a user with something like daemon_kill shows up later (a newbie may mistake this user as a system process that needs root access. While we're talking about it, remove all compilers from your system, or remove execute access by issuing the chmod o-x {compiler} command. These are normally: /usr/bin/perl (Perl) /usr/bin/cpp (C++) /usr/bin/gcc (C) /usr/bin/python (Python) This prevents someone from uploading C code to your system and compiling the program, a nice exploit, and rooting your sorry behind. Don't just block off C compiler access, all compilers and debuggers need to be blocked off, or better yet, removed. If you need the GCC compiler later on (for kernel, etc upgrades), you can just re-install it, or whatever. What I personally do (on a SSH server) is add myself (user account) to the root group (GID is 0), then chmod the compilers to 750, which is rwx for root, rx for me. I recommend, once again, not using the root account, unless absolutely necessary. Then, I would recommend that either you log the activity, or kill the history files in ${HOME}. These are the .bash_history, and also there may be a system-wide history file, depending on which distribution, etc, you use. Mostly, this is used in SCO UNIX systems. Also, you may have installed other various loggers/log parse scripts (scripts which grep the log for pertinent info, then cut it and write to another file). Now then, we need to check file permissions. All files need to be set to where everyone cannot read, write, or execute system files, logs, etc. Leave the directories (modify permissions of the actual compilers, etc in the directories, not the directories themselves) /bin, /bin, and /usr/bin alone, but make /etc to where only the owner (root) can do anything with system files. This prevents others from learning system policies, etc. Also, it helps to make your users aware of chmod permissions. Issue ls -l to check permissions, etc. Then there's the cracker risk. You could set the amount of attempts before locking of the account, but then a cracker could simply do x amount of attempts to every account, thus performing a DoS attack. This would highly inconvenience your users, so you make the call. In any event, you need to make sure your users have a minimum password of at least 8 characters, and that passwords such as "john", "password", "secret" "giraffe" are not used, not prevent dictionary-based cracking. A more suitable password would be "ihavelongpwd00". A mixture of letters and numbers is helpful, but not crucial. In the long run, it only takes more time to crack these passwords, as any password can be cracked, with enough time. You should consistently check /var/log/messages for failed logins, or issue the command: cat /var/log/messages | grep "FAILED LOGIN" Which will only output failed logins (attempts). Depending on the size of your server: cat /var/log/messages | grep "FAILED LOGIN" | more OR cat /var/log/messages | grep "FAILED LOGIN" > /home/user/attempts.txt in your profile, so that when you login, you can automatically see the amount of attempts, as a good sysadmin should. SERVICES Speaking of users and logging in, what services are you running on your system? Are you running any extra services? To find out, download nmap at www.insecure.org/nmap and port scan yourself using syntax: nmap host.domain Now, if you need the following services, ignore my advice, but I would recommend you shutting down the following daemons: telnetd ftpd fingerd talkd smtpd First, lets talk about telnetd. Telnetd enables an individual to connect to your machine, and get a nice little shell, by which they can issue commands remotely onto your machine. This is very bad. Before, I stated that users could upload c exploit source and compile it. Telnetd is how they compile it. If you have users that need to connect to your machine (like if you need to do remote administration), you need to install the Secure SHell, or SSH. SSH includes security features such as encryption to the normal telnetd, so no one, with a reasonable amount of effort, can sniff sshd packets, discovering users' passwords, usernames, etc. Now there's the fingerd. Unless you want people finding out information about your users, I suggest you kill this service as well. The finger service gives way too much information about your users, including last login time, whether they have new mail, their shell, and their real name. There is no good use for fingerd, it is also easily used as a means of penetrating your system, buffer overflow attacks being the most common. Block all access to this port. Now there's ftpd. If you need ftpd, ignore what I'm about to say, just make sure that anonymous logins are disabled, or if you need anonymous login, make sure that anonymous logins can't upload anything. Ftpd's only purpose is to copy files (exploit source anyone?) to your system. This is how an attacker would upload their source to your system to compile. Also, the service itself can be exploited, and by all means, STAY AWAY from Washington University FTP, or WU-FTP. This ftp daemon has so many exploits out for it, its not even funny. Talkd is a medium level threat. Talkd allows users to talk to one another on your system. The only threat is that there are exploits out for it (depending on what version you use, and most common exploits for talkd involve buffer overflow attacks.) Now there's the smtpd. SMTP protocol is a risky venture in itself; it enables someone to mask his or her true e-mail address, which can be annoying when dealing with spam. Also, "mail bombing" may occur, which is a DoS attack which floods the SMTP server with messages, until the server gets so bogged down, no useful activity can occur. Also, there are smtpd exploits out there, once again, the most common are buffer overflow attacks. If you don't use the smtpd, block all access to port 25. If you do need it, be prepared for the headache. Another mentionable service is httpd. Httpd is mostly secure, especially if you use the most recent version of Apache. Once again, if you don't use it, get rid of it! Updating services is crucial to system security. Always run the most recent stable version of a service/package. Older products have the most exploits. FIREWALLS Firewalls are EXTREMELY important in maintaining system security. Which firewall you use is up to you, although I recommend using AT LEAST ipchains. Ipchains allows you to filter specific behavior/traffic accros your network. I also suggest using hosts.deny and hosts.allow. However, NEVER depend on hosts.* for "security", as these can be bypassed at the kernel level. Ipchains is the kernel's means of routing/denying. Once policy I suggest you employ is to deny all ICMP packets. ICMP packets have been used in DoS attacks, and any script kiddie with a Windoze box can do this: /sbin/ipchains -A input -j DENY -p ICMP This setting denies all icmp packets directed towards your system. You may have to: /sbin/ipchains -F This rule disables ping, and traceroute, among other tools. To disable, simply flush ipchain rules: /sbin/ipchains -F If you need to traceroute someone, such as a cracker. If you offer shell accounts, some of your users may complain, but this policy blocks many icmp DoS attacks (they still can perform a DoS attack based on sheer requests for an icmp reply). UPDATING As a good little sysadmin that you are, you need to update EVERYTHING on your system, all services, the actual kernel, EVERYTHING. Refusal to do this only makes your life as a sysadmin harder on yourself. As far as updating goes, NEVER run anything that is considered unstable on any system you care about. Unstable means that there are bugs, and bugs lead to exploits. Only run stable versions of services, the kernel, and any other applications. Not only is it good for system stability, but also for security. AN ATTACKER'S VIEW The best way to check your security is to play the other side. For this, you will need several tools: COPS (I recommend TARA, a COPS extension): is a security scanner that scans for blank user passwords, duplicate accounts, incorrect values in /etc/services, and so forth. SATAN: another good scanner.... reputably the best. CRACK: this tests out your user's passwords for easy passwords. VERY important. TRIPWIRE: This is a tool that tells you if important files have been changed, which is one of the first questions that needs to be asked after a penetration. NMAP: Aforementioned, this is a good port scanner, and can be used to test your firewall against stealth scans (half-open). Other than these, subscribe to any and all security/exploit related news zines, BUGTRAQ is a good one, and 2600, although dated, provides a good insight on vulnerabilities, so you can check to see if your system policies reflect theirs. LOGS Always check your system logs. These tell of attackers/crackers, and also give insights on how your system operates (what daemons are started at boot), these can normally be found in /var/logs/messages, and are usually quite long. Check these every 12 hrs or so. For the paranoid, log every connection to your system. Every packet. Every event. EVERYTHING. Also check out /var/log/maillog for SMTP logging (connections).