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.

Why Be Stealthful?

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.

Physical and System-Level Setup

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.

Stealth Sniffing

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).

Listing 1. A Packet Dump without Hexadecimal Data

Snort's sniffing functionality works perfectly well on an interface without an IP address.

Stealthful Intrusion Detection

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.

Listing 2. A Sample snort.conf 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.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Paranoid Penguin: Stealthful Sniffing, Intrusion Detection a

Anonymous's picture

man ethers

/etc/ethers

is suppost to be another standard way to "map" MAC to IPs..

arp -s {MAC} {IP}

is still the prefered method.

ifconfig eth{x} 0.0.0.0 up

is the way to bring interface up with no IP address.

This article lacks (in my opinion) command line examples and gives "Red Hat" crap. (Red Hat is a "fair" distro) Giving the actual commands to use allows one on ANY distro to try things out!

I do the following:

ifconfig ethx down hw ether 00:00:00:00:00:00 0.0.0.0 up

assuming support is compiled into Kernel/Ethernet Driver for mac rewriting but since Promisc mode is required for Snort, assuming no ethernet hacks (mods) have been applied.

--DX

Re: Paranoid Penguin: Stealthful Sniffing, Intrusion Detection a

Anonymous's picture

although the syslog server doesn't have an ip address which will make

it harder for a cracker to find, there are clear indicators about which host

will be the syslog server from the /etc/syslog.conf file where you have

192.168.0.111 as the server ip. If the cracker tries to ping that host,

nothing will happen, of course. But a smart intruder would be wise to

that and check to see if there are arp entries for the ip. Then, seeing

that there are, it's pretty simple to change the mac address to something

else by sending another arp, or ifconfig with the server's 'steath' ip.

After that, all the syslog data will just go out to the air because there

is no syslog daemon listening to the bogus mac.

I'm not so sure that it's worth bothering to hide the syslog server

in this way since once the cracker is on your local network, you

have some really large problems.

The rest of the article about snort+acid is really nice.

Re: Paranoid Penguin: Stealthful Sniffing, Intrusion Detection a

Anonymous's picture

Couldn't you have the Snort server attached to the network using a tap, and have your hosts sending log data to an unused IP address?

Re: Paranoid Penguin: Stealthful Sniffing, Intrusion Detection a

Anonymous's picture

A smart sysadmin might disable arp on the stealth logger, then configure the stealth logger to generate alarms if logging is interrupted.

Nope a good hacker....

Anonymous's picture

would publish the hacked box's mac for that IP, then anyone picking up the arp (e.g. the switch) would send logs to the compromised box. The problem with sending to a black hole is that that you've no acknowledgement that the logs actually made it to the log server.

It's far better to use a ssh tunnel to _pull_ back the logs, and just ensure that your log server run host based filtering.

Dom

Re: Paranoid Penguin: Stealthful Sniffing and ARP manipulation

Anonymous's picture

I think you're missing the point here. A good cracker is going to be able to track down where the packets are going, that's a given. In fact, one of the first things a good cracker will generally do is kill the syslog daemon. However, having a secure loghost prevents them from covering their tracks. In this case, the syslog is for post-mortem analysis and prosecution anyway. We're not talking about a honeypot where we're monitoring an intrusion in progress.

Now, I don't know ARP very well, so help me out here. Can the compromised machine poison the ARP caches of the other hosts even if their ARP entry for the "bogus" IP address is static? I wouldn't think so, but my ARP knowledge is minimal. If the static entry sticks around, then the other machines will still be able to use the stealth logger.

I really like this idea. I'm going to try it in an even more interesting way. My plan is to build a host with two NICs and no IPs running VMware. I'll run the firewall in a VM, accessing both NICs, and other servers in other VMs, accessing only the LAN NIC. Running snort on the LAN NIC should provide stealth logging for all VMs and other machines on the LAN. Running it on the WAN NIC will give me an IDS.

The only caveat to this idea is that there is no way for the host to notify someone of an intrusion other than a phone line or serial port. This is true of the example in the article as well. Perhaps in my case, there is a way to connect the host to a VM through a null modem between the two serial ports..

Interesting stuff!

Re: Paranoid Penguin: Stealthful Sniffing, Intrusion Detection a

Anonymous's picture

exactly! I noticed that too.

Re: Paranoid Penguin: Stealthful Sniffing, Intrusion Detection a

Anonymous's picture

You can easily avoid this by keeping a bogus ip of 192.168.1.111 however instead of using a static ARP entry, just sniff the same network say your in that /24 192.168.1.111/24 then you'll be able to get those packets as the router should broadcast it out that subnet.

Re: Paranoid Penguin: Stealthful Sniffing, Intrusion Detection a

Anonymous's picture

hehe me tooo,,,,,

Re: Paranoid Penguin: Stealthful Sniffing, Intrusion Detection a

Anonymous's picture

Wow...this is amazing....I know Linux is ahead of its time but this is a little crazy...

An article posted in the future!!

"on Tuesday, October 01, 2002"

Re: Paranoid Penguin: Stealthful Sniffing, Intrusion Detection a

Colslev's picture

Hi there, have any of you used acid console to log events/alerts from snort databases . I have set this up and followed every step given to me through help documents . But My problem is now that ACID console is not logging anything . Has any body come accross this error before . I have tried everything but I cannot get a result . I went to certs website who support acid console database (there is no configureation to be done here apart from the acid.conf which I have done and the prerequisites eg phplot,php,adodb,gd etc . Does anyone know if there is more configuration work that I need to do or is there something that I am missing . Can you direct me to a full and complete setup guide for this setup as I have done everything I can at this stage and I cannot resolve the issue

Please Help me out here

Re: Paranoid Penguin: Stealthful Sniffing, Intrusion Detection a

Anonymous's picture

Time Travel. !!!! Linux Timetravel module

Re: Paranoid Penguin: Stealthful Sniffing, Intrusion Detection a

Anonymous's picture

All articles from the print magazine are posted as being on the first of the month of the cover date.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix