Durch den Umzug auf den Webhoster All-Inkl ergaben sich hier und da kleine Schwierigkeiten.
Ich hatte zum Beispiel ein Problem mit den Besitzerrechten der WordPress Ordner, wie zum Beispiel „wp-content/uploads/“ oder „wp-content/gt-cache“ (gehört zum Global Tranlator Plugin).
Wenn man WordPress normal installiert werden bestimmte Ordner von den automatischen WordPress Scripts angelegt und die Besitzerrechte erhalten dann die Scripts, was auch vollkommen richtig ist.
Zieht man jetzt mit dem kompletten Blog auf einen anderen Hoster muss man alle Dateien auf den neuen Webspace via FTP hochladen. Dabei werden die Besitzerrechte geändert. Nun hat der FTP User die Besitzerrechte, nicht mehr das Script.
Das resultiert in verschiedensten Fehlermeldungen, die alle „Permission Denied“ ausgeben. Die normalen Berechtigungen von „755“ auf Ordnern und „644“ auf Dateien, wie es bei WordPress normal wäre, reichen hier nicht mehr aus. Abhilfe würde chmod „777“ schaffen aber es sollte jeder halbwegs gescheite Webmaster wissen, dass es sowas niemals geben sollte.

Also an alle All-Inkl Besitzer, die Probleme mit Besitzerrechten haben.
Prüft in eurem FTP Programm ob der Ordner, der Probleme macht (entnommen aus der Fehlermeldung natürlich), die richtigen Berechtigungen (755 z.B.) besitzt. Sollte es so sein und es gibt Fehlermeldungen dann ist der Besitzer dieses Ordners sicher euer All-Inkl Benutzername (z.B. w00b3a24).
Um das zu beheben geht in das KAS und dort unter Tools->Besitzrechte findet ihr Abhilfe.
Wählt den Nutzer „PHP-User“ und dann den Ordner (z.B. wp-content). Setzt das Häkchen von Rekursiv und bestätigt den Prozess.
all-inkl-besitzrechte-wordpress
Nach einigen Sekunden sollte Prozess abgeschlossen sein. Der gewählte Ordner gehört nun dem PHP User. Testet kurz, ob Updates/Installation von Plugins oder die benötigte Funktionalität damit korrigiert wurde. Wenn ja, Glückwunsch.
Nun solltet ihr wieder denselben Ordner (z.B. wp-content) zurück auf euren FTP-Benutzer zurückzustellen, damit die Rechte innerhalb von WordPress nicht durcheinandergewürfelt sind. Die WordPress-Funktionen sollten auch nach dem Reset zurück auf den FTP-Benutzer erhalten bleiben.

Ich habe den Fehler wahrscheinlich gefunden, das PlugIn Tweet This scheint mir den Blog unerreichbar gemacht zu haben.
Trotzdem war ich mit der Stabilität meines bisherigen Webhosters nicht zufrieden und werde daher dieses Event als Anlass nehmen, endgültig den Umstieg auf einen anderen Provider durchzuziehen.
Ich habe mich daher heute bei All-Inkl angemeldet und werde heut Abend die KK-Anträge nachschicken. Hoffentlich bin ich schnell wieder online.

anti-spam-basics-fuer-versender-spf-dkim-dmarc-samuel-zeller-367977-unsplash

Spam? Gut oder Böse?

Spam-Mails gehören mittlerweile zum Alltag eines jeden Nutzers und Empfängers und in den meisten Fällen wird der Spam-Ordner nicht einmal mehr eines Blickes gewürdigt. Dabei kann es passieren, dass wichtige und legitime Mails aus Versehen als Spam eingestuft werden. Im weiteren Verlauf des Artikels wird sicher deutlicher, dass dies keinesfalls „Versehen“ oder „Zufall“ ist, sondern aus einer Menge an Gründen und Faktoren durch Algorithmen kalkuliert wird. So kann es passieren, dass Reservierungsbestätigungen oder die legitime Lotto-Gewinnbenachrichtigung nicht im Posteingang eintrifft – Millionengewinn verpasst, schade.
Falsch eingestufter Spam ist also nicht nur ärgerlich für Empfänger, sondern vor allem auch ein Problem für Absender. Der Kunde wird nicht erreicht, wichtige Nachrichten nicht übermittelt, Umsatz geht verloren, Vertrauen und Image wird beschädigt. Die direkten und undirekten Kosten für ein Unternehmen mit Spam-Problemen können enorm sein.

