Monday, February 2, 2009

Snort 3.0 (SnortSP) Inline Bridging Mode in 3 Steps

One of the many interesting new features in Snort 3.0 (SnortSP) is the ability to run in inline bridging mode.

Step 1: Add a new function to your snort.lua file
If you followed my previous SnortSP Installation HOWTO, then the default snort.lua file is in /etc/SnortSP/snort.lua. Open the file and add the following function:

function bridge(interface1, interface2)
if interface1 == nil then
error("Two interfaces must be specified ( e.g. bridge(\"eth0\", \"eth1\") )")
end
if interface2 == nil then
error("Two interfaces must be specified ( e.g. bridge(\"eth0\", \"eth1\") )")
end
dsrc2 = {name="src2",
type="afpacket",
intf=interface1..":"..interface2,
flags=10,
snaplen=1518,
maxflows=262144,
maxidle=300,
flow_memcap=10000000}
dsrc.new(dsrc2)
eng.new("e2")
eng.link({engine="e2", source="src2"})
eng.start("e2")
end


Step 2: Start SnortSP
Start SnortSP using the following command:
sudo snortsp -L /etc/SnortSP/snort.lua
SnortSP will start up and read your new snort.lua file. You will then be greeted by the SnortSP Lua shell.

Step 3: Use the bridge() function
In the Lua shell, type the following (replacing eth0 and eth1 with the correct interfaces on your system):
bridge("eth0", "eth1")

Once the bridge is up and running, you can do the following to display packets traversing the bridge:
eng.set_display({engine="e2", display="none"})
Press the Up arrow and change "none" to "classic".
View the output.
Press the Up arrow twice to retrieve the "none" command and press Enter.

When finished, shut down SnortSP by running the following command:
ssp.shutdown()

Note that there is a bug in the SnortSP README file (and/or the SnortSP afpacket DAQ itself). The README file suggests the following:
dsrc1 = {name="src",
type="afpacket",
intf="eth2:eth3",
flags=10,
snaplen=0,
maxflows=262144,
maxidle=300,
flow_memcap=10000000}
dsrc.new(dsrc1)

Setting snaplen to 0 and passing traffic through the bridge results in segmentation fault. Per the SnortSP developers, this value should be set to 1518 for normal ethernet operation. Thanks to the SnortSP developers for their assistance with this issue.

3 comments:

  1. Hey Doug,

    I am having a hard time here. It's probably something stupid simple. But I am banging my head against the wall. :-)

    I have done everything up to the point of the NSMnow installation on Ubuntu 8.04 Server. Everything went smoothly except for a small problem. I have three interfaces. eth0 and eth1 are for my inline IDS/IPS and eth2 is configured with an address so that I can monitor remotely. I have eth0 connected via a crossover cable to the host I want to monitor. Eth1 connects to the switch to put the host online.

    When I fire up the bridge, it spawns as expected.

    SNIPPET ...
    snort> bridge("eth0", "eth1")
    Creating new data source
    Flow manager created with 262144 flow capacity
    Engine "e2" created
    Linking engine "e2" to data source "src2"
    Calling engine_start()
    [*] Data Source Config:
    Name: src2
    Type: afpacket
    Interface: eth0:eth1
    Filename:
    Snaplen: 1518
    Flags: 0x0000000A
    Display: None (0)
    Filter command:
    DAQ: 0x8078500
    User Context: 0x80ea6e0
    Max flows: 262144
    Max idle: 300
    Memcap: 10000000
    [*] Flow Manager Config:
    Max flows: 262144
    Max idle: 300
    Memcap: 10000000
    [*] AFPacket DAQ config:
    Interface: eth0:eth1
    Snaplen: 1518
    Datalink: 1
    Page Size: 4096
    Pages: 32768
    Frame Size: 1584
    Frames/Page: 2
    Frames: 65536
    Count: 0
    Packet Count: 0
    analysis context ptr: 0xb7297008
    [*] Spawning engine thread!
    e2 thread running - 2800298896 (4858)
    snort>
    ... END SNIPPET

    Yet ... I am dropping packets on the monitored host. If I run a tcpdump on eth0 or eth1 I can see that traffic is flowing perfectly. But from that box that is connected via crossover to eth0 - I cannot ping anything. For that matter, I end up with an empty ARP table.

    If I filter tcpdump to this single host that I am monitoring I see it wandering the network in search of the gateway I am trying to ping (running ping -t in a command prompt).

    SNIPPET ...
    ballantynesd@KCHOINK:~$ sudo tcpdump -i eth0 host 10.60.60.213
    tcpdump: WARNING: eth0: no IPv4 address assigned
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
    13:25:13.044266 arp who-has 10.60.60.1 tell 10.60.60.213
    13:25:18.544044 arp who-has 10.60.60.1 tell 10.60.60.213
    13:25:24.043968 arp who-has 10.60.60.1 tell 10.60.60.213

    3 packets captured
    3 packets received by filter
    0 packets dropped by kernel
    ballantynesd@KCHOINK:~$ sudo tcpdump -i eth1 host 10.60.60.213
    tcpdump: WARNING: eth1: no IPv4 address assigned
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
    13:25:29.544004 arp who-has 10.60.60.1 tell 10.60.60.213
    13:25:35.043863 arp who-has 10.60.60.1 tell 10.60.60.213
    13:25:40.543817 arp who-has 10.60.60.1 tell 10.60.60.213
    ... END SNIPPET

    I am guessing that this might have something to do with the switch caching ARP entries. Do you think that could be the case? In other words ... is the host that I slipped inline now being found on the MAC address which belongs to eth0 in my monitoring box?

    I have also considered that ip forwarding should be enabled. But I would think that it should be DISABLED. I have tried flipping the bit. It didn't make a difference. I have also tried passing "promisc" and "-arp" to eth0 and eth1 when I am bringing them up ... but it looks like Snort does that for me when I bridge them (according to dmesg).

    Anyhow, thanks for getting me this far. And thanks in advance for any insight you may have. :-)

    ReplyDelete
  2. Hello Doug,

    I hope I am not bombarding you with comments. You can tell me to shut up at any time. ;-)

    I wanted to tell you that I moved my snortsp box back onto my desk and hooked everything up in a test environment. With an XP workstation placed in-line with the Snort box, everything works like it's supposed to. I am able to open up sguil and watch sensors get tripped while I launch attacks against the box.

    I think my problem off in the server environment is dealing with a feisty switch and it's auto-negotiation (or lack thereof). Everything on the switch is giga, but I am trying to reroute it to 100Mbs nic's. At any rate - it has nothing to do with my snort setup.

    Thanks again for the tutorials. I am learning a lot, and these were a great start.

    ReplyDelete
  3. Hello again Steve,

    I'm glad you were able to determine the nature of your problem. Please let me know if you have any further questions or problems.

    Thanks,
    Doug Burks
    http://securityonion.blogspot.com

    ReplyDelete

Note: Only a member of this blog may post a comment.