Category Archives: Opensuse 12.3

Erfahrungen mit OS 12.3

Strato-V-Server mit Opensuse 12.3 – II – Installation / SSH-Port ändern

Posted on by

Im vorhergehenden Teil dieser kleinen Reihe zum Aufsetzen eines LAMP-Systems auf einem Strato-V-Server
https://linux-blog.anracom.com/2013/10/03/virtueller-strato-v-server-mit-opensuse-12-3-i/
hatten wir einen kurzen Blick auf die durchaus begrenzte Verwaltungsoberfläche für das Serverpaket geworfen, die Strato anbietet. In diesem Beitrag installieren wir auf dem bereitsgestellten V-Server zunächst Opensuse 12.3. Danach treffen wir erste Maßnahmen, um die Sicherheit des Systems etwas zu verbessern. Dies betrifft das Hochfahren einer einfachen Firewall, aber auch einige Maßnahmen in puncto SSH-Zugang. Die Nummern unserer “Schritte” zur Installation zählen wir einfach weiter hoch.

Schritt 2: Installation eines “Opensuse 12.3”-Minimalsystems

Die Linux V-Server von Strato sind nach ihrer Bereitstellung mit Ubuntu ausgestattet. Wir möchten jedoch gerne Opensuse 12.3 nutzen. (Liegt in diesem Fall nicht nur an mir, sondern auch am Kunden). Der Menüpunkt “Neuinstallation” des Strato-Verwaltungsmenüs hilft uns hier weiter. Dort können wir das zu installierende Betriebssystem auswählen.

strato_server_7_600

Der Neuinstallationsprozess dauerte bei uns ca. 45 Minuten. Danach war das Strato-System wieder zugänglich. Wer erwartet, nun eine umfangreiche Installation mit Serverdiensten vorzufinden, irrt. Es wird lediglich ein (32Bit-) Minimalsystem mit SSH-Zugang installiert. Die weitere Bestückung mit Serverdiensten obliegt dem Kunden selbst. Hierzu muss er entweder die Web-Administrationsoberfläche “Plesk” verwenden, oder er legt – wie wir – selbst Hand an. [ Ich werde hier nicht in eine unergiebige Diskussion einsteigen, warum ich aufgrund früherer Erfahrungen für die Einrichtung des Servers nicht Plesk verwende].

Um auf dem Server arbeiten zu können, benötigen wir einen Shell-Zugang über SSH.

Schritt 3: Erster SSH-Zugang

Nach der Suse-Installation kann der Standard “ssh-Port 22” für den Shell-Zugang genutzt werden. Die erforderlichen Informationen zum Root-Zugang erhält man unter dem Strato-Verwaltungs-Menüpunkt “Serverkonfiguration >> Serverdaten”. Also auf dem eigenen System (hier mit “mylinux” bezeichnet)

mylinux:~ # ssh root@hxxxxxx.stratoserver.net

mit seiner Serverkennung hxxxxxx eingeben und die Frage nach dem Passwort beantworten. Man landet dann auf einem normalen (roten) SuSE-Shell-Prompt

hxxxxxxx:~#

Die Opensuse Paketverwaltung für die ASCII-Terminaloberfläche ist über das Kommando “yast” selbstverständlich zugänglich. Mit dem SW-RPM-Management (yast-Punkt: “SW installieren oder löschen”) kann man sich dann mal ansehen, was alles installiert ist. Das ist nicht viel. Die vorhandenen Installationsquellen beschränken sich auf die elementaren Repositories und die installierten SuSE-Paketgruppen bzw. Patterns im wesentlichen auf das Basissystem.

strato_server_8_600

Um das System zu beschäftigen, während wir uns gleich weiteren administrativen Aufgaben zuwenden, installieren wir im Hintergrund mittels “yast” die RPMs des Patterns “WEB- und LAMP-Server”. Ferner installieren wir das RPM-Paket “rkhunter”.

strato_server_10_600
strato_server_14_600

Letzteres Paket liefert ein Programm, das den Host nach Rootkits durchforstet. Wenn man die anlaufende Installation parallel verfolgen will, z.B. um ein Gefühl für die die Netzperformance zu bekommen, öffne man einfach eine zweite Shell auf dem Server.

Schritt 4: Firewall aktivieren

Ein Absetzen des Befehls

hxxxxxxx:~# iptables -L

und ein Blick mit “yast >> Sicherheit und Benutzer >> Firewall” belehren einen darüber, dass auf dem Minimalserver keine Firewall läuft. Andererseits zeigt ein

hxxxxxxx:~# lsof -i

doch einige offene Ports an (sunrpc, ipp,..). Das gefällt uns erstmal nicht. Um die Ports nicht gleich schließen zu müssen, aber doch den Schutz etwas zu verbessern, fahren wir deshalb eine minimale Firewall in Form der Suse-Firewall2 (“yast >> Sicherheit und Benutzer >> Firewall”) hoch.

