View and vote on the article here: Securing a Web Server: Part 1
Securing a Web Server: Part 1| Category | | | Summary | | As some of you have noticed, zZine is taking a much more serious view of its own security by making public exactly what goes on behind the scenes. To that end, here is a small tutorial on basic web server security administration. This is only a beginner |
| | Body | The first part of administrating a server starts before you upload even a single document to your site. Very large sites, like Microsoft.com, Yahoo.com, and even CyberArmy.com are in charge of the very servers themselves. Most of us do not have to deal with that level of security. There are also volumes upon volumes of books dealing with the subject, and a plithera of operating systems and configurations, not to mention changing and evolving code, make giving such a tutorial literally impossible that would not be out of date in a matter of hours.
What I'm going to cover is security that takes place above the raw server level. We're not going to ignore that level, but as users who are hosted on servers we do not own, there isn't much that needs to be directly done in that area.
The first thing you should do before even uploading your site is to take inventory of exactly what you want to run, and the security holes that exist before you do so. To do this, you need to first find out exactly what the server you are running on supports. Many features you will want to disable first. For instance, it may sound groovy that you can run cgi, php, frontpage extensions, virtual reality worlds "wrl", Java, ftp, telnet, and POP/IMAP e-mail. But, for every feature you include or is included, there are tens of thousands of exploits that can give a hacker complete control over the server and make you're life a living hell.
The first thing is to only activate that which you want to use. For instance, if you aren't using frontpage extensions, disable it through settings, and make sure that all "_vti*" directories are deleted. If you aren't using, kill it. I don't mean just disable, but KILL! The host you are with may have some sort of page for you to configure these features, but take the initiative to find lingering entry points and eliminate them. This does not mean hack yourself, but to simply FTP and telnet to you're host space, and go through to find files that the admin control page may not have picked up.
After doing that, you are still not ready to upload any documents. More than likely, you will have your own access accounts for FTP, e-mail, and telnet. These are actually the most vulnerable points. Make absolutely sure that you're password is impenetrable! If allowed, it should be at LEAST 8 characters. This is not you're ISP e-mail we're talking about. Once you start hosting a webserver, you are actively advertising yourself to hackers. You password should at a minimum included letters and numbers. The result should not be readable by ANY dictionary file. For instance, you would assume that "password" is in every dictionary file ever made, and the first thing a hacker will try. Unfortunately, this is actually the default password with many hosts, and admins never change it. These admins are fools, and won't keep their site more than a few weeks (if they aren't very popular). Good hosting services will force you to use long passwords, consisting of at least letters and numbers, and even better ones (like my college account) won't let you use any consecutive characters either, also check you're pass with their own dictionary list, and make you change it frequently.
Now, if your's doesn't or even if it does, it's up to YOU to have a good password. So, in our example, you simply can't use "p4ssw0rd" and assume that it's now unbreakable. Many dictionary brute crackers will also try several word modification techniques. The key is, if you thought it up, it's crackable. Also, do not use any random sequence password generators. Not many people know it, but some of these programs generate passwords based on a limited algorythm, which means that while they appear to be random, they are actually very limited, and many good hackers have lists of known sequences, and even write their own sequencers to "plant" bad passes.
So how do I create a truly unbreakable password?
The short answer is... you can't! But, you can make it so hard that the likelihood of of a hacker getting is nearly impossible. First, don't just randomly pound your keyboard, even that act creates commonly hit key sequences. What you must do is start with an out of this world 3 or 4 character sequence. Use lowercase, uppercase, and/or numbers. One seqence might not have a number, or no lowercase, or no uppercase. Another might have all three. NONE SHOULD ONLY HAVE 1 OF THE 3! Create 3 or 4 of these sequences, making the pass 9-16 characters. If it's too large, only use the maximum (usually 10) by taking the first 10 characters.
So, now you've got an unbreakable password, so you're now safe, right? Wrong. if you use this password for years, you might be lucky, and stay safe... or maybe someone will intercept an old e-mail with the pass in it, and hack your site when you least expect it. At a minimum, you should create a new password every 6 months. If you really want good security change it every month. now, if you have many admins, like zZine does, this isn't easy to do. Here, we try to enforce a 3 month policy on all accounts. An admin who doesn't change their pass within a week of request get's deactivated. Admin's with super-user access are not allowed to pick their own pass, but have them generated by us. With the root pass to our account, it is changed monthly.
Ok, I've got a secure password, and I change it frequently, now I can upload my files, and be hacker-proof?
Security isn't something you do in five minutes every 6 months and forget about. Before you upload your files, go through them. Go through every file, every page, every script, every peice of code. Every format you use has an exploit. To give you an idea, let us go through zZine as if it were just being uploaded for the first time.
zZine mainly uses PHP and SQL. Frontpage, ftp, and such have already been disabled. A solid password policy is enforced. So, what we have to look at next is the structure. Each PHP script we upload is a possible gateway for hackers. Some people assume that if a script is exploitable, a hacker can only corrupt that script. In truth, a hacker rarely cares about the script they exploit, because in fact, they are using it as a gateway to the rest of your site. They will use it to steal accounts, run malicious code on the server, deface the site, or gain root access.
What we have to do is first research all of the scripts. If you are writing your own scripts, then you are a lot more insecure even than if you simply used known exploitable scripts. The reason is that only an exceptional expert could write an unexploitable script. Even if you don't make any mistakes, the script itself could be insecure by nature. Let's look at an example:
I write a script that does "news" posts. To write it, I have the let the script write files to the site. It uses a variable file that keeps track of the last file, and adds to it on every post. Like: 1.html, 2.html, 3.html, etc... The variable I use is easy to remember, so my coding is easier, like $postnum. It's a very small script, so it should be very easy to spot any holes. I've written it very well, and it appears to run flawlessly in tests. However, a few days after I get hacked because I made many mistakes that aren't flaws in the script. The hack is posted on a security site as:
http://www.mysite.com/news.cgi?postnum=".htaccess"&post=""
Using my simple, flawless script, a hacker used it to wipe out my .htaccess file, which controls all authorization to my site. It's that simple.
I can't go into how to write secure scripts, that's another tutorial altogether. What I will say is that it's best to use widely used scripts. zZine uses PHP-Nuke. This script structure is actually known to be insecure in many areas. So why do we use it? It's simple, really... exploits are quickly posted to security sites and newsletters, often with patch information. The zZine staff watches these sites and subscribes to all prominent security news letters. As soon as an exploit if found, we patch it immediately. But, we also go farther, and examine our own scripts and try to hack them. All of our top admins are also top hackers at CyberArmy. CHiCoSTo and I (Goliath) are by no means expert hackers, but being in the top .1% of all hackers at CA does help. On zZine, we use our skills to secure ourselves.
Many people think that CA trains people to hack. In fact it does. And, I will go even farther to say that more people need to learn how to hack. A site admin that does know how to hack is lending themselves to be victims of hackers. It's like gun control... if everyone had a gun, there'd probably be fewer muggings.
So, if you run a site, subscribe to security news letters, frequent security exploit sites, and basically keep you're ear to the ground. Also, frequently check back with the site that wrote the script, and actively search for exploits. Another tip for non-experienced admins is to not use the latest scripts. There are two schools of thought on this. One says that you should only use older scripts where all known exploits are already found and have patches. The other says that by always staying with the latest, you can stay one step ahead of exploits. The factor really depends on how often you admin the site scripts. If you have the time, you can stay with the most current scripts, but this means a lot more time going over them for exploits. If you don't have the time, you should use versions that are a little older, and apply all of the patches.
Ok, I'm learning to hack my scripts, not using home grown scripts, and applying all known patches, can I finally upload my site?
Ok, ok, you're almost ready, but not just yet. Remember that I mentioned .htaccess files? Now you have to create those files. An .htaccess file is used on 99% of servers to restrict access(except those with FrontPage set up). An associated file with this is the .htpasswd file. This contains all accounts that can be authorized through .htaccess settings. Basically, .htaccess controls file permissions, and .htpasswd can be called to authorize a login. Note: .htpasswd won't be used unless called by the server itself, or an .htaccess file. On some server's this is very tricky to get the settings correct. I'll leave it to you, the reader, to find resources on creating and maintaining these files. Juat a few words on these files. You must set their "permissions" (see Unix CHMOD permissions at you're nearest search engine). Set them so that they are only readable by the server, not by the entire world. A readable .htpasswd, even though usually encrypted, can easily be cracked by hackers, and will probably give them root to your account. The same goes for .htaccess, which will usually give them valuable info on what you are trying to protect.
G*DD*MN IT! CAN I UPLOAD NOW?!?
Yes, my little gringo! Upload to your heart's desire! But, don't think you are even near done; you are only just beginning. But, now you have a good base of security, and an idea of what areas you are exposed to. Unfortunately, this ends the first tutorial. In the next tutorial, I will explain how to maintain security, how to spot hackers trying to break in, and some very groovy tricks for keeping them out (giving yourself methods for being notified durring attacks even if your host doesn't provide you with the tools and becoming a Security Samurai!)
-Goliath |
|
This article was imported from zZine. (original author: clickman)
There are no replies to this post yet.
|