Defenses Against Hackers by Roy Troxel

We’re not talking about script-kiddies here. You know, the fourteen-year-old kids who can slip little programs into you server that leave obscene messages on your web site?

We’re talking about dedicated criminals, mean-spirited ex-employees, organized crime – these guys are going after the big enchilada. They want to take down defense systems, banks, brokerages, and corporations. These are the kind of guys that hacked Amazon and Microsoft.

They’re also the kind of characters that divert electronic funds transfers.

Or maybe they work on a smaller scale. Maybe they just go after small business. If they go after enough of them, then they make money. One thing they all have in common is patience.

In this article, I’ll try to explain briefly ( a few sentences) how various hacking methods work so that you can learn to recognize them. For the more technically-minded, I’ve included several web references that contain more detailed explanations. Please remember that the methods you use to locate hacking attempts on your system are similar or, in some cases, identical to the methods used by the hackers themselves. But that’s how you catch the crooks sometimes: determine what their methods are, and then proceed logically as they would, step-by-step.

Sources of Information:

So how do you defend yourself against such attacks as Denial of Service, spoofing, sniffing, and password theft. This article is intended as a guideline to several methods of protecting your servers. There are other more detailed sources, such as “Counter Hack”, an excellent manual on hacker defense strategies by Ed Skoudis, as well as the following websites:

I’ve tried to limit the site references to “safe” ones. There are numerous sites on the ‘net, set up by and for hackers. Professional security experts often visit these sites to download hacker software. Don’t do this unless you have taken a number of precautions. Many of these sites will record the IP addresses of all visitors, and these aren’t the kind of people who should have that kind of information! If you’re interested in investigating these sites, or even downloading their software to become familiar with hacking methods, set up a separate “lab” network and use a different ISP than you use for your professional network.

Let’s now discuss the number one defense against hackers:

Plug up Those Ports!
We all know what ports are, right? Those spaces in computer programs set aside for input and output of data. The operating systems Windows NT and 2000, for example, each have 65,535 ports. They are used by Windows to perform numerous tasks, most of them invisible to the user. Some of the ports however, are visible to the user, and are called “well-known” ports. For example, the default port for the HTTP protocol is 80. For example, if you’re running MS Internet Information Server as your web server (or, for that matter, Apache), then you will probably use port 80 for the input and output of data to your site.

Now, there’s nothing that says some hacker couldn’t use that same port for input and output of data, only in the hacker’s case, the data could be a virus or a Trojan Horse. (We’ll discuss the ways that this can be done later.) One defense against someone entering your server through port 80 is to run your web site from a port that is not “well-known”, like, say, port 5555. If you do this however you will have to notify your visitors to enter your site through that port. So the URL would look something like this:

Now suppose you aren’t running a site on your server; i.e., you’re just using it for a gateway. In that case, there’s no need to have either port 80 or the HTTP service running at all! So, just shut it off. The same goes for FTP, Telnet or any other service that you don’t really use.

Protect Passwords, Logs and Accounting Files

If hackers can reach the files and folders containing your users’ passwords they can be copied (by FTP or Telnet, for example) to the hacker’s PC and then decoded. A similar situation exists with accounting files in which file permissions are set (give name of file in UNIX and Windows), and logs which record the files that users access or services that the server runs. All of these tidbits are pieces of a puzzle to the hacker, enabling him to build a total picture of your network.

This defense here consists of initiating a strong password policy for your users and making sure, via memo or email, that users are aware of the dangers of password cracking and should follow the policy to the closest letter. The more sensitive the information the users work with, the more stringent the policy should be.

Hide the password database:

This is located in the \SYSTEM32\CONFIG directory of the Windows 2000 server. In UNIX or Linux it is in /etc/groups or /etc/passwd.

Conduct your own password – cracking tests with software like L0phtCrack. This can be purchased at the following site:

Other authentication methods, like voice recognition or security cards, can be used for highly confidential information. Or you can store your password files and logs on write-once CD-ROMs.
Make your important files difficult to find, using the .htaccess directory. (UNIX machines do not see files or directories preceded by a dot.) (Hiding files works both way, of course. Both the attackers and the attacked can hide files. If you think that hackers have left hidden files on your servers, use file-integrity checking software to locate hidden files.)

Windows’ checks and balances:

Like the US legal system, Windows NT/2000 security is based on a system of checks and balances. NTFS file properties, user properties and account properties can override each other, if not set properly. This can create confusion in the mind of the systems administrator: “Why am I denied access to this file, when I know it’s part of the Administrator group?”
Well, it’s because the file properties themselves are set to “Access Denied”, and that overrides everything else. “But how did THAT happen??” Well, someone hacked into your system and changed the permissions!

Conclusion: Permissions for Users and Permissions for Processes must both be monitored.

Beware of Denial of Service (DoS) attacks!

Denial of Service attacks have become very popular with hackers during the past few years. They’re relatively easy to perform, for one thing. The most basic kind of attack consists of repeatedly pinging a server’s IP address, until the server stops under the burden of having to reply to so many requests.

A more sophisticated form of this attack includes the creation of “zombies.” These are servers or workstations that have had special communications software installed on them, by stealth. The software enables the hacker to communicate with machine and order it to begin executing pings to a specific server.

Let’s suppose that the hacker has created a team of zombies by installing his communications software on eight servers, located on the internet. He now has eight servers at his command, and when he executes his order to each server to begin pinging, say, a server or servers on a large corporate network, you can bet that they will come down very swiftly! And, because the attacker has used servers randomly located on the ‘net, it will be difficult to find the perpetrator of this attack.

There are several lines of defense against DoS attacks, but they can be expensive. You can purchase wider bandwidth from your ISP. This can extend the length of time it takes for your server to crash during an attack. Or, you can sign up with multiple ISPs and create redundant paths to them from your server(s).

The second line of defense is simply to have a rapid incident response set up with your ISP. This way, you can notify your ISP immediately when any server slowdown or other intrusion is detected.

Copyright 2002 (c) Roy Troxel, All rights Reserved. Roy is webmaster of Cyber-Routes, an online newsletter for Internet professionals, specializing in issues about web design and web security. You can also receive Cyber-Routes weekly by email by subscribing from our home page at

Leave a Reply

Your email address will not be published. Required fields are marked *