Hello,
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@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
CheersMark
On 27 Jul 2020, at 10:08, Daniel-Constantin Mierla <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:
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.
CheersMark
On 27 Jul 2020, at 09:14, Daniel-Constantin Mierla <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@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla