[Bro] Bro not seeing certain FTP transfers

James Lay jlay at slave-tothe-box.net
Wed Apr 17 05:36:23 PDT 2013


No more thoughts on this all?

James

On Apr 11, 2013, at 11:30 AM, James Lay <jlay at slave-tothe-box.net> wrote:

> On 2013-04-11 11:25, Castle, Shane wrote:
>> I wonder if it's because the conversation ended with an RST - the
>> originator sent a FIN and got back RST. I assume the line you quoted
>> corresponds with the actual transfer.
>> 
>> --
>> Shane Castle
>> Data Security Mgr, Boulder County IT
>> 
>> 
>> -----Original Message-----
>> From: bro-bounces at bro.org [mailto:bro-bounces at bro.org] On Behalf Of 
>> James Lay
>> Sent: Thursday, April 11, 2013 11:09
>> To: bro at bro-ids.org
>> Subject: [Bro] Bro not seeing certain FTP transfers
>> 
>> Topic says it...here's what I have from conn.log:
>> 
>> 2013-04-08T06:00:25-0600        rTIHfQrsHgh     x.x.x.x    26519
>> x.x.x.x   21      tcp     ftp     22.117093       1141    4128    
>> RSTR
>> T       0       ShAdDaFr        111     5601    71      6972    
>> (empty)
>> 
>> And from my other logs:
>> Apr  8 06:00:31 x.x.x.x FTP connection from interface:x.x.x.x/26519 
>> to
>> x.x.x.x/21, user Stored file filename
>> 
>> ftp.log has no record at all of either the filename or the IP 
>> address.
>> I am my own ISP and I peer with two other ISP's over two separate
>> interfaces, meaning a packet can go out one interface, but come in 
>> the
>> other.  I'm running bro with:
>> 
>> bro -i eth4 -i eth5 local Site::local_nets += { ipspace/mask,
>> ipspace/mask }
>> 
>> Any hints on where to look for a solution to this?  I suspect I'm 
>> going
>> to end up bridging these interfaces.  Thank you.
>> 
>> James
> 
> Indeed it does.  Thanks Shane.
> 
> James
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro




More information about the Bro mailing list