Nessus Scanning with SSH Proxies

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
  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

SSH Proxy

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 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….

  1. 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
  1. Redirect any SSH traffic destined to the target to the locally bound port:
iptables -t nat -I OUTPUT -p tcp --dst --dport 22 -j DNAT --to-destination
  1. Configure Nessus to not ping the remote host (it’s behind the bastion box, so won’t succeed):
    Nessus configuration

Now if you configure your Nessus scanner to target 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.