Mailing List Archive

smtp_accept_max & DDoS
Hi,

i wonder about DDoS, i will try explain why in more descriptive,
please aproximate my English...

I have separate MSA exim, it autentificates users against dovecot
and i use dovecot's Auth Policy daemon to do some checks before
ligin itself.

I am facing many login attempts (attacks) from ~100-200 different
IPs daily, without any pattern in country/ASN/IP block. Most of them
is properly identified by mentioned Auth Policy daemon, which
prevents to real login. The dovecot shows in its logs something as
"drop connection". That all works as excpected when IMAP login
attempts happens.

The problem is in exim. It gets (logs) "authenticator failed ..." line,
that line contains "535 Incorrect authentication data ..." too. Then
it responds that (i guess) to client, which never responds. The
connection is then hold open, until timeout happens (in my case
i lowered it to 60 sec). As attackers does that login attempts in
waves 10-15 IPs in short time, here are multiple connections
openned until timeout happens.

They repeats login from the same IP only after relative long time
(in days), thus blocking in FW doesn't solves that. I have some
thousands IP in FW already, its count grows and currently blocks
about 40-60 % of connections, but still many new IPs appears and
that happens for about 2 years. I do not know if it is one or more
attackers (bothets), but i guess that more groups trying me.

By docs, the default smtp_accept_max is 20, i have set it higher
value already, but that doesn't matter, as i see that attacker has
many thousands IPs available. Thus i wonder, that it is able to reach
that limit if it will want anytime, just by opening many connections
and abandon them, thus effective run DDoS against MSA. I didn't
meet that DDoS yet, but i wonder about it -- is my wondering
real or am i too paranoid?

I cannot find way, how to follow mentioned "drop connection" from
Auth Policy daemon from authentificator, thus how to drop connection
on **some** login attempts. I do not know if that is even possible,
nor in exim, nor in dovecot. Please, is here way to drop these policy
blocked logins to prevent connection timeouts?

Please, wonder/meet that someone other too?

regards

--
Slavko
https://www.slavino.sk/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
> To: exim-users @ lists.exim.org

~ $ dig lists.exim.org mx
;; QUESTION SECTION:
;lists.exim.org. IN MX

;; ANSWER SECTION:
lists.exim.org. 294 IN CNAME cumin.exim.org.
cumin.exim.org. 300 IN MX 10 cumin.exim.org.

In my home computer (with FreeBSD) by default the MSA is sendmail, I suppose
it "canonicalizes" the hostname before submission to my MTA on my VPS (Exim).

2023-05-12 00:24:49 +0300
H=cumin.exim.org [37.120.190.30]
SMTP error from remote mail server after RCPT TO:<exim-users @ cumin.exim.org>: 550 unknown user

In my home computer I had to add to /usr/local/etc/unbound/unbound.conf :

local-data: "lists.exim.org MX 10 cumin.exim.org"

> From: Slavko <linux@slavino.sk>

> The problem is in exim. It gets (logs) "authenticator failed ..." line,
> that line contains "535 Incorrect authentication data ..." too. Then
> it responds that (i guess) to client, which never responds. The
> connection is then hold open, until timeout happens (in my case
> i lowered it to 60 sec). As attackers does that login attempts in
> waves 10-15 IPs in short time, here are multiple connections
> openned until timeout happens.

How do you know that connection is held open and timeout happens?
I seldom see that in my logs.
During last 30 days I see (logged in notquit ACL)
3867 connection-lost and 63 command-timeout events
after authentication failed.
In my config:

