Bridging firewalls, honeynet.org rc.firewall, and UML honeypots

[Mike Tremoulet <coffeemike () gmail com>]

All --

I've read everything I can get my hands on, and I'm stumped.

I'm running Gentoo on my linux machine at home with a 2.6.6 kernel.
I've compiled a 2.4.24 UML kernel that boots into a Debian install
that I want to use as my honeypot.  I have managed to create a bridge,
bring up the Debian image, and successfully network both the Gentoo
and Debian systems on my home network.  (These both do sit behind a
D-Link wireless router.)  Originally, I had iptables and all its
features compiled into my host kernel, but I've now pulled them out
into modules.

However, I'm not able to set up the firewall rules correctly on the
Gentoo host to allow for networking.  I've pulled down the latest
rc.firewall script from honeynet.org, and configured it for my setup
(see below).  When I run the script, however, nothing is logged on my
host and no network is visible from the guest.  I've worked through
most of the script by hand, implemented only the TCP logging part of
the script, which did log to the host.  Below is an excerpt from the
logs for connections generated *from* the guest honeypot machine. 
They show up as inbound TCP traffic (not outbound), from the bridge to
the bridge, with correct devices and src/dst data.

Nov  9 08:53:16 localhost kernel: INBOUND TCP: IN=br0 OUT=br0
PHYSIN=honeyeth0 PHYSOUT=eth0 SRC=192.168.1.15 DST=63.247.137.8 LEN=60
TOS=0x10 PREC=0x00 TTL=64 ID=39110 DF PROTO=TCP SPT=1033 DPT=21
WINDOW=5840 RES=0x00 SYN URGP=0
Nov  9 08:53:41 localhost kernel: INBOUND TCP: IN=br0 OUT=br0
PHYSIN=honeyeth0 PHYSOUT=eth0 SRC=192.168.1.15 DST=66.39.119.133
LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=55441 DF PROTO=TCP SPT=1034 DPT=21
WINDOW=5840 RES=0x00 SYN URGP=0
Nov  9 08:53:44 localhost kernel: INBOUND TCP: IN=br0 OUT=br0
PHYSIN=honeyeth0 PHYSOUT=eth0 SRC=192.168.1.15 DST=66.39.119.133
LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=55442 DF PROTO=TCP SPT=1034 DPT=21
WINDOW=5840 RES=0x00 SYN URGP=0
Nov  9 08:57:33 localhost kernel: INBOUND TCP: IN=br0 OUT=br0
PHYSIN=honeyeth0 PHYSOUT=eth0 SRC=192.168.1.15 DST=66.39.119.133
LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=28914 DF PROTO=TCP SPT=1035 DPT=21
WINDOW=5840 RES=0x00 SYN URGP=0

I'm just not sure how to debug this, or if I understand the placement
of the virtual machines correctly.  I believe that, if rc.firewall
works correctly for me, that br0 (the bridge) becomes the external
interface for my host, but also routes traffic to the guest honeypot. 
Because this is bridged and not NAT, however, the guest honeypot
should be a full-fledged member of my home network, not hidden behind
any translation on the host.  Any help in spotting the
misconfiguration would be GREATLY appreciated.

Below are the settings in my rc.firewall script:
#*************************************************************************
# USER VARIABLE SECTION
#*************************************************************************

###############
# COMMON VARS #
###############

# The MODE variable tells the script to #setup a bridge HoneyWall
# or a NATing HoneyWall.
#MODE="nat"
MODE="bridge"

# A space delimited list of honeypots IPs (public IP)
# If you are in "bridge" mode, this is the list of your
# honeypot IP's that will be behind the bridge.  If you are
# in "nat" mode, this is the list of public IPs you will
# be using for IP address translation.  Still confused?  Its
# the list of IPs the hackers will attack.
PUBLIC_IP="192.168.1.15"


### Variable for external network
INET_IFACE="eth0"                       # Firewall Public interface

### Variables for internal network
LAN_IFACE="honeyeth0"                  # Firewall interface on internal network
LAN_BCAST_ADDRESS="192.168.1.255"      # IP Broadcast range for internal network

