Am Donnerstag, den 04.06.2009, 18:27 +0200 schrieb Steve:
The Idea is good but I guess an option to just disconnect the attacker wouldn't hurt in the config file?
Is that not the wrong approach? I mean: all you wanted is to have a log entry showing when there was a username/password mismatch when logging in. And you found out that with normal logging options that log entry only shows up if the connection get's disconnected. Right? So would it not be better to have an option to log ANY username/password login mismatch even if the user/attacker does not disconnect?
Right, logging a wrong username/password should always be done. That's one reason why I favor a disconnect. Almost any service logs a disconnect - so does dovecot.
This would be much easier to detect/monitor on an upfront firewall/IDS.
A disconnect on TCP/IP level is easier to detect/monitor? How? Without logging or without inspecting the communication channel you are pretty much lost. Correct me if I am wrong.
Any serious firewall those days has the capability to track the amount of connection attempts on any port without knowing whats in the packet. By just delaying the next try within the service the firewall would have to inspect the packets to know whats going on. So by disconnecting an intruder (and forcing him to reconnect) its easy to detect such an attack on the firewall/IDS by just counting the amount of connects in a given timeframe. Within iptables for example this can accomplished with "--hashlimit 5/Minute".
Henry