Kategorie: Website schützen

Die Sicherheit durch .htaccess bedeutend verbessern

Wenn du eine Webseite betreibst, kannst du die Sicherheit durch .htaccess bedeutend erhöhen. Die .htaccess-Datei ein mächtiges Werkzeug, um die Sicherheit deines Webspace zu verbessern. Lass uns einen Blick darauf werfen, wie du diese Datei nutzen kannst, um deine Webseite vor unerwünschten Zugriffen und potenziellen Bedrohungen zu schützen.

Eine .htaccess wird in der Regel bei dir unterstützt, sofern dein Webspace unter einem Apache- oder Nginx-Server läuft!

Sicherheit durch .htaccess – Homepage Sicherheit

Zum Thema Sicherheit durch .htaccess folgt zuerst eine Erklärung zu wichtigen Einstellungen in der .htaccess.

Header set X-XSS-Protection „1; mode=block“:

• Diese Einstellung aktiviert den integrierten XSS-Schutz (Cross-Site Scripting) in modernen Browsern. Der Header X-XSS-Protection mit dem Wert „1; mode=block“ verhindert, dass Browser Seiten laden, die XSS-Angriffe enthalten könnten. Falls ein solcher Angriff erkannt wird, blockiert der Browser die Ausführung des schädlichen Skripts.

Header set X-Frame-Options „SAMEORIGIN“:

• Diese Einstellung steuert, ob eine Webseite in einem HTML-Frame (zum Beispiel durch <iframe>) angezeigt werden darf. Der Wert „SAMEORIGIN“ erlaubt nur das Einbetten der Seite in Frames, die von der gleichen Ursprungsdomain stammen. Dadurch wird das Risiko von Clickjacking-Angriffen reduziert.

Header set X-Content-Type-Options „nosniff“:

• Der Header X-Content-Type-Options mit dem Wert „nosniff“ verhindert, dass der Browser den MIME-Typ einer Datei automatisch interpretiert. Dies schützt vor Angriffen, bei denen Angreifer versuchen, schädlichen Code in Dateien mit falschen MIME-Typen einzuschleusen.

Header always set Strict-Transport-Security „max-age=63072000; includeSubDomains“:

• Diese Einstellung implementiert das „Strict Transport Security“ (HSTS)-Protokoll. Der Header gibt an, dass der Browser für einen bestimmten Zeitraum (hier 2 Jahre) eine sichere Verbindung (HTTPS) erzwingen soll. Die Option „includeSubDomains“ bedeutet, dass diese Regel auch für alle Subdomains der Hauptdomain gilt.

Header set Referrer-Policy „same-origin“:

• Diese Einstellung legt die Politik für die Übermittlung von Referrer-Informationen fest. Der Wert „same-origin“ sorgt dafür, dass der Referrer nur an Seiten auf der gleichen Ursprungsdomain übergeben wird. Dies trägt dazu bei, sensible Informationen zu schützen, indem verhindert wird, dass der Referrer auf externe Domains übertragen wird.

Mehr Sicherheit durch .htaccess – Homepage Sicherheit

Für mehr Sicherheit durch .htaccess hier nun das Beispiel für diese wichtigen Einstellungen in der .htaccess:

# X-XSS-Protection
<IfModule mod_headers.c>
Header set X-XSS-Protection „1; mode=block“
</IfModule>
# X-Frame-Options
<IfModule mod_headers.c>
Header set X-Frame-Options „SAMEORIGIN“
</IfModule>
# X-Content-Type-Options
<IfModule mod_headers.c>
Header set X-Content-Type-Options „nosniff“
</IfModule>
# Strict-Transport-Security
<IfModule mod_headers.c>
Header always set Strict-Transport-Security „max-age=63072000; includeSubDomains“
</IfModule>
# Referrer-Policy
<IfModule mod_headers.c>
Header set Referrer-Policy „same-origin“
</IfModule>

Die Möglichkeit, mit der .htaccess bestimmte Bots und etc. aussperren.

Kein Zutritt für Hacker- und Login-Idioten

Diese Konfiguration in der .htaccess-Datei dient dazu, bestimmte Bots oder User Agents von deiner Webseite auszusperren. Hier wird die Direktive SetEnvIfNoCase verwendet, um anhand des User-Agent-Headers der HTTP-Anfragen bestimmte Bots zu identifizieren. Wenn ein User Agent mit einem der aufgelisteten Bots übereinstimmt, wird eine Umgebungsvariable (bad_bot) gesetzt.

