Re: under another kind of attack
(I think I am testing other readers' patience, so if you want to follow-up, you can Email me directly.) but how often do you have to type your username ? Not often, but I'm not talking the typical case. The larger the population you serve, the more circumstances you'll have to cover. Only on the initial config of your mailer. After that you are done. Mail reader setups by users is often an error prone process, judging from the number of times I have to correct a setup. This is especially true for an educational institution that typically has a large turnover of accounts. If a user gets it initially wrong, then fixes their mistake, they can't get it to work despite trying all sorts of config variations, not realizing it can't be resolved anymore. Result: trouble call. If someone blows it setting on a multi-user workstation, other users with a working setups can't log in. Result: trouble call. If a student flubs their credentials, all the roommates behind their residential NAT gateway suffer. Result: trouble call. If a user screws up using an external service that slurps their mail (e.g. Gmail, Yahoo, uniboxapp, etc.), or worse, someone malicious does it on puropse, all other users of this service will be DoS'd. Result: trouble call(s). If a user acquires a DHCP address in a polluted network ..., well you get the idea. Not to mention ex-users who forget to remove their mail accounts from their smartphones, leaving a trail of blacklist entries in their wake as they travel from coffee shops to other public WiFi hotspots. So this is why I decided to use two distinct jails with different policies. It seems to work reasonable well. Until it doesn't. If it works for you, more power to you. The cost/benefit of a hair-trigger blacklist policy is that it saves you a few log entries showing futile attempts at finding weak passwords (because you have strong passwords, don't you?) at the risk of dealing with any of the above situations. Joseph Tam
Issue on install - file mbox-sync.c: line 1371 (mbox_sync_handle_eof_updates): assertion failed: (trailer_size <= 2)
First of all apologies for using such an old version - I am trying to upgrade slowly and have had to go through this version first. As you can see I am getting an error in the log file as : file mbox-sync.c: line 1371 (mbox_sync_handle_eof_updates): assertion failed: (trailer_size <= 2) Raw backtrace: imap [0x80acdc1] -> imap [0x80accdc] -> imap(mbox_sync+0x14e9) [0x8079a29] -> imap(mbox_storage_sync_init+0x3e) [0x8079d8e] -> imap(imap_sync_nonselected+0x1c) [0x806183c] -> imap(_cmd_select_full+0xc3) [0x8059983] -> imap(cmd_select+0x19) [0x8059b49] -> imap [0x805afb8] -> imap [0x805b03c] -> imap(_client_input+0x6c) [0x805b71c] -> imap(io_loop_handler_run+0x110) [0x80b2a50] -> imap(io_loop_run+0x1c) [0x80b1f8c] -> imap(main+0x4c0) [0x8063640] -> /lib/libc.so.6(__libc_start_main+0xdc) [0xdd4edc] -> imap [0x80561a1] Is this some setting missing or corrupt mailbox? I only have very basic set up at this time to test. Version 1.0.7 # 1.0.7: /etc/dovecot.conf ssl_cert_file: /etc/postfix/certs/emma.turls.co.uk.crt ssl_key_file: /etc/postfix/certs/turls_csr.key login_dir: /var/run/dovecot/login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(pop3): /usr/libexec/dovecot/pop3-login mail_location: mbox:~/mail/:INBOX=/var/spool/mail mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(pop3): /usr/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/imap mail_plugin_dir(imap): /usr/lib/dovecot/imap mail_plugin_dir(pop3): /usr/lib/dovecot/pop3 auth default: passdb: driver: pam userdb: driver: passwd Regards Ian -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: under another kind of attack
On 07/26/2017 10:01 PM, Joseph Tam wrote: Olaf Hopp wrote: And I have a new one just for "unknown user" and here my bantime and findtime are much bigger and the retries are just '2'. So here I'm much harsher. I'll keep an eye on my logs and maybe some more twaeking is necessary. Just be careful about typos (like twaeking!): users could simply misspell their username, or get mixed up with some another account or alias. This is why I favour targetting known bad accounts, not merely accounts that don't exist. Joseph, but how often do you have to type your username ? Only on the initial config of your mailer. After that you are done. Exception is my webmail server. But that IP is of course on the "ignoreip" list of fail2ban. Otherwise it would be very easy to trigger a DOS without much effort. So this is why I decided to use two distinct jails with different policies. It seems to work reasonable well. Regards, Olaf -- Karlsruher Institut für Technologie (KIT) ATIS - Abt. Technische Infrastruktur, Fakultät für Informatik Dipl.-Geophys. Olaf Hopp - Leitung IT-Dienste - Am Fasanengarten 5, Gebäude 50.34, Raum 009 76131 Karlsruhe Telefon: +49 721 608-43973 Fax: +49 721 608-46699 E-Mail: olaf.h...@kit.edu atis.informatik.kit.edu www.kit.edu KIT – Die Forschungsuniversität in der Helmholtz-Gemeinschaft Das KIT ist seit 2010 als familiengerechte Hochschule zertifiziert. smime.p7s Description: S/MIME Cryptographic Signature
Re: under another kind of attack
On 07/27/2017 05:19 AM, James Brown wrote: On 26 Jul 2017, at 7:57 pm, Olaf Hopp wrote: Dear collegues, many thanks for your valuable input. Since we are an university GEO-IP blocking is not an option for us. Somestimes I think it should ;-) My "mistake" was that I had just *one* fail2ban filter for both cases: "wrong password" and "unknown user". Now I have two distinct jails: The first one just for "wrong password" and here the findtime, bantime, retries are tolerant to typos. And I have a new one just for "unknown user" and here my bantime and findtime are much bigger and the retries are just '2'. So here I'm much harsher. I'll keep an eye on my logs and maybe some more twaeking is necessary. Another interesting observation: I activated auth_verbose_passwords = plain to log the plain password when (and only when) there is "unknown user". It reveals that all different IPs trying one unknown account always try with the same stupid password scheme 1234. So this doesn't look very well coordinated between the bots ;-) Olaf, how do you do this only for the unknown user? Can you share the Dovecot settings? I’m under the same sort of slow distributed attack. Also the two fail2ban jails would be helpful. Nothing special in the dovecot config /etc/fail2ban/jail.local [dovecot] enabled = true filter = dovecot action = iptables-multiport[name=dovecot, port="pop3,pop3s,imap,imaps,submission,465,sieve", protocol=tcp] logpath = /var/log/dovecot bantime = 600 findtime= 600 maxretry= 5 backend = auto [dovecot_unknown] ignoreip = X.X.X.0/24 enabled = true filter = dovecot_unknown action = iptables-multiport[name=dovecot_unknown, port="pop3,pop3s,imap,imaps,submission,465,sieve", protocol=tcp] logpath = /var/log/dovecot bantime = 14400 findtime= 14400 maxretry= 2 backend = auto /etc/fail2ban/filter.d/dovecot.local = [INCLUDES] before = common.conf [Definition] failregex = dovecot: auth-worker\(\d+\): pam\(.*,,\<.*\>\): pam_authenticate\(\) failed: Authentication failure \(password mismatch\?\) ignoreregex = /etc/fail2ban/filter.d/dovecot_unknown.local [INCLUDES] before = common.conf [Definition] failregex = dovecot: auth-worker\(\d+\): pam\(.*,,\<.*\>\): unknown user.* ignoreregex = The failregex lines may need adaption to your log format. "fail2ban-regex" is your friend. On my Dovecot 2.2.31 unknows user log lines are Jul 26 14:58:56 irams1 dovecot: auth-worker(2822): pam(inikul,112.54.93.34,): unknown user (given password: inikul2017) and "wrong password" lines look like this Jul 26 15:01:41 irams1 dovecot: auth-worker(3530): pam(johndoe,120.209.164.118,): pam_authenticate() failed: Authentication failure (password mismatch?) Regards, Olaf -- Karlsruher Institut für Technologie (KIT) ATIS - Abt. Technische Infrastruktur, Fakultät für Informatik Dipl.-Geophys. Olaf Hopp - Leitung IT-Dienste - Am Fasanengarten 5, Gebäude 50.34, Raum 009 76131 Karlsruhe Telefon: +49 721 608-43973 Fax: +49 721 608-46699 E-Mail: olaf.h...@kit.edu atis.informatik.kit.edu www.kit.edu KIT – Die Forschungsuniversität in der Helmholtz-Gemeinschaft Das KIT ist seit 2010 als familiengerechte Hochschule zertifiziert. smime.p7s Description: S/MIME Cryptographic Signature