smtp_max_synprot_errors = 0
WARNTO = Lena@lena.kiev.ua
SHELL = /bin/sh
ADDRNAME = $sender_host_address $acl_c_country ${sg{${lookup dnsdb{>, defer_never,ptr=$sender_host_address}}}{\N[^\w.,-]\N}{}}
chunking_advertise_hosts =
slow_lookup_log = 1500
auth_advertise_hosts = ${if eq{$sender_helo_name}{ylmf-pc}{}{*}}
log_timezone
smtp_accept_max = 15
smtp_accept_max_nonmail = 9
log_selector = +smtp_confirmation +queue_time +queue_time_overall \
+deliver_time +receive_time -retry_defer \
+smtp_incomplete_transaction +smtp_no_mail +incoming_interface
acl_smtp_connect = acl_check_connect
acl_smtp_helo = acl_check_helo
acl_smtp_auth = acl_check_auth
acl_smtp_mail = acl_check_mail
acl_smtp_quit = acl_check_quit
acl_smtp_notquit = acl_check_notquit
host_lookup = *
rfc1413_hosts = *
rfc1413_query_timeout = 2s
HELODETAINTED = ${sg{$sender_helo_name}{\N[^\w.,-]\N}{}}
# these two masks are used only in case of IPv6:
# how many IPv6 addresses you give to your single user:
MASKL = ${if match{$sender_host_address}{:}{/64}}
# how many external IPv6 addresses you treat as one attacker:
MASKW = ${if match{$sender_host_address}{:}{/56}}
...
begin acl
...
acl_check_connect:
drop message = $sender_host_address locally blacklisted for a bruteforce \
auth (login+password) cracking attempt
condition = ${if exists{$spool_directory/blocked_IPs}}
condition = ${lookup{$sender_host_address}iplsearch\
{/var/..$spool_directory/blocked_IPs}{1}{0}}
drop message = stretchoid and similar scanners banned
condition = ${if match\
{${lookup dnsdb{defer_never,ptr=$sender_host_address}}}\
{\N\.(stretchoid.com|shodan.io|internet-research-project.net|binaryedge.ninja|tchelebi.io|alphastrike.io|airtelbroadband.in|proxy-research.com)$\N}}

accept

acl_check_helo:
...
drop message = suspicious client with helo=$sender_helo_name \
locally blacklisted
condition = ${if eq{$sender_helo_name}{ylmf-pc}}
acl = setdnslisttext
condition = ${if match{$acl_c_country}{(?i)br|cn|vn}}
continue = ${run{SHELL -c 'echo \\\"$sender_host_addressMASKW\\\" \
>>$spool_directory/blocked_IPs'}}

drop message = suspicious client with helo=$sender_helo_name \
locally blacklisted
condition = ${if match{$sender_helo_name}\
{\N^(ganymede|ylmf-pc|\*\.\*|\[192\.168\.2\.33\])$\N}}
acl = setdnslisttext
continue = ${run{SHELL -c 'echo \\\"$sender_host_addressMASKW\\\" \
>>$spool_directory/blocked_IPs; \
\N{\N echo Subject: HELODETAINTED. blocked ADDRNAME; \
echo; echo for bruteforce auth cracking attempt.; \
\N}\N | $exim_path -f root WARNTO'}}

accept

acl_check_auth:
drop message = authentication is allowed only once per message in order \
to slow down bruteforce cracking
set acl_m_auth = ${eval10:0$acl_m_auth+1}
condition = ${if >{$acl_m_auth}{2}}
delay = 22s

drop message = blacklisted for bruteforce cracking attempt
set acl_c_authnomail = ${eval10:0$acl_c_authnomail+1}
condition = ${if >{$acl_c_authnomail}{4}}
condition = ${if exists{$spool_directory/blocked_IPs}\
{${lookup{$sender_host_address}iplsearch\
{$spool_directory/blocked_IPs}{0}{1}}}\
{1}}
acl = setdnslisttext
continue = ${run{SHELL -c 'echo \\\"$sender_host_addressMASKW\\\" \
>>$spool_directory/blocked_IPs; \
\N{\N echo Subject: blocked ADDRNAME; echo; echo \
for bruteforce auth cracking attempt.; \
\N}\N | $exim_path -f root WARNTO'}}

drop message = blacklisted for bruteforce cracking attempt
condition = ${if >{$acl_c_authnomail}{4}}

accept set acl_c_authhash = ${if match{$smtp_command_argument}\
{\N(?i)^(?:plain|login) (.+)$\N}{${nhash_1000:$1}}}

acl_check_mail:
deny message = 503 Bad sequence of commands - must send HELO/EHLO first
condition = ${if !def:sender_helo_name}

accept set acl_c_authnomail = 0

setdnslisttext:
accept dnslists = all.ascc.dnsbl.bit.nl
set acl_c_country = ${if match{$dnslist_text}{ CC=(\\S+) }{$1}}

accept

acl_check_quit:
accept condition = $authentication_failed
logwrite = :reject: quit after authentication failed: \
${sg{$sender_rcvhost}{\N[\n\t]+\N}{\040}}
acl = setdnslisttext
condition = ${if match{$acl_c_country}{(?i)br|cn|vn}}
continue = ${run{SHELL -c 'echo \\\"$sender_host_addressMASKW\\\" \
>>$spool_directory/blocked_IPs'}}

