Wobei Singapur schon ein erheblicher Aufpreis ist. Der Server kostet im Angebot 10,41 € in Nürnberg
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.
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
Display MoreWie 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.
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.
[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.
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.
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.
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!
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)
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...
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.
Why would you need a firewall on Netcup level by software ( not hardware) if you manage the system yourself and the firewall here is software wise the same?
If you have risk managing things like docker, use virtualization and manage FW rules between the hosts
As long firewalls are not hardware based for me it makes no sense to have them in the SCP/outside my RS/VPS
It does make sense, because even if it's software based (most firewalls are software based, they are just adapted to the specific hardware by the way) you have an additional layer, in case you made an error on your own vps regarding the firewall rules. Almost all cloud providers (not so many vps providers) provide a firewall for their cloud servers.
