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

Doug Burks doug.burks at ...11827...
Sun May 3 13:19:49 EDT 2015


Hi Chris,

Have you verified that NIC offloading features are disabled?
http://blog.securityonion.net/2011/10/when-is-full-packet-capture-not-full.html

On Sun, May 3, 2015 at 9:31 AM, Chris <berzerkatives at ...11827...> wrote:
> 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.
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users
>
> Please visit http://blog.snort.org to stay current on all the latest Snort news!



-- 
Doug Burks
Need Security Onion Training or Commercial Support?
http://securityonionsolutions.com




More information about the Snort-users mailing list