Tja, die Frage überfordert mich. So rein laienhaft würde ich vermuten, weil die HMAC-FW schon ein dem Paketfilter nachgeschalteter Prozess ist, ist es hier eben ein weiterer, zusätzlicher Verarbeitungsschritt, und das (im Gegensatz zu den Netfilter-Modulen) sogar außerhalb des Kernels und darüber hinaus imho auch auf einem höheren Layer. Außerdem verewigen sich die HMAC-Failed's ja auch im LOG, nur halt im VPN-Log, das heisst, statt journald im Log des Daemons... also auch nicht wirklich eine Verbesserung.mat6937 hat geschrieben:14.08.2019 14:03:17Ja, der Server ist gut gehärtet, ... aber es stellt sich die Frage, was ist Ressourcen schonender im Falle eines (Dauer-)Angriffs, die HMAC-Firewall oder der Paketfilter?
Im Grundegenommen liegen also die Conntrack-Module auf der einen Waage-Seite, und die Daemon-eigenen Prozesse auf der anderen... was wiegt hinsichtlich CPU-Last mehr? Aber ich kann (und will) ja nicht grundsätzlich aufs Traffic-Tracking verzichten, ich halte das für wertvoll... und so groß sind die Recent-Tabellen selbst durch die Attacke nicht geworden... es waren ja nicht tausende von SADDR, sondern nur 1000e von Zugriffen einer eher kleineren Anzahl von SADDR.
Ich würde jetzt sagen, wenn ich auf das Logging des Paketfilters verzichten würde, wäre der Paketfilter imho die performanteste Verarbeitung... aber diese Entscheidung an einem einzigen Vorfall in etlichen Jahren festzumachen, wäre m.M.n. auch ein wenig unüberlegter Aktionismus. Außerdem, was mir auch wichtig ist/war, ich verwende das Journald-Logging eben auch als faktisches Positiv-Fazit beim täglichen Kontrollüberblick. Darauf müsste ich dann verzichten... und ich glaube, das würde mir weniger gut gefallen.