Achtung- im Umgang mit einer Firewall auf einem Remote-System gibt es ein paar wichtige “Trivialitäten” zu beachten :

  • Beim Einrichten einer Firewall auf einem Remote-Server ist eine regelmäßige Grundübung die, darüber nachzudenken, dass man sich nicht selbst aussperrt. Dies impliziert die Freigabe bestimmter Dienste (für bestimmte eigene IP-Adressen) und ggf. auch ein Nicht-Hochfahren der Firewall bei einem Reboot als letztem Rettungsanker.
  • Wir müssen bei der Konfiguration der SuseFirewall und vor deren Start erst einmal den Standard “SSH-Port/SSH-Dienst” freigeben. Das ist essentiell, sonst sperren wir uns mit dem Start der Firewall unmittelbar selbst aus.
  • Den automatischen Start der Firewall haken wir auf der entsprechenden YaST-Konfigurationsseite (zunächst) nicht an. Dies gibt uns die Chance, bei Fehlern mit der Firewall zumindest über einen Reboot wieder Zugang zum Serversystem zu erlangen.

Nachdem man mal eine laufende und getestete FW-Konfiguration erstellt hat, wird man einen entsprechenden Service zum Anlegen der iptables-Regeln natürlich mit dem Start des Systems automatisch hochfahren lassen. Bei dieser Gelegenheit ist die Anmerkung angebracht, dass Strato technisch begründete Restarts der V-Server oder deren Hosts normalerweise vorab mit E-Mails ankündigt. Man kann sich dann im Bedarfs- oder Zweifelsfall zur Not auch auf ein manuelles Hochfahren seiner Firewall einstellen.

Also:

strato_server_11_600

strato_server_12_600

Erst jetzt starten wir die Firewall [FW] mit Hilfe der entsprechenden Optionen unter der YaST-Oberfläche für die SuseFirewall. Nach deren Start sollte man direkt in der geöffneten Shell weiterarbeiten können. Ein erneutes “iptables -L” zeigt uns nun allerdings eine Reihe aktiver Regeln an. Eine Abbildung der wichtigsten Regeln der SuSE-Firewall liefere ich weiter unten nach einer weiteren Einstellung nach.

Hinweis: Diese Firewall-Regeln werden uns später nicht mehr genügen. Im Bereich eingehender Verbindungen ist nun nur noch der SSH-Zugang erlaubt. Die FW läßt im Moment aber noch jede Art von ausgehender Verbindung zu. Das macht es später deutlich schwerer, illegale Aktivitäten
des Servers zu entdecken. Am Ende dieser Artikel-Reihe werden wir deshalb auch ausgehende Verbindungen drastisch beschränken.

Schritt 6: Root Kit-Scan

Bevor wir uns intensiver mit SSH befassen, ist es durchaus sinnvoll, zunächst einen Scan auf bekannte Linux-Root Kits durchzuführen. Als Grund führe ich die Welle an SSH-RootKits an, die Ende Februar dieses Jahres viele gehostete Server betroffen haben. Siehe hierzu die Links am Ende des Beitrags. Wir sollten uns vor weiteren sicherheitsrelevanten Maßnahmen sicher sein, dass wir uns über die Installation und den eigenen SSH-Zugang nicht bereits etwas auf dem System eingefangen haben.

Also :

hxxxxxxx:~# rkhunter -c

Es werden verschiedene Checks durchlaufen – u.a. eben auch auf RootKit-Merkmale. Auf dem Stratoserver mit Opensuse 12.3 kommt es dabei auch zu einigen interessanten Warnungen.

strato_server_15_600

Im Bereich der RootKit-spezifischen Suchen sollte – oder besser muss – aber alles OK sein.

strato_server_18_600

Danach tauchen weitere Warnungen auf:

strato_server_16_600

strato_server_17_600

Die Warnungen sollte man übrigens durchaus ernst nehmen und ihnen durch Studium des Logfiles

/var/log/rkhunter.log

einzeln nachgehen. Ich habe das gemacht und in allen Fällen sehr plausible Gründe dafür gefunden, warum die bemängelten Dinge auf dem frisch installierten System dennoch in Ordnung waren. Die Warnungen zu den Kernel-Modules rührt u.a. daher, dass auf dem mit Parallells virtualiserten Systemen keine Kernelmanipulationen der Hosts erlaubt sind und “lsmod” und “modprobe” wegen des fehlenden Hostzugriffs nicht funktionieren. [Das ist anders als z.B. bei KVM.]

Schritt 6: SSH-Port verlagern

Es ist keine gute Idee, den SSH-Port auf der Standardeinstellung 22 zu belassen. Das hilft nur den Script-Kiddies. Ich wähle deshalb für die SSH-Kommunikation immer einen Port weit jenseits normaler hoher Ports. Diese werden nach meinen Erfahrungen nicht so häufig von scripts durchsucht. [Natürlich nutzt eine Port-Verlagerung nichts gegenüber professionellen Angreifern – aber getreu der Weisheit, mehrere Hürden zu staffeln, ist das ein erster ablenkender Schritt.]

