seeseekey.net - Invictus Deus Ex Machina

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.

Wenn man eigenen Server eingerichtet hat, auf welchem auch Webdienste laufen, so möchte man diese eventuell einem Lasttest unterziehen, damit man sieht wo die Grenzen des Servers bzw. des entsprechenden Setups liegen.

Ein mit loader.io durchgeführter Test

Mit dem Dienst loader.io ist möglich seinen Webserver unterschiedlichsten Lasttest zu unterziehen. In der kostenlose Variante sind die maximalen Anfragen begrenzt, allerdings sind die Begrenzungen so hoch gewählt, das ein sinnvoller Test ohne Probleme möglich ist. Lasttest fremder Server sind auch nicht möglich, da man die entsprechende URL vorher verifizieren muss, in dem man eine bestimmte Datei auf dem Webserver ablegt oder alternativ die DNS-Konfiguration anpasst.

Dank der Heartbleed-Sicherheitslücke, sollten Applikationen welche OpenSSL nutzen, neue Zertifikate erzeugen. Dies trifft auch auf den Mailserver Dovecot zu. Um hier ein neues Zertifikat zu erzeugen gibt man im Terminal folgendes ein:

openssl req -new -x509 -days 3650 -nodes -out /etc/dovecot/dovecot.pem -keyout /etc/dovecot/private/dovecot.pem

Die zeitliche Gültigkeit des Zertifikats sollte man dabei je nach seinen Bedürfnissen über den Parameter „days“ anpassen. Anschließend muss Dovecot neugestartet werden:

service dovecot restart

Nach dem Neustart wird das neue Zertifikat genutzt.

Weitere Informationen gibt es unter:
http://wiki2.dovecot.org/SSL/CertificateCreation

Für Ubuntu sind eine Reihe von Proxyservern verfügbar. Die meisten dieser Dienste sind relativ schwergewichtig, was sich unter anderem auf die Konfiguration auswirkt. Tinyproxy und Polipo dagegen gehören zu den leichtgewichtigeren Varianten. Tinyproxy scheidet allerdings aus, da er keine Authentifikation anbietet. Es existiert zwar ein entsprechender Bugreport, aber augenscheinlich wird dieser nicht bearbeitet. So bleibt nur noch Polipo. Um dieses einzurichten muss es im ersten Schritt installiert werden:

apt-get install polipo

Anschließend kann die Konfiguration bearbeitet werden

nano /etc/polipo/config

In diesem Fall soll ein Server konfiguriert werden welcher von außen mittels Authentifizierung erreichbar ist. Dazu müssen folgende Optionen aktiviert werden:

### Basic configuration
### *******************

proxyAddress = "::0"        # both IPv4 and IPv6

### Authentification
### *******************

authCredentials=seeseekey:geheim

Nachdem die Konfiguration geändert wurde muss der Dienst neugestartet werden:

service polipo restart

In den Proxyeinstellungen für die Clientseite muss der Server, Port, Nutzername und das Passwort angegeben werden. Polipo nutzt dabei standardmäßig den Port 8123. Bei der Authentifizierung sollte man beachten das diese unverschlüsselt erfolgt und somit nicht wirklich sicher ist.

Die Proxy-Einstellungen von FoxyProxy

Für den Firefox empfielt sich auf Clientseite das AddOn FoxyProxy, welcher die Proxy-Konfiguration von Firefox erheblich verbessert. Damit auch DNS-Anfragen beim Proxy aufgelöst werden, sollte unter „about:config“ die Option „Network.proxy.socks_remote_dns“ auf true gesetzt werden. FoxyProxy erledigt dies in der Standardeinstellung automatisch.

Weitere Informationen gibt es unter:
http://wiki.ubuntuusers.de/Polipo

Betreibt man einen Minecraft-Server auf einem Ubuntu basierten Server, so möchte man meist, das dieser mit dem Server startet. Dafür benötigt man ein Init-Skript. Natürlich kann man sich dieses selbst schreiben und damit einige Minuten bis Stunden verbringen. Mit Hilfe des in der Minecraft Wiki stehenden Skriptes geht das ganze aber wesentlich schneller. Auf der entsprechenden Seite der Wiki findet sich das Skript neben einer Installationsanleitung. Wenn man das ganze auf seinem Server eingerichtet hat, startet Minecraft automatisch und kann mittels des „service“-Kommandos kontrolliert werden.