[Oisf-devel] geoip keyword syntax

I. Sanchez sanchezmartin.ji at gmail.com
Thu Oct 18 20:54:55 UTC 2012


Yes, you are right.

I have changed it now to use the flow keyword from the rule.

On Mon, Oct 15, 2012 at 11:23 AM, Victor Julien <victor at inliniac.net> wrote:

> On 10/14/2012 01:25 AM, I. Sanchez wrote:
> > It is fixed now. It was a silly issue with one "if" (plus a few other
> > minor issues in the option string parser).
> >
> > Now everything seems to be working ok.
> >
> > The match function looks like this now:
> >
> > static int DetectGeoipMatch(ThreadVars *t, DetectEngineThreadCtx
> *det_ctx,
> >
> >                              Packet *p, Signature *s, SigMatch *m)
> >
> > {
> >     DetectGeoipData *geoipdata = (DetectGeoipData *)m->ctx;
> >
> >     int match = 0;
> >     int matches = 0;
> >
> >
> >     if (PKT_IS_IPV4(p))
> >
> >     {
> >         if (geoipdata->flags & GEOIP_MATCH_SRC_FLAG || geoipdata->flags
> > & GEOIP_MATCH_BOTH_FLAG)
>
> You could write this as
> if (geoipdata->flags & (GEOIP_MATCH_SRC_FLAG|GEOIP_MATCH_BOTH_FLAG)
>
> >
> >         {
> >             /* if there is a flow get SRC IP of the flow, not packet */
> >             if (p->flowflags & FLOW_PKT_TOCLIENT)
>
> Not sure I understand why the flow direction is checked here? The
> keyword should inspect the pkt src I think, regardless of flow.
>
> If a user wants only a certain flow direction checked, the flow keyword
> can be used:
>
> flow:to_client; geoip:src,CN;
>
> Cheers,
> Victor
>
> >
> >                 /* the dst (from server to client) is our src */
> >                 match = CheckGeoMatchIPv4(geoipdata,
> > GET_IPV4_DST_ADDR_U32(p));
> >
> >             else
> >                 match = CheckGeoMatchIPv4(geoipdata,
> > GET_IPV4_SRC_ADDR_U32(p));
> >
> >             if (match)
> >             {
> >                 if (geoipdata->flags & GEOIP_MATCH_BOTH_FLAG)
> >
> >                     matches++;
> >                 else
> >
> >                     return 1;
> >             }
> >         }
> >         if (geoipdata->flags & GEOIP_MATCH_DST_FLAG || geoipdata->flags
> > & GEOIP_MATCH_BOTH_FLAG)
> >
> >         {
> >             /* if there is a flow get DST IP of the flow, not packet */
> >             if (p->flowflags & FLOW_PKT_TOCLIENT)
> >
> >                 /* the src (from server to client) is our dst */
> >                 match = CheckGeoMatchIPv4(geoipdata,
> > GET_IPV4_SRC_ADDR_U32(p));
> >
> >             else
> >                 match = CheckGeoMatchIPv4(geoipdata,
> > GET_IPV4_DST_ADDR_U32(p));
> >
> >             if (match)
> >             {
> >                 if (geoipdata->flags & GEOIP_MATCH_BOTH_FLAG)
> >
> >                     matches++;
> >                 else
> >
> >                     return 1;
> >             }
> >         }
> >         /* if matches == 2 is because match-on is "both" */
> >         if (matches == 2)
> >
> >             return 1;
> >     }
> >
> >
> >     return 0;
> > }
> >
> >
> >
> > On Sat, Oct 13, 2012 at 9:46 PM, I. Sanchez <sanchezmartin.ji at gmail.com
> > <mailto:sanchezmartin.ji at gmail.com>> wrote:
> >
> >     Ok, I have done an initial implementation (just country geolocation
> >     for now). It is available at
> >     https://github.com/owlsec/suricata/tree/geoip
> >
> >     When checking a packet, I take into account the flow source and
> >     destination IPs for the match-on condition, if a flow exists.
> >     However in my tests I have seen it is not working well... a
> >     geoip:src,US; rule will be triggered as well when talking HTTP to
> >     google.com <http://google.com> from a non US source IP address.
> >
> >     I am not sure about the reason of this behavior, so perhaps somebody
> >     could let me know what is wrong here.
> >
> >     https://github.com/owlsec/suricata/blob/geoip/src/detect-geoip.c
> >
> >     The relevant function is this one:
> >
> >     static int DetectGeoipMatch(ThreadVars *t, DetectEngineThreadCtx
> >     *det_ctx,
> >
> >
> >                                  Packet *p, Signature *s, SigMatch *m)
> >
> >
> >     {
> >         DetectGeoipData *geoipdata = (DetectGeoipData *)m->ctx;
> >
> >
> >         int match = 0;
> >         int matches = 0;
> >
> >         uint32_t ip;
> >
> >         if (PKT_IS_IPV4(p))
> >
> >         {
> >             if (geoipdata->flags & GEOIP_MATCH_SRC_FLAG ||
> >     geoipdata->flags & GEOIP_MATCH_BOTH_FLAG)
> >
> >
> >             {
> >                 /* if there is a flow get SRC IP of the flow, not packet
> */
> >                 if (p->flowflags & FLOW_PKT_TOCLIENT)
> >
> >                     ip = GET_IPV4_DST_ADDR_U32(p); /* the dst (from
> >     server to client) is our src */
> >
> >                 else
> >                     ip = GET_IPV4_SRC_ADDR_U32(p);
> >
> >                 match = CheckGeoMatchIPv4(geoipdata, ip);
> >
> >                 if (match && geoipdata->flags & GEOIP_MATCH_BOTH_FLAG)
> >
> >
> >                     matches++;
> >                 else
> >
> >                     return 1;
> >             }
> >             if (geoipdata->flags & GEOIP_MATCH_DST_FLAG ||
> >     geoipdata->flags & GEOIP_MATCH_BOTH_FLAG)
> >
> >
> >             {
> >                 /* if there is a flow get DST IP of the flow, not packet
> */
> >                 if (p->flowflags & FLOW_PKT_TOCLIENT)
> >
> >                     ip = GET_IPV4_SRC_ADDR_U32(p); /* the src (from
> >     server to client) is our dst */
> >
> >                 else
> >                     ip = GET_IPV4_DST_ADDR_U32(p);
> >
> >                 match = CheckGeoMatchIPv4(geoipdata, ip);
> >
> >                 if (match && geoipdata->flags & GEOIP_MATCH_BOTH_FLAG)
> >
> >
> >                     matches++;
> >                 else
> >
> >                     return 1;
> >             }
> >
> >             /* if matches == 2 is because match-on is "both" */
> >             if (matches == 2)
> >
> >                 return 1;
> >         }
> >
> >
> >         return 0;
> >     }
> >
> >
> >
> >     On Fri, Oct 12, 2012 at 11:35 AM, I. Sanchez
> >     <sanchezmartin.ji at gmail.com <mailto:sanchezmartin.ji at gmail.com>>
> wrote:
> >
> >         Yes, I forgot to mention it. Negation will be supported.
> >
> >
> >         On Fri, Oct 12, 2012 at 10:03 AM, Peter Manev
> >         <petermanev at gmail.com <mailto:petermanev at gmail.com>> wrote:
> >
> >             Excellent - thank you.
> >             comments bellow ...
> >
> >             On Thu, Oct 11, 2012 at 10:07 PM, I. Sanchez
> >             <sanchezmartin.ji at gmail.com
> >             <mailto:sanchezmartin.ji at gmail.com>> wrote:
> >
> >                 Good idea, I will implement multiple
> >                 conditions(countries) in the same rule. Let's use the
> >                 <match-on><condition>+ syntax where match-on can be src,
> >                 dst, both or any.
> >
> >
> >                 alert http any any -> any any (msg:"GEOIP: IP located in
> >                 US/Germany/Canada/France";*geoip:src,US,DE,CA,FR*;
> >                 sid:3450002; rev:1;)
> >
> >                 I can also support geoip:US; by assuming geoip:any,US; ,
> >                 for simplicity.
> >
> >
> >             I agree with the assumption here - i think it is good to
> >             assume so.
> >             I was thinking further on the matter and I am not sure if i
> >             am starting to sound annoying - but wouldn't it be nice if
> >             we can also negate geoip? :
> >             alert http any any -> any any (msg:"GEOIP: IP destination
> >             *NOT* located in US/Canada";**geoip:*dst,!*US,CA;
> >             sid:3450002; rev:1;)
> >
> >
> >
> >                 Regarding the city support, indeed the MaxMind DBs in
> >                 their free versions support cities in addition to
> >                 countries although the accuracy drops from 99.5% (for
> >                 countries) to 78% in US (for cities), and I guess much
> >                 less accuracy in other countries.
> >
> >                 In the commercial DBs, they apparently support regions,
> >                 organizations...
> >                 http://www.maxmind.com/en/geolocation_landing
> >
> >                 For now I will just implement support for countries, but
> >                 we should take this into account for the keyword syntax.
> >                 I see some options:
> >
> >                   * Autodetect city vs country. I could detect whether
> >                     the condition is a known country code, and assume
> >                     city otherwise. However this will not work for
> >                     regions, organizations...
> >                   * Allow -for future versions- the check type as an
> >                     optional param of the <match-on> condition. ie:
> >                     geoip:src,city,Madrid;
> >
> >
> >             this would be awesome in my opinion.
> >
> >                 Regards,
> >
> >
> >
> >
> >
> >                 On Thu, Oct 11, 2012 at 9:02 PM, Peter Manev
> >                 <petermanev at gmail.com <mailto:petermanev at gmail.com>>
> wrote:
> >
> >                     Hi,
> >
> >                     I think i love that new geoip keyword - thank you
> >                     for the efforts !
> >
> >                     A couple of suggestions/requests if I may:
> >
> >                     1.I agree/like the proposal - but I wonder if it
> >                     would be possible to include multiples(maybe up to a
> >                     certain number [32 or something] ) of countries -
> like:
> >                     alert http any any -> any any (msg:"GEOIP: IP
> >                     located in
> >                     US/Germany/Canada/France";*geoip:src,US,DE,CA,FR*;
> >                     sid:3450002; rev:1;)
> >
> >                     2. As there is - *src, dst, both* - i think it would
> >                     be nice if there is also "*any*" -
> >                     alert http any any -> any any (msg:"GEOIP: some
> >                     traffic to/from the Cayman Islands";*geoip:any,KY*;
> >                     sid:3450005; rev:1;)
> >                     any - meaning either source or destination.
> >
> >                     thanks a bunch!
> >
> >
> >                     On Thu, Oct 11, 2012 at 6:42 PM, Victor Julien
> >                     <victor at inliniac.net <mailto:victor at inliniac.net>>
> >                     wrote:
> >
> >                         On 10/11/2012 06:16 PM, I. Sanchez wrote:
> >                         > Hi,
> >                         >
> >                         > I am implementing support for IP address
> >                         country geolocation in
> >                         > Suricata, and I wanted to ask your opinion
> >                         about the syntax to be used
> >                         > for the geoip keyword options.
> >                         >
> >                         >
> >
> https://redmine.openinfosecfoundation.org/issues/559
> >                         >
> >                         > The keyword options would be:
> >                         >
> >                         >   * Country code. ie: US
> >                         >   * Match condition: match on source IP, match
> >                         on destination IP, or
> >                         >     match on both.
> >                         >
> >                         > What do you think would be the best syntax for
> >                         this?
> >                         >
> >                         > Some possibilities:
> >                         >
> >                         >   * geoip:<src|dst|both>,<countrycode>;
> >                         >       o alert http any any -> any any
> >                         (msg:"GEOIP: IP located in
> >                         >         US";*geoip:src,US*;sid:3450002;rev:1;)
> >                         >   * geoip:<countrycode>,<src|dst|both>;
> >                         >       o alert http any any -> any any
> >                         (msg:"GEOIP: IP located in
> >                         >         US";*geoip:US,src*;sid:3450002;rev:1;)
> >
> >                         Thanks for picking this up!
> >
> >                         Doesn't the geoip also allow for other types of
> >                         data, such as city? I'm
> >                         sure that if we have this in Suricata ppl will
> >                         be interested in buying
> >                         the more detailed databases as well.
> >
> >                         --
> >                         ---------------------------------------------
> >                         Victor Julien
> >                         http://www.inliniac.net/
> >                         PGP: http://www.inliniac.net/victorjulien.asc
> >                         ---------------------------------------------
> >
> >                         _______________________________________________
> >                         Oisf-devel mailing list
> >                         Oisf-devel at openinfosecfoundation.org
> >                         <mailto:Oisf-devel at openinfosecfoundation.org>
> >
> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
> >
> >
> >
> >
> >                     --
> >                     Regards,
> >                     Peter Manev
> >
> >
> >                     _______________________________________________
> >                     Oisf-devel mailing list
> >                     Oisf-devel at openinfosecfoundation.org
> >                     <mailto:Oisf-devel at openinfosecfoundation.org>
> >
> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
> >
> >
> >
> >
> >
> >             --
> >             Regards,
> >             Peter Manev
> >
> >
> >
> >
>
>
> --
> ---------------------------------------------
> Victor Julien
> http://www.inliniac.net/
> PGP: http://www.inliniac.net/victorjulien.asc
> ---------------------------------------------
>
> _______________________________________________
> Oisf-devel mailing list
> Oisf-devel at openinfosecfoundation.org
> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-devel/attachments/20121018/beb0fe68/attachment-0002.html>


More information about the Oisf-devel mailing list