Whether it’s home based or corporate, you want it safe!
By Red Squirrel
I just can’t get over the fact that so many corporate servers were hit with the SQL slammer which hit January 24-25th and took a while to fade away. In fact, our very own server has been setup to monitor the activity of this worm directed at us and there is still an occasional hit.
When something like this happens, you can blame the company who made the software which is insecure (in this case, Microsoft SQL server), you can blame whoever launched that worm in the wild, or you can blame yourself. Fact is, most will go blame Microsoft right away. They did play a big role in this worm, and mostly have something to do with most other worms, but in this case, it could have been avoided, as Microsoft had released patches. One thing when you run a server, especially when you are depending on software from a company that has a bad security reputation – DO the updates and DO install any released patches. Patches are Microsoft’s dirty way of archiving perfection, but at least do THAT, to help.
Not only Microsoft products have bugs that allow viruses through, but their products are the worse. For example, Microsoft IIS HTTP server can easily be crashed with a packet of less then 1KB sent to it.
If you like keeping up with installing patches, and being informed of new security holes, go ahead and use the Microsoft products for your server, but you’ll be spending lot of time to install patches that way.
Choosing decent server side software
If you have more time on your hands to learn the more complex software, go and run open source GNU licensed software, such as Apache HTTP server, MySQL for your databases, and PHP for scripting. These 3 programs well configured are very powerful and solid. With no patches or any updates installed, our server survives some of the worse case scenarios for Microsoft based servers! In fact, I don’t even think there is updates for these software other then new releases. These software packages are perfected BEFORE release date, which makes them ideal for productivity use. Also, you will save yourself thousands of dollars. The downside is that most of it is harder to learn at first, but it’s well worth the time investment, the internet is full of good resources on Apache which, as simple as it looks, is a very configurable server.
The operating system
Another security issue is the operating system you use for your server. However, the server software itself has a bigger impact, but it does not help to be running it on an unsecured operating system such as a clean install of Windows 2000. For networks, Windows 98 is in fact more secure, as it does not have too much of what Microsoft likes to call “features”. Windows 2000 has over 30 network-related “services” that runs by default and are a pain to kill off, including Netbios, which shares your entire hard disk by default! If you unshare it, Windows goes and shares it back sometimes when you least expect it! We at IceTeks are in an infrastructure situation where we can’t change the OS, but as soon as we can, we will be installing a Unix based operating system. Unix based operating systems are the most widely used operating systems for servers. Most are also open source, including Linux Red Hat, which is probably the most commonly used. However, the downside is it’s ease of use and configuration. However, if you take time to learn it, it will bless you in the future.
If you don’t plan to run one of these, get your server off the net! Whether it’s a home server or corporate, you should have at least one firewall that is decent. Make sure it has the ability to block specific IPs/ranges, and also specific ports and applications. Basically, a firewall on a unsecured Windows 2000 installation can secure it well. You can make sure all ports are blocked, in exception of the server ones. For example, if all you are running is a HTTP server, you should only allow traffic to connect on port 80. Also, you will run into situations where someone is illegally trying to gain access to your server – with your firewall, you can simply block that IP address.
Knowing what’s happening
As secure as a server can be, if you give a script kiddie unlimited time to try something without you knowing, eventually there should be a way to get in, or cause damage otherwise. Hacking into a server does not only consist of “getting in”, but can be various things, such as DDoS (distributed denial of service attacks, will be discussed later) or simply getting past validation on a BBS for example. It may be hours, days, or even months, but it’s best not to wait and see! Something most server software has is logging, which is simply what it says it is: logs. It keeps information logs of who gets what, and other info. For example, if you typed keywords in Google and found this page, from our logs we can know who you are (as in, your IP address), where you came from (full address, which includes the keywords you typed) and we also know the time this document was accessed. Let’s say this article showed you how to hack into a server, and that later on in the log it shows an attempt from the same IP, we would easily know that you came here from google by typing “how to hack computers” (just an example of keywords), that you read the article, and waited a bit and tried it on our server. If we wanted to, from there we could get more information on your IP using trace route or another tool and then contact your ISP. Now that I told you this don’t be scared to have your privacy threaten! We have policies to not show logs with the IP, logs alone will sometimes go to third parties (such as admin forums, asking what a certain request is, for example) but never with the IP address. Every site you go to, or at least, most sites, log this information as well.
What about other protocols?
We are mostly talking about HTTP here, but logging goes for ftp as well, and any other type of server should have logging. If it does not – I don’t recommend it.
It’s nice to have all this information on people who access your server, but it remains useless until you actually see it! Make it a daily routine to check your logs. From this, you also get good information on where your visitors come from, and also if others “hotlink” your images. If you are concerned about others linking directly to your images, it’s good to check your referrer logs for unknown addresses. Also, it is good to “rotate” your logs regularly, by this, I mean closing the server, renaming the log file with the date, and restarting the server, that way you have many small log files instead of trying to find yourself in a log several gigs long!
Type of attacks
There are many type of attacks that script kiddies like to do to servers. Here are a few that are common:
DDoS: This stands for Distributed Denial of Service attack. This is when the script kiddie will spoof his or her IP address to make it look like several hundreds of other servers are requesting data. This will cause your server to respond to many faulty requests. Depending on your connection speed, your server will sooner or later time out and cause errors because of too much bandwidth usage. This can also be done in reverse where spoofed connections are made to many other servers making it look like yours, which will then receive all the responses. This is all done by simply manipulating packet data and can easily be done by the experienced. There is not much you can do about these as your server is simply doing it’s job. The best way to avoid them is to notice them, if you notice a big slowdown, look into what is causing it. Sometimes it’s just a busy night, but sometimes it could be an attack. With all the attacks our own server got in the past, we never received a DDoS, which comes to show that for smaller servers, they are pretty rare, but still possible.
Password crack: If you have any scripts such as a forum, or even basic authentication, this is a form of attack that can be done using “dictionary attacks” which keep guessing the password over and over. Sometimes it can be insecure scripts which make it easy to gain access to information. These attacks depend on what exactly is being attacked.
Miss configuration attack: There is a wide variety of things that can be done simply due to miss configuration. For example, if you have a public FTP and allow that directory to be accessed via HTTP. A script kiddie could program a script, upload it there and run it via HTTP and do what he desires, including getting password information from authentication folders, by requesting the .htaccess file, then the password file (I hope I’m not giving ideas to script kiddies here...:}). Or something as simple as an ftp server sharing your entire drive with write access could lead to problems. Basically, it does not matter what software you run but rather how you configure it. The best thing to avoid such an attack is to use common sense, and every time you change or create a setting, ask yourself how it could be abused.
Security exploit: This can be anything from bad, buggy software (Microsoft comes to mind…) or simply outdated software that is not supported anymore. Some script kiddies simply look for security exploits in software, create a worm for it, and release it in the public where any server with this exploit gets infected. The code red worm is a great example. It attacks IIS servers which is a Microsoft server that is full of security exploits. The only thing to get around this is to use decent software for your server needs, and keep up with updates when there is some.
There are many other type of attacks, but these are mostly the main ones, and the easiest to get around, maybe in exception of DDoS attacks, which can however be blocked before they cause too much downtime.
Hopefully now you have a better understanding of server security. To summarize how to have a secure server, here is the steps you should take:
Simply following this has helped our own home-based server stay secure and keep script kiddies away, and I hope it will help yours as well! If you simply run a home network, you’d probably be more interested in our home-based computer security article, but if you run a home server for your own purposes, it can still apply.
However, it does not matter how hard you try, there’s always ways script kiddies will succeed, but if you are capable of tracking them down and reporting them, you still win.
I hope that you enjoyed this article, and that you learned something new out of it!
- “Red Squirrel”, IceTeks senior administrator
This site best viewed in a W3C standard browser at 800*600 or higher
Site design by Red Squirrel | Contact
© Copyright 2017 Ryan Auclair/IceTeks, All rights reserved