re: Feature Discussion: Handling large numbers of IPv6 Remote Sessions
in Anvil
Wietse wrote:
Anvil currently does not consider whether IP addresses in the same
address range. There are plenty legitimate mail servers in the
same /24 block, and I expect that IPv6 will be no different.
When the anvil daemon runs into a memory resource limit, it terminates
with a fatal error message, and it is immediately restarted by the
master daemon. It is not the end of the world.
To arrive at realistic numbers you need to take into consideration
that all anvil requests are mediated by an SMTP daemon process, and
that the SMTP daemon introduces significant latency. If you go too
fast, then you end up SYN-flooding the site.
I don't see why we can't discuss this on list.
Wietse
Thanks for the reply.
Yes, I understand there's the overhead of the smtpd first having to
contact anvil, so if everything was session set up traffic this would
indeed be equivalent to a SYN attack on the whole site.
I just wanted to have a lower bound of performance to shoot for that was
realistic for a typical 100MB fiber SME connection.
I see this as (a small) part of a layered defence, in the same way anvil
tracks at multiple levels (connect, TLS .... )
So you could potentially use this in a larger set up in combination with
multiple postfix servers, hidden MX records using BIND view, RFC7098
stateless IPv6 flow label load balancing, firewall rate filters etc. etc.
I'd just like to focus on this one area of the difference between
tracking IPv4 and IPv6 if you don't mind, as I think I might be able to
book some progress resulting in running code.
I think there's definitely a balance to be struck e.g. between being
able to defend what is a huge address space of IPv6/48 available to a
single user, and generating false positives for individual IPv6/64's
containing multiple legitimate clients (that happen to fall within a
particular /48).
I was thinking of incorporating variable limits per range (based on
longest prefix matching) although that might just get too complex/ slow.
I can imagine being more lenient with respect to the number of clients
served from my own /32 range compared to the number of connections
permitted from an unknown /48 address range.
Does anyone have any idea what is a realistic number of remote sessions
that a single smptd can concurrently process?
That would also help me get a handle on how scalable this would need to be.
Is it 100, 1000 or 10000 sessions?
MfG Robert Schetterer wrote:
To give you some ideas perhaps look at
https://sys4.de/de/blog/2012/12/28/botnets-mit-rsyslog-und-iptables-recent-modul-abwehren/
https://sys4.de/de/blog/2014/03/27/fighting-smtp-auth-brute-force-attacks/
sorry german too ,but tec side should be understandable anyway
for sure there many other aspects more in this discussion question
Best Regards
MfG Robert Schetterer
Thanks for the tips! I can also read German.
Interesting defence: iptables being implemented in the kernel is much
quicker than starting a daemon.
However, a similar problem might arise in that an IPv6 DNSRBL would also
have to be prefix length aware. Otherwise even a lone attacker or
limited group of attackers can generate load from enough different
source addresses within a /64 or /48 so that only one packet arrives
from each IPv6/128. The following post highlights the difficulty that
there's no reliable way today to know the prefix length structure within
a remote organisation.
http://www.circleid.com/posts/20120526_running_dnsbls_in_an_ipv6_world/
AFAIK the https://virbl.bit.nl IPv6 RBL tracks on a fixed /64 prefix
length. An attacker could also potentially fill up your ip6table with
many redundant entries if you didn't adapt your rule-creation strategy
when porting from from IPv4 to IPv6, meaning your defence could
potentially become the attack vector. So e.g. an Hurricane Electric
tunnelbroker user with access to a /48 could have a 2^16 advantage over
legitimate /64 users. 2^16 is a lot of additional firewall rules to
process. Equivalent to an individual having access to a class B in the
IPv4 world.
So perhaps an adaptive prefix-length tracking method might also be
applicable to an ip6tables firewall defence for IPv6: more than n* /64
firewall entires are instead replaced by 1* /56 or 1* /48 rule as
appropriate in your rule creation scripts.
--
Regards,
RayH