Hier ein Beispiel für die .htaccess dazu:

SetEnvIfNoCase User-Agent „Proxy“ bad_bot
SetEnvIfNoCase User-Agent „80legs“ bad_bot
SetEnvIfNoCase User-Agent „Pixray“ bad_bot
SetEnvIfNoCase User-Agent „Squider“ bad_bot
SetEnvIfNoCase User-Agent „Seznam“ bad_bot
SetEnvIfNoCase User-Agent „Mail.ru“ bad_bot
SetEnvIfNoCase User-Agent „BaiDu“ bad_bot
SetEnvIfNoCase User-Agent „Python“ bad_bot
SetEnvIfNoCase User-Agent „WGet“ bad_bot
SetEnvIfNoCase User-Agent „Yandex“ bad_bot
SetEnvIfNoCase User-Agent „sqlmap“ bad_bot
SetEnvIfNoCase User-Agent „Spider“ bad_bot
SetEnvIfNoCase User-Agent „Other“ bad_bot
SetEnvIfNoCase User-Agent „AhrefsBot“ bad_bot
SetEnvIfNoCase User-Agent „Java“ bad_bot
<Limit GET POST PUT HEAD>
order allow,deny
allow from all
deny from env=bad_bot
</Limit>

Zugriffskontrolle Sicherheit durch .htaccess: Wer darf rein?

Die .htaccess-Datei ermöglicht es dir, den Zugriff auf deine Webseite zu steuern. Mit ein paar einfachen Befehlen kannst du festlegen, wer deine Seite betreten darf und wer eben gesperrt wird! Das ist besonders nützlich, um zum Beispiel bestimmte Netzwerke zu sperren, die gerne von vielen Hacker- und Login-Idioten genutzt werden.

Hier sind die Erklärungen für die einzelnen Anweisungen:

• order allow,deny: Gibt die Reihenfolge an, in der die allow und deny Anweisungen angewendet werden sollen. Hier wird zuerst allen Anfragen erlaubt (allow from all), und dann werden diejenigen, die den aufgeführten Kriterien entsprechen, verweigert (deny from …).
• deny from .amazonaws.com: Blockiert den Zugriff für alle Anfragen, die von Domänen mit der Endung „.amazonaws.com“ kommen.
• deny from 2.38.128.0/17: Blockiert den Zugriff für alle IP-Adressen im Bereich von 2.38.128.0 bis 2.38.255.255.

Ähnlich werden alle nachfolgenden deny-Anweisungen genutzt, um den Zugriff für bestimmte IP-Adressbereiche oder Domänen zu blockieren. Dies kann nützlich sein, um beispielsweise den Zugriff von bekannten schädlichen IPs oder Domänen einzuschränken.

Die folgende Konfiguration in der .htaccess-Datei dient dazu, den Zugriff auf die Webseite für bestimmte IP-Adressbereiche und Domänen zu sperren. Das Sperren des Domain-Namen funktioniert leider nur, wenn er auch übertragen wird.

Was immer super funktioniert, ist das Sperren eines kompletten Netzwerks eines Hosting- oder Cloud-Providers. Hier wird die <Limit>-Direktive verwendet, um den Zugriff für bestimmte HTTP-Methoden wie GET und POST einzuschränken.

Weitere Sicherheit durch .htaccess, das Beispiel dazu:

<Limit GET POST>
order allow,deny
allow from all
deny from .amazonaws.com
deny from .bc.googleusercontent.com
deny from .co.nz
deny from 2.38.128.0/17
deny from 3.144.0.0/13
deny from 4.240.0.0/12
deny from 5.23.50.0/24
deny from 13.64.0.0/11
deny from 20.64.0.0/10
deny from 36.111.67.0/24
deny from 40.76.0.0/14
deny from 47.111.0.0/16
deny from 88.99.0.0/16
deny from 91.199.3.0/24
deny from 92.39.104.0/21
deny from 106.227.48.0/22
deny from 114.224.0.0/12
deny from 118.80.0.0/15
deny from 123.180.0.0/14
deny from 125.88.0.0/13
deny from 176.99.128.0/19
deny from 188.40.0.0/16
deny from 203.145.46.0/23
deny from 222.79.64.0/18
deny from 2400:8901::/32
deny from 2401:5f80:5000::/36
deny from 2600:3c00::/32
deny from 2a01:4f8::/32
deny from 2a06:2ec0::/32
</Limit>

