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.luaSnortSP 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)
3 comments:
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. :-)
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.
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
Post a Comment