Preventing Tunneling

Privileges Down, Control Up

Attack paths shrink once privileges, segments, and management channels are consistently configured.

For Preventing Tunneling, segmentation is the lever: explicit paths, deny-by-default, and controlled management.

This limits not only the chance of incidents, but especially the scope and duration when something goes wrong.

Immediate measures (15 minutes)

• Start with MFA, least privilege, and tiering for admin accounts.
• Enforce segmentation and explicit firewall rules on critical paths.
• Embed logging, detection, and recovery testing as a structural operation.

Why this matters

The core of Preventing Tunneling is risk reduction in practice. Technical context supports the choice of measures, but implementation and assurance are central.

Defense

Now, the cynical part. Because someone has to say it.

"Our network is segmented."

Yes. That's what they all say. It's in the PowerPoint. It's in the security policy. There was once an architect who made a beautiful drawing with colored areas and arrows, and everyone nodded and said "good plan."

And then it turns out that the application server in the DMZ has a second network card that connects directly to the database VLAN, "because the application is otherwise too slow." Or that there's a management VLAN that can reach everything, and everyone in IT has access to it "for troubleshooting." Or that the firewall rules were once temporarily relaxed and never rolled back, because nobody remembers why they were there.

Segmentation that is not enforced is not segmentation. It is decoration.

But fine. There are things you can do to make tunneling more difficult. Not impossible -- nothing is impossible if the attacker has enough time and motivation -- but more difficult.

Egress filtering

Most firewalls check incoming traffic as if their lives depend on it, and let outbound traffic through without any inspection. That's like running a nightclub where the bouncer only checks who comes in, but cheerfully waves through everyone walking out with a flatscreen under their arm.

Implement egress filtering. Restrict which ports outbound traffic may use. Allow SSH only to known destinations. Force HTTP traffic through a proxy. And log everything.

# Example: only known destinations for SSH
iptables -A OUTPUT -p tcp --dport 22 -d known_ssh_server -j ACCEPT
iptables -A OUTPUT -p tcp --dport 22 -j DROP

DNS inspection

DNS tunneling works because nobody looks at DNS traffic. Change that.

• Monitor query lengths: normal DNS queries are short. DNScat2 queries are long and contain encoded data.
• Monitor query volumes: a machine making hundreds of DNS queries per minute to the same domain is suspicious.
• Use a DNS firewall that blocks known tunneling domains.
• Force all DNS traffic through your own resolvers and block direct DNS to external servers.

Network monitoring

Deploy an IDS/IPS that recognizes tunneling patterns:

• SSH over non-standard ports
• HTTP traffic that contains no real HTTP payload (Chisel)
• Abnormal DNS patterns
• Long-lived connections to single hosts

SSH hardening

• Restrict SSH access to specific IP addresses and users
• Disable agent forwarding unless explicitly needed: AllowAgentForwarding no
• Disable TCP forwarding where not needed: AllowTcpForwarding no
• Log all SSH connections and monitor for anomalies
• Use certificate-based authentication instead of passwords

Microsegmentation

The trend in modern networks is microsegmentation: not just segmenting per VLAN, but per workload. Every application, every service, every container has its own set of firewall rules that only allow strictly necessary traffic.

It's more work. Much more work. But it means that a compromised web server can't automatically reach the database, even if they're in the same VLAN. The tunnel must not only bridge the network, but also the application layer, and that makes pivoting exponentially harder.

The cynic has the last word

You know what's most beautiful about tunneling? It perfectly demonstrates how the security industry works.

An organization spends hundreds of thousands of euros on next-generation firewalls with deep packet inspection, SSL interception, and AI-powered threat detection. They hire a consultant to design the network segmentation. They have an architecture drawing made that looks like a Mondrian artwork.

And then a penetration tester runs ssh -D 1080 on a forgotten Linux server in the DMZ and within two minutes has access to the entire internal network.

Not because the tools don't work. Not because the firewall is bad. But because somewhere, on a Tuesday afternoon at half past four, someone made an exception. "Just temporarily." "Just for this project." "Just for this server."

Temporary exceptions are the permanent residents of every security policy. They come in with the promise that they'll leave tomorrow, and five years later they're still there, wearing slippers and subscribed to cable TV.

The only defense that truly works against tunneling is not a product or a tool. It is discipline. It is the discipline to document every exception, to review it, and to remove it when it's no longer needed. It is the discipline to audit firewall rules. It is the discipline to check whether the architecture drawing still matches reality.

And discipline, as we know from human history, is precisely the thing we as a species are worst at.

Reference table

Summary

Tunneling is the art of creating hidden connections through networks that are designed to prevent those connections. From the simple elegance of SSH local port forwarding to the brute force of a Metasploit pivot chain; from the transparency of sshuttle to the ultimate stealth channel of DNS tunneling -- every tool has its place.

The choice depends on three factors:

1. What is available? SSH? HTTP? Only DNS?
2. What do you need? A single port? An entire subnet? A full SOCKS proxy?
3. How quiet do you need to be? Does detection matter, or is speed more important?

In the next chapter, we leave the tunnels and dive into the world of Linux post-incident recovery -- where the servers are quiet, the logs are extensive, and the cronjobs are treacherous.