Serverlast, Bots/Crawlers und Fail2ban/Crowdsec/(x)

Allgemein
1

An diversen Stellen hab ich in den letzten Wochen/Monaten den Wunsch gelesen, sich über die Abwehr von übereifrigen (AI-)Bots auszutauschen, die die Server (u.a. Discovery) auch gerne mal lahmlegen. Unter anderem in der Findex-Mailinglist (Thema „Verbindungsabbrüche und stark verzögerte Antwortzeiten“) oder bei Mastodon von @acka47.

Nun schreib ich hier, allerdings ist es bei mir nur ein neben-neben-neben-Thema und nur wegen der aktuellen Personalsituation bei uns, d.h. ich bin da inhaltlich nicht gut aufgestellt. Im Wesentlichen haben wir Fail2ban für Webseite und Discovery im Einsatz, wo ich teils nach How to Avoid High CPU Load and Block Hackers and Bad Bots Effectively (2024-02-13) nachzubessern versucht habe und zusätzlich noch ein Perma-Jail eingerichtet habe, wo ich inzwischen riesige Netzwerkblöcke reinhaue, sobald die Seite abraucht.

Das wesentliche Problem scheint mir, dass robots.txt-ignorierende Bots mit x IPs, ohne nutzbaren User agent kommen und damit einzeln von Fail2ban-Regeln schwer zu fassen sind in der Summe aber alles lahmlegen. Daher hab ich schon mal überlegt Crowdsec zu nutzen, aber auch wenn Linux-Server in 15 Minuten mit CrowdSec absichern stimmen würde, ist mir das im Moment zu heiß als neben-neben… Statt dessen nutz ich den Crowdsec IP-lookup und haue ggf. die Ranges in das Perma-Jail von Fail2ban. Und hoffe, dass bald eine Stelle nachbesetzt wird bei uns :wink:
Das ist natürlich sehr unschön.

Langer Rede, kurzer Sinn: gibt es hier Leute, die z.B. ihr Discovery gut in den abgesichert bekommen haben mit z.B. Fail2ban und robots.txt, die gute Tipps, ~Links/Literatur oder ggf. gar teilbare Scripts/Configs haben?

(Es gibt schon AI-Crawler in robots.txt blockieren?, aber mit einem etwas stärkeren Fokus auf robots.txt; falls zu redundant, gerne dieses Thema ignorieren).

3 Likes
2

Moin Tobias, schön Dich hier zu lesen! Und auch noch mit einem Thema, das mich schon seit Monaten beschäftigt. Irgendwie habe ich es bisher nur nicht geschafft, das Thema hier anzusprechen. Jetzt antworte ich auf deine Steilvorlage spontan :slight_smile:

Wir setzen Fail2Ban seit ca. einem Jahr ein. Anfänglich noch eher als prophylaktische Maßnahme gedacht und um die Serverlast zu verringern. Seit einigen Monaten aber auch, um Ausfälle bspw. von nwbib.de zu verhindern, die durch massenhafte Anfragen von Bots ausgelöst wurden. In diesem konkreten Fall waren es Anfragen mit bad queries, die unsere Backendserver in die Knie gezwungen haben und zu Timeout-Fehlern geführt haben.

Ich habe noch keine systematische Analyse der Botzugriffe über einen längeren Zeitraum gemacht, aber mein Eindruck ist, dass sie immer mehr werden. auch bedingt durch die Zunahme von AI-Bots. Als kleines Indiz hier ein Screenshot der Auswertung der Webserverlogs, die wir mit mit goaccess erstellen. Der Anteil der Botzugriffe auf nwbib.de im Oktober 2024 liegt bei über 90% aller Zugriffe:

grafik
grafik869×866 89.6 KB

Zur interaktiven HTML-Seite der Auswertung, da kann man die Zeile mit den Crawlers durch Klick aufklappen und sehen, welche Bots es sind.

