-1

My question is regarding preventing php scripts from sending mail. It has been marked a duplicate of another more general question about server security but that's not what this question is about.

After a long and bitter fight against hackerspammers who are somehow injecting rogue base64 encoded php files into various web directories on my Debian / Apache / PHP server, (the bitter fight involving first patching existing scripts and changing ftp passwords, web service passwords, and mysql passwords, then rebuilding sites from scratch, installing maldet - which has curbed the problem but not completely eliminated it - then finally turning off postfix altogether by stopping the service (but not uninstalling), then blocking port 25 traffic from the server at the firewall) I am still having problems.

My problems went away for many months, and the server was automatically removed from blacklists according to mxtoolbox. But today I received an mxtoolbox email saying my server is again blacklisted by many services. I don't fully understand how this is possible given I've disabled outgoing port 25 traffic.

When there's a problem, my postfix mailq fills up with hundreds of thousands of emails from a given webuser on my server.

My questions are this:

  1. Given I've disabled port 25 traffic using iptables -A OUTPUT -p tcp --dport 25 -j REJECT, how is it possible that mxtoolbox is reporting my server is still sending out spam? When I check the mailq, the mails are backed-up. When I start postfix, items in the mailq don't send as indeed I expect, and I see (delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:10024: Connection refused) next to each entry.

  2. Having identified the location of the RAT by looking at the X-PHP-Originating-Script line in a spammy mail in the mailq, I can find and destroy the file in question, which resolves the problem for anywhere between 5 days and many months. How do I completely prevent any php script from sending a mail? If I enter disable_functions = mail into my php.ini file, I understand this prevents the use of internal functions but not custom functions, which a spammer could take advantage of.

  3. What else am I doing wrong?

Caveat: I know #2 doesn't solve my problem at its root, but having taken advice and hardening the security of my server in as many ways as I understand over a couple of years now, I'm working on "deal with the mail reputation issue" rather than "solve all security issues period".

This is a follow-up from my last related question here on ServerFault.

Community
  • 1
hazymat
  • 390
  • 1
  • 9
  • 16
  • 1
    This is like putting a band-aid on cancer. You're getting hacked and your response is to shut off outgoing email? Who knows what else the thoroughly infested server is doing? *Something* you're doing/running is entirely insecure. Fix that. – ceejayoz Oct 12 '15 at 23:23
  • Last time I checked, there was no cure for cancer. And so it is with security. Rather than asking every doctor to become a cancer care specialist, I concluded I would rather concentrate on what I do best, hence my original question! – hazymat Oct 12 '15 at 23:32
  • 3
    As with security issues, many types of cancer are very curable. A doctor who puts a band-aid on cancer and says "that'll do it!" is criminally irresponsible. Chances are if your server is sending out spam it's also doing other nasty things like DDOSing people, serving up malware, exposing your clients' data, etc. – ceejayoz Oct 13 '15 at 00:57
  • 1
    In addition to the information in the question linked as duplicate, you should not merely block outgoing port 25. You should block *all* outgoing traffic except that from an existing HTTP/HTTPS session. There is no reason for a webserver to start initiating connections all over the place. – Jenny D Oct 13 '15 at 07:13
  • The reason this question was marked as a duplicate is that if you are getting emails generated on your server despite all you've done to protect it, then the server must be considered to be compromised. It does not matter that the reason for the compromise is that someone wanted to spam through - it's still a compromised server and needs to be handled as such. – Jenny D Oct 14 '15 at 12:23
  • If your question does not garner enough reopen votes, and you still think it should be reopened, you can post to [meta] and ask that it be reconsidered. – Jenny D Oct 14 '15 at 12:25

2 Answers2

3

You have choices

  1. Remove postfix
  2. Remove php-mail (Ubuntu/Debian package name)

However, spammers can still write their own SMTP code.

Check that SMTP is actually blocked like this

telnet alt4.gmail-smtp-in.l.google.com 25
Ryan Babchishin
  • 6,260
  • 2
  • 17
  • 37
1

Firewall control for port 25 is still your best option, you can then tell any valid users to send email via authenticated servers like mandrill or others on smtps (tcp/587), or use Email API's by 3rd party ESP's

You can still write php code that will connect directly to MX servers via sockets unless you use the firewall approach.

You could also redirect TCP/25 to a catch all system so you can monitor who is compromised or abusive.

Jacob Evans
  • 7,886
  • 3
  • 29
  • 57