P
P
pred8or2017-07-07 22:11:35
Mikrotik
pred8or, 2017-07-07 22:11:35

Attack on the mail system, the first wave is repulsed, what's next?

At the beginning of the week, an attack began on the organization's mail system running on ZCS. The main vector is the selection of the password of several accounts through IMAP. Zimbra has a built-in mechanism - after several unsuccessful login attempts, the account is blocked for a certain time in order to slow down the attacker. However, such blocking hits employees.
We began to look at how large the set of addresses from which the attack is being carried out. It turned out to be large, so individual locks are not an option. As a result, a single new connection forward rule for WAN-DMZ has turned into several:

  • White list. All necessary ports (http, imap, pop3, smtp) from the local network, external monitoring systems, mobile networks of Moscow operators - accept
  • Gray list (for monitoring what is happening). All ports for addresses from the corresponding list - accept
  • Suspects. http, imap ports - tar pit
  • Postman Pechkin. ports pop3, smtp - accept
  • Well, the default rule is drop everything that came here. In principle, all necessary conditions must be processed earlier, so for this rule the counter must remain at 0. If not 0, then there is an error somewhere

As a result, mail is delivered, employees at their workplaces and on mobile phones in Moscow can use mail, and it does not come to guessing passwords. The router is practically not strained. However, for those employees who do not have a static address at home or from some kind of wifi, mail is not available. Mail is not available to employees from a mobile phone outside of Moscow, especially abroad.
We tried to think in this direction: everything is allowed, but on the mail server, the daemon monitors the audit log file. If an authentication error occurs, use the RouterOS API to blacklist the corresponding address for a while. This blacklist should be used by rules for both new connections and established/related ones. However, the problem is that access from a single address occurs very rarely, many addresses work in parallel, so the selection will still occur with virtually no loss for the attacker. And employees will again be without mail.
In which direction should you think? How is this resolved?

Answer the question

In order to leave comments, you need to log in

2 answer(s)
T
TOParh, 2017-07-10
@pred8or

In a similar situation, fail2ban helped, and block on three unsuccessful attempts. A very effective measure.

C
CityCat4, 2017-07-08
@CityCat4

Option 1 - VPN to the network and mail only after VPN
Option 2 - certificates (in the sense of checking a personal certificate)
Option 1 is technically simpler - VPN is installed and configured once. True, if you do a normal VPN, it should not be PPTP, you may need to install a client
Option 2 is technically more difficult, but it doesn't care about IP from the word at all - the "friend or foe" check is based on the presence on the device of a certificate issued by a corporate CA. True, the problem is that not all mail clients have the ability to work with S / MIME in general, and not all of them work with personal certificates. Well, the publication of CRL, the issuance of new employees, the recall of those fired - there will be a lot of fuss. But don't care - static IP, dynamic IP, the main thing is that port 500/4500 is not blocked (not all clients support an arbitrary port)

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question