11

I'm going to be deploying an Linux machine as a sort of public terminal at a remote location. I'd like to be able to access it remotely via SSH for maintenance but I don't want to keep a port open on the remote firewall for the rare occasions I need to access this machine. I've though about a simple script to create a reverse SSH tunnel to a machine on the outside, but I'd rather not have to have a user have to do anything when I need to access it. Any ideas?

Update: I've decided to go with my original plan of a script to create a reverse ssh tunnel. While other suggested solutions, such as port knocking would be more along the lines of what I really want to do, in this case, I don't have any access to configure the router other than walking a user through a config. shudder

baudtack
  • 490
  • 2
  • 6
  • 15
  • You have not to configure router. Linux has iptables firewall which is enough for firewall security. And making an always on ssh tunnel to server makes it vulnerable to attack it throw the host it is connected to. – Kazimieras Aliulis May 15 '09 at 09:38
  • 1
    I would have to open a port on the router however to pass anything I needed off to the linux box. The ssh tunnel isn't on always. It is going to be started by a user aat that end when I need the access to the machine. – baudtack May 15 '09 at 14:56

8 Answers8

6

I wouldn't be that worried about leaving port 22 accessible to the internet, but I would take some steps to secure it.

Firstly, disable keyboard interactive authentication and move to ssh keys.

Secondly, install something like fail2ban on your remote server to blackball IP addresses that repeatably probe your machine. Because you have setup ssh keys, there should be no authentication failures for authorized users.

Alternatively if you are able, take WerkkreWs advice and configure the firewall in front of the machine to terminate a vpn connection, then only allow the ssh daemon on the remote server to accept connections coming across that vpn.

Alternatively if your firewall can't terminate the vpn connection, you can probably forward the GRE or IPSEC packets to your linux machine, and terminate it there.

Dave Cheney
  • 18,567
  • 8
  • 49
  • 56
  • It has less to do with being concerned with a port being open and more to do with not wanting to walk a user though the process of opening up a port. I don't have any access to this router at all unfortunately. – baudtack May 13 '09 at 22:40
  • I understand and sympathize with your pain. – Dave Cheney May 13 '09 at 23:14
  • 2
    The first step in this solution would be to configure sshd to run on a non standard port. There are lots of bots knocking on port 22 out there. Choose a port that does not appear on /etc/services and "nmap HOST" does not find it. – hayalci May 14 '09 at 00:42
5

It has less to do with being concerned with a port being open and more to do with not wanting to walk a user though the process of opening up a port. I don't have any access to this router at all unfortunately.

If changing the router is completely out of the question, you may need to look at a P2P or VPN solution like Hamachi. If you setup the system to automatically establish the VPN connection at startup, then you should be able to connect in whenever you need to. Hamachi does all the firewall negotiation for you. The one drawback is you have to rely on the Hamachi servers being up and functional when you need to connect.

If you have a server that is always up, you could setup autossh so that the remote system always keeps a tunnel open and connected to your server. The one drawback is the remote system is compromised they attacker will get the keys that where used to establish the ssh session. It would be very important to keep your system that accept the ssh connection really locked down.

Below is my original answer, I had assumed that updating the router was an option.

One solution you might want to investigate if you firewall supports it, is port knocking. With some firewalls it should be possible to send out a special set of packets that the firewall notices and then temporarily opens hole through the firewall.

There are many implementations some better then others. Some use strong cryptography to make it nearly impossible for a person without the right keys to send the correct knock.

