[SR-Users] Using GeoIP2 AS Lookup?

Mon Jul 27 11:32:04 CEST 2020

Hi

Sounds very similar to the way I’ve been heading, working on multi layer defence like this;

1) Already Blacklisted -> drop

2) Very naughty things we should never see (SQL injection/scanner) -> Add to permanent blacklist & drop

3) Rate Limiting . Using temp blacklist, banning for x mins.

4) If not an “Invite/Register” and IP not on list of IPs we have seen auth previously, drop. (Gets rid of all the Option/Subscribe scanners)

5) “Not for us” user/domain check -> drop.  (good, as it ignores all those invites from 100 at 1.1.1.1 <mailto:100 at 1.1.1.1>. Bad, as it means a badly configured UA trying to talk to us on IP domain doesn’t get an Auth challenge)

6) Normal Challenge Auth, with failure rate limit

(Using details retrieved as part of Auth)

7) If not in $au:$ip:$ua.. cache Check IP / GeoIP Countries / Device UA / etc. Caching result

8) Check if endpoint / user / etc is disabled (means disabling a single endpoint doesn’t end up banning entire IP for Auth failures)

Most of which is coded by hand inside cfg file at the moment.  Couldn’t quite get security module etc to work quiet how I wanted the logic to work.

Cheers
Mark

> On 27 Jul 2020, at 10:08, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> 
> Hello,
> 
> what worked quite well so far for me was maintaining ipban and ipallow htables, adding to ipallow the address of a successfully authenticated request and adding to ipban the address of a flooding end point (detected via pike or pipelimit) which is not in ipallow.
> 
> Of course, skipping trusted fixed ip end points (e.g., pstn gateways).
> 
> Most of the end points send the REGISTER and once authenticated and gets back 200ok, then they flood with SUBSCRIBE for BLF/MWI/Presence, but at that moment, the IP is in ipallow. I also maintain an userban htable where to keep username:ip if that user failed to authenticate 5 times in a row.
> 
> Anyhow, adding more layers of trusting levels is better.
> 
> Cheers,
> Daniel
> 
> On 27.07.20 10:45, Mark Boyce wrote:
>> Hi
>> 
>> I only have ubuntu to hand.  The latest v20.04 still seems to include a country db version, although it’s from Dec 2019.
>> 
>> Completely agree on security, and still wondering how much admin overhead maintaining it is.
>> 
>> At the moment I’m thinking of layering it like this;
>> 
>> - Fixed IP
>> - Dynamic IP but Fixed ISP (AS)
>> - Mobile but Fixed/Limited Country
>> - Mobile no restrictions
>> 
>> Also playing with matching User-Agent from headers against a list of RegEx’s to verify that the endpoint is the make/model expected.  
>> 
>> 
>> GeoIP Module - Great.  I’ll have a look at module source and try to document what’s involved.
>> 
>> 
>> Cheers
>> Mark
>> 
>>> On 27 Jul 2020, at 09:14, Daniel-Constantin Mierla <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>>> 
>>> Hello,
>>> 
>>> indeed, I noticed a while ago MaxMind requires registration to fetch the
>>> latest database, from that point I was still using a local copy of an
>>> older version for testing. Are the major Linux distros still shipping it?
>>> 
>>> I can add lookup of AS to the module -- it would be appreciated and
>>> speed up things if you can give some references/links to the API/library
>>> docs for it.
>>> 
>>> As for how much security it can bring, as always, it depends. If you
>>> have only fixed lines customers, then it can be an extra check. But if
>>> the people can use mobile apps, they can go in parks, or public places
>>> and use mobile carriers or public wifi networks. Also, I encountered
>>> situations when people do vpn from their mobile and show up as coming
>>> from another country, a matter where the vpn server is located.
>>> 
>>> In general, the more restrictions you can set for end point locations,
>>> the better. Still, they can be compromised even if they are inside a
>>> known isp network...
>>> 
>>> Cheers,
>>> Daniel
>>> 
>>> On 23.07.20 12:18, Mark Boyce wrote:
>>>> Hi all
>>>> 
>>>> Just looking at the latest GeoIP2 MaxMind databases (now requires registration, but still free) and noticed that they also include the AS (ISP) lookup one in the free offering.
>>>> 
>>>> Wondering if this is another way to facilitate better security for users on dynamic IP. Typically working from home these days.
>>>> 
>>>> So, rather than just limiting an end device to a country we could limit it to a particular ISP within that country.
>>>> 
>>>> Has anyone tried this? Have I missed a reason why this wouldn’t help?  Admin overhead not worth it?
>>>> 
>>>> Thoughts?
>>>> 
>>>> Best regards
>>>> Mark
>>>> -- 
>>>> Mark Boyce
>>>> Dark Origins Ltd
>>>> 
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>> 
>>> -- 
>>> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com/>
>>> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>>> Funding: https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>
>>> 
>> 
>> 
>> -- 
>> Mark Boyce
>> Dark Origins Ltd
>> e: mark at darkorigins.com <mailto:mark at darkorigins.com>
> -- 
> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com/>
> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
> Funding: https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>

-- 
Mark Boyce
Dark Origins Ltd
e: mark at darkorigins.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200727/401686ce/attachment.htm>