KategorieAllgemein

Wie kann man bei DomainFactory auf die Datenbank in einem anderen Auftrag per PHP zugreifen?

Bei vielen Hostern kann man auf alle Datenbanken des Hosters, so man die Zugangsdaten hat, zugreifen. Bei einigen Hostern kann man sogar externen Zugriff auf die Datenbanken gestatten.
Bei DomainFactory geht das leider nicht ohne Weiteres. Auch wenn eine Konfigurierbarkeit der Zugriffsmöglichkeiten wünschenswert wäre, muss man doch auf die etwas unhandliche Variante des SSH-Tunnels zurückgreifen.

Sofern man auf der Konsole per SSH arbeitet, ist das nicht weiter schwierig. Auf Server A einfach

eingeben, dass passende Kennwort für den SSH-Benutzer auf Server B eingeben und fertig.

Wenn man jetzt auch gleich noch den Datenbankzugriff auf eine MySql5-DB auf Server B haben möchte, sieht das dann so aus:

Anschließend lässt sich über den Host 127.0.0.1 auf Port 3307 auf die Datenbanken auf Server B zugreifen.

Wenn man nun das Ganze in PHP abbilden möchte, lernt man schnell, dass man zwar mit shell_exec() die SSH-Verbindung anstoßen kann, aber eben nicht das Kennwort übergeben kann.

Die Lösung ist eigentlich ganz einfach. Man generiert entsprechende Schlüssel und anschließend funktioniert der Zugriff ohne Eingabe eines Kennwortes.

Folgendes ist zu tun.

Auf Server A (von dem aus auf Server B zugegriffen werden soll) auf der Konsole:

eingeben und alle Abfragen mit [RETURN] bestätigen.
Es werden dann im Verzeichnis .ssh zwei Dateien abgelegt. Der private Schlüssel id_rsa und der öffentliche Schlüssel id_rsa.pub.

Die Datei id_rsa.pub muss anschließend auf den Server B in das Verzeichnis .ssh kopiert werden und anschließend in authorized_keys umbenannt werden. Sollte die Datei authorized_keys schon bestehen, so ist die id_rsa.pub mit der authorized_keys zu konkatenieren.
Anschließend muss das Verzeichnis .ssh noch auf die Rechte 0700 und die Datei authorized_keys auf die Rechte 0600 gesetzt werden.

Ein Test auf der Konsole von Server A mit

sollte nunmehr eine SSH-Vergbindung mit Server B ohne Rückfrage nach einem Passwort aufbauen.

Sofern das alles funktioniert, kann man nunmehr per PHP den SSH-Tunnel aufbauen und sich dann mit der Datenbank verbinden:

Das „2>&1“ kann man weglassen. Es sorgt lediglich dafür, dass in Verbindung mit der Option -v die Ausgaben der Konsole tatsächlich zurückgegeben werden.
Bei der mysqli-Verbindung muss zwingend 127.0.0.1 statt localhost angegeben werden, da ansonsten versucht wird, eine Socket-Verbindung statt einer Verbindung über Port 3307 aufzubauen, was natürlich nicht funktioniert.

PHP-Codeschnipsel, die man immer mal wieder braucht

Datumsumwandlung ziwschen MySQL- und deutschem Format

MySQL nach deutsch

Deutsch nach MySQL

Einfache Suchmuster mit RegExp für width und height

In älteren HTML-Dateien findet man gern noch fixe Angaben zu Höhen (height) und Breiten (width).

Um diese mit einem RegExp-fähigen Editor (bspw. Notepad++) zu suchen und ggfls. zu löschen oder zu ändern, helfen diese Suchbegriffe:

height=\"[0-9/. \-]*\"
width=\"[0-9/. \-]*\"
style=\"width\:[0-9/. \-]*px\;\"
style=\"height\:[0-9/. \-]*px\;\"

Pear Mail_Mime und das Encoding der Empfängeradresse (to) mit Umlauten – natürlich auch für weitere Header-Parameter

Gleichwohl man annehmen könnte, dass das Encoding von Umlauten heutzutage – zumindest, sofern man UTF-8 benutzt – selbstverständlich sein sollte, stößt man immer wieder mal Probleme.

Aktuell hatte ich ein kleines Skript, dass per PHP über Mail-Mime Multipart-Mails verschickt. Alles lief rund vier Wochen glatt, bis auf einmal eine Mail partout nicht rausgehen wollte. Stattdessen hat mir der Server freundlicher Weise einen 500er geworfen.

Wie sich nach eingehender Recherche herausstellte, lag es an der Empfängeradresse, welche ich in der Form „Vorname Nachname <email@domain.tld>“ übergab. Der Nachname enthielt nun leider ein ß. Soll ja vorkommen…

