u l t r a m o o k i e

So, it’s interesting to see that my machine was broken into around September 19, 2002. It wasn’t the first time that a machine of mine has been broken into — it’s probably the third or fourth time in the three or so years that I’ve had a machine up on the Internet. When one puts a machine up on the Internet, they are just begging for someone to break into it because, like a house or a car, if its there and nobody is watching, someone will definitely try to break in. Here are some things that I found while rebuilding the UltraMookie.Com box that concern security.

The safest box is one that has no network connection, but even then a physical attack or local attack is quite possible. But, I’m not interested in discussing that aspect. This last break-in was significant because of the results. First, this was the first compromise that actually took down the network that my machine was on; this was my entire fault — explanation later. The second is that this compromise yielded a call from the FBI. The call from the FBI was totally unexpected, especially when one takes into account the small operations of the UltraMookie.Com box: email for less than ten people, a website that yields less than 100,000 hits every six months, and no other services.

What I learned from this experience is a lot. I’m sure that this is all basic stuff for some UNIX security people, but I’d like to share it with others “just in case.” The first and most important thing to remember is that if your machine is compromised the first thing you should do is take it off the network and turn the thing off. Don’t worry about email or lost web hits, if you don’t remove the machine you take a huge risk. I didn’t take my machine down immediately and I suffered. Here’s what happened. The intruder was able to replace some important binaries on the machine. They were also able to add an account and also take the password file. They were able to lock me out of any access to the machine – I’m sure that they had a backdoor setup for them self. Logs were trimmed and evidence erased — though as I found out later, they weren’t careful enough with covering their tracks. My machine was then used for other attacks; presumably that was what finally took the network down and what prompted the FBI to give me a call. So, if your machine is compromised, take it down immediately. The time lost upfront will save you a lot of trouble in the future.

But, let’s try not to let our machines get compromised in the first place. Here are some security measures that I’ve found that will hopefully keep my (and your) machine a bit safer. The first thing is diligence. If you aren’t willing to put up the time to properly manage your machine, don’t bother putting up your own machine and just get service from someone else (for instance if all you need is web hosting go pay a dedicated web hosting company for disk space and bandwidth — let them worry about network security). To manage your own machine means that you’ll have to be anal about network security. You’ll constantly have to monitor it. There are automated things that can be setup, but there is still a lot of stuff to be taken care of by you.

I’m only concerned with Red Hat Linux in this article, but most of this stuff can be adapted to be used on other UNIX-like systems. There are security advisories that are given and one has to keep track of these. A good place for this is [url=http://www.cert.org" target="__cert]www.cert.org[/url]. Sign up for the mailing list.

Red Hat also releases security related advisories and fixes on the website. If you want to use Red Hat Linux let me suggest a smart way of spending your money. Don’t run out and spend the sixty dollars on the boxed version of RHL if you don’t need tech support or thin printed manuals. Instead, download the ISO images from redhat.com and burn yourself a copy of it — find (or make) a friend with broadband and have him download it for you if you don’t have broadband access. Take the sixty dollars you just saved (minus the few cents for the CD-R media) and go to rhn.redhat.com and get yourself an annual subscription to the basic [url=http://rhn.redhat.com" target="__rhn]Red Hat Network[/url]. This will allow you to have priority access to all the errata downloads that Red Hat provides. The updating of your system is automatic (with Red Hat’s up2date utility) and you’ll always be informed of what’s new. The boxed version of RHL comes with only 30 days of Red Hat Network trial access. The way that the criminal compromised my system was that I didn’t have the latest version of sshd running on my system. This allowed the criminal to exploit a vulnerability in the old ssh 1 that I was running (look for crc32 and ssh on Google to find out more.) This came to be two-fold: first I was lazy and didn’t keep up with security advisories and also because of that I never upgraded the sshd I ran.

Every place is a bad place. With Red Hat Linux 7.x there is xinetd and tcp wrappers these work to keep you services safe. Basically what they do is start up the wrapper application to check an accessing host before actually starting the requested service. So, for instance if I only let the host goodguy.ultramookie.com access the ftp service this would take place if a host tried to ftp into the system: host requests ftp service and tcp wrappers gets the request. The host name is checked with the list /etc/host.allow and /etc/hosts.deny. If the host is listed in hosts.deny then the connection is refused. If the host is listed in the hosts.allow file then the ftp service is started and the host is allowed to connect. Usually, and I recommend this, the hosts.deny file denies all hosts (with the entry ALL:ALL The first ALL meaning all services and the second ALL meaning all hosts). This will allow us to limit the connections to machines that we know, and we list these machines with the services in the hosts.allow file in the same format that we used in the hosts.deny file. Use “man hosts.allow” and “man hosts.deny” to find out more about this way to lock systems out of your network services. Talking about services: Less is more. If you don’t need the service, then don’t install it or turn it off if it is installed. The more services you run, the more risk you put your system at.

I didn’t know which files were compromised during this last break-in. I had ran the program Tripwire before, but for some reason I had turned it off. What Tripwire does is it creates a database of binaries that you have on your system – you create the policy for which binaries get monitor. It also keeps track of other files (like configuration files and such). The database that keeps track of all these things is encrypted and is password protected. If there are any modifications to the system, then you will be notified when the report is run. Tripwire is in the Red Hat 7.x installation, though I don’t think that it is installed by default. Look for it when you install Red Hat 7.x and install it. The Red Hat 7.x installation of Tripwire includes a policies file that is optimized for use with the Red Hat 7.x OS install. Just run /etc/tripwire/twinstall.sh first. This will allow Tripwire to establish some initial stuff (like passwords for the database). After this is done run “/usr/sbin/tripwire –init” and this will setup the initial database. Red Hat 7.x is setup to run a Tripwire report every morning and the report is sent to the root mailbox.

Go to [url=http://www.psionic.com" target="__psionic]www.psionic.com[/url] and download PortSentry and LogSentry. These two programs are very useful for keeping track of all the activities that are happening on your system. PortSentry actually watches the different ports (that you specify) on your system for strange activities. For instance PortSentry will watch for portscans or access to a specific port, when this happens, an email is immediately sent to you. If it continues it will send an email letting you know that there is a possible hack attempt on your system. This is very useful real-time prevention of system break-ins. LogSentry is run once a day (or whatever you set it to in the cron job). It goes through your different logs and picks out pertinent information – such as strange activities, login counts, etc. This is very useful because it’s hard to monitor the logs all the time to find strange activities.

Anyways, those are just some of the stuff that I learned from this break-in. I hope that they were helpful. I’ll be continually looking out for more stuff that can help increase security and when I find some, I’ll post it.