Zur Umlenkung des SSH-Ports gilt es, als root einen entsprechenden Port-Eintrag am Anfang der Datei “/etc/ssh/sshd_config” vorzunehmen:

Port XXXXX

Natürlich mit einer vernünftigen großen Zahl für den Port – ggf. oberhalb 60000. Wir speichern die Zeile in der sshd-config ab; wir starten den SSH-Service aber natürlich noch nicht neu. Achtung – vor dem Restart des SSH-Services ist zweierlei zu beachten :

  • Den neuen Port muss man sich unbedingt merken ! Sonst kann man sich von seinem lokalen System aus später nicht mehr einloggen.
  • Die laufende Firewall muss zuerst für den neuen Port geöffnet werden.

Letzteres erledigen wir wieder mit yast: Auf der Seite “Erlaubte Dienste” nutzen wir den Punkt
“Erweitert” und fügen folgende eigene Regel hinzu:

strato_server_13_600

Achtung auch hier: die “6xxxx” sind natürlich nicht wörtlich zu nehmen; hier ist insgesamt exakt die oben in der sshd-Konfigurationdatei angegebene neue Nummer des SSH-Ports zu wählen. Mit F10 speichern wir die neue Firewall- Einstellung ab; den Standard-SSH-Port lassen wir auch noch erstmal offen.

Mit “iptables -L” überzeugen wir uns, dass nun extra Regeln gesetzt wurden, in denen der von uns gewählte Port auftaucht.

strato_server_19_600

Erst jetzt – also nach dem Speichern und Starten der Firewall mit der neuen Zusatzeinstellung – starten wir den SSH-Service neu. Danach können wir auf der geöffneten Shell nicht nicht mehr weiterarbeiten, den der sshd-Dämon arbeitet nicht mehr auf dem von uns geöffneten Kommunikationsport. Also beenden wir auf dem lokalen System die Shell mit CTRL-C. Wir müssen uns neu mittels SSH anmelden – nun aber unter Angabe des zu verwendenden Ports:

mylinux:~ # ssh root@hxxxxxx.stratoserver.net -p 6xxxx

Und schon sind wir wieder drin.

Schritt 6: Standard SSH-Port in der SuSE-Firewall schließen

Hat unser Zugang über den neuen Port funktioniert, kann man nun den Standard SSH-Port aus der SuSE-Firewall ausschließen. Hierzu entfernt man in den zugehörigen YaST-Firewall-Einstellungen (s. oben) einfach wieder den anfänglich erlaubten SSH-Serverdienst – natürlich aber ohne aber unsere Zusatzeinstellung unter “Erweitert” für den anderen Port zu ändern.

Nächste SSH-Themen

Aber auch das ist bei etwas Nachdenken natürlich nicht eine hinreichend sichere Lösung. Denn:

  • Der SSH-Port wurde zwar verschoben – aber er ist immer noch von überall her erreichbar.
  • Die Möglichkeit eines Brute Force Angriffes bleibt durch den Passwort-bezogenen Authentifizierungsmechanismus bestehen.
  • Root hat SSH-Zugang

Gerade der letzte Punkt ist ein latentes Sicherheitsproblem:

In den vergangenen Jahren gab es mehrere Beispiele dafür, wie Systeme durch Brute-Force-Angriffe auf ssh-Verbindungen auf einfache Weise kompromittiert werden konnten. Der root-User ist ja der am einfachsten zu erratende User-Account und der Brute-Force-Angriff kann sich auf das Knacken des Passwortes beschränken.

Es ist deshalb eine gute Idee, gar keinen SSH-Zugang für den User root, sondern nur für einen unpriviligierten User auf einem geänderten Port zuzulassen. Dadurch muss der Angreifer den Port ermitteln, den User-Namen und ein Passwort erraten. Und wenn ihm dann der Zugang geglückt sein sollte, hat er immer noch keine Root-Rechte, sondern muss nun zusätzlich auch das root-Passwort erraten. Das Sperren des SSH-Zugangs für root erhöht also den Aufwand für Angreifer.

Wie wir root vom SSH-Zugang zu unserem Stratoserver ausschließen, werde ich im nächsten Beitrag
Strato-V-Server mit Opensuse 12.3 – III – Stop SSH Root Login
beschreiben. Danach gehe ich dann auch auf einen zertifikatsbasierten SSH-Zugang ein.

Links

Rootkit Checks
http://xmodulo.com/ 2013/05/ how-to-scan-linux-for-rootkits.html

http://www.rackspace.com/ knowledge_center/ article/ scanning-for-rootkits-with-chkrootkit

Denjenigen, die am Sinn der hier besprochenen und noch kommenden SSH-Maßnahmen zweifeln, empfehle ich, sich in zwei ruhigen Stunden mal folgende Threads im Internet zu SSH-Rootkits, die im Frühjahr dieses Jahres gehostete virtuelle Server befallen haben, durchzulesen und einige der immer wieder auftauchenden Ratschläge bzgl. der Absicherung von SSH zu Herzen zu nehmen:

