Security, Part 1

I l @ ve RuBoard

Security is visited twice in this chapter. On your first visit, physical, network, and administrative security will be covered.

You're Paranoid, but Are You Paranoid Enough?

The first truism of security is that you match your level of paranoia to the degree of risk. If you're deploying a server that's going to live inside a secure intranet and store the company softball schedule, you can basically do whatever you please . The risk of intrusion is low, and the value of the data is minimal.

On the other hand, if you're deploying an e-commerce site on the open Internet that takes people's credit card information, you should assume that every 16-year-old with a computer has made it a personal mission to break into your site and pilfer your data.

THE WORST-CASE SCENARIO: A CAUTIONARY TALE

Admittedly, playboy.com is a high-profile target. But, that should have made the site all the more wary. Imagine, if you will, how Hugh and company must have felt when scores of their users received the following e-mail:

" since the summer of 1998, a shady hacker group known as ingreslock 1524 has maintained full access to the Playboy Enterprises Inc. (PEI) corporate network.

Even when the PEI Web sites were defaced by BoW/H4G1S and were 'secured,' we retained our full access (no, installing SSH doesn't make you secure).

We did have some very big plans to use the hundreds of thousands of customer details ( names , addresses, order history, and credit card information) harvested to automatically purchase hundreds of different products from different online companies (Amazon, Barnes and Noble, QVC, Yahoo!, and even Playboy) to be sent to each Playboy customer, thus resulting in over $10 million worth of fraud claims being made to credit card and, in turn , insurance companies globally.

In case you think this is some kind of hoax, we have included your personal details below.

Name : [DELETED]

Credit Card Number & Expiry: [DELETED]

Your details are currently circulating the underworld of anarchists and credit card fraudsters, so we highly recommend that you contact your bank before much fraud is committed. We have also distributed over a million e-mail addresses to marketing and 'spam' organizations, so you will certainly have a lot of fun deleting unwanted e-mail into the future!

Online companies can learn many lessons from this compromise:

  1. Do not use the same root or administrative (Oracle, Webserv, etc.) user passwords across different hosts on the same network.

  2. Never assume that by installing the latest security patches and installing SSH that you are secure.

  3. Do not use insecure authentication methods , including nis, nis+ or .rhosts.

  4. Do not protect your passwords with des in your shadow files; use md5.

End users can learn an important lesson from this compromise:

  1. Do not trust companies with your details online.

It has been emotional. We'd like to thank the Playboy systems team for providing us with an interesting and challenging target. I'm sure that a big security company will make easy money auditing their systems and hopefully deploying a more secure network ”although we'll be back to test it again."

Because the customers were actually sent their real credit card information, it was clear that playboy.com had been compromised, which was a huge embarrassment for the company and a potentially costly one.

The first thing that I recommend is that you go out and get a good book on firewalls and security. You should keep in mind a few rules of thumb, in addition to the helpful ones that were mentioned in the sidebar by the Playboy hackers:

  • An open port is an invitation to trouble. Never run a service or enable an inetd entry (the UNIX program that controls what network services are accessible) unless you absolutely need to.

  • Your spouse's name is not a secure password. Neither is a business- related term . Two good easy-to-remember but hard-to-crack strategies are using two unrelated English words separated by a nonalpha character, such as grape*allenwrench, and using the first letters of a phrase, such as tatvotsse, which stands for "These are the voyages of the Star Ship Enterprise."

  • Using a two-tiered network topography with an external firewall box forwarding packets to a DMZ can make things more secure, but only if set up right. If it is set up wrong, it can actually make things less secure. To be set up right, the firewall box should run an absolute minimum number of programs and should forward requests through secure filtering programs (such as smail for SMTP traffic) rather than use port forwarding.

  • Using biometric- or "dongle" “based security devices such as a SecurID card or a fingerprint scanner might be appropriate if the risk factor is high enough. As an example, a SecurID card generates a new six-digit number that is synchronized to a similar number generator running on the server. Unless the two numbers match, you can't log in. This means that you need to have physical possession of the card to gain access. A more advanced version requires you to key in a four-digit PIN as well, meaning that even stealing the card won't gain you access. The downside is that these types of solutions are expensive, especially when there are a large number of users to validate.

  • Always set security options as high as you can without impairing the operation of your server. For example, if myserver talks to mydatabase as its JDBC source, but no one else needs to talk to mydatabase, mydatabase should allow incoming database requests only from myserver. Also, if there is a need to allow users to use SSH to log into the server, restrict it to specific incoming IP addresses, if possible, and turn off the SSH packet-forwarding feature. In general, try to make access as specific as possible.

Physical Security

Network security is only the first step in securing your application. You also have to consider that, given physical access to the server and enough time, nearly any security scheme can be defeated.

If you have the option to use an encrypted file system with your operating system (Linux has several available, and later versions of Windows also have one) and it won't be a performance hit, use it. This will give you some edge because it prevents the hackers from mounting your hard drive as a secondary drive on another system and rummaging through it. Unfortunately, to be truly secure, the operating system needs to prompt you for the encryption password when the machine boots, which makes it impossible to do an unattended reboot.

But, the best defense against this kind of attack is to keep the server where busy little fingers can't get at it. The chance that your site might be attacked by hackers is a good reason to host off-site with a service that offers good security. Remember, even if your site is physically secure, it might not be protected from internal misdoings by your fellow employees. According to some studies, most security breaches come from current or former employees .

Where Were You When the Lights Went Out? (Offsite Hosting)

The best-designed Web site in the world is reduced to an inert hunk of scrap when a flow of electrons is removed. Choosing a place to host your site can be as important to your overall success as choosing the right people to implement it. Here are a few things to look for:

  • Redundant power with a backup generator, 100% UPS

  • Multiple data lines (T3 or better) from different vendors with no single physical point of failure

  • Twenty-four- hour staffing with knowledgeable people in the first tier of support

  • Good physical security

  • Good fire suppression

WHAT ARE SUPPORT TIERS?

You've experienced support tiers if you've ever called technical support for a product. Is the first person you talk to the person who developed the product?

No, the first person you talk to is a minimum-wage, call-center employee who takes down your information and, if you're lucky, gives you a canned answer.

If the problem is beyond the employee's ability, the problem is escalated to a second tier, usually to support engineers with some idea of which end of an Ethernet cable is which.

The third tier is usually developers or network engineers. It can be very hard to get a call escalated to this level because those folks get paid real money. From many companies' perspectives, they usually have better things to do than fix your problem.

In the world of Internet Web site hosting, the first tier in a 24-hour support center are junior engineers, who can handle very basic system administration and can pick up the phone to call a more senior person when they get in trouble.

As someone who has been third-tier support, I can tell you that those 3:24 A.M. phone calls from the support center were not a high point of my life. It can also take more than two to three hours to get escalated to third tier, which will seem like eternity if your Web site is dark.

Administrative Security

Because of the danger of attacks from within, the final link in the security chain is administrative security. Don't give anyone access to the boxes who doesn't need it, and if someone has a temporary need, turn off the access afterward. Restrict root and Administrator access, and use journaled superuser access tools such as sudo rather than giving someone the root password. Don't let any one person have sole knowledge of important security information (for one thing, that person might get hit by a bus.)

As mentioned before, this is one of those topics for which it's worth your while to bring in an expert to point out the chinks in the armor .

I l @ ve RuBoard


MySQL and JSP Web Applications. Data-Driven Programming Using Tomcat and MySQL
MySQL and JSP Web Applications: Data-Driven Programming Using Tomcat and MySQL
ISBN: 0672323095
EAN: 2147483647
Year: 2002
Pages: 203
Authors: James Turner

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net