Google hin, google her, das Problem war zwar erkannt, wollte sich aber gar nicht so einfach lösen lassen. Ein Encoding über imap_8bit() brachte nicht den erwünschten Erfolg.

Im Endeffekt tat es dann folgende kleine Funktion:
function mb_mime_header($string, $encoding=null, $linefeed="\r\n") {
if(!$encoding) $encoding = mb_internal_encoding();
$encoded = '';
while($length = mb_strlen($string)) {
$encoded .= "=?$encoding?B?"
. base64_encode(mb_substr($string,0,24,$encoding))
. "?=$linefeed";
$string = mb_substr($string,24,$length,$encoding);
}
return $encoded;
}

welche ich folgendermaßen nutze

$to=mb_mime_header("Name der Empfängers","UTF-8")." <email@domain.tld>";

Wie kann ich ein php-basiertes Content-Management-System (bspw. WordPress, Joomla, Typo3 etc.) nach einem Hackerangriff von Malware befreien?

Nach einem Hackerangriff und entsprechendem Malware-Befall ist guter Rat meist teuer. Oftmals wird der eigene Webauftritt durch den Provider gesperrt, so dass man nicht irgendein Plugin installieren kann, um die Probleme zu beheben.

Es bleibt nur die gute alte Handarbeit, falls es nicht ein garantiert Malware-freies Backup gibt. Und auch dieses Backup ist nur die halbe Miete, da der Angreifer diese Version ja offensichtlich problemlos infiltrieren konnte.

Variante A – Ihr habt ein aktuelles, garantiert sauberes Backup

Wenn Ihr diesbezüglich sicher seid, dann löscht den gesamten Webauftritt per FTP und leert die zugehörigen DB-Tabellen bspw. per PHPMyAdmin.

Anschließend kopiert Ihr das saubere Backup per FTP auf den Server, legt per .htaccess einen Verzeichnisschutz auf den gesamten Auftritt und spielt dann das DB-Backup ein.

Ihr habe jetzt wieder eine laufende Installtion Eures CMS, auch wenn diese von außen nicht für Andere zugänglich ist. Installiert nunmehr sämtliche Updates für Euer CMS, die Plugins, Themes / Templates etc.

Härtet Eurer CMS durch die Installation eines entsprechenden Plugins (bei WordPress bspw. Sucuri Scan). Überlegt Euch weiterhin, ob Ihr Kommentarfunktionen benötigt und insbesondere, ob Eure Besucher Dateien uploaden müssen. Falls nicht, deaktiviert diese Funktionen und schützt entsprechende Verzeichnisse durch eine .htaccess.

Ändert sämtliche Zugangsdaten – auch das FTP-Passwort!

Theoretisch müsstet Ihr jetzt noch die Logfiles durchsuchen und schauen, ob Ihr nachvollziehen könnt, wie der Angriff zustande kam. Oftmals endet diese Suche – nicht zuletzt mangels hinreichendem Hintergrundwissen – ergebnislos. Ihr könnt aber vorsichtshalber trotzdem Euren Provider fragen, ob er in den Logfiles Hinweise auf den Angriff gefunden hat.

Entfernt nun den Verzeichnisschutz für Euren Auftritt und beobachtet für die nächsten Tage und Wochen Euren Auftritt sehr aufmerksam. Regelmäßige Backups und Updates verstehen sich von selbst.

Variante B – Ihr habe kein sauberes Backup und Ihr traut Euch auch nicht, einfach eine frische Version des CMS einzuspielen

Trauriger Weise dürfte das der Normalzustand sein. Da Lamentieren nicht hilft, ist es dann an der Zeit, in die virtuellen Hände zu spucken.

Achtet darauf, dass Euer Virenscanner aktuell und eingeschaltet ist. Zieht dann per FTP ein vollständiges Backup Eures CMS. Wenn das Backup vollständig ist, lasst Ihr mindestens einen Virenscanner und einen Malware-Checker (bspw. Malwarebytes Anti-Malware) über den Backup-Ordner laufen. Etwaige Funde behebt Ihr sowohl im Backup als auch direkt auf dem Server.

Nehmt jetzt ein Tool, welches Dateien inhaltlich durchsuchen kann (bspw. Agent Ransack) und lasst alle Dateien des Backups nach

