[SR-Users] Using GeoIP2 AS Lookup?

Mon Jul 27 12:31:33 CEST 2020

Hello,

On 27.07.20 11:32, Mark Boyce wrote:
>
> 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

This make sense as well. Probably we should extend sanity module for
doing such checks over the relevant parts of the message (R-URI, From/To
headers, Call-ID).

>
> 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.

that's not easy indeed -- every time I think I should wrap all the
conditions I have in a recent config into a "security" module (for the
sake of easing provisioning), a different pattern pops up that I have to
cover or there is a new deployment with different call scenarios/end
points behaviour that is reusing only a few from the previous config.

Making such a module with very flexible policies stored in database will
be very complex, hard to define the format of the rules, which can end
up being harder to manage than just combining modules and conditions in
configuration file.

Cheers,
Daniel

>
> Cheers
> Mark
>
>
>
>> On 27 Jul 2020, at 10:08, Daniel-Constantin Mierla <miconda at gmail.com
>> <mailto: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
>>>>
>>>> -- 
>>>> 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
>>>>
>>>
>>>
>>> -- 
>>> Mark Boyce
>>> Dark Origins Ltd
>>> e: mark at darkorigins.com <mailto:mark at darkorigins.com>
>>>
>> -- 
>> Daniel-Constantin Mierla -- www.asipto.com
>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>> Funding: 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
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200727/27b7230d/attachment.htm>