[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