Re: Is it possible to require authentication based on specific properties of the MUA or its connection?
On 10/13/2014 9:04 PM, Noel Jones wrote: On 10/13/2014 6:54 PM, Ben Johnson wrote: Hello! Is it possible to require authentication based on specific properties of an MUA or its connection? I would like to require all connections that originate from the php-fpm daemon (or its children) on the server in question to be forced to authenticate when sending mail through Postfix. At the same time, I need for messages from other sources (cron scripts, system maintenance utilities, etc.) to be sent as normal, without requiring authentication. This is usually done by controlling the authorized_submit_users postfix option. http://www.postfix.org/postconf.5.html#authorized_submit_users However, all your web scripts are probably submitting as the www or similar user. Hi, Noel, and thanks for the most helpful response. Thank you also, Stephen. Actually, I've ensured that each virtual-host executes PHP scripts under a unique system user, so I wouldn't have the problem of every script running under www or similar. So, your suggestion to use authorized_submit_users looks very attractive in that respect. But given that this facility only controls the system users who may submit mail, I'm left wanting for a means by which to control authentication requirements, instead of outright forbidding sending. And my only reason for wanting the authentication requirement is to trace abusive sending to a particular website that is hosted on this system. Basically, my concern is that most sites have a legitimate need to send email in one form or another (notices to admins, CMS system emails, new user registrations, web form submissions, etc.), so I'd need to whitelist virtually all of the unique PHP users, thereby mitigating the usefulness of this type of control (and perhaps even creating additional administrative overhead). The other problem is that legitimate websites become compromised (as in this particular case), and they'd be whitelisted when compromised, which mitigates its usefulness in this particular context. In short, I have a pesky PHP script somewhere, under a customer's hosted account, that is sending outgoing spam messages. The script appears not to be using PHP's mail() function, and may instead be speaking to Postfix directly, which renders PHP's mail-related logging functions irrelevant and useless, and makes the source much more difficult to trace. The Postfix and amavis-new logs are not terribly useful in this context (at least at the default verbosity) because all they reveal is that the messages are coming from localhost. The port number is listed, too, but I don't know if that reveals anything useful. amavisd-new doesn't enter into this, as the mail enters via postfix. Likely there is a postfix/pickup line where the mail first enters the queue, which will show the user ID being used (likely just www, and not particularly helpful). Actually, given that all virtual-hosts execute PHP scripts under unique system users, knowing the system username under which the message was submitted would be hugely useful. And now that you say this, I went back and looked and you are exactly right! Oct 13 19:54:20 vr postfix/pickup[1406]: C637426257: uid=5027 from=random_user@other_domain.com I missed the uid=5027! How foolish of me! *** pssschk!!! slaps own face *** This ties the abuse to a particular website, which is all I really wanted. So, THANK YOU! There are probably better clues in your web logs. If there is a better way to deal with this nuisance than resorting to stricter authentication protocols, I would love to hear alternate suggestions. Probably disable the sendmail command for the www user (via authorized_submit_users), and require each user to connect to a specific IP:port that requires SMTP AUTH, each customer with their own credentials. At least that way you know who's account is compromised. But setting this up will be disruptive to current customers. Not fun. Good luck. -- Noel Jones Rather than sift through web logs, I employed a tool called RIPS, which scans a website (recursively, if desired) and flags any scripts that utilize high-risk functions in a way that could lead to arbitrary code execution. It picked-up several compromised files, which when examined manually were indeed backdoors. I highly recommend this tool to anyone, and am considering employing its routine and scripted use in my own work. With your help, the situation is under control, and I'll know exactly where to look in the future. Thanks again! -Ben
Re: Is it possible to require authentication based on specific properties of the MUA or its connection?
On 10/14/2014 9:38 AM, Ben Johnson wrote: So, your suggestion to use authorized_submit_users looks very attractive in that respect. But given that this facility only controls the system users who may submit mail, I'm left wanting for a means by which to control authentication requirements, instead of outright forbidding sending. And my only reason for wanting the authentication requirement is to trace abusive sending to a particular website that is hosted on this system. You seem to be missing the point that when you use the local sendmail(1) interface, the userID *is* the authentication. Postfix must either accept or reject the mail based solely on the userID. To use more robust username/password authentication, you must use SMTP AUTH, which of course requires mail be submitted via SMTP rather than sendmail(1). -- Noel Jones
Re: Is it possible to require authentication based on specific properties of the MUA or its connection?
Noel Jones: To use more robust username/password authentication, you must use SMTP AUTH, which of course requires mail be submitted via SMTP rather than sendmail(1). For submnission with /usr/sbin/sendmail: /etc/postfix/main.cf authorized_submit_users = !uid-of-hacked-acount, static:all This excludes mail from the hacked account. Wietse
Re: Is it possible to require authentication based on specific properties of the MUA or its connection?
On 14 Oct 2014, at 08:38 , Ben Johnson b...@indietorrent.org wrote: Basically, my concern is that most sites have a legitimate need to send email in one form or another (notices to admins, CMS system emails, new user registrations, web form submissions, etc.), so I'd need to whitelist virtually all of the unique PHP users, thereby mitigating the usefulness of this type of control (and perhaps even creating additional administrative overhead). You simply make them use standard libraries and authenticated SMTP. FSVO of “simply”, of course. I missed the uid=5027! How foolish of me! *** pssschk!!! slaps own face *** This ties the abuse to a particular website, which is all I really wanted. So, THANK YOU! Glad you got it sorted. The last time this happened to me with php I had a lot more trouble finding the source of the problem. Now I have all the web stuff on a separate machine from the mail, so it is not possible for web sites to send mail without doing it properly or using someone else’s mail server. -- 'I'm just going to kick some arse dear' 'Oh, good. Just be sure you wrap up well, then.'
Re: Is it possible to require authentication based on specific properties of the MUA or its connection?
On 10/13/2014 6:54 PM, Ben Johnson wrote: Hello! Is it possible to require authentication based on specific properties of an MUA or its connection? I would like to require all connections that originate from the php-fpm daemon (or its children) on the server in question to be forced to authenticate when sending mail through Postfix. At the same time, I need for messages from other sources (cron scripts, system maintenance utilities, etc.) to be sent as normal, without requiring authentication. This is usually done by controlling the authorized_submit_users postfix option. http://www.postfix.org/postconf.5.html#authorized_submit_users However, all your web scripts are probably submitting as the www or similar user. In short, I have a pesky PHP script somewhere, under a customer's hosted account, that is sending outgoing spam messages. The script appears not to be using PHP's mail() function, and may instead be speaking to Postfix directly, which renders PHP's mail-related logging functions irrelevant and useless, and makes the source much more difficult to trace. The Postfix and amavis-new logs are not terribly useful in this context (at least at the default verbosity) because all they reveal is that the messages are coming from localhost. The port number is listed, too, but I don't know if that reveals anything useful. amavisd-new doesn't enter into this, as the mail enters via postfix. Likely there is a postfix/pickup line where the mail first enters the queue, which will show the user ID being used (likely just www, and not particularly helpful). There are probably better clues in your web logs. If there is a better way to deal with this nuisance than resorting to stricter authentication protocols, I would love to hear alternate suggestions. Probably disable the sendmail command for the www user (via authorized_submit_users), and require each user to connect to a specific IP:port that requires SMTP AUTH, each customer with their own credentials. At least that way you know who's account is compromised. But setting this up will be disruptive to current customers. Not fun. Good luck. -- Noel Jones
Re: Is it possible to require authentication based on specific properties of the MUA or its connection?
On 10/13/2014 04:54 PM, Ben Johnson wrote: If there is a better way to deal with this nuisance than resorting to stricter authentication protocols, I would love to hear alternate suggestions. [php direct mailing] Have you considered adding system to the list of disallowed function calls? (I remember someone else mentioning this.) http://www.cyberciti.biz/faq/linux-unix-apache-lighttpd-phpini-disable-functions/
