Auf Shellshock testen

Möchte man Testen ob man vom Shellshock-Fehler betroffen ist, gibt man auf der Konsole folgendes ein:

env x="() { :;} ; echo Anfällig für Shellshock" /bin/sh -c "echo Shellshock-Test"

Wenn man betroffen ist gibt diese Kommandozeile:

Anfällig für Shellshock
Shellshock-Test

aus. Ist man nicht betroffen erhält man folgende Ausgabe:

Shellshock-Test

Versuche Shellshock von Außen zu nutzen kann man feststellen indem man seine Logdateien nach diesem Beispiel:

cat logfile.log | grep };

abgrast. Bei einem Webserver Log könnte das ganze dann z.B. so aussehen:

192.168.1.15 - - [27/Sep/2014:19:32:19 +0200] "GET / HTTP/1.1" 200 18804 "-" "() { foo;};echo;/bin/cat /etc/passwd"

Alternativ kann man ein Skript nutzen, welches von einem Golem Autor erstellt wurde. Der Quelltext für das Skript ist dabei auf GitHub zu finden.

Re-run your boot loader

Bei einer Aktualisierung eines Ubuntusystems mittels des Paketmanagers wurde der Vorgang am Ende mit der Zeile:

The link /vmlinuz.old is a damaged link
Removing symbolic link vmlinuz.old 
 you may need to re-run your boot loader[grub]

abgeschlossen. Die Lösung für das Problem ist dabei relativ unkompliziert. Es reicht auf der Konsole:

update-grub

einzugeben. Damit wird die menu.lst erneut geschrieben.

Administrative Freigaben deaktivieren

Unter Windows wird für jedes Laufwerk beim Start eine administrative Freigaben angelegt (die berühmten C$, D$). Diese Freigaben können in der Computerverwaltung gelöscht werden, allerdings werden sie beim Neustart wieder neu angelegt. Möchte man dies verhindern, muss der Registry Editor gestartet werden und dort der Pfad:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters

geöffnet werden. Je nach System (Server-Betriebssystem oder Workstation) muss dann ein neuer DWORD-Schlüssel anlegt werden. Für Server (z.B. Windows Server 2012) ist dies der Schlüssel:

AutoShareServer

Bei den normalen Systemen (z.B. Windows 7) hingegen muss der Schlüssel:

AutoShareWks

genutzt werden. Ist der Schlüssel nicht vorhanden muss er mit dem Datentyp DWORD angelegt werden. Diese Schlüssel müssen auf den Wert 0 gesetzt werden. Nach einem Neustart des Betriebssystems sind die administrativen Freigaben dauerhaft verschwunden.

Probleme mit der Bucket Size unter Nginx

Als ich meinen Nginx-Server neustarten wollte, wurde dies vom System mit einem Fehler quittiert. In der entsprechenden Logdatei (/var/log/nginx/error.log) fand sich folgende Meldung:

could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32

Die Größe die im Parameter server_names_hash_bucket_size definiert ist, beträgt im Standardfall 32 oder 64. Um den Fehler zu beseitigen muss die Konfigurationsdatei von Nginx geöffnet werden:

nano /etc/nginx/nginx.conf

Dort sollte man den Wert auf 64 oder 128 stellen und Nginx anschließend neustarten. Damit ist der Fehler behoben. Benötigt wird diese Option für die Größe der Hashtabellen in welchen die Servernamen gespeichert werden.

Weitere Informationen gibt es unter:
http://nginx.org/en/docs/http/server_names.html
http://nginx.org/en/docs/http/ngx_http_core_module.html#server_names_hash_bucket_size

Passwort-Authentifikation per SSH deaktivieren

Wenn man sich für seinen SSH Zugang nur noch mit einem entsprechenden Schlüsselpaar anmeldet, kann man die Authentifikation per Passwort deaktivieren. Dazu wird die „/etc/ssh/sshd_config“-Datei in einem Editor geöffnet:

nano /etc/ssh/sshd_config

Dort wird die Option:

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

gesucht und in:

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

geändert. Anschließend muss der SSH Server mittels:

service ssh restart

neugestartet werden. Damit ist die Anmeldung per Passwort nicht mehr möglich und der Server ein Stück sicherer.