Sniffing the Network

December 14th, 2014

This article is intended to provide a simple demonstration of how easy it is to sniff/intercept traffic on various types of networks, and serve as a warning to utilize secure methods of communication on a) untrusted networks and b) known networks with the potential for untrusted clients or administrators.

The first consideration is the topology of the network we’re connected to. To consider 5 common scenarios:

  1. Wired ethernet hub network: Hubs are becoming more and more obsolete as they are changed to switches. Multiple devices can be connected to a hub, and any data received by the hub from one device is broadcast out to all other devices. This means that all devices receive all network traffic. Not only is this an inefficient use of bandwidth, but each device is trusted to accept traffic destined for itself and to ignore traffic destined for another node. To sniff such a network, a node simply needs to switch it’s network interface card to “promiscuous mode”, meaning that it accepts all traffic received.
  2. Wired ethernet switched network: Multiple devices can be connected to a switch, however a switch has greater intelligence than a hub. The switch will inspect the traffic sent on each port, and learn the hardware (MAC) address of the client connected to a particular port. Once learned, the switch will inspect any frames it receives on a port, and forward that frame to the known recipient’s port alone. Other devices connected to the switch will not receive traffic that is not destined for them. This offers enhanced bandwidth usage over a hub. Switches rely on ARP packets which are easily forged in order to learn which devices are on which ports.
  3. Wireless open networks: Multiple devices can connect to an open wireless network. All data is broadcast across the network in plain text, and any attacker can sniff/intercept traffic being broadcast across the network. An open wireless network may present the user with a form of hotspot login page before granting internet access, however this does not detract from the network itself being open.
  4. WEP encrypted wireless network: A WEP encrypted network requires a WEP key to encrypt and decrypt network traffic. WEP has long been an outdated and insecure method of wireless network protection, and cracking a wireless network’s WEP key is fast and requires low skill. WEP is not secure. In addition, all clients connected to the network use the same WEP key to connect. That results in any user on the network with the WEP key being table to view any traffic transmitted to and from other nodes on the network.
  5. WPA/WPA2 encrypted network: A WPA/WPA2 encrypted network is significantly more secure than a WEP network. Whilst attacks exist on parts of the protocol, and extensions such as WPS, no known attack is able to recover a complex WPA/WPA2 password within an acceptable period of time. Whilst all clients connect to the network with the same password, the protocol is engineered to create different keystreams between each connected client and the access point. This means that simple sniffing in the traditional sense is not possible on the network.

Read the rest of this entry »

The value of iptables

July 2nd, 2010

A system administrator’s work is never done, especially with DDOS attacks and other security concerns. How do you block traffic from malicious sources? With the iptables command line program, it’s quite easy for an administrator to set up rules based on IP addresses or blocks of addresses.

Rather than discuss the details of the program, let’s discuss the value of installing it on your server in the first place. The rules are easy to set up, and in essence, you can easily block traffic from sources that have proven to be malicious. In theory, you could block traffic on a preemptive basis, such as refusing traffic from blocks belonging to certain ISP’s or countries. The problem with this approach is that you run a severe risk of blocking legitimate traffic.
Read the rest of this entry »

UDP Tunneling to avoid hotspot or firewall restrictions

February 24th, 2010

UDP tunneling is an attack that is often overlooked when manufacturers design wireless hotspot and other firewall/proxy based devices.

When you try and resolve a domain name, you make a request to a name server on UDP port 53. The way that a lot of wireless hotspot, firewalls and proxies work, is that your DNS request is allowed out, you get the IP for the machine you’re looking for, and then your request to the IP is redirected to the wireless hotspot login page, or through a web proxy server.

The problem is, that all port 53 UDP traffic is allowed out to anywhere, without any kind of authentication. You can therefore install OpenVPN on a remote server which by default listens in on UDP port 1194. You can change this with one configuration option to 53, and then edit your client config to connect to the server on port 53 instead. Often, other TCP/UDP ports might be allowed out, and ICMP is also sometimes a possibility. It is possible to easily tunnel your data out over TCP, UDP or ICMP as a worst case.

This type of attack worked on 5 out of 6 different wireless hotspot systems to gain access without authentication.

The one that it didn’t work on, captured all outbound 53 UDP requests, and silently redirected them to it’s own local DNS server. This is simple enough to do, so I’m not sure why more manufacturers haven’t done the same. Using iptables:

