Probleme Ubuntu ufw

[KaeTuuN]

Hallo zusammen,

ich betreibe meinen eigenen kleinen Webserver (Ubuntu 18.04 LTS Server) und habe hier ein Problem mit der Firewall ufw. Folgende Zeile (Daten geändert) finde ich immer wieder im Log:

Apr 25 14:43:01 srv1 kernel: [169406.655879] [UFW BLOCK] IN=enp2s0 OUT= MAC=<gültige MACs> SRC=1.2.3.4 DST=192.168.1.1 LEN=40 TOS=0x08 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=34100 DPT=443 WINDOW=0 RES=0x00 RST URGP=0

Wenn ich das richtig verstehe, dann möchte die Source mit IP 1.2.3.4 Port 34100 auf das Ziel 192.168.1.1 Port 443 zugreifen.
1.2.3.4 -> Ist meine öffentliche IP
192.168.1.1 -> Ist der Server srv1, auf dem das ganze läuft

Nach meinem Verständnis der ufw dürfte der Verkehr durch die Regel ufw allow 443 nicht mehr geblockt werden. Wird er aber!
Also habe ich noch die Regel ufw allow from 1.2.3.4 to 192.168.1.1 hinzugefügt. Keine Besserung!
Was mache ich falsch?

Mfg Kae

 

[Frazer1]

Also ich hab jetzt auch noch nicht so viel Erfahrung mit ufw, aber ich dachte man muss immer das Protokoll angeben. Bei dir wäre das also ufw allow 443/tcp.
Was sagt denn ufw status. Ist da deine Regel drin?

Frazer1

Edit: Seh grade, dass wenn kein Protokoll angegeben wird, einfach beide (tcp und udp) benutzt werden. Sorry

 

[Stype]

Probier mal:

ufw allow in on enp2s0 from 1.2.3.4 to 192.168.1.1 port 443 proto tcp

 

[KaeTuuN]

Rolle ist angelegt, ufw auch neu gestartet, aber leider keine Besserung...

Mfg Kae

 

[Raijin]

Eventuell wird das Paket von netfilter als invalid eingestuft.

Verbindungen haben 4 states:

New
Das erste und nur das erste Paket jeder Verbindung (SYN-Flag gesetzt) wird als neu eingestuft.

Established
Sobald die Verbindung hergestellt wurde, das initiale SYN-Paket also mit mit SYN-ACK bestätigt wurde, gilt die Verbindung als hergestellt, als established.

Related
Wird aus einer bestehenden (established) Verbindung heraus eine verwandte Verbindung erstellt - beispielsweise die Command- bzw. Data-Verbindung von (aktivem) FTP - gilt sie als related.

Invalid
Pakete, die in irgendeiner Form "defekt" sind, sei es durch Übertragungsfehler oder ganz gezielt von einem Angreifer konstruiert, werden als invalid definiert.


Eine herkömmliche Firewall-Konfiguration arbeitet in etwa so:

1 Allow established/related
2 Drop Invalid
3 Allow irgendein Port oder irgendeine IP (hier wäre zB Allow Port 80 für einen Webserver drin)
4 Allow weitere Ports/IPs
Default Drop

Ich weiß aus dem Stegreif nicht genau wie ufw die Regeln organisiert, weil ich das nach besagtem Schema stets von Hand einrichte, aber wenn sich ufw an ein ähnliches Schema hält, kann der Block auch durchaus bereits vor der eigentlichen Freigabe erfolgt sein, beispielsweise weil das Paket eben "kaputt" ist, weil irgendwas daran nicht stimmt. Evtl kann man bei ufw das Logging so einstellen, dass auch die getriggerte Regel angegeben wird? Das würde die Sache enorm vereinfachen.

Das Problem an ufw ist, dass es zwar einerseits ein sehr komfortables Interface für die Firewall bietet, aber im Hintergrund wird ein riesiges Geflecht an Chains erzeugt. Dadurch erschwert sich die Fehlersuche, wenn man im worst case eben doch die einzelnen Regeln in iptables durchgehen muss.

 

[KaeTuuN]

Zuerst noch ein paar Infos:
Die IP 1.2.3.4 entspricht der öffentlichen IP des Routers.
Die IP 192.168.1.1 entspricht der IP des Servers auf Interface enp2s0.

Eventuell kommen wir der Sache langsam näher. In der Datei /etc/ufw/before.rules habe ich folgende Zeilen gefunden:

# drop INVALID packets (logs these in loglevel medium and higher)
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP

Da das Logging Standardmäßig auf low steht, gehe ich mal davon aus, dass es sich nicht um INVALID Pakete handelt.

Also habe ich mir die Datei weiter angeguckt und bin auf diesen Eintrag gestoßen:

# all other non-local packets are dropped
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP

Leider kenne ich mich mit der Syntax nicht genau aus, vermute aber aktuell hier mein Problem.

Was genau machen diese Einträge?

Mfg Kae

 

[Raijin]

Das ist eine Regel für rate limits bzw flood protection.

