Today, we’ll go over one of the simplest modules provide for the Hak5 LAN Turtle. The “autossh” module is used to create an ssh session from the Turtle out to a pre-designated target server, and use the SSH proxying features to present a port for logging back into the Turtle over this tunneled proxy connection. This can be used in an environment that allows outbound SSH connections to create a connection into the internal LAN via some outside listening system. While there might be legitimate uses for this, make sure you follow corporate policy on such things before taking advantage of this feature on your work network.
To set this up, go to the Turtle shell (menu) and select:
Modules => autossh => CONFIGURE.
There are three fields that need to be filled in. The first is the “User@Host” field, where you put the target user and the target hostname or IP address for logging into the remote system. In order to make that outbound connection, the Turtle needs to know who to login as, and where to login at. This is how you tell it that.
The second field is the “Remote Port” field, and defaults to 2222. This is the port that will get established for the “dial back in via the proxy” tunnel.
The last field is the “Local Port” field, which defaults to port 22 and is fine to leave as is.
After you configure the ports, you can try to use it right away by telling it to “start,” but I generated a key pair and pushed the public key out to the target system from the command line when I tested this. I don’t think it will work without setting up a key manually, first. The Turtle does include “ssh-copy-id” if you prefer to push your key that way, and “ssh-keygen” to generate that key, but the key type should be RSA and use the “id_rsa” default naming scheme. This appears to be hard coded within the module. If you prefer a different key type, you’ll need to modify the module script to call a different key. The script is at /etc/turtle/modules/autossh if you’re looking to customize this.
After you’ve pushed your key and set up the “config” options, you can go back to the Turtle shell (menu) and select the module again, then select “START” instead of “CONFIGURE” to test it. Log into your remote target machine and see if you have a listening port per your “Remote Port” setting (default 2222.) If you do, you can try logging into the Turtle from that machine by doing “ssh -p 2222 root@localhost” (replace 2222 with whatever port number you chose to use if you overrode this default value.) You should be able to connect. If it works as expected, you can go back to the Turtle shell (menu) and select the module one more time, this time to “ENABLE” it. This will make it autossh every time the Turtle is rebooted (or powered on.)
This is equivalent to using the -R flag discussed on Monday.
Disable it when you’re not intending to use it, though. If you’re not getting the expected connection back into the Turtle, make sure there’s not a conflicting service using that “Remote Port” option you chose. If there is, change it to a port that’s not in use. Also check that firewalls aren’t blocking that port per standard troubleshooting techniques (netstat, telnet, etc.)
That’s it for this week, folks. We’ll probably cover another module next week, but with the new kids, the schedule might change without warning.
Thanks for reading!