${IPTABLES} -t nat -A PREROUTING -i eth0 -p udp -m udp –dport 53 -j REDIRECT –to-port 53

These are the same type of rules used to configure transparent proxying for Squid.

Full NAT, DNAT and SNAT aka 1:1 NAT, 1 to 1 NAT

February 10th, 2010

Full NAT, DNAT and SNAT aka 1:1 NAT, 1 to 1 NAT – this is used when you want to map a dedicated external IP on an external interface to another IP on a separate interface with everything routed between them.


echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A PREROUTING -i ${EXTERNAL_IF} -d ${EXTERNAL_IP} -j DNAT –to-destination ${INTERNAL_IP}
iptables -t nat -A POSTROUTING -o ${EXTERNAL_IF} -s ${INTERNAL_IP} -j SNAT –to-source ${EXTERNAL_IP}
route add -host ${EXTERNAL_IP} ${INTERNAL_IF}

netfilter/iptables split access with multiple ISPs

February 10th, 2010

Quite a while back, I posted article

The article focuses on using the standard iproute2 tool to allow the box to attempt to balance traffic over multiple uplinks with multiple default routes. While relatively easy to set up, it has a few problems:

  1. Routes are cached, meaning that once the balancer has decided on a route to a certain IP for the first time, it will continue to use this route for a while.
  2. There is no real control over which packets end up over which route, other than some basic metrics such as source IP and destination IP.
  3. Certain long established TCP connections such as MSN or IRC die after the route cache expires and the packets begin being routed over the other connection. Logically, there should be a fix for this or theres a bug in my script, either way I gave up digging after a while, and just forced connections to given IPs over the same route each time.