Im Folgenden schreibe ich über ein paar Basics im Bereich Anti-Spam-Maßnahmen für Versender. Ziel ist es, dass versandte Mails seltener fälschlicherweise als Spam erkannt werden.

Wie funktioniert Anti-Spam für Versender?

Wenn E-Mails beim Mailserver des Empfängers eintreffen, versucht dieser Server einzuschätzen, ob die Mail tatsächlich vom angegebenen Absender stammt und der Inhalt legitim und relevant für den Empfänger ist. Ein Großteil der technischen Anti-Spam-Maßnahmen betreffen die Validierung des Absenders im Schritt 1, hier gibt es viel Potential für Optimierung. Bei Schritt 2, dem Inhalt, gibt es eher ein paar formale und syntaktische Richtlinien.
Ich schreibe das How-To aus meiner Sicht als Webhosting-Kunde von All-Inkl. Bei anderen Webhostern sowie bei eigenen Root Servern können die nötigen Schritte abweichen. Schaut bitte in die FAQ/Hilfe eures Anbieters oder fragt hier in den Kommentaren, wenn ihr nicht weiter kommt. Für Root Server gibt es hier eine Anleitung, die recht ausführlich Hilfestellung gibt.

Überprüfung der Maßnahmen

anti-spam-basics-fuer-versender-spf-dkim-dmarc-gsuite-mx-check-toolboxEs ist unbedingt empfehlenswert wenn nicht sogar kritisch erforderlich, vor UND nach den folgenden Maßnahmen die Einstellungen zu überprüfen. Wie ist der aktuelle Zustand, wie sieht es danach aus? DNS-Änderungen sind für gewöhnlich innerhalb von Sekunden aktiv und extern sichtbar, kein Warten nötig.
Zum Testen eignen sich besonders die Online Tools MxToolBox und die GSuite Toolbox MX-Check. Prüft damit direkt nach jeder DNS Änderung nach – für gewöhnlich werden diese innerhalb von Sekunden übernommen und sind von extern sichtbar, ebenso die Resultate.
Nun aber zu den Maßnahmen:

#1 – SPF

SPF, Sender Policy Framework (Wikipedia, Standard), ist ein Standard zur Überprüfung des Absenders einer E-Mail und vermutlich der wichtigste Anti-Spam-Indikator. SPF ist eine TXT-Einstellung im DNS der Absender-Domain und leicht zu setzen. Etwas mehr Wissen erfordert unter Umständen das Generieren des TXT Eintrags. Hier muss beachtet werden, welche Mailserver und Maildienste für das Versenden der Mails benutzt werden. Wenn ich den Mailserver meines Webhosters nutze, jedoch Mails über die Googlemail Weboberfläche schicke (E-Mail über SMTP eingebunden), muss ich das im SPF-Eintrag beachten. Hierzu gibt es von fast allen Anbietern entsprechende Infos/Hilfeseiten, etwas googeln hilft hier schnell.
Ein beispielhafter SPF-Eintrag, der Google als Relay inkludiert, könnte so aussehen:
v=spf1 a mx include:_spf.google.com ~all
Kein ptr im SPF, wenn MX gesetzt ist, auch wenn das viele Generatoren immernoch machen. Überprüfung mit SPF Check der MXToolBox. Weitere Infos findet ihr bestimmt in der Hilfe eures Maildienstleisters/Hosters mit der Suche nach „SPF“.
anti-spam-basics-fuer-versender-spf-dkim-dmarc-spf-setup

#2 – DKIM

