Zusätzlich zu dem, was gesagt wurde, ist es auch möglich, durch Überprüfen der iptables- Regeln abzuleiten, was protokolliert werden soll . Insbesondere können die übereinstimmenden Übereinstimmungsregeln wie folgt gefiltert werden sudo iptables -L | grep -i "log"
:
ufw-before-logging-input all -- anywhere anywhere
ufw-after-logging-input all -- anywhere anywhere
ufw-before-logging-forward all -- anywhere anywhere
ufw-after-logging-forward all -- anywhere anywhere
ufw-before-logging-output all -- anywhere anywhere
ufw-after-logging-output all -- anywhere anywhere
Chain ufw-after-logging-forward (1 references)
LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "
Chain ufw-after-logging-input (1 references)
LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW ALLOW] "
Chain ufw-after-logging-output (1 references)
LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW ALLOW] "
ufw-logging-deny all -- anywhere anywhere ctstate INVALID
Chain ufw-before-logging-forward (1 references)
LOG all -- anywhere anywhere ctstate NEW limit: avg 3/min burst 10 LOG level warning prefix "[UFW AUDIT] "
Chain ufw-before-logging-input (1 references)
LOG all -- anywhere anywhere ctstate NEW limit: avg 3/min burst 10 LOG level warning prefix "[UFW AUDIT] "
Chain ufw-before-logging-output (1 references)
LOG all -- anywhere anywhere ctstate NEW limit: avg 3/min burst 10 LOG level warning prefix "[UFW AUDIT] "
Chain ufw-logging-allow (0 references)
LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW ALLOW] "
Chain ufw-logging-deny (2 references)
LOG all -- anywhere anywhere ctstate INVALID limit: avg 3/min burst 10 LOG level warning prefix "[UFW AUDIT INVALID] "
LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "
ufw-logging-deny all -- anywhere anywhere limit: avg 3/min burst 10
LOG all -- anywhere anywhere limit: avg 3/min burst 5 LOG level warning prefix "[UFW LIMIT BLOCK] "
Chain ufw-user-logging-forward (0 references)
Chain ufw-user-logging-input (0 references)
Chain ufw-user-logging-output (1 references)
Dies sind größtenteils Standardregeln. Wenn Sie die Ausgabe oben überprüfen, werden die ufw-before-*
Ketten angezeigt, in denen [UFW AUDIT ..] -Protokolle erstellt werden.
Ich bin kein großer Experte für iptables und das UFW-Handbuch ist in dieser Hinsicht nicht sehr hilfreich, aber soweit ich die Regeln für diese Kette beurteilen kann, finden Sie in /etc/ufw/before.rules .
In den folgenden Zeilen sind beispielsweise Loopback-Verbindungen zulässig, die möglicherweise die letzten beiden Beispielzeilen in Ihrem Protokoll ausgelöst haben (diejenigen, die mit [UFW AUDIT] IN = lo beginnen).
# rules.before
# ....
# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT
# ....
Ich für meinen Teil erhalte viele protokollierte LLMNR- Pakete an Port 5353:
Mar 17 21:02:21 pc kernel: [133419.183616] [UFW AUDIT] IN=wlp2s0 OUT= MAC= SRC=192.168.1.2 DST=224.0.0.251 LEN=146 TOS=0x00 PREC=0x00 TTL=255 ID=22456 DF PROTO=UDP SPT=5353 DPT=5353 LEN=126
Was meiner Meinung nach durch Folgendes verursacht wird rules.before
:
# allow MULTICAST mDNS for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 224.0.0.251 --dport 5353 -j ACCEPT
Eine Möglichkeit, diese zu deaktivieren, besteht darin, Folgendes zu starten:
sudo ufw deny 5353