Category Archives: Erfahrungsberichte

Erfahrungen aus dem Alltag eines Linux-Anwenders

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.

 

Kurzreview Eclipse 4.3 Kepler mit PDT und Aptana

Posted on by

Vor einiger Weile hatte ich mich wegen der miserablen Performance enttäuscht von Eclipse 4.2 Juno mit PDT abgewandt. Besonders bei Benutzung der neuen GTK-Oberfläche tauchten immer wieder lange andauernde 100%-Peaks in der CPU-Belastung von 1 bis 2 CPU-Cores auf. Auf meinem schwachbrüstigen Laptop eine Katastrophe – aber auch auf einem gut ausgestatten Desktop-Rechner eine echte Belastung.

Im besonderen galt dies beim Hin- und Herziehen von Tabs zwischen zwei getrennten parallelen, vertikalen Editor-Bereichen der GUI von Juno. Das Öffnen des Outline-Bereiches machte das System nochmal träger. Die parallel Sicht auf mehrere geöffnete Files sowie den Outline-Bereich benötige ich beim Arbeiten mit vielen Klassenbibliotheken aber immer wieder.

Es half keine Herumdoktern an den Speichereinstellungen für die JVM. Genausowenig half eine Umstellung auf die klassische Eclipse GUI. Daneben gab es auch immer wieder seltsame Probleme mit einer parallelen Installation von Aptana und PDT 3.1/3.2. Die Content Assist Vorschläge wurden entweder gar nicht oder nicht immer vollständig angezeigt. Die Schwierigkeiten waren sowohl bei Einsatz von Suns JVM für Java 7 als auch von OpenJDK 1.7 gegeben. Alles unter Opensuse 12.2 und 12.3 (64 Bit).

Für meine PHP-Entwicklungsarbeiten griff ich aus diesen Gründen bis gestern immer noch auf Eclipse 3.7 “Indigo” zurück.

Nun ist Eclipse in der Version 4.3 unter dem Namen “Kepler” erschienen. Daher habe ich gestern erneut einen Anlauf mit dieser aktuellen Eclipse-Version und dem zugehörigen PDT 3.2 plus Aptana Studio 3 unternommen. Und diesmal wurde ich nicht entäuscht:

Alles funktioniert wie es soll und das wirklich performant. Allerdings musste ich meine unter Indigo aufgebauten Workspaces unter Rückgriff auf vorhandene SVN-Repositories komplett neu aufbauen. Erst danach lief alle fehlerfrei.

eclipse_kepler_1_600

An den Standard Speichereinstellungen habe ich nichts verändert. Die “eclipse.ini” sieht daher wie folgt aus:

-startup
plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar
–launcher.library
plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.200.v20130521-0416
-product
org.eclipse.epp.package.standard.product
–launcher.defaultAction
openFile
-showsplash
org.eclipse.platform
–launcher.XXMaxPermSize
256m
–launcher.defaultAction
openFile
–launcher.appendVmargs
-vmargs
-Dosgi.requiredJavaVersion=1.6
-XX:MaxPermSize=256m
-Xms40m
-Xmx512m

Es gab und gibt nach bislang 12 Stunden Arbeit keinerlei Hänger und keine Peaks in der CPU zu bemängeln! Das Arbeiten mit mehreren parallel angezeigten Editor- und GUI-Bereichen läuft sehr flüssig. Das Verschieben von Tabs für geöffnete Dateien zwischen zwei Darstellungsbereichen führt zwar zu einer kurzfristigen Belastung mehrerer CPU-Kerne – aber eben wirklich nur sehr kurzzeitig und das ist nicht als Bremse für das Arbeiten wahrnehmbar. Auch die Build-Operation für Projekte laufen mit angemessener Geschwindigkeit.

Aptana lässt sich parallel zu PDT einsetzen. Man kann zwischen den verschiedenen “Natures” entsprechend “facettierter” Projekte nach Lust und Laune hin- und herschalten. Die Content-Assists-Hinweise kommen entsprechend. Ich nutze z.T. den Aptana-Editor, um HTML-Code in TPL-Files für die Template-Engines Pear-ITX oder Smarty zu bearbeiten. Ich schätze dabei die browser-bezogenen Content Assist Hinweise. Aber auch der Wechsel zum normalen WST-HTML-Editor mit dessen Content-Assists-Fähigkeiten für HTML- und CSS-Vorschlägen klappt einwandfrei.

