Based on the RTC timestamp in the journal message, discard events
that happened before events we already processed.
This ensures that when the journal rotates, we won't reprocess
events again.
Tallow will now read JSON files from /usr/share/tallow/ and /etc/tallow
and parse them to retrieve filters and patterns. The sshd patterns
are converted to JSON and used to test this change.
If a file exists in /etc/tallow with the same name as a file in
/usr/share/tallow, only the file in /etc/tallow will be parsed.
This change allows much more dynamic insertion of rules and people
to create custom patterns and filters and monitor the logs of other
daemons besides sshd that may be subject to brutefoce login attempts.
Potential use cases:
- IMAP/POP services
- SMTP
- HTTP services permitted they log to syslog
- DNS servers logging malformed requests
- etc.
These entries can be removed from the whitelist by adding any
whitelist entry to the config file. If you add any entry, you
must repeat these in order to have them included, otherwise those
entries are not added to the custom list.
I've encountered two runaway tallow daemons now that seem to
coincide with journald restarts that send it spinning tight
on the `continue` statement and hitting the same _get_data()
error (ENOENT).
I'm unsure if the `break` will fix it, but the `continue`
is definitely broken here. Hopefully the `sd_journal_wait()`
will properly reassess the journal state and notify us of
rotations or other issues.
Before, most rules would block on the 3rd rule hit, with this,
it's 4, which means 1 extra failure before a 1hr block is started
and this is a bit more sympathetic towards `typo` failures.
This allows for some simple form of netmask type patterning
which will work for /8, /16 and /24 subnets to be whitelisted
for ipv4, and for any multiple of /32 subnets for ipv6.
Automatically `block` certain clients based on severity of the
produced error messages. These clients are for sure doing something
bad, and we don't want to let them try this more times before dropping
their packets.
The block is issued immediately, but it only lasts a short time.
Most likely, additional messages will come in after that cause a
longer ban anyway.
This also forces overwriting of ipset entries without warning, which
helps to keep the ipset list in sync without further statekeeping.
The pattern list has been expanded with the instant_block integer
value, which indicates that if the pattern matches, the IP should be
dropped for how many seconds.
Compiling with -DDEBUG=1 will now create an extra verbose version
that can be used to debug the pattern matching in more detail.
The non-debug build is now less verbose, as a result.
Send a USR1 signal to the process to make it dump the current
state table.
Some of these come with a higher weight, as they're very obvious
points of abuse/probing, like attempting to use old protocols or not
being able to use modern key types.
We do not want to rely solely on one pattern for detecting login
attempts. This change creates a simple static list with patterns that
have a weight. If the pattern matches, the weight is added to the IP
score total. If the score total exceeds the max, the IP is blocked.
Previously we blocked on count=3, now we block when score=1.0.
The weight from the standard invalid user login is now dropped to
0.4 to have the same effect.
The `threshold` parameter is now therefore obsolete, and if found in
the config file, it will be ignored.
This is a much more reliable method to extract the IP address
from the log entries, and allows us to consolidate 2 matches into
a single operation.
Once matched, we extract the IP substring and pass it to `find()`
as usual. We can add more regexes later if that is useful.
This reverts commit dc8f37e41f.
This message can print on a normal and legitimate user when they
disconnect, and therefore would be a false positive. We should
100% never get close to blocking legitimate users, ever.
Auke Kok