Cyber Security Expo
GenII Data Control for Honeynets: Understanding and Building Snort-Inline Data Control by Richard La Bella on 16/02/03

The South Florida Honeynet Project

Special thanks to Lance Spitzner for his input throughout this paper.

Since late August 2002 the South Florida Honeynet Project has been deploying and publicly demonstrating high interaction, research honeypots and their tools. One of those tools, which we will talk about today is Snort-Inline, a second generation (GenII) data control system. Our Project uses Snort-Inline to control and contain enemy packets from harming other Internet connected hosts outside of our honeynet. This paper will introduce you to GenII data control and Snort-Inline. The purpose of this paper is to help you understand what GenII data control is, its purpose, and its value. Also included in this paper is a mini HOWTO for building your own Snort-Inline data control system. If you already deploy, or are thinking of deploying high interaction honeypots this paper will bring you up-to-speed on the latest in data control technology.

Throughout this paper you will see the term "high interaction" honeypots. There are three types of honeypots deployed today. Low interaction, medium interaction, and high interaction. A honeynet is defined as a high interaction honeypot. Of the three types of honeypots in production today high interaction honeypots offer the most opportunity for capturing the motives, tools, and tactics of our enemy.

This paper assumes you are familiar with honeypots and how they work. If not, we highly suggest you read the Honeynet Project's paper, "Honeynets". In addition to that paper, we recommend the book “Honeypots, Tracking Hackers” and "Honeypots" by Lance Spitzner.

What is Data Control and Why is it Important?

Data control is a process used to control or contain traffic flow from a honeynet to the public Internet. The purpose for data control is to protect you ( the honeynet operator) from upstream liability. Upstream liability can occur when one or more of your own Internet connected systems--in this case our honeynets--are used to attack, probe, and/or compromise other Internet connected hosts outside of your network or honeynet. Eventually, the honeynet will be compromised. There must be some type of data control trigger, tool, or application in place so the enemy can not harm the availability, integrity, and / or confidentiality of another organizations system(s). As you can see, there is a tremendous amount of risk associated with deploying honeynets. The best way to reduce or mitigate that risk is to deploy some form of data control. The information in this paper covers the implementation and deployment of Snort-Inline, a second generation (GenII) data control system.

What is GenII Data Control?

GenII data control is the next generation of data control. It has been designed, developed, tested, and implemented by members of the Honeynet Project and the Honeynet Research Alliance. GenII incorporates firewall and intrusion detection in one system to produce a more stealthy and flexible level of data control. It can be implemented for layer2 bridging or layer3 network address translation (NAT). In this paper we will cover layer2 bridging since that is the way our data control system has been built and deployed. Within our honeynet environment, packets traverse the GenII data control system from the Internet to the honeynet using layer2 frames. The GenII data control system sits in-line between the honeynet and the Internet watching, capturing, and controlling packets as they move along the wire. The red circle in the diagram below reflects that implementation. GenII data control is a combination firewall and intrusion detection system under one roof. It's pretty robust. As you can see below Snort-Inline sits between the Internet and our Honeynet. Each bridged interface is connected to its own hub. This allows us to physically segment our honeynet from the rest of our infrastructure.

For GenII data control we use Iptables and Snort-Inline to block outbound traffic from the honeynet to the Internet. Iptables and Snort-Inline are the two core applications used in GenII data control. However, other tools are installed and configured to really make GenII data control fly as we will discuss and demonstrate in the sections to follow. For now, allow me to familiarize you with IPtables and Snort-Inline so you can understand how each application offers the functionality required for second generation data control?

IPtables is a free, stateful, Open Source firewall for Linux 2.4.x and 2.5.x. kernels. IPtables operates within the kernel inspecting packets as they come in off the network interface. Each packets header is inspected against a set of "chains". Inside each chain are a set of "rules" that determine the fate of each packet. The fate of each packet is determined by its "target". Common targets are "ACCEPT", "REJECT", "DROP", and "QUEUE". Here's an example of some custom chains used in GenII data control:

$IPTABLES -N tcpHandler
$IPTABLES -N udpHandler
$IPTABLES -N icmpHandler

Here is an example rule implemented for the tcpHandler chain:

$IPTABLES -A tcpHandler -j LOG --log-prefix "OUTBOUND CONN TCP: "
if test $QUEUE = "yes"
$IPTABLES -A tcpHandler -j QUEUE
$IPTABLES -A tcpHandler -j ACCEPT