Aptanas PHP-Unterstützung benutze ich in der Regel nicht und
habe ich daher nicht wirklich getestet. Ein kurzes Umschalten auf die Aptana Editoren und Aptanas Content Assist für PHP zeigte mir aber keine unerwarteten Probleme.

Die SVN-Anbindung über Subversive und die Polarion-Konnektoren lief wie erwartet. Ein Gleiches gilt für MyLyn

Kurzum:
Für PHP-Projekte stellt Eclipse 4.3 “Kepler” endlich eine ernsthafte, weil funktionierende und performante “Eclipse 4.x”-Alternative zu Indigo dar. Ich kann den Umstieg wirklich empfehlen.

Ein kleiner Wermutstropfen
Schade irgendwie, dass es der HTML-“Web Page Editor” bisher nicht in die “WTP 3.5” -Repositories von Kepler geschafft zu haben scheint. Aber eine Installation aus den WTP 3.3.2 Ressourcen scheint keine größere Probleme zu machen.

vsftp unter Opensuse 12.2 und 12.3

Posted on by

Ich bin gerade in der Situation, für Entwicklungszwecke parallel zwei Web-Testserver aufsetzen zu müssen – einen unter Opensuse 12.2 und einen unter Opensuse 12.3. Entwickler sollen per FTP Files in Verzeichnisse unterhalb von

/srv/www/htdocs/webs

auf die Apache Testservern hochladen. Die dortigen Verzeichnisse sind “named virtual domains” des Webservers zugeordnet. Neu entwickelte PHP-Programme sollen unter diesen Domainen für unsere Kunden getestet werden.

Der jeweils dedizierte und einzige FTP-User auf diesen Systemen hatte natürlicherweise ein zunächst leeres Home-Verzeichnis

“/srv/www/htdocs/webs”

erhalten. Bzgl. der ihm zugeordneten Shell habe ich “/bin/false” definiert. Die Entwickler sollen sich über den FTP-Account auf dem Server-System nicht in eine Shell einloggen können.

Als FTP-Serverdienst wollte ich zur Abwechslung mal “vsftp” mit SSL/TLS [ftps] statt “sftp” aus der openssh-Suite aufsetzen. Dabei erlebte ich so einige Überraschungen, die vielleicht auch für andere interessant sind, die sich an vsftp heranwagen oder von früheren Opensuse-Versionen auf OS 12.3 upgraden wollen.

Sicherheit spielt in meinem Fall für die Testserver, die nur aus einem lokalen Netz zugänglich sind, zwar nicht eine essentielle Rolle, aber wenn man einen solchen Service aufsetzt, dann natürlich zur Übung gleich auf TLS-Basis.

Die wichtigsten Statements der “/etc/vsftp.conf” sehen daher wie folgt aus:

write_enable=YES
dirmessage_enable=YES
nopriv_user=ftpsecure
local_enable=YES
anonymous_enable=NO
anon_world_readable_only=YES
syslog_enable=NO
connect_from_port_20=NO
ascii_upload_enable=YES
pam_service_name=vsftpd
listen=YES
pasv_min_port=30000
pasv_max_port=30100
anon_mkdir_write_enable=NO
anon_upload_enable=NO
ssl_enable=YES
rsa_cert_file=/etc/ssl/servercerts/servercert.pem
rsa_private_key_file=/etc/ssl/servercerts/serverkey.pem
ssl_sslv2=NO
ssl_sslv3=NO
ssl_tlsv1=YES
 
#require_ssl_reuse=NO
 
chroot_local_user=YES
local_root=/srv/www/htdocs/webs
hide_ids=YES
ftpd_banner= mysysb vsFTP Server
idle_session_timeout=900
hide_ids=YES
log_ftp_protocol=NO
max_clients=20
max_per_ip=5
pasv_enable=YES
anon_root=/srv/ftp
anon_umask=022
local_umask=006

und abhängig von der Opensuse-Version:

seccomp_sandbox=NO [für Opensuse 12.3]

Wichtiger Hinweis:
Nach meiner Erfahrung ist es leider so, dass der letzte Parameter bei Opensuse 12.3 auf NO gesetzt werden muss. Das gilt nicht für Opensuse 12.2 und Opensuse 13.1. Dort sollte man den Standard nehmen bzw. das Statement ganz weglassen. Die aktuellen man-pages führen diesen Parameter gar nicht mehr auf !

