What is the industry best practice regarding securing access to source code? I am thinking SSL only connections via apache allowed over to our server on an obscure port that doesn't conflict with anything else. The thing that bothers me is storing source code on a public facing server, i.e. not only accessible via a LAN. Moreover, this server has several uses. Apache is serving up some other internal company websites already. I would like everyone to be able to access the source code from anywhere (homes, airport, whatever) so long as they have the correct credentials. Suggestions?
7 Answers
If you're concerned about it being on a public-facing server but would like access from anywhere, you should consider having your developers use a client-based VPN to log into your network remotely to access an internal source control server.
-
1Can you explain your reasoning as to why you believe that a VPN is more secure than a SSL/TLS based server given that both need to be "public facing"? VPNs use familar encryption to SSL/TLS. So if you could hack the VPN you get everything.– hookenzNov 9, 2010 at 8:11
-
1@Matt If there's no reason for him to have his repository on a public segment, then why put it there? In addition, a VPN may have other benefits for his developers. You'll also note that I never said anywhere that "VPN is more secure than SSL/TLS", so don't put words in my mouth:)– phoebusNov 9, 2010 at 14:47
-
1True. I felt security was implied in myr statement. Perhaps you can qualify this: "If you're concerned about it being on a public-facing server "– hookenzNov 9, 2010 at 22:10
-
In my opinion, having private servers/services behind a VPN is part of the layered approach. It helps protect against configuration errors that could expose the source to the public. Not required, but smart. Dec 25, 2011 at 1:15
I'm not too sure why people are thinking the VPN approach is the best. It's not necessarily any more secure and only offers one advantage that I can think of.
PPTP for example is known to have less than ideal security, although I believe it's improved somewhat since first introduced... so be careful which VPN solution you use. I'd go with OpenVPN or IPSEC.
However, you can't beat the convenience of SSL/TLS without the VPN (read further down). And to make it even more secure you can make it certificate only.
However, if you think you might offer other services other than source control then consider a VPN solution because you'll tunnel other services over it.
The disadvantage with using a VPN is that your PC becomes effectively part of the network that it's connecting into. That also can be an advantage. But, if you're a million miles away from home and the network connection to home base isn't too speedy then every time you want to do a diff or check in or out code you might find yourself connecting and disconnecting the VPN.
I can speak from personal experience here as I am a developer and it was a real pain in the bum to be doing this!!! Ideally, both options are preferred.
So if you're going to be browsing the web etc then it might make reading the news etc rather slow. But at least you get secure access to email. So consider how you'll be using it first... If I were you I'd consider implementing both.
Actually, I like your suggestion. If you make your source code repository accessible ONLY via SSL/TLS, and you make certain that your developers don't use easy-to-brute-force passphrases (or better yet, use certificates), then that should be as secure as anything.
You could, instead, hide your server inside your LAN and force developers to use a VPN to get access, but that just means your developers need to put their username/password (and/or cert) into a different login box. I would recommend against creating an entry point into your network whose security implications may not always be obvious, just to allow access to a single service. If you already have VPN configured and secured for other uses, then sure, it's a no-brainer, go ahead and use it. Otherwise, it may be simpler, and thus more secure, to make the service itself directly available via SSL/TLS.
answered Nov 8, 2010 at 22:02
Industry standard probably depends on what your (or your customers') industry is :-)
Practically you need to consider who you want to give access to, and what they can handle. Some people you might want/need to access won't be able to cope with much more than a username/password. Others might be able to get their head around ssh and a private key, which provided you can securely get the key to them, is not bad. TortoiseSVN client can handle ssh+svn and supports private keys with a bit of arm twisting. That has been good enough for my purposes.
A VPN tunnel is also a fair suggestion, although in many places you would be happy to give external people access to just your source control, but not your whole network!
Like others, I prefer a VPN. An alternative would be an SSH tunnel, which I suppose in practical terms is a kind of VPN anyway.
answered Nov 8, 2010 at 21:08
Make it internal-only and implement a remote-user VPN solution. /Doh- duplicate.
If you want access from anywhere, then you need a public facing server — that much is clear.
On that server, you want to expose as little as possible, preferably just Mercurial/Subversion and nothing else. This is to prevent a breach in security from spreading from the source control to the rest of your company. For that reason, I'll agree with Matt when he says that a VPN can be dangerous: it gives much broader access than needed.
For Mercurial, you can lock things down tightly by using hg-ssh to restrict the commands available to clients that connect over SSH. By using SSH, you can easily demand that clients use public key authentication instead of passwords. This protects your server against brute-force login attacks.
Even if a SSH key is compromised (perhaps it had a weak pass-phrase and the laptop storing it was stolen), then the worst damage an attacker can do, is to add garbage history in Mercurial. The protocol used is inherently append-only, so nothing can be deleted with hg push.
For HTTPS, the authentication is done by the front-end webserver. This means that you can require client-site certificates if you want and so get security like the SSH public key authentication above.
