Screaming Penguin

I recently have had a great deal of experience with Linux security issues after having a machine compromised through a common BIND exploit. I admit that prior to that incident security was a concern of mine, but I was not thorough in measures to secure and monitor Linux systems, I simply assumed that there were far easier targets than Linux and that using Linux alone was a good security measure. I was naive and incorrect. While I am not a security expert per se, I also am not generally non-security conscious. I have implemented several VPNs and firewalls on commercial systems and consider myself to have fairly extensive security knowledge and experience. After the experience of a firsthand malicious and destructive attack on a Linux box I am much more wary of Linux security issues. Therefore I decided to get serious about Linux security, here is the result of my research. First of all some background information is important. This document is intended to be a simple but effective security setup for a small implementation, be aware that security encompassess many more aspects than are covered here. This is the quick and simple howto and this document should be considered just that, a basic starting point, not a comprehensive solution. The machine I intended to build and secure was what I call a "network services" server. I refer to network services as services that will be used by other user hosts on the network. These include routing (IPCHAINS), Sendmail, DNS, DHCP, NFS, SAMBA, HTTP, FTP and the like. All of these services have their own security considerations and directives, the details of security for each of these services is beyond the scope of this document, but should it should be noted that each service must be carefully implemented with security in mind. Each service is another potential point of entry or exploit vulnerability on your system. For a secure system you must first select the "custom" installation routine and install on a "clean" machine (a clean machine is important, never simply "fix" a system to make it secure, start over with a formatted machine.) Regardless of distro, select custom and pick ONLY the exact services you need. In my experience selecting very minimal services, basically only the kernel features you want is the best. I generally do not install any major application software packages that come with a distribution, simply because they are usually out of date by the time of install. Install the latest distro of your choice with minimal applications and the kernel features you require (IPCHAINS, etc.) Then once your install on a clean system works CHECK FOR UPDATES, go to the respective website for your distro and make sure all of the latest patches are applied, even for a brand new distro. Lets get to the business of securing the box. Here is an overview of the major steps in this process (again note that this is a simple security setup for a small implementation, there are many more aspects to security and this document should be considered a basic starting point, not a comprehensive solution.)

MACHINE: Setup a clean machine with minimal services and configure IPCHAINS

SERVICES: Secure the master inet and each other service you are using

ACCESS CONTROLS: Setup TCP Wrappers and Portsentry to keep an eye on usage

