Sniffing the Network

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: 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. 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. 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. 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. 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. […]

By | December 14th, 2014|Linux, Security Consultant, Wireless|0 Comments

The value of iptables

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. […]

By | July 2nd, 2010|Security Consultant|0 Comments

netfilter/iptables split access with multiple ISPs

Quite a while back, I posted article http://www.adampalmer.me/iodigitalsec/extending-tc-and-iproute2-linux-routing-split-access-multiple-uplinks-multiple-isps-iptables-masquerading/ 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: 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. 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. 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. […]

By | February 10th, 2010|Technology|1 Comment

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

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. […]

By | October 3rd, 2009|Linux, Security Consultant, Technology|1 Comment

Security Consultant – Ports & Port Knocking

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. […]

By | September 10th, 2009|Security Consultant, Technology|3 Comments

Linux NAT Masquerading HOWTO

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 […]

By | August 20th, 2009|Technology|0 Comments

Linux PPTP (Poptop) VPN Setup with MPPE and MPPC

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. […]

By | February 15th, 2009|Linux, Technology|4 Comments

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

Follow on from: http://www.adampalmer.me/iodigitalsec/linux-on-a-mikrotik-532a-part-4-customization-debian-scripts-shaping-firewall-nat-picolcd/ 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 www.openwrt.org using Subversion. Here http://downloads.openwrt.org/kamikaze/docs/openwrt.html#x1-310002 is a great HOWTO on getting the build root environment set up on your x86 host. Also, see: http://wiki.mikrotik.com/wiki/RB500_Linux_SDK – 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. […]

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

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. bridge.sh #For setting up a simple bridge […]

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

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: […]

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

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. […]

By | September 15th, 2008|Internetworking & Routing, Linux, Technology|3 Comments

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

It’s been a while since the last post, so I thought I’d post a followup article to http://www.adampalmer.me/iodigitalsec/bandwith-limiting-with-linux-tc-and-iproute2/ 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 www.bethere.co.uk 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. […]

By | September 14th, 2008|Internetworking & Routing, Linux, Technology|6 Comments