Because the global cookie threshold is higher than the per-IP block
threshold, it was previously possible for an attacker to block a legitimate
user by sending spoofed IKE_SA_INIT packets from that user's IP.
The timespan for requiring cookies is now also not extended anymore with
every IKE_SA_INIT received during the calm down period. Because this
allowed an attacker, after initially triggering the global cookie threshold,
to force cookies for all clients by sending just a single spoofed
IKE_SA_INIT every 10 seconds.
We keep track of reaching the per-IP threshold in segments of the hashed
IP addresses, so only a (random, due to chunk_hash()'s random key) subset
of clients will receive cookies, if single IPs are targeted.
The default global threshold is increased a bit.
If we are under attack and there are lots of requests, we might hit
the previous use count limit pretty quickly and may switch secrets multiple
times a second, which renders the 10 second default lifetime of COOKIEs
pointless and prevents legitimate clients from sending requests with valid
COOKIEs.
Depending on how CLOCK_MONOTONIC is implemented, time_monotonic() might
return 0 within 1 second after the system is started. If that's the
case, we just default to 0 for now to avoid a crash (doesn't "hide" the
system time, but it's only the uptime anyway in this case).
Closesstrongswan/strongswan#435.
While this doesn't really create any problems it is not 100% correct to
accept such messages because, of course, the sender of an IKE_SA_INIT
request is always the original initiator of an IKE_SA.
We currently don't check the flag later, so we wouldn't notice if the
peer doesn't set it in later messages (ike_sa_id_t.equals doesn't
compare it anymore since we added support for IKEv1, in particular since
17ec1c74de).
We sent both a notify using IKEv1 and IKEv2. This is a little more aggressive
than required, RFC 5996 says we "SHOULD send an unauthenticated Notify
message of type INVALID_MAJOR_VERSION containing the highest (closest) version
number it supports".
Fixes#657.
When the monotonic timer is initialized to 0 right after the system is
booted the daemon responded with COOKIES for COOKIE_CALMDOWN_DELAY (10s).
Since the COOKIE verification code actually produces an overflow for
COOKIE_LIFETIME (10s) it wouldn't even accept properly returned COOKIEs.
Checking for last_cookie makes sense anyway as that condition must only
apply if we actually sent a COOKIE before.
When sender_t is used to send ESP packets this would otherwise cause an extreme
amount of debug messages.
With this change all messages sent via sender_t.send_no_marker() cause no extra
DBG1 log message, but for debugging purposes the socket plugins do log the same
message again with DBG2 for all packets.
This ensures that no threads are active when plugins and the rest of the
daemon are unloaded.
callback_job_t was simplified a lot in the process as its main
functionality is now contained in processor_t. The parent-child
relationships were abandoned as these were only needed to simplify job
cancellation.
Tobias Brunner