Soviel zu dem wichtigen Thema – Mehr Sicherheit durch .htaccess. Eine Übersicht über alle Tipps zum Thema Website schützen über den Link.

Weitere Erklärungen zur .htaccess über diese Website.

Deine WordPress Sicherheit – warum ist XMLRPC gefährlich?

In Bezug auf die WordPress Sicherheit spielte die XML-RPC-Schnittstelle bei seiner Einführung im Jahr 2003 noch weniger eine Rolle. Über die XML-RPC-Schnittstelle wurde von WordPress eine Bandbreite an Funktionen angeboten, die es dir ermöglichen, Daten aus der Ferne zu übertragen und mit deiner Webseite zu interagieren. Auch wenn diese Schnittstelle damals gewisse Vorteile und Funktionen bereitstellt, birgt sie besonders heute wirklich ein erhebliches Risiko!

Heute werde ich dir erklären, was genau diese (alte) Schnittstelle ist, welche Möglichkeiten sie bietet und wie du sie heute am besten deaktivieren solltest.

Die WordPress Sicherheit – Was ist eigentlich diese berüchtigte xmlrpc.php?

Unter /xmlrpc.php stellt WordPress standardmäßig eine Schnittstelle zur Verarbeitung von XML-Dateien bereit. RPC steht hierbei für Remote Procedure Call, was so viel bedeutet wie das Aufrufen einer entfernten Funktion. Über diese Schnittstelle kommunizieren verschiedene Systeme miteinander, wie beispielsweise mobile Anwendungen oder externe Programme.

Ein gutes Beispiel dafür ist die mobile WordPress-App, die es ermöglicht, Medien hochzuladen und Beiträge zu veröffentlichen. Nun ja, mir wäre es eh zu nervig, über ein Smartpohne mit dem Fummel-Display im Blog zu arbeite. Das geht doch viel besser am Notebook oder PC oder?

Bis zur Version 3.5 kommunizierten diese App und deine WordPress-Seite ausschließlich über die XML-RPC-Schnittstelle. Heutzutage erfolgt dies übrigens über die REST-Schnittstelle, da die veraltete xmlrpc.php infolge dessen also ersetzt wurde.

Warum wird xmlrpc.php als gefährlich angesehen?

Die WordPress XML-RPC-Schnittstelle gewährt einen öffentlichen Zugang zu internen Funktionen. Dies stellt einen verlockenden Angriffsvektor für deinen WordPress-Server dar. Die häufigsten Angriffe, die beobachtet wurden, sind daher DDoS-Attacken und Brute-Force-Angriffe.

Beispiel WordPress Sicherheit XMLRPC

Bei einer DDoS-Attacke nutzt der Angreifer die XML-RPC-Schnittstelle (siehe Bild rechts!), die eigentlich für die Registrierung von Pingbacks gedacht ist. Ein Pingback ist ein Benachrichtigungssystem, das den ursprünglichen Verfasser über Verlinkungen in anderen Blogbeiträgen informiert. Ein Angreifer kann damit eine große Anzahl von Pingbacks gleichzeitig senden, um deinen Server zu überlasten und infolgedessen deine Webseite unzugänglich zu machen.

Bei einem Brute-Force-Angriff wird beispielsweise die wp.getUsersBlogs-Funktion der XML-RPC-Schnittstelle genutzt, um hiermit eine Vielzahl von Benutzernamen- und Passwortkombinationen auszuprobieren. Wenn dieser Angriff erfolgreich ist, erhält der Angreifer gültige Anmeldeinformationen und kann sich in die gehackte Webseite einloggen.

In unseren täglichen Hacker Protokoll sind es bis heute oft Versuche, mittel XMLRPC an die Wensite zu kommen, um sie zu übernehmen. Diese Idioten bekommen hier und auf bersits vielen anderen Homepage von Freunden dann ein 404. Sie landen dann von den anderen Websites immer hier auf unserer Homepage, Haha. 🙂

Sollte man bzgl. der WordPress Sicherheit die xmlrpc.php deaktivieren?

Falls bei deiner Homepage keine Abhängigkeiten von dieser Schnittstelle bestehen, kannst du sie wirklich problemlos deaktivieren. Die Schnittstelle existiert ja weiterhin, um eben die Abwärtskompatibilität mit älteren Systemen noch zu gewährleisten. Daher kann das WordPress-Team diese Schnittstelle in zukünftigen Versionen leider noch nicht deaktivieren. Andernfalls könnten sonst veraltete Systeme nicht mehr mit WordPress kommunizieren.