Weil ich das Rad bzw. die Erklärung nicht neu erfinden muss:

--limit
followed by a number; specifies the maximum average number of matches to allow per second. The number can specify units explicitly, using /second', /minute', /hour' or /day', or parts of them (so `5/second' is the same as `5/s').

--limit-burst
followed by a number, indicating the maximum burst before the above limit kicks in.

Quelle: netfilter HowTo

Wie ich schon sagte, wenn man bei ufw sehen könnte welche Regel triggert, wäre es einfacher zu debuggen. Der vollständige Entscheidungsbaum von ufw's iptables-Regeln kann nämlich sehr unübersichtlich werden.

 

[KaeTuuN]

Danke für die Erklärungen.

Leider finde ich keine Option, um das Log um die genutzte Regel zu ergänzen.

Mfg Kae

 

[Raijin]

Man könnte natürlich auch via tcpdump den Traffic aufzeichnen und dann mit etwaigen Log-Einträgen vergleichen. Oder man erhöht obiges rate-limit oder nimmt diese Regel gar testweise ganz raus (in Datei auskommentieren, ufw neuladen oder ggfs Server neustarten).

 

[KaeTuuN]

... oder nimmt diese Regel gar testweise ganz raus (in Datei auskommentieren, ufw neuladen oder ggfs Server neustarten).

Das ich da nicht von alleine drauf gekommen bin...
Ich teste dann mal und melde mich.

Mfg Kae

Ergänzung (26. April 2019)

Beide fraglichen Regeln auskommentiert -> Server neu gestartet -> Keine Probleme mehr
INVALID Regel wieder eingeschaltet -> Server neu gestartet -> Keine Probleme
Zum Test die andere Regel auch wieder eingeschaltet -> Server neu gestartet -> Keine Probleme
Ich bin offiziell verwirrt!

Mfg Kae

 

[Raijin]

Folgende Zeile (Daten geändert) finde ich immer wieder im Log

Beide fraglichen Regeln auskommentiert -> Server neu gestartet -> Keine Probleme mehr
INVALID Regel wieder eingeschaltet -> Server neu gestartet -> Keine Probleme
Zum Test die andere Regel auch wieder eingeschaltet -> Server neu gestartet -> Keine Probleme

Was heißt denn in der ursprünglichen Meldung "immer wieder"? Eventuell wurde während deines Tests schlicht und ergreifend das rate limit nicht überschritten und es erfolgte demnach auch keine Meldung.

Auch wenn du nie konkret erwähnt hast, dass der Webserver als solches einwandfrei erreichbar ist, interpretiere ich den Thread einfach mal so, weil du dich ja explizit über die Einträge im Log wunderst. Im Umkehrschluss heißt das, dass die Firewall als solche den legitimen tcp 443 Traffic offenbar wie gewünscht durchlässt. Das wiederum deutet darauf hin, dass eben dieser Block nur sporadisch auftritt - beispielsweise unter den zuvor genannten Bedingungen (invalid / rate limit). Stellt sich keine dieser Situationen ein, wird auch die Regel nicht getriggert und keine Meldung ins Log geschrieben.

 

[KaeTuuN]

Ja, der Webserver als solcher ist Einwandfrei über 443 und 80 erreichbar. "Immer wieder" bedeutet in dem Fall 2-20 mal pro Minute. Habe den Server jeweils knapp 15 Minuten laufen lassen und währenddessen keinerlei entsprechende Einträge entdeckt.
Was ich nicht gemacht habe und mir gerade selber einfällt, ist zu gucken, ob die Anfragen schlicht aufgehört haben, oder durchgelassen werden (Was ich mit höherem Loglevel jetzt prüfen werde.)

Mfg Kae

 

[Raijin]

oder durchgelassen werden

Es kommt jetzt natürlich darauf an was genau du jetzt auskommentiert hast.

# all other non-local packets are dropped
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP

Hast du nur die erste Regel deaktiviert, wird unter Umständen nur das Logging deaktiviert. Ich weiß leider nicht was in der Chain ufw-logging-deny sonst noch passiert. Auf jeden Fall wird alles was die erste Regel nicht triggert oder via RETURN wieder rauskommt eine Zeile später von der zweiten Regel geDROPped. Es dürfte in diesem Fall also so oder so nichts durch die Firwall kommen was in der hier behandelten Chain ufw-not-local aufschlägt, weil es im worst case vom quasi-default-drop am Ende kassiert wird.

 

[KaeTuuN]

Der Drop der fragwürdigen Pakete ist aus ufw Sicht korrekt. Ich habe jetzt sowohl mit meinem Provider als auch dem Hersteller des Routers Rücksprache gehalten und es handelt sich um IP Broadcast Pakete, welche falsch deklariert sind. Daher werden die von der ufw verworfen.
Von daher vielen dank für eure Hilfe, aber das Problem hätten wir so nicht in Gänze lösen können. Es wird dann demnächst ein Firmware Update für meinen Router geben, welcher dann den Bug behebt.

Mfg Kae