Kategorie: PHP

Mails per PHP von einer Synology Diskstation verschicken

3. Juli 2016 /

mail() funktionert ja bekanntlich unter Synology DSM auf einer Diskstation nicht.

Relativ komfortabel kann man jedoch Mails mit dem PEAR-Mail-Paket via SMTP versenden.
Dazu sind folgende Schritte nötig:

  1. Über den Paketmanager PEAR installieren
  2. Per telnet oder ssh auf der Diskstation eine Konsole öffnen und abschicken
  3. Eine Mail per Mail verschicken:

Update für DSM6

Der PEAR-Pfad muss an zwei Stellen ergänzt werden:

1. Hauptmenü => WebStation => PHP-Einstellungen => Häkchen bei „PHP open_basedir benutzerspezifisch anpassen“ setzen und bei „open_basedir:“ am Ende :/volume1/@appstore/PEAR/ ergänzen

2. auf „Erweiterte Einstellungen“ klicken => Reiter „Kern“ anklicken => den Wert für „include_path“ auf „.:/volume1/@appstore/PEAR/“ anpassen und „OK“ klicken

Ggfls. muss der Webserver noch per SSH neu gestartet werden:
sudo synoservice --restart pkgctl-WebStation

WordPress per PHP direkt von wordpress.org als Zip-Datei auf Server herunterladen und entpacken

6. Juni 2016 /

Um Prototypen für Kunden zu bauen oder auch für eigene Bastelprojekte muss ich immer mal wieder WordPress neu aufsetzen.

Bei vielen Hostern geht das heute auch als App oder Service relativ vollautomatisch, aber oftmals hat man dann nicht volle Schreibrechte in den WordPress-Verzeichnissen. Also installiere ich lieber selbst.

Da das Herunterladen auf den eigenen Rechner, das lokale Entpacken der Zip-Datei und der anschließende Upload der Daten relativ unspannend und zumindest im FTP-Transfer auch zeitaufwändig ist, lässt sich dieser Vorgang mit einem kleinen Skript weitestgehend automatisieren.

  1. aktuelle deutsche Version von WordPress als Zip-Datei mit cURL direkt auf den Server ziehen
  2. Zip-Datei entpacken
  3. Verzeichnisse und Dateien aus dem Unterordner “wordpress” auf die aktuelle Verzeichnisebene verschieben
  4. WordPress-Installation anstoßen

Als Skript sieht das dann so aus:

Noch ein paar Worte zur Erläuterung:

  • Die Klasse ZipArchive sollte ab PHP 5.2 zur Verfügung stehen.
  • Das exec-Kommando kann bei anderen Hostern anders heißen, bspw. system etc.

 

Ein PHP-Skript unter Synology DSM per Cronjob regelmäßig ausführen lassen

9. November 2015 /

In aller Kürze:

  1. Auf der Diskstation den SSH-Dienst aktivieren:
    Systemsteuerung => Terminal & SNMP => Häkchen bei “SSH-Dienst aktivieren” setzen => “Übernehmen” klicken
  2. Per Putty oder anderem SSH-Cilent mit der Diskstation verbinden:
    Host: diskstation (oder welchen Namen Ihr vergeben habt oder die IP-Adresse)
    User: root
    Password: Das Admin-Password
  3. Crontab bearbeiten:
    cd /etc[RETURN]
    vi crontab[RETURN]
    mit den Cursortasten an das Ende der untersten Zeile gehen
    [i] drücken, um in den Editiermodus zu gelangen
    Daten eintragen, bspw.
    0 6 * * * root curl http://127.0.0.1/ein_verzeichnis/eine_php_datei.php
    für das tägliche Aufrufen des Sripts morgens um 6 Uhr
    Die einzelnen Werte müssen mit Tabstopps getrennt werden!
    [ESC] drücken, um den Editiermodus zu verlassen
    [:][w][q] drücken, um die crontab zu speichern und den vi zu verlassen
  4. Cron neu starten:
    restart crond[RETURN]
    exit[RETURN]

Update ab DSM 6.0

Synology lässt nunmehr keinen Login auf das root-Konto zu. Stattdessen muss man sich als admin einloggen und dann vor das vi crontab[RETURN] noch ein sudo setzen. Komplett lautet der Aufruf dann
sudo vi crontab[RETURN]

Update ab DSM 7.0

Um crond neu zu starten:
sudo systemctl restart crond[RETURN]
und
sudo systemctl restart synoscheduler[RETURN]

Google Chrome lädt Seiten nicht oder nur unvollständig und zeigt Net::ERR_INCOMPLETE_CHUNKED_ENCODING oder net::ERR_CONTENT_LENGTH_MISMATCH in der Console an

18. September 2015 /

Wenn Eure PHP-Skripte unter Google Chrome nur unvollständige oder auch gar keine Ausgaben erzeugen, liegt dies mittlerweile immer häufiger an den diversen Echtzeitschutzmodulen der Anti-Viren-Softwarepakete.

Diese scheinen erhebliche Probleme zu haben, wenn im Header keine oder eine falsche Content-Length übertragen wird. Sobald man den Echtzeitschutz temporär ausschaltet, tritt das Problem nicht mehr auf.

Dieses Problem tritt – allerdings ohne brauchbare Fehlermeldung – auch in Firefox auf.

Insbesondere wenn Inhalte dynamisch erzeugt werden und Teile bspw. per Include nachgeladen werden, ist jedoch die Content-Length vorher nicht bekannt.

Abhilfe ist relativ einfach, indem  die Ausgabepufferung aktiviert wird.

Startet ggfls. nach dem öffnenden PHP-Tag noch Eure Session und aktiviert dann die Ausgabepufferung mit ob_start(). Am Ende Eures Skripts gebt Ihr dann durch header(“Content-Length: “.ob_get_length()); die korrekte Content-Length an und gebt den Ausgabepuffer mit ob_flush(); aus.

PHP-Skript bricht ohne Fehlermeldungen ab

16. August 2015 /

Ich habe kürzlich im Rahmen eines Projektes ein Skript gebaut, welches ein dynamisches HTML-Formular erzeugt. Das Formular besteht aus ca. 15.000 Zeichen und wird je nach gesetzten Werten erneut über Ajax nachgeladen.

Leider funktionierte das Nachladen nur sporadisch und ohne erkennbares Muster. Die Logfiles wiesen auf keinerlei Fehler hin und auch der Support des Hosters für das Projekt hatte keine rechte Idee, woran es liegen könnte.

Meinem Kunden kann ich aber schlecht erklären, dass seine Anwendung nur gelegentlich funktionert.

Firebug zeigte über die Konsole zwar brav, dass das Skript über Ajax aufgerufen wurde, jedoch war die Übertragung in 4 von 5 Fällen unvollständig, obwohl ein HTTP-Return-Code 200 zurückgegeben wurde. Mit 0.9 Sekunden Laufzeit war auch das Überschreiten etwaiger maximaler Skriptlaufzeiten unwahrscheinlich.

Vorsichtshalber habe ich auch den Speicherbedarf während der Verarbeitung des Skripts mitgeloggt und bei ca. 16 MB Speicherbedarf gabe es auch keine Probleme.

Schließlich habe ich mir über “Live HTTP headers” die übertragenen Werte des Headers angeschaut und siehe da, für “Content-Length” wurde nur der Wert 32 übertragen.

Also habe ich vor der Ausgabe des Wertes den entsprechenden Header mit

die korrekte Länge des Contents übergeben und siehe da, die Übertragung funktioniert reibungslos.

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

21. Juli 2015 /

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.