DKIM, DomainKeys Identified Mail (Standard, Wikipedia), ist wie SPF ebenfalls ein Protokoll zur Überprüfung von eingehenden Mails und deren unverändertem Inhalt.
DKIM nutzt zur Überprüfung eine asymmetrische Verschlüsselungstechnik mit zwei Schlüsseln – einem privaten Schlüssel, der Mails unsichtbar angehängt wird und einem öffentlichen Schlüssel, abgelegt im DNS des Absenders. Somit kann der Empfänger-Mailserver die Schlüssel aus dem Absender DNS und der Mail-Signatur gegeneinander prüfen und validieren. Das Hinzufügen des privaten Schlüssels in den Mailserver, damit dieser unsichtbar alle ausgehenden Mails damit signiert, erfordert eine fortgeschrittene Anpassung des Mailservers bzw. Konfiguration des Mailers und übersteigt den Rahmen dieses Artikels. Für GMail-Nutzer hilft die Google DKIM Step-by-Step-Anleitung, ansonsten wieder beim Anbieter/Hoster in der Hilfe schauen bzw. Support fragen.
Der zweite Teil besteht aus einem TXT DNS Record, der zuvor generiert werden muss. Benötigt wird dafür die Domain und ein „Selektor“; eine beliebige Zeichenkette, z.B. „meindkim1“. Der Record sollte immer mit v=DKIM1;k=rsa;p= anfangen! Selbst wenn die Generatoren gerne einen der Parameter v oder k weglassen, oder diese als optional angeben, sollten beide gesetzt sein. Info: Beide Überprüfungs-Tools (MxToolBox und GSuite MX-Check) bestätigen einen validen DKIM übrigens nur mit Parametern v UND k, Warnungen falls einer fehlt. Die Überprüfung von DKIM erfordert dann ebenfalls Domain und Selektor und sollte anschließend positiv ausfallen:
anti-spam-basics-fuer-versender-spf-dkim-dmarc-dkim-check
Aber Achtung: Ausschließlich den DKIM DNS Eintrag zu setzen, ohne die Mails zu signieren, hat keine weiteren positiven Auswirkungen (meistens aber auch keine negativen) und ist daher nicht zu empfehlen.

#3 – DMARC

DMARC, Domain-based Message Authentication, Reporting, and Conformance (Standard, Wikipedia):Was wie die deutsche alte Währung klingt, ist eine Technologie zur Erweiterung von SPF und DKIM. Geliefert werden zusätzliche Informationen, wie der Empfängerserver mit geprüften Mails umgehen soll sowie die Möglichkeit von Reports der Überprüfungen. Auch hier ein DNS TXT Eintrag, der die Infos liefert. Zwei grundlegende Fragen müsst ihr euch stellen:
1. Wie sollen Mails behandelt werden, deren SPF/DKIM-Überprüfung fehlschlägt? Ignorieren / Spam / Abweisen.
2. Sollen Daten und fehlgeschlagene Überprüfungen als Reports verschickt werden und an welche Mail-Adresse?
Solltet ihr mit „Ignorieren“ dem Empfangsserver kein Verhalten vorschreiben wollen und auch keinerlei Reporting wünschen (v=DMARC1;p=none;), erfüllt DMARC keinen Zweck und hat auch keine weiteren Effekte auf den Mailempfang, kann also ausgelassen werden.
Restriktiveres Verhalten oder Reporting gewünscht? Dann wird einer der vielen existierenden Generatoren aus den gewählten Optionen einen einfachen bis recht komplexen TXT Record erstellen:
v=DMARC1; p=none; rua=mailto:admin@it-stack.de; ruf=mailto:admin@it-stack.de; fo=1;
Dieser Eintrag schickt Reportings an mich, wenn SPF oder DKIM fehlschlägt sowie generelle Reports, der Mailserver soll die Fehlschläge jedoch wie gewohnt behandeln, ich gebe kein strikteres Vorgehen vor.
anti-spam-basics-fuer-versender-spf-dkim-dmarc-check

#4 – Blacklists

