27 Jul
2020
27 Jul
'20
12:31 p.m.
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(a)1.1.1.1 <mailto:100@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
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
On 27 Jul 2020, at 10:08, Daniel-Constantin
Mierla <miconda(a)gmail.com
<mailto:miconda@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:
--
Mark Boyce
Dark Origins Ltd
e: mark(a)darkorigins.com <mailto:mark@darkorigins.com> 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
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla On 27 Jul 2020, at 09:14, Daniel-Constantin
Mierla
<miconda(a)gmail.com <mailto:miconda@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(a)lists.kamailio.org <mailto:sr-users@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(a)darkorigins.com <mailto:mark@darkorigins.com>