warn condition = $authentication_failed
dnslists = auth.spamrats.com
# http://spamrats.com/rats-auth.php , http://spamrats.com/about.php
condition = ${if exists{$spool_directory/blocked_IPs}\
{${lookup{$sender_host_address}iplsearch\
{$spool_directory/blocked_IPs}{0}{1}}}\
{1}}
acl = setdnslisttext
continue = ${run{SHELL -c 'echo \\\"$sender_host_addressMASKW\\\" \
>>$spool_directory/blocked_IPs; \
\N{\N echo Subject: spamrats. blocked ADDRNAME; \
echo; echo for auth cracking attempt.; \
\N}\N | $exim_path -f root WARNTO'}}

warn condition = $authentication_failed
condition = ${if match{$sender_helo_name}\
{\N^(User|xray500|FlapJack|gerg|smtp.lena.kiev.ua)$\N}}
condition = ${if exists{$spool_directory/blocked_IPs}\
{${lookup{$sender_host_address}iplsearch\
{$spool_directory/blocked_IPs}{0}{1}}}\
{1}}
acl = setdnslisttext
continue = ${run{SHELL -c 'echo \\\"$sender_host_addressMASKW\\\" \
>>$spool_directory/blocked_IPs; \
\N{\N echo Subject: HELODETAINTED. blocked ADDRNAME; \
echo; echo for auth cracking attempt.; \
\N}\N | $exim_path -f root WARNTO'}}

warn condition = $authentication_failed
condition = ${if def:acl_c_authhash}
ratelimit = 0 / 5m / strict / $sender_host_address-$acl_c_authhash
set acl_c_hashrate = ${sg{$sender_rate}{[.].*}{}}

warn condition = $authentication_failed
condition = ${if or{\
{!def:acl_c_authhash}\
{<{$acl_c_hashrate}{2}}\
}}
ratelimit = 7 / 5m / strict / per_conn
condition = ${if exists{$spool_directory/blocked_IPs}\
{${lookup{$sender_host_address}iplsearch\
{$spool_directory/blocked_IPs}{0}{1}}}\
{1}}
acl = setdnslisttext
continue = ${run{SHELL -c 'echo \\\"$sender_host_addressMASKW\\\" \
>>$spool_directory/blocked_IPs; \
\N{\N echo Subject: blocked ADDRNAME; echo; echo \
for bruteforce auth cracking attempt.; \
\N}\N | $exim_path -f root WARNTO'}}

acl_check_notquit:
accept condition = $authentication_failed
logwrite = :reject: $smtp_notquit_reason after authentication failed: \
${sg{$sender_rcvhost}{\N[\n\t]+\N}{\040}}
acl = setdnslisttext
condition = ${if match{$acl_c_country}{(?i)br|cn|vn}}
continue = ${run{SHELL -c 'echo \\\"$sender_host_addressMASKW\\\" \
>>$spool_directory/blocked_IPs'}}

warn condition = $authentication_failed
dnslists = auth.spamrats.com
# http://spamrats.com/rats-auth.php , http://spamrats.com/about.php
condition = ${if exists{$spool_directory/blocked_IPs}\
{${lookup{$sender_host_address}iplsearch\
{$spool_directory/blocked_IPs}{0}{1}}}\
{1}}
acl = setdnslisttext
continue = ${run{SHELL -c 'echo \\\"$sender_host_addressMASKW\\\" \
>>$spool_directory/blocked_IPs; \
\N{\N echo Subject: spamrats. blocked ADDRNAME; \
echo; echo for auth cracking attempt.; \
\N}\N | $exim_path -f root WARNTO'}}

warn condition = $authentication_failed
condition = ${if match{$smtp_notquit_reason}\
{^(connection-lost|synchronization-error)}}
condition = ${if match{$sender_helo_name}\
{\N^(User|xray500|FlapJack|gerg|SERVER-KP1|((mail|smtp)\.)?(lena\.kiev|(ksana|sergej)\.org)\.ua)$\N}}
!hosts = @[]
condition = ${if exists{$spool_directory/blocked_IPs}\
{${lookup{$sender_host_address}iplsearch\
{$spool_directory/blocked_IPs}{0}{1}}}\
{1}}
acl = setdnslisttext
continue = ${run{SHELL -c 'echo \\\"$sender_host_addressMASKW\\\" \
>>$spool_directory/blocked_IPs; \
\N{\N echo Subject: HELODETAINTED. blocked ADDRNAME; \
echo; echo for auth cracking attempt.; \
\N}\N | $exim_path -f root WARNTO'}}

