Apache: manchmal Workers am Limit

Debian macht sich hervorragend als Web- und Mailserver. Schau auch in den " Tipps und Tricks"-Bereich.
Benutzeravatar
whisper
Beiträge: 3255
Registriert: 23.09.2002 14:32:21
Lizenz eigener Beiträge: GNU Free Documentation License
Kontaktdaten:

Re: Apache: manchmal Workers am Limit

Beitrag von whisper » 04.06.2024 09:01:13


Benutzeravatar
heisenberg
Beiträge: 3764
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Apache: manchmal Workers am Limit

Beitrag von heisenberg » 04.06.2024 10:26:58

Du kannst die Verbindungen auch limitieren, dass pro IP/Netz nur eine gewisse Anzahl von neuen Anfragen kommen dürfen:

Beispiel für DNS - Limit per IP:

Code: Alles auswählen

# iptables -L DNS_RATE_LIMIT -v -n --line-numbers |grep -vE "^[1-4]"
Chain DNS_RATE_LIMIT (2 references)
num   pkts bytes target     prot opt in     out     source               destination         
5     1501  114K            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 recent: SET name: dnsratelimit side: source mask: 255.255.255.255
6        0     0 LOG        udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 recent: UPDATE seconds: 20 hit_count: 200 name: dnsratelimit side: source mask: 255.255.255.255 LOG flags 0 level 6 prefix "DNS-UDP blocked: "
7        0     0 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 recent: UPDATE seconds: 20 hit_count: 200 name: dnsratelimit side: source mask: 255.255.255.255 reject-with icmp-port-unreachable
8       51  2817            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 recent: SET name: dnsratelimit side: source mask: 255.255.255.255
9        0     0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 recent: UPDATE seconds: 20 hit_count: 200 name: dnsratelimit side: source mask: 255.255.255.255 ctstate NEW LOG flags 0 level 6 prefix "DNS-TCP blocked: "
Die Logstatements nutze dafür, um bei zu häufigen Limitüberschreitungen mit fail2ban temporäre Blocks zu setzen.

Nochmal als gespeicherte Regeln:

Code: Alles auswählen

# iptables -S DNS_RATE_LIMIT
-N DNS_RATE_LIMIT
-A DNS_RATE_LIMIT -p udp -m udp --dport 53 -m recent --set --name dnsratelimit --mask 255.255.255.255 --rsource
-A DNS_RATE_LIMIT -p udp -m udp --dport 53 -m recent --update --seconds 20 --hitcount 200 --name dnsratelimit --mask 255.255.255.255 --rsource -j LOG --log-prefix "DNS-UDP blocked: " --log-level 6
-A DNS_RATE_LIMIT -p udp -m udp --dport 53 -m recent --update --seconds 20 --hitcount 200 --name dnsratelimit --mask 255.255.255.255 --rsource -j REJECT --reject-with icmp-port-unreachable
-A DNS_RATE_LIMIT -p tcp -m tcp --dport 53 -m recent --set --name dnsratelimit --mask 255.255.255.255 --rsource
-A DNS_RATE_LIMIT -p tcp -m tcp --dport 53 -m recent --update --seconds 20 --hitcount 200 --name dnsratelimit --mask 255.255.255.255 --rsource -m conntrack --ctstate NEW -j LOG --log-prefix "DNS-TCP blocked: " --log-level 6
-A DNS_RATE_LIMIT -p tcp -m tcp --dport 53 -m recent --update --seconds 20 --hitcount 200 --name dnsratelimit --mask 255.255.255.255 --rsource -m conntrack --ctstate NEW -j REJECT --reject-with icmp-port-unreachable
-A DNS_RATE_LIMIT -j DNS_RATE_LIMIT_CIDR
Dann nochmal was auf Ebene von Netzblöcken:

Code: Alles auswählen

