14

Currently I am using VisualSVN Server and it's only accessible on my home network. Eventually there will be others accessing it, but for now it's just me and I would like to be able to go down to the coffee shop (or wherever) and be able to work away from the house.

Currently I'm accessing the server at http://user-pc:xx/svn/Projects/. When I setup my router to forward port XX to my server, what steps should I take to secure the server?

Keep in mind that I am doing this on Windows and while I use the regular command prompt extensively, I haven't been on SVN very long and haven't used anything other than TortoiseSVN to work with it up to this point.

Edit: The only harmful thing an attacker could do, that I'm aware of, is to: guess my port number, username, and password to get into the repository. However as the saying goes, I don't know what I don't know.

So I'm not necessarily asking for step by step instructions (although I would certainly like to have that too) as much as what things I need to keep in consideration for any kind of attack that could be made once the port is open.

bahrep
  • 664
  • 1
  • 9
  • 27
Brandon Moore
  • 456
  • 2
  • 5
  • 17
  • Can you define, what is "to protect myself?" for you? Protect your code, your Apache, your Windows from script-kiddies? – Lazy Badger Nov 20 '11 at 03:17
  • @LazyBadger See my edit –  Nov 20 '11 at 03:37
  • To answer the question you left in the flag, the SO close-voters didn't think this question deserved any more attention. They felt it was clearly off topic (like it is here, it's about a home server which is off topic) and didn't want to spend the time to explain *again* why, forgetting that for each occurrence it is someone's *first time*. I'm not a regular on SO so can't explain what their on/off topic thinking was. – sysadmin1138 Nov 20 '11 at 21:31
  • @sysadmin1138 Thanks for actually taking the time to write. I don't know what you mean by spending time to explain 'again' though since they never explained anything to begin with. I agree it seems off topic here, however it was not off topic at Stack Overflow and I would still love an explanation about that. I suspect there's not one though, and that they just arbitrarily decided they didn't like the question. – Brandon Moore Nov 20 '11 at 21:44
  • I left a flag on the SO question to see if I can get this shifted to a better home. – sysadmin1138 Nov 20 '11 at 21:45

3 Answers3

8
  1. Use https on server side, not plain http (AuthType Basic is interceptable) of use Digest auth (have to configure Apache by hand)
  2. Use (free) CA-issued cert on server, not self-signed (you can use self-signed cert, but will have (?) to verify it by eye every time)
  3. Maintain up-to-date VisualSVN Server version (with fixes for possible problems in Apache and|or SVN itself)
  4. Enable logging in httpd.conf for security-audit (no logging by default in VisualSVN Server)
Lazy Badger
  • 3,067
  • 14
  • 13
7
  1. Use good password strength to secure the VisualSVN server
  2. Use a higher port for the server e.g. 39517 instead of the default port 80 or 443. Makes it harder for an attacker to guess. The attacker would have to rely on a port scan.
  3. VisualSVN server will not allow anonymous access. You need to explicitly define users.
  4. Give user access only to people you know/trust.
One-One
  • 186
  • 2
  • 8
  • 1
    Shouldn't it be 4. Give user access only to people you trust ( don't let them use your account ) –  Nov 20 '11 at 01:48
  • Given his #3, that's what I kind of assumed he meant. –  Nov 20 '11 at 01:50
  • @orn, that is what I mean. Sorry for my English. –  Nov 20 '11 at 02:10
  • One thing I wondered about was brute force attempts to hack a password, but I forget they would have to guess the username as well so that's good. –  Nov 20 '11 at 02:12
  • @BrandonMoore they would also need to know the port. –  Nov 20 '11 at 02:15
  • Good pass doesn't help against packet sniffering in case of `AuthType Basic` – Lazy Badger Nov 20 '11 at 04:30
  • @LazyBadger That sounds like an attack that would have to be made from a server that is in the line of servers helping to communicate data between a valid client and my server. I.e. It's not an attack that could be made from just any random computer, right? And the answer to preventing this would be to use ssh? –  Nov 20 '11 at 04:44
  • @BrandonMoore: "It's not an attack that could be made from just any random computer" - yes, attacker must see packets on road. "the answer to preventing this would be to use ssh?" ssh OR https, any secure protocol in common, i.e you can wrap any insecure access method in secure (known to be secure) shell - f.e plain http with basic auth inside VPN tunnel, terminated on your side in safe point – Lazy Badger Nov 20 '11 at 05:02
  • I used to be desaivv. This is almost 3 years old, post has been closed, but always use HTTPS for your communication with the server. A self signed certificate works here best. – One-One May 22 '14 at 14:46
0

I would recommend using ssh access to your svn server. I personally prefer public/private key authentication.

Even with that, desaivv's suggestions are also things that I would recommend.

  • Thanks Robert. In my google searches that's what I've found everyone says... but I haven't yet found any simple instructions on doing it with VisualSVN. Eventually I will learn about this stuff but in the meantime if you think you know of a laymen's guide to setting up ssh that might be simpler than the ones I've come across I would love to see it. –  Nov 20 '11 at 03:57
  • For client configuration: http://www.visualsvn.com/support/topic/00008/ –  Nov 20 '11 at 04:00
  • It looks like this book: http://my.safaribooksonline.com/book/-/9781849513449/using-ssl-with-tortoisesvn/ch10lvl1sec03?reader=pf&readerfullscreen=&readerleftmenu=1#X2ludGVybmFsX0ZsYXNoUmVhZGVyP3htbGlkPTk3ODE4NDk1MTM0NDkvMjE0 has an entire chapter around VisualSVN and ssh (Chapter 10). –  Nov 20 '11 at 04:05
  • robert: Actually I did see that page. But it looks like that's just providing one piece of the puzzle. I don't know how to make public/private keys, if I need to do anything with Apache server or Windows, or my firewall, etc. to setup ssh. –  Nov 20 '11 at 04:09
  • Ah, I didn't see your 2nd comment before posting the one above. That book looks like it might be just what I need. –  Nov 20 '11 at 04:11
  • 1
    @robertvoliva - VisualSVN **Server** is http/https access protocol **only**, for svn+ssh:// another solution **must** to be used – Lazy Badger Nov 20 '11 at 04:28
  • @LazyBadger If that's the case then what is the webpage he referenced above talking about? (visualsvn.com/support/topic/00008) –  Nov 20 '11 at 04:39
  • 1
    @brandon-moore No, it's about ssh-tunnels from client (TortoiseSVN) to SSH-capable server, which is **not VisualSVN Server** – Lazy Badger Nov 20 '11 at 04:43
  • @LazyBadger Ok... that certainly makes sense but I guess I'm just confused as to why that would be on the VisualSVN website if you can't use ssh with them. –  Nov 20 '11 at 04:50
  • 1
    VisualSVN (not server) is add-on for client-access to SVN-repo, protocol-agnostic, relied on existing svn-client. Support-forum have two separate main category, link from "VisualSVN" category, unrelated to server – Lazy Badger Nov 20 '11 at 05:06
  • @LazyBadger Oooooh, I had totally forgotten about the their plugin when I was reading that. Thanks! –  Nov 20 '11 at 05:16