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
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
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@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
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@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@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@darkorigins.com mailto:mark@darkorigins.com
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@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.
Cheers Mark
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.
Cheers Mark
On 27 Jul 2020, at 09:14, Daniel-Constantin Mierla <miconda@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@lists.kamailio.org mailto:sr-users@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@darkorigins.com mailto:mark@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
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;
Already Blacklisted -> drop
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).
Rate Limiting . Using temp blacklist, banning for x mins.
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)
- “Not for us” user/domain check -> drop. (good, as it ignores all
those invites from 100@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)
- Normal Challenge Auth, with failure rate limit
(Using details retrieved as part of Auth)
- If not in $au:$ip:$ua.. cache Check IP / GeoIP Countries / Device
UA / etc. Caching result
- 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@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:
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@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@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@darkorigins.com mailto:mark@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@darkorigins.com mailto:mark@darkorigins.com
-
Daniel-Constantin Mierla -
Mark Boyce