Re: [mailop] SMTP AUTH harassment
On Mon 26/Jul/2021 21:38:21 +0200 yuv wrote: On Mon, 2021-07-26 at 18:34 +0200, Alessandro Vesely via mailop wrote: On Tue 20/Jul/2021 04:17:31 +0200 Ángel via mailop wrote: On 2021-07-19 at 23:27 +0200, Slavko wrote: Dňa Sun, 18 Jul 2021 13:56:18 -0400 Bill Cole: The only usable way seems to be GoiIP blocking countries, but i afraid that it is wrong way. Why? Hard to describe it in English for me, but i will try. I consider blocking access by country as discriminating all honest people in particular country. (...) You opened the thread describing it as a "personal mail server". I interpret that as being a mta serving just you, or a few select family members/friends. As such you can (should?) be highly selective. >> I run a personal mail server too. I agree with safety arguments and all what Bill said. However, any family member/ friend of mine, or even myself, could travel abroad for a week and forget to punch that hole in the firewall. In addition, some use foreign services that login on their behalf (gmail is one). Punch hole in the firewall function must be easy. All user need to do is call a URL from the IP address from which they want to send email. Arrive at the hotel, log on to WiFi, hit https://example.com/hereIam with some authorization token or password and the hole in the firewall is punched automatically for the next 24 hours. If they forget, they get a bounce back from the mail server, they do the log on and they resend. Sounds cute. I have something similar to exceed daily send limit of 100 msgs. Nobody has ever used it, yet. Define "foreign?" -- to me, in the hostile world of the internet, every IP address that is not under my control is foreign. Yeah, right. I meant in the Geo sense. However, I discriminate by country when I report such abuses. I only send reports to countries where I expect providers act under democratic laws. > How do you know the laws of all countries? when interests are aligned, autocratic laws are better than democratic laws. If China's rulers decide to clamp down on spam emission, you can bet that their enforcement and therefore their outcome will be superior to that of any self-righteous idiocracy. Hm... China is often accused of punishing lawbreakers excessively. OTOH, Russia doesn't seem to have any aim at reducing cyber-piracy. But then I don't know, and IANAL. I keep clear. And the big ISP/ESP are like not-so-little autocracies. If Microsoft/ Google/ Amazon wanted to reduce spam, they could do it by cutting accounts aggressively. However, that is not aligned with their interest of making money. Those amounts are all associated with a credit card. Not necessarily the spammer's, but as long as money flows in, GAFAM will not make a fuzz about it. That deserves being countered. However, spam is different from clownish password cracking attempts. Even GAFAM counter it actively. I don't want to wreak more havoc than it deserves, nor to deal with incomprehensible problems. This discrimination also helps reducing the overall number of reports being sent. Does that make any sense? If it makes sense for you, by all means. Given the outcome, I wonder how many of these reports are directed straight through to /dev/null with zero human review. /dev/null is probably the main recipient. Some abuse teams bounce. Some (e.g. OVH) reply automated messages saying that they only accept complaints through their web interface. (I have a no-send list for that.) I figure most of those abusers are half-interested webmasters who fell victim of bot intrusions. Good ISPs notify their customers who, in turn, remove the malware. I can gauge ISP intervention by steadily decreasing complaint rates. Best Ale -- ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
On Mon, 2021-07-26 at 18:34 +0200, Alessandro Vesely via mailop wrote: > On Tue 20/Jul/2021 04:17:31 +0200 Ángel via mailop wrote: > > On 2021-07-19 at 23:27 +0200, Slavko wrote: > > > Dňa Sun, 18 Jul 2021 13:56:18 -0400 Bill Cole: > > > > > > > > The only usable way seems to be GoiIP blocking countries, but > > > > > i > > > > > afraid that it is wrong way. > > > > > > > > Why? > > > > > > Hard to describe it in English for me, but i will try. > > > > > > I consider blocking access by country as discriminating all > > > honest > > > people in particular country. (...) > > > > You opened the thread describing it as a "personal mail server". I > > interpret that as being a mta serving just you, or a few select > > family > > members/friends. > > As such you can (should?) be highly selective. If you only use ISP > > A, > > why should you allow from any other source? It's not as if you > > won't > > notice when you change providers. If John uses only provider B, why > > would you let a login from ISP C? > > I run a personal mail server too. I agree with safety arguments and > all what Bill said. However, any family member/ friend of mine, or > even myself, could travel abroad for a week and forget to punch that > hole in the firewall. In addition, some use foreign services that > login on their behalf (gmail is one). Punch hole in the firewall function must be easy. All user need to do is call a URL from the IP address from which they want to send email. Arrive at the hotel, log on to WiFi, hit https://example.com/hereIam with some authorization token or password and the hole in the firewall is punched automatically for the next 24 hours. If they forget, they get a bounce back from the mail server, they do the log on and they resend. Define "foreign?" -- to me, in the hostile world of the internet, every IP address that is not under my control is foreign. > However, I discriminate by country when I report such abuses. I only > send reports to countries where I expect providers act under > democratic laws. How do you know the laws of all countries? when interests are aligned, autocratic laws are better than democratic laws. If China's rulers decide to clamp down on spam emission, you can bet that their enforcement and therefore their outcome will be superior to that of any self-righteous idiocracy. And the big ISP/ESP are like not-so-little autocracies. If Microsoft/Google/Amazon wanted to reduce spam, they could do it by cutting accounts aggressively. However, that is not aligned with their interest of making money. Those amounts are all associated with a credit card. Not necessarily the spammer's, but as long as money flows in, GAFAM will not make a fuzz about it. > I don't want to wreak more havoc than it deserves, nor to deal with > incomprehensible problems. This discrimination also helps reducing > the overall number of reports being sent. > > Does that make any sense? If it makes sense for you, by all means. Given the outcome, I wonder how many of these reports are directed straight through to /dev/null with zero human review. -- Yuval Levy, JD, MBA, CFA Ontario-licensed lawyer ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
On Tue 20/Jul/2021 04:17:31 +0200 Ángel via mailop wrote: On 2021-07-19 at 23:27 +0200, Slavko wrote: Dňa Sun, 18 Jul 2021 13:56:18 -0400 Bill Cole: The only usable way seems to be GoiIP blocking countries, but i afraid that it is wrong way. Why? Hard to describe it in English for me, but i will try. I consider blocking access by country as discriminating all honest people in particular country. (...) You opened the thread describing it as a "personal mail server". I interpret that as being a mta serving just you, or a few select family members/friends. As such you can (should?) be highly selective. If you only use ISP A, why should you allow from any other source? It's not as if you won't notice when you change providers. If John uses only provider B, why would you let a login from ISP C? I run a personal mail server too. I agree with safety arguments and all what Bill said. However, any family member/ friend of mine, or even myself, could travel abroad for a week and forget to punch that hole in the firewall. In addition, some use foreign services that login on their behalf (gmail is one). By now, all my users learned that the paradoxicality of "password" doesn't make it so unusual that no cracker would even try it. So the added risk of accepting attempts from abroad doesn't seem to worsen the overall state of affairs. However, I discriminate by country when I report such abuses. I only send reports to countries where I expect providers act under democratic laws. I don't want to wreak more havoc than it deserves, nor to deal with incomprehensible problems. This discrimination also helps reducing the overall number of reports being sent. Does that make any sense? I paste the relevant snippet from my script below. Am I missing some? Best Ale -- case "$country" in "AU"|"HK"|"ID"|"IN"|"JP"|"KR"|"NC"|"NP"|"NZ"|"SG"|"TH"|"TW") rdap_url="https://rdap.apnic.net/ip/$key";;; "US"|"CA"|"BB") rdap_url="http://rdap.arin.net/registry/ip/$key";;; "AL"|"AT"|"BE"|"BG"|"CH"|"DE"|"DK"|"ES"|"FI"|"FR"|"GB"|"GR"|"IE"|"IL"|"IS"|"NL"|"NO"|"PL"|"RO"|"SE"|"SI"|"SK"|"TR") rdap_url="https://rdap.db.ripe.net/ip/$key";;; "BW"|"CV"|"MU"|"ZA") rdap_url="https://rdap.afrinic.net/rdap/ip/$key";;; "AR"|"BR"|"CO"|"CR"|"MX"|"PY"|"UY") rdap_url="https://rdap.lacnic.net/rdap/ip/$key";;; *) let non_reported_bp++ rdap_url="" ;; esac ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
On Sun, 2021-07-18 at 13:56 -0400, Bill Cole via mailop wrote: > 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? IMHO this should be the general design principle of every protocol, every server, and every router going forward. I just have not been bothered enough so far and have simply steered clear of obvious creepware devices: I do not an LG TV to report my viewing habits, a Samsung washer/dryer to report my laundry habits, and some shady dataminer inferring that if I stopped watching porn and am doing more laudry on the delicate cycle I got a girlfriend and they can now spam me with Valentine Day offers instead of XXX. For SMTP, there is the added complexity that sometimes I have an obligation to receive emails. I was recently a side-show on a Federal Court case in which the judge allowed service per email. To a few hundred parties, many with gmail/hotmail and the like. The behavior of the big mail servers outcompetes some of the most notorious defendants absconding service. As long as SMTP is plagued with these deliverability issues (and with the even worse problem of spam), it is good for internal email only. The guy who predicted the pandemic does not always get it right: https://www.nytimes.com/2004/01/26/business/gates-predicts-that-spam-will-go-away.html In that case, one could think of that statement as willful blindness, since spam is in the eyes of the beholder, and spam is good business for the company he represented back then, it seems. -- Yuval Levy, JD, MBA, CFA Ontario-licensed lawyer ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
On 2021-07-19 at 23:27 +0200, Slavko wrote: > Hi, > > Dňa Sun, 18 Jul 2021 13:56:18 -0400 Bill Cole: > > > > The only usable way seems to be GoiIP blocking countries, but i > > > afraid that it is wrong way. > > > > Why? > > Hard to describe it in English for me, but i will try. > > I consider blocking access by country as discriminating all honest > people in particular country. (...) You opened the thread describing it as a "personal mail server". I interpret that as being a mta serving just you, or a few select family members/friends. As such you can (should?) be highly selective. If you only use ISP A, why should you allow from any other source? It's not as if you won't notice when you change providers. If John uses only provider B, why would you let a login from ISP C? This is not about limiting people. It would be wrong not to let someone access a public place¹ based on their race or nationality.² We are talking about your own server, such as your home. It would be perfectly fine not to let any Elbonians to the door of your house if you don't have any Elbonian friend (or you know they will tell you before paying you a visit) or, conversely, to ask the doorman to filter out any visitors not wearing hats. Of course, they would still need a key to open the door to your house, but there's no reason to to a quick filtering before letting them try their lock-picking skills. Regards ¹ In a broad meaning, including privately-owned ones, such as a shopping center. ² Ok, you may argue that an embassy might be considered a "public place" and yet to have a legitimate reason for being highly selective on your nationalitiy. PS: > One can be surprised, but my long term country stat shows, that worst countries are USA and Germany, and no, China is even not in top 10. (...) For July, the top number of fake auth attempts come from US, RU, BG, CN, BR and NL. If counting just distinct IP addresses, it's BR, CN, IN, PL, N/A, IR, US, AR, RU, KR ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
On 2021-07-18 at 22:29 -0400, John Levine via mailop wrote: > > I do wish it were easier to report and kill the drop boxes, though. > > It would be nice if regasignsd...@yahoo.com went away. I was only visited by that on July 9th. Others like mx-server.org are much more persistent here. Here are some of the most common drops I have seen this month (some using AUTH, others just trying to get by with a return-path): 4247 → Just from a couple of Russian IP addresses 3745 3233 → 2k IPs, 35 countries 2899 2433 1292 1193 → Uses tor exit nodes 1134 642 → 1k IPs, 26 countries 269 → From a single source: 89.42.211.197 152 → Apparently a new mail of yurespav...@libero.it 64 Cheers ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
On 2021-07-19 at 17:27:58 UTC-0400 (Mon, 19 Jul 2021 23:27:58 +0200) Slavko via mailop is rumored to have said: Hi, Dňa Sun, 18 Jul 2021 13:56:18 -0400 Bill Cole via mailop napísal: The only usable way seems to be GoiIP blocking countries, but i afraid that it is wrong way. Why? Hard to describe it in English for me, but i will try. I consider blocking access by country as discriminating all honest people in particular country. One can be surprised, but my long term country stat shows, that worst countries are USA and Germany, and no, China is even not in top 10. Yes, my stats are screwed by blocking from blocklist.de, which seems to catch about 50 % of abusive access and those never reach the server, thus are missing in that stats, but anyway... And yes, i have in my stats my own country too, while far away from top. I am doing no one in Europe any injury by not accepting connections to ports 465, 587, 993, and 995 from the European networks from which I've had authentication attacks. It isn't something the millions of innocent honest Europeans will ever notice, because none of them have any legitimate reason to make any sort of connection to those ports. I do not offer anyone based in Europe or Asia or South America or Africa any form of mail submission, POP, or IMAP service, so no one who is blocked from those ports for essentially geographic reasons is in any way affected by that blocking. Second, blocking by country breaks the main Internet purpose -- connect together the whole world. I also do not allow the world as a whole to connect to port 22 on any of my systems and for the very few networks that I do allow to try, I require that they have a valid authorized SSH key for a user whose account is enabled for login. Neither that nor my restrictions on access to any other authenticated services impede my connectivity to the whole world. I also don't operate any open mail relays, and that also is not an injury to universal communication. Finally, blocking by country seems as simplest solution. But many of (if not all) simplest solutions are not good solutions too. They are simple only simplest. Do one remember one of simplest solution in past -- cut off burglar's hands? It solved nothing... Blocking access to services that require authentication at the network/transport layer from networks which never have been and never will be the sources of legitimate access injures no one. 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? It is 2021 year here, people are not slaves nor vassals, they are free to travel, they use VPSs, VPNs, proxies, etc for good purpose, not only to hide their abusive behaviour. I do not want to limit nor to spy them, especially when they are family or friends. They must be free to use services from anywhere and does not matter, if they need this or not. That's all quite hypothetical. As a practical matter, eliminating the overwhelming majority of authentication attacks by wholesale blocking of problematic networks with geography as one of many decision factors is relatively easy to do without causing legitimate users any meaningful problems. 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. I do not afraid to block whole network blocks (even countries), but it must have good reason AND must be short term solution. Once again, in most of network blocks are honest people, even clouds (VPS) are using honest people too. And in this specific case, there is no overlap between the good honest people using mobile phone networks and cloud providers in China or OVH in Europe or government systems in Brazil and the good honest people who have reasons to use my personal mail server for initial mail submission, POP, IMAP, or SSH. If and when there is some overlap, I'm sure the support effort to solve the difficulty will be minimal. Consider, why are RBLs, which block whole network blocks (and people which use them), as often criticised not only in this list history. Why people complains (again not only in this list) about mail providers, which rejects mails only due bad neighbours, etc, etc... Irrelevant. I'm not advocating that anyone apply the same criteria to block inbound mail (i.e. port 25) as to block access to authenticated services. That would be silly. Yes, one can tell that even behind one IP can be honest people too, and will be right. In ideal world we will able to distinguish them, unfortunately we are living in real world, not in ideal. In ideal world they all will have unique IP (no IPv6 will not solve it), until this we have to live with this limitation, but we mu
Re: [mailop] SMTP AUTH harassment
Hi, Dňa Sun, 18 Jul 2021 13:56:18 -0400 Bill Cole via mailop napísal: > > The only usable way seems to be GoiIP blocking countries, but i > > afraid that it is wrong way. > > Why? Hard to describe it in English for me, but i will try. I consider blocking access by country as discriminating all honest people in particular country. One can be surprised, but my long term country stat shows, that worst countries are USA and Germany, and no, China is even not in top 10. Yes, my stats are screwed by blocking from blocklist.de, which seems to catch about 50 % of abusive access and those never reach the server, thus are missing in that stats, but anyway... And yes, i have in my stats my own country too, while far away from top. Second, blocking by country breaks the main Internet purpose -- connect together the whole world. Finally, blocking by country seems as simplest solution. But many of (if not all) simplest solutions are not good solutions too. They are simple only simplest. Do one remember one of simplest solution in past -- cut off burglar's hands? It solved nothing... > 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? It is 2021 year here, people are not slaves nor vassals, they are free to travel, they use VPSs, VPNs, proxies, etc for good purpose, not only to hide their abusive behaviour. I do not want to limit nor to spy them, especially when they are family or friends. They must be free to use services from anywhere and does not matter, if they need this or not. > 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. I do not afraid to block whole network blocks (even countries), but it must have good reason AND must be short term solution. Once again, in most of network blocks are honest people, even clouds (VPS) are using honest people too. Consider, why are RBLs, which block whole network blocks (and people which use them), as often criticised not only in this list history. Why people complains (again not only in this list) about mail providers, which rejects mails only due bad neighbours, etc, etc... Yes, one can tell that even behind one IP can be honest people too, and will be right. In ideal world we will able to distinguish them, unfortunately we are living in real world, not in ideal. In ideal world they all will have unique IP (no IPv6 will not solve it), until this we have to live with this limitation, but we must do not do things even worse... That is why we have SPAM checks software, brute forcing guards and similar solutions. Their purpose is distinguish honest access from abusive on per case base, not by its origination. One again one no, simplest solutions are only rarely good solutions at once. (I hope, that i wrote this properly in English...) regards -- Slavko http://slavino.sk pgp__X6twfbuz.pgp Description: Digitálny podpis OpenPGP ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
On 2021-07-18 9:46 p.m., Patrick via mailop wrote: 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! I've been doing it for at least 5 years. When a couple of IPs decide that you're "vulnerable" (tee hee) the volumes can spike enormously. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
Hi, Dňa Mon, 19 Jul 2021 00:34:40 +0100 Tim Bray via mailop napísal: > 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) i have a lot custom rules in it, to catch even my own log messages (exim's logwrite, log_message and/or message stuff). It works well for my config and offending IP, of course fails in this case as IP doesn't repeats. I do block for relative short time (1 hour) to quick reveal of false positives, and i use f2b's recidive jail to add long block on repeating hosts. If you want, be free to contact me off list, i can help you with it. There is not need to do own parsing, when f2b can do it for you. > acl_connect: > accept hosts = * > delay = 6s I have RBL & PTR checks in connect ACL. It works well, as it ads timeout too (even bigger on some failing PTR checks). But i have separate exim for MX & MSA, thus i can simple distinguish AUTH access (and abuse) from incoming mails in this ACL. The problem with rejecting connection is, that many clients consider it as network failure and repeats constantly, even when they got own timeout (disconnects before got answer). But thanks to f2b, they are blocked shortly and thus it is effective. > - this confuses some botnets. Some are confused by multiline banner too, they are then caught as out of sync by exim ;-) But, eg. rspamd's reporting is confused too... I noticed that recent exim adds connect pipelining, but i use older version yet. > obviously somebody might write a better botnet email client or they abuse real MTA for delivery... > 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 agree. While it is not about security, one can simply distinguish login attempts on harvested email addresses. I use this approach for years, and where it is (was) not possible, i never do use email address which is login name, but its aliases. But nowadays gmail's generation doesn't know about aliases... > My main motivation for getting the blocking right is to avoid having > 1000s of connections from scanners, and so real mail not getting > through. Sure, blocking them is mostly not due security (but it counts too), but about saving own resources. Most of the (one shot) abusers then move away, to find more simpler target. But some have "long cable" and try to "break wall by head" (in quotes raw translation of our idioms). For now it seems, that this SMTP attack is gone, and i can to enjoy on the next one... regards -- Slavko http://slavino.sk pgpPZHrdA2cyh.pgp Description: Digitálny podpis OpenPGP ___ 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? In case you don't know about it already, have a look at https://www.abuseipdb.com/ . Some people have scripts to report things like auth abuse here, so you can see if IP addresses you're getting attacked by are attacking others. -- Paul Paul Smith Computer Services supp...@pscs.co.uk - 01484 855800 -- Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 Sign up for news & updates at http://www.pscs.co.uk/go/subscribe ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
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 th
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
Re: [mailop] SMTP AUTH harassment
On 2021-07-17 22: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've seen it for at least 16ish years, at work and on my personal servers. Mostly Brazil, South Korea, Turkey and Vietnam (+honourable mentions to VPSes in France, Belgium, The Netherlands and USA). So no, you're not special :-) / Jesper ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
Hi,
Dňa 17 Jul 2021 20:41:14 -0400 John Levine via mailop
napísal:
> It appears that Thomas Hochstein via mailop said:
> About 12,000 here. It's a botnet, it's not targeting you any more
> than any other random server it can find, and I don't know of any way
> to block it. You can use something like fail2ban to block individual
> IPs but it's a very large botnet.
Thanks a lot for all answers, it helped me to understand that it is not
by some of my mistake, as i always care about own mistakes first...
> The logins are pretty random:
Now the IMAP (dovecot) attack starts again, where i see full failed
logins log. While it seems as different botnet (different IP
sources/countries) i see, that only one account is targeting with
passwords (and its variations) which looks know to me, but i cannot
bring in mid from where ;-) But this current attack seems to be more
massive than previous, as my F2B log shows twice IP blocked yet (and it
grows).
Ad blocklist.de: i update IP list (ipset with timeout) hourly with
adding only new (recent) IPs from this list and count of added IP is
loged. There was times, when script adds hourly about 2500 IP, now it
is adding only about 500 - 600. It doesn't help - i watch on
incoming SYN packets on router and i see very little amount without
SYN+ACK, thus only very little IP are blocked...
Ad fail2ban: it helps, not a lot, but helps. I did some research before
i go to to sleep yesterday, and i found why i do not know how to block
subnets in fail2ban, as it was introduced in its 0.10.5 version, but in
debian stable there is only 0.10.2, but anyway blocking subnets will
help only little more (see stats below).
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:
Top 5 countries of 33:
75 South Korea (KR)
36 Japan (JP)
25 Hong Kong (HK)
20 China (CN)
18 Taiwan (TW)
Top 5 networks of 220:
7 117.146.0.0/16
4 113.252.0.0/14
4 111.240.0.0/12
3 77.53.0.0/16
3 219.100.37.0/24
Top 5 IPs of 257:
2 191.177.186.129
2 88.215.95.21
2 219.73.72.159
1 37.57.200.229
1 59.8.115.197
I do not know if attachments are allowed here, thus i add it here, if
someone is interested:
import sys
from collections import Counter
import geoip2.database
icnt = Counter()
ccnt = Counter()
ncnt = Counter()
total = 0
maxi = 5
with geoip2.database.Reader('/var/lib/GeoIP/GeoLite2-Country.mmdb') as creader,
\
geoip2.database.Reader('/var/lib/GeoIP/GeoLite2-ASN.mmdb') as areader:
for ip in sys.stdin:
ip = ip.strip()
ctr = creader.country(ip)
asn = areader.asn(ip)
isoc = f"{ctr.country.name} ({ctr.country.iso_code})"
netw = str(asn.network)
icnt[ip] += 1
ccnt[isoc] += 1
ncnt[netw] += 1
total += 1
print(f"\nTop {maxi} countries of {len(ccnt)}:")
for k, v in ccnt.most_common(maxi):
print(" %-3s %s" % (v, k))
print(f"\nTop {maxi} networks of {len(ncnt)}:")
for k, v in ncnt.most_common(maxi):
print(" %-3s %s" % (v, k))
print(f"\nTop {maxi} IPs of {len(icnt)}:")
for k, v in icnt.most_common(maxi):
print(" %-3s %s" % (v, k))
One can tweak the maxi value, if want to see more top items...
regards
--
Slavko
http://slavino.sk
pgpIIQsP66Zyf.pgp
Description: Digitálny podpis OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
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.) -- Andre van Eyssen. Phone: +61 417 211 788 mail: an...@purplecow.org http://andre.purplecow.org About & Contact: http://www.purplecow.org/andre.html ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
It appears that Thomas Hochstein via mailop said: >Slavko wrote: > >> Please, i want ask others if are these (mostly) Brasil attempts know to >> others too or am i "special" target? > >Personal server here too. > >| root@moria # grep 'Incorrect authentication data' /var/log/exim4/mainlog.1 | >wc -l >| 1026 > >So, a bit more than 1.000 attempts yesterday. About 12,000 here. It's a botnet, it's not targeting you any more than any other random server it can find, and I don't know of any way to block it. You can use something like fail2ban to block individual IPs but it's a very large botnet. The logins are pretty random: 2021-07-15 01:09:03.374311500 mailfront[97178]: Fake login rssman / abc123 2021-07-15 01:09:05.838211500 mailfront[97183]: Fake login bob_fr / qwerty 2021-07-15 01:09:06.772155500 mailfront[97191]: Fake login andrew / asdfgh 2021-07-15 01:09:07.335611500 mailfront[97194]: Fake login nnsquad / abc123456 2021-07-15 01:09:07.898144500 mailfront[97195]: Fake login rssmanagi / abc123456 2021-07-15 01:09:10.362742500 mailfront[97201]: Fake login bob_fr / asdfgh 2021-07-15 01:09:11.357415500 mailfront[97208]: Fake login andrew_ / letmein 2021-07-15 01:09:11.853999500 mailfront[97212]: Fake login nnsqua / 00 2021-07-15 01:09:12.347805500 mailfront[97215]: Fake login rssman / 00 2021-07-15 01:09:14.819537500 mailfront[97224]: Fake login bob_fra / letmein 2021-07-15 01:09:15.370713500 mailfront[97214]: Fake login tele / 7001 2021-07-15 01:09:15.924577500 mailfront[97229]: Fake login andrew / abc123 2021-07-15 01:09:16.431118500 mailfront[97235]: Fake login nnsqua / 123123 2021-07-15 01:09:16.789482500 mailfront[97236]: Fake login rssman / 123123 2021-07-15 01:09:19.228958500 mailfront[97241]: Fake login tele / 4001 2021-07-15 01:09:19.270550500 mailfront[97243]: Fake login bob_fr / abc123 2021-07-15 01:09:20.502396500 mailfront[97251]: Fake login andrew_ma / abc123456 2021-07-15 01:09:21.005099500 mailfront[97256]: Fake login nnsqua / 11 2021-07-15 01:09:21.275142500 mailfront[97258]: Fake login rssman / 11 2021-07-15 01:09:23.93500 mailfront[97267]: Fake login bob_frank / abc123456 2021-07-15 01:09:24.922478500 mailfront[97274]: Fake login andrew / 00 2021-07-15 01:09:25.596200500 mailfront[97279]: Fake login nnsqua / 22 2021-07-15 01:09:25.772230500 mailfront[97280]: Fake login rssman / 22 2021-07-15 01:09:28.488612500 mailfront[97289]: Fake login bob_fr / 00 2021-07-15 01:09:29.315868500 mailfront[97299]: Fake login andrew / 123123 2021-07-15 01:09:30.066903500 mailfront[97302]: Fake login nnsqua / 33 2021-07-15 01:09:30.179992500 mailfront[97304]: Fake login rssman / 33 2021-07-15 01:09:33.019374500 mailfront[97317]: Fake login bob_fr / 123123 2021-07-15 01:09:33.807393500 mailfront[97323]: Fake login andrew / 11 2021-07-15 01:09:34.482521500 mailfront[97328]: Fake login nnsqua / 44 2021-07-15 01:09:34.719871500 mailfront[97329]: Fake login rssman / 44 2021-07-15 01:09:37.517548500 mailfront[97336]: Fake login bob_fr / 11 2021-07-15 01:09:38.452654500 mailfront[97343]: Fake login andrew / 22 2021-07-15 01:09:39.100721500 mailfront[97346]: Fake login nnsqua / 55 2021-07-15 01:09:39.158732500 mailfront[97347]: Fake login rssman / 55 2021-07-15 01:09:42.019243500 mailfront[97356]: Fake login bob_fr / 22 2021-07-15 01:09:43.087836500 mailfront[97364]: Fake login andrew / 33 2021-07-15 01:09:43.571643500 mailfront[97367]: Fake login rssman / 66 2021-07-15 01:09:43.656882500 mailfront[97368]: Fake login nnsqua / 66 2021-07-15 01:09:46.697044500 mailfront[97375]: Fake login bob_fr / 33 2021-07-15 01:09:47.531018500 mailfront[97386]: Fake login andrew / 44 2021-07-15 01:09:48.110315500 mailfront[97390]: Fake login nnsqua / 77 2021-07-15 01:09:48.117088500 mailfront[97388]: Fake login rssman / 77 2021-07-15 01:09:51.304767500 mailfront[97397]: Fake login bob_fr / 44 2021-07-15 01:09:52.100357500 mailfront[97406]: Fake login andrew / 55 2021-07-15 01:09:52.679086500 mailfront[97407]: Fake login rssman / 88 2021-07-15 01:09:52.699856500 mailfront[97408]: Fake login nnsqua / 88 2021-07-15 01:09:55.784831500 mailfront[97416]: Fake login bob_fr / 55 2021-07-15 01:09:56.733251500 mailfront[97421]: Fake login andrew / 66 2021-07-15 01:09:57.219744500 mailfront[97422]: Fake login nnsqua / 99 2021-07-15 01:09:57.260230500 mailfront[97423]: Fake login rssman / 99 2021-07-15 01:10:00.259598500 mailfront[97429]: Fake login bob_fr / 66 2021-07-15 01:10:01.268775500 mailfront[97436]: Fake login andrew / 77 2021-07-15 01:10:01.777671500 mailfront[97438]: Fake login nnsqua / 696969 2021-07-15 01:10:01.853818500 mailfront[97437]: Fake login rssman / 696969 2021-07-15 01:10:04.698859500 mailfront[97455]: Fake login bob_fr / 77 2021-07-15 01:10:05.905906500 mailfront[97464]: Fake login andrew / 88 2021-07-15 01:10:06.302905500 mailfront[97469]: Fake login nnsqu / admin
Re: [mailop] SMTP AUTH harassment
Slavko wrote: > Please, i want ask others if are these (mostly) Brasil attempts know to > others too or am i "special" target? Personal server here too. | root@moria # grep 'Incorrect authentication data' /var/log/exim4/mainlog.1 | wc -l | 1026 So, a bit more than 1.000 attempts yesterday. > The IP > is only rarely used more than once, and as one can see, the IP networks > and AS numbers doesn't get high counts too (with some exceptions which > i blocked manually). Same here, fail2ban doesn't help that much. > I do not know what > accounts/passwords they are trying, as real AUTH doesn't happen. Most try "postmaster" at domains the host is MX for, others try harvested addresses from domains the host is MX for (with and without domain), and yet others try addresses I know that have no obvious connection to that host. None of those has an STMP-Auth password, so no harm done. -thh ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] SMTP AUTH harassment
Hi all! I registered here only in recent time and this is my first post here (i am sorry, my English is not best)... In recent days i bother with many login attempt to my personal mail server, which i use for some years. I meet distributed dictionary attack to IMAP server which was partially blocked by my fail2ban with some manual intervention. But attempts to login into SMTP server are less often, thus more difficult to catch. I will shortly describe current situation: They all connects to port 465 (as i do not provide other for logins) and repeats one attempt about every hour (30 - 90 min) any from different IPs. Most of them are known to SpamHaus CSS/XBL, which i use to deny AUTH for them. They waits max. about 10 s to every response (connect, EHLO, AUTH), and then disconnects without QUIT. They disconnect without QUIT to 5xx response to AUTH too. I do not know what accounts/passwords they are trying, as real AUTH doesn't happen. Two or three days ago i decided to extend AUTH response delay to they disconnect before they get reply and to see what happens. This results in burst 8 - 12 attempts every time, again all from different IPs. They are logged and counted by exim's notQUIT ACL, here is excerpt (wrapped manually): 2021-07-17 20:18:02 H=[186.190.163.50] NotQ connection-lost (AS:27953 10.5, N:186.190.163.0/24 1.0, C:AR 40.1) EHLO,AUTH 2021-07-17 20:18:24 H=[202.52.230.206] NotQ connection-lost (AS:4613 2.6, N:202.52.230.0/24 1.0, C:NP 4.3) EHLO,AUTH 2021-07-17 20:18:46 H=[187.62.177.90] NotQ connection-lost (AS:262662 1.0, N:187.62.176.0/21 1.0, C:BR 301.1) EHLO,AUTH 2021-07-17 20:19:14 H=[103.63.29.72] NotQ connection-lost (AS:134888 2.0, N:103.63.29.0/24 2.0, C:IN 46.7) EHLO,AUTH 2021-07-17 20:19:49 H=[45.188.61.3] NotQ connection-lost (AS:269585 1.0, N:45.188.61.0/24 1.0, C:BR 302.1) EHLO,AUTH 2021-07-17 20:20:16 H=[188.112.7.125] NotQ connection-lost (AS:42739 6.9, N:188.112.0.0/18 3.4, C:PL 65.7) EHLO,AUTH 2021-07-17 20:20:47 H=[45.168.31.121] NotQ connection-lost (AS:268052 1.9, N:45.168.31.0/24 1.0, C:BR 303.0) EHLO,AUTH I count ASN (AS:), IP network (N:) and country (C:) by exim's ratelimit facility for 1 week, to get some quick look. Most of them come from Brasil, other top includes India, Poland, Argentina and others. The IP is only rarely used more than once, and as one can see, the IP networks and AS numbers doesn't get high counts too (with some exceptions which i blocked manually). 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: - 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? - have someone similar feeling about blocklist.de effectivity or am i wrong? - some days ago i decide to register my IP with dnswl.org, can it be related? (in really i am not sure, if they start closely before i register or after) 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. thanks -- Slavko http://slavino.sk pgpC9pMowkv2z.pgp Description: Digitálny podpis OpenPGP ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
