Hardware
Servers
|
SoftwareFor the moment, our big production servers run Linux. We have a bit of a history with Linux: We have written a few Linux Kernel patches in order to get our hardware running (mainly drivers for Promise IDE RAID cards). Our biggest patch is to make the SuperTrak SX6000 compile, boot and work cleanly into the official Linus Torvalds kernel tree. It's not as fast as we'd like, but it works. :) Atop the UNIX core, we use a universal filesystem structure, shared across all servers by NFS. We were trying to replace this with a distributed Coda filesystem, but Coda is a royal pain in the ass. Oracle just released some new stuff that may let us do distributed filesystems in the future. User accounts are managed on the back-end via custom software and access is granted to front-end servers via NIS. DNS: We run ISC BIND 9, since prior architectures of BIND are inexcusably poor and djbdns still seems overly complicated. Mail: We run a highly-customized implementation of Qmail. We have our implementation using SSL for every mail protocol, and requiring SMTP AUTH in order to send non-local mail. Our latest implementation also includes serious anti-spam capabilities built in. All mail is filtered for spam using SpamAssassin. We have a system-wide bayesian filter, and are working on providing automated per-user bayesian filtering as well. By default, spam is automatically delivered to a "spam" folder, separating it from good email. This can be configured for each mailbox, though. The system can automatically delete spam messages, bounce them back to the sender, or deliver them to another folder (even your INBOX). We also provide secure webmail with an open-source package called AeroMail, which we help develop. Qmail is an excellent mail system, but it has an extremely high learning curve. Building a major qmail system is not for the faint of heart! Web: Of course, Apache! We now run Apache 2.0. It's customized, as is our implementation of PHP. On our system, both CGIs and PHP scripts actually run with the security credentials of the user (YOUR account). This allows for better security and privacy for users' data that they access or manage through scripting. |
Design1. Expect things to break. Build your systems so that they can withstand the loss of other parts of your network and still (at least partially) run. 2. Expect people to be mischevious. Well, this wasn't always common-sense, but to anyone these days who spends 30 seconds with a packet sniffer connected to an unfiltered internet connection, it's a very obvious statement. Basically, expect people to snoop around and try to test the limits of your system. Beat them to it - create yourself a few test accounts and do everything you can to try to circumvent things. Be especially careful about permissions to shared services (web server security in particular). 3. Keep it simple. Now this statement can be deceiving... "keep it simple" can mean to write a little shell script instead of a full-blown application that stores stuff in SQL... but if you get 20 of these little scripts trying to work on the same chunk of data, it may be simpler to set up that SQL database and write that application. Try this rule of thumb: Do things in such a way that you can fully explain what you're doing to a stanger in as few words as possible. 4. Avoid setuid-root programs. You'd be amazed how many programs come straight from the vendor/distro as setuid root that don't need to be. For a single-user workstation it might make sense, but for a server or otherwise secure machine, there are VERY, VERY few times where a setuid-root program is needed to do the job. Go through the distribution and find all the setuid-root programs. Figure out how to either eliminate the program or make it work correctly without being setuid-root. |