Add a tallow.patterns man page which explains the json configuration
files that contain regex patterns and banning thresholds. This
functionality was added by 9174590b04.
It appears that using a signed int causes the reads from libsystemd-journal
to return incorrect values when comparing time stamps. I've fixed them
to unsigned ones and monitored the performance on 2 systems for 3 days and
it no longer misbehaves. I've also made it use `atoll` instead of `atoi`
to prevent incomplete results.
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.
