On 2008-08-14 at 15:17 -0400, Gordon Dickens wrote:
> unknown sender so I became concerned. It appears, from looking at the
> exim logs, that the sender was authenticating as the"admin" unix user.
> Here is an example of one of these log entries:
> 2008-08-14 02:33:49 1KTWP7-00073v-2J <= [1]uffice@???
> H=rrcs-67-79-255-138.sw.biz.rr.com (User) [67.79.255.138] P=esmtpa
> A=fixed_login:admin S=2110
Take a look at your fixed_login authenticator. Someone used
authentication within SMTP to authenticate as user admin. This doesn't
mean that they were on your system with a shell.
This is probably a dictionary attack which succeeded against a weak
password.
Note also that this was unencrypted SMTP; if it had been within TLS/SSL
then you would see P=esmtpsa instead of P=esmtpa. Depending upon which
authentication protocol is used, you might be permitting cleartext
passwords to travel across the network.
You can ensure that a given authenticator is only offered (and therefore
available) over an encrypted link with:
server_advertise_condition = ${if def:tls_cipher}
> Also, how can I disable exim's SMTP services for unix user accounts
> such as admin?
By default in Exim, no system accounts or any other account is
configured to be allowed to authenticate to send mail. So some
authenticator ("fixed_login" here, perhaps others) is explicitly
checking passwords and permitting system logins, perhaps using PAM.
You use the server_condition option on an authenticator. For plaintext
authenticators, this is what determines if authentication succeeds at
all and you can make it a bit more complicated with and{{..}{..}} inside
the ${if...}. For other authenticators, this defines additional checks
which happen after authentication succeeds, so it's purely an
authorisation filter.
-Phil
