3 Answers
3

Tunnelling is useful because it allows you to connect to any other machine on the network. Once you compromise one internal machine, you can use it as a platform for other attacks. Simply installing tools such as nmap on the compromised machine won't allow you much freedom in terms of actually exploring the network, beyond preliminary scans.

Getting a VPN connection on a network is pretty much the holy grail of tunnelling. It's the logical equivalent of actually being connected to that network directly. As such, tools that can't easily be run over a proxy, or on a remote system, can be run with relative ease. Most VPN protocols operate as an abstraction of the link layer, such that arbitrary network protocols can be translated onto the remote network. This is extremely useful for tools like ARP spoofing, where a normal SOCKS proxy won't allow arbitrary packets to be sent across. This makes it very convenient to just fire up your BT5 instance (or whatever pentesting box you're using) and jump right into the network. Furthermore, VPN traffic is encrypted and likely to be completely ignored by a firewall.

Alternatively, you might use a SOCKS proxy or even a Tor hidden service to facilitate your tunnelling needs. These are more limited, due to the level at which they relay traffic, but are easier to set up and easier to customise in order to hide traffic from a firewall / IDS.

I'd say that tunnelling is important due to the freedom that it allows with specific types of testing. This really only applies to external tests as if you start the test on the Internal network tunnelling is less important (although it could be useful for getting data out of the network).

On an external test you might find an issue that allows for command execution (e.g. SQL Injection or perhaps a buffer overflow). What you can do with that issue may well be limited (running one line commands and also you will likely only be able to use tools already installed on the vulnerable server). So If the goal of the test is to penetrate further into the Internal network, a more flexible and powerful connection makes this much easier.

In a lot of cases you won't be able to just open a port on the compromised server and connect to that, so in that case tunnelling a connection out to your server is the best way of getting a full interactive shell on the compromised system.

Typically most firewalls will allow outbound access on port 443/TCP as an example, so creating a tunnel from the compromised system to your server over that port is likely to be allowed. This can give you full interactive shell and make it easier to penetrate the network further. Also as an added bonus if you use SSL for the connection it can help to obfuscate your traffic from any Intrusion Detection Systems that are in place.

One system cannot directly access all other systems connected to the internet. Internal hosts with RFC1918 addresses are often only accessible via tunneling through a host that bridges the network you're currently on with the target host's network.

Tunneling is a useful technique for several reasons:

Provides access to systems, ports, and applications that would otherwise not be directly accessible to you / your system.

Securing data as it travels through the network. Tunneling over SSH means hosts that are sniffing / looking at traffic passing through them aren't able to read the data in most cases.

Note that "tunneling" is an encompassing term - the other posters covered this well. Generically, it just means encapsulating your traffic within some other form. A VPN, a proxy, an SSH tunnel or simply using netcat to create a tcp tunnel between systems are all examples, though you are limited only by your toolset on each host. Ptunnel would be a good example to study.