Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Over the past day we've detected someone from China using our server to send spam email. It's very likely that he's using a weak username/password to access our SMTP server, but the problem is that he appears to be using base64 encoding to prevent us from finding out which account he's using. Here's an example from the maillog:

May  5 05:52:15 195396-app3 smtp_auth: SMTP connect from (null) []
May  5 05:52:15 195396-app3 smtp_auth: smtp_auth: SMTP user info : logged in from (null) []

Is there any way to detect which account it is that he's using?

share|improve this question

closed as unclear what you're asking by Chris S Feb 6 '14 at 14:16

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question.

Base64 is part of standard SMTP auth. It cannot do what you claim it's being used for. Second, it's an encoding, so it can be easily reversed (base64 -d). – grawity May 5 '10 at 12:38
I'm only echoing what Rackspace support told me. The only information I have as to who is logging in is that above - (null). – robotmay May 6 '10 at 13:37

If I were you, I would look at the SASL logs (if that's what you're using) and see which users are being logged on at the same time. If you don't have SASL logs, you can always look at MySQL/LDAP search logs around that time.

Considering he is logging in as null, I would check my database to make sure I don't have malformed entries or something like that.

Base64 encoding is the norm for SMTP authentication, so that's normal. There is MD5 digest but that won't help if he has "valid" credentials.

A temporary solution would be to block either his IP or the entire IP block.

share|improve this answer
I did block an IP range last night, but his IP has changed dramatically since then. Are the SASL logs separate to the postfix log? I've never dealt with the mail systems on our server, so I'll have a poke around to find out if there are any additional details lying around. – robotmay May 5 '10 at 9:19
SASL logs are separate to Postfix logs indeed. Check out all the possible logs in /var/log and see if you can find anything relevant. Where are the user credentials stored ? – Antoine Benkemoun May 5 '10 at 20:30
Couldn't see any relevant logs in /var/log, or /usr/local/psa/var/log/ (where postfix seems to be logging). Rackspace support have just suggested that we disable logging in without a full email address, which should solve the problem with base64 encoding obscuring the credentials used. However, we won't be able to act on this for a week or two, due to having to notify our clients that they'll need to change. – robotmay May 6 '10 at 13:37
base64 is really not supposed to obscure the credentials used. When you log in with user "foo", it will show up as user "foo" in the logs. base64 is only used for the transmission of the information. – Antoine Benkemoun May 6 '10 at 16:31

You can also try increase the verbosity of postfix, starting it with a -v argument (google says it should be in, I am not a postfix expert).

smtp      inet  n       -       n       -       -       smtpd -v

If that does not work, there is always the nuclear option, tcpdump/wireshark.

share|improve this answer
Tcpdump/wireshark is where I'm sat right now. I'm kinda at a loss, so passing it on to Rackspace to sort out. I'm not familiar enough with our mail system, so they can fix it :D – robotmay May 5 '10 at 13:49

Not the answer you're looking for? Browse other questions tagged or ask your own question.