warn condition = $authentication_failed
condition = ${if def:acl_c_authhash}
ratelimit = 0 / 2h / strict / $sender_host_address-$acl_c_authhash
set acl_c_hashrate = ${sg{$sender_rate}{[.].*}{}}

warn condition = $authentication_failed
condition = ${if match{$smtp_notquit_reason}\
{^(connection-lost|synchronization-error)}}
condition = ${if or{\
{!def:acl_c_authhash}\
{<{$acl_c_hashrate}{2}}\
}}
ratelimit = 7 / 2h / strict / per_conn
condition = ${if exists{$spool_directory/blocked_IPs}\
{${lookup{$sender_host_address}iplsearch\
{$spool_directory/blocked_IPs}{0}{1}}}\
{1}}
acl = setdnslisttext
continue = ${run{SHELL -c 'echo \\\"$sender_host_addressMASKW\\\" \
>>$spool_directory/blocked_IPs; \
\N{\N echo Subject: blocked ADDRNAME; echo; echo \
for bruteforce auth cracking attempt.; \
\N}\N | $exim_path -f root WARNTO'}}

hash:
accept set acl_c_authhash = ${nhash_1000:$acl_arg1}

...
begin authenticators

plain:
driver = plaintext
public_name = PLAIN
server_prompts = :
server_condition = ${if pam{$auth2:${sg{$auth3}{:}{::}}}}${acl{hash}{$auth2,$auth3}}
client_send = ^${extract{user}{$address_data}{$value}fail}^${extract{pass}{$address_data}{$value}fail}
server_set_id = $2

login:
driver = plaintext
public_name = LOGIN
server_prompts = "Username:: : Password::"
server_condition = ${if pam{$auth1:${sg{$auth2}{:}{::}}}}${acl{hash}{$auth1,$auth2}}
server_set_id = $1


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
D?a 12. mája 2023 4:07:51 UTC používate? Lena--- via Exim-users <exim-users@lists.exim.org> napísal:

>How do you know that connection is held open and timeout happens?

From logs, eg:

2023-05-12 00:45:57 H=[52.176.51.76] Connected CC=US con=1
2023-05-12 00:46:06 dovecot_login authenticator failed for ([52.176.51.76]) [52.176.51.76]: 535 Incorrect authentication data (set_id=...)
2023-05-12 00:47:06 SMTP command timeout on TLS connection from ([52.176.51.76]) [52.176.51.76]
2023-05-12 00:47:06 H=[52.176.51.76] NotQ command-timeout CC=US EHLO,AUTH

And confirmed by netstat, when i am lucky to watch it
in that time...

>I seldom see that in my logs.
>During last 30 days I see (logged in notquit ACL)
>3867 connection-lost and 63 command-timeout events

My numbers/ratio are opposite.

I initially blame my FW, which block these attempts, but
some time ago i moved that rule after ESTABLISHED accept
without significant ratio change, thus seems that FW is/was
not root of problems...

BTW, i have simillar ACL to drop on second login after
failed one (on the same connection), but these second
attempts are very rare here...

regards


--
Slavko
https://www.slavino.sk/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
On 11/05/2023 18:28, Slavko via Exim-users wrote:
> By docs, the default smtp_accept_max is 20, i have set it higher
> value already, but that doesn't matter, as i see that attacker has
> many thousands IPs available. Thus i wonder, that it is able to reach
> that limit if it will want anytime, just by opening many connections
> and abandon them, thus effective run DDoS against MSA. I didn't
> meet that DDoS yet, but i wonder about it -- is my wondering
> real or am i too paranoid?

The _max option is there to cap the load imposed on the system;
a DDOS is possible whether you have that cap or not (though a
DOS become easier if you limit to lower than the ultimate
system capability). It's not related to authentication,
really, unless your system *only* handles MSA work.

One might imagine a per-port cap... but the implementation
feels problematic at first glance; you really don't want to
be doing an expensive expansion in the daemon loop.

