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 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.
Auke Kok