http://www.webhostingtalk.com/ showthread.php?s=714ab2598f1b14729348957 db7196325&t=1235797

http://forums.cpanel.net /f185/ sshd-rootkit-323962-p5.html

Sonstiges zur SSH-Absicherung
http://www.ibm.com/ developerworks/ aix/ library/ au-sshlocks/
http://www.rackaid.com/ resources/ how-to-harden-or-secure-ssh-for-improved-security/
http://stackful-dev.com/ linux-101-hardening-ssh.html
http://www.lowendguide.com/ 3/security/ how-to-harden-and-secure-ssh-for-improved-security/
http://linuxmoz.com/ how-to-secure-ssh-servers/

 

Strato V-Server mit Opensuse 12.3 – I

Posted on by

Manchmal wollen Kunden ihren eigenen Web-Apache- und LAMP-Server als gehosteten virtuellen Server betreiben. In letzter Zeit hatten wir die Aufgabe, solche Server unter Opensuse 12.2 und Opensuse 12.3 beim Hoster Strato aufzusetzen. Hier ein mehrteiliger Bericht dazu, wie wir dabei vorgegangen sind. Ich kann dabei allerdings nicht auf Details des LAMP- und des Sicherheits-Setups eingehen und verweise an passender Stelle auf passende frühere Artikel dieses Blogs oder andere Beiträge im Netz.

Vorbemerkungen zum V-Server-Paket

Ein paar Anmerkungen vorweg zum Strato-Angebot, das unsere Kunden typischerweise nutzen. Ich beziehe mich hier auf ein Strato V-Server-Paket des Typs “V-Server Linux Level 3”. Beworben wird dieses Paket wie folgt:

V-Server Linux Level 3 (Stand 02.10.2013)

  • zwei zugewiesene CPU-Cores,
  • ein garantierter RAM von 4 GB (dynam. max. 6 GB),
  • Plattenplatz: 200 GB.

Interessanterweise findet man in den aktuellen Informationen (02.10.2013) der Hauptwebseite zu diesem Paket keine Aussage zu den 2 zugewiesenen Cores. Enthalten ist eine entsprechende Feststellung aber auf folgender Seite
https://www.strato-pro.com/ ger/ virtual-server/#/ linux/

Strato hält diese etwas versteckte Zusage von 2 CPU-Cores jedenfalls ein. Auch bzgl. des RAMs hat sich die Zuteilung in den von uns betreuten Verträgen bislang als großzügig erwiesen. Im Schnitt standen uns mehr als die zugesagten 4 GB zur Verfügung. Als Virtualisierungsplattform wird Parallels eingesetzt. Als Admin hat man die Möglichkeit, die Web-Oberfläche “Plesk” für 10 Domainen einzusetzen

AMD Opteron CPU und Linux als 32-Bit Gast begrenzen die Leistungsfähigkeit des V-Server-Systems

Als CPU wird ein “AMD Opteron(tm) Processor 6128” eingesetzt. Infos zu den Eigenschaften des kostengünstigen und bereits betagten Prozessors sowie zu seiner Performance findet man z.B. unter folgenden Links :

http://products.amd.com/ en-us/ opteroncpuresult.aspx? f1=AMD+Opteron%E2% 84%A2+6100+Series+Processor& f2=6128&f3=Yes&f4=2000& f5=512&f6=G34& f7=D1&f8=45nm+SOI& f9=115+W& f10=6400&f11=8&

http://www.cpu-world.com/ CPUs/ K10/ AMD-Opteron%206128%20-%20 OS6128WKT8EGO%20 %28OS6128WKT8EGOWOF%29.html

http://www.cpubenchmark.net/ cpu.php?cpu=AMD+Opteron+6128

http://www.jaxbeachtech.com/ content/ processor-performance-rank

http://browser.primatelabs.com/ geekbench2/391840

Diese schon etwas ältere CPU hat 8 Cores (16 Threads unter Linux) und wird normalerweise mit 2 GHz getaktet. Im Normalbetrieb läuft der Core bei Strato allerdings mit 1.725 GHz. Linux Opensuse Guests kommen nur in 32-Bit Versionen zum Einsatz. Zusammen begrenzt das das Leistungsvermögen. Man darf hinsichtlich der Performance also wirklich keine Wunder erwarten.

Um einen eigenen Überblick zu erhalten, haben wir uns verschiedene eigene PHP/MySQL-Programme auf virtuellen Servern unter KVM auf eigenen Systemen im Vergleich zum Strato-V-Server angesehen. Das Spektrum reichte dabei von einfachen CMS-Anwendungen zur Generierung von Webseiten
bis hin zu CPU-intensiven Simulationen. Zusammenfassend kamen wir zu folgendem Ergebnis :

Auf einem meiner eigenen älteren Server-Systeme schlägt ein virtueller 64-Bit Gast mit Opensuse 12.3,

  • der unter KVM mit virtio-Treibern und direkten Zugriff auf Raid10-Partitionen genutzt wird und
  • dem nur ein (!) CPU Core einer Intel Quad 9550 CPU zugewiesen wurde,