> is here way to drop these policy
> blocked logins to prevent connection timeouts

If your authenticator has an expansion which determines this
policy condition, what happens if you use an acl expansion
component which does a "drop"? I've not tried this; no
idea if if functions.
--
Cheers,
Jeremy


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
D?a 12. mája 2023 11:56:18 UTC používate? Jeremy Harris via Exim-users <exim-users@lists.exim.org> napísal:

>The _max option is there to cap the load imposed on the system;
>a DDOS is possible whether you have that cap or not (though a
>DOS become easier if you limit to lower than the ultimate
>system capability). It's not related to authentication,
>really, unless your system *only* handles MSA work.

I understad (i hope) that already. The DDoS i mean is not
load based, as connection limit will happen early. Most of
load on that host happens on email delivery (dovecot's
full text search indexing). I talk about DDoS based on
connections count by keeping open these pontless failed
logins attemts.

Defaults are 20 concurent connections and 5min timeout,
that limit can be easy reached with 1 conn per 15 sec,
keeping it open for that timeout. If one has botnet with
1000 IPs it can keep all server's connections up for more
than 4 hours without repeating from the same IP. Or in
other words, it can connect from one IP only once per
~4 hours and keep connections busy for long time, not
allowing to connect from real hosts... And that repeating
rate will remain unnoticed by many IDS/IPS... Or am i
wrong?

If we can prevent that timeout, the IP count or repeating
rate must be much higher to achieve the same result.
DDoS still possible, but less simple and better to detect...

Currently i have concurent connections under 5 all time,
as attacker mostly waits to get response and then try
from another IP after small pause. I have some delays too,
but they are conditional, if connections cross 25% of limit,
the delays drops to 0s, but that is really rare.

>One might imagine a per-port cap... but the implementation
>feels problematic at first glance; you really don't want to
>be doing an expensive expansion in the daemon loop.

No, that is not what i need. That host does MSA for public
access and MDA for my MX. The host_reserve (and so)
are enough for me yet. The MX (MTA) is on another host...
Beside the fact that i have public access to ports separated,
it is more simple to maintain ACLs (and others) for me.

>If your authenticator has an expansion which determines this
>policy condition, what happens if you use an acl expansion
>component which does a "drop"? I've not tried this; no
>idea if if functions.

Do you mean the server_condition option? AFAIK it will
not work with dovecot autentificator, as it is consulted
only after success authentification. Or do you mean
something else?

I know, that recently was added auth failed event, but it
is not in my version (4.94) yet, and i am not sure if it will
help with drop connection, as it is not documented in
current docs yet.

Anyway, i do not know if exim gets some extra info from
dovecot autentificator, which one can parse. I do not
know if dovecot pass it... Know someone that?

regards


--
Slavko
https://www.slavino.sk/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
On 12/05/2023 14:43, Slavko via Exim-users wrote:
> I understad (i hope) that already. The DDoS i mean is not
> load based, as connection limit will happen early.

and a botnet will be able to exceed that limit,
whether doing your auth thing or not.
But, whatever...

> Do you mean the server_condition option? AFAIK it will
> not work with dovecot autentificator, as it is consulted
> only after success authentification. Or do you mean
> something else?
>
> I know, that recently was added auth failed event, but it
> is not in my version (4.94) yet, and i am not sure if it will
> help with drop connection, as it is not documented in
> current docs yet.

Indeed, with the dovecot authenticator and that version of Exim
I don't think there's anything special you can do if you can't
fingerprint these connections in some way.
Your short setting for smtp_receive_timeout is probably the best
way (despite violating standards).

As a future-version possibility, I wonder if a settable TCP keepalive
would work. It depends on whether the attacker really has abandoned
the TCP connection, though this seems likely. Default values are in
the two hours region, so not immediately helpful.
--
Cheers,
Jeremy


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
D?a 12. mája 2023 14:36:23 UTC používate? Jeremy Harris via Exim-users <exim-users@lists.exim.org> napísal:

>Your short setting for smtp_receive_timeout is probably the best
>way (despite violating standards).

IMO that standars violating is not true, RFC 6409 allows shorting
SMTP timeouts for MSA, it doesn't strictly defines them, only
suggests 2-5 mins...

Anyway, thanks for suggestions ;-)

regards


