On 28/06/13 23:33, John Fawcett wrote:
> On 28/06/13 22:30, Wietse Venema wrote:
>> Wietse Venema:
>>> John Fawcett:
>>>> I use fail2ban in order to block some types of apparently malicious
>>>> connections to postfix when the clients keep retrying. For example the
>>> As you agree logging every failed command would not be safe by
>>> default.
>>>
>>> On the other hand, logging the command name (even without) parameters
>>> for every [45]XX response could be tricky. Adding IF statements all
>>> over the code is undesirable, so this would require a structural
>>> change to the command reader and responder.
>>>
>>> What about a one-line change, such that the SMTP server logs the
>>> existing per-session error counter when the connection is closed?
>>>
>>> This counter is reset upon successful completion of a (MAIL, RCPT,
>>> DATA, end-of-data) sequence. This should be sufficient to expose
>>> clients that hammer your server with unimplemented AUTH commands.
>> Example:
>>
>> Jun 28 16:27:25 spike postfix/smtpd[65532]: disconnect from
>> camomile.cloud9.net[2604:8d00:0:1::3] error_count 0
>>
>> As per the patch below for any Postfix version ever released.
>>
>> Wietse
>>
>> *** ./src/smtpd/smtpd.c- Sun Jun 23 11:10:02 2013
>> --- ./src/smtpd/smtpd.c Fri Jun 28 16:26:41 2013
>> ***************
>> *** 4989,4995 ****
>> * After the client has gone away, clean up whatever we have set up at
>> * connection time.
>> */
>> ! msg_info("disconnect from %s", state.namaddr);
>> smtpd_state_reset(&state);
>> debug_peer_restore();
>> }
>> --- 4989,4996 ----
>> * After the client has gone away, clean up whatever we have set up at
>> * connection time.
>> */
>> ! msg_info("disconnect from %s error_count %d",
>> ! state.namaddr, state.error_count);
>> smtpd_state_reset(&state);
>> debug_peer_restore();
>> }
> Thanks Wietse
> That looks like it will do it.
I did some testing on this. For the record I added the following regex
in fail2ban:
disconnect from (.*)\[<HOST>\] error_count [^0]
Postfix is logging the errors and fail2ban is firing.
I have to admit my own error though. While I was checking this I found
some log lines further down which I had overlooked before.
Jun 28 09:04:52 rosalia postfix/smtpd[10175]: lost connection after AUTH
from 202-136-109-205.static.adam.com.au[202.136.109.205]
So seems the "attack" came in two different stages, one where there were
just connects and disconnects and then another where there were connects
AUTH and disconencts. I mismatched the evidence from the two stages. Sorry.
The "lost connection after AUTH" would have been more than adequate to
do the blocking in the case of disallowed AUTH commands. Actually now I
have to find why fail2ban didn't pick them up, but that's OT.
Thanks
John