Was das Blocken von Subnetzen angeht, hätte ich einen Tipp und zwar diese zusätzlichen Skripte: GitHub - ruppel/fail2ban-recidive-subnet: Find an ban recidive subnets using fail2ban Damit lassen sich automatisiert Subnetze von Bots wie Bytespider blocken. Seit wir die Skripte nutzen, ist die Anzahl der durch die Jail apache-badbots geblockten IPs um etwa ein Zehntel geschrunpft, von ca. 25 Tsd. auf knapp 3 Tsd.

Status for the jail: apache-badbots
[...]
   |- Currently banned:	2953
   |- Total banned:	25501

Kannst Du diese These belegen? Ich habe das so bei uns noch nicht beobachtet.

Bei unseren Diensten sind es Bots, die sich zwar nicht an die robots.txt halten wie der Bytespider, die aber über den user agent identifizierbar sind und somit auch von Fail2Ban automatisiert geblockt werden können. In letzter Zeit sind bei uns auch meta-externalagent und facebookexternalhit durch bad queries und/oder massenhafte Anfragen aufgefallen, weshalb wir sie auf die Badbots-Liste gesetzt haben. Den facebookexternalhit mussten wir aber wieder zulassen, weil einige Dienste von Apple wie iMessage den user agent facebookexternalhit/1.1 Facebot Twitterbot/1.0 verwenden, d.h. wer über iMessage einen Link auf eine unsere Dienste geteilt hat, wurde versehentlich geblockt!

Soviel erstmal von mir. Ich freue mich über weiteren Austausch!

1 Like
3

Moin Tobias, schön Dich hier zu lesen!

Dito :slight_smile:

Erst mal vielen Dank für die Antwort. Das goaccess und vor allem das fail2ban-recidive-subnet klingen sehr interessant.

Das wesentliche Problem scheint mir, dass robots.txt-ignorierende Bots mit x IPs, ohne nutzbaren User agent kommen und damit einzeln von Fail2ban-Regeln schwer zu fassen sind in der Summe aber alles lahmlegen.

Kannst Du diese These belegen? Ich habe das so bei uns noch nicht beobachtet.

Bei mir ist das alles viel banaler.

  1. Ich awk-greppe nur ein wenig durch die Logs und gucke, wenn der Server als unerreichbar gemeldet wird, welche IPs da gehäuft auftauchen
  2. Gucke dann, ob schon so erkennbar bestimmte Oktette sich häufen bei den IPs
  3. Gucke dann ggf. bei Crowdsec IP-lookup um eine Einschätzung zur IP und das korrekte Subnet zu bekommen
  4. Setze dann ggf. die einzelne IP oder das Subnetz á la fail2ban-client set ip-blacklist banip 140.206.236.0/23 in die erstelle Fail2Ban-Blacklist
logcheck.sh 
#!/bin/bash
#
# Apache-Log nach IPs filtern
# * tub.find-Logs werden wöchentlich rotiert
# * Es wird default nach heutigem Datum gefiltert.
# * Es kann auch nur nach Oktetten einer IP gesucht werden.
#       Also z.B. "3" für x.x.x.0
#       Oder z.B. "2" für x.x.0.0
#
# date=20/Aug/2024
# time=16:3
#

# Standardwerte für die Parameter
date=$(date '+%d/%b/%Y')
octets="4"
time=""

# Funktion zur Anzeige der Hilfe
usage() {
  echo "Usage: $0 [-o|--octets value1] [-t|--time value2] [-d|--date value3]"
  exit 1
}

# Optionen parsen
while [[ $# -gt 0 ]]; do
  case $1 in
    -o*|--octets)
      if [[ $1 == --octets ]]; then
        octets="$2"
        shift
      else
        octets="${1#-o}"
      fi
      shift
      ;;
    -t*|--time)
      if [[ $1 == --time ]]; then
        time="$2"
        shift
      else
        time="${1#-t}"
      fi
      shift
      ;;
    -d*|--date)
      if [[ $1 == --date ]]; then
        date="$2"
        shift
      else
        date="${1#-d}"
      fi
      shift
      ;;
    *)
      echo "Invalid option: $1" >&2
      usage
      ;;
  esac