--
Slavko
https://www.slavino.sk/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
Am 12.05.23 um 17:23 schrieb Slavko via Exim-users:
> D?a 12. mája 2023 14:36:23 UTC používate? Jeremy Harris via Exim-users <exim-users@lists.exim.org> napísal:
>
>> Your short setting for smtp_receive_timeout is probably the best
>> way (despite violating standards).
> IMO that standars violating is not true, RFC 6409 allows shorting
> SMTP timeouts for MSA, it doesn't strictly defines them, only
> suggests 2-5 mins...
>
> Anyway, thanks for suggestions ;-)
>
> regards
>
>

It's easy to detect if someone if blocking your exim:

Loop over :

1. Getting all ID-Tripples

netstat -lnap | grep exim | grep <INSERT WORD CONNECTED IN YOUR SYSLANG
HERE>   | awk '{print $5":"$7;}' | sed -e "s/\/exim//g"

87.123.20.215:36858:1127858
87.123.20.215:36834:1127839
87.123.20.215:36844:1127849

You now have the identifing tripple, it's highly unlikely, next to
impossible to get the same tripple of ip:port:processid again.

2. Check them against a HASH with the tripple as key and a timestamp as
value

3. if tripple is not in hash , put in with now() as timestamp
    if tripple is in hash, check if timestamp is xxx seconds old, end
exim with "kill $pid" and "iptables -A smtpattacker -s $IP -j DROP"

4. if you find tripples in the hash, that are not in the actual set of
tripples from step 1 , remove them from hash.

5. Sleep 10s

End Loop

I suggest to choose your timeout for the kill wisely, as some servers
send a big chunk of data slow as hell, but a reasonable amount would be 30s.
In addition, the netstat output could give out, if any data is in the
connection buffer as an indicator that the host as send real data as an
indication for a valid connection attempt.


best regards,
Marius

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
7On Sat, 13 May 2023, Cyborg via Exim-users wrote:

> It's easy to detect if someone if blocking your exim:
>
> Loop over :
>
> 1. Getting all ID-Tripples
>
> netstat -lnap | grep exim | grep <INSERT WORD CONNECTED IN YOUR SYSLANG
> HERE>   | awk '{print $5":"$7;}' | sed -e "s/\/exim//g"
>
> 87.123.20.215:36858:1127858
> 87.123.20.215:36834:1127839
> 87.123.20.215:36844:1127849
>
> You now have the identifing tripple, it's highly unlikely, next to
> impossible to get the same tripple of ip:port:processid again.

I think those three values are all available within exim.
Since the issue is after a failed auth, can you do something
with them after an appropriate test in the auth acl ?
Possibilities include:
1. logging, and having a reaper daemon watching the logs
and killing any of these processes that survive a delay.
2. using ${run} or exim's perl process to start a script
which delays snd then kills the pid.

> 2. Check them against a HASH with the tripple as key and a timestamp as
> value
>
> 3. if tripple is not in hash , put in with now() as timestamp
>     if tripple is in hash, check if timestamp is xxx seconds old, end exim
> with "kill $pid" and "iptables -A smtpattacker -s $IP -j DROP"
>
> 4. if you find tripples in the hash, that are not in the actual set of
> tripples from step 1 , remove them from hash.
>
> 5. Sleep 10s
>
> End Loop
>
> I suggest to choose your timeout for the kill wisely, as some servers send
> a big chunk of data slow as hell, but a reasonable amount would be 30s.
> In addition, the netstat output could give out, if any data is in the
> connection buffer as an indicator that the host as send real data as an
> indication for a valid connection attempt.

By logging or triggering this in an ACL and only when the problem occurs
we avoid the case of slow but valid incoming connections.

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
Am 13.05.23 um 11:41 schrieb Andrew C Aitchison:
>
>> I suggest to choose your timeout for the kill wisely, as some servers
>> send a big chunk of data slow as hell, but a reasonable amount would
>> be 30s.
>> In addition, the netstat output could give out, if any data is in the
>> connection buffer as an indicator that the host as send real data as
>> an indication for a valid connection attempt.
>
> By logging or triggering this in an ACL and only when the problem occurs
> we avoid the case of slow but valid incoming connections.
>


I'm afraid, you can only test things in an acl, IF new connections are
coming in, which the DDOS open-connection-attack would deny.

This needs to be external, or it's useless when you need it :)

