OpenWrt Forum Archive

Topic: Snort (or tcpdump) on WNDR3700?

The content of this topic has been archived on 13 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I'd like to monitor the WAN side of my WNDR3700v2 with snort. I can think of 3 ways:

1. Install snort on the WNDR and have desktop monitor WNDR's syslog for snort warnings. (WNDR processor intensive?)

2. Install tcpdump on the WNDR; raw dump output to a socket; monitor and interpret that socket with snort on the desktop. (lots of raw data over the encrypted wireless LAN)

3. Splice a read-only cable into the connection between modem and WNDR; connect that cable to a second NIC on the desktop and run a separate instance of snort to monitor that second NIC. (no load on the WNDR; desktop has plenty of oats)

I'd like to avoid number 3, as it'll require me to physically locate the desktop near the modem.

Is anyone doing something along the lines of 1 or 2; if so, comments please. Is it satisfactory? I'm running the basic hnyman1 software, and expect to add openvpn to the WNDR.

TIA

The router has a GbE switch, which can - in both scenarios - create substantial traffic that's too big to pump through WLAN in a sustained manner.

As part of my job, I implemented two alternative options, and both worked (though I did it on a TP-Link 1043, but that shouldn't matter).

1. use tcpdump to dump the entire set of data on a USB stick. If the stick uses ext2 with the filesystem fstab-bed in async-mode, this'll give you around 15 MBytes/s sustained. That's below the GbE range of approx. 30 Mb/s net still, but in fact, I never saw packet drops in real-life-conditions, even under very heavy load.

You can Wireshark the dumps afterwards, and if that's too much data, you can easily set flexible filters.

2. use a second router in between as you intend, but instead of soldering a cable that'll most likely trash whatever you attach it to, you could use the second router as a pass-through-sniffer. In essence, this should be possible by defining two VLANs on this second router (one for the incoming cable, one for the outgoing), bridge them and tcpdump the bridge. When I tried this on the TP-Link 1043, I found that there is a bug in it's GbE-drivers that prevent bridging at present (ticket 8701, confirmed also on three other devices). In your scenario, however, that's not a problem, because most routers have five physical ports. Here, you could, instead of performing software bridging, you could actually bridge the two VLANs physically (by plugging a regular CAT5--patchcable into two ports on the two VLANs).

In this scenario, you'd use one port for the incoming line from upstream, one for the outgoing line to the second router, two for the physical bridge and the additional WAN port for dumping the data elsewhere.


Both worked.

THANK YOU for your reply!

I'm more interested in real-time monitoring, so I won't try the first.

The second alternative confirms a fear I had - that I'd get too much data (heh.... especially given I like to stream). It also reinforces the suspicion that wiring a cable is more complicated than I had thought/hoped (and I don't want another cable)

Looks as though putting snort on the firewall is what I'll try. 

Thanks again!

98i4rtg wrote:

THANK YOU for your reply!

I'm more interested in real-time monitoring, so I won't try the first.

The second alternative confirms a fear I had - that I'd get too much data (heh.... especially given I like to stream). It also reinforces the suspicion that wiring a cable is more complicated than I had thought/hoped (and I don't want another cable)

Looks as though putting snort on the firewall is what I'll try. 

Thanks again!

Yes, that is certainly possible.
But if you're concerned about performance, it may be smarter to not run too much software onto your primary router (which hosts the firewall already), but distribute load. In this case, I'd recommend having the primary router as a firewall and then place other potentially required software on other routers in the site system (like samba hosting, tcpdumping, mail-serving, webmail, etc.) as a means of "supersimple load balancing".

Also from a configuration management POV, my client wanted a modular approach that allowed him to plug in our out pieces of the system by just adding or removing a physical device, rather than fiddling with router settings. So I went for "a chain of cheap routers", each serving one particular service, so that if a client wanted to get rid of packet sniffing, he could just unplug that device and shortcut into the next module in the chain.

So in short: theres no option to have snort directly on OpenWrt router? nstallation needs to be split in two mashines because of CPU power or limited storage?

janptak wrote:

So in short: theres no option to have snort directly on OpenWrt router? nstallation needs to be split in two mashines because of CPU power or limited storage?

No.
You can certainly dump via tcpdump on the very same device.
Just if you've installed many services and are concerned about the performance of the DSL connection, you may not want to place too much on your primary router. I run a mail server and a webmail server on a TP-Link 1043, and since particularly the SSL-encryption eats up much of the device's performance (plus swapping isn't really superfast), it wouldn't be too smart of me to run too many services all on the primary device.

But of course you can.

(Last edited by sborilla on 14 Sep 2011, 11:01)

The discussion might have continued from here.