Fog Creek Software
Discussion Board




Just. for web server on developer machine

Our current policy is that no web servers are allowed to run on developer machines for security purposes. 

Due to a variety of reasons, including bandwidth problems to the server,  I would like to changes this so that each developer has Apache, Tomcat, whatever running on their desktop and a source control/build process to move things to a central server for testing and production.  A combination of personal firewall and web server settings *could* restrict access to connections from localhost.

I would appreciate any references to standard developer configurations and the justifications, or just good arguments I can use.

steved
Thursday, July 01, 2004

"Our current policy is that no web servers are allowed to run on developer machines for security purposes."

Why would it be a security risk?  I would assume that your offices have a firewall that would prevent outside access to the machines on port 80 anyway.

Almost Anonymous
Thursday, July 01, 2004

Why not configure the web server to use a different port, then block all external access to that that port using the development machine's firewall software?

John Murray
Thursday, July 01, 2004

I am also confused as to why it would be a security
risk. If they can get inside your network does a web
server compromise your safety that much?

son of parnas
Thursday, July 01, 2004

I didn't say the current policy was rational :)

The rationale is something like "Web servers have vulnerabilities and web servers not under central control can't be guaranteed to be securely configured".

steved
Thursday, July 01, 2004

If it doesn't run on port 80 is it a webserver ?
Can you get permission for an "encapsulated test object server" on port 8080 ?

Martin Beckett
Thursday, July 01, 2004

You could use vmware with networking disabled. Or even User Mode Linux (but that takes more effort to set up)

somemorone
Thursday, July 01, 2004

The justifications are pretty easy:

If each developer has his own server that he's damaging, that means he's not damaging the production/development server. He's also not hogging bandwidth on that server.

To ameliorate some of the security risks, configure the firewall to deny connections originating from external sources to connect to developer machines.  You should be doing this anyway, because a developer machine is the single most likely system to have something strange done to it that leaves it vulnerable.

Clay Dowling
Thursday, July 01, 2004

Who abbreviates Justification? I mean, come on.

2
Thursday, July 01, 2004

PC operating systems have vulnerabilities and PCs aren't under central control.  Are you a mainframe shop?  :-)

VAX is too high-tech for us
Thursday, July 01, 2004

I think that VMWARE Server would be great for your shop. Just run on it on dual proc Dell server with loads of RAM and your set. At least 128MB per guest or 256MB to run it comfortably.

Convince you your colleagues and bosses with trail version if you have spare server lying around. Can be old and slow as it’s just to prove the concept.

Like Joel said in one of his articles he, you should equip your developers with the best tools money can buy.

If people like it then buy a Dell server* (with loads of RAM) and VMWARE Server at possibly the total price of $7.000. Now each developers is able to do possible anything he wants without affecting anyone.

Ooh if you are Windows based shop get an MSDN subscription as this allows you to run any version of Windows for testing purposes.

The total price of such a workshop should not be expensive for a professional software development company considering the advantages it brings.

*Building your own or AMD Opteron based could be cheaper in some ways.

somemorone
Thursday, July 01, 2004

You shouldn't run webservers on developer machines:

* They don't know security, security is hard. Unless your programmers have been writing SUID software or defeating web attacks for the last 5 years I wouldn't chance it. If they say "Linux/OpenBSD/FreeBSD/NetBSD is secure out of the box", I would just tell them to do a search on "root kit" on Slashdot.org.

* They don't have the time, it will just make baby sitting their box that much more complex, it will make replacing them painful. They will use tons of tools from source forge you never heard of and they will not let you in on it.

* It will make moving them to the next office next to impossible. Instead of a little 5 gig backed up storage allocated to them that's carefully backed up. Now you have 50 UNIX boxes all run different ways (there's more than 50,00,000 ways to do anything on UNIX) and Joe can't go from 192.168.2.* to 192.168.4.* without moving his computer along too.

overweightnerd
Friday, July 02, 2004

Clay Dowling, SSH can be made to do reverse listening. Meaning a malicious programmer can set up a SSH service with a daemon to dial OUT (and chances are on most unix friendly networks the network firewall has the SSH out-bound rule set to enabled and the rule is unfortunately too often 255.255.255.255). Firewalls aren't any good against that unless you run an application firewall that watches out-going connections on a library by library (or application by application) basis. So some idiot who uploads an malware to sourceforge.net could theoretically get a lot of people to download the malware (which in turn would turn little boxes into zombies). Don't let your developers install whatever the hell they want, have a quick discussion about every software installed as long as you don't turn into a BOFH.

overweightnerd
Friday, July 02, 2004

Get a new job. Seriously, no company that makes software can be successful with a policy like that.

Matthew Lock
Friday, July 02, 2004

Hmm, if you are just using the webserver on the desktop for local testing I don't see any problems with moving machines around. localhost will be localhost, no matter what the actual location in the network is.

I would suggest running the tools you need on the desktop and have your version control system take care of the integration of changes made by the individual developers. Using a combination of Subversion and scheduled central builds and deployments with (N)Ant should be able to do the trick.

Running local servers makes sense, especially in the light of bandwith restrictions.

Say cheese
Friday, July 02, 2004

Sounds like a no-brainer - just configure Apache to bind only to the localhost interface, how could that possibly be a problem? You'd need to standardise the install somehow, but still.

Matt
Friday, July 02, 2004

What about a peer-to-peer web server like BadBlue?

That should be safe.

<j/k>

http://badblue.com/blog
Friday, July 02, 2004

*  Recent Topics

*  Fog Creek Home