# iptables -L DNS_RATE_LIMIT_CIDR -v -n
Chain DNS_RATE_LIMIT_CIDR (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 8555  644K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: up to 40/sec burst 80 mode srcip srcmask 24
    9   682 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 2/min burst 5 LOG flags 0 level 4 prefix "DNS_RATE_LIMIT_DROP_CIDR: "
   10   760 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0     

# iptables -t filter -S DNS_RATE_LIMIT_CIDR
-N DNS_RATE_LIMIT_CIDR
-A DNS_RATE_LIMIT_CIDR -m hashlimit --hashlimit-upto 40/sec --hashlimit-burst 80 --hashlimit-mode srcip --hashlimit-name conn_rate_limit --hashlimit-srcmask 24 -j RETURN
-A DNS_RATE_LIMIT_CIDR -m limit --limit 2/min -j LOG --log-prefix "DNS_RATE_LIMIT_DROP_CIDR: "
-A DNS_RATE_LIMIT_CIDR -j DROP
Die Zahlen musst Du natürlich an Deine Bedürfnisse anpassen.

-------

Ansonsten habe ich mich etwas verarscht frustriert gefühlt, wenn ich was von SYN-Attacke lese und bekomme dann UDP-Grafen präsentiert. :facepalm: 8O :D

Ich möchte es nochmal wiederholen:
Ansonsten finde ich die schiere Menge an Graphen absolut verwirrend. Da würde ich auch den Wald vor lauter Bäumen nicht mehr sehen und mir eher mal ein Dashboard mit vielleicht den 10 wichtigsten zusammenstellen, z. B.:

disk.io
disk.ops
apache.workers
apache.requests
system.cpu
cpufreq.cpufreq
ip.tcpsock
postgres.connection_connection_state_count

und noch 1-2 Graphen für RAM/Swap.

Benutzeravatar
whisper
Beiträge: 3255
Registriert: 23.09.2002 14:32:21
Lizenz eigener Beiträge: GNU Free Documentation License
Kontaktdaten:

Re: Apache: manchmal Workers am Limit

Beitrag von whisper » 04.06.2024 11:06:51

ja udp war mal als kontrolle mit drin, und jetzt nur nicht wieder rausgenommen.
Das dashboard hat jetzt auch nicht den richtigen zeitrahmen.
Deine Vorschläge für graphen habe ich mir angesehen, da ist aber nichts was bei mir zutrifft.
Aber sooo viele grafiken sind es doch gar nicht....
Aber danke für deine iptables zeilen, das kann einen schon erschlagen.
Was ich nicht dokumentiert habe, ist wie ich überhaupt auf port 8009 kam.
Hole ich noch nach.

Benutzeravatar
heisenberg
Beiträge: 3764
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Apache: manchmal Workers am Limit

Beitrag von heisenberg » 04.06.2024 11:12:13

Ich meine, wenn ich den Verdacht auf einen Angriff mittels SYN-Paketen habe, dann wären für mich die Anzahl der aktiven TCP-Verbindungen und der TCP-Pakete die ersten zwei Werte, die ich mir ansehen würde. Da habe ich aber keine Graphen zu gesehen. (Anzahl Syn-Pakete war allerdings da. Das war auf jeden Fall hilfreich.).
Aber danke für deine iptables zeilen, das kann einen schon erschlagen.
Ja. Darf man sich ein paar Minuten anschauen. :-)

Im Zweifelsfall den Digitalen Zufalls-/Erklärbär befragen. (ChatGPT. Ist gerade überlastet.)

P. S.: Sorry für die vielleicht etwas unfreundliche Anmerkung oben. Ich bin etwas neben der Kappe gerade.

Benutzeravatar
whisper
Beiträge: 3255
Registriert: 23.09.2002 14:32:21
Lizenz eigener Beiträge: GNU Free Documentation License
Kontaktdaten:

Re: Apache: manchmal Workers am Limit

Beitrag von whisper » 04.06.2024 12:27:40

