Keine Chance für Trafficdiebe

Wäre es nicht elegant Trafficdieben das Handwerk zu legen, indem wir Ihnen statt dem verlinkten Bild eine andere Datei unterschieben? Statt des gewünschten Fotos könntest du den Contentdieb auf diese Weise unfreiwillig ein Werbebanner für deine eigene Website einbinden lassen.

Voraussetzung für die beschriebene Technik ist ein Apache Webserver mit dem Modul mod_rewrite. Der Code kann entweder über .htacess oder direkt über die Apache-Konfigurationsdatei eingebunden werden.
Ersetze einfach domain.tld gegen die Domain deiner Website und stoppt_contentdiebe.png gegen den Namen der Grafik, die du Contentdieben unterschieben möchtest.



RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?domain.tld [NC]
RewriteCond %{REQUEST_FILENAME} !stoppt_contentdiebe.png$
RewriteRule .*\.(gif|jpg|png)$ http://domain.tld/images/stoppt_contentdiebe.png [R]



Erklärung zum Script

Zunächst prüfen wir anhand der Direktive filesmatch die Dateiendung gegen einen einfachen regulären Ausdrucks:

Damit erfassen wir alle aufgerufenen Dateien, die die Dateiendung .gif, .jpg oder .png tragen. Selbstverständlich ließe sich der Ausdruck um viele weitere Dateiendungen erweitern, deren direkte Verlinkung wir unterbinden möchten.

Im nächsten Schritt schalten wir die RewriteEngine an. Die RewriteEngine erlaubt es uns mittels RewriteCond verschiedene Parameter des HTTP-Request gegen reguläre Ausdrücke zu prüfen und bei Entsprechung die aufgerufene URL zu manipulieren.

Grundsätzlich müssen wir überprüfen, von welcher Domain aus das Bild verlinkt wurde. Dazu lesen wir den Parameter HTTP_REFERER aus. HTTP_REFERER gibt den Referrer, also die auf einen Link verweisende Domain an.

Getreu dem Motto “Was nicht erlaubt ist, ist verboten” können wir zwei Bedingungen für ein legitimes Verlinken der Fotos formulieren.

1. Wenn kein Referrer angegeben ist. Das ist der Fall, wenn beispielsweise durch einen Proxy gelöscht oder die URL direkt aufgerufen wurde.
2. Wenn der Referrer unserer eigenen Domain entspricht.

Wir können demnach folgende Bedienungen formulieren:

Der Referrer ist leer:

RewriteCond %{HTTP_REFERER} !^$


Der Referrer entspricht unserer eigenen Domain, wobei domain.tld gegen die Domain deiner Website zu ersetzen ist:

RewriteCond %{HTTP_REFERER} !^http://(www\.)?domain.tld [NC]


Damit die RewriteEngine sich nicht in einer endlosen Schleife verfängt, die letztlich mit einem Internal-Server-Error quittiert würde, müssen wir für das dem Trafficdieben unterzuschiebende Bild eine Ausnahme formulieren:

RewriteCond %{REQUEST_FILENAME} !stoppt_contentdiebe.png$

Sind alle Bedingungen erfüllt, greift folgende Regel, mit der wir alle fremdverlinkten Bilder gegen unseren Hinweis ersetzen.

RewriteRule .*\.(gif|jpg|png)$ http://domain.tld/stoppt_contentdiebe.png [R]

Viel eleganter und schneller lässt sich die Datei trotz mangelnder Zugriffsrechte direkt aus vim heraus abspeichern:
:w !sudo tee %

Ein kleine Befehlsfolge, die mir künftig viel Zeit sparen wird.

16:18:35 up 276 days, 2:47, 2 users, load average: 5.49, 4.99, 3.83

[ad]

USE master
EXEC xp_regread 'HKEY_LOCAL_MACHINE',
'SOFTWARE\Microsoft\Microsoft SQL Server\80\registration',
'CD_KEY'


Linux bietet mit dem Konzept der virtuellen Netzwerkinterfaces eine elegante Lösung, um an einen Netzwerkadapter viele IP-Adressen zu binden. Jede physikalisch Netzwerkkarte trägt einen eindeutigen Namen, etwa eth0 für die erste Karte oder eth1 für die zweite Netzwerkkarte. Für jede physikalische Netzwerkarte lassen sich mehrere virtuelle Interfaces mit einer eigenen IP-Adresse konfigurieren. Dazu ist das physikalische Interface (eth0, eth1, eth2 usw.) gefolgt von einem Doppelpunkt und der Nummer des zu erstellenden virtuellen Interface anzugeben. So bezeichnet eth0:1 das erste virtuelle Interface an der physikalischen Netzwerkkarte eth0 und eth1:5 das fünfte virtuelle Interface an der zweiten Netzwerkkarte eth1.

Die virtuellen Netzwerkschnittstellen lassen sich mit den gleichen Werkzeugen konfigurieren, wie ihre physikalischen Pendants.