MAINTENANCE: Monitor the logs regularly and keep up to date with patches Specifically for this document I am setting up a RedHat 6.1 box that will be a firewall-gateway via IPCHAINS, will run FTP and will run SSH (Secure Shell.) This box will first be setup as the firewall host for a small network using IPCHAINS and then each service, FTP and SSH, will be configured. MACHINE Starting with a clean install (as mentioned earlier) setup a the machine with multiple network cards (this is obvious, but must be noted.) One card for the Internal network and one card for the external network. Setup the cards so that one uses a private network space for the internal network, 192.168.200.1 for example, and one is the Internet IP address provided by your ISP (often via DHCP for DSL or cable modem connections.) Once you have both network cards working as required (specific setup of networking is beyond the scope of this document, for more info see the Linux networking howto) make sure you can communicate with the outside network and with the inside network, ping a few hosts on each. Make sure DNS is working correctly, a local caching DNS can be helpful also, however you setup DNS make sure you test it (again, setup of DNS is not covered here, see the DNS howto, or the great Oreilly book, DNS and BIND.) With a machine correctly configured and on the network, we can begin the firewall-gateway setup. IPCHAINS is used to translate internal network addresses into external addresses and allow traffic through the gateway host to the outside, and vice versa. This simple setup does not protect any sepcific services, but it does hide the identity of your internal hosts while still allowing transparent traffic. It also makes the only point of entry into your network the gateway host, which is where security can be concentrated and monitored. IPCHAINS super-mini howto (for more infor see the actual IPCHAINS howto): /sbin/modprobe ip_masq_ftp /sbin/modprobe ip_masq_irc /sbin/modprobe ip_masq_quake /sbin/modprobe ip_masq_user /sbin/modprobe ip_masq_raudio ipchains -P forward DENY ipchains -A forward -i eth0 -j MASQ echo 1 > /proc/sys/net/ipv4/ip_forward The first section of these commands enable the modules for special ipchains rules, these include FTP, IRC, QUAKE, USER and REALAUDIO. These are the obvious and essential services, right! The deal is that IPCHAINS can handle pure traffic like HTTP no problem, it needs help with services that require dynamic port remapping, such as these, these are the already written and configured helper rules, they handle most all major services and make life easy. The next section gets into the guts of ipchains, briefly. IPCHAINS uses three "chains" to define rules for traffic, input, output and forward. The line "ipchains -P forward DENY" -P is policy, this first rule sets a blanket policy that nothing can be forwarded, nothing, this makes sure no other rules override. The next line "ipchains -A forward -i eth0 -j MASQ" sets up the special rule whereby internal clients can do whatever they want, the -A appends a rule to the forward chain, the -i means the interface, in this case eth0, which is the external interface, then -j means jump to the special funtion MASQ, which is masquerade. What this does is allows any traffic sent to the external interface to be masqueraded as the interface and passed to the external network. With these simple lines you have a basic firewall that is very functional. Of course there are many more functions of IPCHAINS and this is a very BASIC setup, but that will accomodate many a small network. Thats it. This makes our new host a firewall-gateway to the internal network. If the internal network hosts use this host as a default gateway, then they can communicate to the outside network. Note that another neat feature is setting up DHCP on this host, the gateway host, (this requires you do a few things special such as bind to only the internal address as a DHCP server, but it works great, with a correctly configured DHCP server here, with options such as domain name and gateway setup, all your internal hosts only have to plug in, then they get an IP address assignement with all the correct options from the DHCP server-gateway host and they can connect transparently to the outside network, DHCP setup is alsp beyond the scope of this document, but it can easily be done, see the DHCP howto for more info.) SERVICES Now that a configured firewall-gateway host is ready, your internal network has connectivity and is protected, but you still need to secure the gateway itself further. Now check the master inet daemon. View and edit your inetd.conf file (generally /etc/inetd.conf.) Disable all services except for exactly what you require. My reccomendation is FTP only (and I prefer ProFTPD, check proftpd.org, proftp is easily configurable via directives in a configuration file, it is also easy to chroot all the FTP users.) . Yes, you read correctly, FTP only, I would not recommend telnet at all, usage of SSH (secure shell) is preferable to telnet (I will get to SSH.) I recommend that FTP be non anonymous and limited to non privileged accounts. All FTP users should be chrooted into their home directories and no priveleged users should be allowed access (again, this implementation depends on your flavor of ftp daemon, generally a set of files or file controls access, never allow root FTP access, only allow FTP access for specific non priveleged users, see the proftpd note above.) FTP is a clear text service, so assume that each FTP allowed account could be compromised, if they are all non priveleged accounts even if they are compromised that should not be a major issue. Disable all services such as telnet, rlogin, rsh, linuxconf, etc. Either rem or remove each respective line for services you do not want. Then make sure you restart the inetd daemon. To do this, find the PID for inetd and reload and restart it (to find it: 'ps aux | grep inetd' to restart it 'kill -1 PID'.) With all services disabled from inetd, except for securely configured FTP and or exactly what you need then move on to the replacement for telnet, SSH. SSH uses encryption (various types, that is configurable) to secure remote shell sessions, telnet is clear text, telnet is not secure at all. Go to http://openssh.com/ and get the files, then install (install is easy and is covered in the installation instructions on the site, there are even RPMs.) OpenSSH provides an SSH server, sshd. This SSH server allows clients with special SSH client programs (of which there are many free, even for windows clients, check out http://freessh.org for more infor on the clients) to connect and run a remote shell similar to telnet, only SSH is encrypted traffic (the encryption methods vary, see the install instructions.) SSH should be run standlaone if you expect many connections, if you expect only a few you can run it as an inetd service with the -i option. Install and test SSH, get a client and try it, it is easily configurable and works great. In my case I run ONLY FTP and SSH from the master inet daemon, inetd. I also secure the service run by inetd using TCP Wrappers. That is covered in the next section. ACCESS CONTROLS TCP Wrappers is a program that is used by the master inet daemon to authenticate and keep an eye on users that connect. Wrappers is easy to setup and is generally included in most distributions, in fact if you are using redhat it is already setup. A wrappers line in the inetd.conf looks like "ftp stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/proftpd" tcpd is the wrappers program that checks each request for each serivice it is configured to protect and then runs that actual service if the connection is allowed. Wrappers uses text files named 'hosts.deny' and 'hosts.allow' to check just that, which hosts are allowed. The 'tcpd' server is run in front of each service checking the requests, if they are explicitly allowed or denied, they are respectively either passed to the actual service or denied. Its a simple concept that works well. Note that I reccomend putting the SSH server, sshd inside of a TCP wrappers conenctions as well. That makes 2 services configured thus far in inetd.conf, FTP and SSH. Next we setup a program called 'Portsentry' that is a key element in the security picture. Portsentry is an "active defense system" for UNIX machines. Portsentry detects any and all types of port scans, which generally are a sign of trouble and possibly impending attack. Then Portsentry acts based on options you choose to defend the system. Portsentry uses either or BOTH TCP Wrappers and IPCHAINS to defend the system. The concept is that if a host (any host) runs a port scan (tcp or udp) against the gateway-firewall host then the host automatically kicks out the potential intruder bt denying access via wrappers and dropping the route back to the host via IPCHAINS. Portsentry is very efficient, it detects scans, logs all activity and then uses commands to drop the attacker into a black hole, it works great. Portsentry uses IPCHAINS with a "KILL_ROUTE" variable as such: 'KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY -l"'. This command takes the attacker, $TARGET$ and drops them into DENY, effectively disallowing any further traffic. Portsentry can also logs the incident and can be configured to page the adminsitrator. Portsentry can also be told to always ignore or always kill certain hosts and Portsentry is easily configurable with many options. Take this advice, if you put a Linux box on the Internet, use Portsentry. Get it and further info on it from Psionic, the company that makes it freely available (http://www.psionic.com/, psionic also makes some log monitoring utilities that are worth looking into, great stuff.) MAINTENANCE Once you have the gateway-firewall host secured, that is with minimal protected services including but not limited to IPCHAINS, FTP and SSH and TCP Wrappers - Portsentry configured then you have to maintain your reasonably secure machine. It is mandatory that you check the logs for the system and all services regularly, many services can be configured to log to the syslog, making one convenient log location. Check it, know what it means. Then always make sure that you check for updates to all packages you use, distro and or otherwise. Often the most commonly used exploits are successful because an administrator did not update a package with a known problem (as in the case of my BIND situation, DOOOH!) That is a basic, secure system. All of the items mentioned herein are easily configured, this is a minimal secure system, there is certainly more to security than this article has covered, but these simple measures will stop many intruders and eliminate many problems. Sidebar: Note that this secure system can easily become a web, mail, samba, nfs and or whatever else server as well. I generally restrict the use of NFS and or SAMBA to internal machines only, for obvious reasons, however they can be setup on the gateway host and configured to only communicate with the interanl network via the internal adapter. Also, sendmail and or apache can live on the gateway box as well. Each of these have many security considerations of their own to consider (beyond the scope again, I know, its getting old, but trust me, its true, get the oreilly respective titles for info on these popular programs.) While these services can be configured and secured on the gateway host itself, a better solution is to run these services internally and then bind the particular service port to the gateway host, again using ipchains. This is a bit more complciated use of ipchains, but not to difficult and works great, that way these services are secured and distributed. There is a lot to consider in the security picture, while this article is not comprehensive by any means (not intended to be) it hopefully may help with basic measures and or provide direction to find further resources on security. Good luck out there, even with the best security, you may need it.   freessh