Aufgrund dieser Abhängigkeiten kann allerdings auch nicht jeder die Schnittstelle deaktivieren. Hier können jedoch verschiedene Plugins wie „Disable XML-RPC Pingback“ helfen, die dann nur bestimmte Funktionalitäten der Schnittstelle deaktivieren.

Wie kann man die Schnittstelle vollständig entfernen?

Ein einfaches Löschen der Datei reicht hier bei weitem natürlich nicht aus, da diese bei jedem kommenden WordPress-Update immer wieder neu erstellt würde. Die Schnittstelle kann am besten durch die Konfiguration der Webserversoftware wie Apache- oder NGINX-Server entfernt werden. Wenn das zu technisch ist, kann problemlos ein Plugin wie „Disable XML RPC API“ genutzt werden, um die Schnittstelle zu deaktivieren.

Alternativ gibt es auch diesen Filter, über den ich bereits einen Beitrag geschrieben habe. Dieser Filter deaktiviert die XML-RPC-Schnittstelle (rechts ein Bild dazu):

WordPress Sicherheit XMLRPC deaktivieren

Hier der als Text dazu:

add_filter( ‚xmlrpc_enabled‘, ‚__return_false‘ );

Wenn du die Schnittstelle selbst deaktivieren möchtest, folge basierend auf deinem genutzten Webserver diesen Schritten. Beim Entfernung unter Apache kann der Zugriff auf Dateien über die .htaccess-Datei gesteuert werden. Um den Zugriff auf die xmlrpc.php-Datei zu verbieten, füge folgenden Code im Stammverzeichnis von WordPress in die .htaccess-Datei ein:

<Files xmlrpc.php>
Order Allow,Deny
Deny from all
</Files>

Beim Entfernen unter NGINX wird der Zugriff über einen Serverblock gesteuert. Innerhalb des server { … } Blocks muss folgender Code eingefügt werden:

location ~* ^/xmlrpc.php$ {
return 403;
}

Alternativ kannst du diesen Code in einer weiteren Konfigurationsdatei unter /etc/nginx/includes speichern und in jedem WordPress Serverblock diese Konfiguration mittels include /etc/nginx/includes/proxy.conf einbinden.

Als Ergenis solltest du die Fehlermeldung 403 erhalten. 🙂 Dann funktioniert die Regel, der Zugriff auf xmlrpc.php ist jetzt verwehrt.

Die WordPress Sicherheit wurde erhöht, das Ziel wurde erreicht.

Nun solltest du sicherer unterwegs sein, ohne die eh veraltete XML-RPC-Schnittstelle. Um sicherzugehen, versuche einfach mal, deine URL mit einem angehängten /xmlrpc.php zu öffnen. Du solltest eine 403-Fehlermeldung erhalten, ähnlich wie bei unserer Webseite hier.

Bleibe immer sicher und halte dein WordPress durch eine höhere Sicherheit geschützt!

Weitere Infos zu XMLRPC übrigens auch auf Wiki. 😉

Das Webseiten-Login absichern ist sehr wichtig!

Dein Webseiten-Login absichern ist wirklich von sehr entscheidender Bedeutung, besonders wenn du Zugang zum Administrationsbereich hast. Eine der effektivsten Maßnahmen zur Sicherung deiner Webseite ist die Vermeidung von Standard-Login-URLs.

Standard-Login-URLs sind die typischen Pfade bei verschiedenen CMS-Systemen, über die Administratoren auf den Login-Bereich ihrer Website zugreifen, wie z.B. „deinewebsite.com/wp-admin“ oder „deinewebsite.com/admin“. Diese sind ja allgemein bekannt und erleichtern es potenziellen Angreifern, gezielt nach diesen Zugangspunkten zu suchen und Angriffe zu starten.

Wir sehen es ja immer wieder bei den illegalen Login-Versuchen in unseren Log-Files über mehrere .DE- und .COM-Domains.

Das Ändern der Standard-Login-URL kann als eine Art „Türschlosswechsel“ gesehen werden. Indem du diese URL änderst, machst du es den Angreifern, insbesondere den sogenannten LOGIN-IDIOTEN schwerer, den Eingang zu finden. Dies ist ein wichtiger Schritt, um dein System vor Brute-Force-Angriffen und anderen Formen der unbefugten Zugriffe zu schützen.

Webseiten-Login absichern – Zugriff verweigert!

Wie kann man das Webseiten-Login absichern?