Natürlich kann man sich über das “chroot_local_user=YES” und die Tatsache, dass nicht mehrere virtuelle User angelegt wurden, vielleicht streiten. Aber wir wollen ja keine userspezifischen Daten-Container aufbauen, sondern gemeinsam genutzte Web-Test-Domainen versorgen.

Nicht ganz unwichtig ist hier das Statement

local_root=/srv/www/htdocs/webs

das auch künftige andere User auf ein ganz bestimmtes Verzeichnis – hier ist das identisch mit dem Home-Verzeichnis des FTP-Users – einschränken würde.

Übrigens: Da der FTP-User sich ja sowieso nicht einloggen darf, kann
man den Owner und die Gruppe des Verzeichnisses in unserem Fall auch auf “root:root”, z.B. mit Mode 751, ändern.

# chown root.root /srv/www/htdocs/webs
# chmod 751 /srv/www/htdocs/webs

Man muss das aber nicht. Wichtig ist hingegen der Entzug der Schreibrechte für unseren FTP-User – auch wenn das zunächst paradox wirken mag. Letzteres ist aus Sicherheitsgründen wichtig. Sie die Anmerkungen weiter unten.

Ein weiterer Hinweis:
Konfiguriert man vsftp mittels YaST2, so wird für TLS unbedingt ein File zu einem DSA-Key gefordert. Die YaST-CA-Verwaltung legt aber Serverzertifikate RSA-basiert an. Ich helfe mir über diese Klippe dadurch weg, dass ich das pem-File des RSA-Keys angebe, danach dann die Datei “vsftp.conf” editiere und die Statements zum Zertifikats- und Key-File wie oben gezeigt auf “RSA” abändere:

rsa_cert_file=/etc/ssl/servercerts/servercert.pem
rsa_private_key_file=/etc/ssl/servercerts/serverkey.pem

Die Kombination “local_enable=YES” und “ssl_enable=YES” lässt keine unverschlüsselten Sitzungen mehr zu

Hat man SSL aktiviert, werden unverschlüsselte Sitzungen nicht mehr zugelassen, wenn man sich über einen lokalen, nicht-anonymen User authentifizieren will. Das erscheint völlig logisch. Und so wunderte ich mich nicht, dass beim Versuch einer unverschlüsselten Verbindung folgende Meldung in FTP-Clients, wie Filezilla, hochkommt:

Response: 530 Non-anonymous sessions must use encryption.
Error: Could not connect to server

Eine klare und verständliche Meldung. Also “Explizites TLS” für die gewünschte FTP-Verbindung anfordern ! In Filezilla kann man das sehr einfach bei der Definition seiner FTP-Server hinterlegen.

Der FTP-User darf keine Schreibrechte auf sein chroot-Verzeichnis haben

Eine erste, wenn auch nicht wirklich überraschende Erkenntnis unter OS 12.2 und 12.3 war, dass man im Falle von

chroot_local_user=YES

aus Sicherheitsgründen gehindert wird, auf ein chroot-Verzeichnis eingeschränkt zu werden, auf dem der FTP-User Schreibrechte hat.

Aber Achtung: Das ist in unserem Beispiel das Verzeichnis aus dem Statement

local_root=/srv/www/htdocs/webs

Das wäre auch so, wenn der FTP-Account ein tieferliegendes Heimatverzeichnis hätte !
Merke:
Das Verzeichnis aus dem “local-root”-Statement kann durchaus ein anderes als das Heimatverzeichnis des FTP-Users sein! Passt man hier nicht auf, kann es bzgl. erforderlicher Rechtesetzungen schon mal zu Missverständnissen und Fehlern kommen. Der zu authentifizierende FTP-User darf bei Benutzung von “local_root” keine Scheibrechte auf demjenigen Verzeichnis haben, das in diesem Statement angesprochen wird. Die Rechte bzgl. eines ggf. abweichenden Heimatverzeichnis ist bei gesetztem “local_root” zweitrangig !

Die Einschränkung bzgl. der Schreibrechte versteht man! Das ist übrigens schon seit der vsftp-Version 2.5.x so und ist u.a. auch bei der Einrichtung aktueller sftp-Varianten mit chroot-Definitionen zu beachten.

Man kann das Verweigern einer Verbindung zu einem beschreibbaren chroot-Verzeichnis unter aktuellen vsftp-Versionen auch nicht mehr wie früher durch irgendwelche zusätzlichen Parameter wie “allow_writeable_chroot=YES” umgehen. Was dann natürlich Konsequenzen für das Setup der Verzeichnisstruktur hat, die von außen per FTP zugänglich sein soll.

