Netsh
There is a native way to create a port forward on Windows we should explore:
the built-in firewall configuration tool Netsh, also known as Network Shell.
Using Netsh, we can set up a port forward with the portproxy subcontext
within the interface context.
While Netsh requires administrative privileges
to create a port forward on Windows,
it can be very useful in some restrictive situations.
Let’s consider a slight modification of the previous scenario.
MULTISERVER03 is serving its web application
on TCP port 80 on the perimeter.
CONFLUENCE01 is no longer accessible on the WAN interface.
For simplicity, the firewall on MULTISERVER03
also allows inbound TCP port 3389,
meaning we are able to log in over RDP directly.
We want to SSH into PGDATABASE01 directly from our Kali machine.
To do this, we’ll need to create a port forward on MULTISERVER03
that will listen on the WAN interface and forward packets
to the SSH port on PGDATABASE01.
To start setting up a port forward,
let’s RDP directly into MULTISERVER03 from our Kali machine using xfreerdp again.
In our RDP session, we can run cmd.exe as administrator to open a command window.
Using this window, we can run Netsh.
We’ll instruct netsh interface to add a portproxy rule
from an IPv4 listener that is forwarded to an IPv4 port.
This will listen on port 2222 on the external-facing interface,
and forward packets to port 22 on PGDATABASE01.
Although we don’t receive any output from the command,
we can confirm that port 2222 is listening using netstat.
We can also confirm that the port forward is stored by issuing the show all command
in the netsh interface portproxy subcontext.
The port is listening, and the port forward is set up.
However, there’s a problem.
We can’t connect to port 2222 from our Kali machine.
We’ll specifically check port 2222 using nmap.
The response shows that port 2222 is filtered.
It’s most likely that the Windows Firewall
is blocking inbound connections to port 2222.
In order to access it, we need to poke a hole in the firewall on MULTISERVER03.
We can use the netsh advfirewall firewall subcontext to create the hole.
We will use the add rule command and name the rule “port_forward_ssh_2222”.
We need to use a memorable or descriptive name,
because we’ll use this name to delete the rule later on.
We’ll allow connections on the local port on the interface
with the local IP address,
using the TCP protocol...
specifically for incoming traffic.
The command completes successfully with an “Ok.” response.
We can check how the port appears from our Kali machine again.
The port is open!
We can now SSH to port 2222 on MULTISERVER03,
as though connecting to port 22 on PGDATABASE01.
Great!
We’re SSH’d into PGDATABASE01
through a port forward set up on MULTISERVER03 using Netsh.
Using netsh advfirewall firewall, we can delete the rule,
referencing it by its catchy name: “port_forward_ssh_2222”.
The command completes successfully,
and we receive confirmation that the firewall rule was deleted.
We can also delete the port forward we created.
This time we’ll use the netsh interface subcontext
to delete the portproxy we created.
We will reference the forwarding type
and the listenaddress and listenport we used when creating the rule,
so Netsh can determine which rule to delete.
When we delete the rule, we don’t get any response for a success.
Nevertheless, the command completed successfully, and the rule is deleted.
In this section, we created a port forward on Windows using the Netsh command.
We also created a firewall rule to allow inbound traffic on our listening port.
We used these in conjunction to create a working port forward
from the WAN interface of MULTISERVER03 to the SSH server of PGDATABASE01.