Re: Size in log file.
tejas sarade: > Hello, > > My understanding is that 'size' field in the Postfix logs shows the size of > mail including headers and body. > Can someone tell me if it is correct. The message content length including Postfix record boundaries (typically two bytes per record). The message content length outside Postfix depends on whether line boundaries are CRLF (two bytes) as in SMTP, or newline (one byte) as with UNIX textfiles. Wietse
Re: Compromised Passwords
Am 04.03.2014 23:38, schrieb Homer Wilson Smith: Change their password? from my experience the only thing that really stops the spam Maybe it's anoying for the account owner but it works most reliable. Counting IPs might help also but what if the spammer uses the same src ip for its garbage? Your server would be on blacklists and all clients are affected. So imho it's really better to change passwords, that case only one user is affected. Have a published abuse contact and react on complains promptly also helps. To make it harder for the spammers to get login credentials we use fail2ban which monitors maillogs for failed logins and blocks IPs after X numbers of failed logins. The ban time we keep just some minutes, but thats enough for most of the bruteforcers to go to another server
Re: Compromised Passwords
Homer Wilson Smith wrote the following on 3/4/2014 4:38 PM: Dear Gentle Folk, What is the state of the art in dealing with users whose SASL password has been compromised? Running CentOS, and latest postfix. When a password gets compromised, spam starts to pour out of the server from endless numbers of IP's, to endless numbers of addresses. Rate limiting is interesting but doesn't really stop the spam. Counting client=[IP] addresses until a threshold is reached is highly effective, but then what? Change their password? Thanks in advance. Homer Just to confirm what others have said. Yes. Monitor activity for abusive/suspicious behavior and take action to stop it as soon as it's discovered. If you can automate it, even better. While one could use a policy server, we chose to use an out of band monitoring solution that used the postfix logs. We track emails sent and then geolocate by IP of the client. If a single customer is simultaneously (or very quickly) spending time in several countries or continents then we know there's a problem. This has had a very low false positive hit rate and does a good job of catching most of the abuse we see coming from our customer accounts. We use other thresholds based on volume to catch spam sent from one or two IP addresses. Like another poster, we also use fail2ban, anvil, and have minimum password requirements to help create a layered solution to slow or prevent abuse in an automatic fashion. We typically change the password on accounts flagged for abuse and then contact the customer to inform them of the problem and recommend they take action to secure their systems and change their passwords on any other accounts that may have shared similar credentials. --Blake
Re: backscatter
Thank you Wietse, You spurred me to look at the logs and take a closer look. The problem was an old whitelist entry from when we were in the ISP business. Removing the entry solved my problem. Mike On Tuesday, March 04, 2014 12:34:50 Wietse Venema wrote: > Mike McGinn: > > I ma getting some backscatter problems lately. > > If you are receiving backscatter mail, then filtering on client > properties won't do much good, because in this case the clients are > real mail servers not spambots. > > Instead, reject mail for non-existent recipients if possible, and > try to do some content filtering as outlined in > http://www.postfix.org/BACKSCATTER_README.html > > If the backscatter is affecting a specific recipient, then there > may be no other option than to reply 450 to all requests except > those from clients that he/she has exchanged email with in the past. > > Before writing down examples it is good to know what the problem is. > > Wietse > -- Mike McGinn KD2CNU Ex Uno Plurima No electrons were harmed in sending this message, some were inconvenienced. ** Registered Linux User 377849
Re: any known issues with mailing lists?
On Mon, Mar 03, 2014 at 05:08:08PM -0600, Noel Jones wrote: > On 3/3/2014 4:45 PM, Jay G. Scott wrote: > > > > I have one user telling me that he has a long mailing list > > (on the order of 34 -- hardly long) and some of the recipients > > bounce. If he mails them one at a time the mail works -- so > > the addresses are okay. > > > > > > What else should I tell you? > > > > > That's not much to go on. > > Postfix logs all bounces, and the reason for the bounce, so finding > the proper log entries is the only thing that keeps you from blindly > guessing at the problem. > > At a minimum examine a bounce message, which should help you find > the relevant postfix logging. heh. The original report to me was enormous and I managed to overlook a "too many hops" notice. I've seen these at my site before, they've been going on for years, but they're still rare. Maybe 4-6/year. I checked all the "offending" addresses and they came back as deliverable. So I believe these are transient effects due to occasional spikes in the machine load (the machine's load is low with occasional spikes -- but the spikes occur several times/day last time I checked). seem reasonable? thanks, BTW. j. > > If you post bounce messages or logs to this list, you can change > user names, but please leave domain names intact. > > > > -- Noel Jones -- Jay Scott 512-835-3553g...@arlut.utexas.edu Head of Sun Support, Sr. System Administrator Applied Research Labs, Computer Science Div. S224 University of Texas at Austin
Re: Compromised Passwords
> > > I'm constantly facing the same problem (passwords comprimised, accounts > abused). May you be so gentle to share your policyd configuration? It would > be really helpful. Thank you in advanced. > I sent you an email with our configuration/notes. If anyone else is interested, let me know. cheers, VM
Re: any known issues with mailing lists?
Jay G. Scott: > overlook a "too many hops" notice. > > I've seen these at my site before, they've been going on for years, > but they're still rare. Maybe 4-6/year. I checked all the "offending" > addresses and they came back as deliverable. So I believe these > are transient effects due to occasional spikes in the machine load > (the machine's load is low with occasional spikes -- but the spikes > occur several times/day last time I checked). > > seem reasonable? Hmm.. If the hop-count increases due to overload then some system is mis-configured and sending mail in a loop. This should be easy to diagnose by looking for a repeating pattern with the hostnames in Received: headers. Wietse
Re: Compromised Passwords
On Wednesday 05/03/2014 at 9:25 am, Blake Hudson wrote: Homer Wilson Smith wrote the following on 3/4/2014 4:38 PM: Dear Gentle Folk, What is the state of the art in dealing with users whose SASL password has been compromised? Running CentOS, and latest postfix. When a password gets compromised, spam starts to pour out of the server from endless numbers of IP's, to endless numbers of addresses. Rate limiting is interesting but doesn't really stop the spam. Counting client=[IP] addresses until a threshold is reached is highly effective, but then what? Change their password? Thanks in advance. Homer Just to confirm what others have said. Yes. Monitor activity for abusive/suspicious behavior and take action to stop it as soon as it's discovered. If you can automate it, even better. While one could use a policy server, we chose to use an out of band monitoring solution that used the postfix logs. We track emails sent and then geolocate by IP of the client. If a single customer is simultaneously (or very quickly) spending time in several countries or continents then we know there's a problem. This has had a very low false positive hit rate and does a good job of catching most of the abuse we see coming from our customer accounts. We use other thresholds based on volume to catch spam sent from one or two IP addresses. Like another poster, we also use fail2ban, anvil, and have minimum password requirements to help create a layered solution to slow or prevent abuse in an automatic fashion. We typically change the password on accounts flagged for abuse and then contact the customer to inform them of the problem and recommend they take action to secure their systems and change their passwords on any other accounts that may have shared similar credentials. --Blake We run a dedicated outbound mx, omx1, which runs postfwd tht does sender rate limiting, at 3 levels of quantity. This box's my_networks contains only the 3 IPs of our 3 mail servers. 50 msgs max for everybody not whitelisted for the 50 msg limit. 700 msgs max for users we know are legit volume senders send more than 50 but less than 700 are legit volume senders a few legit senders send over 700, so they have their own whitelist. 2000 msgs max for everybody, since no legit user sends that many. So even if one of the above whitelisted senders gets cracked, the cracker is HOLDed at 2000 msgs. when these limits are hit, postfwd returns a HOLD action to postfix for that sender. Monit is watching the HOLD queue and sends an alert. On the box doing SMTP AUTH submission, we observed how many different IPs legit users submitted from per day.that number was 10 IPs. We run a script every 10 minutes that checks PER THIS HOUR for any SMTP AUTH login that exceeds 10 IPs. That script doesn't react to block that cracked SMTP AUTH user (that's next), but does email an alert with username and number of SMTP AUTH IPs. this two-level checking has, so far, killed our exposure to password cracks. Len
RE: Compromised Passwords
What has worked for me. Develop a policy where user must have 8 char min password that is not dictionary based. Linux Pam for example helps with this. Then obtain and run fail2ban against your smtp/pop/imap logs. Most passwords are guessed using dictionary attacks, which fail2ban you can blacklist ips if they get the password wrong X number of times. This will not stop 100% of the spam due to compromised accounts as some accounts are compromised from the users PC but for me it has made a huge improvement, it has cut down on spam generated from my servers by 98%. The other thing to do is subscribe to yahoo/aol/etc spam feedback loops as this will let you know if there is spam from your network and email you at which point you can minimize the issue and fix the problem. I used to have an issue with compromised accounts generating spam but using the combination of things I mentioned above it have almost no issues. I now go several months without any issues and haven't gotten blacklisted in years and this is running 4 smtp servers. p -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of lcon...@go2france.com Sent: Wednesday, March 05, 2014 4:42 PM To: postfix-users@postfix.org Subject: Re: Compromised Passwords On Wednesday 05/03/2014 at 9:25 am, Blake Hudson wrote: > > Homer Wilson Smith wrote the following on 3/4/2014 4:38 PM: >> >> >>Dear Gentle Folk, >> >>What is the state of the art in dealing with users whose SASL >> password has been compromised? >> >>Running CentOS, and latest postfix. >> >>When a password gets compromised, spam starts to pour out of >> the server from endless numbers of IP's, to endless numbers of >> addresses. >> >>Rate limiting is interesting but doesn't really stop the spam. >> >>Counting client=[IP] addresses until a threshold is reached is >> highly effective, but then what? Change their password? >> >>Thanks in advance. >> >>Homer >> > > Just to confirm what others have said. Yes. Monitor activity for > abusive/suspicious behavior and take action to stop it as soon as it's > discovered. If you can automate it, even better. > > While one could use a policy server, we chose to use an out of band > monitoring solution that used the postfix logs. We track emails sent > and then geolocate by IP of the client. If a single customer is > simultaneously (or very quickly) spending time in several countries or > continents then we know there's a problem. This has had a very low > false positive hit rate and does a good job of catching most of the > abuse we see coming from our customer accounts. We use other > thresholds based on volume to catch spam sent from one or two IP > addresses. Like another poster, we also use fail2ban, anvil, and have > minimum password requirements to help create a layered solution to > slow or prevent abuse in an automatic fashion. > > We typically change the password on accounts flagged for abuse and > then contact the customer to inform them of the problem and recommend > they take action to secure their systems and change their passwords on > any other accounts that may have shared similar credentials. > > --Blake We run a dedicated outbound mx, omx1, which runs postfwd tht does sender rate limiting, at 3 levels of quantity. This box's my_networks contains only the 3 IPs of our 3 mail servers. 50 msgs max for everybody not whitelisted for the 50 msg limit. 700 msgs max for users we know are legit volume senders send more than 50 but less than 700 are legit volume senders a few legit senders send over 700, so they have their own whitelist. 2000 msgs max for everybody, since no legit user sends that many. So even if one of the above whitelisted senders gets cracked, the cracker is HOLDed at 2000 msgs. when these limits are hit, postfwd returns a HOLD action to postfix for that sender. Monit is watching the HOLD queue and sends an alert. On the box doing SMTP AUTH submission, we observed how many different IPs legit users submitted from per day.that number was 10 IPs. We run a script every 10 minutes that checks PER THIS HOUR for any SMTP AUTH login that exceeds 10 IPs. That script doesn't react to block that cracked SMTP AUTH user (that's next), but does email an alert with username and number of SMTP AUTH IPs. this two-level checking has, so far, killed our exposure to password cracks. Len >
Re: any known issues with mailing lists?
On Wed, Mar 05, 2014 at 04:19:16PM -0500, Wietse Venema wrote: > Jay G. Scott: > > overlook a "too many hops" notice. > > > > I've seen these at my site before, they've been going on for years, > > but they're still rare. Maybe 4-6/year. I checked all the "offending" > > addresses and they came back as deliverable. So I believe these > > are transient effects due to occasional spikes in the machine load > > (the machine's load is low with occasional spikes -- but the spikes > > occur several times/day last time I checked). > > > > seem reasonable? > > Hmm.. If the hop-count increases due to overload then some system > is mis-configured and sending mail in a loop. > > This should be easy to diagnose by looking for a repeating pattern > with the hostnames in Received: headers. thanks. i'll go do my homework. j. > > Wietse -- Jay Scott 512-835-3553g...@arlut.utexas.edu Head of Sun Support, Sr. System Administrator Applied Research Labs, Computer Science Div. S224 University of Texas at Austin
outbound ipv6
I have a long running postfix setup dual stacked IPv4 and IPv6. I've specified the outbound bind addresses for smtp. smtp unix - - - - - smtp -o smtp_bind_address=[...] -o smtp_bind_address6=[...] I use the host to receive mail to my domain as well as send outbound mail from my accounts. I noticed recently that outgoing mail did not appear to be using IPv6, even for destinations which should support IPv6 MX. Mail being received arrives fine over IPv6. To experiment, I setup a transport_map for a known third party and bound it only to IPv6. When I then sent mail to that third party, IPv6 was used, as expected. So my smtp_bind_address6 *was* correct, but for some reason postfix was preferring v4 without the map. After some further testing it occurred to me to try modifying the "relay" service with smtp_bind_address and smtp_bind_address6 as I did with the "smtp" service. In doing so, my mails suddenly started exiting via IPv6. Reverting the bind option went back to IPv4, and restoring the options again enabled outbound IPv6. So I'm left with a couple questions: 1- Why is my outbound mail using 'relay' instead of 'smtp'? Based on what I saw in the documentation (http://www.postfix.org/postconf.5.html#relay_transport), relay sounds like it's "for remote delivery to domains listed with $relay_domains". My $relay_domains is localhost and my hostname, so I wouldn't expect an external domain (eg gmail.com) to use 'relay'. I can't tell if I've horribly misconfigured something, or if I'm just misunderstanding the documentation on when relay is normally used. 2- Why does postfix stop using IPv6 just because I haven't bound it to a specific IPv6 address? Even if I had never realized that it was using relay, the host still has inet_protocols = all, clearly receives over IPv6, and clearly has functional IPv6 addresses for outbound mail. In absence of the transport being bound to either IPv4 or IPv6, I would have expected it to opportunistically use IPv6, but it appears to only ever use IPv4. Thanks
