Re: Rules not triggering

[Matt Olney <molney () sourcefire com>]

Two things:

1)  Even though the load balancer may be handling "A" 3-way handshake
on the front end, a 3-way handshake still has to occur to the server
in the back.  A web server, for example, still needs to see an
established tcp connection on a listening port before it will reply.

2)  "private ip custom port" gets my attention, as most Snort rules
are port specific.  If your load balancer is passing web traffic to
port 2090 and you haven't modified your HTTP_PORTS variable then
you'll miss the traffic.  You might also want to ensure that your
HOME_NET and EXTERNAL_NET variables are set correctly for the backend
environment.

3)  The stream reassembly issue is something to think about, but most
likely this is not a concern.  The load balancer installations I've
seen pass a complete tcp session across to one server, so your back
end sensor should still see what it needs to see.

After all of that, I'd do a pcap on the snort sensor itself looking at
the traffic.  This should answer most of the questions you have.

Matt Olney

On Wed, Sep 16, 2009 at 6:13 AM,  <Gregory.Brunn () compucom com> wrote:
> All,
>
> I am currently running into a problem with a sensor that is behind a load
> balancer not triggering on alerts that our sensor in front of load balancer
> is triggering on.
>
> I have been told by device owners that the load balancer does not alter the
> traffic in anyway however I can not trust this information because after
> doing a tcp dump the on both devices the amount of traffic that the same
> crafted attack is doubled on the inside sensor.
>
> Also I have checked using tcp dump output in hex that the content of what I
> am is coming through.
>
> Also this load balancer is trading the public ip to a private ip custom
> port.
>
> I have double checked our snort configuration I have found nothing that
> might flag why this is happening.
>
> I have double checked the rule and the specific rule and it has the
> statement
>
> flow:to_server,established;
>
> My thought was that because the load balancer appears to be handling the 3
> way handshake and passing the traffic back to the private ips the rule would
> never trigger so I wrote a customer rule and removed this condition however
> the could not get the new rule to trigger.
>
> I wanted to see if anyone else was having this problem or is it possible
> that the fact the load balancer is doubling the traffic messing up the way
> snort reassembles packets.
>
> Any suggestions or help are greatly appreciated as I have spent a lot of
> time on the issue.
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Snort-users mailing list
> Snort-users () 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://www.geocrawler.com/redir-sf.php3?list=snort-users

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Snort-users mailing list
Snort-users () 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://www.geocrawler.com/redir-sf.php3?list=snort-users