Fighting Hackers

Discussion forum for Enterprise Edition.
Posts: 58
Joined: Thu Oct 18, 2012 6:19 pm

Re: Fighting Hackers

Post by PMad » Fri Mar 24, 2017 10:06 pm

siteffect wrote:Blocking IP addresses on SMTP would be a good solution.
The best way that I can think of to block these is to have something that will block failed connection attempts by IP address. ME would count each consecutive failed login attempt by the IP address rather than the username, so lets say users are locked out after 5 failed login attempts, and this bot is set to try 5 passwords on an account before trying a different login. And lets say this setting is set to 7, so somebody with 7 failed login attempts would be banned for lets say 48 hours. This attacker would lock the first account, and after 2 attempts on the second account, the IP address would be banned for 48 hours. This would be helpful, not a solution but helpful.
Is this something that could be implemented in a next version ?
I created a suggestion in the suggestion forum for this in Feb:

There are no comments on it. I'd love to see the feature! It would definitely ease the pain and make daily maintenance much easier!
tomr wrote:Interesting reading on the web for ylmf-pc they have been at this for a few years. They are persistent bastards.
They could be somebody who is trying to gather valid email address and sell them for cash, or they could be somebody trying to hack into as many computers as possible to install things like ransomware which happened to me last week (i caught them in the middle, stopped them, and decrypted all the files they encrypted). People will do anything for money...

Posts: 88
Joined: Thu Jan 08, 2004 9:44 pm

Re: Fighting Hackers

Post by microwil » Sat Jul 28, 2018 7:37 pm

I upgraded to the new version of Mailenable because of the capable block ECHO function. But I am not happy with that. Every single attack will lead to a few lines written in the smtp log file before it stops. It means Mailenable didn't stop it in the 1st attack and have no memory of the ip. The perfect way of cause is your ISP do it. The second best will be your firewall do it. My firewall, if pay for it, can do it. I am now manually block those ip on my firewall because of the $ I don't have.
And the third way is if Mailenable can block them efficiently. NAS can now auto-block those attacks after let them play around a few times. Why don't Mailenable borrow this technology?

Posts: 36
Joined: Fri Jul 25, 2003 11:02 pm
Location: Sydney, NSW, Australia

Re: Fighting Hackers

Post by Philb » Sun Jul 29, 2018 11:22 pm

These "ylmf-pc" bots (any many others) speak out of turn. That is, the mail cleints do not wait for the SMTP server to properly greet them before sending their HELO/EHLO.

For some years I've run postfix as a front-end MTA to my ME server. I know from the postfix logs that every one of these ylmf-pc senders is detected as a PREGREETer:

Code: Select all

Jul  5 16:59:56 postfix/postscreen[31481]: PREGREET 14 after 0.32 from []:52718: EHLO ylmf-pc\r\n
After connection establishment, postfix fools these bots into talking out of turn by sending a fake greeting that a properly implemented mail client will ignore. It then waits to see if the client speaks before the proper greeting is sent.

After DNSBL lookups, pregreet detection is definitely the next most effective anti-spam tool that postfix gives me.

It would be great to see ME emulate this and provide a way to drop/refuse connections from repeat offenders.

Posts: 1
Joined: Thu Oct 18, 2018 1:27 am

Re: Fighting Hackers

Post by Charlott » Thu Oct 18, 2018 1:30 am

Hey, I use RDP Guard to block the <a href="">IP address.</a>

Posts: 8
Joined: Wed Apr 19, 2017 1:22 am

Re: Fighting Hackers

Post by AdamC » Sat Aug 29, 2020 3:51 am

I'm all for disabling the email accounts & IP addresses if someone repeatedly tries to hack in.

But INSTEAD of simply locking the email account, you should have a graded approach to the block:

Step 1 - Lock access to the account IF the IP is from a new country of login origin.

Step 2 - Restrict access to the account from IP's which have been used to successfully connect before.

Step 3 - lock access to the account.

I'll see if I can submit this to a suggestion inbox as well.

Post Reply