[Bro] [bro] Scanning IP's

Tim Desrochers tgdesrochers at gmail.com
Sun Feb 14 05:19:06 PST 2016


FANTASTIC!!  Giving it a shot now

On Sun, Feb 14, 2016 at 7:35 AM, Azoff, Justin S <jazoff at illinois.edu>
wrote:

> The thing to understand is that the ignored_types and emailed_types are
> just tables defined to make tweaking the base notice policy easier.
>
> That default notice policy is:
>
> hook Notice::policy(n: Notice::Info) &priority=10
>         {
>         if ( n$note in Notice::ignored_types )
>                 break;
>
>         if ( n$note in Notice::not_suppressed_types )
>                 n$suppress_for=0secs;
>         if ( n$note in Notice::alarmed_types )
>                 add n$actions[ACTION_ALARM];
>         if ( n$note in Notice::emailed_types )
>                 add n$actions[ACTION_EMAIL];
>
>         if ( n$note in Notice::type_suppression_intervals )
>                 n$suppress_for=Notice::type_suppression_intervals[n$note];
>
>         # Logging is a default action.  It can be removed in a later hook
> if desired.
>         add n$actions[ACTION_LOG];
>         }
>
> As you can see, adding notice types to those tables just tweaks the
> behavior of the default Notice::policy hook.  To do some of the things you
> want to do, you just need a hook like
>
> hook Notice::policy(n: Notice::Info)
> {
>     if (n$note == Scan::Port_Scan && Site::is_local_addr(n$src))
>         add n$actions[Notice::ACTION_EMAIL];
> }
>
> If that would get repetitive, you can create your own table like
>
> const local_emailed_types: set[Notice::Type] = {} &redef;
>
> and have the policy be
>
> hook Notice::policy(n: Notice::Info)
> {
>     if (n$note in local_emailed_types && Site::is_local_addr(n$src))
>         add n$actions[Notice::ACTION_EMAIL];
> }
>
> --
> - Justin Azoff
>
> > On Feb 14, 2016, at 6:14 AM, Tim Desrochers <tgdesrochers at gmail.com>
> wrote:
> >
> > As with every infrastructure I am plagued with people scanning my
> external edge.  I see little value in getting notices for scanning attempts
> and password guessing attempts but I do see value in running monthly
> reports and generating blocklists based on repeat offenders.
> >
> > Is there a way to tell the notice framework to only create alarms
> (emails) if it sees scans of any kind (address, port, password guessing,
> etc) if they are from the IP's in my $HOME_NET defined in network.cfg?
> >
> > Justification, If I
> >
> > redef Notice::ignored_types += {
> >   SSH::Password_Guessing,
> >   Scan::Address_Scan,
> >   Scan::Port_Scan,
> >   HTTP::SQL_Injection_Attacker,
> >   ShellShock::Scanner,
> >   ScanUDP::Address_Scan,
> >   ScanUDP::Port_Scan,
> > };
> >
> > Then I get no logging of the events anywhere.  Therefore I can't run
> reports of offenders and build active blocklists or other intel gathering
> activities.
> >
> > If I:
> >
> > # Set rule to only email specific notice types:
> > redef Notice::emailed_types += {
> >   Weird::Activity,
> >   Signatures::Sensitive_Signature,
> >   Signatures::Multiple_Signatures,
> >   Signatures::Multiple_Sig_Responders,
> >   Signatures::Count_Signature,
> >   Intel::Notice,
> >   TeamCymruMalwareHashRegistry::Match,
> >   Traceroute::Detected,
> >   FTP::Bruteforcing,
> >   FTP::Site_Exec_Success,
> >   HTTP::SQL_Injection_Victim,
> >   SMTP::Blocklist_Error_Message,
> >   SMTP::Blocklist_Blocked_Host,
> >   SMTP::Suspicious_Origination,
> >   SSH::Login_By_Password_Guesser,
> >   SSH::Interesting_Hostname_Login,
> > };
> >
> > Then I get flooded with email from any of the guessing activity (Side
> note: I find that the above logic doesn't restrict email notices to just
> those listed in the defined email types above.  I still get plenty of
> notices about events not listed in the list above).  If the redef
> Notice::emailed_types worked it would be a start but I'd still like to get
> emails about IP addresses in my internal net getting scanned by other IP's
> in my internal net, that definitely an indicator of unwanted behavior.
> >
> > Any assistance would be greatly appreciated.  Just trying to tune things
> to a manageable level.
> >
> > Thanks
> > Tim
> > _______________________________________________
> > Bro mailing list
> > bro at bro-ids.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20160214/92aa0883/attachment.html 


More information about the Bro mailing list