By BoLOBOOLNE payday loans

Isolate your Continuous Integration Server!

Here’s a little food for thought about hacking into a development system.  If you wanted to gain control of somebody’s network how would you do it?  Well, you’d probably try to figure out a way to get one of the computers on the inside of their firewall to run some code for you.  If you could get it to run an arbitrary block of code that you wrote, then you’re probably pretty close to 0wning it.

Now think about the continuous integration server in your development farm.  What does it do?  Whenever anybody checks in new code, it runs all the unit tests to make sure they still pass.  Or, look at it this way: it takes whatever code anybody checks into the source control system and … compiles it and runs it.  This means that unless you’re being really careful, anybody who has write access to your source control system has control over your CI server and complete access to your network.

Old strategies for containing this mess included running the CI daemon as a limited authority user or chroot’ing the process.  These days, I think putting the CI server in a dedicated virtual machine is the way to go.  VMWare’s newly free Server product is perfect for this. 

These strategies can limit what somebody can do to the CI server itself.  But regardless of that, they’ve got open access to your network from inside your firewall.  So if you’re being really paranoid (a fine quality in a system administrator IMHO) cut it off from the rest of the network except the source control server.  The CI machine generally needs to be able to send e-mail to let folks know when things break, which means it also needs outbound SMTP access.  The smart hacker will use this to impersonate somebody within your org and get deeper in through social-engineering.  The best way I can see around that is to have a process on the email server poll the status of the last build on the CI system (say over HTTP, perhaps checking an RSS feed that many CI systems support) and send e-mail as appropriate.  Remember — your network firewall rules isolating this box don’t have to be symmetric.  It shouldn’t be able to see out, but other boxes can still get in.

This should make you think seriously about how accessible your SVN server is.  What kinds of passwords do your users have on it?  Do you require HTTPS?  Do you require client certs?  What about cached SVN credentials on all those dev boxes?  Remember — if you’re running a CI server, SVN write access in the wrong hands translates pretty quickly into a whole lot more access.

Comments are closed.