Re: [exim] New compromise...?

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: Sebastian Nielsen
Data:  
Para: exim-users
Asunto: Re: [exim] New compromise...?
Yeah. Both of them is good.
First have a base restriction that locks an account to a specific country. Then use a ratelimit to further restrict inside the country.
Could be a good idea to have different ratelimits for /32, /24 and /16, so /16 has very strict ratelimit (only like 4 different per 24h), 24 has a bit sloppier (like 1 change per hour) and /32 has the sloppiest like 6 changes per hour.

But I would say the risk of compromise is much very lower when you GeoIP restrict to countries.

The base restriction is important, because if a attacker finds valid credentials, they will keep them, even when the ratelimit is hit. They will just try later.
Thats why its important to have a strict ratelimit locked to country.

For travelling, you could have that the customer/user has to call helpdesk and ask for travel access to a specific country for a specific duration.
Or even a self service portal where you login with 2FA and then unlock your mail account for a specific country ("travel mode") for a max period of, lets say 1 month. After that, you cannot activate travel mode any more for 5 months.

-----Ursprungligt meddelande-----
Från: Exim-users <exim-users-bounces+sebastian=sebbe.eu@???> För Heiko Schlittermann via Exim-users
Skickat: den 25 september 2019 19:19
Till: exim-users@???
Ämne: Re: [exim] New compromise...?

Sebastian Nielsen via Exim-users <exim-users@???> (Mi 25 Sep 2019 05:49:26 EDT):
> Another way to deal with compromises is to IP-restrict the user accounts so they can only login from where they are supposed to login from.
> If ALL of your users "belong" to the same country - for example i fits a company-internal email server, I would suggest set auth_advertise_hosts to a list of CIDR ranges that your country, or even better, your company, uses.


Maybe we use ratelimit to restrict the numbers of distinct
sender_host_addresses that are allowed to do (successful)
authentication.

The challenge will be to find the right balance between being too sloppy
and too strict.

(Think about a mobile device, reconnecting serveral times over the
course of a day)

    Best regards from Atlanta/GA
    Viele Grüße aus Atlanta/USA
    Heiko Schlittermann
--
 SCHLITTERMANN.de ---------------------------- internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --------------- key ID: F69376CE -
 ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -