Um Dateien und Verzeichnisse auf dem Server schnell zu ändern und zu bearbeiten, kann ein SSH-Account sehr nützlich sein. Es gibt diverse Editoren auf der Shell, mit denen die Dateien bearbeitet werden können, viel verwendet wird dafür der Editor „vim“.
vim bietet einen großen Umfang von Funktionen, über die wir einen kleinen Überblick als Basis verschaffen möchten.
Dateien öffnen, bearbeiten, speichern und schließen
Um eine Datei im vim zu öffnen, kann ganz einfach der Befehl „vim“ genutzt werden:
vim datei.html
Durch Drücken von ESC gelangt man in den „Visualmode“, über den man Anweisungen z.B. zum Speichern, Schließen oder Editieren der Datei geben kann.
Durch die Eingabe von „i“ gelangt man in den „Insertmode“, nun kann man in der Datei schreiben.
Am häufigsten werden sicher die folgenden Befehle gebraucht (zuvor muss immer über ESC in den Visualmode gewechselt werden.)
[esc] :w = „write“ – speichern
[esc] :wq = „write/quit“ – speichern und beenden
[esc] :q = „quit“ – beenden
[esc] :q! = „quit!“ – beenden ohne zu speichern
[esc] :e = „edit“ – editieren
Wir möchten jetzt hier aber nicht einfach eine Liste aller Befehle erstellen, die es ja bereits zur Genüge im Internet gibt, sondern vielmehr einen Überblick über vim-Funktionen schaffen, die im täglichen Gebrauch sehr nützlich sein können.
Kopieren und einfügen
(VisualMode, zuvor also immer ESC drücken)
Mit der Tastenkombination
[esc] shift + v
werden Zeilen markiert und mit
[esc] y (yank)
in die Zwischenablage kopiert. Um einzelne Zeichen zu markieren wird die Tastenkombination
[esc] strg + v
verwendet. Mit
[esc] p (paste)
werden die Daten aus der Zwischenablage an der Stelle eingefügt, an der sich der Cursor befindet.
Suchen
Durchsucht werden kann eine Datei mit
[esc] /<suchbegriff>
. Zum nächsten Treffer springt man mit
[esc] n (next)
, zum vorherigen Treffer mit
[esc] shift +n
Mehrere Dateien gleichzeitig bearbeiten
Bei Programmierarbeiten ist es für einen guten Überblick oft sinnvoll, mehrere Dateien gleichzeitig zu öffnen, um Daten zu prüfen und eventuell auch Teile daraus kopieren zu können.
Um eine zweite (oder auch dritte, vierte…) Datei zu öffnen, wird die Tastenkombination
[esc] strg + w + n
verwendet. Nun wird das Fenster „geteilt“. Man kann jetzt also die neue Datei bearbeiten oder eine vorhandene Datei öffnen:
[esc] :e dateiname