I’ve recently decided to give this a go in netfilter purely. My environment is a router with a number of LAN devices, with eth0 being the LAN interface (, while eth1 and eth2 are separate ISP links with public IPs.
Read the rest of this entry »

Linux Security Freelancer – Securing a node – Where to start?

October 3rd, 2009

As a Linux Security Freelancer, I’m often asked where best to start when securing a single linux host. Whereas most would suggest configuring iptables or similar, the most effective first step in my opinion is to remove unnecessary services.

There are a number of methods that you can use to show open sockets at least:
lsof -U will list open sockets
nmap -sT -sU localhost will scan your local machine for open TCP or UDP ports
netstat -a | grep LISTEN will show all listening sockets.

Forgive me for stating the obvious, but the first thing to do is disable any open sockets or services that aren’t required. On a default install, this could include the likes of the portmapper service, identd and an smtpd.

Next, you want to suitably lock down user accounts, check passwords, and perhaps consider enforcing a secure password policy, at minimum I generally prefer at least 8 characters, at least one uppercase, one lowercase and one integer. Obviously this shouldn’t be easily guessible, nor should it just end in a ‘1’.

Once done, the next thing that you want to do is to suitably firewall the services that you do require open, and perhaps also restrict the rate of ICMPs, etc, with iptables.
Read the rest of this entry »

Security Consultant – Ports & Port Knocking

September 10th, 2009

Port Knocking is a clever and interesting method of allowing remote firewall manipulation whilst leaving all ports closed to all IPs. When I attempt to initiate a TCP connection to a remote host I send a packet with a ‘SYN’ flag, indicating my intention, along with other information such as a source port, destination port, source IP and destination IP. The target machine has the option of responding by accepting, responding by rejecting, or simply ignoring the packet alltogether, known under iptables and most other firewalls as ACCEPT, REJECT or DROP.
Read the rest of this entry »

Linux NAT Masquerading HOWTO

August 20th, 2009

Here’s a really quick rundown on setting up masquerading. You’d use this to share one internet connection between multiple local network machines. It’s what most regular ‘routers’ that your ISP sends out do and it’s really easy to set up under Linux in it’s most simplest form
Read the rest of this entry »

Linux PPTP (Poptop) VPN Setup with MPPE and MPPC

February 15th, 2009

Here’s a quick guide that I write as I’m setting up PPTP/MPPE/MPPC on a Linux server. My preferred VPN technology is OpenVPN mainly because it’s so quick and easy to set up and use, however in some cases PPTP is required chiefly when the Client wants to use the inbuilt Windows VPN capabilities rather than having to deploy 3rd party software.

My server is a Debian (of course) etch machine, with 2.6.24 (from source) kernel. My client is Windows XP Pro SP3.
Read the rest of this entry »

Linux Squid Transparent Proxy

February 9th, 2009

There are a number of reasons why you might want to use Squid in transparent mode, I won’t go into them – I’ll just explain how!

In Squid versions before 2.6, you’ll want to edit your configuration to specify:

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

In 2.6 versions and beyond, you can append ‘transparent’ to the end of your http_port option, i.e.:

http_port transparent

Squid will now be ready for transparent proxying. Now create some iptables rules to push all outbound port 80 traffic through squid:

iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 80 -j REDIRECT –to-port 3128

eth0 is the local side of your router, –dport 80 specifies a destination port of 80 (HTTP) and we’re going to redirect it to 3128 where your Squid proxy runs.

Linux on a Mikrotik 532a , Part 5 Final – OpenWRT and Custom Scripts

October 19th, 2008

Follow on from:

I’ve used OpenWrt previously to this project to build some firmwards for the Linksys Router WRT54 range. OpenWrt is an incredibly powerful and small Linux distro. Although debian is probably better suited to the reasonably powerful hardware, I wanted to give OpenWrt a go anyway.

Unless you’re running a MIPS 4Kc processor on your host which I’m guessing you’re not, you’ll either need to cross compile your binaries, or just compile them natively on the device itself. Compiling on the device works fine as long as you have the relevant packages, however if I was going to build a 2.6 kernel, I’d rather do it on an x86 quad core intel host, rather than waiting a week for the device to do it. I also wanted to minimize the writes on the CF card.

OpenWrt comes with a nice buildroot environment which you can read about and download from using Subversion.

Here is a great HOWTO on getting the build root environment set up on your x86 host.

Also, see: – this is a very complete HOWTO, which is why I’ve not covered most of the installation process and just detailed customizations.

You’ll need to select the RB5xx target for the kernel. Also, run:

make kernel_config

In your build root top directory, and add USB support (as my one is modded for USB which is not RB5xx default.

While you’re there, browse to the networking options and make sure you have everything you want, specifically the schedulers for traffic shaping.

Read the rest of this entry »

Linux on a Mikrotik 532a, Part 4 – Customization, Debian Scripts, Shaping, Firewall, NAT, picoLCD

October 11th, 2008

Follow On From: 05 Oct 08 APNIC Box – Linux on a Mikrotik 532a, Part 3 – Installing Debian, Prebuilt Disk Image

Following on from the previous article, I’ve written some scripts which you’ll find in the /root/scripts/ directory of the prebuilt image. I’ve attached and commented them here, as they could also be useful elsewhere. #For setting up a simple bridge
Read the rest of this entry »

APNIC Box – Linux on a Mikrotik 532a, Part 3 – Installing Debian, Prebuilt Disk Image

October 5th, 2008

Follow on from 01 Oct 08 APNIC Box – Linux on a Mikrotik 532a, Part 2

The device runs a 2.4.30 kernel on a debian woody (mipsel) environment. If anyone can contribute anything for 2.6.x and debian etch, that would be great.

Installation instructions:

Read the rest of this entry »

Quick Linux and Windows OpenVPN HOWTO and tutorial, including VPN routing

September 15th, 2008

OpenVPN is a popular Windows/Linux VPN Server/Client pair. I think there’s a separate GUI available for it if you’re so minded. This howto will cover command line usage only.

I’ll provide example configuration based on a Linux server and a Windows client, however the same applies pretty easily if you wanted to mix and match.

On Debian, apt-get install openvpn. On any other linux distro, use your own package manager or alternatively download from source and compile.
Read the rest of this entry »

Extending tc and iproute2. Linux routing split access multiple uplinks multiple isps iptables masquerading

September 14th, 2008

It’s been a while since the last post, so I thought I’d post a followup article to which focused on bandwidth limiting in a datacenter environment using tc and iproute2.

I’ve taken the same script but tweaked IPs and bandwith values into my office. Previously I was on a 24mbit down 2.5mbit up DSL connection courtesy of The office is only about 800m from the closest exchange which is quite nice – I generally find I get 18+mbit down and 1.5+mbit up. Not only great bandwidth, but latency is also very small and responsiveness is great, especially as a regular [constant] SSH use. Recently, despite having no business justification whatsoever, I ordered the same again for the same office. This one clocks in at about 19mbit up and 1.7mbit down – even better! Some ISPs support line bonding – I dont believe that many in the UK do, and seeing as at the time of writing, bethere were the only ISP to support anywhere close to 24mbit, I wasn’t going to try and find another.
Read the rest of this entry »