done

LOG=/srv/www/log/tubfind_ssl_acc.log


# Keine TUB und HCU-IPs
IP_IGNORE="134\.28\.|195\.37\.187\.176|194\.95\.79\.15"

echo $date:
#cat $LOG | egrep ${DATUM}:${ZEIT} | egrep -v "($IP_IGNORE)" | awk '{print $1}' | sort | uniq -c| sort -n
cat $LOG | egrep ${date}:${time} | egrep -v "($IP_IGNORE)" | awk -v octetes=$octets '{
    split($1, a, ".")
    octet = a[1]
    for (i = 2; i <= octetes; i++) {
        octet = octet "." a[i]
    }
    # print octet "\t" $9 "\t" $13,$14,$15,$16,$17,$18,$19,$20,$21,$22
    print octet "\t" $13,$14,$15,$16,$17,$18,$19,$20,$21,$22
}' | sort | uniq -c| sort -n

Leider ist das alles nicht sauber dokumentiert bei uns, so dass man das als Vorlage leicht nachnutzen kann. Aber es ist halt auch so noch gar nicht gut. Ich werde jetzt erst mal das fail2ban-recidive-subnet ergänzen.

1 Like
4

Wenn ich den Thread in der Findex-Mailingliste richtig gelesen habe, ist das Discoverysystem nicht überlastet, weil es zu viele Anfragen erhält. Es wird vom Findex ausgebremst, weil der Findex ein Rate Limiting anwendet. D.h für mich, dass im Discovery auch ein Rate Limiting stattfinden muss. Man könnte das z. B. mit Fail2Ban so in der Art wie diese Dummy-Jail machen:

[throttler]
enabled = true
logpath = /var/log/apache2/access_log
filter = findex-queries
findtime = 1m
maxretry = 175
bantime = 5s

Der filter sollte Anfragen erkennen, die eine Query im Findex auslösen. Und maxretry müsste noch deutlich kleiner sein, weil sonst bereits eine einzelne IP das Limit erreichen könnte.
Wahrscheinlich sollte man sich auch die Queries genauer angucken. Wenn das unsinnige oder bad queries sind, könnte man die Anfragen direkt im Webserver abfangen (400 Bad request) oder die anfragende IP via Fail2Ban (kurzzeitig) sperren.

1 Like
5

Das fail2ban-recidive-subnet hat schon mal einen ganzen Haufen ergänzt. Das ist doch fein :slight_smile:

Beim Discovery bin ich bis jetzt davon ausgegangen, dass es bisher einfach nach Bot-Anstürmen nicht mehr reagierte. Ich steck jetzt auch nicht so tief in dem Findex-Thread, aber soweit ich es verstehe, sollten die Limits von echten Menschen eher nicht erreichbar sein. Insofern greifen vielleicht dann auch die regulären Jails schon ausreichend. :thinking:

6

Super! Was ich sehr praktisch finde sind die Mails mit whois-Abfrage, die man sich von Fail2Ban schicken lassen kann. Jetzt kriegen wir morgens so was

Hi,

The IP 173.252.82.0 has just been banned by Fail2Ban after
1 attempts against recidive-subnet.

Here is more information about 173.252.82.0 :

[…]
NetRange: 173.252.64.0 - 173.252.127.255
CIDR: 173.252.64.0/18
NetName: FACEBOOK-INC
NetHandle: NET-173-252-64-0-1
Parent: NET173 (NET-173-0-0-0-0)
NetType: Direct Allocation
OriginAS: AS32934
Organization: Facebook, Inc. (THEFA-3)
RegDate: 2011-02-28
Updated: 2021-12-14
Ref: https://rdap.arin.net/registry/ip/173.252.64.0

[…]

7

