Jun 16
Für (private) ADSL-Anschlüsse liefert die Telekom Austria das Thomson TG585 v7 aus. Wer nicht die DNS-Server des Providers verwenden möchte, sondern z.B. einen Filter zum Schutz vor Malware-Seiten oder eine Korrektur für Tippfehler in Domains haben möchte, kann die Nameserver von OpenDNS kostenlos verwenden. Diese Änderungen sind nur sinnvoll, wenn man nur einen Internetanschluss und kein aonTV hat, da letzteres sonst nicht mehr funktioniert. Um die DNS-Server zu konfigurieren verbindet man sich via Telnet mit dem Modem – hierfür tippt man in die Konsole/Eingabeaufforderung/Terminal den Befehl “telnet dsldevice” oder “telnet 10.0.0.138″. Daraufhin werden Benutzername und Passwort abgefragt – beide Felder lässt man leer. Als nächstes fügt man die OpenDNS-Nameserver mit den Befehlen “dns server route add dns=208.67.222.222 metric=0 intf=INTERNET” und “dns server route add dns=208.67.220.220 metric=0 intf=INTERNET” hinzu. Mit dem Befehl “dns server route list” kann man die aktuelle Nameserver-Konfiguration anzeigen lassen – auf diesem Modem:
DNS Server Entries:
DNS Server Source Label Metric Intf State Domain
S 208.67.222.222 0 INTERNET UP *
S 208.67.220.220 0 INTERNET UP *
D 10.156.0.33 10 MGMT UP *
D 10.156.0.49 10 MGMT UP *
D 194.48.139.254 30 INTERNET UP *
D 194.48.124.200 30 INTERNET UP *
Abschließend speichert man die Konfiguration mit dem Befehl “saveall” und beendet die Telnet-Sitzung mit “exit”. Ruft man nun die Seite http://www.opendns.com/welcome/ auf, wird die Meldung “Welcome to OpenDNS!” angezeigt, wenn die Konfiguration erfolgreich war. Weitere Konfigurationsanleitungen findet man in der Knowledge Base von OpenDNS.
Jul 29
Mit der Version 4.1 fanden Zeichensätze Einzug in MySQL. Man möchte meinen mit der gewünschten Einstellung von Datenbank- bzw. Feld-Kollationen seien alle Probleme beseitigt, dem ist aber nicht immer so. Zeichensätze führen häufig zu Problemen, da mehrere Komponenten beteiligt sind und somit an vielen Stellen die korrekte Angabe nötig ist, z.B. auch bei der Auslieferung des HTMLs an den Browser. Die häufigsten Problem treten aber in Verbindung mit MySQL auf.
Vor der Einführung von Zeichensätzen in MySQL wurden alle Daten als ISO-8859-1 gespeichert. Der MySQL-Client führt deshalb in der Standardkonfigurationen Anfragen an den Server weiterhin mit diesem Zeichensatz durch, um die Kompatiblität aufrecht zu erhalten. Ist nun die Kollation seitens des MySQL-Servers auf UTF-8 eingestellt, führt es unweigerlich zu Problemen, wenn der MySQL-Client mit diesem in ISO-8859-1 kommuniziert. Deshalb ist es notwendig, nach der Initalisierung der Verbindung den korrekten Zeichensatz für die Verbindung festzulegen – die geschieht mit:
SET NAMES 'UTF-8'
Diese Abfrage überschreibt für die aktuelle Verbindung die Standardeinstellung für character_set_client, character_set_connection und character_set_results. Alternativ wäre es natürlich auch möglich die Konfiguration entsprechend anzupassen und standardmäßig auf UTF-8 einzustellen. Aus Kompatibilitätsgründen sollte man darauf verzichten, solange nicht wirklich alle darauf zugreifenden Komponenten mit dieser Einstellung umzugehen wissen. Denn eine Kommunikation mittels UTF-8 mit einer ISO-8859-1-Datenbank führt unweigerlich zum selben Problem.
Apr 09
Bei HostEurope wird für vServer Virtuozzo zur Virtualisierung verwendet. Dieses setzt bei jedem Start die Dateien “/etc/hostname” und “/etc/resolv.conf” neu, d.h. geänderte Konfigurationseinstellungen gehen bei jedem Neustart verloren. Abhilfe schafft ein kleines Startup-Skript, das in “/etc/init.d/hostname-vps.sh” mit folgendem Inhalt abgelegt wird:
#!/bin/bash
if [ -f /etc/hostname.override ]
then
cp /etc/hostname.override /etc/hostname
cat /etc/hostname | xargs /bin/hostname
fi
if [ -f /etc/resolv.conf.override ]
then
cp /etc/resolv.conf.override /etc/resolv.conf
fi
exit 0
Wenn die Datei “/etc/hostname.override” existiert, so ersetzt diese die Datei “/etc/hostname”. Selbiges gilt analog für “/etc/resolv.conf.override” und “/etc/resolv.conf”. Damit dieses Skript beim Starten ausgeführt wird, müssen noch Links in den entsprechenden Runlevel-Ordner hinzugefügt werden. Debian stellt hierfür das Tool “update-rc.d” zur Verfügung:
# update-rc.d hostname-vps.sh defaults 09
Nun müssen noch die override-Dateien mit den gewünschten Optionen angelegt werden. Anschließend kann das System neu gestartet und die Funktionalität überprüft werden:
# reboot
Feb 14
Remote-Management (RMC) bzw. Light Out Management (LOM) wird vor allem in Servern in Rechenzentren eingesetzt, insbesondere dort wo eine Anwesenheit eines Administrator nicht (immer) möglich (z.B. Mietservern) oder zu teuer ist – allgemein um (eine große Anzahl an) Server ferngesteuert (remote) betreuen und betreiben zu können. LOM überwacht laufend den Zustand des Systems, die bereitgestellte Funktionalität (Ein-/Ausschalten, Überwachung von Temperaturen, KVM, Booten von Medien über IP, Verhalten im Problemfall,…) ist vom Hersteller abhängig. Damit diese Technik funktioniert, handelt es sich um ein völlig autonomes System im Server, das über unabhängige Anschlüsse (Netzwerk und Strom) verfügt, sodass eine Erreichbarkeit auch bei ausgeschalteter Server-Hardware oder Defekt gewährleistet ist. Üblicherweise ist LOM nur im höheren Preissegment und für den Dauerbetrieb ausgelegten Systemen verfügbar.
Bedeutende Hersteller von Servern bieten LOM-Funktionalität unter folgenden Namen:
Feb 02
In alten Versionen war es möglich, dass RealURLs “baseURL” automatisch gesetzt wurde, indem man ihr den Wert “1″ zuwies. Das wurde allerdings als Sicherheitsrisiko eingestuft und deshalb besteht diese Möglichkeit in aktuellen Versionen nicht mehr. Die Anzahl der Domains sollte sich allerdings in Grenzen halten und man kann mit TYPO3-Conditions das Problem der unterschiedlichen URLs umschiffen:
config.baseURL = http://www.blogix.net/
[globalString = ENV:HTTP_HOST = www.example.com]
config.baseURL = http://www.example.com/
[globalString = ENV:HTTP_HOST = www.example.net]
config.baseURL = http://www.example.net/
[global]
In diesem Beispiel wird standardmäßig der URL http://www.blogix.net/ als baseURL verwendet. Wird die Seite über die Domain “www.example.com” aufgerufen wird “http://www.example.com/” verwendet, für die Domain “www.example.net” “config.baseURL = http://www.example.net/”.
Nun möchte ich noch auf das oben genannte Sicherheitsrisiko eingehen – da es keine offizielle Stellungnahme zum Problem gibt, hier meine Vermutungen, wie die automatische Konfiguration eigentlich nur zu einem Sicherheitsproblem werden kann:
Voraussetzungen am Server:
- Der Webserver muss die TYPO3-Seite IP-basiert und nicht domainbasiert ausliefern, d.h. ein Aufruf der IP-Adresse im Browser würde die TYPO3-Seite zeigen.
- Cache muss in TYPO3 aktiviert sein, warum sehen wir gleich.
Der Angriff:
- Eine Domain so einrichten, dass sie auf die IP-Adresse des Servers verweist – da der Server IP-basiert und nicht domainbasiert auf die Anfrage antwortet, liefert dieser die TYPO3-Seite aus.
- Die TYPO3-Seite über die in Schritt 1 eingerichtete Domain per Browser oder Skript aufrufen – nun müsste die Seite im Cache landen, dieser “vergiftet” werden, damit weitere Schritte des Angreifers zu seinem Erfolg führen.
- Die in Schritt 1 eingerichtete Domain wird nun umkonfiguriert, sodass sie auf eine böse Seite (z.B. Malware oder eine Konkurrenzseite) zeigt.
Der Besucher und die Weiterleitung:
- Die TYPO3-Seite wird über die bekannte Domain aufgerufen.
- Eingebundene Bilder kommen von bzw. Links führen zu der Domain des Angreifers, da die baseURL aus dem “vergifteten” Cache von TYPO3 stammt.
Das Problem kann meiner Meinung nach nur entstehen, wenn der Webserver die TYPO3-Seite IP-basiert ausliefert. D.h. bei ausschließlich domainbasierter Auslieferung führt oben genanntes Szenario nicht zum Erfolg des Angreifers und die Verwendung der automatischen Konfiguration wäre meiner Meinung nach sicher. Dass kein weiteres Szenario für einen erfolgreichen Angriff existiert, kann ich nicht ausschließen. Mit dem Plugin “lt_basetag” kann die automatische Konfiguration wieder aktiviert werden – Verwendung natürlich auf eigene Gefahr.
Recent Comments