Um beispielsweise manuell die IP-Adresse 192.168.35.100 an die Netzwerkkarte eth0 zu binden, genügt es folgenden Befehl mit root-Rechten auszuführen.

ifconfig eth0:1 192.168.35.200 netmask 255.255.255.0 broadcast 192.168.35.255 up

Möchte man die manuell vorgenommene Konfiguration dauerhaft hinterlegen, wäre unter Debian die /etc/network/interfaces wie folgt zu editieren:

auto eth0:1
iface eth0:1 inet static
address 192.168.35.200
netmask 255.255.255.0
broadcast 192.163.35.255


Wen das Verhalten als erfahrenen User nervt, kann es zum Glück abstellen:
Dazu genügt es in die Adresszeile about:config einzugeben folgende Einträge zu konfigurieren:

• browser.xul.error_pages.expert_bad_cert  = true
• browser.ssl_override_behavior = 2

Seit Einführung des Verfahrens vor 2 Wochen hat sich die Anzahl des Spam in den Postfächern der User von über 100 auf unter 10 reduziert.
Doch einen Pferdefuß hat das Greylisting: Ständig werde ich von meinen Kollegen gefragt, ob unser Mailserver denn noch liefe, sie hätten schon so lange keine E-Mail mehr erhalten.

Bevor wir beginnen, solltest du sicherstellen, dass du eine aktuelle SSH Version benutzt. Unter Debian genügt dazu der Einzeiler apt-get update; apt-get dist-upgrade. Unter anderen Distributionen stehen ähnliche Werkzeuge zum Update zur Verfügung wie etwas yast unter Suse.

Nun ist es an der Zeit die Konfigurationsdatei /etc/ssh/sshd_config zu bearbeiten. Ich werde im folgenden die sicherheitsrelevanten Optionen durchgehen und kurz kommentieren.

ListenAddress 217.79.182.18

Wenn ein Server mit mehr als einem Netzwerkinterface ausgestattet ist, kann es sinnvoll sein den Zugriff bestimmte Interfaces zu beschränken. Beim klassischen Webserver dürfte das allerdings nicht der Fall sein.

Port 2222

Standardmäßig lauscht der SSH-Dämon auf Port 22. Viele Bruteforceattacken gegen ganze Netzwerksegmente können durch Nutzung eines anderen Ports erfolgreich abgewehrt werden. Solche Angriffe gehen meist von Botnetzen oder bereits gekaperten Servern aus, die mit großer Bandbreite tausende Logins gegen Port 22 feuern. Dabei werden Standardbenutzernamen (admin, root, httpd, mail usw.) mit leerem Passwort oder Passwörter aus Wörterbüchern und Passwortlisten durchprobiert. Solche Angriffe können zwar einen sicher konfigurierten Server nicht gefährden, blähen aber die Logdateien auf, führen zu verminderten Reaktionszeiten und schlimmstenfalls können sich legitimierte Benutzer ob der vielen Anfragen nicht über SSH einloggen. Selbstverständlich bietet die Nutzung eines anderen Ports keinen Schutz gegen gezielte Brutforceangriffe, bei denen dem eigentlichen Angriff ein Portscan vorausgeht. Abhilfe können hier zum Beispiel sshblack schaffen oder eine Kombination von Snort, Netfilter und iptables. Da DoS-Attacken kein SSH-spezifisches Problem sind, werde ich an dieser Stelle nicht weiter darauf eingehen.

Protocol 2

Die Version 1 des SSH-Protokoll enthält Designschwächen, die einen unbefugten Login ermöglichen, und sollte darum nicht benutzt werden.

PermitRootLogin no

Es ist eine gute Idee root den Zugang über SSH zu verwehren. Denn wenn jemand gelänge sich über SSH unbefugt Zugang zum Server zu verschaffen, könnte er als unprivilegierter Nutzer nur begrenz Schaden anrichten. Da es ohnehin von Leichtsinn zeugt stets als root zu arbeiten, spricht auch wenig dafür den direkten Login als root zu erlauben. Wichtig ist auf einen frisch installierten System einen neuen Benutzer anzulegen, bevor wir über PermitRootLogin no root vom SSH-Login ausschließen.

AllowUsers tom thomasfalkner@thomas-falkner.de
AllowGroups admin

Wenn nur bestimmte Nutzer sich via SSH auf dem Server einloggen dürfen, können diese über AllowUsers bestimmt werden. Wenn Benutzer nur von einem bestimmten Host aus Zugang zum Rechner erhalten sollen, kann dass über user@host geregelt werden. Das kann sinnvoll sein, wenn ein Webdesigner sich nur aus dem Firmennetzwerk, nicht aber von zu Hause auf dem Server anmelden darf. Durch die Option AllowGroups kann der Login auf bestimmte Benutzergruppen beschränkt werden.
Sollen mehr Benutzer erlaubt als ausgeschlossen werden, ersparen die Gegenstücke zu AllowUsers und AllowGroups, DenyUsers und DenyGroups, eine Menge Tipparbeit.

