Posts by engine

Ich bin wirklich froh, dass nach Pandemie, Ukraine-Krieg und dem Zoll-Wahnsinn nun die nächste Sau namens KI durchs Dorf getrieben wird. Es gibt wirklich nichts was ich mir sehnlichster Wünsche, als das diese sinnlose Blase platzt. Machine Learning war schon immer ein Thema, aber diese KI-Blase ist einfach nur noch ein riesen großer Fake.

Quote from fvbor

Wobei Singapur schon ein erheblicher Aufpreis ist. Der Server kostet im Angebot 10,41 € in Nürnberg

pasted-from-clipboard.png

Jop, wird in den Foren auch schon extrem bemängelt. Ist schon happig, ja...aber Singapur war schon immer Premium, weil v.a. der Traffic dort so teuer ist.

Ich kenne mindestens zwei Foren, die jetzt so viel Traffic bringen, dass selbst Netcup zusammenbricht, weil der Standort Singpur dort so beliebt ist. Wundert mich jetzt nicht

Hab zwar G11, aber bei mir läuft die Firewall auch ohne Probleme.

Quote from muto

Ok, I think I got the issue now. TCP is stateful and can be tracked, thus TCP responses for outgoing TCP requests are accepted (established connections). BUT UDP responses need to be explicitly allowed?

Thanks for your answer!

Exactly

Quote from -Manu-

Wie sieht das mit der Bandbreite aus?

Viele haben sich ja vor ihren eigentlichen Server(n) einen bspw. VPS mit OpnSense installiert zzgl. dem kostenlosen CloudVLAN (100Mbit). Der VPS dient dann im Prinzip als "out of band"-Firewall....also das, was jetzt die neue Firewall seitens Netcup übernimmt.

Man knipste sich damit über das CloudVLAN nur die Bandbreite auf 100Mbit/sec runter.

Kann ich hier davon ausgehen, dass keine Einschränkung vorhanden ist? D.h. wenn mein RS mit 2.5Gbit angebunden ist, dass bei "von-über-nach" über die Netcup-Firewall diese 2.5Gbit weiter bestehen? Oder findet hier (ggf. technisch bedingt) eine Verringerung statt?

Sieht bei mir gleich aus wie vorher, sprich keine Verringerung

Prinzipiell kenn ich‘s von Fortigate und anderen Enterprise Firewalls so, dass du am Ende eine Drop all Regel hast. Alles was zuvor nicht durch Regeln definiert wurde, wird verworfen - egal ob in oder out.

Quote from NaN

Diese Auflösung funktioniert wahrscheinlich in den meisten Fällen auch ohne die UDP 53 IN Regel, weil der Resolver dann auf TCP umschaltet. Deswegen fällt es vielleicht erst durch den Performanceverlust auf, dass man diese Regel braucht. Dass die UDP-Regeln stateless sind, führt allerdings die UDP-Firewall fast ad absurdum, weil ein Angreifer nur einen dann praktisch immer freizugebenden Source Port wie DNS verwenden muss, um beliebige UDP-Ports auf dem Server erreichen zu können. (Man kann die Regeln auf den Portbereich einschränken, der für abgehende "Verbindungen" verwendet wird, aber wer macht das schon.)

Oder auf die Source-IP filtern, sofern man nur externe Nameserver verwendet. Dann müsste der Angreifer auch die IP spoofen.

Quote from Zierleiste

[netcup] Sarah G. Zum Thema DNS:

Bei Verwendung der netcup-DNS-Server werden keine Firewall-Regeln für DNS benötigt, richtig?

Das Beispiel in der Hilfe dient für den Betrieb eines eigenen DNS-Servers und nicht für die Verwendung externer DNS-Server wie beispielsweise 1.1.1.1?

Beides sollte man vielleicht in der Hilfe erläutern.

Doch, auch für 1.1.1.1 oder ähnliches brauchst du entsprechende Firewall-Regeln. Wie es mit den internen aussieht kann ich dir nicht beantworten.

Quote from johnassel

