So, wie du loggst, ist die Festplatte schneller voll als du schauen kannst. Sowas muss man beschränken. Außerdem hast du mehrere Optimierungs-Optionen. Ich schreib dir da mal ein Beispiel:
[src=bash]#!/bin/bash
# Firewall setup
# ==== Pre-Setup ====
# Deleting existing rules
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
# ==== Chain Setup ====
# Add new custom chains
iptables -N log_reject
iptables -N log_drop
# Feed log_reject chain
iptables -A log_reject -m limit --limit 10/day -j LOG --log-prefix "[IPTables] REJECT: " --log-level 7
iptables -A log_reject -j REJECT
# Feed log_drop chain
iptables -A log_drop -m limit --limit 10/day -j LOG --log-prefix "[IPTables] DROP: " --log-level 7
iptables -A log_drop -j DROP
# ==== Feed main chains ====
# Always accept loopback traffic
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
# Snatch invalid traffic
iptables -A INPUT -m state --state INVALID -j log_drop
# Reject ISATAP traffic without logging
iptables -A INPUT -p 41 -j REJECT
# Allow established connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Specific rules
iptables -A INPUT -i eth0 -p tcp -dport 22 -j ACCEPT
iptables -A INPUT -i eth0 -p udp -dport 80 -j log_reject
...
# Reject everything else without logging
iptables -A INPUT -j REJECT
# ==== This movie is over ====
exit 0
[/src]
Haupt-Interesse sollten für dich die Custom Chains im Chain Setup sein. Du kannst beliebige eigene Chains erstellen, so hältst du die Wege für Pakete kurz und die Firewall effizient. Will ich loggen, schiebe ich die zu loggenden Pakete in eine eigene Chain. Da kann ich dann von hunderten Regeln die Pakete sammeln und loggen, mit nur einem einzigen Statement. INVALID-Pakete sollten grundsätzlich gedroppt werden, denn die dürften gar nicht ankommen (zum Beispiel ein TCP teardown ohne vorherige bestehende Verbindung). Dort zu rejecten macht keinen Sinn, denn die Anfrage ist illegitim, der Gegenüber wird eine Antwort gar nicht verarbeiten können. Sonst sollte man natürlich IMMER rejecten, sofern nicht ein starkes Missverhältnis zwischen Up- und Downloadgeschwindigkeit und die Gefahr eines DDoS gegeben ist.
Letztlich musst du auch nicht (wie phre4k vorgeschlagen hat) von jedem einzelnen Paket das Statement "NEW" tausende Male prüfen, wenn du alle nicht-NEW-Pakete gleich zu Beginn abfrühstückst und zulässt bzw. droppst. Dann arbeitet deine Firewall nämlich nur noch NEW-Pakete ab und wendet die Regeln auf diese an, was die Sache auch viel schneller macht. Verbindungsaufbau ist schließlich nur einmal, egal wie viele Daten fließen. Außerdem ist meineswissens die Prüfung des Packet State vergleichsweise langsam gegenüber anderen Filterregeln (input interface, IP, Destination Port etc.), daher willst du das so selten als irgend möglich prüfen.
Die Logging-Line 21 erklär ich dir mal kurz noch:
Der in Zeile 17 hinzugefügten Chain log_reject wird als erstes Element hinzugefügt, dass für 10 spezifische Ereignisse pro Tag (also 10 gleiche Verbindungsanfragen innerhalb von 24 Stunden) geloggt wird, alle weiteren Vorkommnisse fallen unter den Tisch. Dabei wird das Syslog bedient, und jede geloggte Zeile bekommt ein "[IPTables] REJECT: " vorangestellt. So kannst du dann hübsch mittels rsyslog filtern und in eigene, spezifische Logdateien schreiben lassen. Ich weiß nicht, ob man fail2ban auf eigene Chains umbiegen kann, sollte aber sicher irgendwie möglich sein. So könntest du auch weiter filtern (z. B. erst rejecten, bis fail2ban anschlägt, dann direkt droppen und diesen drop auch loggen). Damit bist du umfassend informiert, was deine Firewall so treibt. Natürlich kannst du auch ACCEPTs loggen, Prinzip identisch.
P.S.: Der Grund, warum ich 10 Anfragen pro Tag loggen ließe, ist, dass das in meinen Augen für ein externes Interface nach Angriff aussähe, und ich ab dieser Schwelle Fail2ban eingreifen lassen würde. Ab dem Eingriff brauch ich erstmal kein weiteres Logging mehr.