Hier sind nun einige Möglichkeiten, wie du die Standard-Login-URL deiner Website ändern oder auch verbergen kannst:

• Verwende Plugins oder Sicherheitstools: Es gibt verschiedene Plugins und Sicherheitslösungen für verschiedene Content Management Systeme (CMS) wie WordPress, Joomla oder Drupal, die es dir ermöglichen, die Login-URL anzupassen oder zu verbergen. Diese Tools bieten oft benutzerfreundliche Optionen, um die URL nach deinen Präferenzen zu ändern.
• Manuelle Anpassung durch Entwickler: Für fortgeschrittene Benutzer oder Entwickler ist es möglich, die Standard-Login-URL manuell durch Anpassung der Konfigurationsdateien oder mittels Codeänderungen zu ändern. Dies erfordert jedoch ein gewisses technisches Verständnis und sollte mit Vorsicht erfolgen, um das Funktionieren der Webseite nicht zu beeinträchtigen.
• Implementiere zusätzliche Sicherheitsebenen: Selbst wenn die Login-URL geändert wurde, solltest du dennoch zusätzliche Sicherheitsmaßnahmen wie die Zwei-Faktor-Authentifizierung (2FA) oder IP-basierte Zugriffsbeschränkungen implementieren, um die Sicherheit noch weiter zu erhöhen.

Es ist wichtig zu betonen, dass das Ändern der Login-URL ein sehr wichtiger Schritt ist, aber nicht die einzige Maßnahme zur Sicherung deiner Website sein sollte. Es ist eine Ergänzung zu anderen Sicherheitspraktiken wie der Verwendung starker Passwörter, regelmäßiger Updates und Überwachung der Login-Aktivitäten.

Im Artikel vorher hatten wir ja schon das Einschränken der Login-Versuche behandelt. Dies ist auch eine sehr wichtige Maßnahme, um die Sicherheit einer Homepage zu erhöhen.

Indem du die Standard-Login-URL deiner Website änderst, kannst du potenzielle Angreifer abschrecken und die Sicherheit deiner Online-Präsenz erhöhen.

Das Websiten-Login absichern unter WordPress als Beispiel

Homepage-Login schützen mit WPS Hide Login für WordPress

Wie schon im vorherigen Artikel angesprochen, gibt es auf für das Absichern des Logins ein sehr gutes Addon. Das WordPress-Login absichern ist ganz einfach. Es kommt vom gleichen Anbieter wir das bereits bekannte WPS Limit Login. 🙂

Wir empfehlen hier das WPS Hide Login, es ist einfach und doch genial. Du kannst damit sehr effektiv dein Homepage-Login schützen. Von außen kann man die neue URL des Logins nicht mehr finden oder auslesen. 🙂

Nach der Installation und Aktivieren gehe beim Addon in die Einstellungen. Hier kannst du nun dein Homepage-Login schützen. Das sieht dann so aus:

Es gibt 2 neue Felder. Das erste für die neue Login-URL. Das zweite Feld ist für die Fehlerbehandlung. Wähle für die neue Login-URL aber NICHT sowas:

1234 ist zu einfach, das finden die Login-Idioten schnell heraus. Nimm besser ein Begriff aus mehreren Wörtern, hier nur ein Beispiel:

Websiten-Login absichern – Beispiel WPS Hide Login für WordPress

Der zweite rote Pfeil, hier kannst du die Fehlerseite auswählen, sie behandelt dann den Fehler beim ungültigen Login. Bei uns sind viele Websites mit der 404 so eingerichtet, dass die ganzen Login-Idioten dann hier auf unserer Homepage Hacker-Idioten landen. Haha… Mit diesen Addon kannst du sehr gut dein Homepage-Login absichern.

Bleib also stets immer auf dem neuesten Stand der Sicherheitspraktiken, um deine Website bestmöglich zu schützen.

Die Login-Versuche begrenzen – Schütze das Admin-Konto deiner Website

In unseren ersten Artikel zum Thema Login-Versuche begrenzen geht es um die Login-Sicherheit deiner Homepage. In den Log-Files unserer Websites sehen wir ganz klar, fast 50% der armseeligen Versuche, die Homepage zu übernehmen, sind Login-Versuche.

Login-Versuche unbedingt eingrenzen!

Die Sicherheit deiner Website liegt in deinen Händen, insbesondere wenn du auf der Homepage als Administrator agierst. Der Schutz deiner Anmeldedaten ist von sehr entscheidender Bedeutung, um deine Website vor den z.T. unzähligen unerwünschten Zugriffen zu bewahren. Eine der wirksamen Methoden, um deine Anmeldeseite zu sichern, ist also die Begrenzung der Anzahl der Login-Versuche.

