Re: [mailop] Slow botnet IMAP scans?
On 6 Oct 2017, at 14:19, Brandon Long wrote: Are you sure they're trying a slow dictionary attack? It varies. I've seen both dictionary attacks of varying speeds (from many per second to a few per minute) using a dictionary of common names and role accounts AND relatively slow runs *from multiple ips* of the same set of email addresses with and without domains in the same order every time, no quicker than 2/minute. These are probably mostly password reuse attacks, since the addresses are strictly email address identities, NOT authentication identities (e.g. see my address...) On the other hand, some of the addresses are ones that have been only used for mailing lists and don't seem to have been compromised, so it isn't clear what the attackers think they are doing with those. That seems unlikely to be useful, It's not exactly news that spammers are not terribly bright in general and frequently use extremely low-yield (even entirely futile) modes of attack. For example: • Cutwail has been using the same idiosyncratically bogus HELO behavior for many years. • I get authentication attempts on port 25 listeners which never advertise (and do not have) SMTP AUTH support. • I get attack runs making plaintext authentication attempts on unencrypted POP3 and IMAP sessions despite the fact that they both explicitly disallow that. perhaps instead they are using known passwords looking for reuse, that's been our experience. Yes, there's surely some of that. Anyways, passwords are so broken now, we have to have an entire permission flow to see whether an access is likely from the actual user and not a hijacking attempt, and we pushed most users to oauth instead. I realize oauth doesn't scale as is, they need to get the discovery and auto registration stuff done, haven't looked at the status of that in a couple years. As far as email goes, I don't think passwords are really so broken as long as you split mail routing identities from authentication identities. For example, I have used an unknown number of email addresses in the scconsult.com and billmail.scconsult.com domains, many of which remain usable in the sense that mail sent to them will very likely reach my eyes. No system I run recognizes any of those addresses (with or without the domain part) as an authentication identity, not even the IMAP server hosting the single account to which they all get delivered. There has never been any attempt to crack that account, because the username isn't a mailable address. I have implemented similar models on much larger scales with the only problem being a tiny minority (<1%) of users who require being told twice that their username and their email address are 2 different things which don't closely resemble each other. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Slow botnet IMAP scans?
Hi Brandon, Just a quick note to be clear, the CID RFC Draft doesn't specify especially the 'client identifier', and the MAC address is just an example. In the real world of course, much better client identifiers are available, and the CID proposal recognizes that and assumes that the 'device' implementations, would use the most accurate identifier available. For instance, WebMail might use 'HTML Canvas' and 'Cookies', or an under lying machine/device identifier accessible to a browser type. It doesn't really matter which one is chosen, other than it should offer some elements of uniqueness. What is significant, is that the CID proposal also addresses how to only present that over encrypted channels, while still leaving support for legacy methods. But it is up the server implementation on what controls and restrictions they wish to place or allow, whether server wide, domain wide, or even per user controls. As you pointed out, some of the 'big boys' have invested considerable amounts into creating 'auth' rules and mechanisms, however this is a simple and easy way for all operators to gain extra levels of control. For instance the WebMail only user can 'lock' down any attempts to use the credentials, to only those who have the correct CID, whether that be HTML Canvas, or Cookie.. and even better, alert the user to someone who used their email address and password, from an environment where that information wasn't presented. And given the bad habit of people using the same credentials (email and password) for multiple services, the ability of bad bot operators to perform dictionary and brute force attempts, (as per the original reporter) we see this as an important ability. As well, it offers the additional ability to report such attacks as described, so that the server can detect and prevent such future attacks, without solely locking out the originating IP Address. PS, as much as this method can also be used to measure cases where a 'device' identifier magically transports itself to different GEO locations, my phone today alone reported that I was in Montreal, Vancouver, Edmonton, Las Vegas, and New York. IPv6, portable dynamic networks, and many other 'flex routing' issues effectively make that difficult, aside from some large scale (eg China vs US geo locations), but this goes beyond that, I want to know if someone in the same coffee shop is trying to use my credentials. But it will take work making this a standard of course, but in the interim, value can be seen even in the mosts limited server deployments. As long as email operators wish to continue supporting IMAP/POP/SMTP we need to improve those protocols to some level, where we can 'who' or at least 'what' is trying to use a person's security tokens, in this case the email address and password. And hopefully, those who use this can detect those 'slow botnet IMAP scans' on their first attempt, no matter what distributed methods are used to attempt such attacks. On 17-10-06 03:18 PM, Brandon Long wrote: We didn't release any, since we changed focus. The simple answer is, instead of PLAIN which has a sasl format of (taking the abnf from RFC 4616): message = [authzid] UTF8NUL authcid UTF8NUL passwd it includes a client-token: message = [authzid] UTF8NUL authcid UTF8NUL passwd UTF8NUL client-token I also wouldn't recommend using the MAC address as in Michael's proposal, as that as privacy implications. It should either use a device specific API to request a unique id and store it in the client, or just have the client create one and keep it. The point is, that always a user to wipe a device and give it to someone else, or even just wipe and replace, without being able to track the user in other ways. The benefits are the same, if you've never seen a client-token before, you need to be more careful with it, but if you have seen it before, then it's less likely that the login attempt is a hijacking or dictionary attack. It can also aid in using say geohop stats. Ie, one easy way to try to detect hijacking is to geoloc the accessing IP, and see how close it was to the last access, or keep track of where the user is accessing from. This has obvious issues if your users travel. If a user with a phone that supports it goes somewhere else, chances are they'll access from the phone first, even if their desktop client doesn't support client-token, so you have a strong signal that they traveled somewhere else. All of this requires per-user login permission systems, nothing as simple as say banning AWS or China, its' knowing whether a given user ever uses your service from those locations. A first access from that location may be blocked, requiring the user to go to a web page and verify the access attempt (web access gives you a lot more signals, so doing login permission detection there is often easier). Anyways, the massive service providers have been havi
Re: [mailop] Slow botnet IMAP scans?
On 07/10/17 00:30, Philip Paeps wrote: > I don't consider a long random password the user can't change > particularly insecure. It's not too bad really, if the password is per application and saved. Lots of corporates have single sign on. Same password everywhere in business. In theory, this should mean people people login once, and kerberos, OAUTH, ... does it's trick and people are logged in. In practice, people add their company IMAP account to their phone, and click `save password`. They login (on their desktop) to a corporate web application that uses an LDAP backend rather than tokens to login. They save their password. So their `keys to everything` corporate password gets saved and entered all over the place. This is poor Google have obviously done a good job of risk managing new logins. Tim ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Slow botnet IMAP scans?
On Sat, 07 Oct 2017 01:30:27 +0200, Philip Paeps said: > On 2017-10-06 15:18:45 (-0700), Brandon Long via mailop wrote: > >It can also aid in using say geohop stats. Ie, one easy way to try to > >detect hijacking is to geoloc the accessing IP, and see how close it > >was to the last access, or keep track of where the user is accessing > >from. This has obvious issues if your users travel. If a user with a > >phone that supports it goes somewhere else, chances are they'll access > >from the phone first, even if their desktop client doesn't support > >client-token, so you have a strong signal that they traveled somewhere > >else. > > This paragraph sounds incredibly creepy... I'm glad I'm not one of your > users! I read it as "even if they travel, we have a way to identify it's them and not an impostor". Can be really handy sometimes. I notified my bank that I was going to the Philippines once - and had my card declined in the Beijing airport because it wasn't the Philippines. Now that they have given out new cards that have chips on them, my bank can be more sure that it's really my card in the Beijing airport next time pgpwLPdZ_FFiQ.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Slow botnet IMAP scans?
Hey, that's awesome, thanks for the PLAIN-CLIENTTOKEN description! I was finally able to add basic support to my own mail server (can be tested at https://ethereal.email): $ openssl s_client -crlf -connect imap.ethereal.email:993 * OK Ethereal Email IMAP Server ready A CAPABILITY * CAPABILITY IMAP4rev1 AUTH=PLAIN AUTH=PLAIN-CLIENTTOKEN ENABLE ID SASL-IR A OK CAPABILITY completed A AUTHENTICATE PLAIN-CLIENTTOKEN "AHo0YzJkbWcycWU2ZGdid2hAZXRoZXJlYWwuZW1haWwAQXJqZVVBNWsyd1lqWWo0eWJKAHRlc3Q=" A OK z4c2dmg2qe6dgbwh@ethereal.email authenticated I didn't manage to get any real mail clients to pick this authentication scheme though, all the clients I tested went with the regular "AUTHENTICATE PLAIN". Regards, Andris 2017-10-07 1:18 GMT+03:00 Brandon Long : > We didn't release any, since we changed focus. The simple answer is, > instead of PLAIN which has a sasl format of (taking the abnf from RFC 4616): > message = [authzid] UTF8NUL authcid UTF8NUL passwd > it includes a client-token: > message = [authzid] UTF8NUL authcid UTF8NUL passwd UTF8NUL client-token > > I also wouldn't recommend using the MAC address as in Michael's proposal, > as that as privacy implications. It should either use a device specific > API to request a unique id and store it in the client, or just have the > client create one and keep it. The point is, that always a user to wipe a > device and give it to someone else, or even just wipe and replace, without > being able to track the user in other ways. > > The benefits are the same, if you've never seen a client-token before, you > need to be more careful with it, but if you have seen it before, then it's > less likely that the login attempt is a hijacking or dictionary attack. > > It can also aid in using say geohop stats. Ie, one easy way to try to > detect hijacking is to geoloc the accessing IP, and see how close it was to > the last access, or keep track of where the user is accessing from. This > has obvious issues if your users travel. If a user with a phone that > supports it goes somewhere else, chances are they'll access from the phone > first, even if their desktop client doesn't support client-token, so you > have a strong signal that they traveled somewhere else. > > All of this requires per-user login permission systems, nothing as simple > as say banning AWS or China, its' knowing whether a given user ever uses > your service from those locations. A first access from that location may > be blocked, requiring the user to go to a web page and verify the access > attempt (web access gives you a lot more signals, so doing login permission > detection there is often easier). > > Anyways, the massive service providers have been having to do this stuff > for almost a decade, it's always been a matter of time til it filters down > to the larger or medium size providers. > > Anyways, that's the reason we moved to requiring OAUTH by default, and > requiring users to jump through hoops to enable "less secure apps" (ie, > password based auth). > > Brandon > > On Fri, Oct 6, 2017 at 11:57 AM, wrote: > >> Is there any documentation available about PLAIN-CLIENTTOKEN? All I can >> find are SMTP transcripts about connecting to Gmail. >> >> Best regards, >> Andris Reinman >> >> On 6 Oct 2017, at 21:24, Brandon Long via mailop >> wrote: >> >> I still prefer our sasl extension, PLAIN-CLIENTTOKEN instead, since you >> can then use it for imap/pop/smtp simply. >> >> Or focus on oauth... >> >> On Oct 6, 2017 7:57 AM, "Michael Peddemors" >> wrote: >> >> SMTP Auth Scanners are easier to stop, which is why there are more IMAP >> scanners being seen in the wild. >> >> But that is why we are pushing forward on our CID implementations.. >> >> https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/ >> >> Can't really block AUTH attempts strictly by 'firewall' or IP rules, as a >> bot could be operating out of shared or dynamic space, which would mean >> that you effectively block legitimate users from accessing email. >> >> We actually have a RATS-AUTH list designed to report on IP(s) used for >> AUTH attacks, the broken bots are easier to pick up. >> >> But this isn't a 'Chinese' thing only, we see lot's of these attacks >> coming from everywhere, including Amazon AWS etc.. >> >> >> On 17-10-06 05:30 AM, Tim Bray wrote: >> >>> On 06/10/17 10:51, Otto J. Makela wrote: >>> Are you keeping an eye out for (mostly Chinese) botnets doing slow IMAP scans, using scraped email addresses and apparently going through whole dictionaries? >>> >>> I haven't seen them. But we are getting a lot more SMTP auth scanners >>> than we used to. >>> >>> We just drop them in the firewall for a bit.We've dropped about 300 >>> IPv4 addresses in the last 6 hours. >>> >>> >>> Tim >>> >>> ___ >>> mailop mailing list >>> mailop@mailop.org >>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >>> >>> >> >> >> -- >> "Catch the Magi
Re: [mailop] Slow botnet IMAP scans?
On 2017-10-06 15:18:45 (-0700), Brandon Long via mailop wrote: It can also aid in using say geohop stats. Ie, one easy way to try to detect hijacking is to geoloc the accessing IP, and see how close it was to the last access, or keep track of where the user is accessing from. This has obvious issues if your users travel. If a user with a phone that supports it goes somewhere else, chances are they'll access from the phone first, even if their desktop client doesn't support client-token, so you have a strong signal that they traveled somewhere else. This paragraph sounds incredibly creepy... I'm glad I'm not one of your users! I hope you're not stalking users like this by default, or at least allowing them to opt out? What's the fallback authentication in case the user decides they don't like being stalked and use something like Tor? IMAP doesn't have convenient CAPTCHA support... Anyways, that's the reason we moved to requiring OAUTH by default, and requiring users to jump through hoops to enable "less secure apps" (ie, password based auth). I don't consider a long random password the user can't change particularly insecure. Most of the problems with passwords are because humans can't (or won't) pick secure (i.e.: long and unmemorable) ones and then go on to use the same bad passwords everywhere. Pesky humans! Nothing wrong with "app passwords" though: difficult to reuse, difficult to brute-force, and easy to revoke. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Slow botnet IMAP scans?
On 2017-10-06 12:51:41 (+0300), Otto J. Makela wrote: Are you keeping an eye out for (mostly Chinese) botnets doing slow IMAP scans, using scraped email addresses and apparently going through whole dictionaries? I have most Chinese address space that I know about firewalled. I have no users in China and any of my users travelling to China are smart enough to tunnel their way out. Having said that: slow IMAP scans are a global phenomenon. For different values of slow. One particular network (in Poland) managed about 600K login attempts before I got bored of them in my logs and firewalled them. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Slow botnet IMAP scans?
We didn't release any, since we changed focus. The simple answer is, instead of PLAIN which has a sasl format of (taking the abnf from RFC 4616): message = [authzid] UTF8NUL authcid UTF8NUL passwd it includes a client-token: message = [authzid] UTF8NUL authcid UTF8NUL passwd UTF8NUL client-token I also wouldn't recommend using the MAC address as in Michael's proposal, as that as privacy implications. It should either use a device specific API to request a unique id and store it in the client, or just have the client create one and keep it. The point is, that always a user to wipe a device and give it to someone else, or even just wipe and replace, without being able to track the user in other ways. The benefits are the same, if you've never seen a client-token before, you need to be more careful with it, but if you have seen it before, then it's less likely that the login attempt is a hijacking or dictionary attack. It can also aid in using say geohop stats. Ie, one easy way to try to detect hijacking is to geoloc the accessing IP, and see how close it was to the last access, or keep track of where the user is accessing from. This has obvious issues if your users travel. If a user with a phone that supports it goes somewhere else, chances are they'll access from the phone first, even if their desktop client doesn't support client-token, so you have a strong signal that they traveled somewhere else. All of this requires per-user login permission systems, nothing as simple as say banning AWS or China, its' knowing whether a given user ever uses your service from those locations. A first access from that location may be blocked, requiring the user to go to a web page and verify the access attempt (web access gives you a lot more signals, so doing login permission detection there is often easier). Anyways, the massive service providers have been having to do this stuff for almost a decade, it's always been a matter of time til it filters down to the larger or medium size providers. Anyways, that's the reason we moved to requiring OAUTH by default, and requiring users to jump through hoops to enable "less secure apps" (ie, password based auth). Brandon On Fri, Oct 6, 2017 at 11:57 AM, wrote: > Is there any documentation available about PLAIN-CLIENTTOKEN? All I can > find are SMTP transcripts about connecting to Gmail. > > Best regards, > Andris Reinman > > On 6 Oct 2017, at 21:24, Brandon Long via mailop > wrote: > > I still prefer our sasl extension, PLAIN-CLIENTTOKEN instead, since you > can then use it for imap/pop/smtp simply. > > Or focus on oauth... > > On Oct 6, 2017 7:57 AM, "Michael Peddemors" > wrote: > > SMTP Auth Scanners are easier to stop, which is why there are more IMAP > scanners being seen in the wild. > > But that is why we are pushing forward on our CID implementations.. > > https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/ > > Can't really block AUTH attempts strictly by 'firewall' or IP rules, as a > bot could be operating out of shared or dynamic space, which would mean > that you effectively block legitimate users from accessing email. > > We actually have a RATS-AUTH list designed to report on IP(s) used for > AUTH attacks, the broken bots are easier to pick up. > > But this isn't a 'Chinese' thing only, we see lot's of these attacks > coming from everywhere, including Amazon AWS etc.. > > > On 17-10-06 05:30 AM, Tim Bray wrote: > >> On 06/10/17 10:51, Otto J. Makela wrote: >> >>> Are you keeping an eye out for (mostly Chinese) botnets doing slow IMAP >>> scans, >>> using scraped email addresses and apparently going through whole >>> dictionaries? >>> >> >> I haven't seen them. But we are getting a lot more SMTP auth scanners >> than we used to. >> >> We just drop them in the firewall for a bit.We've dropped about 300 >> IPv4 addresses in the last 6 hours. >> >> >> Tim >> >> ___ >> mailop mailing list >> mailop@mailop.org >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> >> > > > -- > "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 the use of the individual or entity to which they are addressed. > Please note that any views or opinions presented in this email are solely > those of the author and are not intended to represent those of the company. > > > ___ > mailop mailing
Re: [mailop] Slow botnet IMAP scans?
Is there any documentation available about PLAIN-CLIENTTOKEN? All I can find are SMTP transcripts about connecting to Gmail. Best regards, Andris Reinman > On 6 Oct 2017, at 21:24, Brandon Long via mailop wrote: > > I still prefer our sasl extension, PLAIN-CLIENTTOKEN instead, since you can > then use it for imap/pop/smtp simply. > > Or focus on oauth... > > On Oct 6, 2017 7:57 AM, "Michael Peddemors" wrote: > SMTP Auth Scanners are easier to stop, which is why there are more IMAP > scanners being seen in the wild. > > But that is why we are pushing forward on our CID implementations.. > > https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/ > > Can't really block AUTH attempts strictly by 'firewall' or IP rules, as a bot > could be operating out of shared or dynamic space, which would mean that you > effectively block legitimate users from accessing email. > > We actually have a RATS-AUTH list designed to report on IP(s) used for AUTH > attacks, the broken bots are easier to pick up. > > But this isn't a 'Chinese' thing only, we see lot's of these attacks coming > from everywhere, including Amazon AWS etc.. > > >> On 17-10-06 05:30 AM, Tim Bray wrote: >>> On 06/10/17 10:51, Otto J. Makela wrote: >>> Are you keeping an eye out for (mostly Chinese) botnets doing slow IMAP >>> scans, >>> using scraped email addresses and apparently going through whole >>> dictionaries? >> >> I haven't seen them. But we are getting a lot more SMTP auth scanners >> than we used to. >> >> We just drop them in the firewall for a bit.We've dropped about 300 >> IPv4 addresses in the last 6 hours. >> >> >> Tim >> >> ___ >> mailop mailing list >> mailop@mailop.org >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> > > > > -- > "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 the use of the individual or entity to which they are addressed. > Please note that any views or opinions presented in this email are solely > those of the author and are not intended to represent those of the company. > > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Slow botnet IMAP scans?
I still prefer our sasl extension, PLAIN-CLIENTTOKEN instead, since you can then use it for imap/pop/smtp simply. Or focus on oauth... On Oct 6, 2017 7:57 AM, "Michael Peddemors" wrote: SMTP Auth Scanners are easier to stop, which is why there are more IMAP scanners being seen in the wild. But that is why we are pushing forward on our CID implementations.. https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/ Can't really block AUTH attempts strictly by 'firewall' or IP rules, as a bot could be operating out of shared or dynamic space, which would mean that you effectively block legitimate users from accessing email. We actually have a RATS-AUTH list designed to report on IP(s) used for AUTH attacks, the broken bots are easier to pick up. But this isn't a 'Chinese' thing only, we see lot's of these attacks coming from everywhere, including Amazon AWS etc.. On 17-10-06 05:30 AM, Tim Bray wrote: > On 06/10/17 10:51, Otto J. Makela wrote: > >> Are you keeping an eye out for (mostly Chinese) botnets doing slow IMAP >> scans, >> using scraped email addresses and apparently going through whole >> dictionaries? >> > > I haven't seen them. But we are getting a lot more SMTP auth scanners > than we used to. > > We just drop them in the firewall for a bit.We've dropped about 300 > IPv4 addresses in the last 6 hours. > > > Tim > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > -- "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 the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Slow botnet IMAP scans?
Are you sure they're trying a slow dictionary attack? That seems unlikely to be useful, perhaps instead they are using known passwords looking for reuse, that's been our experience. Anyways, passwords are so broken now, we have to have an entire permission flow to see whether an access is likely from the actual user and not a hijacking attempt, and we pushed most users to oauth instead. I realize oauth doesn't scale as is, they need to get the discovery and auto registration stuff done, haven't looked at the status of that in a couple years. Brandon On Oct 6, 2017 9:35 AM, "Bill Cole" wrote: On 6 Oct 2017, at 5:51, Otto J. Makela wrote: Are you keeping an eye out for (mostly Chinese) botnets doing slow IMAP > scans, > using scraped email addresses and apparently going through whole > dictionaries? > Not so much any more. It's extremely low-cost for many non-Chinese IMAP & POP servers to put very large chunks of Chinese network space into the firewall to drop all TCP traffic to ports 110, 143, 993, and 995. Submission servers can do the same for 587 (and if they support it, 465.) The same goes for many countries which have Internet controls and laws akin to the PRC. As I understand it, a legitimate user connecting to a non-PRC IMAP server from an IP belonging to a PRC entity is either submitting to a man-in-the-middle attack or is violating Chinese law. Doing the same for various big hosting providers is slightly riskier, but not by much. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Slow botnet IMAP scans?
On 6 Oct 2017, at 5:51, Otto J. Makela wrote: Are you keeping an eye out for (mostly Chinese) botnets doing slow IMAP scans, using scraped email addresses and apparently going through whole dictionaries? Not so much any more. It's extremely low-cost for many non-Chinese IMAP & POP servers to put very large chunks of Chinese network space into the firewall to drop all TCP traffic to ports 110, 143, 993, and 995. Submission servers can do the same for 587 (and if they support it, 465.) The same goes for many countries which have Internet controls and laws akin to the PRC. As I understand it, a legitimate user connecting to a non-PRC IMAP server from an IP belonging to a PRC entity is either submitting to a man-in-the-middle attack or is violating Chinese law. Doing the same for various big hosting providers is slightly riskier, but not by much. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Slow botnet IMAP scans?
SMTP Auth Scanners are easier to stop, which is why there are more IMAP scanners being seen in the wild. But that is why we are pushing forward on our CID implementations.. https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/ Can't really block AUTH attempts strictly by 'firewall' or IP rules, as a bot could be operating out of shared or dynamic space, which would mean that you effectively block legitimate users from accessing email. We actually have a RATS-AUTH list designed to report on IP(s) used for AUTH attacks, the broken bots are easier to pick up. But this isn't a 'Chinese' thing only, we see lot's of these attacks coming from everywhere, including Amazon AWS etc.. On 17-10-06 05:30 AM, Tim Bray wrote: On 06/10/17 10:51, Otto J. Makela wrote: Are you keeping an eye out for (mostly Chinese) botnets doing slow IMAP scans, using scraped email addresses and apparently going through whole dictionaries? I haven't seen them. But we are getting a lot more SMTP auth scanners than we used to. We just drop them in the firewall for a bit. We've dropped about 300 IPv4 addresses in the last 6 hours. Tim ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- "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 the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Slow botnet IMAP scans?
On 06/10/17 10:51, Otto J. Makela wrote: > Are you keeping an eye out for (mostly Chinese) botnets doing slow IMAP scans, > using scraped email addresses and apparently going through whole dictionaries? I haven't seen them. But we are getting a lot more SMTP auth scanners than we used to. We just drop them in the firewall for a bit. We've dropped about 300 IPv4 addresses in the last 6 hours. Tim ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Slow botnet IMAP scans?
Are you keeping an eye out for (mostly Chinese) botnets doing slow IMAP scans, using scraped email addresses and apparently going through whole dictionaries? -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 0100 01001011 * * * * * * */ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
