Schlagwort: Server

Halber Erfolg

Hm, der letzte Post hat meinen Server wieder eingefroren und auch Seiten mit anderen Domains (etwa rb.autoren-net.de) waren temporär tot. Aber kein Fehlerlog und dieses Mal musste ich den Webserver nicht neu starten. Ich habe nur einige Package auf dem V-Server (u.a. auch Apache) aktualisiert, einige Plugins vorher schon dekativiert und nach einer Weile war er wieder erreichbar. Mittlerweile sind weitere Plugins deaktiviert bzw. gelöscht. Das wurde mittlerweile eine richtige Unordnung. Mal sehen, ob dieser Post aus WordPress dann keine Probleme mehr macht oder weiter ein Post für Magenverstimmung bei Apache sorgt.

Edit: Die Magenverstimmung ist noch da, aber nicht mehr so schlimm. Posten führt dazu, dass gut 1 Minute Schicht im Schacht ist, aber dann scheint es wieder zu gehen. Vielleicht ist auch MySQL bzw. MariaDB schlecht. Werde mal über alle DB eine automatische Reparatur laufen lassen.

Log4shell oder warum angeblich das Internet brennt

Die Medien berichten mal wieder über einen Hacker-Angriff. Oder genauer – eine Schwachstelle in Log4J, über die wohl im Moment ziemlich viele Angriffe auf Server gefahren werden. Log4J bezeichnet eine sehr oft eingesetzte Java-Bibliothek zum Protokollieren von Serverzugriffen.

Schon eigenartig, aber es sieht so aus, als hätte ich etwas von Nostradamus. Denn gerade halte ich zwei Schulung zu JavaScript und in der Einleitung zu solchen Schulungen erzähle ich immer davon, wie stark JavaScript in der Vergangenheit unterschätzt wurde. Und dass man immer mehr Projekte finden kann, bei denen JavaScript zum Einsatz kommt und sogar teils Java verdrängt, da JavaScript schlanker und vor allen Dingen einfacher und wartbarer ist. M.W. steigt etwa Paypal seit Jahren Server-seitig immer mehr von Java auf JavaScript um.

Das zweite eigenartige Phänomen ist, das ich bei JavaScript immer die Build-In-Funktion eval vorstelle – mit dem Merksatz „Eval ist evil“. Denn damit ist Code injection ein Kinderspiel – wenn freie Daten eingegeben werden können. Auch beim Server.

Und Punkt Nummero 3 ist, dass ich mit Node.js letzte Woche in der Schulung ein kleines Protokollier-Skript für einen Webserver unter Node.js vorgestellt habe. Also so etwas wie Log4J-Light mit JavaScript.

Als hätte ich es geahnt, dass die Sache am Wochenende nach meinen Schulungen ein großes Thema wird. Oder haben die Hacker sich bei meiner Schulung die Anregung geholt? Muss mal meine Schulungsteilnehmer befragen, ob die eine Praxisübung machen wollten und die aus dem Ruder gelaufen ist ;-).

Ach nein – Log4J ist ja Java – und kein JavaScript.

Es tut gut, wenn man seit Jahrzehnten Fan des lange verlachten JavaScript ist und nun JavaScript sich als sicherer und vor allen Dingen schlanker und wartbarer erweist als die hochgelobten, schwergewichtigen Konkurrenten. Bei denen kann man oft in den Unmengen an Code einfach nicht mehr erkennen, wie die Geschichte wirklich abläuft. Und daraus resultieren eben Schwachstellen und Sicherheitslücken, die in einem schlankeren System viel schneller aufgedeckt und beseitigt werden können.

Aschenbrödel hat sich durchgesetzt.

SFTP-Einstellung – die Nachwehen vom Server-Umzug

Ich bin bereits vor einigen Monaten mit meinem Server bzw. V-Server umgezogen, aber einige Sachen sind noch immer nicht ganz aufgeräumt bzw. vollständig eingerichtet. Etwa der FTP-Zugang. Ich habe aus Sicherheitsgründen sowieso mittlerweile (weitgehend) auf SFTP umgestellt, aber genau da gab es Probleme.

Als root konnte ich mich mit SFTP einloggen, aber die Dateien und Verzeichnisse nur ansehen und nicht runterladen bzw. irgendetwas hochladen. Bei ein paar Verzeichnissen bzw. Domain hat FTP funktioniert – mit verschiedenen Usern, bei anderen nicht. Und SFTP ging mit anderen Usern gar nicht. Aber ich konnte den zentralen Fehler irgendwann identifizieren.

ERROR: Received unexpected end-of-file from SFTP server

Die Suche danach in Internet hat zur Lösung geführt. Auch wenn die bei mir etwas anders gelagert war als in den Quellen beschrieben. Aber im Kern war es das – in der Konfiguration des SSH-Daemons gab es ein Problem. Da wurde was bei der Installation des V-Servers durch den Provider nicht ganz korrekt konfiguriert.

Ein Lösungsvorschlag war, in der Datei /etc/ssh/sshd_config nach dem folgenden Eintrag zu suchen:

# Subsystem sftp /usr/lib/openssh/sftp-server

Auskommentieren beibehalten und das folgende ergänzen, war der Tipp:

Subsystem sftp internal-sftp

Dumm nur, dass der Kommentar bei mir nicht gesetzt war. Das SFTP-Subsystem war also schon aktiv.

Eine andere Quelle hat die Zeile genannt:

Subsystem sftp /usr/libexec/openssh/sftp-server

Und das hat mich zu der Lösung geführt, die für meinen Server gepasst hat. Denn diese Pfadangabe gab es bei mir nicht. Folge – ich habe verstanden, was es dem ersten Fall mit dem Verweis auf das interne SFTP auf sich hat.

Die Lösung bei mir war, den SFTP-Server von OpenSSH auszukommentieren, auf das interne SFTP umzustellen und dann mit

service sshd restart

den SSH-Daemon neu zu starten.

Jetzt scheint der Zugang mit SFTP bei allen Domains bzw. allen eingerichteten Usern zu funktionieren.