Best regards,
Marius

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
D?a 13. mája 2023 8:50:26 UTC používate? Cyborg via Exim-users <exim-users@lists.exim.org> napísal:

>I suggest to choose your timeout for the kill wisely, as some servers send a big chunk of data slow as hell, but a reasonable amount would be 30s.

As i have separate MSA, would not be more easy to setup
that timeout right in exim? Will not this have the same effect?...

As there is AuthPolicy daemon in action, filling FW is done
by fail2ban parsing its logs. That allow me distinguish
auth rejection reason in more precise way than simple
success/fail in exim, beside the fact, that fail2ban
provides repeat counting, ban persistance -- and unban
of course (as many of them seems to be end users, from
time to time cleaned infection and/or changed IP).

regards


--
Slavko
https://www.slavino.sk/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
On Sat, 13 May 2023, Slavko via Exim-users wrote:

> D?a 13. mája 2023 8:50:26 UTC používate? Cyborg via Exim-users <exim-users@lists.exim.org> napísal:
>
>> I suggest to choose your timeout for the kill wisely, as some servers send a big chunk of data slow as hell, but a reasonable amount would be 30s.
>
> As i have separate MSA, would not be more easy to setup
> that timeout right in exim? Will not this have the same effect?...

I don't think we can do the kill from within exim.
We may be able to get exim to fork a process that waits and then kills the
stuck process, but once it it stuck a process cannot kill itself.

If we can reduce
smtp_receive_timeout
in the auth acl and increase it again in the data acl,
will that stop the process getting stuck ?

I would still like to know where the delay is actually happening;
currently I guess it is somewhere in the authentication.
In the simplest case the username and credentials (password)
are included in the request and the data is local, so there is no
potential for delay and hence no timeout option for authentication
(that I can find), but challenge-response and using the dovecot
authenticator both introduce conversations which could cause delays
and require timeouts.
Are you using the dovecot authenticator ?

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
D?a 12. mája 2023 14:36:23 UTC používate? Jeremy Harris via Exim-users <exim-users@lists.exim.org> napísal:

>Indeed, with the dovecot authenticator and that version of Exim
>I don't think there's anything special you can do if you can't
>fingerprint these connections in some way.

I did simplifíed adaption of python dovecot's SASL client
(available on PyPi) to do auth over unix socket and when
AuthPolicy rejects authentication, dovecot returns reason
from it in "reason" arg. If authentication fails (i tested
nonexistent user), the reason is not in response at all.

Thus exim can get it, but does it that? I guess that it doesn't
do that, perhaps because its AuthPolicy is relative new and
not widely used...

regards


--
Slavko
https://www.slavino.sk/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
On 13/05/2023 12:55, Andrew C Aitchison via Exim-users wrote:
> I would still like to know where the delay is actually happening;
> currently I guess it is somewhere in the authentication.

No, the client has tried an auth command which we responded "fail"
to, and then the client abandoned the TCP connection without
bothering to close it (let alone QUIT the SMTP layer session,
or (I expect) properly terminate the TLS session).
Because that's the cheap thing for an attacher to do.
Meantime, we're waiting for the next SMTP connand from the
client, because per SMTP standards the ball is in their court.

The delay is our SMTP command timeout. It is currently our
way of detecting this behaviour.

We could
- manipulate the SMTP command timeout, as you suggest
- run a shorter TCP keepalive probe delay. When it fires,
we hope to get a RST back from our first probe, assuming
a normal TCP stack at their end. But they could be running
a custom, so also reduce the number of probe tries before
we declare the TCP connection dead.
- Unilaterally send some probe data, again to try to elicit
a RST. This would be violating the SMTP protocol.
Perhaps a 421 SMTP response?
- Somehow exempt cnnection in this state from the
smtp_accept_max counting
--
Cheers,
Jeremy

I wish there was an IOCTL to send a keepalive probe.


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
D?a 13. mája 2023 11:55:36 UTC používate? Andrew C Aitchison via Exim-users <exim-users@lists.exim.org> napísal:

>I don't think we can do the kill from within exim.

But is that needed? When timeout happens, socket is closed
and process ends.

>We may be able to get exim to fork a process that waits and then kills the stuck process, but once it it stuck a process cannot kill itself.