Uh, noch mehr Mails :face_with_peeking_eye: Aber ich probier es mal, ob es einen Info-Mehrwert hat. :slight_smile:

Hast du denn auf Mails hin noch von Hand Dinge angepasst? Oder eigentlich doch eher set-and-forget?

8

Ich würde sagen eher set-and-forget. in der apache-badbots.conf habe ich die failregex angepasst:

#failregex = ^<HOST> -.*"(GET|POST|HEAD).*HTTP.*"(?:%(badbots)s|%(badbotscustom)s)"$
# match any part of the user agent, eg. .*SemrushBot.*
failregex = ^<HOST> .*"(GET|POST|HEAD).*HTTP.*(?:%(badbots)s|%(badbotscustom)s).*"$

Als erstes hatten wir Bytespider und SemrushBot ergänzt, weil sie laut Stichproben ein Drittel des gesamten Traffics ausgemacht haben.
Bei einem Discoverysystem würde ich wahrscheinlich fast alle gängigen Bots aussperren, weil ich der Meinung bin, dass sie keinen Mehrwert für die Nutzer:innen bringen. Für unsere Dienste gibt es noch ein offenes Ticket „Welche weiteren Bots wollen wir aussperren?“ :wink:

Ich hätte gern noch Email-Alerts, wenn z.B. ein Limit an Error Status Codes in den Logs auftauchen. Leider ist das Feature noch nicht in GoAccess implementiert.

Außerdem würde ich bei Gelegenheit mal ein paar unsinnige Requests blocken wollen, die massenhaft gemacht werden, z. B. /resources/stars/null bei lobid-resources

9

Ich hab mir das so aus Seiten (u.a. der Plesk-Seite aus dem Eingangspost) zusammengeschnipselt. Ich glaub, die ist jetzt ganz gut. Vielleicht auch etwas too much, aber ehrlich gesagt lieber das als eine am Boden liegende Seite.

apache-badbots.conf 
# Fail2Ban configuration file
#
# Regexp to catch known spambots and software alike. Please verify
# that it is your intent to block IPs which were driven by
# above mentioned bots.
#
# https://www.plesk.com/blog/product-technology/avoid-high-cpu-load-block-hackers-bad-bots-effectively/

[Definition]
 
