Stop www-data Spam Mail on Your Server

If your server is sending out spam emails, the culprit is often the www-data user—the account that runs your web server. A compromised PHP script, a vulnerable plugin, or a misconfigured contact form can be abused to send thousands of emails. This guide shows you how to lock down www-data so it can no longer send mail, stopping the spam at the source. You’ll need root or sudo access to your server.

What You’ll Need

• Root or sudo access to your Linux server (Ubuntu, Debian, CentOS, etc.)
• Basic familiarity with the command line
• Ability to edit files in /etc (e.g., using nano or vim)

Step-by-Step

1. Identify the mail path. First, check which mail transfer agent (MTA) is installed. Run which sendmail and which postfix. If you see /usr/sbin/sendmail, it might be Postfix or Sendmail. Also check which exim and which mail. This tells you what binaries are being used to send mail.
2. Check current mail logs. Look at /var/log/mail.log (or /var/log/maillog on CentOS) to see if there are bursts of outgoing mail. Use grep 'status=sent' /var/log/mail.log | tail -n 20 to see recent sent messages. Note the sender and recipient addresses—they’ll often be random or from your domain.
3. Find the source script. If you see emails from www-data, search your web directory for PHP files that contain mail functions. Use grep -r 'mail(' /var/www/html (adjust path to your web root). Look for suspicious files—recently modified, in upload directories, or with obfuscated code.
4. Remove or neutralize the malicious script. Delete the offending file if it’s clearly malware. If it’s a legitimate plugin or script that’s vulnerable, update it or remove it temporarily. Also check cron jobs (crontab -e for root, and ls /etc/cron.*) for anything running as www-data that might be sending mail.
5. Block the sendmail binary for www-data. The most direct fix is to remove execute permissions on the mail binary for the www-data user. Run:
   chmod o-x /usr/sbin/sendmail
   This removes execute permissions for “other” (which includes www-data). Test with sudo -u www-data /usr/sbin/sendmail -v test@example.com—it should fail with “Permission denied.”
6. Use AppArmor or SELinux (if available). On Ubuntu/Debian with AppArmor, you can create a profile to deny mail sending. For example, create /etc/apparmor.d/usr.sbin.php-fpm with rules that deny /usr/sbin/sendmail. On CentOS with SELinux, you can set setsebool -P httpd_can_sendmail off (this is often already off, but verify).
7. Configure PHP to disable mail functions. In your php.ini file (find it with php -i | grep php.ini), add disable_functions = mail, sendmail. Then restart PHP-FPM or Apache. This stops any PHP script from using the mail() function.
8. Restart services. After making changes, restart your web server and MTA: sudo systemctl restart apache2 (or nginx/php-fpm) and sudo systemctl restart postfix (if you’re using Postfix).
9. Monitor logs. Watch /var/log/mail.log for any new attempts. If you still see outgoing mail, the attacker may have found another way (e.g., using SMTP directly). In that case, you’ll need to block outbound SMTP connections from the web server (see Common Mistakes).

Common Mistakes

• Only removing the script. If you delete the malicious script but don’t lock down the mail binary, the attacker can re-upload it. Always combine script removal with permission changes.
• Blocking sendmail but not other MTAs. Some servers use Exim or Postfix’s sendmail wrapper. Make sure you block all mail-sending binaries: /usr/sbin/sendmail, /usr/sbin/exim4, /usr/sbin/postfix (though postfix is usually not directly executable by www-data).
• Forgetting about PHP’s mail() function. Even if you block the binary, PHP’s mail() function can still try to use it. Disable it in php.ini as described.
• Not checking for other users. Spam might be sent by another user (e.g., a compromised FTP account). Repeat the process for any user that runs web services.
• Overlooking SMTP direct connections. A script can connect to localhost:25 (or a remote SMTP server) directly. To block this, use firewall rules to prevent outbound connections on port 25 from the web server, except to your own mail server if needed.

Tips

• Use a firewall. On Ubuntu, use UFW: sudo ufw deny out 25 (this blocks all outbound SMTP, which may affect legitimate mail sending—adjust accordingly). On CentOS, use firewalld: sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p tcp --dport 25 -j REJECT.
• Run your web server as a non-privileged user. If you can, run PHP-FPM as a dedicated user (e.g., phpuser) instead of www-data. Then you can restrict that user’s permissions more tightly.
• Use a mail relay. If your applications need to send email (e.g., password resets), set up a dedicated mail relay that requires authentication. Then block direct SMTP from the web server and only allow the relay.
• Regularly scan for malware. Use tools like ClamAV or Linux Malware Detect (LMD) to scan your web directory for malicious files.
• Keep software updated. The most common way www-data gets compromised is through vulnerable plugins or outdated CMS software. Regular updates reduce the risk.

Troubleshooting

• After blocking sendmail, your legitimate web forms stop sending email. This is expected. You’ll need to configure a valid mail relay or use an external SMTP service (like your hosting provider’s SMTP) with authentication in your application. Update your PHP scripts to use SMTP instead of the mail() function.
• You still see outgoing mail in logs. Check if the mail is being sent via a different binary (e.g., /usr/bin/mail). Block that too. Also check if the attacker is using a PHP script that connects to an external SMTP server—use netstat -tulpn to see active connections from the web server.
• AppArmor or SELinux denies everything. If you enable a strict profile, you might break legitimate services. Test with aa-status (AppArmor) or getenforce (SELinux). Adjust the profile to allow necessary operations while denying sendmail.
• You can’t find the malicious script. Use lsof -p $(pgrep -u www-data | head -1) | grep mail to see which files the www-data process has open. Also check /tmp and /dev/shm for suspicious files.
• After restarting services, the site breaks. If you disabled too many functions, PHP might error out. Check /var/log/php_errors.log and re-enable any functions that are essential (e.g., mail might be needed for a contact form—instead, use SMTP).

Frequently Asked Questions

1. Will blocking sendmail break my website? It will break any script that relies on the PHP mail() function or direct sendmail. However, most modern applications use SMTP with authentication, which is not affected. If you need mail, configure an SMTP relay.
2. How do I know if my server is sending spam? Check mail logs for a high volume of sent messages, or look for bounce-back emails in your inbox. You can also use pflogsumm (for Postfix) to summarize mail traffic.
3. Can I just change the www-data user’s shell to nologin? That would prevent login, but www-data still runs web processes. It won’t stop mail sending. You need to restrict the mail binaries specifically.
4. What if I use Nginx instead of Apache? The process is the same—www-data is often used for Nginx too. The steps apply regardless of the web server.
5. Is it safe to delete the malicious script? Yes, if you’ve verified it’s malicious. But first, back it up for analysis. After deleting, scan the entire web directory for other infected files.
6. How do I prevent this from happening again? Keep your CMS and plugins updated, use strong passwords, disable file uploads in directories that don’t need them, and regularly scan for malware. Also, consider using a Web Application Firewall (WAF).

Related

• Galaxy S7 & S7 Edge: Fix Disappeared Gallery Pictures
• Coding Agent Permissions: What to Allow & When
• How to Enable 4K HDR and 120Hz Over HDMI