This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Prevent brute force attacks through IMAPS

Hello,

we are seeing brute force attachs with the IMAPS protocol which lead to locked out accounts in the backend. Is there any efficient way to prevent this?

Best regards,

Bernd



This thread was automatically locked due to age.
Parents
  • You are in a bind.   Somehow you need to correlate the login failure to an IP address, then block the IP.   If your mail server does not have the source IP in the logs, this will be a mess.   If you have IP address and some programming resources, you may be able to automate the process of detecting the login failure and then using Restful API to automatically apply a IP block rule to UTM. 

    If UTM is your firewall, then the block is a DNAT-to-dead-end rule.   Details of that strategy can be found elsewhere.  Start with "How to understand UTM Port usage" and then follow the links about DNAT that are in there.  

    Of course, the bad guys probably have a lot of IP addresses at their disposal, so this may be a long struggle,  The alternatives are to go with access methods that are processed at UTM, so that breakin evasion rules can be applied, and so 2-factor authentication can be added:

    • Webmail, ideally with 2-factor authentication
    • Client SSL, ideally with 2-factor authentication, then IMAP inside the tunnel.

    Internet-based IMAP, POP, ActiveSync, and EWS are probably doomed because they cannot support 2-factor authentication, and because the password guessers are getting sophisticated.

  • The lockouts came from very different IP adresses mostly from Russia, Brasil, Indonesia, Iran, India and US. There was only 1-3 accesses per IP.

    2 Factor authentication is/was not an option because the IMAP is used primarily for accessing a single support Mailbox from a large number of devices. Support personal does not want to check the mailbox manually with two factor authentication when being in standby. With ActiveSync this led to problems with 10+ devices. 

    Finally I did a geoblocking on the perimeter firewall (other vendor). 

  • We use a different architecture for after hours support.   Alarms are forwarded to onpage.com, which sends an alarm to the cell phone of whoever is on duty.   I don't know the geogrphic coverage for OnPage, or your geography, or our cost.  But cost is probably reasonable if your geography works.

Reply
  • We use a different architecture for after hours support.   Alarms are forwarded to onpage.com, which sends an alarm to the cell phone of whoever is on duty.   I don't know the geogrphic coverage for OnPage, or your geography, or our cost.  But cost is probably reasonable if your geography works.

Children
No Data