das Strato-V-Server-System bei etlichen CPU- und datenbankintensiven LAMP-Aufgaben klar, wenn auch nur mit Faktoren zwischen 1.2 bis 1.5. Ein Grund ist sicher das eigene, sehr gut gepufferte Plattensystem.

Deutlich schlechter sieht der Vergleich allerdings bei Einsatz aktueller Intel i7-CPUs und SSD-Platten aus. Hier sehen wir im Schnitt Faktoren > 2 – 3 – vor allem bei CPU-intensiven Prozessen.

Aber wir wollen nicht klagen. Ein großer Provider muss sich um ganz andere Dinge kümmern, als wir mit unseren Haus-Serverchen. Für den Betrieb normaler PHP-generierter Webseiten reicht das Paket in der Regel durchaus aus :

Typische Dinge, die bei uns 80-90 msec mit unserem eigenen PHP-basierten CM-Framework dauern, nehmen auf dem Strato-Server 200 msec in Anspruch. Typische totale Antwortzeiten (ohne Caching-Verfahren, inkl. Internet-Transfer der Daten ) – die wir mit Browser-Tools für einzelne, durch unser CMS generierte Seiten gemessen haben – liegen dauerhaft im Bereich von 350 msec. Das ist aus meiner Sicht OK und deutlich besser als für billige Web-Hosting-Pakete bei anderen Providern, wie z.B. 1&1. Dort schwankt die Antwortzeit für PHP-basierte Sites tagsüber deutlich und um Faktoren; sie ist zudem stark vom Preis des Hosting-Pakets abhängig.

Einer unserer Kunden betreibt CPU-intensive aber auch datenbank-lastige Simulationen von Supply Chain Netzwerken – er muss im direkten Vergleich zu Systemen mit aktueller HW einen Faktor 2,5 an schlechterer Performance als auf KVM-Guests auf Servern mit aktueller HW hinnehmen.

Nebenbei : Bei 1&1 erhält man aktuell zwar 64-Bit-Gast-Systeme, zahlt aber gemessen an garantiertem RAM und Plattenplatz deutlich mehr. U.a. aus diesem Grund haben wir Strato gewählt. Hinzu kommt die kurze Kündigungsfrist von 1 Monat bei Strato. An Support erwarte ich von beiden Providern nach schlechten Erfahrungen beim Webhosting und auch bei DSL (1&1) schlicht wenig bis nichts. Plesk als Server-Verwaltungsoberfläche nutze ich nicht. Wer eine echte Backup-Strategie fahren muss, sollte sich ein Verfahren überlegen, bei dem man mit Rsync-basierten Tools wesentliche Bereiche auf eigene Serverplatten abgleicht – oder aber gegen Aufpreis eine der möglichen avancierteren Backup-Zusatzpakete bestellen.

Schritt 1: Blick in die schlichte Web-Verwaltungsoberfläche zum Strato-Server

Nach der Bestellung seines V-Server-Paketes erhält man seine Zugangsdaten zum Server per E-Mail und das zugehörige Passwort per SMS. Lobenswert ist die Trennung. Das zeigt zumindest an, dass man sich (ISO 27000 Zertifizierung der Strato-Rechenzentren) um Sicherheit grundsätzlich Gedanken macht. (Ob die aber in Zeiten wie diesen wirklich viel hilft, sei mal dahingestellt. Warum verwenden solche Provider eigentlich nie Verschlüsselungsverfahren oder bieten deren Nutzung im Zusammenhang mit dem Austausch von Zugangsdaten zumindest an?).

Mit Hilfe der übermittelten Daten meldet man sich unter folgender Oberfläche an.

strato_server_1_600

strato_server_2_600

Dort erwartet einen ein schlichtes Verwaltungsmenü, das
bei genauerem Hinsehen mit vielen Links zu Zusatzpaketen gespickt ist. Auch wird man mit aktuellen Werbe-Nachrichten und Nachrichten zu Sicherheitslücken in Plesk/Parallels konfrontiert. Letzteres finde ich allerdings nicht schlecht. Was bieten die Menüpunkte? Ich picke nur die wichtigsten heraus:

  • Zugangsdaten : Hier ändert man den Zugang zu eben dieser Verwaltungsoberfläche.
  • Traffic Control : Infos und Grafiken zum ein- und ausgehenden Netzwerkverkehr. Das ist durchaus von Bedeutung – sollte man ab und zu einen Blick hinein werfen. Denn wirklich frei ist der Traffic nicht : Ab 1000 GB / Monat wird die Anbindungsgeschwindigkeit auf 10 MBit/sek – also Unbrauchbarkeit – gedrosselt. Siehe hierzu das Kleingedruckte am Ende der oben angegebenen Webseite zu Details des V-Server-Pakets. Dies ist insbesondere dann interessant, wenn – wie in einem unserer Fälle – der LAMP-Server Simulationen mit erheblichem Output für Downloads durchführen soll.

    Die Grafiken kann man sich in verschiedenen Varianten anzeigen lassen – eine hinreichende Analyse in Kombination mit anderen eigenen Tools wie vnstat, cacti etc. ist damit möglich.