Das eigentliche Problem ist aber, dass man als vsftp-Unbedarfter ggf. nicht entfernte Schreibrechte auf dem chroot-Verzeichnis nicht unbedingt als die eigentliche Ursache von Fehlermeldungen erkennt ! Solche Rechte können z.B. auch über eine unglücklich gesetzte Gruppenzugehörigkeit
ins Spiel kommen. Genau das war bei mir der Fall.

Hat man nun unglücklicherweise bei der Einrichtung des FTP-Users

  • entweder Standardrechte auf seinem Heimatverzeichnis gesetzt und belassen,
  • oder bei der Zuordnung zu einer Gruppe Schreibrechte auf dem chroot-Verzeichnis übersehen,
  • oder nicht erkannt, dass es in der obigen Konfiguration um die Schreibrechte auf dem Verzeichnis aus dem “local_root”-Statement und nicht wirklich um das Heimatverzeichnis des FTP-Users geht,

so kann das unter bestimmten Umständen in Filezilla und unter OS 12.2 zu TLS-bezogenen Fehlermeldungen führen, was dann doch sehr missverständlich ist. Ich jedenfalls bekam beim Experimentieren mit sftp haufenweise TLS-Fehlermeldungen, die meist mit dem eigentlichen Problem – wie hier einer risikoreichen Zugangsberechtigung – im Kern gar nichts zu tun hatten und in die Irre führten. [Die Funktionstüchtigkeit seiner TLS-Einrichtung und seiner Zertifikate sollte man natürlich auch mal unabhängig von vsftp testen!]

Auf dem OS 12.3 erhielt ich dann aber nach einigen Experimenten in einer aktuellen Filezilla-Version die Meldung:

500 OOPS: vsftpd: refusing to run with writable root inside chroot ()

Die half dann wirklich weiter. Weiteren Aufschluss brachten folgender Artikel und die dortige Diskussion
https://www.benscobie.com/fixing-500-oops-vsftpd-refusing-to-run-with-writable-root-inside-chroot/

sowie ein genereller Artikel zu Sicherheit im Zshg. mit chroot()
http://www.onlamp.com/excerpt/PUIS3_chap16/index3.html

Hilfreich war zudem ein Blick in die Original-FAQ-Hinweise zum akt. vsftp-Packet in der Version 3.0.2 unter
vsftpd.beasts.org/users/cevans/untar/vsftpd-3.0.2/FAQ
aus der ich nachfolgend zitiere:

Q) Help! I’m getting the error message “refusing to run with writable root”.
 
A) vsftpd is protecting against dangerous configurations. The cause of this message is usually dodgy ownership of the ftp home directory. The home directory should NOT be owned by the ftp user itself. Neither should it be writable by the ftp user. A way to fix this is:
chown root ~ftp; chmod -w ~ftp
Another cause might be an attempt to use chroot_local_user without setting up the directory ownership properly.

Ok, das ist klar. Natürlich sollte ein FTP-User nicht an seinem Root-Verzeichnis herumpfuschen können. Das gilt, wie gesagt, auch für sftp-Installationen aus der openssh-Suite (s. etwa: http://www.techrepublic.com/blog/opensource/chroot-users-with-openssh-an-easier-way-to-confine-users-to-their-home-directories/229)

Also verändert man in Fällen, die meiner Konstellation vergleichbar sind, am besten die Owner und die Rechte auf dem local_root-Verzeichnis, wie oben beschrieben.

Ein weiteres interessantes Thema:

Q) Help! What are the security implications referred to in the “chroot_local_user” option?
A) Firstly note that other ftp daemons have the same implications. It is a
generic problem.

The problem isn’t too severe, but it is this: Some people have FTP user accounts which are not trusted to have full shell access. If these accounts can also upload files, there is a small risk. A bad user now has control of the filesystem root, which is their home directory. The ftp daemon might cause some config file to
be read – e.g. /etc/some_file. With chroot(), this file is now under the control of the user. vsftpd is careful in this area. But, the system’s libc might want to open locale config files or other settings…

OK, hieraus verstehe ich, dass User mit “Shell” = “/bin/false” unter gewissen Umständen zu einem Problem werden können. (Auf anderen als Opensuse Systemen muss man ggf. /bin/fale auch in die Datei /etc/shells aufnehmen).

