Web Server Security Best Practices

« Comcast: The Best Grassroots Support Money Can Buy | Main | APA Paper Challenges Preconceptions About Online "Predators" »

February 27, 2008

Web Server Security Best Practices

Charlie in the first of two on Web server security best practices:

Many companies, at least a few I've seen recently, have widely varying ideas about how to configure permissions for Web hosting users. The two basic schools of thought are: give every user their own group and a umask of 002, or require that the user maintain their own permissions, with a 022 umask.

In the first scenario, the benefit is that when collaborating, users never need to mess with permissions. Their umask will cause files to be written with group writable permissions, which is OK, because context matters. If they are writing files to a shared group resource, the parent directory will have the setgid bit set, and all files will be created with the same group id. Likewise, if they are in their own space, files will be written with the user's own group id. There are no obvious security holes here, but two issues quickly come to mind. First, this is training the user of the system to not pay attention to permissions at all. Second, certain security settings and third-party modules will not operate if files are group-writable, because the potential exists for malicious code to be introduced. If a single user's account in a group is compromised, the shared storage is as well.

The second scenario doesn't train users to ignore permissions, and allows modules like su_exec to run without hacking the source and commenting out the code that checks for group-writable files. In the end, the biggest concern regardless of the strategy to deal with collaboration among users, is that users will continue creating world-writable directories.

Many Web applications, even popular ones, tell the user to 'chmod 777' as part of the install process. That's fine, but they never tell them to fix the permissions after the installation process! Increasingly, especially in the .edu world, I've seen more and more malicious scripts actively looking for world-writable directories. A compromise of a single site on a server often leads to many sites having unauthorized content written to them.

You don't have to look far for "tutorials" on running just about any Web app that stop after "hello world" or "installation successful" or whatever. There's a singular lack of imagination in the Web hobbyist community regarding just how much damage a seemingly trivial app can do.

On the flip side, something as simple and elegant as the basic Unix permissions model is periodically just impossible for people to get.

Remember Debian ca. 2000? I do. It went around behind your back "fixing" permissions to stuff without regard to context or expectation, and it didn't bother to tell you when it did so. I was playing around with KDE at the time, and I spent two days wondering why it was I couldn't run the little PPP dialer app after it had worked when I went to bed the night before. A survey of the logs eventually told me what was up: kppp wasn't supposed to be setuid root, and none of the modem devices were supposed to be usable by mere users.

I don't even hold that against Debian, really. At the time, Linux was going through a small boom with a bunch of easy-to-use distributions and a lot of buzz. The old suspenders-and-beards people were watching a lot of newbies flock in not because of some particular affinity with Linux's heritage, but because it was one of any number of things: a replacement for some beloved other operating system (BeOS, OS/2), not Windows, cool, whatever. You could stick a CD in a computer, reboot, and just do what the pretty pictures told you to do, and suddenly you were in possession of a machine that could do anything.

Up through the late '90s, Red Hat was terrible for tossing in the kitchen sink along with whatever services one might want with a functional Unix-like server, and leaving it hanging out there. SMTP listeners, Web servers, assorted network services that had no business running on a machine in the care of someone who didn't even know the services were running, or what "network services" were. So when I'd see Debian pull something like turning a magical permissions fairy loose to make sure bad people couldn't get at my modem, well ... the alternative was the looming sense of dread we (and by "we" I mean "Linux enthusiasts") had that Linux's reputation for being more secure than The Alternative from Redmond was going to be undone by bad packaging and inexperienced, o.k., ignorant users.

But that didn't make it any more fun to contend with things like Debian's magical permissions fairy. I remember my first impulse when it made my modem unusable for the third morning in a row: I wanted to yank it out. Humility prevailed, though, and I found a little GUI wrapper that'd let me run my dialer from my unprivileged account. The magical permissions fairy quit sprinkling downer dust all over my stuff. I think a lot of novices were more inclined to visit a board where slightly less inexperienced novices would tell them how to defeat whatever security measure was making Linux less "friendly" than Windows.

The Linux world has, of course, moved on since then: The major distributors are more careful about configuring installations appropriate to the user's needs, and the user base has been herded into a life of pecking in a password for whatever sudo wrapper their distro is using whenever they want to do anything potentially dangerous, destructive or system-altering. (Same as the Mac people on that score, and, I guess, the Windows people.) It's not a perfect system, but it puts some space between the users, who just want to do whatever they need to do, and the guts of the OS, which will do harm to others if its capacity for self-regulation is tampered with.

But rather than seeing user education and better packaging overtake the problem, we've moved on to the Web as the platform of choice for punters, hobbyists and generally nice but inexperienced people, so the problem hasn't so much disappeared as it has migrated. And there's something oddly abstract to a lot of people when you try to discuss Web application security in particular.

I touched on this last summer when I wrote a column for Practically Networked on the changing nature of security threats. The mainstream news media conditioned people to think of threats in terms of deleted files, the computer "going haywire," or whatever. It was all about, for a long time, emphasizing the destructiveness of viruses and other malware. That's not what it's really about now, though:

"The overwhelming goal of malware in the wild today is not to eat files. It's to compromise computers and use them to do something the compromiser would prefer not to be caught doing himself. Like send torrents of spam directing people to sites where a) they can download malware that compromises their systems, adding to the snowball of compromised systems or b) give up personal information that can be used for identity theft or simple credit card fraud. It's to the benefit of the people compromising these systems to remain undetected for as long as possible, so the maximum amount of spam can be sent out before detection and remediation."

And don't even try to explain the way phishing sites work, or the way they rely on compromised Web apps. The value of a insecure Web site serving up an easily exploitable app is often obscured by the length of the chain of events the criminals compromising the site have set up. It may be that all they want is a tidy collection of pages coming from a domain with good search engine juice to stack Google results with the site they've got to serve up client exploits, or take credit card information. That's kind of subtle. It's definitely not "omg!1!! Michaelangelo is gonna eat all your files!11!"

Charlie does a pretty good job of outlining the basic issues in his article, though, even if it is deja vu all over again: We need better packaging from the distributors, and more user education, so people can at least know to be offended when a lazy PHP coder manages to write a beautiful, functional, professional-looking Web app, but doesn't bother to mention how to lock it down.

(Link)