[Bro] Load Balancers

Bill Jones bill.jones at syntervision.com
Sat Feb 6 10:12:36 PST 2010


John,

Thanks for the quick response.

> Not sure what Netscalar does, but it all should act the same.  The host
> TCP stack would drop any attempted connection for which a session was
> not established regardless of what was upstream from it.  Quick and
> dirty, you sould be able to fire up tcpdump and see the session
> initialization.

That's what I'm finding strange.  After running a tcpdump capture on
the interface and analyzing it with Wireshark, I do not see any 3-way
handshakes for this particular web application.  For any HTTP GET that
I see in Wireshark that pertains to this application, when I "Follow
TCP Stream", the first entry in Wireshark is always the GET message
itself.  For all other applications on the network, doing the above
results in the first entry being the SYN.

I've generated a few dumps with the same results.  I wonder if the
load balancer is somehow keeping a session active for very long
periods (if this even makes sense).

If you have any suggestions or thoughts, I'd be very interested.


Thanks,
Bill

On Sat, Feb 6, 2010 at 12:51 PM, John Hally <JHally at ebscohost.com> wrote:
> Hi Bill,
>
> I've run BRO in the past with load balancers (Arrowpoint/Cisco CSS) and
> was able to see all traffic.  In our setup we had 2 segments; a VIP
> access link and a services trunk link where the real/origin servers
> lived.  Both of these links had physical network taps and it was as
> simple as plugging in the Ethernet, flipping the interface to
> UP/PROMISC, and starting BRO.
>
> With the CSS, even though the unit would handle the initial connection,
> it would 'snap' that over to the origin server it picked during load
> balancing so you would still see the tcp setup.
>
> Not sure what Netscalar does, but it all should act the same.  The host
> TCP stack would drop any attempted connection for which a session was
> not established regardless of what was upstream from it.  Quick and
> dirty, you sould be able to fire up tcpdump and see the session
> initialization.
>
> Thoughts?
>
> Tahnks.
>
> John.
>
> -----Original Message-----
> From: bro-bounces at ICSI.Berkeley.EDU
> [mailto:bro-bounces at ICSI.Berkeley.EDU] On Behalf Of Bill Jones
> Sent: Saturday, February 06, 2010 10:22 AM
> To: bro at ICSI.Berkeley.EDU
> Subject: [Bro] Load Balancers
>
> Hi everyone,
>
> I was curious if anyone has any experience running bro between
> load-balancers (such as Netscaler) and web applications.  We are
> currently trying to get HTTP logs generated for a web application.  We
> couldn't figure out why bro was not triggering the HTTP analyzer, but
> I now believe that this is because it is never seeing the original SYN
> + SYN/ACK for the conversation.  When viewing the conversations in
> Wireshark, I can see that all the TCP streams for this particular
> application begin with the GET and do not include the initial 3-way
> handshake.
>
> Here is an entry in the conn.log for this stream which shows the states:
>
> 1265389087.849048 ? 10.19.120.12 10.19.2.78 http 2232 80 tcp 14785
> 604140 OTH X DdAa
>
> Other web applications on the wire, which do have the 3-way handshake
> visible for all connections, seem to work just fine and I get http
> logs.
>
> My questions are:
>
> Am I correct in assuming that the lack of initial connection
> establishment is why the HTTP analysis is never occurring (and
> therefore I'm not getting entries in http.log)?
>
> Is there a way to force bro to analyze the traffic even though there
> is no proper 3-way handshake visible?
>
>
> Thanks for your time,
> Bill
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>




More information about the Bro mailing list