Tatsächlich ist es mir in einigen ersten schnell hintereinander durchgeführten experimentellen Anläufen mit Filezilla unter OS 12.2 gelungen, Dateistrukturen oberhalb des chroot-Verzeichnisses zu sehen, die ich eigentlich nicht mehr hätte sehen dürfen. Ich hatte dabei zunächst TLS abgeschaltet und den FTP-User auf “/bin/false” gesetzt und keine chroot-Einschränkung vorgenommen. Danach bei laufender Filezilla-Sitzung “chroot_local_user=YES” auf dem Server gesetzt und den FTP-Service per “systemctl restart vsftp.service” neu gestartet. Die Filzilla-Sitzung wird dabei unterbrochen – man kann sie aber sofort restarten. Und dann geschehen manchmal die seltsamsten Dinge bzgl. der Anzeige des Dateibaums. Und man sieht, wie gesagt, ggf. Dinge, die man nun nicht mehr sehen sollte. Irgendwie waren dabei wohl Filezilla- und Server-Caches im Spiel. Ein Refresh in Filezilla führte nämlich jedesmal zur Reduktion der Filesystem-Darstellung.

Was immer man daraus schließen mag … ich sehe es als jedenfalls wichtig an, dass an an chroot-Konfigurationen nicht im lauenden Betrieb rumgebastelt wird, wenn nicht sichergestellt ist, dass dann alle potentiellen Zwischenspeicher geleert sind. Man muss halt den svftp-Service sauber aufsetzen und nicht im produktiven Betrieb an Berechtigungen rumbasteln. Zudem ist der oben diskutierte grundsätzliche Entzug der Ownerschip und der Schreibrechte am chroot-Verzeichnis auch hier von Bedeutung: Waren die Rechte von vornherein richtig, d.h. restriktiv gesetzt, traten die beobachteten Probleme mit der Sicht auf unerlaubte Verzeichnisbereiche erst gar nicht auf.

Konsequenz: Entzug der Schreibrechte

Man nimmt dem FTP-User und auch der Gruppe, der er zugeordnet ist, die Schreibrechte am Heimatverzeichnis. Hier “/srv/www/htdocs/webs” und legt darunter ein oder mehrere schreibbare Verzeichnisse an. In meinem Fall kein Problem. (Was aber machen Leute, die nach einem Upgrade vorhandene Verzeichnisstrukturen nicht umorganisieren können oder wollen ?)

Unter OS 12.2 lief das Ganze dann in meinem Beispiel auch ohne Problem mit der dortigen PAM, der vsftp-Version 3.0.2-3.4.1 und dem Kernel 3.4.6.

Identische vsftp-version Konfiguration wie unter OS 12.2 läuft nicht unter OS 12.3 und Kernel 3.7.10

Nachdem der vsftp-Server unter OS 12.2 dann endlich so lief, wie ich mir das wünschte, und die Rechte auf hochgeladene Verzeichnisse und Dateien per vsftp-umask, SGID-Bit und setfacl so erzeugt wurden, wie ich das für sinnvoll und notwendig befand, wollte ich die gleiche Konfiguration auch unter Opensuse 12.3 zum Laufen bringen.

Erstmal ging zu meinem Schrecken aber gar nichts. Hier ein Auszug aus der Filezilla-Kommunikation mit dem Server:

Status: TLS/SSL-Verbindung hergestellt.
Antwort: 331 Please specify the password.
Befehl: PASS *******
Antwort: 230 Login successful.
Befehl: SYST
Antwort: 215 UNIX Type: L8
Befehl: FEAT
Antwort: 211-Features:
Antwort: AUTH TLS
Antwort: EPRT
Antwort: EPSV
Antwort: MDTM
Antwort: PASV
Antwort: PBSZ
Antwort: PROT
Antwort: REST STREAM
Antwort: SIZE
Antwort: TVFS
Antwort: UTF8
Antwort: 211 End
Befehl: OPTS
UTF8 ON
Antwort: 200 Always in UTF8 mode.
Befehl: PBSZ 0
Antwort: 200 PBSZ set to 0.
Befehl: PROT P
Antwort: 200 PROT now Private.
Status: Verbunden
Status: Empfange Verzeichnisinhalt…
Befehl: CWD /
Antwort: 250 Directory successfully changed.
Befehl: PWD
Antwort: 257 “/”
Befehl: TYPE I
Antwort: 200 Switching to Binary mode.
Befehl: PASV
Fehler: GnuTLS error -15: Ein unerwartetes TLS-Paket wurde empfangen.
Fehler: Verbindung zum Server getrennt: ECONNABORTED – Connection aborted
Fehler: Verzeichnisinhalt konnte nicht empfangen werden

