all bits considered data to information to knowledge

25Sep/120

Securing SVN external access

If you are going to allow external access to your SVN installation there are few basic things that you might want to ponder that are security related, all revolving around authorization and authentication.

1. Apply "least privilege" rule to selecting accounts, and disable unused features

If setting your SVN on Windows pay closer attention to the accounts under which processes will run.
If you do not plan implement any hooks, you can run subversion on Local System Account. Same type of account could be used with Apache server.

Additionally, secure Apache server by following all the standard procedures: disabling all unnecessary modules, turning off multiple options etc.

2. Choose your access protocols wisely
There are several protocols that can be used to access SVN:
[irrelevant, by and large]
file:// - Through this protocol you get direct repository access. Works only on the same system (local disk), not over the network.

[not secure]
http:// - It is possible to use WebDAV on a Subversion-aware Apache2 server to access a repository. Works over the network (port 80).
svn:// - Access to a repository is done through an svnserve server. Works over the network (port 3690).

[the only ones that should be considered for external access]
svn+ssh:// - Same as svn://, but through an SSH tunnel (port 22).
https:// - Same as http://, but over a secure SSL connection (port 443).

Using reverse proxy/gateway to fine-tune the access is highly recommended
------------------------------------------------------------------------------------------------
The communications must encrypted either with SSL (get a real Verisign/Thawte certificate, or generate your own), or using SSH keys (instead of passwords set in open text! It does add to maintenance but is worth it ).

3. Restrict directory browsing.

You can limit the user to the one and only one directory by disabling directory browsing altogether on Apache HTTP Server level. This comes in handy when using "blanket" LDAP authentication as it might be possible to traverse directory structure by doctoring URL

Here's an example:
# Disallow browsing
<DirectoryMatch "^/.*/\.svn/">
Order deny,allow
Deny from all
</DirectoryMatch>

4. Test your installation for vulnerabilities: what you don't know will hurt you

To test SVN security we could use any of network security tools such as Nessus or free OpenVAS
----------------------------------------------------
P.S.   SVN (also: TortoiseSVN client) supports SASL (Simple Authentication and Security Layer). It adds generic authentication and encryption capabilities to any network protocol. More information can be found here

25Aug/090

To explore strange new worlds: SVN on Windows

Subversion is one of the finest version control systems out there (Ok, GIT afficionados might disagree :)), it can run on any OS out there - Linux, FreeBSD, MacOS, Windows..

Well, almost. For a number of reasons, I am running my sandbox SVN environment on Windows (Windows 2003).

Here is a stack trace of an error logged into Hudson; the build failed on check-out step:

Checking out https://XYZ.test.agilitator.com:8443/svn/Sandbox/hudson ERROR: Failed to check out https://XYZ.test.agilitator.com:8443/svn/Sandbox/hudson  org.tmatesoft.svn.core.SVNException:
svn:Path  'https://XYZ.test.agilitator.com:8443/svn/Sandbox/hudson'
is not canonicalized; there is a problem with the client.
svn: REPORT of '/svn/Sandbox/!svn/vcc/default': 400 Bad Request (https://XYZ.test.agilitator.com:8443)

This somewhat cryptic error was thrown once IP addresses to SVN repository were replaced with URL. It took us quite awhile to discover the culprit: uppercase URL.

Replacing the URL [https://XYZ.test.agilitator.com:8443 ] with this one [ https://xyz.test.agilitator.com:8443] solved the problem.

For me, this "case sensitivity" underscores Linux heritage of SVN, the Windows port was an afterthought..