Apache: manchmal Workers am Limit

[whisper]

Hier mein Zwischenstand:
https://daucity.de/de/tools/SYN-Attack

[heisenberg]

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.

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.

[whisper]

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.

[heisenberg]

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.

[whisper]

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 ss geschrieben, bzw. zusammen mit meinem Kumpel GPT 4o



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

[whisper]

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.

[heisenberg]

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

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

[whisper]

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

[heisenberg]

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.

[whisper]

aktuelle Situation:

[whisper]

Jetzt ist eigentlich alles in Butter.

und die jails haben sich eingependelt

Froi

[whisper]

Heute Morgen gerade gesehen.
In netdata gibt es jetzt auch fail2ban Statistiken
und wenn ich richtig gucke seit Mitte Juli. (17.7.)

Also wenige Tage nach dem Screenshot hier drüber...