seeseekey.net - Invictus Deus Ex Machina

Von Zeit zu Zeit laufen Zertifikate ab. So auch in meinem Fall, als sich mein XMPP Client beschwerte, das dass Server-Zertifikat nicht mehr gültig ist. Um für ejabberd neue Zertifikate zu erzeugen, sollte man sich auf seinem Server einloggen und dort folgenden Zeilen eingeben:

openssl req -newkey rsa:2048 -keyout ejabberd.pem -nodes -x509 -days 365 -out ejabberd.cer
cat ejabberd.cer >> ejabberd.pem
cp ejabberd.pem /etc/ejabberd/ejabberd.pem

Anschließend kann der Dienst mittels:

service ejabberd restart

neugestartet werden. Das neue Zertifikat ist damit aktiv und der Dienst kann wieder genutzt werden.

Wenn man einen OpenVPN-Server in der Standardkonfiguration betreibt, wird man sich unter Umständen wundern, an welcher Stelle ist das OpenVPN Log zu finden ist. Das liegt daran das der OpenVPN-Server das ganze in /var/log/syslog speichert. Möchte man nun die OpenVPN betreffenden Punkte filtern so sollte man auf der Konsole folgendes eingeben:

grep VPN /var/log/syslog

Alternativ kann man auch die OpenVPN-Konfiguration anpassen. Dazu muss die Datei /etc/openvpn/server.conf bearbeitet werden. Dort gibt es eine Option log-append, welche wie folgt angepasst wird:

log-append /var/log/openvpn.log

Nach einem Neustart des Service mittels:

service openvpn restart

wird die neu eingestellte Logdatei genutzt.

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.

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.

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. Diese Schlüssel müssen auf den Wert 0 gesetzt werden. Nach einem Neustart des Betriebsystems sind die administrativen Freigaben dauerhaft verschwunden.

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

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.

Um die Versionsnummer eines installierten Postfix zu ermitteln, reicht es im Terminal folgendes einzugeben:

postconf -d mail_version

Anschließend erhält man eine Ausgabe nach dem Schema:

mail_version = 2.11.0

Da die Parameter aus der main.cf ausgelesen werden, ist es wichtig den Parameter –d anzugeben. So werden nicht die überschriebenen Werte zurückgegeben, sondern die Standardwerte, in diesem Fall die korrekte Versionsnummer.

Da sitzt man vor seinem Ubuntu-Upgrade und eine unbedachte Handbewegung später hat man das Upgrade abgebrochen. In einem solchen Fall sollte man das Upgrade natürlich fortsetzen, wer möchte schon gerne ein halbfertiges System. Wurde die SSH Verbindung unterbrochen, muss sich im ersten Schritt mit dem Server verbunden werden. Anschließend gibt man im Terminal folgendes ein:

dpkg --configure -a
apt-get dist-upgrade
apt-get autoremove
apt-get autoclean
reboot

Danach sollte der Server auf dem aktuellsten Stand sein und das Upgrade durchgeführt sein. Sollte man das Upgrade vor dem Umstellen der Paketlisten abgebrochen haben, dürfte ein einfaches „do-release-upgrade“ genügenum den Upgrade-Vorgang erneut zu starten.

Standardmäßig hört der Mail Transfer Agent Postfix auf dem Port 25. Möchte man nun das Postfix auch auf einem zusätzlichen Port hört, so muss man die „/etc/postfix/master.cf“-Datei bearbeiten. Dort sucht man die Zeile:

smtp      inet  n       -       -       -       -       smtpd

Unter der Zeile fügt man die Zeile:

587      inet  n       -       -       -       -       smtpd

hinzu. Anschließend muss der Dienst noch neugestartet werden:

service postfix restart

Damit hört Postfix neben Port 25 nun auch auf Port 587, dem bevorzugten Port für die Maileinlieferung von Clients.