Wir optimieren derzeit das Firewall-Management des VCP (vServer Control Panel) für alle vServer Kunden. Hierbei kam es in letzter Zeit bei einzelnen Kunden leider zu Problemen bzw. der Zuordnung von verschiedenen Problemen aufgrund ähnlicher Symptome auf ein vermeintlich gleiches Problem.
Um dem Entgegen zu wirken möchten wir hier Informationen anreißen wie einzelne Probleme entstehen können und wie man diesen entgegen wirkt.
[h]Connection Tracking[/h]Das Connection Tracking Feature wie man es aus IPtables kennt, kam bei unserem Firewall-Management bisher ebenfalls zum Einsatz, arbeitete jedoch etwas anders als man dies kennt. Dies hat bei einigen Kunden für Verwirrung gesorgt und war in wenigen speziellen Fällen auch dafür verantwortlich, dass für den Kunden richtig erstellte DROP Filter nicht so gegriffen haben, wie man dies erwartet hätte. Durch eine grundlegende Optimierung der Firewall im Hintergrund haben wir das Verhalten der Firewall nun noch weiter an den bekannten Standard angeglichen.
Diese Optimierung hat zur Folge das es wiederum in anderen Fällen zu neuen Problemen kommt die man als Kunde ggf. nicht abgesehen hat. Diese Optimierung rollen wir auch nicht auf einen Schlag auf alle Server aus da dieses katastrophal für uns und die Kunden wäre. Ein evtl, entstehendes Supportaufkommen könnte nicht mehr abgedeckt werden und da wir den Service natürlich mindern möchten, erfolgt die Umsetzung der Optimierung momentan Schrittweise.
[h]Beschreibung und Behebung des bekanntesten Problems[/h]fwbeispielschema.png
Das Problem bei welchem einzelne DROP Filter nicht so griffen wie man dies erwartet hat, ist erfolgreich behoben. Dadurch allerdings ergibt sich aufgrund nicht ausreichender oder richtig gesetzter Firewall Regeln ein neues Problem.
Beispiel 1 (vor der Optimierung)
Man hat seine vServer Firewall für INPUT per Default auf "verwerfen" (DROP) gestellt. Es kann also keinerlei Verkehr rein oder raus. Nun hat man zusätzlich einige Ports freigeschaltet, z.B. SSH, FTP, HTTP. Hat man nun zusätzlich für einzelne Quell-IPs oder Quellnetze eine DROP Regel erstellt hat diese auch mit dem Setzen expliziter STATE Werte nicht gegriffen. Hier war u.a. ein Teil des Connection Tracking schuldig.
Nachteil: Es kamen bereits aufgebaute Verbindungen trotz DROP rein, aber es kamen auch eingehende (Reply) Pakete von ausgehenden Anfragen rein was eigentlich nicht sein dürfte, z.B. Antworten auf eine DNS Auflösung durch einen "ping" oder ein "apt-get update" bzw. "yum update".
Beispiel 2 (nach der Optimierung)
Man hat seine vServer Firewall für INPUT per Default auf "verwerfen" (DROP) gestellt. Es kann also keinerlei Verkehr rein, auch explizit keine Reply Pakete auf Basis ausgehender Anfragen. Diesmal gilt diese Regel vollständig, es geht absolut nichts durch den INPUT. Schaltet man nun wieder SSH, FTP, HTTP frei und versucht nun einen "ping google.de" auszulösen, geht die DNS-Auflösungsanfrage der Domain google.de welche man pingt raus, aber die Reply-Pakete kommen nicht rein da nur SSH, FTP und HTTP freigeschaltet wurden.
[h]Die Lösungswege[/h]Lösung A
Man schaltet im INPUT absolut alle notwendigen eingehenden Ports frei.
Lösung B (zu empfehlen)
Man erstellt im INPUT einen einzelnen ACCEPT Filter für alle Quellen und Ziele mit den States ESTABLISHED und RELATED. Auf diese Weise werden generelle DROP Regeln mit den States NEW, ESTABLISHED und RELATED für einzelne IPs oder IP-Netze umgehend berücksichtigt, aber Reply-Pakete von ausgehenden Anfragen (z.B. DNS-Namensauflösung) dürfen weiterhin durch.
Wir haben hierzu ein Beispiel in die Anleitung des VCP im netcup Wiki aufgenommen. Siehe netcup Wiki - vServer Control Panel - Beispielregeln: globaler Drop
[h]Bei weiteren Problemen[/h]Die Änderungen des Firewall-Management, welche nicht die Formulare im VCP betreffen, dort ändert sich nichts, werden wie bereits erwähnt derzeit Stück für Stück auf die Server ausgerollt. Es ändert sich dabei auch nichts an den bestehenden Regeln der Kunden für Ihre vServer. Insofern jemand jedoch eine Veränderung oder Probleme mit der Firewall feststellt weil sich definitiv ohne Änderung, Regeln anders verhalten, so möge sich der betroffene Kunde bitte direkt per E-Mail mit dem Support in Verbindung setzen.
