Bei allen Firewalls, die ich kenne, ist die erste zutreffende Regel entscheidend. Alles nachfolgende wird dann ignoriert und implizite Regeln, die den Rest erledigen stehen am Ende.
Das ist bei nftables so einfach nicht mehr korrekt, aber die üblichen Frameworks machen das so, ja. Die default policy von iptables Firewalls ist allerdings keine Regel im eigentlichen Sinn und wird deshalb manchmal auch nicht in der praktisch relevanten Reihenfolge aufgelistet.
Naja, ich habe das bezogen auf die externen Firewalls der Provider, so wie hier.
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.
Ich habe auf einigen Server geoip-shell im Einsatz.
Funktioniert sehr gut.
Allerdings rate ich jedem, das nur mit Blacklisting zu betreiben. Alles blocken und nur bestimmte Länder zu erlauben kann ins Auge gehen:
Ich weiß, die USA darf man nicht blocken für gewisse Dienste und Crawler. Bei Google Merchant kann es auch ein Ausschlussgrund sein. Aber für viele Zwecke kann es Ressourcen sparen.
Heiliger Grahl!
Da hab ich hab seit Tag 1 als Kunde hier drauf gewartet!!! 
Dankeschön ans gesamte netcup-Team und Glückwunsch zur Implementierung!
/cc Moderatoren
Nur um sicherzugehen: Ich gehe einmal davon aus, dass die neue Firewall wirklich bei allen Paketen auf dem öffentlichen Interface beachtet wird? Also auch Traffic, der aus dem selben Subnetz bzw. vom gleichen Hostsystem (anderer vServer) kommt?
Sprich: Die Regeln werden wirklich auf dem jeweiligen Hostsystem ausgeführt und nicht irgendwo zentral auf einem Router/Switch von netcup?
(Dass sie beim Cloud vLAN nicht funktioniert, ist mir schon klar.)
Vielen Dank für die Einführung der Firewall. Super Weihnachtsgeschenk.
Heiliger Grahl!
Bei den Foos hieße das »Heiliger Grohl!« scnr
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?
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
Danke für das Feature. Ich habe gehofft, dass es mal kommen soll.
Ich habe aber mal eine Frage:
Wenn ich einen Webserver freigeben will, muss ich ja Port 80 und 443 freigeben.
Wie muss ich bei den Ports bei Outgoing und Incoming angeben?
Outcoming
Source Port 80 zu Destination Port 80
Incoming
Source 80 zu Destination Port 80
Natürlich auch für Port 443. Des Weiteren auch für IPv4 und IPv6.
Ein Drop-Regel als letztes benötige ich nicht, so wie ich das hier im Thread gelesen habe.
Definiere ich das richtig oder denke ichda falsch?
Du brauchst nur den Incoming-Teil mit Ziel 80 und 443 TCP.
Outgoing und Quelle kannst du ignorieren.
Und ssh (22, falls nicht geändert) nicht vergessen. 
(Ebenso)
Minimum sollte also so aussehen:
Hängt die Erhöhung der Latenzen zu den Servern mit dem Start der Firewall zusammen, oder ist das nur eine Korrelation statt Kausalität? Das Routing bis zu Netcup hat sich nicht geändert.
Hier sieht alles ganz normal aus.
/cc Moderatoren
Nur um sicherzugehen: Ich gehe einmal davon aus, dass die neue Firewall wirklich bei allen Paketen auf dem öffentlichen Interface beachtet wird? Also auch Traffic, der aus dem selben Subnetz bzw. vom gleichen Hostsystem (anderer vServer) kommt?
Sprich: Die Regeln werden wirklich auf dem jeweiligen Hostsystem ausgeführt und nicht irgendwo zentral auf einem Router/Switch von netcup?
(Dass sie beim Cloud vLAN nicht funktioniert, ist mir schon klar.)
Hi KB19
danke für deine Nachfrage 
Um diese kurz zu beantworten: Ja, jeglicher öffentliche Traffic geht durch die Firewall.
Ich hoffe, das klärt deine Frage auf.
Liebe Grüße
Sarah & das netcup-Team
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?
Hallo -Manu-
Zu deiner Frage, ob es eine Einschränkung gibt, möchten wir dir auch noch Auskunft geben:
Durch die Firewall gibt es keinerlei Traffic-Einschränkungen – der jeweilige Wert bliebt weiter bestehen.
Liebe Grüße
Sarah & das netcup-Team
Irgendwas ist da buggy.
Wenn ich eine Policy erstelle und bspw. EINGEHEND HTTPS TCP/443 erlaube und das Ganze speichere....geht es so wie es soll.
Editiere ich nun die bestehende Policy und füge eine weitere Regel hinzu (bspw. EINGEHEND SSH).....dann geht danach SSH, aber HTTPS nicht mehr).
Ich muss in einem Rutsch alle Regeln reinpacken und dann speichern...dann geht alles.
Füge ich eine Regel in einer Policy hinzu und speichere....und füge dann noch eine Regel hinzu und speichere wieder....dann gehen die vormals gespeicherten nicht mehr.
EDIT:
Ich habe jetzt auch testweise alle Regeln rausgeschmissen und habe jetzt nur noch die implizierte Regel seitens Nectup "ACCEPT ALL OUTGOING+INCOMING auf ANY). Die wird gesetzt wenn ansonsten keine anderen Policies drin sind.
Und selbst jetzt ist immer noch alles dicht...!?
EDIT VOM EDIT: Ich habe jetzt nochmals das gespeicherte bereits gespeichert (die unter EDIT genannte Regel) und jetzt gehts wieder....entweder ist da ne signifikante Wartezeit oder man muss mit mehr Elan auf "Speichern" klicken...mindestens 2x.
policy raus, rein bringt da auch keine abhilfe?
Das Verhalten ist für mich derzeit nicht nachvollziehbar.
Durchaus möglich, dass ein RAUS/REIN der Policy das umgeht....aber dann müsste darauf hingewiesen werden.
Ich gehe ja nach Treu und Glauben davon aus, dass wenn ich "einfach nur" eine weitere Regel einer meiner (bestehenden) Policies hinzufüge, dass das logischerweise gehen sollte.
Auch schlägt mir bei jeder Änderung an der Firewall erstmal direkt mein Uptime Kuma an (erreicht die zu überwachenden externen Services nicht mehr)....so als ob bei Änderungen (egal was) erstmal *random* für einen Zeitintervall X alles dicht ist...bis die Firewall sich mal erbarmt, die Regelwerke/Policies (wieder) anzuwenden.
Es ist für mich nicht transparent.
Unterm Strich wirkt es auch allgemein so, als gäbe es zwischendurch irgendwo ein zeitliches Delta zwischen Regel-/Policy-Setzung und deren Umsetzung auf der Firewall.
Ändere ich während diesem zeitlichen DELTA wieder etwas, dann verwürfelt sich das "irgendwie".