The targets set in the rules above say to QUEUE packets if the $QUEUE variable is set to "yes". If the $QUEUE variable is set to "yes" then pass that packet to the QUEUE target. If it is set to "no" then pass the packet to the ACCEPT target where packets will not be queued but, instead will pass outbound until a connection limit has been reached. We'll explain how queuing and connection limiting work in the sections to follow.

Snort-Inline is Snort plus the ability to retrieve packets from the QUEUE target we discussed above. When we run Snort-Inline with the -Q switch this enables that functionality. When packets are read in by Snort from the QUEUE (buffer) the packet metadata and/or payload are matched against a set of snort rules. When a match is made (the packet has been identified as an enemy packet containing some type of exploit signature) Snort-Inline will determine the fate of that packet based on that rules verdict. We set our rules to Drop, therefore, Snort sets a verdict of Drop on the packet. It set the verdict using libipq's ip_set_verdict, and then passes it back to IPtables in kernel space where the verdict is implemented in the IPtables rule base policy.

A kernel module called ip_queue is responsible for passing packets from the QUEUE target in kernel space to our Snort-Inline user space application. The ip_queue module is required for Snort-Inline data control to work. It is the standard queue handler for IPv4 packets. The libipq man page states, "ip_queue is provided as an experimental module with 2.4 kernels". Ip_queue is compiled by default with Red Hat 7.3, kernel 2.4.18-3. We have tested and confirmed this to be true. So can you. Once you have your new Red Hat 7.3 (kernel 2.4.18-3) foundation up and running check the ip_queue packet handler is present. This is a good lesson to learn for troubleshooting if you need to later.

First, run "lsmod" to list your active kernel modules.

# lsmod

Second, run "modprobe ip_queue" to load the ip_queue module in kernel space.

# modprobe ip_queue

Next, check ip_queue was loaded successfully.

# lsmod

Last, remove ip_queue for the mini HOWTO we run through later.

# modprobe -r ip_queue

First Generation (GenI) Data Control
Before GenII data control we deployed (GenI) data control. GenI data control relies on a bash shell script known as to control or contain traffic from leaving the honeynet to the public Internet. GenI data control operates at Layer3 employing the IP stack of each interface to control and capture traffic. A connection limiting script known as is responsible for limiting outbound connections. There are logs which are part of the Alert toolset as well. They are (1) a daily log file- alert.log; (2) an archive log file- archive.log; (3) a unique log file- uniq.log; and (4) a log rotate script- for rotating daily logs to the archive log at the end of the day. is a single mode data capture tool. This single mode of data capture is known as "connection limiting". is used to watch, capture, control, and alert the honeynet operator of outbound packets using connection limitation. Another instance of can be used to watch, capture, alert and log inbound packets without limiting connections. In GenI data control connection limiting is the only mode available to control packets from leaving the honeynet. Connection limiting works by blocking packets after a certain threshold has been met. The threshold is equal to the number of packets allowed out before connections are blocked. This threshold or limit is set in the script. For example, if we set our script to block and alert us after it has seen its tenth packet egress the honeynet then we know our threshold has been met and the packets have been dropped. This is a good sign we have been compromised.

Alert works with Check Point Firewall 4.1 and Check Point Firewall NG's (Pre-FP1) "User Defined" and "Mail Alert" facilities. Alert was authored by Lance Spitzner of the Honeynet Project and was originally written for Solaris running Check Point Firewall 4.1. Later, the South Florida Honeynet Project modified the script to work with Check Point Firewall NG on Linux. Soon after, members of the Honeynet Research Alliance modified the Alert script to work with IPtables on Linux. Alert offers excellent logging, connection control, and alerting mechanism's via e-mail. We have tested and used Alert in production from October 2001 to June 2002 using Check Point NG on Linux 7.1. If you are interested in obtaining Alert for your own research please see Lance Spitzner's paper, Alert is an excellent script to deploy if you are just getting your feet wet with honeynets.

Advantages: has been tested and used for more than two years now. It is a mature data control script that is simple to install and configure. It offers logging and alerting via e-mail as well

Disadvantages: operates at Layer3 (IP) and relies solely on connection limiting. This makes it easy for our attacker to discover the data control system through TTL decrementing and routing. Once our enemy discovers packets are being blocked this preempts our ability to capture more of our enemy's motives, tools, and tactics. Eventually our enemy will leave the scene of the crime.

