• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Apparent serious security problem with qmail?

Q

Qamera

Guest
running plesk 7.5.4 on fedora

Please forgive my newness to this, I will try to be as precise as I can with my limited understanding of QMail. I have seen many threads similar to my problem, but none seem to address my specific details that I have been able to deduce, so here goes with the story

Firstly I noticed email from my server were starting to take a longer and longer to arrive at their destination. After looking into this I found tonnes of messages in the mail queue, stuck there, apparently illegal destinations that are being held for retry. I cleaned the queue but obviously it was still going on.

After reading this forum a while I tried a few things.

1. I cleared the files rcpthosts and virtualhosts in /var/qmail/control/ so that QMail would not recognise any address as local. (yes i did restart qmail and xinetd)
Why? So that there was no way any email in the queue could be an undeliverable bounce message being sent back to the return path of the original message that was sent to a non-existant local mailbox. Seeing as there are no local domains at all.

2. I sat and watched and saw more messages getting jammed in the queue so I stopped httpd.
Why? So that the queued messages could not be coming from any web site hosted on my server that has a mailer script, either by design or by exploit.

3. Messages still kept appearing in the queue. The ONLY way these could be getting in was through the smtp server, so I stopped it with xinetd. Low and behold, the queued messages stopped appearing.

That was how they were getting in, via the SMTP server. the question is how? Analasis of a message in the queue showed that it was recieved by an external client (not localhost) by SMTP. I do not have any entries in my whitelist other than 127.0.0.1 either. When i test the SMTP server using telnet it appears to be disallowing relaying correctly, so the question is how the hell are these spammers getting round this? It would appear to be a serious security bug from my view point.

My next line of action is to change the port SMTP runs on to 8825 and setup a TCP redirect from port 25 to port 8825 locally so i can monitor what is being sent to the SMTP server from the spammers. Hopefully I will find out what they are doing. If you want me to post the results here, or if anyone out there knows what is going on, please let me know.

Thanks.
 
I reported this problem to my server hosting provider and they have mailed me back saying it was a known issue and has been resolved. I checked my root login and saw that someone from there had logged in as root not so long ago. They did not say what they have done or what the actual vulnerability was, so I have replied asking them if they would let me know the details so that I could repair my other servers myself instead of paying them $300 an hour to do it.

So far, no reply.
 
Back
Top