Re: [mailop] SMTP AUTH harassment
It appears that Patrick via mailop <201901-mai...@planhack.com> said: >Wow. A fake auth module would seem to invite spam storms. Which for some might >be handle-able and a good way to learn interactively with botnets? All mine does is say that the AUTH worked and send the subsequent message on a detour. Since the messages never get back to the bot herder, I don't think it's had any effect on the volume of spam attempts. I do wish it were easier to report and kill the drop boxes, though. It would be nice if regasignsd...@yahoo.com went away. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
Wow. A fake auth module would seem to invite spam storms. Which for some might be handle-able and a good way to learn interactively with botnets? Has anyone implemented such a thing? Thanks! ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
It appears that Al Iverson via mailop said: >I get many of these attempts too, and since I have no need for SMTP >AUTH at all, I use it all as suggestions of IPs to ban. I have a fake auth module that pretends to work and sends the message off to the spam trap. The messages have the IP, user, and pw to tell the bot herder that it found an exploitable relay. I've been meaning to let a few of those through and then see what the try to send. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
On 17/07/2021 21:13, Slavko via mailop wrote: Please, i want ask others if are these (mostly) Brasil attempts know to others too or am i "special" target? I seem to get continuous SMTP stuff. Work is much worse than my personal server. But we have 10's of domains and due to historical reasons the server on a few different IP addresses. And finally, please can someone help me to create fail2ban rule, which will catch network IP from these logs? While i am able to do own f2b rules and actions, i do not know how to catch (and use) network address in them and i cannot find any resource for it. I didn't really get on with fail2ban. I do have it running, but it pulls very little for exim. I did write my own script to follow the exim mainlog with a bunch of regexp and drop IP addresses into ipset. (task for future is to make it work nft natively) And I go for long blocks - days rather than minutes. Because most scanning seems to happen real slow now. Things that helped In exim acl_connect: accept hosts = +relay_from_hosts accept hosts = +trusted_nets accept hosts = * delay = 6s The delay 6 means that the connection is opened and exim waits 6 seconds - this confuses some botnets. And the resulting `AUTH command used when not advertise` really stands out in the logs. I've blocked 14 IPs using this in the last 10 minutes. obviously somebody might write a better botnet email client I'm also lucky that our usernames follow a bit of a format which isn't the email address. Seems quite common for bots to have a few guesses about what the username might be - again, easy to block. I also really look for auth requests that mention users who have left - these will never be genuine (years after), so block away. My main motivation for getting the blocking right is to avoid having 1000s of connections from scanners, and so real mail not getting through. -- Tim Bray Huddersfield, GB t...@kooky.org ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
I get many of these attempts too, and since I have no need for SMTP AUTH at all, I use it all as suggestions of IPs to ban. I do it with a very simple script like this: https://pastebin.com/5HtCFY7K It'd be easy to spruce this up and add some sort of tracking mechanism or counts or something, but it works fine for my limited use case as-is. Cheers, Al -- Al Iverson // Wombatmail // Chicago Deliverability: https://spamresource.com DNS Tools: https://xnnd.com ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
This particular botnet, (and you can tell this strain by the password list attempted, and the number of attempts from each IP) appears to come from at least two(2) actors, one which is a windows malware on older windows machines, and the other uses the gpon/router compromisd botnets. Interestingly, the bot appears to simply 'harvest' those email accounts if finds with weak passwords, and later uses a different system to actually utilize the compromised system, so maybe someone is just harvesting those for resale, but usually it is within a couple of days of the compromise, that it gets utilized. Seeing a lot of utilization from cloud providers, eg Azure, Google and AWS for these utilization. You should prevent logins from the cloud, for the most part.. The IP ranges (see earlier threads) are public knowledge. (Shameless plug, you can use RATS-AUTH and RATS-NULL for blocking auth attacks, and he are looking at making RATS-CLOUD public) But as far as those attacks from dynamic IP ranges, and IoT devices, well careful what you block, because that is where real people access it from. We do have country auth blocking on all our mitigation tools and mail platforms, and that is really helpful, and of course transparent 2FA should be used, and then it simply becomes noise in the logs. (Until that one customer decides to travel to Brazil ;) But even with country auth blocking, the real dangerous hackers simply get an IP address in your country. And while fail2ban is everyone's go to, remember that the botnets number in the millions, so they can simply do a couple of auth attacks from each IP, and spread the attack out. And of course, you should have auth rate limiters on an individual user basis, a trick we use is checking rate limiters per person on an IP Address + EHLO basis, which can really help for the majority, and there are some bots that randomize the EHLo in attacks, making it trickier, but the type of randomization they use is a signal all on it's own. And nowadays, with more use of Carrier Grade NAT, or really large wifi networks you have to be careful that one bad actor, doesn't block out a valid network. All in all, you can easily do improved auth ACL's and controls, but the only long term solution is transparent 2FA. (One approach, you can tighten 465/587/993/995 with country and cloud auth restrictions, and force everyone else to use with webmail or email clients that support transparent 2FA) On 2021-07-17 7:05 p.m., Andre van Eyssen via mailop wrote: On Sat, 17 Jul 2021, Slavko via mailop wrote: Please, i want ask others if are these (mostly) Brasil attempts know to others too or am i "special" target? Some other questions, which comes to my minds without answers, while perhaps nobody here will/can know right answer, i will ask: Nope, this is sadly a fact of life these days. At times there's way more bad auth attempts than actual mail running through one of my MXes. - i use blocklist.de IP list to block access on router for years, but i feeling in recent time as it is not as effective as before, can it be related, that i do not see similar attempts before? The fact that you're using a blocklist is probably why you're only seeing the distributed scattered attempts and not a roar from certain subnets. I've had a few /24s blocked for years now and every time I give them a test unblock they just start pouring brute force attempts in. Picking one subnet from the last little while, there are attempts from: Jul-18-21 00:24:40 [Worker_1] [TLS-out] 78.128.113.99 [SMTP Error] 535 5.7.8 Bad username or password (Authentication failed). Jul-18-21 00:44:15 [Worker_1] [TLS-out] 78.128.113.75 [SMTP Error] 535 5.7.8 Bad username or password (Authentication failed). Jul-18-21 01:09:57 [Worker_1] [TLS-out] 78.128.113.74 [SMTP Error] 535 5.7.8 Bad username or password (Authentication failed). Jul-18-21 01:41:02 [Worker_1] [TLS-out] 78.128.113.77 [SMTP Error] 535 5.7.8 Bad username or password (Authentication failed). Jul-18-21 01:46:41 [Worker_1] [TLS-out] 78.128.113.74 [SMTP Error] 535 5.7.8 Bad username or password (Authentication failed). Jul-18-21 01:46:46 [Worker_1] 78.128.113.69 [SMTP Error] 521 (redacted) does not accept mail - closing transmission - too many previous AUTH errors from network 78.128.113.0 (After five attempts the /24 goes into the sin bin and all auth attempts are rejected.) -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for
Re: [mailop] SMTP AUTH harassment
On 2021-07-18 at 06:43:51 UTC-0400 (Sun, 18 Jul 2021 12:43:51 +0200) Slavko via mailop is rumored to have said: [...] The only usable way seems to be GoiIP blocking countries, but i afraid that it is wrong way. Why? If you have no users who need to authenticate from a particular network, there's no need to allow access from that network. If knowing where a network is based helps you make an accurate estimation of whether access from that network is needed, what's wrong with that? On one small mail server I manage, I have 346 IPv4 networks blocked from all ports that expose any password-based authentication, with some of those being /6 networks. None of the users of that system need to use IMAP, POP, or mail submission from cloud server networks or random parts of of other continents. On an everyday basis, all valid authentication attempts come from US and Canadian mobile networks, a handful of retail access providers, and a regionally limited collection of office networks. For the rare cases where users need to connect from random places, I have a 'web knocking' rig to poke holes as needed. The whole attack took about 5-6 hours. I will continue to investigate weakforced for future as i feel, that it is not real end, only pause... Anyway, despite of all words about Kerckhoffs's principle, using the same email address as login name seems to be wrong approach (as someone pointed already), because without valid username no password will match and thus knowing username saves 50 % of the attacker work. Thus while username is not secret, not revealing it can help... Of course, to hide username is not (enough) security method. Not using the email login identity as an actual email address is very useful in preventing *successful* account cracking, but it does not prevent the steady stream of doomed authentication attempts. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
Hi, Dňa Sun, 18 Jul 2021 06:54:07 +0200 Slavko via mailop napísal: > To see from where they come i did simple Python(3) script, which reads > list of IP from stdin and prints some stats based on GeoLite2 DBs. > When i feed it with IPs parsed from today dovecot's fail2ban log i > can see: Seems to be finished for now. fail2ban will not help with it at all, as no one IP was used more than twice and even very little amount of networks was repeated (little improved script's output): Top 5 of 50 countries: 241 South Korea (KR) 104 Japan (JP) 75 Hong Kong (HK) 40 United States (US) 40 Taiwan (TW) Top 5 of 546 networks: 12 223.16.0.0/14 (9304, HK) 10 219.100.37.0/24 (36599, JP) 8 117.146.0.0/16 (9808, CN) 7 113.252.0.0/14 (9304, HK) 7 221.124.0.0/14 (9304, HK) Top 5 of 697 (total 713) IPs: 2 179.35.122.18 (BR) 2 112.164.147.228 (KR) 2 191.177.186.129 (BR) 2 88.215.95.21 (DE) 2 219.73.72.159 (HK) The only usable way seems to be GoiIP blocking countries, but i afraid that it is wrong way. The whole attack took about 5-6 hours. I will continue to investigate weakforced for future as i feel, that it is not real end, only pause... Anyway, despite of all words about Kerckhoffs's principle, using the same email address as login name seems to be wrong approach (as someone pointed already), because without valid username no password will match and thus knowing username saves 50 % of the attacker work. Thus while username is not secret, not revealing it can help... Of course, to hide username is not (enough) security method. regards -- Slavko http://slavino.sk pgp7byj4jwJIH.pgp Description: Digitálny podpis OpenPGP ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