### IPTables script can be used with the Snort-Inline filter
### You can find the current release at
###  http://www.honeynet.org/papers/honeynet/tools/
#QUEUE="yes"            # Use experimental QUEUE support
QUEUE="no"              # Do not use experimental QUEUE support

### Set the connection outbound limits for different protocols.
#SCALE="day"             # second, minute, hour, etc.
SCALE="second"             # second, minute, hour, etc.
TCPRATE="15"            # Number of TCP connections per $SCALE
UDPRATE="20"            # Number of UDP connections per $SCALE
ICMPRATE="50"           # Number of ICMP connections per $SCALE
OTHERRATE="15"          # Number of other IP connections per $SCALE

STOP_OUT="no"           # Set to yes if you don't want to allow any
                        # outbound connections.  This setting will
                        # override all RATE options if set to 'yes'.


### This section allows you to compensate for the use of sebek
#   on the honeynet.  Since sebek uses spoofed ips, sebek traffic
#   would clutter our logs with SPOOFED SOURCE entries.  Setting
#   it to yes, will drop all SEBEK_DST_IP ips before it has a
#   chance to hit the SPOOFED SOURCE ip rule.  It can also be used
#   as a hacker activity monitor by labeling this traffic as SEBEK
#   in the firewall rules.
#SEBEK="yes"
SEBEK="no"

# Allows the user to decide whether to drop the sebek packets or
# allow them to be sent outside of the Honeynet.
#SEBEK_FATE="ACCEPT"
SEBEK_FATE="DROP"

SEBEK_DST_IP="10.0.0.1"
SEBEK_DST_PORT="1101"

#SEBEK_LOG="yes"
SEBEK_LOG="no"

######################
# END OF COMMON VARS #
######################

##################################
# SPECIAL CONSIDERATION VARIABLE #
##################################

# You may want to allow unrestricted outbound DNS access.
# If you want to restrict the hosts that can access public dns servers,
# set the DNS_HOST variable to the ip of the honeypots allowed to
# make queries.  Otherwise, leave it blank and the proper set of
# ips will be assigned in order to allow all of your honeypots to
# make dns queries.
DNS_HOST=""

# List of DNS servers your honeypot(s) are allowed to go to.
# This is once a gain a space delimited list.
DNS_SVRS=""

######################################
# VARIABLES FOR MANAGEMENT INTERFACE #
######################################


# Interface for remote management.  If set to br0, it will assign
# MANAGE_IP to the bridge logical interface and allow its use
# as a management interface.  If you do not want to use a
#  management interface, set it to "none"
MANAGE_IFACE="br0"

MANAGE_IP="192.168.1.10"           # IP of management Interface
MANAGE_NETMASK="255.255.255.0"     # Netmask of management Interface

# Space delimited list of tcp ports allowed into the management interface
ALLOWED_TCP_IN="22"

# IP allowed to connect to the management interface
# If set to "any", it will allow anyone to attempt to connect.
# The notation ip/mask or a space delimited list of ips are
# allowed.
#MANAGER="any"
MANAGER="192.168.1.0/24"


####################
# END OF MANAGE VARS
####################

##########################################################
# VARIABLES THAT RESTRICT WHAT THE FIREWALL CAN SEND OUT #
##########################################################

# This variable will limit outbound Firewall connections
# to ports identified in the ALLOWED_TCP_OUT and
# ALLOWED_UDP_OUT variables.  If set to yes, it will
# restrict the firewall.  If set to no, it will allow all
# outbound connections generated by the firewall.
# NOTE:  There must be a management interface in bridge
# mode in order to have a firewall interface to restrict.

#RESTRICT="no"
RESTRICT="yes"

ALLOWED_UDP_OUT="53 123"
ALLOWED_TCP_OUT="22 43 80 443"

##########################
# END RESTRICT VARIABLES #
##########################

############################################
# LOCATION OF PROGRAMS USED BY THIS SCRIPT #
############################################
PATH="/sbin:/usr/sbin:/usr/local/sbin:/bin"

####################
# END OF PROG VARS #
####################




Thanks,
-- Mike