#135 Auto-ban for mitigating brute force attacks

[Felipe]

Dear Oliver,

We've been happily using NOCC for years now, but accessing it indirectly instead of from our website frontpage as wishable, because of a real concern regarding abuse by brute force attacks for example (as experienced).
I think some kind of mechanism like auto-ban or a similar one can avoid or, at least, mitigate such challenge.
I wonder whether many others have been facing this issue too, that's why I decided to post it just in case.

Att, Felipe

[Oliver Heil]

Hi Felipe,

good point, I have faced brute force attacks too.

If you are on a linux system you should (always) utilize fail2ban. These is the changelog note about this:

* Failed and successful logins are logged to php.log and syslog as
    NOCC: successful login from rhost=2.2.2.2 to server=your.server.eg:993/ssl/novalidate-cert as user=username
  and
    NOCC: failed login from rhost=2.2.2.2 to server=your.server.eg:993/ssl/novalidate-cert as user=username
  Log entries can be used to detect and react on brute force attacks (e.g. with
  fail2ban)

A simple fail2ban filter entry can be e.g.

failregex = ^%(__prefix_line)s.*NOCC: failed login from rhost=<HOST> to.*$

But, this is currently only available if you have set the login_allowed array in your configuration, which again is highly recommended: it restricts general login to a set of accounts.
Try to login with a user not in this list, results in above syslog entry.

My opinion is that above ban strategy is sufficient, but I see now, that it ignores windows systems where fail2ban is not available (as far as I know).

I will go into this and try to implement a NOCC specific auto ban feature if feasable. You may provide your thoughts here.

What I do not understand is what do you mean with:

but accessing it indirectly instead of from our website frontpage as wishable

What do you have in mind with that?

Regards,
Oli

[Felipe]

Hi Oliver,

The login_allowed array surely is a good idea, but I make use of Windows Server, so brute force attacks cause a massive number of login attempts in the PHP error log, what indicates the amount of resources lost behind it.
I attached a printscreen of the interface with auto-ban feature found in hMailServer, which works great.
Besides that, I faced the same issue by opening a server port for Tight VNC (that I like very much) to the internet. This eventually lead me to use AnyDesk instead (German by the way, lol) - see: https://sourceforge.net/p/vnc-tight/feature-requests/741/ .
Similarly, what I meant with "but accessing it indirectly instead of from our website frontpage as wishable" is that I can't afford to expose NOCC login page URL or its username and password fields, as well as its login button, directly on our company's homepage (publicly), at the cost of suffering from attacks like those.

Regards,
Felipe

[Felipe]

In addition, sort of it (works great too) is also used in 3CX, an IP PBX system I make use of. A print of its interface is found attached to this post.

P.S.: another factor made me abandon Tight VNC was the lack of encryption to/from WAN traffic. Besides, I provide the link 'More details...' on the previous post attachment leads to: https://www.hmailserver.com/documentation/latest/?page=reference_autoban (for reference).

[Oliver Heil]

Hi Felipe,
hmm, there are quite some deep topics in your short description of your wishes ;-)

From what I read is that you really need to setup something like fail2ban for windows. A short search brought
https://github.com/DigitalRuby/IPBan
(as the single free one)
I don't know how hMailServer solves this issue, but to address the problem of ressource costs used for the attacks, the only way is blocking ip adresses at the level of the windows firewall, which is out of scope for NOCC. It would need a php API to the windows event log system and to the windows firewall, I never heard of such APIs for php.

Implementing a ban feature in NOCC can only enhance security on the login level of NOCC itself, by blocking accounts (or better slowing down login attempts) which are currently under attack, and blocking the IP of those attacks from within NOCC (not allowing this IP to login whatever credentials are entered). But this wouldn't help for the ressources used for attacking attempts as those would still go on and use more or less the same ressources of the php server as before. So, I see no suitable way for your issue within the realm of NOCC.

For the indirect access the same. It doesn't seem to be something which can be solved by NOCC. Typically you would expose your inner NOCC server using a proxy, which routes access from the outside through the proxy to the NOCC server. This proxy access can be restricted in many ways (including IP bans on hacking attacks). But remember, NOCC itself is some kind of a proxy, as it proxies access to existing imap/pop3 servers through a html frontend. So perhaps there is some better kind of access to the users mailboxes from the outside.

So, my understanding for now is: banning IP adresses because of hacking attemps for security AND for ressource saving can't be solved by NOCC.

I am still looking into something to enhance security of NOCC. But I am afraid it doesn't help your issue completely.

Regards,

Oli

[Oliver Heil]

This will be addressed in the next release, v1.9.11, but it needs memcache php extension and memcached, because of performance issues with otherwise persistent data.