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
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
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
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.
Second, run "modprobe ip_queue" to load the ip_queue module in kernel
# modprobe ip_queue
Next, check ip_queue was loaded successfully.
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 alert.sh 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 alert.sh 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- rotate.sh-responsible
for rotating daily logs to the archive log at the end of the day. Alert.sh is
a single mode data capture tool. This single mode of data capture is known as
"connection limiting". Alert.sh is used to watch, capture, control,
and alert the honeynet operator of outbound packets using connection limitation.
Another instance of Alert.sh 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 alert.sh script. For example,
if we set our alert.sh 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
Alert is an excellent script to deploy if you are just getting your feet wet
Advantages: Alert.sh 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: Alert.sh 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
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:
- Connection Limiting Mode
- Snort-Inline Drop Mode
- Snort-Inline Replace Mode
Connection Limiting Mode
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
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
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:
- 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.
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
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
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
includes the following:
- Acquire most recent Snort rules/signatures
You can download a precompiled binary of Snort-Inline as well from the Honeynet
Project. It's called Linux
# wget http://www.netfilter.org/files/iptables-1.2.7a.tar.bz2
# 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.
# wget http://www.tcpdump.org/release/libpcap-0.7.1.tar.gz
# tar zxvf libpcap.tar.gz
# cd libpcap-0.7.1
# ./configure && make && make install
# wget http://www.snort.org/dl/contrib/patches/inline/snort-inline.tgz
# tar zxvf snort-inline.tgz
# ./configure --enable-inline && make && make
You must use the --enable-inline option with the configure script in order
to run Snort-Inline.
# wget ftp://rpmfind.net/linux/redhat/7.3/en/os/i386/RedHat/RPMS/bridge-utils-0.9.3-4.i386.rpm
# rpm -ivh bridge-utils-0.9.3-4.i386.rpm
Untarring the Latest Snort Rules
# wget http://www.snort.org/dl/rules/snortrules-current.tar.gz
# tar zxvf snortrules-current.tar.gz
Setting Snort Rules to Drop for Snort-Inline Drop
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
# 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;
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,www.cert.org/advisories/CA-2001-27.html;
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,www.cert.org/advisories/CA-2001-27.html;
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.
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.
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
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 alert.sh 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
Common commands used to manage our GenII Snort-Inline data control system.
This command will list your IPtables policy.
This command will flush the policy.
This command will list all loaded kernel modules
This command will load ip_queue
This command will unload or remove ip_queue
This command will show you all the bridge commands you have at your disposal.
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.
-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 firstname.lastname@example.org.
Good luck and have tons of fun!