Stealthful Sniffing, Intrusion Detection and Logging
In a column about syslog [see “syslog Configuration” in the December 2001 issue of LJ] I mentioned “stealth logging”--by running your central log server without an IP address, you can hide your central log server from intruders. But log servers aren't the only type of system that can benefit from a little stealth. Network sniffers and network intrusion detection systems (NIDSes) probes can also function perfectly well without IP addresses, making them less vulnerable to network attacks than the systems they protect.
This month I demonstrate three ways to use the versatile and powerful Snort—as a stealth sniffer, a stealth NIDS probe and a stealth logger—on a network interface with no IP address. If you're already familiar with Snort, I hope you'll see how easily it can be used stealthfully. If you're new to Snort, this article may be a useful crash course for you. All Snort commands and configurations in this article work equally well on interfaces with and without IP addresses.
Running internet-connected computers is risky. Anytime you provide services, there's a chance that a hostile user might hijack the system through an application vulnerability or simply overwhelm the system with a denial-of-service attack that sends more traffic to your system than it can handle. For web servers, FTP servers and other systems that end users interact with, this risk never can be eliminated—it only can be minimized or contained.
Network probes and log servers are unique, however, because their roles are fundamentally passive; they receive data but don't need to send any. Taking advantage of their passivity by making them inaccessible from the networks they protect makes a lot of sense.
The trade-off is systems without IP addresses must be administered only from the console, or must have another network interface with an IP address. If a system has multiple interfaces, two precautions are vital. First, IP forwarding must be disabled, and second, the interface with an IP address must be connected to a different network from the sniffing/logging interface. It could, for example, be connected to a dedicated “admin” network consisting only of NIDS probes, loggers and administrative workstations.
Physically installing a network interface card (NIC) is easy. Provided that your NIC is supported by your kernel, Linux should automatically detect the NIC and load the appropriate kernel module(s).
However, different distributions handle NIC initialization in different ways. For example, after adding a second NIC to my Red Hat stealth sniffer, I had to create a new file, /etc/sysconfig/network-scripts/ifcfg-eth1, with the following contents:
DEVICE=eth1 USERCTL=no ONBOOT=yes BOOTPROTO= BROADCAST= NETWORK= NETMASK= IPADDR=
Although Red Hat's Kudzu tool automatically detected the new interface, its network-configuration script returned an error when I declined to give an IP address. By creating my own /etc/sysconfig/network-scripts/ifcfg-eth1 file, I got Red Hat to activate the new interface without actually giving it an IP address. On different distributions other steps may be required.
Once you've installed and activated your stealth NIC and connected it to the network you wish to monitor, it's time to try some stealth sniffing. For the remainder of the article I'll assume you've already installed Snort. Most Linux distributions contain their own Snort packages, and the latest version is available at www.snort.org. If you're going to use Snort as a NIDS, it's especially important to be running a recent version of Snort.
The Snort command for “sniffer mode” is simply:
snort -dvi eth1
The -d option tells Snort to decode application data. The -v option tells it to print packets to the console, and the -i option lets you specify the interface to sniff. To tell Snort to skip the hexadecimal data and show only ASCII, use the -C option (Listing 1).
Snort's sniffing functionality works perfectly well on an interface without an IP address.
Intrusion detection is a big topic, and Snort's intrusion detection abilities are diverse and powerful. Before we go any further, then, I want to stress that I'm only scratching the surface: running Snort with a near-default configuration file, using only the included rules, is not the most effective way to use Snort as a NIDS. I'm describing this method here because it's a simple and fast way to get started with NIDS.
To start using Snort in NIDS mode, all you need to do is edit the file /etc/snort/snort.conf and start Snort in dæmon mode. Then, periodically update the Snort rules referenced in snort.conf as new attack signatures become available. Let's briefly discuss each of these steps.
Although you can specify any configuration file you like with Snort's -c startup option, most people use /etc/snort/snort.conf. For the remainder of this article I'll assume that's your choice too. Listing 2 shows a truncated but syntactically complete Snort configuration file.
As you can see, a Snort configuration consists of global options, variable declarations, “preprocessor” statements, “output” statements and Snort rules. Global options (“config” statements) provide a handy means of setting most of the options that also can be passed to Snort via startup flags, which saves typing.
Variables are used by Snort rules to make attack detection more accurate. For example, by specifying the IP address of your local name servers via the DNS_SERVERS variable, Snort will disregard certain types of packets sent by your DNS servers that, in other circumstances, might look like attacks.
Preprocessor statements are used to configure preprocessor modules, which are Snort components that act on or alter packets prior to matching them against rules. For example, the preprocessor frag2 re-assembles fragmented packets, and it also watches out for IP-fragment-based attacks and other fragment-related anomalies.
Output statements configure postprocessor modules, which provide different means of logging or otherwise archiving Snort alerts and observed packets. For example, the database postprocessor can be used to log packets to a MySQL database for later correlation and analysis by tools such as ACID (www.andrew.cmu.edu/~rdanyliw/snort/snortacid.html).
Finally, rules can be listed either directly, as with Listing 2's “Cisco Catalyst Remote Access” alert, or in included text files, as with the remainder of Listing 2. The latter method makes it easy to use the rule files maintained by the Snort team at www.snort.org/dl/signatures/snortrules.tar.gz (updated every 30 minutes!) or the ArachNID rules at www.whitehats.com/ids.
To start Snort in NIDS mode using this configuration file, execute this command:
snort -c /etc/snort/snort.conf -D -i eth1
Remember that in earlier examples we set up eth1 as our stealth interface.
By default, Snort will log alerts to /var/log/snort/alert and port-scanning activity to /var/log/snort/portscan.log. Packets referenced in alerts will be logged to subdirectories of /var/log/snort, as described in Listing 3.
A dedicated NIDS probe will need to start Snort in its boot routine. The official Snort RPM automatically installs the startup script /etc/init.d/snortd. Once you've configured Snort to your satisfaction, activate this script for the desired runlevels with the chkconfig command. You may need to write your own startup script if you installed Snort from source.
Running Snort in NIDS mode deserves its own article, even a whole series of articles, but this is enough to illustrate that Snort can be used with a non-IP-addressed interface and to show how to get started with NIDS mode.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Build a Skype Server for Your Home Phone System
- Tech Tip: Really Simple HTTP Server with Python
- Why Python?
- A Topic for Discussion - Open Source Feature-Richness?
- Reply to comment | Linux Journal
9 min 53 sec ago
- Not free anymore
4 hours 11 min ago
7 hours 58 min ago
- Reply to comment | Linux Journal
8 hours 6 min ago
- Understanding the Linux Kernel
10 hours 21 min ago
12 hours 51 min ago
- Kernel Problem
22 hours 54 min ago
- BASH script to log IPs on public web server
1 day 3 hours ago
1 day 6 hours ago
- Reply to comment | Linux Journal
1 day 7 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?