Typically the first step in attacking a remote network is to scan it for vulnerabilities. A vulnerability might be a computer running a service daemon that has a Buffer Overflow bug that can be exploited to run arbitrary commands at an elevated privilege level. Once the “vulnerability footprint” of a network is known, the attacker can focus attention on the vulnerable computer(s), gain entry, and use the compromised computer to attack other computers.
In addition to a system cracker intentionally focusing an attack on a particular network, or simply scanning to see if a vulnerability exists, there are programs (worms) that use these same vulnerabilities to spread autonomously, scanning for vulnerable systems and automatically infecting any that are discovered. The Microsoft IIS “Code Red” and “Nimda” worms are particularly high-profile examples of worms that continue to be active even today.
Also, many publicly-accessible FTP servers are misconfigured to allow anonymous write access. Many people actively scan for FTP servers seeking misconfigured servers they can use to exchange stolen software (“ warez”) and entertainment media (e.g. movies) for free.
This document describes how to configure a Linux firewall that is guarding a publicly accessible network (e.g. a “boundary network” or “DMZ”) so that the firewall will (1) automatically detect the initial scan for vulnerabilities and (2) react in real time to protect the network. In addition to simply blocking the host that is performing the scan, the firewall will (3) act to interfere with the scan, both to interfere with the attacker and to slow the spread of autonomous worms, and (4) report the scanning activity to the appropriate responsible parties.
This document also briefly covers using "tarpit" software to respond to or prevent specific types of abuse, with a focus on email.
This document's intended audience is Linux network administrators. You are assumed to have familiarity with the concepts of TCP/IP networking, firewall design principles, and with the syntax of the firewall commands in Linux. In the examples we will use the syntax as supported by the 2.2 kernel; the commands should be easy to translate to 2.4 and subsequent kernels.
You may have to rebuild your firewall kernel to enable support for Transparent Proxy, so you should be familiar with and comfortable with configuring, building, and installing customized kernels.
It is possible that these tools and techniques can be used on other Unix-flavor operating systems. If you are able to implement a scan-trap on another OS and it is similar to what is outlined here, please let me know; I'd like to include instructions for that as well.
Our scanner tarpit will be built by tying together a suite of powerful and freely-available tools and services. These include:
- Abacus Portsentry
- LaBrea
- LogSentry (formerly LogCheck)
- DShield
- MRTG
Note that we're not going to be using an intrusion-detection tool such as Snort - this document assumes you don't care to determine exactly what vulnerability the attacker or worm is trying to exploit. In fact, tarpitting the scanning traffic will interfere with the ability of an IDS tool to analyze that traffic, since it's being throttled down to nothing.
The home page for the Scanner Tarpit HOWTO is http://www.impsec.org/linux/security/scanner-tarpit.html
Please feel free to send any feedback or comments regarding this document to me at <jhardin@impsec.org>. The current version can be found at:
Thanks to Tom Liston for thinking up and coding LaBrea.
Thanks to Eric Raymond for maintaining the Jargon File, and Denis Howe for The Free On-line Dictionary of Computing.
The author's home page is at http://www.impsec.org/~jhardin/
This document is copyright © 2002-2006 by John D. Hardin. Permission is granted to redistribute it under the terms of the GNU Free Documentation License version 1.1, available at http://www.gnu.org/licenses/fdl.txt Please leave intact the links to the original document, and please notify the original author if you alter or republish this document.
THE AUTHOR IS NOT RESPONSIBLE FOR ANY DAMAGES, INCLUDING LOSS OF CONNECTIVITY, INCURRED DUE TO ACTIONS TAKEN BASED ON THE INFORMATION IN THIS DOCUMENT. BACK UP ANY AND ALL CRITICAL INFORMATION BEFORE IMPLEMENTING THE CHANGES OUTLINED IN THIS DOCUMENT.In other words, take sensible precautions and make sure you can undo what you've done.