[Snort-users] Trigger anomalies (on LXC container versus host)

Chris berzerkatives at ...11827...
Sun May 3 09:31:06 EDT 2015

I'm observing a problematic difference in behaviour between two
instances of Snort that are configured identically (recursive diff'ed
their config dirs, and compared their initialisation outputs) aside
from the required differences (interfaces names) as one is running
inside an LXC container, listening to its single virtual interface, and
the other instance is on the hypervisor/base OS listening to the bridge
interface that all the containers are attached to. The container
receives traffic through NAT'ing rules on the hypervisor.

What I see is that certain rules aren't being triggered on the
container instance of Snort, but are being triggered on the hypervisor.
This is despite being able to see the packets that trigger these rules
appear on both machines (hypervisor and container) using tcpdump to
view the respective interfaces that Snort is configured to listen on.
Specifically, the rules that I've noticed are being ignored are those
that involve HTTP header inspection, like GET /test.cgi.

Like I said, I can see what look like the EXACT SAME packets on these
respective interfaces, so I've tried the following troubleshooting
without any luck.

 * Switching off Snort on the hypervisor in case it was interfering.

 * Creating a rule that triggers for any packet that is considered to
   be web traffic (i.e. EXTERNAL any -> HTTP HTTP_PORT) and this
   triggers for those packets without issue, so it's not a problem with
   those variables being misconfigured.

 * Wondering whether LXC doesn't properly isolate the interfaces
   somehow, so I tried configuring the container Snort to use the
   bridge interface on the hypervisor, however it correctly wasn't able
   to use it (as it didn't exist inside the container, of course).

So I'm stuck as to where to go next. The container is where I want Snort
to be running, as it's my load balancer (including SSL termination) so
that's where I would like to detect and block rogue traffic. The only
reason that I run it on the hypervisor is to just see whether any
concerning traffic is bypassing the load balancer, and whether
undesirable traffic is being generated by services behind it.

Thanks for your time, I really hope someone can shed some light on this
frustrating situation. Very happy to answer any questions about the
setup, including configuration specifics, though they're essentially
vanilla installions on Debian Wheezy straight out of apt.

More information about the Snort-users mailing list