SSH Port Forwards In Simpler Terms

I love SSH, I love port forwards, I love all they allow you to do. I hate my memory and all it forgets to do. I decided to write the following so I can easily recall the syntax and meaning for SSH port forwards (-L & -R).

Firstly, both use the same syntax (order of parameters doesn't matter):

ssh root@someVPS -i ~/.ssh/whateverKey -L localhost:2323:localhost:2424
ssh root@someVPS -i ~/.ssh/whateverKey -R localhost:2323:localhost:2424

Even though they are both basically From:To, They have different meanings because -L & -R have different contexts.

-L localhost:2323:localhost:2424 means:

• Create a listening socket on my local laptop (the client) listening at localhost:2323
• Any connection coming into that socket (on my local laptop) send over the SSH connection to the VPS's "localhost:2424" - assuming some app or something is listening on the server on 2424 so this connection is actually useful.
• Can be more easily understood as "-L LocalContextIP:LocalPort:RemoteContextIP:RemotePort"

-R localhost:2323:localhost:2424 means the inverse:

• Create a listening socket on the VPS at localhost:2323
• Any connection into that socket (on the remote VPS) send over the SSH connection to the Laptop's "localhost:2424"
• Can be more easily understood as "-R RemoteContextIP:RemotePort:LocalContextIP:LocalPort"

It's important to note that this isnt restricted to localhost. You can "bounce" connections either way just by changing the "To:" location.

Bounce a connection from my laptop to my VPS and out to google? sure

ssh root@someVPS -i ~/.ssh/whateverKey -L localhost:2323:google.com:80

Bounce a connection from my VPS to my laptop and out to google? sure

ssh root@someVPS -i ~/.ssh/whateverKey -R localhost:2323:google.com:80

-L & -R are really doing nothing more than telling you the direction that the traffic flows. -L is from client -> server and -R is from server -> client. 

I use the term "Context" here because that's really what it is. It consults the machine's IPs/Hostnames/whatever that is local to _that_ machine.

This means that if my VPS has an entry in /etc/hosts for "1.1.1.1 yoloswag" and my Laptop has an entry for "2.2.2.2 yoloswag" - they will mean different things depending on where in the command you place "yoloswag"

There, now I won't have to second guess myself everytime I try to create a reverse tunnel through 8 different boxes.

Stupid SSH Trick:
So if you understood what I just wrote then you should say to yourself: "wait, doesnt that mean I can forever have two tunnels passing data back and forth forever" - yes. Yes you can. And it's dumb. Here's how it works:

First anything coming on your laptops localhost:3030 gets sent out to the VPS's localhost:3131
ssh yolohax -L localhost:3030:localhost:3131
Second, anything coming into your VPS's localhost:3131, send out to your Laptops:3030:
ssh yolohax -R localhost:3131:localhost:3030

Go ahead and try it, watch your network usage. Once you issue your first transmission (echo infinitelooplol | ncat localhost 3030) you should get a constant .5-1.5Kbps in both directions. Ctrl-c'ing it won't help because it's stuck in tunnel loop. You have to kill one of the tunnels for it to end.

SSH Persistent Connection Script

I just reinstalled a test machine and forgot to save my ssh tunnel script so i decided to write a new one.

#!/bin/bash
#this script will constantly maintain (via crontab) a remote forward connection to another machine. This can
#be used as a way to connect to a jumpbox to get over a pesky NAT

remote_listen_port=2222
local_ssh_port=22
remote_host=example.com
remote_user=user1
identity_file=/home/user1/.ssh/key1

connect_string="ssh -N -T -R ${remote_listen_port}:localhost:${local_ssh_port} ${remote_user}@${remote_host} -i ${identity_file} -o ConnectTimeout=60 ServerAliveInterval=10"

process_is_up(){
 ps aux | grep "${connect_string}" | grep -v grep
}

start_bot(){
 ${connect_string}
}


if process_is_up ; then
 echo process is up, exiting
 exit 1
else
 echo process is down, starting now
 start_bot &
fi;
#add to root homedir and then crontab with the following line:
#* * * * * /root/ssh-bot-script.sh > /dev/null

Barracuda SSH Backdoors

Today i learned of an advisory posted on reddit regarding Barracuda and certain "support" ssh backdoors installed on many of their products. Unfortunately i dont have a Barracuda product to test the specific attack strings on, but i have been able to gather quite a bit of information on it:

Here is the reddit netsec article on it:
http://www.reddit.com/r/netsec/comments/176p7z/critical_ssh_backdoor_in_multiple_barracuda/

Here is the Neohapsis copypasta from SEC-consult:
http://archives.neohapsis.com/archives/fulldisclosure/2013-01/0221.html

Here is the original advisory:
https://www.sec-consult.com/fxdata/seccons/prod/temedia/advisories_txt/20130124-0_Barracuda_Appliances_Backdoor_wo_poc_v10.txt

Barracuda released several "tech alerts" about this vuln:
https://www.barracudanetworks.com/support/techalerts

Here is a full disclosure post in 2011 where someone suspected Barracuda had a backdoor (for lolz)
http://seclists.org/fulldisclosure/2011/Apr/460

Here is a blog post from 2009 (seriously) of a guy that got root access from the console and revealed overlapping details about the advisory:
http://blog.shiraj.com/2009/09/barracuda-spam-firewall-root-password/

Summary of the situation:
The following products:
     Barracuda Spam and Virus Firewall
     Barracuda Web Filter
     Barracuda Message Archiver
     Barracuda Web Application Firewall
     Barracuda Link Balancer
     Barracuda Load Balancer
     Barracuda SSL VPN
     (all including their respective virtual "Vx" versions)
vulnerable version: all versions less than Security Definition 2.0.5

All have preinstalled (undocumented) support accounts with SSH access in /etc/passwd.
The "product" support account drops you to shell without requiring SSH keys. Which also has access to the MySQL database that can modify the list of users who can log in...

Only hosts coming from certain IPs can access this ssh daemon:
192.168.200.0/24
192.168.10.0/24
205.158.110.0/24
216.129.105.0/24

There are certain reports that the "product" user requires no password.

If anyone can get me the user hashes, i can run it through my (pretty big/extensive) wordlists with rulesets.

SSH File Permissions

If your permissions on your SSH files are out of whack (i.e. id_rsa/config) than ssh will simply ignore using them out of security concerns. To fix permission issues you can run the following:


chmod 750 $HOME
chmod -R 700 $HOME/.ssh

This creates the strictest permissions for all the files under .ssh which will satisfy SSH's requirements for those files. SSH's recommendations and requirements (underlined) are below (from the manpage):

• ~/.ssh/id_rsa (OR ANY PRIV KEY) - These files contain sensitive data and should be readable by the user but not accessible by others (read/write/execute).  ssh will simply ignore a private key file if it is accessible by others.
• ~/.ssh/config - Because of the potential for abuse, this file must have strict permissions: read/write for the user, and not accessible by others.
• ~/.ssh/authorized_keys - This file is not highly sensitive, but the recommended permissions are read/write for the user, and not accessible by others.
• ~/.ssh/ - There is no general requirement to keep the entire contents of this directory secret, but the recommended permissions are read/write/execute for the user, and not accessible by others.
• ~/.rhosts - Additionally, this file must be owned by the user, and must not have write permissions for anyone else.  The recommended permission for most machines is read/write for the user, and not acces- sible by others.
• ~/.shosts - Same as rhosts
• ~/.ssh/id_rsa.pub (OR ANY PUB KEY) - These files are not sensitive and can (but need not) be readable by anyone.
• /etc/hosts.equiv - It should only be writable by root
• /etc/shosts.equiv - same as above
• /etc/ssh/ssh_known_hosts - It should be world-readable

SSH Failover

You can have SSH iterate through a list of servers until it finds the one that works.

for i in $(cat servers.txt); do
if ssh -o ConnectTimeout=10 $i; then
echo "$i is the one that works"
fi
done

The ConnectTimeout option specifies that if it cant make a connection in the specified time, than it stops trying, and moves on to the next iteration. Otherwise you can wait the default of 45 seconds.

My suggestion is to have servers.txt file actually be the host entries in ~/.ssh/config :
my_vps
my_other_vps
my_vps2


Otherwise, just type out:

user@example.com
user1@internet.com
user@internet.com
etc...

Simpler SSH Tricks

So last time i said that basically you had to create a bunch of reverse port forwards to get that whole odd tunnel system to work. Well, you actually dont.

C still has to have a reverse tunnel to B, but on A all you have to do is create a local port forward. So, on A:

ssh -L $local_listen_port:localhost:$remote_listen_port $user@$B

now just:

 ssh -D localhost:$local_socks_port $user@localhost -p$local_listen_port 

Stupid SSH Tricks - Securely jumping NATs

I have 3 machines - A,B,C.
A and C are two residential networks that are behind typical NAT routers.
B is a VPS on the internet.

My problem is that I'm at a friend's house, and i need to check my torrent downloads via a webserver on my home's internal network. How can i do this without actually exposing any listening ports to the internet?

So, basically I want to connect from A to C in order to browse several servers in C's network.

This is how to do it without opening any publicly listening ports. (the easy way is just to have C listen on a B's public interface, but that raises security concerns)

1. Have C create a remote port forward to a port on B's localhost
i.e (from C's terminal)

 ssh -R 6000:localhost:22 user@vps 

2. Have A create a remote port forward to a port on B's localhost
i.e (from A's terminal)

 ssh -R 6001:localhost:22 user@vps 

3. Have B create a remote port forward between A and C via the local ports
i.e (from B's terminal)

 ssh -R 6002:localhost:6000 localhost -p6001 

4. Have A setup a socks connection to the new local port listening on A
i.e (from A's terminal)

 ssh -D localhost:8080 localhost -p6002 

5. Point A's browser to use localhost:8080 as a socks proxy. This now will tunnel all the requests from that browser over the ssh tunnels to C's internal network.

My suggestion, is that you keep C always connected to B. This allows you to set up all the tunnels with one long command from A's terminal:

 ssh -R 6001:localhost:22 user@vps -t ssh -R 6002:localhost:6000 localhost -p6001 -t ssh -D localhost:8080 localhost -p6002


EDIT NOTE
Its important to note that you dont TECHNICALLY need to do that many reverse tunnels. 1 reverse tunnel from C to B, and then a local forward from A to B is really all thats needed. But, to each his own...