Warum ist die Begrenzung der Login-Versuche so wichtig?

Login-Versuche begrenzen gegen die Login Idioten – ScriptKiddys

Stell dir vor, jemand versucht sich wiederholt mit verschiedenen Passwörtern in dein Admin-Konto auf deine Homepage einzuloggen. Das nennt man einen „Brute-Force-Angriff“. Ohne Schutzmaßnahmen könnte ein solcher Angriff im schlimmsten Fall Erfolg haben und damit den Zugang zu sensiblen Teilen deiner Website ermöglichen. Durch die Begrenzung der Anzahl von Login-Versuchen pro bestimmtem Zeitraum kannst du diese Art von Angriffen erheblich erschweren.

Wie kannst du die Begrenzung der Login-Versuche umsetzen?

Viele Content-Management-Systeme (CMS) und Website-Plattformen bieten Funktionen oder Plugins an, mit denen du die Anzahl der zulässigen Login-Versuche begrenzen kannst. Beim am häufigsten eingesetzen System WordPress gibt es da mehrere Plugins aber nur wenige sind wirklich gut! Diese Tools ermöglichen es dir, eine bestimmte Anzahl von Fehlversuchen festzulegen, bevor ein Konto für eine definierte Zeitspanne gesperrt wird.

Schritte zur Implementierung der Begrenzung der Login-Versuche

• Plattform überprüfen: Überprüfe, ob deine Website-Plattform bereits eine integrierte Funktion zur Begrenzung von Login-Versuchen hat. Falls nicht, suche nach zuverlässigen Sicherheits-Plugins oder Erweiterungen, die diese Funktion bieten.
• Einstellungen anpassen: Konfiguriere die maximal zulässige Anzahl von Login-Versuchen und die Dauer der Sperrzeit sorgfältig. Eine zu strikte Einstellung könnte legitime Benutzer beeinträchtigen, während eine zu lasche Einstellung die Sicherheit deines Kontos gefährden könnte.
• Regelmäßige Überprüfung: Überwache regelmäßig die Login-Aktivitäten, um verdächtige oder ungewöhnliche Muster zu erkennen. Dies ermöglicht dir, potenzielle Angriffe frühzeitig zu identifizieren und entsprechend zu handeln.

Hier nur ein Beispiel aus der Praxis, warum man die Login-Versuche begrenzen sollte!

Er wenn man die fehlgeschlagenen Login-Versuche sieht, wird einem klar, was da abgeht. Viele Webmaster oder Administratoren wissen ja gar nicht, was da so den ganzen Tag versucht wird. Hier sind es nur die versuchten Brute-Force-Angriffe. Andere Versuche, die Homepage zu übernehmen, tauchen da ja noch gar nicht auf. Mittlerweile ist auch diese betroffene Website gegen unzählige Login-Versuche geschützt:

Login Versuche begrenzen – Login-Versuche auf Website

Fazit zum Thema Login-Versuche begrenzen

Login-Idioten gesperrt

Die Begrenzung der Login-Versuche ist eine effektive Verteidigungslinie gegen Angriffe auf dein Administrator-Konto. Indem du diese Sicherheitsmaßnahme implementierst, trägst du dazu bei, deine Website vor unerwünschten Zugriffen zu schützen und die Vertraulichkeit deiner Daten zu wahren.

Also, zögere nicht länger! Sichere dein Admin-Konto noch heute, indem du die Login-Versuche einschränkst und damit einen entscheidenden Schritt hin zu einer sichereren Website machst.

Wir nennen diese kriminellen Typen, die versuchen, sich als Admin auf die Homepage einzuloggen übrigens Login-Idioten. Die meisten Versuche sind zwar eher von dummen Amateuren oder Script-Kiddies aber auch ein Idiot kann ja mal Erfolg habe.

Sichere dein Homepage also mehr ab und bleib sicher im Netz! 🙂

Als Beispiel der täglichen Login- und Hacking-Versuche gehe auf den Link.

Als Tipp von uns, das Plugin WPS Limit Login für Websites die unter WordPress laufen ist sehr zu empfehlen! Hier kannst du das WordPress-Login einschränken. 🙂

Eine Sicherheitslösung mehr Sicherheit bei Homepages wird auch bald durch einen Geschäftspartner angeboten. 😉