Second Generation (GenIl) Data Control
GenII data control is more stealthy and flexible. Why? Well, for one it operates at Layer2 (Data Link) which makes it a much more stealthy system for hiding data control from the enemy. There's no IP stack to worry about. If our enemy decided to run a traceroute (a command used to view router hops across the Internet) from one of our compromised honeypot's he/she wouldn't see our Layer2 data control bridge at all. Our GenII data control system remains transparent passing packets onto our ISP assigned default gateway.

There are three modes of data control operation that can be implemented for GenII data control. This makes for a much more flexible system all around. I think it's best we talk about each data control mode separately so you get a solid grasp of it all. In addition, we provided you with a single Power Point slide to demonstrate each data control mode separately. Click on the words "Live Demonstration" under each modes heading to see that mode in action. A separate browser window will pop up asking you to "Open" or "Save" the demonstration. If you have a good connection to the Internet choose open so you can see a demonstration of each mode right away, otherwise, save it to your hard drive and do what you like with it. It's yours for keeps. Enjoy!

The three modes of operation for GenII data control are:

  1. Connection Limiting Mode
  2. Snort-Inline Drop Mode
  3. Snort-Inline Replace Mode

Connection Limiting Mode
Live Demonstration
Connection limiting mode works by counting packets per protocol type (ICMP, TCP, UDP, Other) until a specified outbound packet limit has been reached for that protocol. Once a limit has been reached packets are dropped and logged. This controls the flow of traffic from reaching our enemy's destination. For example, we can set all TCP packets to be dropped after the tenth TCP packet for one hour if we like. Therefore, if our enemy were to launch a TCP type of attack then he/she would be blocked for one hour. Connection limiting is good, however, connection limiting of any type (GenI for example) has been known to restrict our ability to capture our enemy's activities over longer periods of time. The reason is once our enemy has discovered packets are being dropped (not getting to the next hop for example) our attacker will leave the scene of the crime and move onto other targets. To combat this problem we can implement Snort-Inline for drop or replace mode in conjunction with connection limiting mode. This is why GenII data control is so flexible. Let's have a look.

Snort-Inline Drop Mode
Live Demonstration
Snort-Inline drop mode works by combining IPtables, ip_queue, and Snort-Inline. Packets are passed from kernel space (IPtables) where they are sent to the QUEUE target. The QUEUE target leverages the ip_queue kernel module we spoke about earlier to copy the packets into a buffer using ipq_read. Snort uses libipq's ipq_get_packet API call to retrieve packets from the buffer. It is here, in user space where the packets are matched against a set of Snort rules. Our Snort rules are set to use the Drop option.

There are three Snort-Inline options:

Drop - The Drop option drops the packet, sends a RST (Reset) packet back to the host, then sends an alert.

Sdrop - The Sdrop option drops the packet and sends a RST packet back to the host. No alert is generated using this option

Ignore - The Ignore option drops the packet and sends an alert. No RST is sent back

Once a signature attack has been identified by Snort-Inline Snort-Inline will set a verdict on the packet using libipq's ipq_set_verdict API call to say, "drop that packet". At that point, the packet is sent back to kernel space (iptables) where a rule is generated in policy to drop that and future packets that match the verdict. Once dropped a RST (Reset) packet is sent back to the host and an alert is generated.

So you understand Snort-Inline's purpose better; we don't rely solely on connection limiting when running Snort-Inline drop mode. Rather, we increase the connection limiting threshold for outbound connections for TCP, UDP, ICMP, etc. to enable the use of Snort-Inline. In the event enemy egress activity is high and our Snort-Inline application doesn't set a verdict on packets (because there's no matching signature) then we have connection limiting to fall back on for data control. The purpose for this type of implementation is to capture more of our enemy's activities. When we set the connection limiting, packet threshold counters higher for each protocol; the purpose is to engage Snort-Inline and IPtables QUEUE support for data control. As I stated earlier, data control at this level is somewhat of a balancing act that can only be learned from experience.