Zoredache
  • 130,897
  • 41
  • 276
  • 420
  • That sounds like a great idea! Unfortunately the firewall in question is just a simple consumer grade Linksys or some equivalent. – baudtack May 13 '09 at 21:48
  • 1
    If you can install dd-wrt you can use knockd (http://www.dd-wrt.com/wiki/index.php/Knockd) – Zoredache May 13 '09 at 21:53
  • @Zoredache True, but this is at a remote location. I have no access to this router and I'd shudder at the thought of trying to walk a user through a dd-wrt install. – baudtack May 13 '09 at 22:38
  • I do agree that this is probably the Right Way to set this up, providing that I had physical access to the router to install dd-wrt. – baudtack May 13 '09 at 22:42
  • Hamachi, since being acquired by LogMeIn, has shown abysmal consideration to Linux users. I find the product unreliable when Linux machines are part of my hamachi network. – bmb May 14 '09 at 00:19
4

It sounds like you are looking for knockd

You can install that on the linux server itself, with iptables so that it's kind of like a 2nd level firewall. Even with port 22 open on the frontend firewall, it wouldn't be open on the server, so portscans wouldn't see any open ports. Then when you send the "secret knock", all of a sudden you have an open path to port 22.

Does that make sense?

Brent
  • 22,857
  • 19
  • 70
  • 102
  • Unless I am mistaken, I'd have to forward all the knock ports as well right? Wouldn't that be obvious when someone scanned the router? They wouldn't know the order but dropping the possible combinations to 6, if I remember my how to do permutations correctly, gives them a huge head start. Or am I thinking about this wrong? – baudtack May 13 '09 at 23:01
  • While the ports used for knocking would need to be forwarded, the host running knockd doesn't actually need to reply to the source of the knocking in any way. – Zoredache May 13 '09 at 23:07
  • correct - the ports open on the first firewall will not be open on the 2nd, so to the scanner they all appear closed. No way to distinguish knocking ports from non-knocking. – Brent May 14 '09 at 00:45
3

To sum up all answers:

use ssh, but make it more obscure and secure.

For security:

  • Make sure root login is not allowed (PermitRootLogin no).
  • Limit users, which can log in by config option AllowUsers or AllowGroups.
  • Ensure it uses only 2 version ssh protocol (Protocol 2).
  • It is advisable to use only authentication keys, but password is more convenient, when there can be a need to connect to server from holiday where you have no access to authentication keys.

For obscurity:

  • Change ssh port to some random high port you would remember, like 20486. This would get rid of most automatic bruteforcers, but it would not hide it from all port scan on server.
  • Hide ability to connect to port. One way is port knocking mentioned in other answers, but you need special software, which can not be accessible everywhere. Another simple option is to use iptables firewall with recent module to create rule, which would allow to connect only on second or third try. So you know you have to try several times to connect successfully, but simple all port scan would not reveal ssh port. Rules would be similar to those:


iptables -A INPUT -m tcp -p tcp --dport 20486 -m state --state NEW -m recent --set
iptables -A INPUT -m tcp -p tcp --dport 20486 -m state --state NEW  -m recent --rcheck --seconds 60 --hitcount 2 -j ACCEPT
iptables -A INPUT -m tcp -p tcp --dport 20486 -j DROP
Kazimieras Aliulis
  • 2,324
  • 2
  • 26
  • 46
2

Scheduled task the script for your reverse ssh tunnel, or open the firewall port.

If you're worried about SSH being open to the world you could scheduled task when your maintenance period with iptables scripts and only have the port available then.

sclarson
  • 3,684
  • 22
  • 20
  • 1
    Agreed. Unless you have a way to VPN in, the only real solution is to basically open a port. If you are nervous about it you could always use a non-standard port. – WerkkreW May 13 '09 at 21:44
2

Look into port-knocking to open up your SSH tunnel.

Also, run denyhosts to lock out people after too many bad requests.

Both packages are available in the standard Ubuntu, Fedora, and RHEL repositories.

Tim Howland
  • 4,728
  • 2
  • 27
  • 21
1

Go ahead and open a port, just make it one outside of the normal range. I would make it some random port over 1024. That way hackers would be unlikely to even look for it.

Brad Gilbert
  • 2,503
  • 2
  • 21
  • 19
0

No reason not to poke the hole in the firewall if you need access to the machine remotely, however infrequently.

However, if you'd still rather not (or can't) open the port, a simple shell script could monitor some Internet available resource that you control and listen for the command to launch the reverse tunnel. Email accounts,IRC channels,and web pages come immediately to mind as trigger devices.

Of course, this is a lot more brittle and less secure than just opening the port. But I'm sure you have your reasons.

Brian
  • 925
  • 2
  • 12
  • 20