SSH Proxying is a neat way to bounce via a bastion host to a target within a network. An example of a SSH proxy file is below:
Host bastion.securenet.local User username1 HostName 198.51.100.72 IdentityFile ~/keys/bastion-key Host host*.securenet.local IdentityFile ~/keys/secure-key User username2 ProxyCommand ssh bastion.securenet.local -W %h:%p Host host1.securenet.local HostName 203.0.113.11
SSH’ing to host1.securenet.local will proxy the connection via the bastion.
Unfortunately, Nessus does not support SSH proxying. This is a problem when scanning remote hosts behind a bastion box, especially when it is not possible to bind or connect to a new port to the bastion box due to firewall rules. Binding a port to localhost and pointing Nessus to 127.0.0.1 is also not an option as Nessus handles scanning localhost in a different way and will report issues with the scanning box itself.
In a pinch it is possible to hack around this problem by tricking the Nessus scanner into thinking it’s scanning the remote host when it is in fact connecting via a port bound to the localhost. Iptables to the rescue….
- Set up an SSH connection to your ultimate target (using SSH proxy config), binding port 22 on the target to your scanning box:
ssh -L 2223:localhost:22 host1.securenet.local
- Redirect any SSH traffic destined to the target 203.0.113.11 to the locally bound port:
iptables -t nat -I OUTPUT -p tcp --dst 203.0.113.11 --dport 22 -j DNAT --to-destination 127.0.0.1:2223
- Configure Nessus to not ping the remote host (it’s behind the bastion box, so won’t succeed):
Now if you configure your Nessus scanner to target 203.0.113.11 or host1.securenet.local , SSH will be redirected to the port bound on the scanning box, which in turn will proxy via the bastion and hit the ultimate target. “Port scanning” will be conducted via netstat, as default with any authenticated scan, allowing you to determine which ports would be exposed if you were in the local subnet with the target.