strato_server_4_600

  • Serverkonfiguration : Hier erhält man relevante Submenüpunkte:
  • Backup Control: Schlichte Liste über tägliche, automatisch angelegte Backups. Für komplexere Backups, die einer Backupstrategie folgen sollen, ist ein zahlungspflichtiges Upgrade erforderlich. Spätestens hier fängt man an, über eigene Backup-Verfahren für wichtige System- und Datenbereiche (u.a. /etc, /srv, /var …) nachzudenken.
  • Serverdaten: relevante Daten wie das intiale root Passwort, IP-Adresse des Servers
  • Neuinstallation: Wichtig, wenn man – wie wir – initial ein anderes Betriebssystem als das vorinstallierte Ubuntu haben möchte. Interessant aber auch in einem ernsten Schadensfall.
  • Revovery Manager: Möglichkeit zum Reboot oder Starten eines Notfall-Systems. Hier denkt man nicht nur an ein aus irgendeinem Grunde hängendes System. Im Auge haben sollte man auch so hübsche Dinge wie ein sich selbst Aussperren bei Experimenten mit einer Firewall. Ein durchaus interessantes Thema, das einen später zu der Frage führt, in welchen restriktiven Zustand eine Firewall nach einem Restart hochfahren soll. Dies ist deswegen von Bedeutung, weil auch Strato ab und zu Neustarts der Systeme vornimmt.
  • IP-Adressen: Zuschalten einer IPV6-Adresse bei Bedarf.
  • Optionen: Regeln von Quotas / automatischen Backups / resolv.conf-Politik

strato_server_5_600

strato_server_6_600

Im nächsten Teil

Strato-V-Server mit Opensuse 12.3 – II – Installation / SSH-Port ändern

beschreiben wir kurz den SSH-Zugang, eine Verlagerung des SSH-Ports und das Starten einer ersten einfachen SuSE-Firewall mit relativ restriktiver Einstellung.

 

FWBuilder – conntrack – Warnungen

Posted on by

Ich nutzte in der Vergangenheit sehr gerne FWBuilder, um iptables-Regeln zu generieren. Mit den aktuellen Paketen aus dem Repository

http://download.opensuse.org/repositories/security/openSUSE_12.3/

ergeben sich jedoch Schwierigkeiten. So erhält man – je nach Zustand des Zielsystems – Warnungen der Art

WARNING: The state match is obsolete. Use conntrack instead.

Dies gilt insbesondere für Server, die auf Basis von Opensuse 12.3 eingerichtet wurden. Dort wird iptables in einer Version > 1.4.16 verwendet. FWBuilder ist damit nicht kompatibel. Siehe hierzu u.a.:

http://www.mbse.eu/2012/11/iptables-1-4-16-and-fwbuilder-doesnt-work/

Der Bug ist auch schon seit einer ganzen Weile bekannt. Siehe:

http://sourceforge.net/p/fwbuilder/bug-reports-current-version/245/
http://sourceforge.net/p/fwbuilder/discussion/16372/thread/8789d909/

Die schlechte Nachricht

FWBuilder ist aus meiner bescheidenen Anwender-Sicht eine Perle von einem Programm gewesen. Stichworte: Sehr nützlich, gutes Layout, einfach zu bedienen, gut verständlich, etc. und bis Anfang des Jahres auch immer aktuell. Nun musste ich zur Kenntnis nehmen, dass die zwei tragenden Entwickler das Projekt und ihre ehemalige Firma verlassen haben. Siehe :

http://sourceforge.net/p/fwbuilder/news/2013/04/announcement-/
http://sourceforge.net/p/fwbuilder/discussion/16372/thread/54f339dc/
http://sourceforge.net/p/fwbuilder/news/2013/07/i-am-leaving-netcitadel/

Mir ist leider bislang völlig unklar geblieben, wie es z.Z. um den Status des FWBuilder-Projektes bestellt ist. Man kann jedenfalls nicht mehr so ohne weiteres erwarten, dass sich jemand der Sache mit den conntrack-Warnungen annimmt. Es gibt daher für mich als Endverbraucher 4 Alternativen:

  1. Man bleibt bei IPtables V1.15.X. Dies bedeutet bei Opensuse, dass man dafür Hand anlegen und kompilieren muss. Auf Dauer sicher keine gute Lösung.
  2. Man sieht sich nach einer Alternative zu FWBuilder um. In Frage käme etwa “shorewall”. Dabei wird man jedoch die komfortable grafische Oberfläche von FWBuilder vermissen. Zudem muss man sich in das dateibasierte Interface von Shorewall einarbeiten. Sollte sich niemand des FWBuilder Projekts annehmen, ist dieser Schritt vielleicht auf Dauer nicht zu vermeiden.
  3. Man findet sich mit den Warnungen ab. Zur Sicherheit sollte man dann aber testen, ob die Regeln noch tatsächlich wirksam sind. Der Grund ist, dass das Modul “state” früher oder später möglicherweise nicht mehr in allen Kernelkonfigurationen repräsentiert sein wird. S.u. Auf Dauer also auch nicht gut.
  4. Man nutzt FWBuilder weiter und baut als Workaround um die generierten fw-Installationsskripts ein Script herum, dass die notwendigen Änderungen an den von FWBuilder generierten iptables-Regeln vornimmt. Das wäre immerhin ein Workaround auf Zeit …