Snort-Inline Replace Mode
Live Demonstration
Snort-Inline Replace mode is similar to Snort-Inline Drop Mode only the packets are not dropped. Evil packets are inspected against the Snort signatures or rules using the same functionality as discussed above. When an exploit packet is matched against a Snort signature the payload of that packet will be replaced to protect the target system or network from being exploited. Another way of wording it is to say we can "scrub" the packet. Once the packet has been modified or "scrubbed" it is then passed back down to kernel space and passed on to the Internet. Packets are not dropped. They are passed on as a harmless packets leaving our enemy wondering why their chosen exploit is not doing what it is suppose to do. For example, if our enemy decides to launch an attack from our honeynet, we can flip a single bit within the payload of a harmful packet to make it harmless. We could change "/bin/sh" to "/ben/sh" keeping our attacker from harming the shell on the remote system. Pretty slick, huh?

What Makes GenII Data Control Fly?

This section is most important for understanding the core functionality of GenII data control. In the section above we identified the two main applications used for GenII data control. They were, Iptables and Snort-Inline. Iptables offers the firewall functionality and Snort-Inline offers IDS functionality. I mentioned in the section above that there were other tools Iptables and Snort-Inline must rely on to really make GenII fly?

Those tools are:

  • libipq
  • libpcap
  • Bridge-Utils
  • Latest Snort Rules
  • rc.firewall script

Let’s look at each of these tools in more detail.

libipq is a development library or API for iptables or Netfilter packet queuing. Packet queuing is a process whereby packets are passed from out of the stack in kernel space to a user space application where a verdict can be made on what to do with that packet. The verdict might be one of DROP, or "modify/replace" the packet and sent back down to kernel space where the verdict can be implemented by IPtables. I like to think of libipq as the bridge between kernel to user mode packet delivery and determination.

libpcap is a packet capture library used by most Open Source sniffers. It is libpcap that provides the ability for sniffer applications such as TCPdump and Snort to grab packets from off the wire. Although libpcap is not necessarily used for GenII data control it must be installed for Snort-Inline to compile successfully. If and/or when you decide to run your data capture on the same system libpcap will be neccessary. Since Libpcap comes as an option to be installed with most Linux kernels these days there's never any real need to download the source or binary package seperately. Check your system for libpcap.

Bridge-Utils is used to set up the Linux Ethernet bridge.

Latest Snort Rules
You can find the latest set of Snort rules or signatures on the Snort site. These rules are set to Alert by default. Because we are running Snort-Inline in "Drop Mode" we set most of our rules to drop. The mini HOWTO below will show you how you can set rules from Alert to Drop.

rc.firewall Script
The rc.firewall script is everything you need to set up the GenII data control system. I like to think of this script as the keys to the car. The author of the rc.firewall script is Rob McMillen. The rc.firewall script sets up the GenII data control system. The next section is devoted to understanding how rc.firewall works for setting up connection limiting, Snort-Inline mode, your bridge interfaces, and remote management for your GenII system as well.

By now you have a better understanding of the importance of data control. Data control is the best way to protect you and other organizations connected to the Internet from being stalked and compromised by your own honeynet. GenII data control is a combination firewall and intrusion detection system centralized within one box. The two applications that make up this data control are Iptables and Snort-Inline. The glue used for bringing iptables and snort-inline together to achieve a stealthy, robust form of data control are libipq, bridge-utils, and Rob McMillen’s rc.firewall script. As you soon will see, Rob McMillens rc.firewall script are the keys to the car. We'll talk more about rc.firewall in the next section below.

Building Snort-Inline: A Mini HOWTO

In this section we walk you through a simple build for implementing and deploying GenII data control in Snort-Inline Drop mode. Our data control system is running on Red Hat Linux 7.3, kernel 2.4.18-3. If you are running a 2.4.x kernel other than 2.4.18-3, or a 2.5.x kernel you must obtain a bridge firewalling patch to support bridging with IPtables/Netfilter. At this point, we will assume you are running kernel 2.4.18-3 for this mini HOWTO. Kernel 2.4.18-3 ships with built in support for bridging and bridge firewalling support. To obtain bridge firewalling support patches for 2.4.x, or 2.5.x we direct you to:

Checking your kernel for bridge and bridge firewall support
To check that you have bridging and bridge firewall support compiled into your kernel change to the directory where you have your kernel source installed. For us it is the following path you see below.

# cd /usr/src/linux-2.4

Next, run "make menuconfig"

# make menuconfig

A Main Menu should pop up. Using your arrow keys to navigate up and down through the menu items arrow down to "Networking Options". In the "Networking Options" screen arrow down toward the end of the menu screen until you see the following:

<*> 802.1d Ethernet Bridging

[*]    netfilter (firewalling) support