durchsuchen. Insbesondere Funde von „eval(base64_encode(“ und „eval(gzinflate(“ guckt Ihr Euch genauer an. Wenn diese von kryptischen Zeichenfolgen gefolgt werden, handelt es sich mit großer Wahrscheinlichkeit um Malware. Aber auch alle anderen Funde solltet Ihr gewissenhaft prüfen. Behebt die jeweiligen Befälle jedoch nur auf dem Server, so dass Ihr im Worst Case ein Backup habt.

Wenn Ihr alle Dateien gesäubert habt, werft auch noch einen Blick auf die Datenbank und durchsucht diese komplett nach „%<iframe%“, und „%<noscript%“. Löscht verdächtige Inhalte, nachdem Ihr ein DB-Backup erstellt habt.

Legt per .htaccess einen Verzeichnisschutz auf den gesamten Auftritt und bittet Euren Provider ggfls., den Zugriff auf die Seite wieder zu erlauben..

Ihr habe jetzt wieder eine laufende Installtion Eures CMS, auch wenn diese von außen nicht für Andere zugänglich ist. Installiert nunmehr sämtliche Updates für Euer CMS, die Plugins, Themes / Templates etc.

Härtet Eurer CMS durch die Installation eines entsprechenden Plugins (bei WordPress bspw. Sucuri Scan). Überlegt Euch weiterhin, ob Ihr Kommentarfunktionen benötigt und insbesondere, ob Eure Besucher Dateien uploaden müssen. Falls nicht, deaktiviert diese Funktionen und schützt entsprechende Verzeichnisse durch eine .htaccess.

Ändert sämtliche Zugangsdaten – auch das FTP-Passwort!

Theoretisch müsstet Ihr jetzt noch die Logfiles durchsuchen und schauen, ob Ihr nachvollziehen könnt, wie der Angriff zustande kam. Oftmals endet diese Suche – nicht zuletzt mangels hinreichendem Hintergrundwissen – ergebnislos. Ihr könnt aber vorsichtshalber trotzdem Euren Provider fragen, ob er in den Logfiles Hinweise auf den Angriff gefunden hat.

Entfernt nun den Verzeichnisschutz für Euren Auftritt und beobachtet für die nächsten Tage und Wochen Euren Auftritt sehr aufmerksam. Regelmäßige Backups und Updates verstehen sich von selbst.

 

Kopieren / Clonen einer Festplatte mit defekten Sektoren (oder auch ohne)

Hardwarebetreuung – egal ob einzelene Rechner oder ganze Netzwerke – waren mein erstes Standbein. Irgendwann war ich aber genervt von den wiederkehrenden Problemen mit Netzwerkdruckern, nicht gepflegten Backups etc. Also habe ich diesen Zweig meiner Tätigkeiten ad acta gelegt.

Privat kommt man aber trotzdem nicht darum herum, sich gelegentlich mit defekten Festplatten & Co. auseinanderzusetzen. Aktuell hatte eine Freundin ein „kleines“ Problem mit ihrem Laptop. Um es genau zu sagen, die Festplatte hatte diverse defekte Sektoren und das System (Windows 7) fuhr nur noch unter Protest und endlos langen Festplattenüberprüfungsvorgängen hoch. Immerhin!

Sie besorgte also auf meinen Rat hin eine neue 500 GB SSD von Samsung. Die Dinger laufen in mehreren meiner Rechner seit geraumer Zeit ohne zu mucken. Die von Samsung mitgeliefert Clone-Software funktioniert normaler Weise auch sehr zufriendstellend und kopiert selbst die Systempartition aus dem laufenden Betrieb heraus lauffähig auf die neue SSD. Leider verweigert sie den Dienst, wenn sie auf defekte Sektoren trifft.

Also musste eine andere Variante her. Ich probierte es mit der Live-CD von GParted, aber auch hier waren die defekten Sektoren der Knackpunkt.

Letztendlich landete ich bei Ubuntu Rescue Remix. Die aktuelle Version (zur Zeit 12.04) war schnell als ISO heruntergeladen, auf eine CD gebrannt und im Laptop gestartet.

Nach dem Hochfahren der Live-CD lässt man sich mit

die vorhandenen Festplatten anzeigen. In meinem Fall hatte das (leicht defekte) Quelllaufwerk die Bezeichnung /dev/sda und die neue SSD am USB-SATA-Adapter die Bezeichnung /dev/sdb.

Den ersten Kopierdurchgang startet man dann mit

-n (–no-split) sorgt dabei dafür, dass er sich nicht lange an defekten Dateien aufhält, sondern erstmal das rettet, was problemlos lesbar ist.

–force sorgt dafür, dass die neue SSD tatsächlich komplett überschrieben wird.

Nachdem dieser erste Kopiervorgang durchgelaufen ist, kann man dann, sofern es Probleme mit dem Quelllaufwerk gab, einen zweiten  Kopiervorgang starten:

-d (–direct) sorgt dafür, dass direkt auf die Festplatte zugegriffen wird.

-r3 (–max-retries=3) sorgt dafür, dass drei Mal versucht wird, defekte Sektoren einzulesen.