Es gibt eine Vielzahl von professionell betriebenen Anti-Spam-Listen, also Blacklists, die von Mailservern zur weiteren Überprüfung abgefragt werden können. Ob mein Mailserver auf einer Blacklist steht, kann ich beispielsweise mit der MxToolBox Blacklist Suche herausfinden. Gebt hier eure Domain ein und eine Auswertung von über 100 Blackslists wird eventuelle Funde aufzeigen. Solltet euer Mailserver nicht die IP eurer Domain teilen oder weitere in das Mailing involvierten MX-Server-IPs bekannt sein, diese am besten auch noch testen.
Eure Domain/IP ist in einer Blacklist gefunden worden? Das ist unpraktisch, kann aber mal passieren. Geblacklistet werden für gewöhnlich ganze Server. Auf einem Shared Server, wie das bei Webhosting fast immer der Fall ist, sind, je nach Vertrag, 20 bis 100 weitere Kunden untergebracht. Die Chance, dass ein anderer Kunde für das Blacklisting verantwortlich ist, ist hoch.
Was tun? Auf der Betreiberseite der Blacklist gibt es meistens Suchen/Informationsportale, in denen Blacklist-Kandidaten, teilweise mit mehr Details und Begründung, gesucht werden können. Ich empfehle zwei Recherchen: Suche nach der Domain und nach der/den IPs.
So kann es sein, dass die IP-Adresse des Servers in mehreren Einträgen gefunden wird (Reportfunde bei Spamhaus ZEN: Link1, Link2, in welchen wiederum eure Domain nicht erwähnt wird), für die Domain jedoch kein Eintrag vorhanden ist. Das sind weitere Hinweise darauf, dass nicht ihr, sondern ein anderer Kunde des Servers Schuld hat.
Unabhängig von diesen Recherchen könnt ihr vermutlich wenig gegen das Blacklisting tun. Manche Betreiber bieten Unblock Formulare an, andere nicht. Informiert auf jeden Fall euren Webhoster/Mailing-Anbieter mit allen herausgefundenen Informationen über das Blacklisting – dieser hat für gewöhnlich andere Optionen und kann direkt selbst in die Behandlung der Problemursache, also gegen entsprechende Kunden, vorgehen.
anti-spam-basics-fuer-versender-spf-dkim-dmarc-blacklist-check

#5 – User Trust

Desweiteren hilft es, sich zusätzlich Trust über den User/Empfänger zu holen – beispielsweise durch das Hinzufügen eurer Absenderadresse zu den Kontakten, das Markieren der Nachrichten als „Wichtig“ oder Versehen mit Sternchen/Markern (je nach Client heißt das anders), den Absender „Nie als Spam markieren“ (ebenfalls je Client anders) und mehr. Alles, was man mit einer Mail oder einem Absender bei dem jeweiligen Anbieter des Empfängers tun kann, dass letztlich einen positiven Effekt hat. Die Anbieter speichern solche Informationen (wie oft wurde eine Mail mit Inhalt X positiv behandelt, wie oft der Absender usw.) und behandeln Mails dieses Absenders zukünftig besser. Diese Maßnahme kann man bis zu einer gewissen Anzahl mit den eigenen Mitarbeitern starten – Mails an ihre private Mailadresse schicken, bestenfalls bei unterschiedlichen Anbietern, und die Mails von ihnen „positiv behandeln“ lassen.

1und1 Webhosting

In meinem Blog kann man es an vielen Posts erkennen: Ich bin eigentlich Fan vom Webhoster All-Inklusive und dort seit über einem Jahrzehnt sehr zufrieden. Man muss aber dazusagen, dass sich an den Features, dem Design, dem Backend und auch allgemein wenig verändert hat – All-Inklusive fährt wohl das „never change a running system“ Prinzip. In der heutigen Zeit, in der Konkurrenz in Massen aus dem Boden sprießt und binnen kürzester Zeit stark aufblühen kann, ein riskantes Unterfangen.
Vor All-Inklusive hatte ich auch mal ein 1und1 Webspace, damals (so um 2009 rum) noch für ganz statische HTML Seiten, fancy erstellt mit Microsoft Frontpage … das waren Zeiten 😀 Das 1und1 Webhosting war damals schon recht funktional und modern vom Design her:
1und1 Webhosting 1und1-webhosting-test-2018-history-2009
Damals waren Stabilität und Support allerdings mein Grund zu wechseln. Ich wollte mal schauen, was 1und1 in der Zeit so gemacht hat, wie sich das Webhosting dort entwickelt hat und wie es meinen aktuellen Needs entsprechen würde.

