!!!HELP - mac server infected with a spam agent

Shut down the mail server; on 10.6, that's pretty easy as you can hold all outbound messages via Server Admin.app configuration for the mail server.

There's little point in looking at the spam messages themselves.

Launch Console.app from Applications > Utilities and look for where the spam is arriving in the server. That could be a breached server, a breached client, or mail server credentials, or a classic open relay configuration. This is a key step to securing the server. You need to know where the messages are arriving at your server; how they're getting accepted.

Then launch Terminal.app from Applications > Utilities and post the output of the command

postconf -n

and post the output of that. If you want or need to expurgate, then (consistently) replace your domain name(s) with hosts within the (reserved) domains example.com or example.net or example.org.

If your server security has been breached — somebody got root access — then you're headed for a complete reinstallation from distributions; what's often called a nuke and pave, or wipe and install, etc.

You'll also eventually need to clear up the blacklist settings with Spamhaus and other providers, once you've sorted out the issue and plugged it.

This all assumes you're at a public static IP address, too. If you're at a DHCP dynamic address, then there are other issues.

meandrik wrote:

...I searched for malware with ClamXav on the server - with no help

I'm a bit surprised that worked since the OS X Server contains it's own version of the ClamAV® scan engine and often interferes with ClamXav and vice versa. Apple includes it specifically to scan e-mail content for malware, etc.

meandrik wrote:

Hey!!!! I found something. Attached image - someone from PI 41.138.183.186 trying to connect to the server

IP ADDRESS INFORMATION

IP Address41.138.183.186

Hostname41.138.183.186

NetworkAfrican Network Information Center

Country NG - NIGERIA

Region05

CityLagos

Latitude6.4531

Longitude3.3958

IP Range41.138.170.0 - 41.138.191.255

IP NetworkAmerican Registry for Internet Numbers (ARIN)

ABUSE

HandleGENER11-ARIN

NameGeneric POC

Phone+230 4666616

EmailAbusepoc@afrinic.net

I'd guess an exposed password. (See below.)

Garbage? That's surprising. There should be a large selection of logs visible there, including the logs visible viua the Server Admin.app "keyhole" view of the logs. I greatly prefer Console.app, as what Server Admin.app shows for log contents is practically useless; it's a far too small window into what's going on with far too short a recall of events. You will need to select the particular logs related to the mail server in the left navigation of Console.app, rather than looking at the general (aggregate) view.

In general, please read through the mail server logs yourself, and learn how those pieces fit together. In particular, find where several of the messages are arriving at your mail server. Reading and understanding the logs is key to running and particularly to troubleshooting a server. Follow the mail message IDs as the message goes through the various parts of the processing.

In the "Thank for your response! Here is the log" images, IMAP is not used to send out mail, so there won't be useful data in that log. The SMTP traffic shows some activity and a whole lot of relay reports, but I don't see any submissions there. (Console.app shows more data than what's in that view, too.)

In the same "Thank for your response! Here is the log" posting, there's a particular user shown in the mail access log that's being very frequently used in that section of the logs. That volume of messages might be normal traffic for that user, or the credentials for that user may have been breached. Knowing your mail traffic and also viewing more of the log data via Console.app should help you differentiate that.

In the "Hey!!!! I found something." image, that's a whole pile of login failures. That may have been a result of the password change.

Getting barrages of accesses from random IP addresses (whether 41.138.183.186 or otherwise) is normal, and may or may not be tied to the other issues you're seeing here.

I don't see a way to relay the messages from the postconf -n settings (not having an open relay is goodness), but I do see plaintext authentication and — if that's available from off your network — can result in the exposure of server login credentials. SSL/TLS should be used for submissions.

MadMacs0: installing a second ClamAV probably won't perturb the default installation within OS X Server, presuming the add-on package went into /usr/local and not elsewhere. If the add-on went into the OS X system directories, then all bets are off.

Strangely I cannot see your latest posting here when I'm logged in???

MrHoffman wrote:

MadMacs0: installing a second ClamAV probably won't perturb the default installation within OS X Server, presuming the add-on package went into /usr/local and not elsewhere. If the add-on went into the OS X system directories, then all bets are off.

That's correct, both engines will be installed (ClamXav puts it into /usr/loca/clamXav/). The problems we have seen come up when you attempt to use a process that is already running. That would usually be the clamd process used by ClamXav Sentry, but we've also seen it happen with the freshclam update process.

It's actually pretty simple to skip the engine install and point ClamXav to the server version of the engine (/usr/), but in the past that has usually meant using an out-of-date version since Apple has been slow to update. The recent updates were unusual (perhaps the a first), probably because they were labeled as security related.