Hi, It seems that courierlogin filter is just turned off in default fail2ban configuration. Recently I have been scanned by pop3 protocol, someone tried to guess logins/passwords for my mailbox, fortunately without success, but fail2ban did nothing to filter it. I think it should filter that attacker's IP by ports 25,110,143,993,995, and 465. And that reference to courierlogin filter should be included in default fail2ban config. Thank you in advance for your work.
severity 407404 wishlist retitle 407404 fail2ban: automatic enable for sections if log files exist thanks 1. I don't see why it has to be on by default: courier is not even a default MTA on the Debian system, and exim is not using courierlogin by default. Correct me if I am wrong 2. For banning multiple ports you would need to use either iptables-multiport action, or iptables with no port (actually I think it is worth adding it but then all traffic would need to go through that chain), or shorewall action. Indeed, while dealing with MTAs it is useful to ban at least smtp, and smtps. While with authenticators like courierlogin - since we don't know really where attemtp came from - then all, smtp, smtps, imap, imaps, pop, pops should be banned Ok, so now let me rephrase your bug to something which could be fixed: 1. Since debian kernel comes with multiport module for iptables - I will make iptables-multiport default one and will adjust corresponding jails to ban multiple ports. Since multiport banning is described in README.Debian I consider this of wishlist level. Cyril, do you think it is a good idea? 2. Wishlist: Cyril, it might be good to have another value for enabled - "auto". For that, fail2ban would check if there are any logfiles, and enable the jail if there is any. Optional parameter "autoage" might be introduced to enable jail only if any file is newer than specified age (like 2-3 days). That would allow to don't enable monitoring of services which are no longer active. Cyril, please let me know what you think
Hi all, Yes, it is probably a good idea. But what if multiport is not compiled in? Is it not better to simply ban every ports? However, this can be adjusted for each distribution. Nice idea :) However, this is not trivial to implement correctly ;) I had this to my TODO list for 0.9. Thank you for those idea :) Cheers, Cyril Jaquier
packet fi scrip object-o for Pyt Nó
Dear Customer, We can not deliver your parcel arrived at February 02. Please check the attachment for complete details! Your help is greatly appreciated, Ricky Weeks, UPS Chief Station Manager.
Let's try again. My first unarchive attempt on 791640 actually unarchived only 407404 (though it is merged with 791640), but this bug got archived again a few minutes later!
This is incredible! While it worked, the bugs are now again archived and closed!
OK, now https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791640 shows (again) that the bug is reopened: Control: unarchive 407404 Control: unarchive 791640 Control: reopen 407404 Control: reopen 791640 This is incredible! While it worked, the bugs are now again archived and closed! [...] ------------------------------------------------------------ but https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407404 (after a forced reload and a test with lynx and wget) shows that bug 407404 is still archived and closed (last line from 05 Mar 2017).
Each time I unarchive and reopen the bugs, someone is reverting my changes, i.e. the last line on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791640 is back to the "Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 05 Mar 2017 07:25:15 GMT)"!!! Let's reopen again...