Weiterlesen

Es stimmt mich schon fast ein wenig traurig aber es war höchste Zeit…

…mein Blog bekommt ein Facelifting!

Seit 2009 gibt es den Blog nun, das ist schon eine Weile. Seither hat sich jedoch nicht soo viel getan, vom Inhalt abgesehen. Es hat seinen Zweck immer gut erfüllt.

HAT , Vergangenheit, wohlgemerkt. Mittlerweile kann ein (erster) Besuch auf der Seite schon überraschen, nicht nur im positiven Sinne, wenn man sich – wie ich – nicht über Jahre daran gewöhnt hat. Es wirkt dunkel, zu eng, überladen, oldschool.

Also, in die Hände gespuckt, angepackt, Zeit investiert … und …
Neues Design, neuer Name, neue Domain, neue Extras.
Weiterlesen

Fehler

Folgender Fehler kann bei WordPress auftreten, vermutlich nur bei bestimmten Hostern, nachdem es installiert oder hosterübergreifend umgezogen wurde:
Das Bild zeigt den WordPress Dialog, bei dem FTP Verbindungsinformationen benötigt werden sowie den Fehler, dass diese nicht korrekt seien - egal, welche Daten man eingibt. Das liegt an fehlerhaften Besitzrechten nach der WordPress Installation auf einigen Hostern wie beispielsweise auch All-Inkl und Hosteurope.
Der Fehler erscheint vermutlich bei der Installation oder Aktualisierung von Plugins oder Themes.

Erklärung

Das Bild zeigt den WordPress Dialog, bei dem FTP Verbindungsinformationen benötigt werden. Das Phänomen tritt auf, wenn ihr WordPress von Hand auf euren FTP hochgeladen und danach die Installation ausgeführt habt. Dadurch ist das WordPress Core mit den Besitzerrechten eures FTP Nutzers, mit dem ihr die WordPress Dateien hochgeladen habt, versehen. Alle Tätigkeiten aus dem WordPress System heraus, also beispielweise das Installieren von Plugins über die WordPress „Plugins“ Oberfläche, werden jedoch server-intern von einem anderen Nutzer ausgeführt. Dieser Nutzer heißt je nach System oftmals PHP-User, www-User, www-data oder ähnlich. Nun fehlen dem Nutzer aber die Zugriffsrechte auf die entsprechenden Ordner.

Lösungen

Es gibt mehrere mögliche Lösungen:

1)
Gebt bei der WordPress Nachfrage die FTP-Nutzerdaten ein, mit denen ihr WordPress hochgeladen habt. Den Nutzer könnt ihr, falls ihr es nicht mehr genau wisst, vielleicht mit dem WebFTP-Tool eures Hosters auslesen:
Das Bild zeigt die Oberfläche eines WebFTP Programms mit markierten Besitzerinformationen eines Ordners
Im besten Falle führt WordPress danach alle Plugin Aktionen ohne Klagen aus und ihr hört nie wieder von dem Problem. Aber dann wärt ihr wahrscheinlich auch gar nicht hier gelandet.

2)
Ändert die Besitzrechte von wp-content. Nutzt dafür vom Hoster zur Verfügung gestellte Möglichkeiten der Besitzrechteveränderung (Adminbackend -> Tools).
Zuerst wird der Ordner wp-content auf den PHP-User gestellt, die benötigte WordPress Funktion getestet (z.B. Plugin-Update, sollte jetzt gehen) und dann stellt ihr den Besitzer wieder zurück auf den FTP-User. Bei mir hat das die Probleme dauerhaft behoben und die Besitzrechte sind einheitlich weiterhin auf dem FTP-Nutzer.

