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