IMO when process stucks, that must be bug, the timeouts are
generally supposed to prevent processes to remain running
forever. Othervise we will have serious problem, as
connections can be lost in normal conditions too, especially
with nowadays as common mobile devices...

>I would still like to know where the delay is actually happening;

In my case, for "suspicious" connections i apply small delay
on every command. In case of normal auth it is in connect
ACL, HELO ACL and AUTH ACL (conditionaly based on
connections count).

Then delay happens on dovecot side, first is not explicit
delay, but AuthPolicy processing, where eg. DNS queries
can delay result, i have configured 6 sec timeout for response,
but almost all are finished under 4 secs, with 95 percentil
in hundreds milisecs. Then dovecot penalty happens if no
nopenalty (or so) arg was passed (which seems to be exim's
case, as i see 2 sec delay betveen lines in dovecot & exim
log lines). These dovecot's delays are always here if auth
fails...

Of course, AuthPolicy deamon can return reply with
explicit delay, but i don't use that.

As most of discussed connections are recognized as
"suspicious" and its count is not too high yet, the connection
tooks at least 8 sec until it gets failed auth response...

If connection is not suspicious and auth was success,
that tooks only some hundreds msecs in most cases,
including DNS queries and password hashing.

regards


--
Slavko
https://www.slavino.sk/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
Please create DNS records instead of CNAME:

lists.exim.org. 300 IN MX 10 lists.exim.org.
lists.exim.org. 300 IN A 37.120.190.30

Or accept emails to lists sent to <listname @ cumin.exim.org> .

Else some people trying to post to lists get "unknown user"
because sendmail "canonicalises" hostnames.

> From: Andrew C Aitchison

> If we can reduce
> smtp_receive_timeout
> in the auth acl and increase it again in the data acl,
> will that stop the process getting stuck ?

smtp_receive_timeout is expanded in smtp_setup_msg function in smtp_in.c
at the start of a SMTP session.

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
On 13/05/2023 14:03, Jeremy Harris via Exim-users wrote:
> We could
> - manipulate the SMTP command timeout, as you suggest

It turns out to be not much code to add an ACL control
which modifies the timeout. Would that be of use for
this case, and is it worth the feature-creep?

The docs entry goes:

This control changes the current values for receive timeout,
originally set by the &%smtp_receive_timeout%& or &%receive_timeout%&
main config option (or commandline equivalents).
Both values are changed, for the current receive process
(which could handle multiple messages off a single connection, if SMTP).

--
Cheers,
Jeremy


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
D?a 13. mája 2023 18:01:43 UTC používate? Jeremy Harris via Exim-users <exim-users@lists.exim.org> napísal:
>On 13/05/2023 14:03, Jeremy Harris via Exim-users wrote:
>> We could
>> - manipulate the SMTP command timeout, as you suggest
>
>It turns out to be not much code to add an ACL control
>which modifies the timeout. Would that be of use for
>this case, and is it worth the feature-creep?

I can imagine how one can use it, eg. i would add it into
ACL where i disable pipeline on MX in some conditions.
I can imagine, that control as useful in some reject
conditions too.

But in the case of failed auth we are back in problem
processing of that failed auth in dovecot autenticator.
When i will know, that host is bad (and sometime i know
that) i will reject/drop it before it reach aurh. I am not
sure if i want to set it on suspicious connections, as these
can be not bad in real and be on bad connection/link.

IMO great can be, if something as this would be
autenticator option, in mean of set timeout in
failed auth case, ideally expandable...

Or can this control be set from failed auth event
named ACL?

regards


--
Slavko
https://www.slavino.sk/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
On 13/05/2023 20:24, Slavko via Exim-users wrote:
> Or can this control be set from failed auth event
> named ACL?
Yes.
--
Cheers,
Jeremy


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
D?a 13. mája 2023 19:59:24 UTC používate? Jeremy Harris via Exim-users <exim-users@lists.exim.org> napísal:
>On 13/05/2023 20:24, Slavko via Exim-users wrote:
>> Or can this control be set from failed auth event
>> named ACL?
>Yes.

nice ;-)



--
Slavko
https://www.slavino.sk/

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: smtp_accept_max & DDoS [ In reply to ]
On 13/05/2023 19:01, Jeremy Harris via Exim-users wrote:
> Would that be of use for
> this case, and is it worth the feature-creep?

Having heard no additional support, it seems not.
--
Cheers,
Jeremy


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/