So, the first thing to do is to install and run a simple HTTP(S) proxy on LOCALHOST.
SSH PROXY HTTP UPDATE
The procedure to update the Nessus plugins is quite similar, however Nessus seems to need a HTTP proxy (instead of a SOCKS5 proxy) to work correctly. Run 'apt list -upgradable' to see them.Īs you can see, APT is working like a charm! Updating Nessus Scanner via HTTP proxy Get: 2 http:/ /kali.download/kali kali-rolling/main amd64 Packages ġ517 packages can be upgraded.
Get: 1 http:/ /kali.download/kali kali-rolling InRelease We need to create a new APT config file for the proxy settings, then run "apt update" to try to update the cache: # run these commands on :~$ cat /etc/apt// 12proxyĪcquire::http::proxy "socks5h://127.0.0.1:1080" Īcquire::https::proxy :~$ sudo apt update The last step is to tell APT to use the SOCKS5 proxy. This means that, from the REMOTEHOST's point of view, a SOCKS5 server is listening on 1080/TCP port on localhost. Now, we need to forward our newly created SOCKS5 port to the remote machine, and we can do it by using SSH this way: # run these commands on :~$ ssh -R 1080 :localhost: 1080 if we open a shell on REMOTEHOST and check the open ports, we'll see something like this: # run these commands on REMOTEHOST :~$ netstat -tunlp | grep 1080 The command above makes a loopback SSH connection, making SSH act as a SOCKS5 server bound on 1080/TCP port (but you can choose any different port). To do this, we use SSH this way: # run these commands on :~$ ssh -f -N -D 1080 :~$ netstat -tunlp | grep 1080 Using APT via SOCKS5 proxyįirst of all, we need to make our local machine behave like a SOCKS5 proxy. Let's call LOCALHOST our own PC (which is connected to the Internet), and REMOTEHOST the remote scanner machine that can not reach the Internet (but reachable from LOCALHOST via VPN+ SSH).
SSH PROXY HTTP HOW TO
More specifically, we'll see how to install updates or new packages on Debian-like GNU/Linux distros via APT, and how to install Tenable® Nessus Professional™ Vulnerability Scanner plugin updates. In this article I'll explain how to elegantly bypass that block - by using SSH tunneling techniques - to let the remote scanner machines reach the Internet. Actually, this is not a real problem (since the VMs are intended to reach the internal subnets only), but sometimes, when working on them, I need to install updates or new packages as well as specific tools needed on the spot, but this is not possible with the remote machines having no access to the Internet. Sometimes customers refuse to let those "blackbox" scanner machines exit from their internal perimeter. Moreover, those machines are often denied access to the Internet due to customers' security and/or networking policies. Normally, those VMs are accessible to me via SSH through a VPN. Hello everyone, and welcome to my first technical article on LinkedIn.Īs a penetration tester, I often make use of customized scanner VMs that are delivered to customers and then deployed on their hypervisors to perform planned vulnerability assessments on their internal private networks.
0 kommentar(er)