Zwischen den Dateien wird mit
[esc] strg + w + k (nach oben)
[esc] strg + w + j (nach unten)
gewechselt.
Eine Liste der Kommandos für den vim ist z.B. hier oder einfach über die Suchmaschinen zu finden.
Die in diesem Beitrag beschriebenen Möglichkeiten decken natürlich nur einen kleinen Teil des Funktionsumfangs des vim ab, können jedoch beim Bearbeiten von Dateien sehr nützlich sein.
Am vergangenen Mittwoch (24.04.2013) haben wir unsere DNS-Infrastruktur für über eine Million Domains ohne Unterbrechung (und nach vielen umfangreichen Tests, Tests und noch mehr Tests!) auf die DNS-Software PowerDNS aktualisiert. Die neue Infrastruktur verschafft uns noch mehr Flexibilität und Robustheit und damit einen noch zuverlässigeren Betrieb der Domains unserer Kunden.
“DNS” oder “Domain Name System” ist einer der grundlegenden Hintergrund-Dienste im Internet. Das DNS sorgt dafür, dass Host-/Domainnamen auf IP-Adressen aufgelöst werden. Als Internetnutzer kann man somit bspw. zum Aufruf der domainFACTORY-Webseite ganz bequem www.df.eu im Browser eingeben ohne sich die dahinter verbergende IP-Adresse 80.67.16.99 des Servers merken zu müssen.
Für Kunden von domainFACTORY bringt das Update eine noch schnellere Übernahme von Änderungen an den Nameserver-Einstellungen mit sich. Nahm eine Übernahme von geänderten Einstellungen in unsere Nameserver bisher bis zu 30 Minuten in Anspruch, erfolgt die Übernahme nun in weniger als einer Minute. Unter Berücksichtigung der in den Nameservern voreingestellten Cache-Zeit (TTL, “Time To Live”) von 60 Minuten, sind Änderungen in den Nameserver-Einstellungen für unsere Kunden somit ab sofort nach spätestens 60 Minuten statt bisher 90 Minuten aktiv.
Nach den gestern veröffentlichen Punkten
1) Reduzierung von HTTP-Requests
2) Javascript und CSS zusammenfassen, “minifizierien” und komprimieren
3) Bilder verkleinern/skalieren und optimieren
4) Grafiken und Icons zusammenfassen / Spriting
nehmen wir uns heute die nachfolgenden Themen vor:
5) Caching
6) Kompression einsetzen – GZIP/DEFLATE
7) Weitere gesammelte Empfehlungen in Kurzform
8) Die eigene Webseite testen
5) Caching
Gemeint ist damit der Cache des Browsers. Viele Anwendungen bringen bereits eine Option zur Aktivierung/Konfiguration von Cache-Werten mit und setzen dann entsprechende Optionen automatisch in einer .htaccess-Datei. Relevant sind v.a. das Caching von Bildern, CSS- und Javascript-Dateien.
Das nachfolgenden Beispiel zeigt, wie eine .htaccess-Datei aussehen kann. Es wird zunächst geprüft, ob das für die Cachesteuerung benötigte Modul auf dem Webserver installiert ist. Nur wenn dies der Fall ist, wird die Option zum manuellen ansteuern der Cache-”Befehle” aktiviert (ExpiresActive on). Mittels ‘ExpiresDefault’ wird ein Standardwert gesetzt, der für alle Dateien Gültigkeit besitzt.
Im Beispiel sollen alle Dateien nach dem Zugriff fünf Minuten lang im Browsercache gehalten werden. Anschließend folgt eine Einschränkung bzw. genauere Definierung für einzelne Dateitypen, die dann teilweise länger oder kürzer bzw. gar nicht im Cache verbleiben sollen. Es sind auch exaktere Angaben möglich wie z.B. “access plus 1 month 19 days 2 hours 8 minutes”.
Bitte beachten Sie, dass die nachstehenden Werte nur der Veranschaulichung dienen und keine allgemein gültige Empfehlung für die Nutzung mit Ihrer Webseite darstellen!
<IfModule mod_expires.c>
ExpiresActive on
ExpiresDefault "access plus 5 minutes"
ExpiresByType image/ico "access plus 1 year"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType text/html "access plus 4 hours"
ExpiresByType text/htm "access plus 4 hours"
ExpiresByType text/javascript "access plus 2 days"
ExpiresByType text/css "access plus 2 days"
ExpiresByType text/xml "access plus 2 days"
ExpiresByType application/xml "access plus 0 seconds"
ExpiresByType application/json "access plus 0 seconds"
ExpiresByType text/cache-manifest "access plus 0 seconds"
</IfModule>
Bei nicht aufgeführten Dateien gilt der Standard-(Default)-Wert. Wird für mehrere Typen der selbe Zeitraum vergeben, so können diese auch zusammengefasst werden, beispielsweise:
ExpiresByType image/jpg image/jpeg image/gif image/png "access plus 1 month"
Alle Details der Konfigurationsmöglichkeiten finden sich in der Apache-Doku zu mod_expires .
6) Kompression einsetzen – GZIP/DEFLATE
Um die Menge an Daten, die bei der Übertragung zwischen Server und Browser anfällt, zu verkleinern, besteht die Möglichkeit der Kompression von Dateien per GZIP. Diese kann per Skript erfolgen oder über das sog. deflate-Modul des bei uns eingesetzten Apache-Webservers.
Auch die dafür erforderliche Aktivierung und Konfiguration wird in der .htaccess-Datei vorgenommen und es müssen explizit die Typen angegeben werden, die komprimiert übertragen werden sollen. Auch hierbei ist es möglich, mehrere Einträge einfach nacheinander anzugeben oder jeweils einzeln in einer Zeile:
<IfModule mod_headers.c>
AddOutputFilterByType DEFLATE text/plain text/html text/xml text/css text/javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript application/x-javascript
</IfModule>
Ein ‘Default’ für alle Dateien ähnlich wie für den Cache existiert ebenfalls. Sollen alle MIME-Typen des Dokuments in komprimierter Form übertragen werden, so kann anstelle der jeweils einzelnen Zeilen einfach die folgende genutzt werden:
SetOutputFilter DEFLATE
Wichtig: Da nicht alle Browser die Kompression unterstützen, sollten dafür Ausnahmen angegeben werden. Die nachfolgende erste Zeile nimmt alle Netscape-Browser der Version 4.06, 4.07 und 4.08 komplett aus, die zweite Zeile führt dazu, dass an alle InternetExplorer kleiner der Version 7 nur html-Inhalte komprimiert übertragen werden. Details der Konfigurationsmöglichkeiten finden sich in der Apache-Doku zu mod_deflate .
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE\s7 !no-gzip !gzip-only-text/html
7) Weitere gesammelte Empfehlungen in Kurzform
- CSS-Dateien sollten zu Beginn geladen und deshalb die Pfade dazu im
<head>-Bereich angegeben werden
- Erforderliche Schriften ebenfalls innerhalb der
<head>-</head>-Attribute, sofern Sie nicht per CSS genutzt/definiert werden
- Redirect-Anweisungen in der .htaccess sind nach Möglichkeit zu vermeiden und auf ein Minimum reduzieren. Hintergrund: Jede Umleitung ist wieder eine neue Anfrage (HTTP-Request) an den Webserver.
- Alle Javascript-Dateien aus dem Quelltext an das Ende unmittelbar vor das schließende stellen, damit der Browser mit der Darstellung der Webseite nicht warten muss, bis alle Javascript-Dateien geladen wurden.
- Bilder später nachladen; beispielsweise erst beim scrollen die weiter unten eingebundenen Grafiken vom Webserver anfordern. Für jQuery existiert ein Plugin: Lazy Load Plugin for jQueryDas Gegenteil von Lazy-Loading wäre das Preloading, also das Laden von Bildern bevor die Seite aufgebaut wurde. Beide Varianten haben Ihre Berechtigung und sind vom gewünschten Ergebnis abhängig. Bei Seiten mit nur wenig HTTP-Requests beispielsweise einer Landing Page oder einer Micro-Site, kann das Preloading als Option genutzt werden.
- Nutzen Sie einen ManagedServer oder einen ResellerDedicated-Server bei uns, so können Sie optional “KeepAlive” für den Server aktivieren lassen. KeepAlivesorgt dafür, dass jede aufgebaute Verbindung zum Webserver offen gehalten wird und so kein neuer Verbindungsaufbau erforderlich ist. Der Performancegewinn ist je nach Webseite/Dienst aber nur marginal.Die Werte für KeepAlive können auf Wunsch auch verändert werden, wir setzen derzeit standardmäßig folgende Werte :
- MaxKeepAliveRequests 100
- KeepAliveTimeout 5 (Dieser Wert sollte nicht zu hoch werden werden, da ansonsten die offenen Socket-Verbindungen über längere Zeit ungenutzt im Warte-Modus verbringen und die Anzahl der möglichen Verbindungen schnell aufgebraucht wird)
8) Die eigene Webseite testen
Die nachfolgend verlinkten Seiten führen verschiedene Messungen aus, die die bisher genannten Punkte prüfen und auf Optimierungspotential hinweisen. Die Ergebnisse werden zwar genauer erklärt, allerdings wird im Regelfall auf englischsprachige Erläuterungen verwiesen. Die Prüfroutinen ähneln sich sehr stark, da Sie bei der Gewichtung der Ergebnisse auf die Empfehlungen des Google Page Speed Grade und des YSlow Grade von Yahoo zurückgreifen. Diese beiden unterscheiden sich jedoch in Ihrer Gewichtung einzelner Punkte.
Browserplugins:
Auch bei den Onlinetests darf nicht vergessen werden, dass es abhängig Ihres Anwendungsfalls nicht immer sinnvoll ist, alle Punkte umzusetzen. Hat man einen Großteil einmal umgesetzt, so sind die verbleibenden Punkte meist nur mit einem deutlich höheren Aufwand realisierbar und das Verhältnis der Kosten/Nutzen verlagert sich stark auf die Kostenseite.
Abschließend möchten wir noch erwähnen, dass die genannten Informationen nur eine Auswahl an Ansätzen darstellen und die Kombinationsmöglichkeiten vielfältig sind. Nicht in jedem Fall können alle Punkte berücksichtigt werden.
Im Oktober haben wir mit dem Beitrag “Die Ladezeit von Webseiten verbessern” 5 einfache Tipps gegeben, die Einfluss darauf nehmen können, dass Webseiten schneller geladen werden.
In den Kommentaren gab es zahlreiche weitere und auch grundlegende Empfehlungen sowie den Wunsch, das Thema etwas genauer und detaillierter zu erläutern. Diesem Wunsch kommen wir nun gerne nach und splitten das Thema aufgrund des Umfangs in zwei Beiträge auf.
1) Reduzierung von HTTP-Requests
Verringern Sie die Anzahl an Dateien, die beim Aufruf geladen werden. Dazu zählen Bilder, CSS, Skripte von Facebook, Twitter, einer Chatbox, Statisktiksoftware, Flash und andere Videos etc. Setzen Sie einen Shop, Blog oder ein CMS sein, so nutzen Sie dafür sicher die eine oder andere Erweiterung. Viele Erweiterungen bringen, ebenso wie Templates eigene CSS- und/oder Javascript Dateien mit, die dann zusätzlich bei jedem Aufruf der Webseite geladen werden müssen. Das führt uns direkt zum nächsten Punkt:
2) Javascript und CSS zusammenfassen, “minifizierien” und komprimieren
Verzichten Sie soweit möglich auf Erweiterungen, die eigene CSS-Dateien und/oder Javascript-Bibliotheken mitliefern, und fassen Sie die zu ladenden Dateien zusammen.
J(ava)S(cript) und CSS können “minified” (Bedeutung eigtl. herabgesetzt) werden und sind dadurch komprimierter. Es werden Leerstellen, Einrückungen, Kommentare und Zeilenumbrüche im Quelltext eingespart, allerdings verringert sich dadurch auch die Lesbarkeit des Codes. Für die “Minifizierung” existieren verschiedene Tools und für beliebte OpenSource-Applikationen auch fertige Plugins sowie Online-Kompressoren.
Wird jQuery als Javascript-Bibliothek eingesetzt, so wirkt sich der Einsatz verschiedener Versionen wie folgt auf die Größe und zu übertragende Datenmenge aus:
jQuery Version 1.8.3
- Normal (261 KB)
- Minified (91.40 KB)
- GZIP (76.81 KB)
- Minfied+GZIP (33.43 KB)
Das Komprimieren der Inhalte wird in diesem Fall im englischen als ‘to minify’ (“Minifizieren”) bezeichnet, sollte aber nicht mit dem in der deutschen Sprache ebenfalls verwendeten Begriff des Komprimierens im Sinne der Kompression verwechselt werden. Letztere bezeichnet eigentlich das Verfahren der Datenkomprimierung beispielsweise mittels dem Kompressionsprogramm gzip.
Die Begriffe werden oft gemeinsam verwendet, spricht man von der Komprimierung von JS- oder CSS-Dateien ist jedoch meistens nur das “to minify” gemeint, da die Kompression mittels einem Kompressionsverfahren separat behandelt wird. Auch wir kommen später noch genauer darauf zu sprechen.
3) Bilder verkleinern/skalieren und optimieren
Bilder sollten in dem Format auf dem Server liegen, in dem sie später auch ausgegeben werden sollen. Ein 1024×684 Pixel großes Bild, das auf der Webseite nur für einen Teilbereich als Vorschaubild genutzt wird, sollte nicht über den Quelltest verkleinert werden, denn es muss das Orginalbild, das bedeutend größer ist, vom Server angefordert werden. Die Angabe der HTML-Größenattribute “width” und “height” sollte aber dennoch genutzt werden, denn dadurch reserviert der Browser direkt den Platz für das Bild und muss nach dem Laden des Bildes die Seite nicht erneut aufbauen (rendern).
Das Optimieren von Bildern durch die Entfernung von Metaangaben, Zusammenfassung von Farbwerten etc. ist mittlerweile nahezu ohne Qualitätsverlust möglich und führt zu einer kleineren Datei. Da es aber keine absolut verlustfreie Optimierung/Komprimierung gibt, sollten Sie die Ergebnisse zunächst individuell prüfen und bei Seiten, die auf qualitativ hochwertige Bilder setzen, darauf verzichten. Beispielweise sollten im Shop eines Herstellers für Kameras natürlich die Beispielbilder, die mit der Kamera erstellt wurden, keinen Qualitätsverlust durch die Komprimierungsverfahren erleiden und damit einem wichtigen Verkaufsargument entgegen stehen.
Online-Anbieter für die Verkleinerung der Bilddateien durch entsprechende Verfahren
Lokale Software
4) Grafiken und Icons zusammenfassen / Spriting
Icons, die sich wiederholen bzw. an vielen Stellen einer Seite eingesetzt werden, können in sog. Sprites zusammengefasst werden. Das CSS-Spriting ist eine in den letzten Jahren zunehmend verbreitete Möglichkeit, die parallelen Anfragen (HTTP-Request) auf den Webserver zu verringern und anstelle von vielen Kleinen, nur eine große Datei zu laden. Übermittelt man zusätzlich noch einen passenden Caching-Wert an den anfordernden Browser, so kann sich dieses Verfahren durchaus gerade für Grafiken lohnen, die sich auf einer Webseite nur selten ändern.
Spriting ist im Regelfall nicht automatisiert auf einer Webseite einsetzbar, da neben der vergleichsweise noch einfachen Zusammenfassung von Icons in eine Datei die Anpassung der jeweils betroffenen Stellen im Quelltext/CSS eine Herausforderung darstellt.
Über Erfahrungen von Anwendern entsprechender Tools oder Software-Empfehlungen freuen wir uns natürlich.
Im zweiten Teil gehen wir auf Caching, die Kompression mittels GZIP/DEFLATE und einige weitere Empfehlungen ein. Auch werden wir ein paar Tools und Plugins nennen, über die Sie Ihre eigene Webseite testen können.
In diesem Teil unserer Reihe zum Thema Sicherheit im Webhosting möchten wir genauer erläutern, was zu tun ist, wenn Sie von uns eine E-Mail mit dem Betreff “Schadhafte Skripte in Ihrem Auftrag // AN:” erhalten haben.
Haben Sie eine solche E-Mail erhalten, so wurde ein Missbrauch Ihrer Skripte (Spam, Malware, Phishing) festgestellt. Entweder wurde ein Skript dazu genutzt, Spam- oder Phishingmails zu versenden oder es wurde durch unsichere Skripte in den Account “eingebrochen” und dort Inhalte abgelegt, die Malware vertreiben oder eine Phishingseite beinhalten. In einem solchen Fall wurden entweder die betroffenen Dateien für den Zugriff per http oder auch die Domain vorübergehend gesperrt.
Wie wird ein Missbrauch der Skripte festgestellt?
Ähnlich wie bei E-Mails, bei denen wir Meldungen von Mailserver-Dienst-Betreibern erhalten, werden wir auch im Falle von einem Missbrauch von Skripten teilweise durch Dienste wie beispielsweise Google oder Yandex per E-Mail informiert, dass eine infizierte Seite aus unserem Netz gefunden wurde. Auch von uns selbst werden dazu Programme eingesetzt, die betroffene Domains ausfindig machen können.
Die Dienste finden die Seiten z.B. beim crawlen oder über sog. Honeypots, über die ein Angreifer versucht hat, eine Datei der gehackten Webpräsenz nachzuladen.
Sie selbst können übrigens mittels einem Dienst wie z.B. dem Sitecheck von Sucuri oder dem noch relativ jungen Portal Initiative S des Verbandes der deutschen Internetwirtschaft e.V. Ihre Seite auf Javascript-Malware prüfen lassen.
Wie erfolgt ein Hack, was macht der Angreifer?
Ein Angriff und schlussendlich ein Hack erfolgen in den meisten Fällen über veraltete Skripte, welche Sicherheitslücken aufweisen und so z.B. über Parameter in der URL andere Dateien von fremden (auch gehackten) Servern nachladen und ausführen (Remote File Inclusion) oder den Code aus einem Formular direkt ausführen.
Der Angreifer lässt sich dann eine PHP-Shell erstellen/laden, über welche er sich komfortabel per Skript Zugriff auf die Quota der Domain verschafft. Die Funktionen sind ähnlich umfangreich wie in einem FTP-Programm. Dies ist mit ein Grund, weshalb wir zum Einsatz von Quotas raten, um einzelne Webpräsenzen abzuschotten, so dass der Angreifer im Fall der Fälle nur innerhalb einer Quota agieren kann.
Über eine solche PHP-Shell infiziert der Angreifer dann die Dateien und fügt in diese Schadcode ein, der beim Aufruf der Seiten geladen wird. Dieser Code ist im Regelfall Javascript-Code welcher versucht, die Besucher beim Aufruf der Domain zu infizieren (Drive-By-Download).
Wenn nun ein User mit einer älteren Software-Installation (Browser, Flash, Plugins…) die Seite besucht, wird dieser mit der verlinkten Software infiziert (meist über ein “Exploit-Kit”) und verschickt seinerseits dann entweder Spam oder greift wiederum andere Systeme an.
Unser Abuse-Team blockiert nach Feststellung der Infektion mit schadhaften Skripten im Auftrag den Zugriff auf die infizierten Dateien über http. So können die Dateien weiterhin über FTP/SSH bearbeitet werden, aber Besucher der Seite können nicht mehr infiziert werden.
Wie finde ich infizierte Dateien bzw. säubere sie?
Haben Sie von uns eine E-Mail erhalten, so können wir Ihnen auf Anfrage die infizierten Dateien nennen. Unsere Technik listet Ihnen diese – soweit möglich – auf Anfrage gerne auf. Je nach Ihrer Einstellung für die Speicherung von Logfiles kann auch darüber ermittelt werden, über welches Skript bzw. welche Lücke der Angriff stattgefunden hat, sofern der Angriff nicht zu lange zurück liegt.
Alternativ können Sie sich die Dateien auf den lokalen Rechner herunterladen und diese mit einem Antiviren-Programm prüfen. Die Antiviren-Scanner können oft auch die Code-Teile erkennen und somit infizierte Dateien finden.
Wichtig nach einer Säuberung der Dateien ist es natürlich auch, die ausgenutzte Lücke zu schließen, indem Sie die Software (CMS, Blog, Shop etc.) und installierte Erweiterungen aktualisieren.
Die meisten Hersteller bieten einen Newsletter, eine Mailingliste oder einen RSS-Feed an, der Sie über eine neue Version der Software informiert.
Nachdem die Dateien bereinigt und der Schadcode entfernt wurde, antworten Sie bitte kurz auf die erhaltene E-Mail und die Kollegen werden die Seite wieder entsperren.
Wir hoffen Ihnen mit diesen Informationen ein Einblick in den Ablauf gegeben zu haben, der uns im Bedarfsfall dazu veranlasst, Skripte oder eine Domain vorübergehend zu sperren, um Dritte vor weiterem Schaden zu schützen und hoffen auf Verständnis für diese Vorgehensweise.
Es kommt vor, dass ein E-Mail-Account (lokal) gehackt und missbraucht wird oder ein Postfach für die Verbreitung von Spammails genutzt wird. Wir erhalten auch Anzeigen und Hinweise von Maildienstbetreibern und Nutzern, die sich durch E-Mails von bei uns verwalteten Domains belästigt fühlen und setzen natürlich selbst Prüfroutinen ein, um den Versand von Spammails über uns frühzeitig zu erkennen und zu unterbinden.
Die Bearbeitung dieser Anfragen und die Kontrolle sowie Erweiterung der vorbeugenden Maßnahmen zählen u.a. zum Aufgabengebiet der Kollegen des “Abuse-Teams”. So werden Kunden, über deren Account ein Versand von Spammails festgestellt wurde, beispielsweise in Form einer E-Mail benachrichtigt.
- Doch wie verhält man sich richtig, hat man eine solche E-Mail erhalten?
- Welche Dinge kann man unabhängig davon tun und selbst dem Missbrauch vorbeugen?
Diese Fragen werden wir nachfolgend gerne beantworten und erweitern damit unsere Reihe zum Thema Sicherheit im Webhosting, die wir in den vergangenen Wochen in Form verschiedener Beiträge hier im Blog veröffentlicht haben.
Was tun bei einer Mail mit dem Betreff “Spam über unsere SMTP Server // AN: ” ?
Haben Sie eine Nachricht mit dem Betreff “Spam über unsere SMTP Server // AN: ” von uns (Absender domainfactory / df.eu) erhalten, dann wurde ein Missbrauch einer Ihrer E-Mail-Accounts festgestellt und der Account vorsorglich gesperrt.
Wie wird ein solcher Missbrauch festgestellt?
Wir erhalten, wie eingangs schon kurz erwähnt, von anderen Providern und Betreibern von Mail-Diensten wie beispielsweise AOL, Hotmail, TrendMicro, Rackspace und vielen anderen jedes mal eine sog. “Abuse-Complaint” (Beschwerde), wenn dort eine Nachricht als Spam erkannt wurde oder der User die Nachricht dort als Spam markiert hat.
Eine solche Beschwerde besitzt ein standardisiertes Format, genannt ARF (Abuse Reporting Format) und wird an eine extra dafür eingerichtete Adresse bei uns eingeliefert. Dort arbeiten zum größten Teil von uns selbst geschriebene Skripte und Programme diese Meldungen ab, prüfen diese auf bestimmte Kriterien und versehen die Meldung mit einem bestimmten Wert (Score).
Zu den Kriterien zählen beispielsweise
- das Alter der gemeldeten Spammail
- wurde die Beschwerde manuell von einem Benutzer ausgelöst, mittels Meldefunktion im E-Mail-Programm
- von welchem Mail-Anbieter wurde die “Abuse-Complaint” gesendet
- etc.
Abhängig des jeweils erhaltenen Wertes und der Häufigkeit der Meldungen zu einem bestimmten Absender, gibt es weitere Kriterien und Stadien die durchlaufen werden. Wird schließlich einer der definierten Schwellwerte im System überschritten, erscheint beim Team eine Meldung mit den Ergebnissen der Prüfungen und Details wie z.B. dem initialen Score, der Anzahl an Beschwerden insgesamt, die Betreff-Zeile(n) etc.
Unser Abuse-Team prüft diese Meldung dann nochmals separat und entscheidet schließlich über das weitere Vorgehen, wie die Information an den Kunden und die Sperrung eines Account. Dabei wird dann auch berücksichtigt, ob es in der Vergangenheit schon einmal einen Vorfall beim jeweiligen Kunden gab und es evtl. sogar dasselbe Postfach betraf.
Wie wird das Problem gelöst?
Als unser Kunde erhalten Sie natürlich nicht nur eine E-Mail mit einer kurzen Notiz, sondern weitergehende Informationen, um einen solchen Vorfall in Zukunft verhindern zu können.
In den meisten Fällen wurde (nur) ein unsicheres Kennwort verwendet (12345, ein Name o.ä.). Hier reicht es aus, im Kundenmenü ein sicheres / komplizierteres Kennwort für den Account einzutragen.
In den übrigen Fällen wurde meist der PC des Benutzers mit einem Trojaner infiziert oder war es zumindest zeitweise, welcher das Kennwort aus dem E-Mail-Client aus- oder mitgelesen hat. In einem solchen Fall ist die umfangreiche Prüfung und Säuberung des Rechners unerlässlich und sollte in jedem Fall erfolgen, bevor das Kennwort anschließend geändert wird. Denn ansonsten kann der/ein Trojaner das neue Kennwort ebenfalls abgreifen.
Es gibt verschiedene Dienste und Tools, den Rechner zu säubern. Wir nennen im Regelfall in der E-Mail die Seite www.botfrei.de es gibt aber natürlich auch andere Dienste und Software dafür.
Besuchen Sie zur Säuberung des Rechner die Seite und navigieren Sie dort im Menü auf “Säubern (https://www.botfrei.de/decleaner.html). Laden Sie sich dort einen der angebotenen DE-Cleaner auf Ihren PC und führen Sie diesen aus. Je nach Version ist auch eine Installation erforderlich.
-
- DE-Cleaner - Optionen
Wichtig: Wählen Sie unbedingt die Option zum Scannen der eigenen Dokumente mit aus!
Nach der Bereinigung sollten Sie dann Ihre Kennwörter ändern, da diese vom Trojaner bereits an Dritte gesendet worden sein können. Dies gilt nicht nur für das Kennwort Ihrer E-Mail-Adresse, sondern auch für FTP und andere Programme, mit denen Sie Zugangsdaten ins Netz übermitteln.
Rückmeldung per E-Mail
Haben Sie eine Nachricht von uns erhalten, der Sie über den Missbrauch einer Ihrer E-Mail-Accounts informiert hat, so vergessen Sie bitte nicht, nach dem Ausführen der Bereinigung und der Änderung des Passwortes auf diese Nachricht zu antworten und den Kollegen Ihre Aktionen mitzuteilen.
Sie erhalten anschließend von uns eine Rückmeldung, sobald Sie den E-Mail-Account wieder verwenden können. Bei Rückfragen zum Vorgehen können Sie sich natürlich jederzeit auch unabhängig davon an unseren technischen Support wenden.
Es empfiehlt sich den DE-Cleaner regelmäßig auszuführen, auch wenn kein Missbrauch vorliegt, um eine Infektion des Systems frühzeitig zu erkennen/beheben.
Wir hoffen auf Verständnis für unsere scharfe Vorgehensweise und “Null-Toleranz-Politik” beim Thema Spammails und hoffen zugleich, die Sensibilität für das Thema bei Ihnen erhöht zu haben.
Co-Autor: Markus Kalmuk
In unserem Blog gab es schon mehrfach Artikel zum Thema Energieeffizienz. Aber: Woher wissen wir überhaupt welche Energiemenge wir an welcher Stelle verbrauchen?
Klar: Für einen ersten Überblick kann man sich anschauen wie viel Strom das Rechenzentrum bzw. einzelne Abschnitte darin komplett benötigen. Zu einem besseren Verständnis was wo passiert – und damit zu einer erfolgreichen Optimierung – gehören aber wesentlich feiner gestaffelte Messmöglichkeiten. Am besten ist eine Live-Verbrauchsanzeige nach Stromkreis und zwar inklusive festgelegter Grenzwerte für den Verbrauch mit entsprechender Alarmierung.
Hier einige Beispiele unserer Systemüberwachung im Bereich Stromverbrauch:

Graph einer Zuleitung eines gerade in Betrieb genommenen Racks

Livewerte für zwei neu aufgebaute Racks
Für ein solches Erfassen der Stromverbräuche gibt es viele fertige Lösungen bekannter Hersteller von denen wir auch einige einsetzen. Als Hoster sind wird jedoch immer daran interessiert zu verstehen, was in solchen Geräten passiert und zu überlegen, ob wir die Aufgabe nicht selbst zuverlässiger und besser erledigen können. Und genau hierbei hilft uns das Raspberry PI.
Mit Hilfe einer selbst entwickelten Platine fragen wir direkt neben unseren Zuleitungen montierte Stromzähler ab und ermitteln damit ständig den aktuellen Verbrauch. Pro Raspberry PI können wir bis zu 9×24 Stromkreise (in der Praxis: 2×24) überwachen – die Anzahl der Geräte bleibt also überschaubar. Der sehr geringe Stromverbrauch der Raspberry PI kommt natürlich ebenfalls unserer Energiebilanz zugute: Weniger Strom für Messeinrichtungen bedeutet weniger Overhead insgesamt.
Besonders wichtig ist es uns die Überwachungs-Elektronik logisch von der eigentlichen Zuleitung zu trennen. Dabei kann ein Defekt im Überwachungsgerät niemals dazu führen dass der Stromkreis unterbrochen wird und somit unsere Verfügbarkeit negativ beeinflussen. Dieser Tatsache messen wir höchste Bedeutung zu, haben wir doch schlechte Erfahrungen mit den fertigen Produkten einiger Hersteller gemacht.
Um die durch die Raspberry PI gewonnen Daten effektiv nutzen zu können, “holt” sich unser Monitoring System fortlaufend und in regelmäßigen Abständen die Werte vom Raspberry PI ab und erstellt unter anderem oben gezeigte Graphen und Live Ansichten.

Platine zur Auswertung von Stromzählern
Der Einsatz der Raspberry PI hat jedoch noch einen weiteren Nutzen für uns, da sich über eine Zusatzplatine eine große Menge von Temperatursensoren anschließen und ebenfalls überwachen lässt.

Platine (noch nicht gereinigt) zum Auslesen von Temperatursensoren

Raumplan mit den Live Werten einiger Temperatursensoren
Zusammen mit den Stromverbrauchswerten hilft uns die detaillierte Übersicht der Temperaturwerte unser Rackdesign und die technischen Systeme weiter zu optimieren. Auch für die Temperatursensoren werden dabei automatisch von uns vorgegebene Grenzwerte überwacht, eventuelle bestehende Hotspots oder sonstige Probleme mit der Klimatisierung bemerken wir also sehr schnell. Ganz wichtig sind dabei für uns nicht nur die absoluten Temperaturen sondern auch dass die Temperaturen sehr konstant bleiben und nicht schwanken.
Als dritte Funktion verfügt jede Raspberry-PI Einheit darüber hinaus auch noch über einen Sensor für die Luftfeuchte, welche ebenfalls durch uns auf Übereinstimmung mit den Soll-Werten hin kontrolliert wird.
Hier ein Bild einer solchen Messstation, montiert in einem 19“ Patchpanel:

19″ Messgerät
Für die Arbeit im Rechenzentrum und die laufend durchgeführten Verbesserungen gilt: Vor dem Optimieren kommt das Messen. Und genau das macht das Raspberry PI für uns – als im Verbrauch sparsame und kostengünstige Plattform – noch einfacher.
Am vergangenen Wochenende fand das “5. TYPO3Camp München“ statt und auch wir waren vor Ort.
Los ging es bereits am Freitag Abend zu einer kleinen Warmup-Party im “Foyer am Oberanger” und für das leibliche Wohl war dank eines leckeren Chili-Con-Carne und eines Freigetränks gesorgt. Natürlich wurden auch weitere Nicht-/Alkoholhaltige Getränke ausgeschenkt; gegen Bezahlung.
Samstag – 08.09.2012
Das eigentliche Event startete dann am Samstag um 9 Uhr mit dem Frühstück. Die Registrierung der Teilnehmer war ab 8 Uhr möglich. Für alle helfenden Hände begann der Tag jedoch deutlich früher und auch unser kleiner Stand war kurz nach halb Acht bereits fertig und die Give-aways und Flyer bereitgelegt
Die Begrüßung inkl. Vorstellung der Organisatoren und Sponsoren, allgemeiner Hinweise und letzlich Planung der einzelnen Sessions, startete etwas verspätet, die Themenauswahl war aber recht breit gefächert und nicht rein auf TYPO3 bezogen. Durch Mittagessen und eine Kaffeepause unterbrochen, waren es am Samstag auf den Tag verteilt maximal 6 parallel stattfindende Sessions in 5 Slots. Dadurch war es natürlich leider auch vereinzelt so, dass interessante Vorträge parallel liefen und man nicht alle besuchen konnte, die man gerne gesehen hätte.
Wie in den vergangenen Jahren konnte am Nachmittag auch die Zertifizierungsprüfung zum “Certified TYPO3 Integrator” abgelegt werden.
Zu den Themen des Samstags zählten u.a.
- Ausblick auf TYPO3 6.0
- Erste Begegnung mit dem Varnish-Cache
- Modern Frontend Development with Sass/Compass
- Grenzen von Extbase
- MySQL
- Agile/Lean – Scrum und Kanban (Teil 1)
- “Selbsthilfegruppe” Responsive Webdesign
- Projektmanagement: Tools und Tipps
Gegen 20 Uhr wurde der Tag mit einem leckeren Barbecue ausgeklungen und auf einem TYPO3Camp darf natürlich auch ein Kicker nicht fehlen (2 Kickertische!). Für den ein oder anderen ging der Abend auch danach noch weiter und wurde u.a. im “Peaches” verbracht. Wann der/die Letzte im Bett waren können wir nicht sagen, Gerüchte sprechen von 5 Uhr früh und später…
Sonntag- 09.09.2012
Der zweite Tag begann ebenfalls um 9 Uhr mit einem leckeren Frühstück und anschließender Planung der verbleibenden und neu aufgekommen Themenwünsche. Nachstehen eine kleine Auswahl der gehaltenen Sessions:
- Testing mit Selenium; Google PageSpeed einsetzen
- TYPO3 Caretaker
- Die 4 Core Cultures nach William Schneider
- TYPO3 Scheduler
- git im Team nutzen, Rechtemanagement
- Webserver-Performance (Apache, Nginx, KeepAlive, PHP-FPM, etc.)
- Workspaces
- Agile/Lean – Scrum und Kanban (Teil 2)
Nach der Verabschiedung am späten Nachmittag und viel Applaus für die Organisatoren, die Location und die Sponsoren, endete das “5. TYPO3Camp München“ nach zwei sehr interessanten Tagen.
Wir bedanken uns für das Feedback von Kunden, die auf dem Camp anwesend waren, für den Smalltalk mit Anwendern und Agenturen sowie den Austausch mit der Community. Es wurde wieder bewiesen, dass der Claim “Inspiring People to Share”, den TYPO3 seit Jahren beherzigt, funktionieren kann.
Natürlich kamen am gesamten Wochenende die TYPO3-lastigen Themen wie Extbase oder Fluid nicht zu kurz, deren Anbindung von/an jQuery mobile oder auch die Vorträge zur korrekten Einrichtung des TCA, wt_cart, Vorstellung der SVG-Erweiterung etc.pp.
Neben reinen Vorträgen gab es auch viel Interaktion in Workshops und Diskussionsrunden.
Das Camp fand – anders als in den Vorjahren – in den “Design Offices Arnulfpark” statt. Für reichlich Essen und Trinken war an beiden Tagen gesorgt und wir möchten uns abschließend an dieser Stelle auch recht herzlich bei den Organisatoren bedanken und unser Fazit ist kurz und knapp:
So ein Wochenende ist einfach immer viel zu kurz
Für viele selbstverständlich, für andere wirft Sie immer wieder Fragen auf: Die PHP.INI-Datei
Die php.ini ist eine zentrale Konfigurationsdatei die PHP sagt, mit welchen Einstellungen es ausgeführt und ob beispielsweise eine Erweiterung geladen werden soll. Die möglichen Optionen, um mit der PHP.INI-Datei letztlich das Verhalten von Skripten zu beeinflussen, sind sehr zahlreich und unterscheiden sich etwas, je nach genutzter PHP-Version.
Diese Konfigurationsdatei wird immer beim Start von PHP eingelesen und somit bei uns bei jedem Aufruf eines PHP-Skriptes geladen. Lediglich bei FastCGI wird die Datei für eine gewisse Zeit vorgehalten und nicht jedes Mal komplett neu vom Webserver gelesen.
Die PHP.INI
Eine PHP.INI-Datei ist relativ simpel aufgebaut und man muss sich nur an wenige Regeln halten. Im einfachsten Fall beinhaltet Sie nur die Zeile mit den Angaben der gewünschten Option, die geändert werden soll, beispielsweise:
[PHP]
register_globals = “off”
Der Wert nach dem Gleichheitszeichen sollte immer in Anführungszeichen gesetzt werden, ist jedoch nicht verpflichtend und im Internet finden sich für beide Varianten viele Beispiele. Ein, wie im Beispiel genannter, boolescher Wert kann für die Aktivierung “true”, “on”, “1″ oder “yes” nutzen und für die Deaktivierung entweder “false”, “off”, “0″ oder “no”. Für obiges Beispiel bedeutet dies, dass jeder der nachfolgenden Einträge die selbe Auswirkung hat:
register_globals = “off”
register_globals = “no”
register_globals = “false”
register_globals = “0″
Soll kein expliziter Wert und somit eine leere Zeichenkette gesetzt werden, so kann dies durch das Leerlassen nach dem Gleichheitszeichen erfolgen oder indem “None” für “kein Wert” gesetzt wird:
register_globals =
register_globals = “”
register_globals = None
register_globals = “None”
Bei Werten, die in Zahlen (integer) ausgedrückt werden, werden die Werte in Bytes angegeben. Es sind folgende Abkürzungen möglich um auch größere Einheiten auszudrücken: K für Kilobytes, M für Megabytes und G für Gigabytes. 8M entspricht somit acht Megabyte oder 8388608 Bytes. 8K entspricht acht Kilobyte oder 8192 Bytes. Unbegrenzt, also keine Obergrenze wird mittels “-1″ ausgedrückt. Somit sind auch hier verschiedene Angaben möglich, die alle die selbe Bedeutung haben:
memory_limit = “100M”
memory_limit = “102400K”
memory_limit = “104857600″
Zeitangaben erfolgen ohne Zusatz als reine Ziffernfolge, die immer die Anzahl an Sekunden darstellen:
max_input_time = “30″
Angaben in einer Zeile, die nach einem Semikolon folgen, werden ignoriert, ebenfalls auch Text in eckigen Klammern. Eine solche Klammerung wird für die Markierung/Trennung von Abschnitten genutzt:
; Kommentar der nicht ausgegeben wird
[PHP] ; Abschnittsmarkierung
Für Pfadangaben, z.B. für Erweiterungen können relative oder absolute Pfadangaben genutzt werden. Nachfolgend einige Beispiele möglicher Angaben:
extension_dir = “/usr/local/lib/php_modules/5-53LATEST”
extension = “mysqli.so”
zend_extension = “/kunden/12345_6789/webseiten/shop/ioncube/ioncube_loader_lin_5.3.so”
include_path = “.:/usr/local/lib/php”
Weitergehende Informationen und eine Liste mit allen Abschnitten und Direktiven der php.ini finden Sie unter: http://www.php.net/manual/de/ini.php
Einfache Bearbeitung mit dem PHP.INI-Editor
In allen aktuellen Webhosting- und Server-Tarifen stellen wir einen Editor zur Verfügung, über den die PHP.INI direkt bearbeitet werden kann. Dadurch ist keine manuelle Anlage einer INI-Datei erforderlich, die – abhängig der Anwendung – zusätzlich auch in jedes Verzeichnis kopiert werden muss, in dem PHP-Skripte ausgeführt werden. Editieren Sie einfach die vorhandenen Werte direkt im Kundenmenü, ändern Angaben ab und speichern Ihre Änderungen. Fertig
Details zu unserem PHP-INI-Editor finden Sie selbstverständlich auch in unseren FAQ unter: http://www.df.eu/de/service/df-faq/technische-faq/phpini-editor/
Auslesen der derzeitigen Werte einer PHP.INI
Möchten Sie sich die Werte, die derzeit für die PHP-Version eingestellt sind im Browser ansehen, so erstellen Sie bitte einfach eine Datei mit dem folgenden Inhalt und speichern diese beispielsweise als “phpinfo.php” ab. Anschließend können Sie die Datei auf Ihren Webspace laden und im Browser aufrufen. Es werden dann Ihre aktuellen Werte dargestellt:
<?
phpinfo();
?>
Wir hoffen, wir konnten Ihnen einen kleinen Einblick in die PHP.INI geben und diese etwas “entmystifizieren”
Nein, noch dreht sich noch nicht alles um das Runde, das ins Eckige muss
“Aus” ist zunächst die Bewerbungsphase für die neuen Top-Level-Domains, sie endete mit dem gestrigen Tag. Bis zum 30.05. konnten Bewerber Anträge für neue Domainendungen einreichen. Mit der Bewerbungsphase für neue Top-Level-Domains (TLD) soll die Vergabe der Endungen grundsätzlich freigegeben werden, sodass – jedenfalls theoretisch – jede beliebige Endung als Domain registriert werden kann.
War bereits die Einführungs- und Vorbereitungsphase des Programms turbulent (wir berichteten), so stand die Bewerbungsphase dem in nichts nach. Ursprünglich sollten Bewerber vom 12.01.2012 bis zum 12.04.2012 Zeit haben, Bewerbungsunterlagen für Domainendungen einzureichen. Aufgrund Sicherheitslücken des Bewerbungssystems, bei welchem einige Bewerber teilweise Benutzernamen und Dateiendungen von Dokumenten anderer Bewerbungen sehen konnten, wurde das Bewerbungsverfahren jedoch just am 12.04. ausgesetzt. Erst sechs Wochen später wurde das System wieder online genommen und den Bewerbern eine weitere Woche Zeit gegeben, Ihre Bewerbungen zu vervollständigen.
Mit dem Abschluss der Bewerbungsphase ist nun die Veröffentlichung der beantragten Domainendungen für den 13. Juni geplant. Zu diesem Datum werden wir also erfahren, welche potentiell neuen Domainendungen es in den kommenden Jahren geben könnte. Zuletzt wurde von ICANN eine Zahl von über 2.000 erfassten Bewerbungen genannt, wobei hier Mehrfachbewerbungen um ein und dieselbe TLD enthalten sind. Ebenso waren noch einen Tag vor Ende des Bewerbungsfensters über 500 Bewerbungen unvollständig oder die Gebühren noch nicht bezahlt. Wurden diese nicht rechtzeitig vervollständigt und/oder bezahlt, erfolgt keine weitere Berücksichtigung der Bewerbungen.
Wie es nun weiter geht
Mit Veröffentlichung startet am 13.06. eine zweimonatige “Feedback-Phase”, innerhalb welcher die Öffentlichkeit Bewerbungen gegenüber ICANN kommentieren kann. Gleichzeitig startet die Evaluierung der eingegangenen Bewerbungen. Gibt es für ein und dieselbe Endung mehrere berechtigte Bewerbungen, so wird die Endung schlussendlich durch eine Auktion dem Höchstbietenden zugeschlagen. Abschließend erfolgt dann die Delegierung der TLD – die Endung ist dann, entsprechende Registrierungen vorausgesetzt, über das Internet verfügbar.
Mit Delegierung der ersten TLDs ist nach derzeitigem Stand frühestens in der ersten Jahreshälfte 2013 zu rechnen, viele Endungen werden wahrscheinlich erst zwei, drei Jahre oder gar noch später zugeteilt werden. Auch bleibt abzuwarten, welche Domainendungen schlussendlich tatsächlich auch “öffentlich” registriert werden können oder nur durch einzelne Organisationen, z.B. Markeninhaber, genutzt werden.
Ausführliche Informationen rund um die neuen Top-Level-Domains finden Sie auf der ICANN-Webseite: http://newgtlds.icann.org