Bad Bots

[Tobi]

Was mich nur noch interessieren würde, wären ein regelset für Anwendungen wie beispielsweise WordPress. Denn die bösen Jungs, wie ihr sagt, besuchen eben leider auch sehr gerne WordPress präsenzen. Ist da auch etwas angedacht??

Schon fertig.
https://de.wordpress.org/plugins/limit- ... -reloaded/
und https://wordpress.org/plugins/disable-xml-rpc-api/

Warum also das Rad neu erfinden?

[goldene-zeiten]

Warum, kann ich beantworten:

1.
Jede WordPress-Installation erfordert wieder und wieder die Installation der PlugIns.

2.
Performance besser, je weniger PlugIns

3.
Updates bei WordPress auf Hauptversion einfacher, sofern PlugIn noch nicht aktuell wäre.

4.
Zentrale Verwaltung in KeyHelp

5.
WordFence gibt es auch noch - sehr gut und mächtig, aber die Funktion des Verbannens der bösen Buben gefällt mir (dauerhaft)

[Fezzi]

Ein wenig Google hilft:

Fail2Ban is an effective security tool for protecting WordPress sites from brute-force attacks and other malicious activities. It works by monitoring log files for suspicious activity and automatically banning IP addresses that exceed a predefined threshold of failed login attempts.

## Overview of Fail2Ban

Fail2Ban operates by creating "jails," which are configurations that specify which log files to monitor, the patterns of suspicious activity to look for (using regex), and the actions to take when an attack is detected. It can modify firewall rules to block offending IP addresses, thereby reducing the load on the server and preventing unauthorized access.

## Setting Up Fail2Ban for WordPress

### 1. Installation

To install Fail2Ban on an Ubuntu server, you can use the following command:

```bash
sudo apt-get install fail2ban
```

### 2. Configuring Fail2Ban for WordPress

After installation, you need to create a filter and a jail configuration for WordPress.

#### Create a Filter

Create a filter file at `/etc/fail2ban/filter.d/wordpress.conf` with the following content:

```ini
[Definition]
failregex = ^<HOST> .* "(GET|POST) /+wp-login.php
^<HOST> .* "(GET|POST) /+xmlrpc.php
ignoreregex =
```

This configuration will detect failed login attempts to `wp-login.php` and `xmlrpc.php`.

#### Create a Jail Configuration

Edit the jail configuration file, usually located at `/etc/fail2ban/jail.local`, and add the following:

```ini
[wordpress]
enabled = true
filter = wordpress
logpath = /var/log/apache2/access.log # Adjust based on your server's log path
maxretry = 5
findtime = 600
bantime = 3600
action = iptables[name=WordPress, port=http, protocol=tcp]
```

This configuration enables the WordPress jail, specifies the log file to monitor, and sets the parameters for retries, time to find failed attempts, and the ban duration.

### 3. Restart Fail2Ban

After making these changes, restart the Fail2Ban service to apply the new configurations:

```bash
sudo systemctl restart fail2ban
```

### 4. Monitoring Fail2Ban

You can check the status of your Fail2Ban jails to see if they are working correctly:

```bash
fail2ban-client status wordpress
```

This command will show you the number of currently banned IPs and other statistics related to the WordPress jail.

## Additional Recommendations

- **Using Plugins**: The WP fail2ban plugin can also be installed to integrate Fail2Ban directly with WordPress, enhancing logging and providing additional configuration options[1][4].

- **Combine with Other Security Measures**: While Fail2Ban is effective, it is advisable to use it alongside other security measures like strong passwords, web application firewalls (WAFs), and security plugins such as Wordfence to provide comprehensive protection against various types of attacks[2][3].

By implementing Fail2Ban and configuring it properly, you can significantly enhance the security of your WordPress site against brute-force attacks and unauthorized access attempts.

Citations:
[1] https://wordpress.org/plugins/wp-fail2ban/
[2] https://www.dogsbody.com/blog/how-to-se ... ress-site/
[3] https://runcloud.io/blog/fail2ban-wordpress-cloudflare
[4] https://www.digitalocean.com/community/ ... untu-14-04
[5] https://forum.hestiacp.com/t/has-anyone ... press/3519

[goldene-zeiten]

