Sometimes I’ll have an internal security assessment lined up and the client is amenable to having a remote testing device sent to them. The goal being to be able to perform an internal penetration testsecurity assessment without having to physically be there. This setup is win-win in my opinion: cuts down on travel costs which is good for everyone. If you think about it, you don’t really need to be there, you just have to get access to the network. You can even perform wifi pen testing, as long as your remote setup is near an AP.
I like to have a dedicated interface for ONLY remote access (sshnx serverfreenx or openvpn reverse back to me), when I’m doing 100% remote assessments. Then I have a second interface for attackingscanning etc. If wireless is in scope I’ll have my third interface (wlan obviously).
When I first started setting the remote machines up I experimented quite a bit. I found that the setup was “flaky” if you simply assigned IP’s to the interfaces and hoped it worked. I messed around with trying to manually set multiple default gateways, but that didn’t work very well. I also found that a lot of tools (even the ones that allow you to choose an interface) will not sendreceive ALL traffic over the one you specify.
The solution that I chose was using IP ROUTE and IP RULE to ensure that any traffic sent to or from an interfaceIP would use the default gateway that i assigned it.
eth0 will be DHCP – It’s the interface the client can plug into their internal network. You’ll get an IP from DHCP (with the default gateway).
eth1 will be statically set, and will be for your remote access (either reverse of bind).
First we need to create a special routing table:
echo "1 pentest" >> /etc/iproute2/rt_tables
Next, we set the routes:
ip route add 10.1.1.0/24 dev eth1 src 10.1.1.2 table pentest ip route add default via 10.1.1.1 dev eth1 table pentest
Notice above we added the information to populate the “pentest” routing table. It has a route and a default gateway now.
Below we set the rules to send all the traffic to and from an IP address to the pentest routing table.
ip rule add from 10.1.1.2/32 table pentest ip rule add to 10.1.1.2/32 table pentest
Now, no matter what happens to eth0 your remote access interface is solid. You can do the same thing for a wlan interface as well. Simply create a second routing table and add the routes and rules.
I pulled most of this technique from this site. Works like a champ for my purposes!