The "*" to the left in brackets simply states both options are "built in". In other words, 802.1d Ethernet Bridging and netfilter (firewalling) support came precompiled with the 2.4.18-3 kernel. This made it very easy for us to build from the get go. We didn't have to download any patches and recompile the kernel.

Once you have confirmed your kernel has support for 802.1d Bridge and bridge firewall (netfilter/iptables) support we can begin to build the rest of our data control system. We built our GenII data control system by installing the following applications in the order listed below. We provide you with the links to download all the tools so you can build your own GenII data control system.

Download The Tools
gen2.tar.gz includes the following:

  1. IPtables-1.2.7a.tar
  2. Libpcap
  3. Snort-Inline
  4. bridge-utils-0.9.3-4.i386.rpm
  5. Acquire most recent Snort rules/signatures
  6. rc.firewall-0.4

You can download a precompiled binary of Snort-Inline as well from the Honeynet Project. It's called Linux Snort-Inline Toolkit

Instaling IPtables-1.2.7a.tar

# wget

# bzip2 -d iptables-1.2.7a.tar.bz2

# tar xvf iptables-1.2.7a.tar

# cd iptables-1.2.7a

# make KERNEL_DIR=<> (for us it was /usr/src/linux-2.4)

# make install KERNEL_DIR=<>

# make install-devel

make install-devel provides you with the libipq libraries for QUEUE support.

Installing libpcap

# wget

# tar zxvf libpcap.tar.gz

# cd libpcap-0.7.1

# ./configure && make && make install

Installing Snort-Inline

# wget

# tar zxvf snort-inline.tgz

# ./configure --enable-inline && make && make install

You must use the --enable-inline option with the configure script in order to run Snort-Inline.

Installing Bridge-Utils

# wget

# rpm -ivh bridge-utils-0.9.3-4.i386.rpm

Untarring the Latest Snort Rules

# wget

# tar zxvf snortrules-current.tar.gz

Setting Snort Rules to Drop for Snort-Inline Drop Mode
To support the Snort-Inline drop mode option we must set our rules to Drop. By default the rules are set for Alert. This is how we set are rules to drop.

Change directory to rules.

# cd /rules

Choose a set of rules you wish to set for Drop. Let's use rpc.rules for this example.

# vi rpc.rules

Last, once you have the set of rpc rules open in vi we issue the following command to change the rules from Alert to Drop.


Save your changes. That's it! Here's an example of how your rules should look for Drop mode. We use the rpc.rule signatures for this example.

drop tcp $EXTERNAL_NET any -> $HOME_NET any (msg:'RPC snmpXdmi overflow attempt'; flow:to_server,established; content:'|0000 0f9c|'; offset:0; depth:4; content:'|00018799|'; offset: 16; depth:4; reference:bugtraq,2417; reference:cve,CAN-2001-0236; reference:url,; classtype:attempted-admin; sid:569; rev:5;)
drop tcp $EXTERNAL_NET any -> $HOME_NET 32771:34000 (msg:'RPC EXPLOIT ttdbserv solaris overflow'; content: '|C0 22 3F FC A2 02 20 09 C0 2C 7F FF E2 22 3F F4|'; flow:to_server,established; dsize: >999; reference:url,; reference:bugtraq,122; reference:cve,CVE-1999-0003; reference:arachnids,242; classtype:attempted-admin; sid:570; rev:5;)
drop tcp $EXTERNAL_NET any -> $HOME_NET 32771:34000 (msg:'RPC EXPLOIT ttdbserv Solaris overflow'; flow:to_server,established; dsize: >999; content: '|00 01 86 F3 00 00 00 01 00 00 00 0F 00 00 00 01|'; reference:url,; reference:bugtraq,122; reference:cve,CVE-1999-0003; reference:arachnids,242; classtype:attempted-admin; sid:571; rev:4;)
drop tcp $EXTERNAL_NET any -> $HOME_NET 32771:34000 (msg:'RPC DOS ttdbserv solaris'; flow:to_server,established; content: '|00 01 86 F3 00 00 00 01 00 00 00 0F 00 00 00 01|';offset: 16; depth: 32; reference:bugtraq,122; reference:arachnids,241; reference:cve,CVE-1999-0003; classtype:attempted-dos; sid:572; rev:4;)

Installing The rc.firewall Script
# cp rc.firewall /etc/init.d
# chmod 766 /etc/init.d/rc.firewall