Nachfolgend widme ich mich nach ein paar Infos zu “conntrack” der Alternative 4.

Unterschiede zwischen “conntrack” und “state” ?

Bevor man sich mit
Eingriffen in sicherheitsrelevante Scripts befasst, sollte man sich wenigstens ein wenig dazu kundig machen, worum es geht. Also hier eine (sehr kurze) Kurzfassung:

Das Verfolgen eines Verbindungszustands ist ein elementarer Bestandteil von Paketfiltern. Unter Linux sind hierfür bestimmte Kernelkomponenten (Kernel Frameworks) verantwortlich, die z.T. und ggf. nicht fix in den Kernel integriert sondern als Kernel-Module kompiliert sein können. Das State-Modul wurde vor einer Weile durch eine ganze Kaskade von optionsreicheren “Conntrack”-Modulen abgelöst. Ob und wie nun ein System mit einer bestimmten Kernel- und Kernel-Modul-Konfiguration auf die alten “-m state” Optionen und zugehörige Suboptionen von IPtables-Filterregeln reagiert, hängt von Details der Implementierung ab. Siehe auch:

http://serverfault.com/questions/358996/iptables-whats-the-difference-between-m-state-and-m-conntrack

Eine Einführung in den Einsatz der Status-Analyse im Zusammenhang mit iptables findet man hier:
http://www.iptables.info/en/connection-state.html

Ich zitiere den dortigen “Original Author: Oskar Andreasson”:

“All of the connection tracking is done by special framework within the kernel called conntrack. conntrack may be loaded either as a module, or as an internal part of the kernel itself. Most of the time, we need and want more specific connection tracking than the default conntrack engine can maintain. Because of this, there are also more specific parts of conntrack that handles the TCP, UDP or ICMP protocols among others. These modules grab specific, unique, information from the packets, so that they may keep track of each stream of data. The information that conntrack gathers is then used to tell conntrack in which state the stream is currently in. For example, UDP streams are, generally, uniquely identified by their destination IP address, source IP address, destination port and source port. “

Entsprechend findet man auf einem Standard-Opensuse 12.3-System folgende Module:

os123:~ # lsmod | grep conntrack
nf_conntrack_ipv4 15013 66
nf_defrag_ipv4 12730 1 nf_conntrack_ipv4
nf_conntrack_netlink 35452 0
nfnetlink 14407 1 nf_conntrack_netlink
nf_conntrack_ftp 18680 0
nf_conntrack_snmp 12858 0
nf_conntrack_irc 13519 0
nf_conntrack_tftp 13122 0
nf_conntrack_pptp 19246 0
nf_conntrack_netbios_ns 12666 0
nf_conntrack_broadcast 12590 2 nf_conntrack_snmp,nf_conntrack_netbios_ns
nf_conntrack_slp 12648 0
nf_conntrack_h323 73846 0
nf_conntrack_sane 13144 0
nf_conntrack_proto_sctp 18823 0
nf_conntrack_amanda 13042 0
nf_conntrack_sip 33868 0
xt_conntrack 12761 66
nf_conntrack_proto_udplite 13282 0
nf_conntrack_proto_gre 14435 1 nf_conntrack_pptp
nf_conntrack_proto_dccp 13511 0
nf_conntrack 98519 19 nf_conntrack_ipv4,nf_conntrack_netlink,nf_conntrack_ftp,nf_conntrack_snmp,
    nf_conntrack_irc,nf_conntrack_tftp,nf_conntrack_pptp,nf_conntrack_netbios_ns,
    nf_conntrack_broadcast,nf_conntrack_slp,nf_conntrack_h323,nf_conntrack_sane,
    nf_conntrack_proto_sctp,nf_conntrack_amanda,nf_conntrack_sip,xt_conntrack,
    nf_conntrack_proto_udplite,nf_conntrack_proto_gre,nf_conntrack_proto_dccp
x_tables 34060 9 xt_LOG,xt_multiport,xt_tcpudp,xt_conntrack,ip6table_filter,ip6_tables,
    iptable_filter,ip_tables,ebtables

Welche Konsequenzen hat das nun für IPtables-Regeln ?

Wie man conntrack verwendet, ergibt sich z.B. aus den Ausführungen dieser Webseiten:

http://www.iptables.info/en/iptables-matches.html#GENERICMATCHES
http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html

Aus meiner Sicht sind daher bisherige IPtables-Regeln wie in folgendem Beispiel zu modifizieren:

