Re: under another kind of attack

[Joseph Tam]

(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)

[Ian Turley]

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

[Olaf Hopp]

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

[Olaf Hopp]

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