Hi, all that needs to happen is for axigen to expose x-real-ip in the logs here...

Hi Gabriel,

I have just seen Axigens posted solution for this major problem that Brute force login attack is representing and that is to force us Windows users to buy a 3rd party product. (Linux users would at least have a free 3rd party solution) To refer to a 3rd party product for the protection of the Axien product (that we paid for!!) from one of the most basic problem that ANY account based product/service is facing - login security!!! is just too much.

https://www.axigen.com/articles/rdpguard-windows-brute-force-attack-protection_84.html

I still have not tried one single other Mail server that does not have native Brute force attack protection built in itself. Except for Axien!?!

Axigen probably needs to take a real good look at all its security implementation. I would even imagine GDPR would have some interests in how bad Axigen protects the accounts within its system and the risk for personal data leaks due to this.

Another example of lacking security I found after I have scrutinized the logs:
I wonder why the connecting client IP in SNMP-receiving is not looked up against DNS-Blocking Lists until after all EHLO commands AND after TLS initialization AND after mail is trying to be sent. Thus not at all for any login attempt
I understand that another DNSBL lookup at the time a mail is being proposed for delivery is needed to catch bad sender domains but a DNSBL lookup directly from the connection IP would probably catch most of these anyway along with loads of the brute force login attacks as well.

Also comparing my settings that only allow 10 new connections per minute from the same IP for SMTP receiving and the flow of connections in the logs I can during a Brute force login attack easily spot 30 or 40 or more connections and login attempts during a minute. So I am wondering if this very weak protection is even doing anything at all!

BTW Manually managing the built in Access restriction list very soon reveal its limited use with a maximum count of about 150 addresses. And any manual IP-block management is just close to wasted management.

I have tried hard to refrain myself from using bad language but I am really losing my patience here!!!

Two things that make me stick around. I really like the Web GUI for administration and webmail (Lacking possibility to get popup windows when opening mail is a setback) and I am hoping to help your other customers by trying to make Axigen own up to its very low standard of security and not push its problems under the rug of a 3rd party log scanning product.

I will send this to Axigen support as well

Hi Gabriel.

error control + flow control is not enough to secure our user.
we see many IP'S in the logs trying to brute force our IP our only solution was IPTABLES.
But this is hassle to admins we need to check the error in the logs assuming per week we caught 10 to 15 IP'S.

brute force in SMTP-IN / POP3 / IMAP / WEBMAIL / WEBADMIN

We are 100% sure spams we received is from SMTP-IN brute-force.

In our case when we blocked those malicious IP in SMTP-IN Spams is reduces to minimal.
Yes we have good anti-spam but.

When the email server received brute-force in smtp-in trying to locate available user and password.

Better to look and add this in future request especially add this features in IMAP / POP3 SMTP-IN or all ports of Axigen same as fail2ban with configuration of banning whitelisting.

This feature will help axigen users.

I'm very sad to see that this request that is almost 4 years (!!!) old and has been in top 3 requests for as long as I have seen it and even at top 1 for a long time is only at a "Planned" status. Hopefully this page is only lacking update... the release of X3 version that "currently" were scheduled to be released Q4 2018 is half a year ago feels less then updated.

I can't help loosing hope somwhat here. This is a feature I have seen in practiacally all competitive Mail servers since many years back.

Im growing tired of trying to manually scan logfiles and add malicius IP's to the blocking lists. I dont want to develop/implement a third party solution for a feature I consider to be mandatory in a mail server (or any system with public login capability). And as a wndows users all the Linux solutions is out of the question anyway.

As a response to Enea's comment om March 12:
This situation would be coverd by the white list requirement. Simply enter this single IP in the white list. I see no need to develop overcomplicated code to do unnecesary (and potentially riskfull) handling of passwords.

Looking forward to this. Please do also consider the scenarios where axigen sits behind a reverse proxy. I.e. start logging the X-Real-IP and/or X-Forwarded-For header tag to allow external parsers (e.g. fail2ban) to do the job.

A nice idea could be not blocking attempt with identical password (in ordet to not lock many account behind a single ip when there's a single client with a wrong password saved...)

A bit far off but at least it is good to hear it is in the plan! :-)

I was directed here for my questions about anti hammering in the Install directory of the Axigen forum .

