Has my mail server been compromised?

I am seeing entries in my maillog similar to this:

May 27 21:44:35 vps postfix/smtpd[32760]: AFFD65A086A4: client=unknown[]
May 27 21:44:36 vps postfix/cleanup[17610]: AFFD65A086A4: message-id=<1211950387.7771@lxe.com>
May 27 21:44:36 vps postfix/qmgr[7538]: AFFD65A086A4: from=<alindsy_cd@lxe.com>, size=1624, nrcpt=3 (queue active)
May 27 21:44:36 vps postfix/smtpd[32760]: disconnect from unknown[]

That’s not my IP or any IP for anybody authorized to send mail using the server.

Any help would greatly be appreciated!

Looks like your postfix could be a open-relay. Check your settings.

Also a whois look up for that IP gives…

inetnum: 190.160/15
status: allocated
responsible: Italo Sambuceti
address: Reyes Lavalle, 3340, 4th floor
address: 6760335 - Santiago -
country: CL
phone: +56 02 3101502 []
owner-c: ISO
tech-c: ISO
created: 20070322
changed: 20070322

nic-hdl: ISO
person: Italo Sambuceti Oyarz�n
e-mail: isambuce@VTR.CL
address: Reyes Lavalle, 3340, 4 th floor
address: 676-0335 - Santiago -
country: CL
phone: +56 02 3101609 []
created: 20020906
changed: 20021122

Thanks for the help!

I am pretty sure I turned off open relaying and when I checked at http://mxtoolbox.com/diagnostic.aspx it says it is not an open relay.

postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
home_mailbox = Maildir/
html_directory = no
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $myhostname, localhost.$mydomain, localhost, vps.MyHostingDomain.net
newaliases_path = /usr/bin/newaliases.postfix
qmgr_message_active_limit = 4000
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sender_bcc_maps = hash:/etc/postfix/bcc
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
smtpd_sasl_auth_enable = yes
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual

What is mynetworks set to?

postconf mynetworks

I doubt that’s the problem, but I don’t see it, so though it worth checking.

It doesn’t look like you have an open relay there…and I’m not sure the logs you’re seeing indicate relaying (there should be more after those messages, I think).

mynetworks =

These are the IPs for my server so they are good :slight_smile:

There are not more associated with that connection as far as I can tell.
How would I do a grep in the maillog for AFFD65A086A4?

OK I figured out how to grep and yes there were more instances of that ID and it looks like it was just spam being send from a single outside source TO to of my mail accounts at the same time so all is ok :slight_smile:

The other lines were about 200 lines down in the log because some clown was doing a dictionary attack and I had gazillion Aborted lines in the file.

This brings up another issue.

What’s the best way to prevent a dictionary style attack like that?

pull the plug

in other words you can’t prevent the attack afaik
you can secure the system better by creating non-dictionary passwords with min. length of 15 characters like hnJyg$42#eds@kjJ

many users use passwords like: “thisismypasswordandnoonewilleverguess” and that’s what dic-attacks are looking for.

Minimum length of 8 characters is fine, as long as the password is strong–numbers, upper/lower letters, and/or symbols. No dictionary words. A strong 8 character password could take years for a brute force attack to find…the attacker will move on to greener pastures after a couple of days.

There have also been discussions here in the forums about other techniques. Lief brought up some nice iptables rules for tackling the problem a couple of years back, and lots of people have had good success using them for all sorts of services (the discussion was about ssh, but they can be applied to almost any service because iptables is awesome like that).

Here’s that thread, with much good discussion:


My passwords are good :slight_smile:

I have been using IPTables to stop unwanted entry by tying some services to my home office IP only and that stopped brute force on the attempted ports dead. Since I am the only user on the box and don’t have hosting customers I can do things like that :slight_smile:

I know about Leifs cool reject rules and the last time I tried to implement them I was on a Virtuozzo VPS running CentOS 4.6 and the needed kernel module could not be added to allow me to run those rules in the VE space.

I am now on an OpenVZ VE running CentOS 5.1 and will try them again as I would rather use that method to stop entry so I don’t have to worry about being able to access if I am at a different location.

have you heard of the super computer NASA has?
According to an article this baby can crack passwords in a few seconds while the strongest home PC would take more than 100 years.

I’m just saying…no one is safe if the FBI gets their hands on that toy, haha :wink:

If the US government is after you, you’re already in serious trouble.

According to an article this baby can crack passwords in a few seconds while the strongest home PC would take more than 100 years.

They’d have to have access to your shadow file to be able to attack any faster than us mere mortals. They still have the limits imposed by the network and the services that they are using as an attack vector. e.g. they can only send so many requests to ssh before they run out of bandwidth into your server or the ssh daemon can’t keep up any more.

The government (NSA, not NASA, by the way!) certainly have serious tools for invading your privacy, but they aren’t usually who we all have to worry about. Most of our security foes are merely looking for more servers to use for sending spam…and they aren’t all that smart, generally. They mostly use off-the-shelf tools, and just look for the low-hanging fruit (Windows boxes, mostly).

I would like to point out DenyHosts – http://denyhosts.sourceforge.net/

DenyHosts is a script intended to be run by Linux system administrators to help thwart SSH server attacks (also known as dictionary based attacks and brute force attacks).

If you’ve ever looked at your ssh log (/var/log/secure on Redhat, /var/log/auth.log on Mandrake, etc…) you may be alarmed to see how many hackers attempted to gain access to your server. Hopefully, none of them were successful (but then again, how would you know?). Wouldn’t it be better to automatically prevent that attacker from continuing to gain entry into your system?

DenyHosts attempts to address the above… and more.