Configuring The rc.firewall Script
From this point out everything we do to build our GenII/Snort-Inline data control system will be determined by the variables we set in Rob McMillen's rc.firewall script. Rob does an excellent job of clearly describing what you need to do to configure the rc.firewall script successfully. We have provided you with a sanitized version of our script here to help you get started.

Running The rc.firewall Script
Once you have configured the variables in the script and saved your changes. We need to check ipchains is not running. If it is kill the ipchains daemon. If you don't you will not be able to run iptables. They conflict. When you are done we can run the script as shown below.

# ./rc.firewall

You should see the output of rc.firewall fly by your terminal as it loads the chains and rules you defined in the rc.firewall script. It goes by pretty quick. What I like to do is increase the output buffer in my terminal so I can scroll through the output after it's loaded. This let's me check for any errors or inconsistencies. The wonderful thing about this script is that it sets up all your bridging, management, and QUEUE support for you as well.

Running Snort-Inline
After you run rc.firewall the next step is to run Snort-Inline. We use the -Q switch to enable in-line mode.

# snort -Q -c /path/to/snort.conf

If you configured the rc.firewall script for QUEUE Mode and you do not run snort-inline QUEUED packets have nowhere to go. This scenario will cause all packets to drop. I have made that mistake a few times in the past. Whenever I bring up a new honeypot, I like to test connectivity by sending ICMP echo requests (ping) to my default gateway. While testing I run tail -f /var/log/messages on the data control system to see if the ICMP packets where passing through. One day while testing I couldn't figure out why my packets were not hitting my default gateway from the honeypot. After chasing my tail (pardon the pun) for about fifteen minutes I realized I wasn't running Snort-Inline. Once I fired up Snort-Inline I could see my ICMP test packets traverse the bridge and the echo reply's coming back.

This is the beginning of some standard output we see after we run Snort-Inline

[root@GEN2 snort]# snort -Q -c /root/rules/snort.conf
Initializing Output Plugins!
Reading from iptables
Initializing Inline mode

From looking at the output above you can see that we successfully ran snort to read in packets from iptables-our kernel space application and initialized inline mode.

Congratulations! We now have a working Snort-Inline data control system.


Data control is a must if you are running high-interaction honeypots. The purpose of data control is to protect us from upstream liability. As we learned from reading this paper data control is somewhat of a skill that can only be learned through real world experience. GenI data control's script is easy to deploy and configure making it perfect for those just getting started with high interaction honeypots. The limitation of GenI data control is that it operates one notch up in the stack at Layer3 making it easier to detect by our enemy. Also, GenI data control only works in connection limit mode. GenII data control operates at Layer2 making it difficult to detect and offers us more options to capture our enemy's motives, tools, and tactics. We can build our GenII data control system for connection limiting, or we can QUEUE enable the packets for Snort where a verdict can be set to determine the fate of each packet based on how the Snort signatures are implemented. We showed you our honeynet so you could have some information to help you place data control within your environment. We provided you with three Power Point slides to show you how each mode of data control operates. Last, we stepped through the build process of Snort-Inline data control to help you build your own GenII data control system. Everything you read about here are the tools and methodologies used by the South Florida Honeynet Project for data control. It is our mission to provide the community with information to help them achieve the same results we did. We hope you enjoy this document and look forward to hearing how we can make this and future papers even better.

Command Summary

Common commands used to manage our GenII Snort-Inline data control system.

# iptables -L                        This command will list your IPtables policy.

# iptables -F                        This command will flush the policy.

# lsmod                              This command will list all loaded kernel modules

# modprobe                           This command will load ip_queue

# modprobe -r                        This command will unload or remove ip_queue

# brctl                              This command will show you all the bridge commands you have at your disposal.

# brctl show                         This command shows you which physical interfaces are part of the logical bridge.

# tail -f /var/log/messages          This command allows you to view the messages file as all traffic traverses the GenII system.

# snort -Q -c /path/to/snort.conf    This command initializes snort-inline.

# man libipq                         This command opens up the libipq man page.

# man iptables                       This command opens up the iptables man page.


Some good reading about honeypot technologies.


If you have any questions, comments, or suggestions about the information contained in this paper send e-mail to

Good luck and have tons of fun!

Rate this article

All images, content & text (unless other ownership applies) are © copyrighted 2000 -  , All rights reserved. Comments are property of the respective posters.