3)
Mein zweiter Tipp ist eigentlich der langfristig sicherste: installiert WordPress nicht von Hand sondern über die 1-Click-Install-Methode eures Hosters. Praktisch jeder Webhoster bietet die Installation von bekannter Software auf seinem System an, WordPress ebenfalls. Dabei richtet der Hoster ein fertig installiertes und eingerichtetes System für euch ein, meistens mit nur wenigen Klicks. Dieses System hat definitiv keine Rechteprobleme, ist nun aber frisch installiert. Je nachdem, wie jung oder alt euer Blog ist, kostet es nun weniger oder mehr Aufwand, die Inhalte in das neu installierte System zu transferieren. Aber diese Lösung ist am sichersten und wird keine zukünftigen Probleme mehr machen, ich empfehle das also.
Export/Import: Der Export besteht im Grundlegenden aus 2 Typen: Daten (Beiträge, Kommentare usw), Plugins und Themes.
Daten: Benutzt entweder die WordPress eigene Export-Funktion unter „Werkzeuge -> Daten exportieren“ oder exportiert eure komplette WordPress Datenbank (SQL Export via phpMyAdmin). Diesen Export dann im neuen WordPress bzw. dessen Datenbank.
Plugins/Themes: Entweder ihr installiert im neuen WordPress die Komponenten von Hand (je nachdem wieviele es sind), oder ihr zieht euch direkt vom FTP die Ordner „plugins“ und „themes“ und überschreibt einfach diese Ordner in eurem neuen WordPress System.
Anschließend müsste der neue WordPress Blog die Plugins, Themes (die beide ggf. noch aktiviert werden müssen) und Daten enthalten.
Ich werde aber demnächst nochmal einen ausführlichen Beitrag über gute WordPress Backup Methoden schreiben und eine komplette Backup Lösung konzipieren.

4)
Tragt in eure .htaccess Datei in der Root eures WordPress Blogs (also direkt im obersten Ordner, beispielsweise „/blog/“) folgende Zeile ein:

AddHandler php5-cgi .php

Hintergrund: Link

Dieser Beitrag ist eine Ergänzung bzw. Erweiterung des vorherigen Posts „FTP-Backup-Lösung mit PHP“. Die große Neuerung der Version 1.2 ist die Funktion MySQL Datenbanken sichern zu können. Auch hier wird ein Backup erstellt, überschüssige Backups (wenn mehr vorhanden sind als der gewünschte Maximalwert) werden gelöscht und neue Backups ggf. zu einem externen Server übertragen. Mit Version 1.2.1 gibt es zusätzlich die Möglichkeit, ALLE Ordner der Root-Ebene, mit Ausnahmen, zu sichern und Version 1.2.2 ermöglicht detailliertere Ausnahmen.

Features

Diese Lösung (v1.2.2) bietet nun folgenden Funktionsumfang:

  • beliebig viele Ordner des All-Inkl Accounts in einzelne .tar.gz Archive sichern
  • oder: alle Ordner der Root-Ebene, mit möglichen Ausnahmen, sichern
  • Detailliertere Ausnahmen mit Datei- und Ordnermasken wie z.B. „*.tar.gz“
  • Einschränkung der Anzahl aufgehobener Backups – älteste Backups werden automatisch gelöscht
  • detaillierte Ausgabe inklusive benötigter Zeit
  • E-Mail Benachrichtigung
  • Farbliche Hervorhebung
  • Verbesserungen des Backup Prozesses, zusätzliche Überprüfungen und Debug Infos bei Fehlern
  • Verbinden eines externen FTP Server und Kopieren aller neuen Backups
  • Angabe eines beliebigen FTP Ports
  • Verbindung über FTPs (SSL FTP) Port 21 wird verwendet, unsicheres FTP nur noch als Fallback
  • detailliertere Informationen über die Backups in der Benachrichtigungsmail
  • Backup von beliebig vielen MySQL Datenbanken von localhost, Aufräumen der Backups und Export an externen Server
  • E-Mail Anpassungen über Parameter möglich – Betreff, Anmerkungen, Details
  • ausführliche Ausgabe aller Backups im Skript und per Mail

