Rozważyć CrowdSec dla sshd (zamiast/obok fail2ban) #1

Open
opened 2026-09-05 19:58:30 +02:00 by erxyi · 0 comments
Owner

Wykrywanie wzorców ataku (SSH brute-force itd.) + automatyczne zgłaszanie do
współdzielonej bazy CrowdSec CAPI, plus ciągnięcie community blocklist od
innych userów. Blokowanie ruchu jest oddzielone (opcjonalny "bouncer"), więc
da się mieć samo wykrywanie+report bez ryzyka że coś się przez pomyłkę
zablokuje.

Nie pilne: obecny ruch skanujący na SSH (boty próbujące root/typowe loginy)
jest i tak nieszkodliwy przy auth wyłącznie kluczem
(PermitRootLogin prohibit-password w roles/base). Rozważyć jeśli szum w
logach zacznie przeszkadzać albo pojawi się realny powód do defense-in-depth.

Zobacz też notatkę w README.md ("Ideas / backlog").

Wykrywanie wzorców ataku (SSH brute-force itd.) + automatyczne zgłaszanie do współdzielonej bazy CrowdSec CAPI, plus ciągnięcie community blocklist od innych userów. Blokowanie ruchu jest oddzielone (opcjonalny "bouncer"), więc da się mieć samo wykrywanie+report bez ryzyka że coś się przez pomyłkę zablokuje. Nie pilne: obecny ruch skanujący na SSH (boty próbujące root/typowe loginy) jest i tak nieszkodliwy przy auth wyłącznie kluczem (PermitRootLogin prohibit-password w roles/base). Rozważyć jeśli szum w logach zacznie przeszkadzać albo pojawi się realny powód do defense-in-depth. Zobacz też notatkę w README.md ("Ideas / backlog").
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
erxyi/niechybnie#1
No description provided.