Vielen Dank Fezzi. Das werde ich implementieren. Aber so ganz abwegig fand ich die Frage trotzdem nicht. Denn die Regeln helfen ja nur, wenn KeyHelp die nicht beim nächsten Update wieder entfernt. Denn es heißt ja, man soll an den Files nichts ändern, weil Keyhelp das dann überschreibt.

[Tobi]

Die Frage ist doch eher wo man die Grenze ziehen will?

Soll KeyHelp auch Typo3 Regeln nativ verwalten?
Warum dann nicht auch joomla!?
Oder vielleicht auch nextcloud?
Owncloud?

Du verstehst worauf ich hinaus möchte?

Wie Fezzi gezeigt hat kann man deinen Wunsch durchaus bereits jetzt mit etwas Eigeninitiative umsetzen.
Oder man nimmt ganz pragmatisch ein Plugin.
Das nimmt man doch sowieso immer als Lösung bei Wordpress?

[Alexander]

Neue Filter werden kommen, wenn sie Dienste betreffen, die auf jedem KeyHelp Server laufen.
Für Anwender-Software (wie Wordpress) gilt dies nicht, die kann individuell von Server zu Server verschieden sein. Soll ja auch Server ohne Wordpress-Instanz geben .

Hier ist Eigeninitiative der Administratoren gefragt, entsprechend Fail2Ban-Regeln zu aktivieren / neu hinzuzufügen, sofern sie für den eigenen Anwendungsbereich in Frage kommen und man sie denn aktivieren möchte. Fail2ban kommt von Haus aus schon mit vielen Filtern daher, darüber hinaus lässt sich im Internet sicher für alle erdenklichen Anwendungen ein Filter finden.

Was das Überschreiben angeht, gilt wie bei allen anderen Konfigurationsdateien auch: Bei jeder Datei, wo der Begriff "keyhelp" Teil des Datei- oder Pfadnamens ist, ist es wahrscheinlich, dass die Datei früher oder später einmal überschrieben wird.
KeyHelps eigene Fail2Ban-Filter heißen "keyhelp-<NAME>.conf" und die KeyHelp-Jail-Konfiguration heißt "keyhelp.local".
=> Das bedeutet also, dass der angesprochen Wordpressfilter ruhig "wordpress.conf" heißen darf und ihr unter "/etc/fail2ban/jail.d/" für neue Regeln besser eine eigene Datei anlegt oder die "local.conf" nutzt.


EDIT: Dateiname korrigiert

[goldene-zeiten]

Alle Argumente sind einleuchtend. Darum habe ich mich jetzt für folgende Lösung entschieden:

1.
WP fail2ban in der kostenlosen Version als PlugIn entschieden und installiert
Somit müssen wir nichts am System verändern und es ist und bleibt eine Einstellung für WordPress.

2.
WordFence als PlugIn zeigt nun weniger Login-Versuche an. Die bösen Jungs scheinen gefiltert zu werden durch Fail2ban bevor WordFence aktiv werden müsste.

Das werde ich nun beobachten. Und wenn es läuft, dann ist der Auftrag erfüllt.

Bei TYPO3 besteht kein Handlungsbedarf. So ein Enterprise-System ist ja von Haus aus geschützt und unangreifbar.

[Jolinar]

Bei TYPO3 besteht kein Handlungsbedarf. So ein Enterprise-System ist ja von Haus aus geschützt und unangreifbar.

Der war gut...

SCNR

[goldene-zeiten]

TYPO3 ist perfekt - sic!

[Henning]

Was das Überschreiben angeht, gilt wie bei allen anderen Konfigurationsdateien auch: Bei jeder Datei, wo der Begriff "keyhelp" Teil des Datei- oder Pfadnamens ist, ist es wahrscheinlich, dass die Datei früher oder später einmal überschrieben wird.
KeyHelps eigene Fail2Ban-Filter heißen "keyhelp-<NAME>.conf" und die KeyHelp-Jail-Konfiguration heißt "keyhelp.conf".
=> Das bedeutet also, dass der angesprochen Wordpressfilter ruhig "wordpress.conf" heißen darf und ihr unter "/etc/fail2ban/jail.d/" für neue Regeln besser eine eigene Datei anlegt oder die "local.conf" nutzt.

Bei mir, Debian 12, heisst die Datei /etc/fail2ban/jail.d/keyhelp.local - falls das wichtig sein sollte.

