[Bro] Intel Framework Issues

Josh Liburdi liburdi.joshua at gmail.com
Tue Nov 24 15:49:27 PST 2015


Generally speaking, I favor grabbing more data over grabbing a portion of the data, so I prefer to see all of the IP indicators in every connection, then process the output outside of Bro. That said, the suggestions of checking for non-TCP / unestablished TCP IN_RESP connections makes sense if a sensor is resource constrained. 

I also like the idea of getting more granular with indicator-related activity (I do a bit of this, just not shared publicly), but I wonder if those specific use cases should be their own policy scripts instead of default behavior. More indicator-related policy scripts could give users better options.

Josh

> On Nov 24, 2015, at 4:28 PM, Derek Ditch <derek at criticalstack.com> wrote:
> 
> On 2015-11-23, 15:40, "Azoff, Justin S" <bro-bounces at bro.org on behalf of jazoff at illinois.edu> wrote:
> 
> 
>> IN_ORIG / IN_RESP may help with this
>> 
>> seen IN_RESP in a failed outbound connection to a known phishing site, useful to know
>> 
>> seen IN_ORIG in a failed incoming port 22 connection from a known ssh scanner, probably just noise.
>> seen in IN_RESP in a failed outbound port 22 connection to that same known ssh scanner, useful to know
>> 
>> Which I guess would mean something like
>> 
>> event connection_i_forget(c: connection) {
>>   if(!Site::is_local_addr(c$id$resp_h)) {
>>       Intel::seen([$host=c$id$resp_h, $conn=c, $where=Conn::IN_RESP]);
>>   }
>> }
> 
> Something that I’d add to Justin’s approach is quasi-state for non-TCP. I’d have to think how best to write the event for a bit, but basically apply the same logic to ICMP/UDP. But also catch if seen IN_ORIG of a UDP connection and there is any response at all. Maybe extend the Crowdstrike script and apply is_local_addr filter.
> 
> Something like (could be glitches, haven’t tested this yet):
> 
> # Source: https://gist.github.com/dcode/dfe6026fd9865fb8e1ab
> @load base/frameworks/intel
> @load policy/frameworks/intel/seen/where-locations
> 
> event connection_state_remove(c: connection)
> {
>  if ( c$conn?$proto && ( c$conn$proto != tcp || ( c$conn?$history && c$conn$proto == tcp && "h" !in c$conn$history ) ) )
>      {
>      if ( !Site::is_local_addr(c$id$resp_h) )
>          {
>              Intel::seen([$host=c$id$resp_h, $conn=c, $where=Conn::IN_RESP]);
>          }   
>      else if ( Site::is_local_addr(c$id$orig_h) && c$resp_pkts > 0 )
>          {
>              Intel::seen([$host=c$id$orig_h, $conn=c, $where=Conn::IN_ORIG]);
>          }
>    }
> }
> 
> 
> Of course, you could definitely parameterize this behavior like known-hosts so it’s easier to configure for incident responders.
> 
>> Derek Ditch
> derek at criticalstack.com
> GPG: 0x2543A3B5
> 
> 
> 
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro




More information about the Bro mailing list