Nach etlichen Recherchen fand ich dann, dass ab Kernel 3.5.X wohl der Parameter zur seccomp sandbox

seccomp_sandbox=NO

auf NO gesetzt werden muss, was ich allerdings für produktive Server etwas beunruhigend finde. Siehe auch:
https://bugzilla.redhat.com/show_bug.cgi?id=845980
und
https://bugzilla.novell.com/show_bug.cgi?id=806758
und
https://bugzilla.novell.com/show_bug.cgi?id=786024.

Jedenfalls können wir mit der genannten Einstellung dann auch unter OS 12.3 auf den vsftp-Server zugreifen.

Problem mit syslog_enable=YES

Als ich dann jedoch

syslog_enable=YES

setzen wollte, kam die nächste Überraschung. In Filezilla taucht danach nämlich folgende Meldung auf :

Status: Connecting to 192.168.0.37:21…
Status: Connection established, waiting for welcome message…
Response: 500 OOPS: priv_sock_get_cmd
Error: Critical error
Error: Could not connect to server

Tja, und dafür habe ich keine Lösung gefunden als eben

syslog_enable=NO

Logging muss man dann eben anders machen. Kann ich aber mit leben ….

Ältere Filezilla-Versionen vertragen die neue Standardoption “require_ssl_reuse=NO” nicht

Bei Filezilla-Versionen 3.5.X kommt es zu Problemen mit der FTP-Verbindung, wenn

require_ssl_reuse=YES

gesetzt ist. Das ist aber in den aktuellen vsftp-Versionen als “Default” der Fall. Hier hilft dann im Falle einer Fehlermeldung ein explizites :

require_ssl_reuse=NO

oder man muss sich unter OS 12.3 die aktuellere Filezilla Version 3.7.0.1 von folgendem Repository

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

installieren. Mit dieser neueren Filezilla-Version geht dann auch “require_ssl_reuse=YES”.
(Ergänzung 08.06.2013: Es geht zumindest besser. Gestern bekam ich aber auch mit der neuen Filezilla-Version bei einem längeren Transfer ein Problem.)

Fazit

Ich verstehe das Bestreben der vsftp-Entwickler nach maximaler Sicherheit gut. Aber das sollte nicht zu so vielen Problemen mit aktuellen Distributionen führen. Die Doku dieser Distributionen muss diesbzgl. auch besser werden und die erforderlichen Einstellungen und potentiellen Probleme in den Release-Notes beschreiben.

Wenn ich mal meine Erfahrungen auf produktive Systeme übertrage, stelle ich mir allerdings die Situation als schlimm vor, die entsteht, wenn solche Systeme auf OS 12.3 mit 3.5-Kernels upgegraded werden. Das dann entstehende Desaster hat evtl. schon einige Admins in den Wahnsinn
getrieben. Es war auf Basis der Fehlermeldungen nämlich nicht immer so leicht, sich die richtigen Einstellungen zusammenzureimen. Nicht gerade Werbung für Opensource !

Abschließender Hinweis zu vsftp-Tests mit Änderungen der Credentials des FTP-Users auf LDAP-Servern

Ein abschließender Hinweis noch zu Experimenten mit Änderungen an den Shell-Zuordnungen oder an den Credentials des FTP-Users:

Ich hatte meinen FTP-User über einen separaten LDAP-Server konfiguriert. Unter Opensuse 12.3 kommt SSSD zum Einsatz. In der Standardkonfiguration hatte SSSD bei mir auf dem Server mit vsftp die Credentials gecacht. Dann kann es bei geänderten Passwörtern zu Problemen kommen, wenn der Remote-FTP-Client das neue und auf dem LDAP-Server auch geänderte Passwort benutzt, aber der vsftp-Server wegen des sssd-Chachings von dem neuen Passwort ggf. noch nichts mitbekommen hat!

In einer solchen Situation muss man die SSSD-Cache-Information, z.B. zu einem User, gezielt mittels des Kommandos

sss_cache -u USER

