3

Is it secure to bind all private services only to the 127.0.0.1 address, and then use a local SSH client's local port forwarding with an RSA public / private key pair file of 4096 bits and a passphrase to access them? I understand 4096 bits to be secure for the foreseeable future provided nobody steals the passphrase to my SSH public key.

(Depending on what the public facing services are able to access of course)

(And of course after the initial key exchange...)

Diagram of said example

Also, would it help to limit the number of internal computers allowed to access it using the source address, destination port, and possibly mac address on the firewall of the server?

I suppose too I should turn off access to the root account over ssh, lest someone get in there and make changes to the hosts file.

Would it also help to limit which ports can be connected to using this method? (not sure how to do this, but I'll bet it's in the SSH config)

Is this secure why or why not? And is there anything I can do to make this more secure?

  • Is it a private server? – mikeazo Nov 24 '15 at 3:39
  • @mikeazo well it has public services, port 443 will be open, and port 80 will redirect to 443, but we snail mail out the username and passwords to it. It's a webserver, so no. – leeand00 Nov 24 '15 at 4:08
  • But you can't just register, you have to be invited, and someone has to make a username and password, you can't make your own. – leeand00 Nov 24 '15 at 4:11
4

You description of local services which you only access through secure SSH forwarding is to vague to evaluate the security of your setup. What this setup is doing is restricting the access to the service to specific hosts, but nothing more. Use of 4096 bit encryption of the transport does not magically make the service itself secure, it protects only the forwarding against sniffing and manipulation.

The following setup similar to yours I've seen several times and while it looks secure at the first glance it is not:

  • some web interface to administrate a device
  • forwarded through SSH to the local machine
  • accessible there as http(s)://127.0.0.1:some-port/

If you visit this web interface then with the same browser you use for your normal browsing an attacker can mount a CSRF attack against the server on 127.0.0.1, i.e. your forwarded administrative interface. Or it might use a DNS rebinding attack to access the device from the internet by using your browser as a relay.

Thus securing the transport and restricting the access to specific hosts is only part of securing a service. Especially with web services you have to take a look at all the usual web based attacks, which don't vanish just by using an encrypted transport. There are probably similar things to watch out for other kind of services.

  • I've added a diagram of the proposed setup. – leeand00 Nov 30 '15 at 15:18
  • 1
    @leeand00: nice picture. But from the look of it my answer still applies. – Steffen Ullrich Nov 30 '15 at 15:29
  • Alright thanks, I'll look into those other vulnerabilities. Thank you. – leeand00 Nov 30 '15 at 15:32
  • 1
    @leeand00: Being safe against CSRF does not mean it is safe against DNS rebinding, against reflected XSS or other attacks on the application layer. Generally it is a bad idea to use the same browser for sites with different security contexts. – Steffen Ullrich Nov 30 '15 at 20:54
  • 1
    @leeand00: within the browser you can access external sites and internal sites at the same time. You can visit a site full of ads and inside the same browser instance online banking. There is only the same origin policy as the isolation principle between all of these sites. This isolation is very weak and can be bypassed with CSRF, XSS, DNS rebinding etc. Thus you don't want to have a browser instance were all of these is mixed together. – Steffen Ullrich Nov 30 '15 at 21:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.