Zwischen den Zeilen 37 und 82 findet ihr alle Variablen, die ihr anpassen müsst/könnt.

Zur Datenbanksicherung ist zu sagen, dass diese auf den Hoster All-Inkl optimiert ist. Sie sichert nur Datenbanken von localhost und benötigt den PHP Befehl „exec()“ sowie die Komponenten „mysqldump“ und „gzip“, die auf All-Inkl Servern erlaubt bzw. installiert sind. Auf anderen Hostern müssen daher ggf. diese Möglichkeiten geschaffen oder die MySQL Sicherung (Zeile 190-191) verändert werden.

Screenshot

Das Bild zeigt die Ausgaben des Backup Skripts und die versendete E-Mail Benachrichtigung

Code

Schaut für Code-Alternativen oder ein weniger komplexes System auch auf die Version 1.1 und 1.0

Update 08.2017: Version 1.2.2 nur noch als Download
Code/Download der backup.phpx

Sicherheit: Absicherung mit .htpasswd

Das Verzeichnis, in dem die backup.php und die Backups liegen, sollte natürlich mit einer .htpasswd abgesichert werden. Mit einer eingerichteten .htpasswd Datei ist zuerst ein Login nötig, eh man auf bestimmte Bereiche des Webspaces zugreifen darf:
Das Bild zeigt eine Login Datenabfrage beim Aufruf der Backup URL
Die Datei .htpasswd enthält hierbei die Login Daten und in der .htaccess des Backup Unterordners wird festgelegt, dass eine .htpasswd diesen Ordner schützt. Die .htpasswd generiert ihr euch am besten mit diesem Generator und baut sie dann folgendermaßen in die .htaccess dieses Ordners ein:

AuthType Basic
AuthName "Backups"
AuthUserFile /www/htdocs/all-inkl-account/backup/.htpasswd
Require valid-user

Sicherheit: Absicherung mit .htaccess

Da wir schonmal bei .htaccess sind, erhöhen wir die Sicherheit mit ein paar weiteren grundlegenden Zeilen:

#block access to certain file types
<FilesMatch ".(htaccess|htpasswd|ini|phps|log|sh|tar.gz)$">
 Order Allow,Deny
 Deny from all
</FilesMatch>

# disable directory browsing
Options All -Indexes

# prevent basic url hacking stuff
# from: http://www.queness.com/post/5421/17-useful-htaccess-tricks-and-tips
RewriteEngine On
# proc/self/environ? no way!
RewriteCond %{QUERY_STRING} proc/self/environ [OR]
# Block out any script trying to set a mosConfig value through the URL
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
# Block out any script trying to base64_encode crap to send via URL
RewriteCond %{QUERY_STRING} base64_encode.*(.*) [OR]
# Block out any script that includes a <script> tag in URL
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|[|\%[0-9A-Z]{0,2})
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ /index.htm [F,L]

ErrorDocument 401 /backup/index.htm
ErrorDocument 403 /backup/index.htm
ErrorDocument 404 /backup/index.htm
ErrorDocument 500 /backup/index.htm

Dadurch werden Zugriffe auf bestimmte Dateitypen (auch die Backup Dateien), Verzeichnisse und Zugriffe mit sicherheitskritischen Merkmalen unterbunden. Alle diese nicht validen Zugriffe bekommen die index.htm serviert, welches einfach nur eine leere HTML Datei ist. Somit wird den Abfragenden auch kein detaillierter Grund gegeben, warum der Zugriff fehlschlug.

Automatisierung mit All-Inkl Cronjobs

Zu guter Letzt hilft diese Sicherungslösung natürlich nur, wenn sie automatisiert wird. Auch dies ist stark abhängig von eurem Hoster, System, dem Anwendungsbereich usw.
Im Falle von All-Inkl als Webhoster, könnt ihr die Cronjob Funktionalität im KAS (KAS -> Tools -> Cronjobs) benutzen:
Das Bild zeigt die Cronjob Einrichtungsoberfläche von All-Inkl