löschen. Unter USER ist die User-Id anzugeben.
(Das Thema der Verwendung gechachter Information durch SSSD hat mich beim Testen von Zugriffsberechtigungen für bestimmte vsftp-User mal kurzzeitig außer Fassung gebracht und mir gezeigt, das sssd-Caching auch mal ein substanzielles Problem darstellen kann !)

Zu anderen Varianten des sss_cache Kommados für das Purgen von Cache-Daten in bestimmten SSSD-Domainen sehe man in die man-Seiten und
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-cache.html

Unter Opensuse muss man übrigens das Paket “sssd-tools” installieren, um “sss_cache” nutzen zu können.

Ergänzung 04.09.2013 zu Firewall-Einstellungen:
Wegen eines aktuellen Erlebnisses: Natürlich muss man auch die Firewalls sowohl auf dem Server als auch auf dem Client angemessen einstellen. So ist auf dem Server der Port 21 für die Clients zu öffnen – wie auch der Range der Ports > 1024, die für den passiven FTP-Austausch benutzt werden. Die entsprechenden Port-Festlegungen hat man in der “/etc/vsftp.conf” vorgenommen. Standardmäßig ist dort der Range

pasv_min_port=30000
pasv_max_port=30100

eingestellt. Aber natürlich kann ma auch einen anderen Range wählen. Man darf dann nur nicht vergessen, die Firewall(s) anzupasssen !

Ergänzung 07.11.2014 zum Parameter connect_from_port_20
Ein Leser hat mich darauf aufmerksam gemacht, dass die Einstellung

connect_from_port_20=NO

ein kleinen Sicherheitsvorteil bringen mag. Das wird ein wenig kontrovers diskutiert. Siehe z.B.:
http://forums.opensuse.org/showthread.php/466059-VSFTP-Not-Allowing-External-Connections
In vielen vsftpd Installationsanweisungen im Internet findet man aber die Einstellung “NO”. Da ich in der NO-Einstellung auch keinen gravierenden Nachteil erkennen kann, habe ich die oben angegebenen Einstellungen entsprechend abgeändert.

Opensuse 12.3, named, aktuelle Fehler

Posted on by

Hatte gerade nach Upgrades eines Opensuse 12.3-Servers ein Erlebnis der weniger netten Art:

Beim Versuch die DNS/Bind-Server-Konfiguration bzgl. neuer KVM-Gäste einer bestimmten Domaine upzudaten, erlitt ich Schiffbruch. Es kamen gleich zwei Fehler hoch.

Falsche Rechte auf dem Verzeichnis /var/lib/named

Einerseits konnte auf dem Arbeitsverzzeichnis /var/lib/named nicht geschrieben werden. Fehlermeldung unter “systemctl status named.service”:

named[11371]: the working directory is not writable

Das “Working Directory” dieses Services ist “/var/lib/named”. Siehe hierzu auch:
https://bugzilla.novell.com/show_bug.cgi?id=818283

Zur Behebung hilft

chown named.named /var/lib/named

Fehlende SuSEconfig.functions
Andererseits war es nicht mehr möglich, DNS-Einträge hinzuzufügen und den DNS/Named-Service neu zu starten. Fehlermeldung unter “systemctl status named.service”:

Error: Can not find /lib/YaST/SuSEconfig.functions!

Siehe hierzu auch:
https://bugzilla.novell.com/show_bug.cgi?id=814978

Ursache ist hier offenbar ein Rückgriff auf unter Opensuse 12.3 nicht mehr vorhandene Dateien SuSEconfig.functions unter /lib/YaST.

Ist doch Schei….. Was machen die denn bei SuSE? Das sind doch keine Kleinigkeiten, wenn der DNS-Service aufgrund solcher Bugs nicht mehr geht !

Wenigstens der letzte Bug ist in der aktuellen Named-Version aus dem Network-Repository
http://download.opensuse.org/repositories/network/openSUSE_12.3/
behoben.

Ich weiss nicht, was durch die vorhergehenden Upgrades aus dem Update-Repository für Opensuse 12.3 noch alles verpfuscht wurde – jedenfalls machte danach auch noch der DHCP-Service die Grätsche. Habe das dann daran gemerkt, dass die virtuellen KVM-Gäste auf dem Host zwar starteten, aber über das Netz nicht mehr erreichbar waren.

Musste den DHCP-Dienst komplett neu – und zwar in der ursprünglichen Version – installieren und neu aufsetzen. Danach ging dann ein Upgrade auf die aktuelle Version des DHCP-Servers aus dem OS12.3-Update-Repository wieder.