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\;\"
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>";
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.
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.
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
|
1 |
"eval(" OR "eval (" OR base64_decode OR base64 OR iframe OR noscript OR "display:" OR gzdeflate OR gzinflate OR rot13 |
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.
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
|
1 |
sudo lshw -C disk -short |
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
|
1 |
sudo ddrescue -n --force /dev/sda /dev/sdb logfile |
-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:
|
1 |
sudo ddrescue -dr3 /dev/sda /dev/sdb logfile |
-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.
