by Steve Patient

Server Security Issues

Site developers often consider security to be somebody else's problem. But lack of faith in site security is cited as the most common reason why people don't shop online.
January 31, 2000

On January 14 2000 MSNBC demonstrated the absence of security on seven ecommerce sites by effortlessly stealing 2,500 sets of customer credit card details - all the sites were running MS SQL and all were wide open, complete with plaintext passwords.

When a site is vulnerable to journalists, and even IT journalists rarely exhibit a deep knowledge of server OS innards, you know the problem is serious. Your average cracker could take such sites apart with his right frontal lobe tied behind his back.

As a site developer, your future business depends on people's willingness to enter into a variety of online transactions. It's in your own interests to ensure the sites you build aren't just attractive, but secure places to shop.

Shortcuts Shortchange

Internet time goes so much faster than the usual kind. It's easy to cave in when the baby products client says the site must be operational by Thursday. So you cut a few corners. On Thursday it looks good and goes live. The client is pleased.

On Saturday your client's baby products site features on SlashDot when it sends out 500,000 invitations to buy cheap child porn movies. On Sunday you're sacked. On Monday the client's lawyers are seeking punitive damages.

You may consider yourself and your site designers to be creatives, not mechanics. You may think security is the client's problem. It isn't. If the site were a high street shop you'd be expected to fit - or at least specify - door locks as part of the job.

To implement or even specify security you need at least a basic understanding of the kinds of attacks to which sites are vulnerable. Possible attacks fall into several categories though their exact nature depends on the site services and software employed.

Denial of service.

It's difficult to provide a complete defence against a serious DoS attack, but certain well known vulnerabilities - such as syn attacks, mail bombing and control characters in strings designed to crash server applications - can and should be secured against.

Data theft

A number of recent exploits have resulted in the theft of thousands of customer details including passwords, credit card numbers, addresses and even social security numbers. They've been stolen, used illegally and even re-sold on the Net.

Just as serious can be details of customer transactions, prices paid, discounts provided and current tender details. If these go you probably won't hear about it but your client's business could be compromised.

Site corruption

Having your client's site's front page replaced by a Photoshopped picture of a naked President Clinton is only funny to other people. But what if internal links are changed at random, prices altered, contact addresses changed, support pages rewritten? Damage can be subtle and have serious business consequences.

Traffic redirection

This is one of the more insidious threats. The redirection can be to an embarrassing site or more seriously, could invisibly propel prospective customers to a competitor's site. Many won't even notice.

Unauthorised use

This covers a multitude of activities including using your mail servers for spamming, using your site as a jumping off point for attacks on other sites, pornography storage and so on.

A subtle misuse is to steal your bandwidth. It's possible for do-badders to upload their own files and create links to them so large downloads choke your server, not theirs. You probably don't want your client's site to be used as a warez site, MP3 repository or porn-ucopia however much others enjoy the arrangement.

Include Security In the Specification

For security, site design must go beyond look and feel, user experience, navigation and other areas normally addressed by creatives. It should include network topography and other, underlying, engineering considerations.

For example, servers exposed to the Net should be separated from internal networks by properly configured firewalls. These are as important as the firewalls protecting the public servers.

All security specifications should acknowledge the possibility of inside jobs. The client's employees remain the most likely source of a security breach. For this reason, don't exclude local access from log files.

The Truth Is Out There

CERT - www.cert.org - lists the following areas where configuration problems in Unix and Linux systems commonly enable unauthorised people to exploit a server. Many apply to other server OSs.

1. Weak Passwords
2. Accounts without passwords or default passwords
3. Resuable passwords
4. Use of TFTP (Trivial File Transfer Protocol) to obtain password files
5. Vulnerabilities in sendmail
6. Misconfigured anonymous FTP
7. Inapropriate network configuration file entries
8. Inappropriate 'secure' settings in /etc/ttys and /etc/ttytab
9. Inappropriate entries in /etc/aliases (or /usr/lib/aliases)
10. Inappropriate file and directory protections
11. Old versions of system software
12. Use of setuid shell scripts
13. Inappropriate export settings
14. Vulnerable protocols and services

This is by no means a complete or detailed list, but it does provide a starting point for the creation of a site security check list. The final step should be an independent external check - with a report - on the site's security before it exposes live customer and client data to the Net.

Secure Server Operating Systems

Your choice of server is constrained by the demands you'll place on it, the server software a client requires you to use and budget. However, WinNT, Solaris, AIX, Linux and even MacOS can be used as a secure server OS. Win2000, while having more security options than NT4, is too new to comment on as yet.