Alte Syntax:
$IPTABLES -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
 
Neue Syntax:
$IPTABLES -A INPUT -m conntrack –ctstate ESTABLISHED,RELATED -j ACCEPT

Ich sage aber ausdrücklich, dass ich das noch nicht im Detail verifiziert habe. Für komplexe Prüfungen mögen mehr Anpassungen von Nöten sein, als in dem simplen Beispiel angegeben. Und zudem gilt:

Das conntrack-System hat wesentlich mehr Optionen als nur "–cstate" !!

Auf die ganzen Möglichkeiten kann und will ich an dieser Stelle nicht eingehen.
Ein Blick in mehrere meiner generierten fw-Scripts zeigte mir jedenfalls für meine Fälle, dass die Ersetzung funktionieren sollte.

Die gute Nachricht – einfache Modifikation der generierten Scripts von FWBuilder

Wenn die oben genannte Ersetzungsregeln richtig sein sollten, dann ist man insofern fein raus, als man zur Modifikation der Skripts, die FWBuilder generiert, auf den jeweiligen Zielmaschinen ein einfaches “sed”-Kommando laufen lassen kann, um die notwendigen Modifikationen vorzunehmen. Folgende sed-Ersetzungsregeln sollten dann ausreichen :

sed ‘s/-m state –state/-m conntrack –ctstate/g’

Siehe auch :
http://gentooligan.blogspot.de/2012/12/change-in-iptables-state-vs-conntrack.html

Tatsächlich passen die angegebenen Blanks in der Ersetzungsregel auch zu den FW-Scripts. “sed” nutzt den Pipe-Mechanismus. Hat man z.B. ein System namens “os123” und hat man dort über die Remote Installationsmechnismen von FWBuilder ein Skriptfile namens “/etc/os123.fw” installiert, so kann man auf diesem System folgendes Kommando durchführen:

sed ‘s/-m state –state/-m conntrack –ctstate/g’ < /etc/os123.fw > os123.fw.mod

Anschließend kann man das neue Script zur Installation der Firewall nutzen:

os123:~ # sh /etc/os123.fw

Um das ganze etwas handlicher zu machen, bastelt man dann ggf. ein Skript um das Ganze. Eine erste Primitiv-Version kann auf dem besagten System etwa so aussehen:

#!/bin/bash
SHORT_HOSTNAME=$(hostname -s)
FW_FILE=”/etc/”$SHORT_HOSTNAME”.fw”
FW_FILE_ORIG=$FW_FILE”.orig”
FW_MOD_FILE=$FW_FILE”.mod”
echo “***************************************************”
echo “Preparing and installing FW-Firewall on “$SHORT_HOSTNAME
if [ -e $FW_FILE ]
then
echo ” – Copying “$FW_FILE” to backup file “$FW_FILE_ORIG
cp $FW_FILE $FW_FILE_ORIG
echo ” – Starting to modify \””$FW_FILE”\” with SED”
sed ‘s/-m state –state/-m conntrack –ctstate/g’ < $FW_FILE > $FW_MOD_FILE
rm $FW_FILE
mv $FW_MOD_FILE $FW_FILE
echo ” – Modification of \””$FW_FILE”\” with conntrack statements
finalized”
echo “Executing the modified script …”
echo “***************************************************”
sh $FW_FILE
echo “***************************************************”
else
echo “Firewall file does not exist”
fi
exit

Ich überlasse es dem Leser, hieraus ein übersichtliches, dokumentiertes Skript zu bauen, das sich für den Produktiveinsatz eignet. Und natürlich muss man das noch mit systemd verheiraten …..

Auf einem realen System sieht das dann etwa so aus:

#sh install_fw
***************************************************
Preparing and installing FW-Firewall on os123
– Copying /etc/os123.fw to backup file /etc/os123.fw.orig
– Starting to modify “/etc/os123.fw” with SED
– Modification of “/etc/os123.fw” with conntrack statements finalized
Executing the modified script …
***************************************************
Activating firewall script generated Wed Aug 28 15:30:16 2013 by root
Running prolog script
Verifying interfaces: br0 lo
Rule 0 (br0)
Rule 1 (br0)
Rule 2 (lo)
Rule 3 (br0)
Rule 4 (br0)
Rule 5 (br0)
Rule 6 (global)
Rule 8 (br0)
Rule 9 (global)
Rule 10 (br0)
Rule 11 (br0)
Rule 12 (br0)
Rule 13 (br0)
Rule 14 (br0)
Rule 15 (br0)
Rule 16 (br0)
Rule 17 (br0)
Rule 18 (br0)
Rule 19 (br0)
Rule 21 (br0)
Rule 22 (br0)
Rule 23 (global)
Running epilog script
***************************************************

Viel Spaß weiterhin mit FWBuilder auf Opensuse-Systemen. Und hoffentlich nehmen sich bald irgendein Sponsor und interessierte Entwickler des verwaisten FWBuilder-Projekts an ….