Na, in einem Screenshot sollte TCP cookies, Connextions drops usw. gewesen sein
kam mir aber nicht so enorm vor, deshalb nicht mehr gezeigt.
Ich habe ein einfaches Script auf der Grundlage von Debianss geschrieben, bzw. zusammen mit meinem Kumpel GPT 4o

4863

Das zeigt die momentanen und Max Werte.

Im Script ist die Rede von einem anderen iptables, das ist aber nicht das, welches jetzt aktiv ist.
Ich lasse das noch eine weile laufen und habe auch sonst noch ein Auge auf die Workers.
Wie schon beschrieben, der Engpass betraf nur WEB.
Der Server ansich ist nahezu unberührt davon.
Klar, nextcloud ist auch betroffen, weil halt auch WEB

Benutzeravatar
whisper
Beiträge: 3255
Registriert: 23.09.2002 14:32:21
Lizenz eigener Beiträge: GNU Free Documentation License
Kontaktdaten:

Re: Apache: manchmal Workers am Limit

Beitrag von whisper » 18.06.2024 15:22:39

Kurze Notiz
Habe wohl den Übeltäter gefunden.
Ein Bot Netz scheint zu versuchen eine Schwachstelle zu finden.

Code: Alles auswählen

Status for the jail: apache-label
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	12782
|  `- File list:	/var/log/apache2/other_vhosts_access.log
`- Actions
   |- Currently banned:	8516
   |- Total banned:	11761
Ist jetzt ca. 75 Minuten aktiv, mal sehen ob sich das beruhigt oder konstant bleibt.
Die Seite hat sich bedankt, kein Stress mehr.
Und Fine Tuning des Jails fehlt auch noch.

Benutzeravatar
heisenberg
Beiträge: 3764
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Apache: manchmal Workers am Limit

Beitrag von heisenberg » 18.06.2024 15:36:54

Ich hatte vor kurzem auch einen nervigen Bot, den ich per iptables gedrosselt habe. Siehe hier:

https://serversupportforum.de/threads/b ... les.61075/

Benutzeravatar
whisper
Beiträge: 3255
Registriert: 23.09.2002 14:32:21
Lizenz eigener Beiträge: GNU Free Documentation License
Kontaktdaten:

Re: Apache: manchmal Workers am Limit

Beitrag von whisper » 18.06.2024 18:48:30

Den habe ich auch.
Ist auch son KI Startup, wenn ich mich richtig erinnere.
Drosseln, statt blocken, gute Idee!

Benutzeravatar
heisenberg
Beiträge: 3764
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Apache: manchmal Workers am Limit

Beitrag von heisenberg » 18.06.2024 20:22:35

Vielleicht ist das die geschicktere Variante bei so unverfrorenen Bot-Betreibern wie Anthropic:

.htaccess

Code: Alles auswählen

RewriteCond %{HTTP_USER_AGENT} ClaudeBot
RewriteRule .* https://www.anthropic.com/[R=301]
Erklärung: Das Obige leitet jede Anfrage mit User-Agent ClaudeBot auf die Webseite vom Betreiber um. Das ist also eine DOS-Attacke auf eine Firma mit Ihren eigenen Requests, wenn diese Umleitung von vielen Zielen gemacht würden.

Benutzeravatar
whisper
Beiträge: 3255
Registriert: 23.09.2002 14:32:21
Lizenz eigener Beiträge: GNU Free Documentation License
Kontaktdaten:

Re: Apache: manchmal Workers am Limit

Beitrag von whisper » 26.06.2024 11:03:43

aktuelle Situation:
4902

Benutzeravatar
whisper
Beiträge: 3255
Registriert: 23.09.2002 14:32:21
Lizenz eigener Beiträge: GNU Free Documentation License
Kontaktdaten:

Re: Apache: manchmal Workers am Limit

Beitrag von whisper » 13.07.2024 11:37:20

Jetzt ist eigentlich alles in Butter.
4924
und die jails haben sich eingependelt
4925
Froi

Antworten