9

We have an internal lan (not connected to internet, all internal ip addresses, behind a firewall, no routing to outside), we also have a machine that sits on the edge of our lan (two nics, one on the internal lan, one on a public lan that can "see" the internet).

I need to see machines on the public lan, from the internal lan, I can SSH to the machine on the edge and tunnel my trafic to see the services that I need on the machine on the public network.

I want to know if this poses any additional security implications?

Ali
  • 723
  • 1
  • 9
  • 18

2 Answers2

6

To be able to run SSH tunneling, you must have an account on the "edge" machine. It is difficult to permit tunneling without giving a complete shell access on that machine. That's a shell as a generic user. Theoretically, Unix-like systems enforce strict security rules with regards to local users, so that giving a shell access to a user is not a big deal. In practice, if your users are potential attackers, this increases the attack surface: you have to worry about what such attackers can do to the edge machine from a shell running on that machine, as opposed to accessing the machine "from the network".

Also, if people from the internal LAN can SSH-connect to the edge machine, they are bound to try it also from the outside (i.e. from their home machine). You may or may not wish to allow that.

The common theme here is that SSH has a kind of all-or-nothing security model: you give access, or not, but it is not easy to enforce a restricted access ("you may connect by SSH on this machine but only to do this or that task"). To make a restricted access, you must set the user shell (at the Unix level) to a specific executable which does the filtering job, such as rssh, but I do not find this to be a really robust solution.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • 1
    thanks, so if the users are not potential trouble makers, and they already need to SSH into the edge machine for other reasons, both from the internal lan and from the public lan, and from home via VPN, there is no "additional" problem with tunneling all by itself, correct? – Ali Nov 30 '11 at 17:51
  • 3
    @Ali: correct. Tunneling is just having SSH do something that the users could already do, since they have a shell account on the system. – Tom Leek Nov 30 '11 at 18:04
2

If your tunnels are forwarding traffic from the internal to the public, then I don't see any additional problems. E.g. forwarding port 8080 on the private side of the edge machine to the intranet webserver on the public side. (Though if all the services you need can be SOCKS proxied, it may be easier to just do ssh -D 8080 user@edge-machine each time you need a tunnel.)

But if you have tunnels that listen on the public side of the edge box and forward traffic into the internal LAN, then you've punched a hole in your firewall. E.g. if you forward 8080 on your edge machine to 80 on some internal machine, then anyone who can see the edge machine can also see the web server on your internal machine.

bstpierre
  • 4,868
  • 1
  • 21
  • 34
  • So if I understand it correctly, having people open a tunnel when they need it by `ssh -D ...` from either side is no "additional" problem (more than giving people ssh access in the first place). – Ali Dec 01 '11 at 03:36
  • 2
    @Ali, I don't think that's quite what bstpierre said. I think bstpierre said the degree of risk depends on which direction the tunneled traffic is going. – D.W. Dec 01 '11 at 09:06
  • 1
    @Ali: D.W. has it right. Depending on how the tunnels are set up and what they expose, you may be increasing the visibility of your internal network beyond what you desire. – bstpierre Dec 01 '11 at 12:57
  • Aha! Got it, that is correct, if a tunnel exposes a vulnerable machine/service to the public side I have practically punched a hole into the defenses. – Ali Dec 01 '11 at 14:45