badbotscustom = thesis-research-bot
badbots = 80legs|360Spider|anthropic-ai|CCBot|claudebot|ClaudeBot|Claude-Web|ChatGPT|GPTBot|HTTrack|acunetix|adscanner|ag_dm_spider|aiHitBot|Ahrefs|AhrefsBot|Alibaba|alibababot|ALittle|Amazon|amazonbot|AmazonBot|applebot|Applebot|BacklinkCrawler|baidu|Baiduspider|Barkrowler|babbar|BLEXBot|BUbiNG|Buck|Bytespider|Bytedance|chimebot|Cliqzbot|clshttp|Cohere|cohere-ai|CommonCrawl|coccoc|coccocbot|coccocbot-image|DataForSeoBot/1\.0|DiffBot|DigExt|domaincrawler|DomainCrawler|DomainRe-AnimatorBot|domaintools|DotBot|Exabot|extract|Ezooms|GarlikCrawler|ChatGPT-User|ggpht|Google Extended|Google-Extended|Gosign-Security-Crawler|grab|gumgum-bot|FacebookBot|facebookexternalhit|fidget-spinner-bot|fr-crawler|harvest|HaosouSpider|JobboerseBot|jobs.de-Robot|ICCrawler|Imagesift|ImagesiftBot|IndeedBot|Keybot|Kraken|LamarkBot|LieBaoFast|Linguee|LinkpadBot|LinkStats|Lipperhey-Kaus-Australis|ltx71|magpie-crawler|majestic12|Mb2345Browser|meanpathbot|MegaIndex|MegaIndex\.ru|MetaJobBot|MJ12|MJ12Bot|mj12bot|mindUpBot|miner|MQQBrowser|netEstate|nikto|oBot|Omgili|Omgilibot|OpenHoseBot|openlinkprofiler|opensiteexplorer|Paqlebot|paqlebot|PerplexityBot|petalbot|petalsearch|petalsearchBot|PhantomJS|Plista|plukkie|postmanruntime|python-requests|Qwantify|SabsimBot|SafeDNSBot|scrapy|ScreamingFrogSEOSpider|SearchmetricsBot|seek|SeekportBot|Semrush|SemrushBot|SemrushBot-BA|SemrushBot-SA|serpstatbot|SISTRIX|Sistrix|sentibot|seocompany|SEOdiver|SEOkicks|SEOkicks-Robot|seoscanners|seznam|SeznamBot|sg-Orbiter|Siteliner|Snap|sogou|spbot|spot|Squigglebot|SquigglebotBot|ssearch_bot|SurveyBot|R6_CommentReader|RestSharp|rogerbot|TalkTalk|ThumbSniper|trendictionbot|trendkite-akashic-crawler|turnitinbot|TwengaBot|UCBrowser|um-IC|UnisterBot|Uptimebot|VelenPublicWebCrawler|VoidEYE|WBSearchBot|webcrawl|webprosbot|winhttp|wotbox|yandex|YandexBot|YottaShopping_Bot|YouBot|ZoominfoBot|Atomic_Email_Hunter/4\.0|atSpider/1\.0|autoemailspider|bwh3_user_agent|China Local Browse 2\.6|ContactBot/0\.2|ContentSmartz|DataCha0s/2\.0|DBrowse 1\.4b|DBrowse 1\.4d|Demo Bot DOT 16b|Demo Bot Z 16b|DSurf15a 01|DSurf15a 71|DSurf15a 81|DSurf15a VA|EBrowse 1\.4b|Educate Search VxB|EmailCollector|EmailSiphon|EmailSpider|EmailWolf 1\.00|ESurf15a 15|ExtractorPro|Franklin Locator 1\.8|FSurf15a 01|Full Web Bot 0416B|Full Web Bot 0516B|Full Web Bot 2816B|Guestbook Auto Submitter|Industry Program 1\.0\.x|ISC Systems iRc Search 2\.1|IUPUI Research Bot v 1\.9a|LARBIN-EXPERIMENTAL \(efp@gmx\.net\)|LetsCrawl\.com/1\.0 \+http\://letscrawl\.com/|Lincoln State Web Browser|LMQueueBot/0\.2|LWP\:\:Simple/5\.803|Mac Finder 1\.0\.xx|MFC Foundation Class Library 4\.0|Microsoft URL Control - 6\.00\.8xxx|Missauga Locate 1\.0\.0|Missigua Locator 1\.9|Missouri College Browse|Mizzu Labs 2\.2|Mo College 1\.9|MVAClient|(?:Mozilla/\d+\.\d+ )?Jorgee|Mozilla/2\.0 \(compatible; NEWT ActiveX; Win32\)|Mozilla/3\.0 \(compatible; Indy Library\)|Mozilla/3\.0 \(compatible; scan4mail \(advanced version\) http\://www\.peterspages\.net/?scan4mail\)|Mozilla/4\.0 \(compatible; Advanced Email Extractor v2\.xx\)|Mozilla/4\.0 \(compatible; Iplexx Spider/1\.0 http\://www\.iplexx\.at\)|Mozilla/4\.0 \(compatible; MSIE 5\.0; Windows NT; DigExt; DTS Agent|Mozilla/4\.0 efp@gmx\.net|Mozilla/5\.0 \(Version\: xxxx Type\:xx\)|NameOfAgent \(CMS Spider\)|NASA Search 1\.0|Nsauditor/1\.x|PBrowse 1\.4b|PEval 1\.4b|Poirot|Port Huron Labs|Production Bot 0116B|Production Bot 2016B|Production Bot DOT 3016B|Program Shareware 1\.0\.2|PSurf15a 11|PSurf15a 51|PSurf15a VA|psycheclone|RSurf15a 41|RSurf15a 51|RSurf15a 81|searchbot admin@google\.com|ShablastBot 1\.0|snap\.com beta crawler v0|Snapbot/1\.0|Snapbot/1\.0 \(Snap Shots&#44; \+http\://www\.snap\.com\)|Sogou|sogou develop spider|sogou music spider|Sogou Orion spider/3\.0\(\+http\://www\.sogou\.com/docs/help/webmasters\.htm#07\)|sogou spider|Sogou web spider/3\.0\(\+http\://www\.sogou\.com/docs/help/webmasters\.htm#07\)|sohu agent|SSurf15a 11 |TSurf15a 11|TrackBack/1\.02|Under the Rainbow 2\.2|User-Agent\: Mozilla/4\.0 \(compatible; MSIE 6\.0; Windows NT 5\.1\)|VadixBot|WebVulnCrawl\.unknown/1\.0 libwww-perl/5\.803|WebEMailExtrac|Wells Search II|WEP Search 00

