8 Replies Latest reply: Sep 26, 2013 2:56 PM by MadMacs0
meandrik Level 1 Level 1 (0 points)

Hello!

 

We have a huge trouble .. Our mac server makes a spam delivery. Our IP already blacklisted in about a dozen of servers (checked with http://mxtoolbox.com/). We have another computers in the same networks, including PC. What I already did and discovered:

 

  1. I found a spam emails in the "Server Admin app"->Mail->Maintenance->Mail Queue (attached image).
  2. I managed to get one of those email from /var/spool/postfix/ folder. Here is the link - simple HTML file (http://www.sendspace.com/file/wbyjov). Didn't find anything useful there, like IP address..
  3. I searched for malware with ClamXav on the server - with no help
  4. I re-checked PC computers with antiviruses - with no help

 

Also, the fact that these emails appears in "Mail Queue" means that Mac OS server sends them by itself, right? Or is it possible that another computer in the same network sends them?


Thank you in advance for you answers!!!!

spam email.png


Mac mini, OS X Server, Version 10.6.8
  • MrHoffman Level 6 Level 6 (13,005 points)

    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 Level 1 Level 1 (0 points)

    Thank for your response! Here is the log:

     

    alias_maps = hash:/etc/aliases

    biff = no

    command_directory = /usr/sbin

    config_directory = /etc/postfix

    content_filter =

    daemon_directory = /usr/libexec/postfix

    debug_peer_level = 2

    enable_server_options = yes

    header_checks =

    html_directory = /usr/share/doc/postfix/html

    inet_interfaces = localhost

    local_recipient_maps =

    mail_owner = _postfix

    mailbox_size_limit = 0

    mailbox_transport = dovecot

    mailq_path = /usr/bin/mailq

    manpage_directory = /usr/share/man

    message_size_limit = 0

    mydestination = $myhostname, localhost.$mydomain, localhost

    mydomain = example.com

    mydomain_fallback = localhost

    myhostname = example.com

    mynetworks = 127.0.0.0/8

    newaliases_path = /usr/bin/newaliases

    owner_request_special = no

    queue_directory = /private/var/spool/postfix

    readme_directory = /usr/share/doc/postfix

    recipient_delimiter = +

    relayhost =

    sample_directory = /usr/share/doc/postfix/examples

    sendmail_path = /usr/sbin/sendmail

    setgid_group = _postdrop

    smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated permit

    smtpd_enforce_tls = no

    smtpd_helo_required = no

    smtpd_helo_restrictions =

    smtpd_pw_server_security_options = login,plain,gssapi,cram-md5

    smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks  reject_unauth_destination permit

    smtpd_sasl_auth_enable = yes

    smtpd_tls_CAfile = /etc/certificates/example.com.E8236D8446AABAAEF98B22D64C6A69F4AA8E4E79.chain.pe m

    smtpd_tls_cert_file = /etc/certificates/example.com.E8236D8446AABAAEF98B22D64C6A69F4AA8E4E79.cert.pem

    smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL

    smtpd_tls_key_file = /etc/certificates/example.com.E8236D8446AABAAEF98B22D64C6A69F4AA8E4E79.key.pem

    smtpd_tls_loglevel = 0

    smtpd_use_pw_server = yes

    smtpd_use_tls = yes

    tls_random_source = dev:/dev/urandom

    unknown_local_recipient_reject_code = 550

    virtual_alias_domains = $virtual_alias_maps

    virtual_alias_maps = $virtual_maps

     

    Unfortunately didn't find anything useful in Console.app just a lot of garbage

    We have a publick/static IP.

    Also, here is logs from Admin panel (IMAP log, SMTP log and ACCESS log):

    IMAP log.png

    SMTP log.png

    ACCESS log.png

  • MadMacs0 Level 5 Level 5 (4,470 points)

    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 Level 1 Level 1 (0 points)

    I didn't know that. I just downloaded it from here http://www.clamxav.com/. It didn't find anything anyway...

  • meandrik Level 1 Level 1 (0 points)

    Hey!!!! I found something. Attached image - someone from PI 41.138.183.186 trying to connect to the server, a lot of requests in short period! I changed passwords for all users and I think he can't connect!!! It looks like attack, what should I do?

     

    attack.png

  • MadMacs0 Level 5 Level 5 (4,470 points)

    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

  • MrHoffman Level 6 Level 6 (13,005 points)

    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. 

  • MadMacs0 Level 5 Level 5 (4,470 points)

    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.