Ideally, if it will do the job, go with the OS with which the client is most familiar and has most in-house expertise. This should be upgraded to the current version rather than patched to ensure all known security holes have been sealed.

Server Application Vulerabilities

Unix applications were originally designed to make it as easy as possible to connect systems. This means some standard server application specifications compromise site security. FTP is a good example as the server connection is determined by the client.

This enables a cracker to arrange for an FTP connection to a third party which originates behind the firewall. As a consequence, it would be allowed by most firewall settings. Clearly, a secure FTP site cannot meet the requirements of the FTP RFC. Only limited compliance is possible. Only by being aware of the Net protocol standards can you guard against unwanted security holes.

Server application holes are usually reported as advisories. These come from a variety of sources. CERT, commercial software vendors, hacker groups such as LopHt, various newsgroups, university researchers and so on. As a Web developer you need to be aware of advisories affecting the applications your client's sites use.

The highest risk to a random (as distinct from targetted) site ocurrs between the adivisory being issued and a fix being published. At securityportal.com/cover/coverstory20000117.html
you can find an interesting story comparing the time between an advisory and a bug fix being issued for several different OSs. You might consider this when choosing server OS and application software. During such periods it's important to raise the level of site monitoring.

Third Party Checks

Most ecommerce sites post privacy statements, but few comment on their attitude to site security. It makes sense to persuade your client to post a security statement listing the measures its taken. If the posting is from a recognised third party site security specialist all the better.

Ideally, security should be a contracted site service - using either internal or external resources - and ongoing. Unfortunately, there isn't currently a recognised international standard for site security, a situation which will have to change if customers are going to have more confidence in ecommerce sites, online banking, government and local authority transaction sites and so on.

If a site states it has contracted such and such a security company to check on and maintain its security your client can at least claim to have done everything practical if security is breached.

Self Help Security

There is much you can do to secure a site even without specialist help. Assuming the site has been configured properly to begin with ensure security advisories are read, security patches are applied and security related upgrades carried out.

Refuse to trust security through obfuscation. If a software vendor won't discuss the security issues you raise don't use it. Security works best if it's been peer reviewed. Concealing problems benefits crackers, not clients.

Process log files. Logs are your greatest security aid. OK, they're large, but processing data is exactly what you bought computers to do. Once you know what you're looking for it's relatively easy to set up scripts to process logs and email an administrator if anything is amiss. It costs money to do this, but it costs more to recover from a total loss of customer confidence.

Deskilled Server Administrators

Windows NT servers can be made pretty secure, but the point and click approach to configuration has led to server administrators with less well developed skill sets than in the past.

This, coupled with Microsoft's traditional disinterest in security wherever it interferes with ease of use - which means the usual default is no security - has resulted in large numbers of exposed Microsoft Net sites.

While learning to configure Sendmail, for example, or Apache, is something you normally learn once security administration requires a pro-active approach to be effective. This is because Apache et al don't gain new features every day while new security flaws are discovered in server software and OSs with depressing regularity.

Legal Eagles Take Wing

Site security is going to become a major ecommerce issue over the coming year with pressure coming down from credit card issuers and up from customers. Part of the problem is having to trust commercial software vendors. It's difficult to audit the security of closed software.

In contrast, Open Source enables developers to check for security flaws as well as fix them. Think about it. Would you rather write kludges to cover up flaws in commercial software or fix the software?

In the long run, site security benefits clients and customers, which means more people and companies willing to carry out transactions on the Net, which means a bigger pie for developers. It's hard to see how closed software can ever be certified fully secure by an independent third party.

Security certification - being able to demonstrate customer data is secure - will eventually be necessary to meet the legal requirements of countries belonging to the EU, for example. And insurance companies who require five lever locks on front doors before your home insurance is valid aren't thrilled insuring sites against vandalism and losses if they can't verify the levels of security in place.

Signing off insecure sites is unprofessional. It's likely to become illegal. We haven't seen much in the way of litigation against site developers as yet but it will happen. You'd probably prefer it didn't happen to you. Take site security seriously.

More articles like this

Steve Patient has covered computing, telecommunications, networks and the social and business changes they bring, since 1978. He believes the best a technology writer can hope for is to emulate the monks of the middle ages. To chronicle a small piece of a much larger picture as accurately as possible. It will be down to some future scribe to make these days look like an inevitably unfolding tale.