#Standard: failregex = ^<HOST> -.*"(GET|POST|HEAD).*HTTP.*"(?:%(badbots)s|%(badbotscustom)s)"$

# https://talk.plesk.com/threads/default-plesk-apache-badbot-fail2ban-doesnt-work.373816/post-945978
failregex = ^<HOST> -[^"]*"(?:GET|POST|HEAD) \/.* HTTP\/\d(?:\.\d+)" \d+ \d+ "[^"]*" "[^"]*(?:%(badbots)s|%(badbotscustom)s)[^"]*"$

ignoreregex =
10

Diese apache-badbots.conf enthält schon sehr viele Bots. Auf jeden Fall mehr als die Standard-conf von 2013 (!), die mit der Paket-Installation mitkommt.

Eine recht aktuelle und umfangreiche Liste von bad bots findet man hier: apache-ultimate-bad-bot-blocker/_generator_lists/bad-user-agents.list at master · mitchellkrogza/apache-ultimate-bad-bot-blocker · GitHub

11

Ach, und wie ich oben schrieb

Eure conf enthält auch den facebookexternalhit, d.h. iMessage-Nutzer:innen werden für die konfigurierte bantime gesperrt.

1 Like
12

Danke! Ich hab jetzt anscheinend ohnehin ein hartes Overblocking mit dem recidive-subnet. Ich muss da wohl nochmal alles unbannen und dann tatsächlich mal auf die Mails achten.

13

Ich krebse ganz langsam dahin, daher haben Jails auch immer noch unsinnige Werte. Aber wenn’s besser wird, dann landet es hier Universitätsbibliothek / Digitale Dienste / Utilities / Monitoring / fail2ban · GitLab - falls es jmd. das Ende der Geschichte interessiert. :wink:

Edit: So in einem Zwischenschritt sind mir übrigens wahnsinnig viele Mastodon-Zugriffe aufgefallen. Vielleicht sind wir manchmal Opfer von so ner Stampede :slight_smile:

1 Like
14

Das Thema scheint bei den Discovery-Systemen noch relevant zu sein, siehe https://lists.gbv.de/private/findex/2024-December/000591.html (zugriffsgeschützt)

Schade, dass sich hier noch keine weiteren Kolleg:innen dazugeschaltet haben. Ich kann aber gut verstehen, wenn man nicht alles öffentlich bereden will. @vform und ich haben uns auch per Direktnachricht hier im Forum ausgetauscht. Oder wir könnten mal einen Videocall machen. Ich bin jedenfalls an weiterem Austausch interessiert.

1 Like
15

Ja, ich wäre da auch weiter interessiert. Das Problem an Fail2ban ist, dass es eben IP-basiert ist. Die recidive-subnet-Lösung ist schon ganz nett für mehr, aber ganz so einfach (/24) sind die IP-Ranges wohl oft nicht.

Gerade eben um 17:3x eiern 919 unique IPs auf unserer Homepage rum (massen mit (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36). 10 Minuten später schon „nur“ noch 538, aber… Gecheckt mit [search-ip_count_filtered.sh](https://collaborating.tuhh.de/tub/dd/utilities/monitoring/fail2ban/-/blob/main/src/root/www-logchecks/search-ip_count_filtered.sh) -o4 -t17:3 | wc. Wer weiß, vielleicht gibt’s auch teils gute Gründe (z.B. die bereits genannte Mastodon-Verlinkung als Ursache), aber echt schwer da eine Überlast einzufangen (wenn man keine Ahnung hat, wie ich).

16

Aber hattet ihr denn um 17:3x eine übermäßige Last auf dem Server? Mit dem Skript zählst Du doch nur die uniquen IPs, oder?

Um die Anzahl der Requests pro Minute um 0 Uhr zu ermitteln, mache ich so etwas:

grep "01/Dec/2024:00" /var/log/apache2/access_log | cut -d[ -f2 | cut -d] -f1 | awk -F: '{print $2":"$3}' | sort -nk1 -nk2 | uniq -c
     33 00:07
     48 00:08
     36 00:09
     65 00:10
    102 00:11
    120 00:12
    218 00:13
    115 00:14
     75 00:15
     68 00:16
    115 00:17
    113 00:18
     72 00:19
     85 00:20
     87 00:21
    143 00:22
     94 00:23
     86 00:24
     68 00:25
     71 00:26
     54 00:27
     39 00:28
     39 00:29
     37 00:30
     49 00:31
     50 00:32
     62 00:33
    583 00:34
    116 00:35
     95 00:36
     92 00:37
     60 00:38
     39 00:39
     57 00:40
     57 00:41
    151 00:42
    139 00:43
     99 00:44
     84 00:45
    113 00:46
    141 00:47
    175 00:48
    135 00:49
    104 00:50
    642 00:51
    174 00:52
     98 00:53
     78 00:54
    110 00:55
    143 00:56
    143 00:57
     53 00:58
    319 00:59

Und pro Sekunde um 00:34:

sudo grep "01/Dec/2024:00:34" /var/log/apache2/access_log | cut -d[ -f2 | cut -d] -f1 | awk -F: '{print $3":"$4}' | sort -nk1 -nk2 | uniq -c
      1 34:00 +0100
      1 34:01 +0100
      2 34:03 +0100
      1 34:05 +0100
      2 34:06 +0100
      3 34:09 +0100
      1 34:10 +0100
      2 34:11 +0100
      1 34:15 +0100
      2 34:17 +0100
     35 34:18 +0100
     64 34:19 +0100
     78 34:20 +0100
     96 34:21 +0100
    127 34:22 +0100
     91 34:23 +0100
     20 34:24 +0100
      2 34:25 +0100
      1 34:26 +0100
      1 34:30 +0100
      2 34:31 +0100
      1 34:33 +0100
      1 34:34 +0100
      2 34:38 +0100
      2 34:39 +0100
      2 34:41 +0100
      1 34:43 +0100
      2 34:45 +0100
      2 34:46 +0100
      2 34:47 +0100
      2 34:48 +0100
      5 34:49 +0100
      3 34:51 +0100
      1 34:52 +0100
     16 34:53 +0100
      3 34:54 +0100
      3 34:56 +0100
      2 34:58 +0100

In diesem Beispiel halten sich die Anzahl der Requests ja in Grenzen und machen keine Probleme.
Um einzelne IPs auszubremsen haben wir jails wie den oben erwähnten throttler, wo die max. Anzahl der Requests (maxretry) pro Zeitraum (findtime) festgelegt ist. Eine andere Möglichkeit für Rate Limits im Apache ist das Modul mod_evasive.

1 Like
17

Update, mitlerweile sind es nur noch einige Hundert einzelne IPs, die geblockt werden müssen.

Status for the jail: apache-badbots
[...]
   |- Currently banned:	472
   |- Total banned:	29804

und Subnetze:

Status for the jail: recidive-subnet
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	115
|  `- File list:	/var/log/fail2ban-subnet.log
`- Actions
   |- Currently banned:	99
   |- Total banned:	99
   `- Banned IP list:	47.128.49.0 47.128.42.0 47.128.122.0 47.128.57.0 47.128.44.0 47.128.113.0 47.128.120.0 47.128.35.0 47.128.99.0 47.128.115.0 47.128.51.0 47.128.52.0 47.128.97.0 47.128.60.0 47.128.119.0 47.128.33.0 47.128.125.0 47.128.116.0 47.128.50.0 47.128.37.0 47.128.45.0 47.128.30.0 47.128.126.0 47.128.17.0 47.128.24.0 47.128.38.0 47.128.110.0 47.128.32.0 47.128.47.0 47.128.28.0 47.128.121.0 47.128.29.0 47.128.96.0 47.128.20.0 47.128.123.0 47.128.46.0 47.128.63.0 47.128.22.0 47.128.41.0 47.128.124.0 47.128.19.0 47.128.21.0 47.128.31.0 47.128.117.0 47.128.111.0 47.128.55.0 47.128.48.0 47.128.39.0 47.128.62.0 47.128.58.0 47.128.59.0 47.128.40.0 47.128.98.0 47.128.16.0 47.128.118.0 47.128.36.0 47.128.53.0 47.128.23.0 47.128.26.0 47.128.127.0 47.128.25.0 47.128.34.0 47.128.112.0 47.128.109.0 47.128.43.0 47.128.18.0 47.128.114.0 47.128.54.0 47.128.27.0 47.128.56.0 47.128.61.0 111.225.148.0 111.225.149.0 173.252.127.0 110.249.202.0 185.191.171.0 110.249.201.0 85.208.98.0 173.252.83.0 173.252.107.0 173.252.87.0 173.252.69.0 66.220.149.0 173.252.70.0 193.36.225.0 136.144.33.0 69.171.249.0 69.171.230.0 194.5.82.0 172.70.188.0 172.70.189.0 173.252.82.0 108.162.227.0 57.141.5.0 85.208.96.0 63.135.161.0 173.239.211.0 108.165.243.0 57.141.0.0

Das Blocken von Subnetzen lohnt sich IMO. Es ist übersichtlicher, man kann Mailbenachrichtigung nutzen und Fail2Ban ist performanter bei Restarts.

1 Like
18

Request per IP (oder Oktett) + User agent guck ich. Meist erst mal auf 10-Minutenblock. Ja, die Last war tatsächlich auch hoch. In diesem Falle nicht so, dass es unresponsive wurde, aber das kommt auch öfter vor (Website & Discovery). Die einzelnen IPs hatten dabei gar nicht sonderlich viele Requests, d.h. da ließe sich gar nicht viel throtteln, aber anscheinend war es die Menge. Evtl. ist auch php-fpm zusätzlich nicht optimal konfiguriert.

Ja, ich wollte auch gar nicht sagen, dass es schlecht ist. Gerade beim Discovery räumt es ganz gut ab und scheint zu helfen. Gestern waren es um 18h 17 Subnetze beim Discovery - ein Alltime-Hoch (sonst mal 1-2 alle paar Tage).

Trotzdem scheinen mir öfter auch mal nicht /24er-Subnetze sperrwürdig. Und da hätte Crowdsec wohl die gute Datenbasis. Daher überlege ich, ob ich nicht doch einfach Crowdsec mal zur Installation vorschlage bei uns. Es klingt für mich als Ergänzung zu Fail2ban ganz gut.
(Ich hab mich bis jetzt nur nicht „einfach“ getraut, weil ich ja mehr das Kind bin, dass Nachts immer im Keller schlecht um an Sachen zu basteln, die es eigentlich nichts angehen :))