Re: Question on early detection for relay spam
Rupert Gallagher skrev den 2020-03-05 00:27: Fails with travelling clients. my custommers want vacation without stress :=)
Re: Question on early detection for relay spam
On 04 Mar 2020, at 16:27, Rupert Gallagher wrote: > Fails with travelling clients. Depends. I block several countries from accessing my mail server. If someone travels to one of those countries, they can use webmail to access their mail. There are always options. However, most people simply use a VPN.
Re: Question on early detection for relay spam
Fails with travelling clients. Original Message On Mar 3, 2020, 16:49, Benny Pedersen wrote: > Marc Roos skrev den 2020-03-03 16:15: >> Use ipset, hardly causing any latency using 50k entries. > > i dont need to block 50k entries, but only whitelist few accepted client > ips, where i resolve asn and open this specifik asn to have access, if > there is abuse it will be removed so its again is blocked, i have tryed > blockin 50k entries it failed maserable, for me it does not matter of > ipsets or not was used > > keeping it tieght helps alot > > the log i showed was not from clients that already had access, so no > need to block it > > if you know iptabels you dont need ipsets :=)
Re: Question on early detection for relay spam
On 4 Mar 2020, at 14:43, RW wrote: On Tue, 03 Mar 2020 16:05:31 -0800 Ted Mittelstaedt wrote: 2FA isn't going to help unless 2FA could be applied to the SMTP Auth port. Sometime 2FA on webmail is combined with separate autogenerated passwords for pop/imap/submission. A.k.a. "application passwords" which people may be accustomed to as a feature of both Google's and Apple's 2FA implementations. It is also possible to couple 2FA with OAuth 2.0 (as Google does) although that does put you in the position of forcing users to adopt MUAs that support OAuth 2.0. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Question on early detection for relay spam
On Tue, 03 Mar 2020 16:05:31 -0800 Ted Mittelstaedt wrote: > 2FA isn't going to help unless 2FA could be applied to the SMTP Auth > port. Sometime 2FA on webmail is combined with separate autogenerated passwords for pop/imap/submission.
Re: Question on early detection for relay spam
If password rotating is out of the question, you might want to check your IPs against blacklists multiple times at a day, it wouldn't stop it but it may notify you earlier to stop an outbreak. Other thing that comes to mind is, you may try rate limiting your users and setup a cron to monitor the number of outgoing messages and notify you if there's a sudden surge of mail requests. M. Omer GOLGELI --- AS202365 https://as202365.peeringdb.com https://bgp.he.net/AS202365 NOC: Phone: +90-533-2600533 Email: o...@chronos.com.tr March 3, 2020 10:26 AM, "Ted Mittelstaedt" wrote: > I know this is probably off topic but I'm getting desperate enough to ask. > > I run a commercial mailserver that regularly seems to have spammers relay > mail through it that have > obtained stolen credentials for a user. Many years ago I stopped allowing > users to change passwords > on it and I setup passwords for all users added to it, and the passwords are > random strings of 8 > characters or more. > > The problem is of course that since the passwords are difficult to remember, > once the users do > remember them they merrily proceed to use > this "highly secure password that I can now remember" on every stupid > website out on the Internet that they care to login to. The problem > isn't really the people using Thunderbird or Outlook or their cell phones or > whatever, because they > save the password in the email client and then immediately forget it, which > is what I want. It is > the people who use the webmail interface on multiple different systems, kiosk > computers and the like, who are the problem. When hosts out on the > Internet get busted into, the spammers get their passwords and > email addresses and start relaying. I've confirmed this with several > users I've called and it's always the same story. > > By the time I see what's going on the server is blacklisted everywhere > and I have to waste time delisting it, and asskissing all of the > little tiny blacklists run by little pricks who want me to pay money > or wait a month to be delisted, etc. (no I'm NOT talking about > spamcop, or barracuda or anyone professional - THEY know what they are > doing and don't look at this as a chance for a shakedown) > > I estimate that last year this happened around 5 times and I just > lost an afternoon today answering the passle of help requests from > users because it happened again. > > What I am wondering is how to tighten up my monitoring on my servers to > more rapidly identify when this starts happening. What I'm doing now is > a kludge but I run mailq (this is a sendmail system) and when I see the > number of pending mail mesages in there exceed a threshold I send an alert to > my cell. It is a > kludge and the problem is that > the mailq doesn't start filling up until my server gets blacklisted. > > I've considered several ideas like running a script out of cron that > checks the number of authid's per hour but all of these seem like even > worse kludges. The only idea that I have come up with that I really > like is taking an AK-47 to the spammers but unfortunately spammers > know that they are unloved and cowardly hide away in Russia and scummier > places and I can't reach 'em. (maybe I could offer a bounty? A nickle a head? > That would pay for > the bullet at least. I don't think those people are worth even that, though) > > I do run a daily sendmail statistics report but by the time I read that > and see the bump in traffic it's too late. > > What do other people do for this problem? > > Ted
Re: Question on early detection for relay spam
On 3/3/2020 5:53 AM, Riccardo Alfieri wrote: On 03/03/20 08:54, Benny Pedersen wrote: Ted Mittelstaedt skrev den 2020-03-03 08:26: What do other people do for this problem? Hi Ted, What I can suggest you is to look at our DQS product (https://www.spamhaustech.com/dqs/), that even in it's free subscription model includes AuthBL, a list made of botnet's known to be used to spam with abused credentials. A simple 5xx if a client connect to your submission port using a listed IP would take care of *most* of your problems. Well since I also am fully IPv6 compliant I don't think I have the space for a real dynamic blacklist. A spammer with half a brain can simply forgo IPv4 completely and have almost an infinite number of IP's to attack me from. Of course most spammers are too stupid to setup a rotator on an IPv6 line so maybe we might get a few more years in the IPv4 space but much of this blacklist stuff can be easily defeated once more people run IPv6. After that, just running a daily report with a table like: sasl_username - number of different ips observed in the latest 24h. Yes, this is what I have been thinking is most likely going to be the most useful approach - that is, writing a log analysis script that runs when the mailog is rolled over, and stuffs all authid IP addresses and corresponding userIDs into a mysql database. Then a second report script that queries the database looking for excessive use. Unfortunately while it's the least kludgy approach it's also the most complicated one. :-( Can help you find out abused credentials that were being used by bots (still) not in AuthBL. I've observed in the field that this is an approach that works when you have up to 20-30k users; after this threshold you may want to write something to automate warnings and/or automatically block accounts if they exceed a defined threshold of (different_ips per sasl_username) per hour. Unfortunately that just opens a DoS hole as an attacker who is attacking a particular userID can stuff the log and lock out a legitimate user. Unlike Google who gives out accounts for free I collect money for them and so therefore unlike Google I can't just do whatever the eff I want to them for no reason anytime I feel like. That's WHY Google gives out free accounts. That, and they have enough of them they can gather all that lovely marketing data by scraping people's emails for keywords. Ted
RE: Question on early detection for relay spam
Well for example of the trouble RBLS cause see this one for your own number: -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [212.26.193.44 listed in list.dnswl.org] >and then immediately forget it, which is what I want. It is the people >who use the webmail interface on multiple different systems, kiosk >computers and the like, who are the problem. When hosts out on the >Internet get busted into, the spammers get their passwords and >email addresses and start relaying. I've confirmed this with several >users I've called and it's always the same story. >Strange your webmail should be on https then it is difficult to catch >passwords. As I mentioned already the issue isn't that people using the password on the webmail interface are getting hacked, The issue is people using the email password on -other- servers on the Internet, which then later get hacked. Some users in fact never use the webmail interface yet still get hacked, it is because they choose to use the same password on multiple servers on the Internet. It's more prevalent with the webmail users because those users type the password in repeatedly, which commits it to their memory, and then since it is committed to memory they find it easy to use elsewhere. 2FA isn't going to help unless 2FA could be applied to the SMTP Auth port. In fact, since my incoming and outgoing mailservers are independent servers, I can use different passwords for incoming and outgoing servers, which is one answer. However, that is a decision that would have been great if it was made back in 2004 when I split the mailserver into independent servers. The main coorelation I have is that users who call me asking "what is my email password" because they are setting up new phones, etc. - they are never hacked. It's the users that remember the passwords that get hacked - obviously because they are using them elsewhere. Ted
Re: Question on early detection for relay spam
On 3/3/20 3:40 AM, Marc Roos wrote: No problem I would say, it is good exchange thoughts and idea's Agreed. Strange your webmail should be on https then it is difficult to catch passwords. I do not have this at al, that peoples passwords get stolen. Hardly ever. So maybe somewhere something is wrong in your setup. Maybe spammers get access via a remote exploit? I do not think this is a common problem. I suspect that key loggers, or malicious browser add-ons, more nefarious things (MitM proxies) are partially to blame. Please remember, that you are causing work for these companies. Someone is complaining. And someone is adding your ip to the blacklist. They get harassed why the shit is getting through their spam filters. True. I would also ask amazon to pay me a few thousands for wasting my time constantly. ~chuckle~ Sendmail has a nice filter that rate limits a user. I was always thinking of implementing this, when I run into a situation as yours. I thought that Sendmail had a per authenticated user rate limit. If it doesn't, I expect that a milter could be created to do that with little effort. I wonder if it would be possible to combine this rate limiting with quarantining. That way the messages could be received from the client and held on the server. Client's would likely be none the wiser. You could then look at the count of quarantined messages and take action based on that. You could also have an automated job that would email the authenticated user when their messages were being quarantined; i.e. they sent > X number of messages in the last Y hours. (25–50 & 24 seems like a start. Check your logs for better numbers.) Things you should consider: - investigate what clients mostly have these problems. Give them a sperate outgoing server. This way when it happens again not everyone's email is blocked. Hum. This seems somewhat problematic. How do you propose using different SMTP servers based on authenticating client /without/ reconfiguring clients or playing DNS games? It seems like the front line MSA would need to conditionally route messages to the next SMTP server based on behavior & sending rate. ps. When I get spam I put the whole /24 range on the blacklist. So maybe get ip's in different ranges. - filter your logs of the last year that have outgoing spam. You wil see same ip ranges. Put all of them on your outgoing mailservers dns blacklist so they cannot connect. - google for outgoing milters. You get blacklisted on the bigger rbl's after sending a lot of spam. At the risk of using buzz words, I wonder if anyone has applied A.I. / M.L. to authenticated user / sending address / recipient address tuples. Do you have any idea if the abusers are using different from addresses (envelope and / or header) not associated with the authentication credentials? It might be a low hanging fruit to associate authentication credentials with the from addressees. Do you filter on outbound messages? Make sure that you aren't violating SFP / DMARC / spam / viruses. A user is not sending 100 emails a day. Most users don't. I'm sure that I have done that in the past, though rarely. Good luck, fighting these spammers!!! +1 -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: Question on early detection for relay spam
On 3 Mar 2020, at 2:26, Ted Mittelstaedt wrote: I know this is probably off topic but I'm getting desperate enough to ask. I run a commercial mailserver that regularly seems to have spammers relay mail through it that have obtained stolen credentials for a user. Many years ago I stopped allowing users to change passwords on it and I setup passwords for all users added to it, and the passwords are random strings of 8 characters or more. The problem is of course that since the passwords are difficult to remember, once the users do remember them they merrily proceed to use this "highly secure password that I can now remember" on every stupid website out on the Internet that they care to login to. The problem isn't really the people using Thunderbird or Outlook or their cell phones or whatever, because they save the password in the email client and then immediately forget it, which is what I want. It is the people who use the webmail interface on multiple different systems, kiosk computers and the like, who are the problem. The standard answer for this is to require some form of 2-step/2-factor authentication. If you have users actually entering their usernames and passwords in to random computers they will never see again, the only sound practice is some form of 2FA where the 2nd step is ephemeral: OTP of some variety, one-time codes via SMS, etc. However, there's another useful tactic that doesn't require you to deploy all-new services, although it will require some user training. Decouple authentication identities from email address deliverability. There is no intrinsic reason that a username must be a deliverable email address, even if it looks like one. I originally did this almost accidentally on my oldest surviving mail system, which has now hit 25 years (across multiple platforms, of course) without a single account hijack. It's absurdly simple. My users all have real user accounts on the mail server. They authenticate using usern...@mailhostname.scconsult.com. Their primary email addresses are somthinge...@scconsult.com. somethinge...@mailhostname.scconsult.com is non-existent in any sense, as is usern...@scconsult.com. The authentication name (usern...@mailhostname.scconsult.com) is only deliverable locally: Postfix only accepts mail via SMTP for virtual domains (e.g. scconsult.com, billmail.scconsult.com, grumpybozo.us, etc.) Usable email addresses are not authentication identities and authentication identities are not usable email addresses. Before I started firewalling them as noisy nuisances, I had a constant flow of auth attempts for various names that could never succeed against IMAP, POP, both submission ports, SMTP (where I don't even allow AUTH!) and a private website with an entirely distinct user namespace. HIBP tells me that some miscreants probably have once-valid email+password combos for some of my users at random breached websites, and I've seen auth attempts for those email addresses from credential-stuffer bots, but even if the owners of those addresses used the same passwords for the breached sites as for their email, those attempts cannot succeed because their email accounts do not use their email addresses as usernames. That DOES NOT solve the Evil Kiosk Operator problem, of course. For that, you need the aforementioned 2FA with one-use second factors. [...] What I am wondering is how to tighten up my monitoring on my servers to more rapidly identify when this starts happening. What I'm doing now is a kludge but I run mailq (this is a sendmail system) and when I see the number of pending mail mesages in there exceed a threshold I send an alert to my cell. It is a kludge and the problem is that the mailq doesn't start filling up until my server gets blacklisted. That's particularly bad with low-flow/snowshoe spammers who route one message every 10 minutes through each of 300 compromised accounts spread across 20 different servers, most of them on megaproviders. You won't notice anything until the particular spam content has been fingerprinted in shared systems like DCC, Pyzor, Razor, and Cloudmark. I've considered several ideas like running a script out of cron that checks the number of authid's per hour but all of these seem like even worse kludges. The only idea that I have come up with that I really like is taking an AK-47 to the spammers but unfortunately spammers know that they are unloved and cowardly hide away in Russia and scummier places and I can't reach 'em. (maybe I could offer a bounty? A nickle a head? That would pay for the bullet at least. I don't think those people are worth even that, though) There's a seed of a useful idea in that paragraph... Why do you allow access to IMAP, POP, or either mail submission port (465 or 587) from random Russian IPs? Do you allow AUTH at all on port 25 and if so, why? What I've done is that I have a log watcher (akin to fail2ban, but
Re: Question on early detection for relay spam
Marc Roos skrev den 2020-03-03 16:15: Use ipset, hardly causing any latency using 50k entries. i dont need to block 50k entries, but only whitelist few accepted client ips, where i resolve asn and open this specifik asn to have access, if there is abuse it will be removed so its again is blocked, i have tryed blockin 50k entries it failed maserable, for me it does not matter of ipsets or not was used keeping it tieght helps alot the log i showed was not from clients that already had access, so no need to block it if you know iptabels you dont need ipsets :=)
RE: Question on early detection for relay spam
Use ipset, hardly causing any latency using 50k entries. -Original Message- From: Benny Pedersen [mailto:m...@junc.eu] Sent: 03 March 2020 15:39 To: users@spamassassin.apache.org Subject: Re: Question on early detection for relay spam Riccardo Alfieri skrev den 2020-03-03 14:53: # abuse port 21 begin 51.178.0.0/16 as16276 #OVH, FR 80.82.77.0/24 as202425 #INT-NETWORK, SC 104.206.128.0/22 as62904 #EONIX-COMMUNICATIONS-ASBLOCK-62904, US # abuse port 21 end # all ips begin 51.178.78.154 80.82.77.240 104.206.128.54 # all ips end # abuse port 465 begin 51.178.0.0/16 as16276 #OVH, FR 111.118.212.0/22 as394695 #PUBLIC-DOMAIN-REGISTRY, US 164.132.0.0/16 as16276 #OVH, FR 180.96.0.0/11 as4134 #CHINANET-BACKBONE No.31,Jin-rong Street, CN 192.241.224.0/20 as14061 #DIGITALOCEAN-ASN, US # abuse port 465 end # all ips begin 51.178.78.152 111.118.215.98 164.132.183.196 180.114.159.48 192.241.226.237 # all ips end # abuse port 587 begin 45.133.99.0/24 as202984 #TEAM-HOST AS, RU 51.91.0.0/16 as16276 #OVH, FR 78.128.113.0/24 as209160 #MITI2000, BG 82.102.160.0/19 as12400 #PARTNER-AS, IL 192.241.192.0/19 as14061 #DIGITALOCEAN-ASN, US # abuse port 587 end # all ips begin 45.133.99.2 51.91.212.80 78.128.113.92 82.102.173.78 192.241.213.144 # all ips end # abuse port 993 begin 45.136.109.0/24 as49505 #SELECTEL, RU 109.252.0.0/16 as25513 #ASN-MGTS-USPD, RU 109.86.81.0/24 as13188 #TRIOLAN, UA 185.30.176.0/22 as60476 #MYCOM-AS, NL # abuse port 993 end # all ips begin 45.136.109.251 109.252.91.113 109.86.81.177 185.30.177.80 # all ips end i have no custommers there, but its need to try anyway logs is from yesterday only
Re: Question on early detection for relay spam
Riccardo Alfieri skrev den 2020-03-03 14:53: # abuse port 21 begin 51.178.0.0/16 as16276 #OVH, FR 80.82.77.0/24 as202425 #INT-NETWORK, SC 104.206.128.0/22 as62904 #EONIX-COMMUNICATIONS-ASBLOCK-62904, US # abuse port 21 end # all ips begin 51.178.78.154 80.82.77.240 104.206.128.54 # all ips end # abuse port 465 begin 51.178.0.0/16 as16276 #OVH, FR 111.118.212.0/22 as394695 #PUBLIC-DOMAIN-REGISTRY, US 164.132.0.0/16 as16276 #OVH, FR 180.96.0.0/11 as4134 #CHINANET-BACKBONE No.31,Jin-rong Street, CN 192.241.224.0/20 as14061 #DIGITALOCEAN-ASN, US # abuse port 465 end # all ips begin 51.178.78.152 111.118.215.98 164.132.183.196 180.114.159.48 192.241.226.237 # all ips end # abuse port 587 begin 45.133.99.0/24 as202984 #TEAM-HOST AS, RU 51.91.0.0/16 as16276 #OVH, FR 78.128.113.0/24 as209160 #MITI2000, BG 82.102.160.0/19 as12400 #PARTNER-AS, IL 192.241.192.0/19 as14061 #DIGITALOCEAN-ASN, US # abuse port 587 end # all ips begin 45.133.99.2 51.91.212.80 78.128.113.92 82.102.173.78 192.241.213.144 # all ips end # abuse port 993 begin 45.136.109.0/24 as49505 #SELECTEL, RU 109.252.0.0/16 as25513 #ASN-MGTS-USPD, RU 109.86.81.0/24 as13188 #TRIOLAN, UA 185.30.176.0/22 as60476 #MYCOM-AS, NL # abuse port 993 end # all ips begin 45.136.109.251 109.252.91.113 109.86.81.177 185.30.177.80 # all ips end i have no custommers there, but its need to try anyway logs is from yesterday only
Re: Question on early detection for relay spam
Riccardo Alfieri skrev den 2020-03-03 14:53: sasl_username - number of different ips observed in the latest 24h. i have limited so that i only allow sasl auth from trusted custommers ips, all else is firewalled witd default policy of drop, and clients ips is so just still logged if ports is something could be untrusted ips range i still need to open as trusted range, this have limited my own problem with strong passwords that got leaked
Re: Question on early detection for relay spam
On 03/03/20 08:54, Benny Pedersen wrote: Ted Mittelstaedt skrev den 2020-03-03 08:26: What do other people do for this problem? Hi Ted, What I can suggest you is to look at our DQS product (https://www.spamhaustech.com/dqs/), that even in it's free subscription model includes AuthBL, a list made of botnet's known to be used to spam with abused credentials. A simple 5xx if a client connect to your submission port using a listed IP would take care of *most* of your problems. After that, just running a daily report with a table like: sasl_username - number of different ips observed in the latest 24h. Can help you find out abused credentials that were being used by bots (still) not in AuthBL. I've observed in the field that this is an approach that works when you have up to 20-30k users; after this threshold you may want to write something to automate warnings and/or automatically block accounts if they exceed a defined threshold of (different_ips per sasl_username) per hour. -- Best regards, Riccardo Alfieri Spamhaus Technology https://www.spamhaustech.com/
RE: Question on early detection for relay spam
>I know this is probably off topic but I'm getting desperate enough to ask. No problem I would say, it is good exchange thoughts and idea's >I run a commercial mailserver that regularly seems to have spammers >relay mail through it that have obtained stolen credentials for a user. > Many years ago I stopped allowing users to change passwords on it and >I setup passwords for all users added to it, and the passwords are >random strings of 8 characters or more. > >The problem is of course that since the passwords are difficult to >remember, once the users do remember them they merrily proceed to use >this "highly secure password that I can now remember" on every stupid >website out on the Internet that they care to login to. The problem >isn't really the people using Thunderbird or Outlook or their cell >phones or whatever, because they save the password in the email client >and then immediately forget it, which is what I want. It is the people >who use the webmail interface on multiple different systems, kiosk >computers and the like, who are the problem. When hosts out on the >Internet get busted into, the spammers get their passwords and >email addresses and start relaying. I've confirmed this with several >users I've called and it's always the same story. Strange your webmail should be on https then it is difficult to catch passwords. I do not have this at al, that peoples passwords get stolen. Hardly ever. So maybe somewhere something is wrong in your setup. Maybe spammers get access via a remote exploit? I do not think this is a common problem. >By the time I see what's going on the server is blacklisted everywhere >and I have to waste time delisting it, and asskissing all of the >little tiny blacklists run by little pricks who want me to pay money >or wait a month to be delisted, etc. (no I'm NOT talking about >spamcop, or barracuda or anyone professional - THEY know what they are >doing and don't look at this as a chance for a shakedown) Please remember, that you are causing work for these companies. Someone is complaining. And someone is adding your ip to the blacklist. They get harassed why the shit is getting through their spam filters. I would also ask amazon to pay me a few thousands for wasting my time constantly. >I estimate that last year this happened around 5 times and I just >lost an afternoon today answering the passle of help requests from >users because it happened again. > >What I am wondering is how to tighten up my monitoring on my servers to >more rapidly identify when this starts happening. What I'm doing now is >a kludge but I run mailq (this is a sendmail system) and when I see the >number of pending mail mesages in there exceed a threshold I send an >alert to my cell. It is a kludge and the problem is that >the mailq doesn't start filling up until my server gets blacklisted. Sendmail has a nice filter that rate limits a user. I was always thinking of implementing this, when I run into a situation as yours. >I've considered several ideas like running a script out of cron that >checks the number of authid's per hour but all of these seem like even >worse kludges. The only idea that I have come up with that I really >like is taking an AK-47 to the spammers but unfortunately spammers >know that they are unloved and cowardly hide away in Russia and scummier >places and I can't reach 'em. (maybe I could offer a bounty? A nickle >a head? That would pay for the bullet at least. I don't think those >people are worth even that, though) > >I do run a daily sendmail statistics report but by the time I read that >and see the bump in traffic it's too late. > >What do other people do for this problem? > Things you should consider: - investigate what clients mostly have these problems. Give them a sperate outgoing server. This way when it happens again not everyone's email is blocked. ps. When I get spam I put the whole /24 range on the blacklist. So maybe get ip's in different ranges. - filter your logs of the last year that have outgoing spam. You wil see same ip ranges. Put all of them on your outgoing mailservers dns blacklist so they cannot connect. - google for outgoing milters. You get blacklisted on the bigger rbl's after sending a lot of spam. A user is not sending 100 emails a day. Good luck, fighting these spammers!!!
Re: Question on early detection for relay spam
Ted Mittelstaedt skrev den 2020-03-03 08:26: What do other people do for this problem? https://www.abusix.com/abusix-mail-intelligence what more do you want to do ? my own servers reject all clients not in danish ip space unless its sasl authed strong leaked passwords does not help much hope to see 2fa auth login to dovecot not only dovecot pro ox as it is now we all have already loosed
