Rogue Network Link Detection

Rogue Network Link Detection

December 5, 2005

Unauthorized network links are one of the biggest problems facing large enterprise networks. Users intent on bypassing corporate proxies will often use cable modems, wireless networks, or even full-fledged T1s to access the internet. These network links can have a drastic affect on organizational security; any perimeter access controls are completely bypassed, making it nearly impossible for the administrators to effectively concentrate their monitoring and intrusion prevention efforts. This document attempts to describe different approaches and techniques that can be used to detect these rogue network links.

H D Moore (hdm[at]metasploit.com)

Rogue Network Detection Paper
Rogue Network Tools v0.01

The Rogue Network Tools (v0.01) are still very simplistic, this code was written a few years ago and has not been maintained since.

There are two components to this package - the detector and the sender. The detector (rogue_det.pl) must be run, as root, on an Internet-facing system, preferably one with as little firewalling as possible. The sender (rogue_syn.pl) is launched on the internal network against each system you would like to test.

This package has only been tested on Linux and will require modifications to use on any other operating system. The build system (build.sh) requires libpcap (and associated header files) to be installed.

Building the package is straightforward and should be performed on both the detector and sender systems:


This should create a subdirectory called 'perl_lib' that contains all of the compiled perl modules.

The next step is to run the detector script - you really should specify a port number, otherwise it will try to decode any and every TCP packet it sees. The following example configures the detector to monitor all incoming packets with destination TCP port 2005 (the default destination port for the sender):


Finally, use rogue_syn.pl to probe the target network, specifying the address of the detector system, the target IP range, and optionally the source and destination TCP ports:


On the monitoring system's console, you should now see incoming requests:


The first column is the source address, the second is the destination (the monitor), and the third is the internal IP address. The internal IP is encoded as the TCP sequence number and the ICMP data.