How secure are you?

Unix Insider –

Recently, the instances of hackers taking over sites has created a serious interest in Web site security. With the recent hacking of http://www.rootshell.com/, a longtime archiver of security and hacking exploits, there seems to be no sacred place left on the Net. The list of hacked sites ranges from the Department of Justice to the CIA and the New York Times. It's a relative who's-who represented at sites like rootshell and www.2600.com/hacked_pages/.

For some reason, many Webmasters and consultants have the misbegotten belief that their sites are untouchable and invulnerable. Look at the hacked New York Times site (http://www.2600.com/hackedphiles/nytimes/) to see what hackers thought of (and did with) the "invulnerability" being spouted by a security consultant related to that site.

Recent studies show that 67 percent of all break-ins are by employees, ex-employees, and other current and former insiders. (IBM is continually touting this number as well in its media campaigns.) This does not seem to fit the perception by the masses that hackers are in the 13-to-16-year-old age range with lots of time on their hands.

I believe Peter Galvin does a great job on the technicals of Sun security in his columns for Unix Insider, so I won't bother to repeat what you can get from reading his past columns and the Security FAQ. I will also avoid inclusion of previously listed security resources. Columns by my predecessor, Chuck Musciano, detail many security issues that haven't changed since he wrote, "Securing your Web server" (three parts, June to August 1996).

Security, from my practices, is typically 65 percent researching risks, 20 percent researching patches and fixes, 10 percent evaluating what the new changes will impact, and 5 percent actually patching or fixing systems. Some hours must be dedicated by every Webmaster towards this subject. According to several ISPs, the two major Sun issues are:

  1. Suns, as normally configured, come with a lot of active services that, in a security-oriented environment, should be turned off. These include SMTP, telnet, FTP, etc., and all services, such as sysdat, daytime, finger, whois, etc., not directly related to Web hosting.

  2. Solaris for ISPs, now known as Sun ISP Server, certainly seems to be an option for those with larger IT budgets. Jim Bogard, manager of Unix systems engineering at major ISP, Digex, warns, however, that with the typical out-of-the-box Sun, "Most directory and file permissions are not set properly, unnecessary or undesirable services are often present, and the overall operating system has been tuned for a single-user or trusted-network environment as opposed to that of a Web server."

On to the Q&A

In the table below, I discuss a set of general security risks and provide advice on how you may wish to handle them.

Security questions and answers

Are you the computer security expert?

You better be! It is critical you learn all you can about security, even if all you ever need those new skills for is to let yourself back into a system you've locked yourself out of.

Yes, I have locked myself out before and those hacking skills did come in handy. They also proved that my system needed a little work. I thought I had a reasonably secure system. I sealed up the holes I came through after the fact, but I would never have thought about them until I had to break into my own system. I suggest you forget your password occasionally and test your systems out yourself. Be sure to try hacking your users' accounts as well. Don't leave any weak links unsealed.

Do you or your customers have an outside expert?

Computer security experts have a variety of skills. Be wary of anyone who says they know it all. The last "expert" sent to me by a major company started quizzing me about firewall ratings one day in front of a Web customer and an ISP's engineers. There was more than a bit of laughter when the "most expert" security person this company had to offer explained that he didn't know much about those (electronic or software) kind of firewalls, he was wondering how long it would take fire to burn through the walls and at what temperature.

Where is your written computer and security policy manual?

A written manual is a double-edged sword. Writing it is necessary to completely develop a policy capable of handling all security requirements. Just by defining all the requirements the Webmaster can, probably for the first time ever, know all that needs securing. Of course, documenting all your security requirements and how to mitigate risks can give someone a recipe for hacking your site.

Is the security and computer policy manual protected from unauthorized prying eyes?

Don't tell me you left it out on the bookshelf in your office, in a file cabinet, or some other ridiculous and obvious place? These are the first places any internal hacker will look. Get a fireproof safe, preferably offsite, and be sure no one can take the whole safe, either.

Do you do random spot checks and do you shake up the system occasionally to see what falls out?

OK, so you may have a written policy you religiously follow. And perhaps you stick to a certain routine, like checking the logfiles at 3 a.m. every day. This just means there are 23 hours for a hacker to pry into your system. If someone else gets to know your habits and learns that you never deviate, well, it's an easy recipe for a hacker to follow.

Plan your work, work your plan, and every once in a while shake things up with a random check up, from the Net up.

I've surprised a few would-be hackers this way myself.

Where do you store backup data, emergency disks, etc.?

Tales of hackers getting backup drives with the operating system and all files intact abound. We've heard about stolen Windows NT emergency diskettes, containing the password file, that were left out in the open or with the machine. A copy of that disk, some time, and a program (like those available at www.l0pht.com) to crack the SAM (user ID/password) file can provide hackers with your password and ID.

Again, an offsite fireproof safe that no one can steal is a great place for these types of items.

How often do you use that password of yours?

Every time you log in from home or across the Net, you could be sending your password in clear text. That's a very big risk. Read up on sniffers at www.sans.org/NSA/glossary.htm and understand that every packet to and from your machine can be captured, decrypted, and utilized against you in some way. Do not take that chance. Change your password frequently.

How often do you change your password, and how often are your customers required to change theirs? Is there a lockout feature after so many bad password attempts?

I recommend you change your password as frequently as you can. Read up on hacking terms and some common windows of vulnerability, like "leapfrog attacks," at the www.sans.org site mentioned above. Understand that any superuser or user can contribute to a hacker's attempts at gaining access to your system.

Locking a user's account after four or five attempts (at most) may seem an inconvenience, but it does prevent a hacker from repeatedly trying to hack an account using brute force (repetitive attempts using numerous combinations of characters) or dictionary methods (the use of common words, which many people use as passwords). Be sure that only administrators can unlock this account, so if need be you can verify that it was really the user attempting to access his or her own account.

Where are your users writing those passwords down, and who is around when they use them?

Have you talked with your users about putting passwords on sticky notes under their keyboards or monitors, or jotting passwords down on their calendars? Watch for this!

If your users enter their passwords in front of others freely, or even worse, share their passwords, you are allowing them to jeopardize any security you may have. Talk to your users about these things. Put up instructions on your intranet or in a human resources package for all new hires.

What is the formula you use to generate passwords?

I won't spell out what I use, but most ISPs recommend that you use a minimum of eight characters -- a combination of upper and lower case letters, numbers, special symbols, etc. And never use words, names, birth dates, or social security or drivers license numbers. The most common passwords hackers try (and sysadmins use) are "sex," "god," "love," "password," "wordpass," and so forth. It may seem a pain to remember a password like "xT8~u9Ro," but that password gives you enough time to use it and change it before it can be cracked. Check out those hacking and password-cracking tools.

Where do you store your user ID and password lists?

This is a trick question! You should never store user IDs and passwords. Shred them, burn them. Never leave them lying around. If your users forget their password, assign them a new one. Otherwise, you're just giving potential hackers a million ways to get into your system and look like an authenticated user.

Q: Why shred or burn sensitive information? A: Have you ever heard of dumpster diving?

Dumpster diving is the process of rifling through a corporation's or individual's trash (at home or at the office) and searching for "starting points" of vulnerability -- a written down password, a printout with the name of a Web page or file most users don't know, user ID lists where hackers can focus on using brute force to hack the account, source code, which is a gem for hackers, and a whole bunch of other sensitive things most people just wouldn't think about. People assume that once it's in the trash, it's gone. Don't think this way anymore; it's just not true.

Do you turn on Secure Sockets Layer (SSL) first, then ask for user IDs and passwords, or do you do all those transactions with clear text (text that is clearly readable)?

I think this one is self-explanatory. If you have a page that asks for a user ID and/or password, use a corridor page to turn SSL on before getting to that page. Then, on the next page, query users for user ID and/or password information.

Do you know many hackers' tools and defenses?

There is Crack (for Unix passwords), l0phtcrack (for Windows NT passwords), and SATAN (for networks). Better yet, there's Net Sonar (network/server prober), Tripwire (binary checksum calculator), Tiger (scanner), and numerous other tools. Many password crackers can break the security behind six- and seven-character passwords in mere minutes; words from dictionaries take only seconds.

Another hacker favorite is "rootkit," a tool for capturing passwords and e-mails to a system. Sure, this would require a hacker to force an execution of the file to start the process, but embedded binary code in a malicious CGI call could start the process of capturing this data.

Get these tools and run 'em! See what hackers see when they look at your systems. Get to know your system's weaknesses. Get to know its strengths. Finally, understand how easily hackers' automated programs can get them into your machines and networks.

Are you really checking those logfiles?

Logfiles are to computers what fevers are to us. They're an indication of the health and welfare of a system. We check our temperatures only when things aren't going well. Logfiles should be checked especially when things are going well. The more traffic and attention your site gets, the more likely you'll be the focus of a hacker. Looking at logfiles randomly and regularly can help you spot creeping sickness -- like multiple hack attempts, suspicious application crashes, and use of your own logons.

Moreover, don't be fooled: hackers often cover their tracks by killing, scrambling, or editing the very same files you depend on. If you're keeping logfiles on the same system being targeted, you're making a big mistake. Storage of these critical records should be done on another machine or mirrored on another machine with verification between the two that the files haven't been tampered with -- a sure sign you've received an uninvited guest.

Go beyond the standard files Sun uses and log your own important events. If it matters, log it: database accesses, directory accesses, admin function accesses, and so on.

Who writes your software? Have you reviewed it?

I know this may seem unnecessary or tedious, and maybe you don't have the time, but make some time!

Backdoor passwords that even well-intentioned programmers leave in for testing purposes or super user functions are vulnerable to a hacker's prying eyes. Backdoor passwords also provide the means for an angry ex-employee to gain access to your site. Do not allow this. Review all the code on your site and make sure you're not being walked down the garden path. Historically, some programmers have planted "mockingbirds," and "logic bombs" in systems users or ex-employees might later activate.

If possible, use only compiled and/or binary code on your site instead of scripts. It's a lot harder to work with, and it's still not ideal because it can be reverse engineered or disassembled, but it does offer more protection than clear text.

Are you using form-to-e-mail CGI scripts or programs, or are you e-mailing private information publicly?

It is of major concern that you secure your servers, network, and operating system. One thing that's often ignored is the transfer of information between users and Web sites. According to a recent report, while 73 percent of Internet users check out product Web sites, due to security and privacy concerns only 15 percent make online purchases. Secure Socket Layer (SSL) is one method to keep that data secure as it passes through the many machines and points of interception along the way. A basic security marketing paper shows this risk area (along with others) quite well: www.prospect-tech.com/ec/download.html.

Even with SSL, one of the weaknesses I often see is form-to-e-mail CGI gateways, where credit card or personal information leaves the site for other destinations. While the form interaction with the user may be encrypted by SSL, Webmasters seem to forget that once the e-mail is sent offsite, it passes through a large number of other systems in clear text (unencrypted) format. This means transaction security can be jeopardized at any point along the way. Hackers armed with sniffers love this! I highly discourage this kind of information passing if you would like to stay in business. Encrypt this data before sending the e-mail, using PGP or other methods.

Are you using JavaScript to check for user IDs and passwords?

I've seen this repeatedly. Foolish Webmasters put snippets of JavaScript into their pages while looking for a particular password or reading user IDs and passwords from a file, showing exactly where the file is. This makes it easier for the hacker to attack specific targets. In addition, anyone can view the source to a Web page and poof, there's the password. Do not do it.

Peter Galvin's Unix Insider security columns and past Webmaster columns show alternate password and user ID methods using .htaccess and/or .htpasswd.

If you're using Java, JavaScript, and other applications that run on a user machine, do they feel safe?

Users worry, as I do, about malicious applets on sites' Web pages. Hackers love to plant unobtrusive applets on Web pages, prompting for user IDs and passwords or collecting them as the information is entered. Most of the time this information will be forwarded to a dropoff point on the Net, from which the hacker will later arrange to pick up the information.

What assurances have you made to your users that your applets and applications are safe from this type of tampering?

Are you filtering binary data from CGIs and scripts?

It's possible for hackers to send you a URL with binary data included, which can execute a program granting access to your server. No matter what your CGI code is written in, it's a major risk if there's a way a client can fool a CGI script. For example, commands can be appended to a CGI script command page, where additional commands are postfixed to the CGI command being issued, such as "send me the password file."

When writing your scripts and CGIs or reviewing those that are written for you, remember this: filter out binary data and throw it in the bit-bucket where it belongs. Your server can be used to pass letterbombs and mailbombs this way. Do not become a willing accomplice.

In addition to checking for this, be sure your server software isn't susceptible to "buffer overflow" or other methods of passing a long URL to your server and crashing it.

Is your IT environment tied to Human Resources?

Ex-employees can be a major risk factor in any computing environment. Your IT department, Web site access, and network access must be closely tied to employee departure. People aren't so keen on risking their jobs with foolish activities, but when they have no job to risk, well, this could be a major problem.

Have you selected your Web server software based on security requirements also?

If you haven't looked at more than one Web server package, visit The Netcraft Web Server Survey (http://www.netcraft.com/survey/) or Internet.com's WebCompare (http://Webcompare.internet.com/) sites to see what each Web server package has to offer. You may be surprised.

Yes, Mr. Lemonjello, the number is...

Social engineering. I cannot say enough on this subject. A recent Dateline NBC show followed a "hacker" (paid by a large firm) who elicited information from someone at a company, and in less than 40 hours an entire banking system was compromised.

The whole process started with nothing more than a simple telephone number. The hacker gave his name, "Mr. Lemonjello." The person on the other end of the telephone complied because it sounded urgent. Don't let a hacker fool you or your staff into giving out passwords, phone numbers, and so on. Test whatever system you have in place at all levels for susceptibility to this.

Hey, where's my power?

Hackers do not just try to get passwords and access. They also attempt to cause problems by assuming your identity and cutting off your phone, electrical, and Internet services.

This may sound overboard, but it's not. For every account you have remotely touching your Web site, your physical plant, even your personal life, set up a password with that provider of services and change it frequently. Without this, people can call up, say they're you, and have your service cut off. It has happened; don't let it happen to you.

How do you know you've been hacked?

Keep tabs on suspicious activities by using software packages with Tripwire features or even monitored dummy accounts, and by religiously checking those logfiles and multiple logging systems, especially those actually stored on other machines.

Designing and closely monitoring software and files with obvious "dummy" user IDs and passwords (and other such data goodies a hacker might find too tempting to resist) has proven effective. The Cuckoo's Egg is probably the most famous book that gives a detailed account of hackers being gullible and falling for just these types of methods.

Tools that serve as your best security guards include firewalls, software protection and authentication tools, careful Web site design and coding, system testing tools, and a constant attentiveness to system health and welfare and to the newest developments in the hacking community. According to one security expert, "It is pretty bad that you have to ally with [hackers] to stay ahead of them, but that's the reality."

If you've taken all of the precautions you possibly can and you still get hacked, don't feel bad. Learn from it. Hindsight is always 20/20. Naive system administrators have been known to leave a known vulnerability in place, somehow expecting that it won't be hacked twice.

Hackers generally don't stumble into your network -- you were picked as a target. Hackers study the problem and take note of all that they find. If the hole in your security armor allows a hacker's arrow to pierce you once, you better believe this weakness has been posted throughout most of the hacking groups and IRC (Internet relay chat) channels.

Just having completed a year-long military computer security study, I will quote from my report: "The only way to secure the systems one hundred percent is to turn them off."

Next month, I'll take some time to help my fellow Webmasters out by ferreting out places on the Net to find source code (Perl, counters, Web site search functions, Web stores, etc.) to run on your Web site. Anyone who would like to contribute resources, suggestions, or information to this column is always welcome to e-mail me.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies