Mich begeistert die Möglichkeit mit CGI-Skripts Code auf dem Web-Server auszuführen. Beim Nachlesen im Internet bin ich allerdings auf die Gefahr, die von den CGI-Skripten ausgehen kann, aufmerksam geworden.

Wenn so ein Skript zum Beispiel von einem html-Formular aus gefüttert wird, und die übergebenen Parameter auswertet, dann kann ein Angreifer die volle Kontrolle über das Web-Server-System erhalten.

Beispiel: Man hat ein html-Formular, das mit der get-Methode Parameter an das CGI-Skript übergibt. Wenn der Angreifer dann einfach die URL mit beliebigem Code verlängert, dann könnte es (je nach Art der Programmierung) dazu kommen, dass der Server Aufgaben durchführt, die gar nicht vorgesehen waren.

eval $(echo $QUERY_STRING | sed ’s/%20/ /’) | while read; do echo $REPLY “< / br>“; done

Das wäre ein hübsches Beispiel dafür (ok, es ist sehr konstruiert, aber ok.) Wenn man an die Internet-URL ein ?ls -l anhängt, dann macht der Browser daraus: ?ls%20-l . Das Skript filtert das %20 wieder raus, und generiert ein Leerzeichen daraus. Anschließend wertet eval diesen Befehl aus. Die while-Schleife erzeugt die html-Zeilenumbrüche.

Der Angreifer könnte hier genauso gut weitere Befehle senden. Also, ich für meine Person werde in den CGI-Scripts ab sofort genau überprüfen, ob die gesendeten Parameter zulässig sind!

Nachdem ich mir viel Zeit gelassen habe, bin ich nun doch so mutig geworden, und habe einen ftp-Server mit Anonymous-ftp am laufen. Ein incoming Directory existiert auch. Wer mal schauen möchte, der klicke hier.
Klar, die Gefahr besteht, dass der Gute mißbraucht wird. So gut es geht, habe ich aber versucht ihn gegen sämtliche böse Vorhaben zu schützen.

Welcher Server ist in Betrieb? Ich habe mich für proftpd entschieden, da er einer der sichersten ftp-Server sein soll. Außerdem highly configurable.

Ich werde die Configuration des Servers hier nicht völlig veröffentlichen, sondern mich darauf beschränken, die Punkte aufzuschreiben, auf die ich geachtet habe.

< Limit Login >
Deny All
< / Limit>

Sämtliche Logins von Usern der Maschine werden unterbunden. Der Anonymous ftp ist changeroot jailed in /home/ftp, damit sollte auch kein Zugriff auf die anderen Verzeichnisse möglich sein. Alle Verzeichnisse haben per default nur Leserechte.
Für das incoming-Dir habe ich Schreibrechte erlaubt. Explizit verboten sind die ftp-Aktionen für Lesen, Löschen und Verzeichnis erstellen. Auf diese Weise dürfte dem Mißbrauch weitestgehend vorgebeugt sein. Wer also Files uploaden möchte, der kann dies tun. Damit ein Download möglich wird, ist zuerst der Admin (meine Wenigkeit) anzumailen. Ich kopiere dann die Files nach Outgoing, und fertig.

Damit dem Mißbrauch zusätzlich vorgebeugt wird, werde ich die Logfiles regelmäßig checken. Auf diese Weise kann ich schauen, was alles auf der Maschine los ist.

Hm, nichts desto trotz, ein etwas mulmiges Gefühl bleibt …

Es ist ja immer wieder interessant mal einen Vergleich zwischen Linux und Windows im Hinblick auf Performance vom Zaune zu brechen. Das haben ja glücklicherweise schon andere vor mir getan und dies im Internet veröffentlicht. (Ich könnte es eh nicht, da es mir an ausreichender Hardware mangelt.) Also habe ich mich auf diesen Bericht beschränkt. Daraus geht hervor, dass Samba 3 eine 2.5fach bessere Performance bietet, als Windows 2003 Server.

Gut, der Bericht ist schon 3 Jahre alt. Es begeistert mich aber trotz allem immer wieder, zu welchen Leistungen die Open Source Community fähig ist.

Aus meiner Sicht ist es nur sehr schade, dass ich so wenig Möglichkeiten habe, dies selbst zu überprüfen. Einen Server zu betreiben, der 20 oder mehr Clients bedient, das wäre mal was. Also Leute, laßt uns ein Netzwerk hochziehen!

Eigentlich wollte ich ja nur mit den neu gekauften Inlinern fahren. (Die Schwägerin war der Meinung, ich sollte das unbedingt tun, weil: lustig.)

Freilich, lustig war es - für die Zuschauer. Meine Güte, sieht doch bei all den anderen so easy aus. Naja, rumgerudert habe ich mit den Armen, dass es nur so eine Freude war. Jetzt weiß ich auch, warum Hubschrauber fliegen können. Wenn man schnell genug die Arme im Kreis dreht, fällt man auch nicht hin…

Windows ist ja immer so nervend höflich und fragt vor jeder Aktion: Wollen Sie wirklich löschen, umbenennen, herunterfahren, ihre Freundin betrügen, etc…

Also mich nervt das ja immer ohne Ende. Weil: Wenn ich will dann will ich. Und da soll doch das OS nicht ständig an meiner Kompetenz zweifeln.

Heute hat sich meine Einstellung zu Nachfragen dieser Art doch deutlich geändert. Da gibt es an den Shell-Tanksäulen doch tatsächlich zwei Rüssel, auf denen Diesel steht. Also: rein mit dem zweiten von links (im Hintergrund grübelte ich schon etwas: wozu eigentlich zwei Diesel-Rohre? Naja, ist wohl recht begehrt, der Diesel.)

Hm, beim Löhnen wurde mir das dann auch klar: V-Power-Diesel war’s. Und da habe ich für die (vermutlich) gleiche Suppe, 10 ct je Liter mehr gezahlt. Was in Summe etwa einem großen Starbucks-Cappuccino gleichkommt. Verd*.

Fazit: Ausnahmsweise wäre ich dankbar für eine Nachfrage gewesen: Wollen Sie wirklich V-Power tanken?

Nachdem ich ja das passende cgi-script geschrieben habe, um sämtliche Rechner in meiner Wohnung über das Internet starten zu können, sollte jetzt noch eins her, um die entsprechenden Rechner auch wieder runterfahren zu können. Das hat sich allerdings als deutlich schwerer dargestellt, als gedacht. Zum Runterfahren braucht es bekanntlich besondere Rechte. Also habe ich mir gedacht, ich mache es über ssh und public keys.

Dazu habe ich auf den Servern, die heruntergefahren werden sollen einen dummy-user angelegt:

adduser shutdownuser –disabled-password –disabled-login

Für diesen User wurde anschließend ein ssh-key erzeugt:

su shutdownuser
ssh-keygen -t rsa

Den private-key habe ich dann auf den Webserver kopiert, da von dort aus das cgi-script den shutdown-prozess anstoßen soll. Auf den herunterzufahrenden Rechnern war zuerst dem shutdownuser die Berechtigung für’s herunterfahren einzuräumen. Und zwar mußte in der /etc/sudoers folgender Eintrag hinzugefügt werden:

shutdownuser   ALL = NOPASSWD /sbin/shutdown

Damit darf der shutdownuser von allen Rechnern aus den shutdown-Befehl ohne Eingabe eines Passwortes ausführen.

Der Befehl im cgi-script sieht jetzt so aus:

ssh -i private_key_ID_file shutdownuser@Server_xy sudo shutdown -h now

Damit wird der shutdown-Befehl über ssh an den entsprechenden Rechner geschickt, und zwar unter der Kennung des shutdownusers. Das private ID-File des Shutdown-users muß mit der Option -i angegeben werden. Wichtig dabei: der Dienst des Webservers sollte der Owner des ID-Files sein, damit er es öffnen kann. Somit funktioniert auch das shutdown von Servern über den Webserver.