Doch es ist nicht nur wichtig festzulegen, wer sich über SSH anmelden darf, sondern auch welche Authentifizierungsverfahren dazu genutzt werden sollen. Hier greift die Regle: Alles deaktivieren, was nicht benötigt wird.

Wer mit dem höchsten Sicherheitsstandard arbeiten möchten, sollte ausschließlich die PubKeyAuthentication nutzen und alle anderen Authentifizierungsverfahren ausschalten.

RhostsRSAAuthentication no
HostbasedAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
RSAAuthentication no


Obwohl die meisten Optionen wie etwa RhostsRSAAuthentication per Default abgeschaltet sind, halte ich es für sinnvoll sie explizit auf no zu setzen, um eine klare Konfiguration vor Augen zu haben. Ferner wäre es töricht davon auszugehen, dass die Defaulteinstellungen sich bei neueren Versionen nicht ändern würden. Updates sollten übrigens ohnehin nie ungeprüft eingespielt werden.

Bevor wir die Passwort basierte Anmeldung mittels PasswordAuthentication no und UsePAM no vollständig deaktivieren, muss zuerst die Anmeldung über PubKey konfiguriert und getestet werden – sonst laufen wir Gefahr uns selbst auszusperren.

Dazu ergänzen wir /etc/ssh/sshd_config wie folgt:

PubkeyAuthentication yes
Damit wird die Authentifizierungs per RSA- oder DSA-Schlüssel aktiviert.

AuthorizedKeysFile %h/.ssh/authorized_keys

Gibt an, wo die öffentlichen Schlüssel auf dem Server gespeichert werden.
Per Default im Homeverzeichnis des jeweiligen Benutzers unter .ssh/authorized_keys.

Nun sollte der der SSH-Dämon neu gestartet werden: sudo /etc/init.d/sshd restart

Damit ist der Server vorbereitet für den passwortfreien Login über Schlüssel. Was fehlt ist der Schlüssel, oder genauer gesagt das Schlüsselpaar. Da der private Teil des Schlüssels auf dem Client verbleibt und nur der öffentliche auf den Server kopiert wird, empfiehlt es sich das Schlüsselpaar auf dem Client zu erzeugen. Unter UNIX-Derivaten starten wir dazu unter dem Useraccount, der sich später auf dem Server einloggen können soll, ssh-keygen.

ssh-keygen -t dsa

Wenn die Voreinstellung bestätigt wird, legt ssh-keygen den private Schlüssel id_dsa als auch den öffentlich id_dsa_pub unter ~/.ssh ab. Die Frage nach der Passphrase kann mit 2x Return übergangen werden, wenn man den Schlüssel nicht mit einem Passwort schützen möchte. Eine generelle Empfehlung ob es sinnvoll ist den Schlüssel mit einem Passwort zu schützen oder nicht, ist schwer möglich. Wird kann Passwort vergeben, kann jeder sich auf dem Server anmelden, der in Besitz des Schlüssels ist. Soll heißen: Wird der Rechner, auf dem der private Schlüssel hinterlegt ist geknackt oder gerät in falsche Hände, steht dem Angreifer auch der Zugang zum Server offen.
Sind die Schlüssel mit einem Passwort zusätzlich geschützt, müsste der Angreifer erst das Passwort per Bruteforce knacken – was bei ausreichend starken Passwort nicht in angemessener Zeit möglich ist.
Das höhere Maß an Sicherheit erkauft man sich jedoch mit der lästigen Eingabe des Passworts beim Login über SSH.

Ist der Schlüssel je nach Gusto mit oder ohne Passpharse erzeugt, muss er auf den Server übertragen werden.

Zuerst prüfen wir, ob es in unserem Homeverzeichnis auf dem Server einen Order .ssh bereits gibt. Wenn nicht, legen wir ihn an. Dazu kann folgender Einzeiler vom Client aus abgesetzt werden:

ssh domain.tld -p2222 "test -d .ssh || mkdir .ssh && chmod 700 .ssh"

Wie oben erwähnt, gehe ich davon aus, dass der User auf dem Client den gleichen Namen trägt wie auf dem Server.
Aus Sicherheitsgründen ist es unerlässlich, dass die Zugriffsrechte des .ssh-Verzeichnisses auf 700 und die für authorized_keys auf 600. Ferner müssen sowohl Datei als auch Verzeichnis dem anzumeldenden User gehören.
Letztere Bedingung erfüllen wir, indem wir Verzeichnis und Datei selbst anlegen, die Zugriffsrechte indes sollten wir explizit setzen.
Auch das lässt sich zu einem Befehl zusammenfassen:
cat ~/.ssh/id_dsa_pub | ssh domain.tld -p2222 "cat >> .ssh/authorized_keys && chmod 600 .ssh/authorized_keys"

Der passwortlose Login sollte damit funktionieren.

Zu den Möglichkeiten von SSH lässt sich noch eine Menge schreiben. Zu gegebener Zeit an dieser Stelle mehr.