Das wäre dann vielleicht auch etwas, was man in den Standardregelsatz aufnehmen könnte. Das dürfte dann ja jeden DNS-Verkehr betreffen. 🤔

Sehe ich auch so, denn selbst ein lokaler Resolver hat - wie du sagst - einen Upstream und der schlägt dann fehl, wenn die entsprechenden Ports nicht freigegeben sind.

Quote from johnassel

UDP mit Port 53 als Zielport hatte ich ja, sonst könnte ich meinen DNS nicht erreichen. Aber es fehlte UDP mit Port 53 als Quelle. Ohne läuft es nicht.

Genau, hatte ich mich falsch ausgedrückt.

Quote from johnassel

Puh, das mit DNS ist eine böse Falle. Ich musste die hier auch Eingehend VON Port 53 TCP/UDP erlauben, damit der lokale DNS wieder auflösen konnte. Klar, auf dem Papier spricht man intern mit dem DNS. Dieser fragt im Hintergrund aber nach draußen. Müsste das dann nicht alle DNS-Requests betreffen, sobald man irgendeine eingehende Regel definiert? Weil dann ja die implizierte Regeln eingehend auf DROP ANY schaltet?

Es reicht UDP 53 IN, TCP sollte ja dank stateful funktionieren - so hab ichs gelöst. Zusätzlich hab ichs noch auf die IPs meiner beiden externen Resolver eingegerenzt.

So nun läuft das Ganze, mal gucken. Prinzipiell begrüsse ich das Firewall-Feature aber sehr, das hat mir gefehlt!

Quote from tab

Naja, die Regeln werden von oben nach unten abgearbeitet. Sowie eine Regel greift, werden die restlichen nicht mehr ausgewertet. Das was du eingehend explizit erlauben willst, müsste dann vor den impliziten Regeln stehen?!? Oder interpretiere ich das falsch?

Na wenn der aRaphael auch eine Regel einbaut die alles blockt von jeder IP zu jeder IP, dann ist ja klar, dass das gesamte Internet jetzt tot ist!

Na, passt schon. Das Problem lag am UDP, das das explizit erlaubt werden muss (für DNS)

Quote from tab

Spannend, gerade getestet, bei mir geht es noch. Sowohl meine eigenen Resolver über das Cloud VLAN als auch 1.1.1.1. Hast du die "impliziten Regeln" rausgenommen?

Nope, die sollen bleiben. Ausgehend alles erlauben, aber eingehend alle verwerfen, ausser was ich erlaube.

Geht bei euch die DNS-Auflösung noch mit externen Nameservern? Bei mir geht z.B. 1.1.1.1 nicht mehr, time out. Vermutlich ist das eine stateless Firewall und man muss den eingehenden Traffic von 1.1.1.1 auf UDP & TCP Port 53 zulassen?

EDIT: Ich hatte recht, wenn man externe Nameserver verwendet (am Beispiel von Cloudflare) muss man Source IP 1.1.1.1/32, Source Port 53 UDP & TCP auf Any zulassen, sonst funktioniert die Namensauflösung nicht...

Quote from Homwer

warum willst du noch isos einbinden?

ipxe > chain http://boot.netboot.xyz

Andere ISO die es dort nicht gibt? Brauchte ich auch schon…

Bin ich der Einzige, dessen Root Server in Wien zwei mal für ca. 10 Minuten weg war? Ca. 11.06 und 11:27

Naja, wenn du ein Remotebackup mit 4 TB hochlädst, dann gehen 3 TB mit Fullspeed (meiner Meinung nach) und nach 24 Stunden kannst du die restlichen 1 TB mit Fullspeed hochladen, nicht bereits nach einer Stunde? Aber was weiss ich...

Du musst natürlich den Port auch mit ufw allow 22/tcp bzw ufw allow ssh erlauben, bevor du die Firewall aktivierst, damit der SSH Port danach funktioniert? Ausserdem solltest du noch ufw deny incoming und ufw allow outgoing durchführen. Und falls du IPv6 nutzt, sollte das auch in /etc/default/ufw mit yes aktiviert sein.