• Introducing WebPros Cloud - a fully managed infrastructure platform purpose-built to simplify the deployment of WebPros products !  WebPros Cloud enables you to easily deliver WebPros solutions — without the complexity of managing the infrastructure.
    Join the pilot program today!
  • Support for BIND DNS has been removed from Plesk for Windows due to security and maintenance risks.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS.

qmail security problem

M

masterkain

Guest
hi,
today one of my servers got hit hard, probably by an automatic worm that send tons of emails to yahoo.com users.

with the help of netstat I was able to track down the offender: 83.225.117.60 but the worst thing is that this must be an authenticated user since we do not relay (of course).

now, I'm not able to know who is he, and which email has, since qmail logs are pretty orrible and doesn't show any info.
I've tried searching maillogs for this ip, maybe to catch a login, but nothing.

is there a way to know who is this user and how damn to enable source ip address in qmail logs without recompiling and patching from source?

thanks.
 
btw I'm on debian, no rpms atomicrocketetc rpms there..
 
How did you come to the conclusion that it was via a authenticated relay user?

Qmail should be setup to POP first, then allow relay. Which means you should see an entry in your maillog similar to this:

Dec 19 04:26:13 host1 pop3d: IMAP connect from @ [192.168.0.1]INFO: LOGIN
, user=doof, ip=[192.168.0.1]

And then later on you should see an entry in /var/log/secure:

Dec 19 18:46:42 host1 xinetd[1199]: START: smtp pid=29281 from=192.168.0.1

It is very difficult to tie the qmail log back to the secure log. Another trick is to look at the queue directories for messages that are queue for outbound delivery, pick off the header's the source of the trouble.

Somehow you figured out the IP, so you should be able to get it from the POP logs, unless it was a local delivery (caused by vulnerable web app, for example).
 
Back
Top