[Fezzi]

Alle Argumente sind einleuchtend. Darum habe ich mich jetzt für folgende Lösung entschieden:

1.
WP fail2ban in der kostenlosen Version als PlugIn entschieden und installiert
Somit müssen wir nichts am System verändern und es ist und bleibt eine Einstellung für WordPress.

2.
WordFence als PlugIn zeigt nun weniger Login-Versuche an. Die bösen Jungs scheinen gefiltert zu werden durch Fail2ban bevor WordFence aktiv werden müsste.

Das werde ich nun beobachten. Und wenn es läuft, dann ist der Auftrag erfüllt.

Bei TYPO3 besteht kein Handlungsbedarf. So ein Enterprise-System ist ja von Haus aus geschützt und unangreifbar.

Na dann ist ja alles gut... sehe das Problem nicht einen Fail2Ban Filter am Server zu machen... der ist ja update sicher und funkt einwandfrei.

Der mit TYPO3 made my day...

[goldene-zeiten]

Also im Grunde genommen schrieb ich ja ursprünglich, dass ich das gerne auf Basis von fail2ban serverseitig lösen, möchte. Dann aber schrieb Tobi, dass das keinen Sinn macht und es besser wäre ein Plugin für WordPress zu nehmen. Nehmen. Schlussendlich habe ich dieses Plugin auch wieder deinstalliert und mich für die serverseitige Lösung entschieden.

Bei so unsicheren Systemen wie WordPress muss man ja auf jeden Fall immer auf der Hut sein. Wir reden ja nicht von einem Enterprise System, welches das sicherste System ist geht es. Bei TYPO3 ist. Wenn alle TYPO3 einsetzen würden, dann wäre die Welt sicherer und es gebe keine Probleme und keine Heckerangriffe mehr, weil die sinnlos wären.

[Alexander]

Die wenigstens Wordpress-Systeme werden durch hacken des Wordpress-Logins geknackt. Klar, wer hier ein schwaches Passwort wählt, ist selber schuld.
Wordpress ist nicht per se unsicherer als andere Systeme. Im Gegenteil, ich würde jetzt argumentieren, dass durch die enorme Verbreitung von Wordpress es jederzeit einer großen Anzahl von Hack-Versuchen auf mögliche Schwachstellen ausgesetzt ist. Aus diesem Grund sollten alle möglichen Schwachstellen den Entwicklern bekannt und entsprechend behoben worden sein, so dass das Grundsystem recht sicher sein sollte.

Was Wordpress allerdings offen wie ein Scheunentor machen kann sind die Plugins. Jeder Hinz und Kunz kann ein Plugin schreiben und die Leute installieren es in der Regel ohne zu hinterfragen, von wem es stammt.

Fail2Ban und wahrscheinlich auch die o.g. Plugins (die hab ich mir nicht näher angeschaut). Helfen dir gegen Brute-Force Angriffe auf den Login. Aber bei unsicheren Plugins helfen die nicht.

[goldene-zeiten]

Womit wir ja beim Thema Unverwundbarkeit von TYPO3 wären. Die Hürden, eine Extension für TYPO3 zu schreiben, sind auch von der Codequalität höher und geprüft wird der Code zudem. Das meine ich ja mit Enterprise und sicherstes System der Welt. TYPO3 ist halt TYPO3 und nicht WordPress. Drum schaue ich ja auch, so wenige Plugins wie möglich zu verwenden bei WordPress. Ich sehe es exakt so wie du - außer vielleicht die Begeisterung für TYPO3, die bei mir wohl ausgeprägter ist als bei dir

[Blubby]

Die wenigstens Wordpress-Systeme werden durch hacken des Wordpress-Logins geknackt. Klar, wer hier ein schwaches Passwort wählt, ist selber
.....
Fail2Ban und wahrscheinlich auch die o.g. Plugins (die hab ich mir nicht näher angeschaut). Helfen dir gegen Brute-Force Angriffe auf den Login. Aber bei unsicheren Plugins helfen die nicht.

Da hast du Recht, allerdings macht fail2ban schon in der Hinsicht Sinn das automatisierte Bruteforce Angriffe massiv Last verursachen können wenn man nicht nur ein Wordpress auf dem Server hat.