Reading this I am really loosing my hope here. This question has been up for vote for two and a half years, is at the top of suggestions and Axiegen has still not created a function or a viable solution (scanning log files for actions in the firewall is not a acceptable solution). It is the mail server service that has the potential to knowledge about failed logins - NOT the firewall. And the error control and flow control really doesn't satisfactory address the problem here.

For example -One attack a few days back on my mail server resulted in about 800 hammering failed logon tries within 30 minutes from the same IP (New session for each try). That is not much of an attack but still filled my logs with unnecessary junk when I was trying to look for other problems.

This might be the first mail server I have seen and certainly used that does not have any anti hammering feature.
Get in the game Axien!

There need to be a admin configurable:
- automatically temporary ban of IP for x time when x number of failed login attempts in x minutes has been received.
- automatically temporary lock of users for x time when x number of failed login attempts has been received.

Black and white list of course for manually configure IP's and mail addresses/hosts to circumvent the above settings.

Best regards
//Erik

I would like to see this feature be user defined. X number of bad passwords within X minutes, yields an X hour or X day ban before clearing. I would also like the ability to white list any IP so that it can't be blacklisted at all. Thanks

After 10 failed login attempts on the same account with same IP within 1 hour,
introduce a 1 hour ban from the IP to the account.
Write it into a log file and send an notification to admin.

It should able to unlock the account from webadmin.
The log and notification to admin is important to review and deny those attack from zombie network.

While reviewing my logs for another matter, I too found that my server was under attack from someone trying a brute force attack. In this case it was the STMP service they were attacking. I have implemented fail2ban and in less than 24 hours it has blocked 10 IP addresses. It would be nice of that kind of security was built into axigen itself. Clearly there is a need.

Till this suggestion will pass the review phase Linux users could use fail2ban (www.fail2ban.org) and Axigen security log (introduced from version 9) to block IP addresses.

More details about this implementation could be found in [1].

As @Gabriel has posted the most important issue is to take into consideration that an attack from a NATed PC will trigger a block for the WAN IP and this an increase of support tickets to the server support team will be observed,

Because of the IPv6 support (which will be introduced with Axigen 10) blocking IPs will be a more difficult process and, in my opinion, a better approach could be to introduce a delay at each failed login (which could double at each failure) making the dictionary password attack nonfunctional.

[1] https://www.axigen.com/forum/forum/support-discussion-lists/feature-requests/4154-brute-force-fail2ban-style-protection?p=23209#post23209

Hi,

What's still unclear to me is why error control + flow control is not enough.
More specifically, I'm referring to the combination of the following two options:

1. Error control
Close session after [x] failed authentication attempts (default: 5)
+
2. Flow control
Allow max. [y] new connections in [z minute(s)] from each remote IP (defaults: 600 new connections in 1 minute)

Could you please detail why the combination above is not sufficient?

I'm a bit reluctant in blocking IPs, because that might introduce frequent issues in the case of users behind a NAT, so I'm first trying to dig deeper into what's wrong / missing and identify improvements with less potential chances of generating more problems than the benefits they bring.

@Gabriel
Hi Gabriel,

this is for SMTP and IMAP as error control and flow control is not enough protection.
What is needed is a specific mechanism to block IP's that try to hack IMAP or SMTP users.
Thanks

@Everyone: do you have this problem on WebMail only? I'm asking as with POP3 & IMAP, Axigen already includes error control & flow control, which should provide enough protection mechanisms.

Hi Gabriel,

there is also a need for a block if:

IP address w.w.w.w has had x number of failed password attempts in the last y minutes. Block for z minutes

this is what usually happens that hackers try to go through a number of different usernames and passwords. So please do not just do this per userid, please also do this per IP.

Thanks

i think it is good conception.
One more: it should be possible to set exceptions for ip/ip range

Hi,

Regarding the wrong password attempts, here's a proposal that would apply on any service:

* After 5 failed login attempts on the same account within a 1 minute interval, introduce a 5 minutes ban until the next login try is allowed from that IP
* After 10 failed login attempts on the same account, introduce a 1 hour ban until the next login try is allowed from that IP
* List the temporary banned IPs in the webadmin, with the possibility for the admin to unblock.

Would this solve it?
Would we also need an email notification for the admin?
Would we also need the option for the admin to move to permanently denied IPs?

Best wishes,
Gabriel

+1 for wrong password blocklist