두 도구 모두 로그를 읽고 주소를 차단하니, 얼핏 보면 CrowdSec은 코드베이스가 더 새로운 Fail2ban입니다. 둘의 차이는 그보다 본질적이며, 코드의 나이가 아니라 차단 결정이 어디에서 오는가에 있습니다.

구조

Fail2ban은 로그를 읽고 정규식 일치를 세어 방화벽 명령을 부르는 하나의 프로세스입니다. 모든 결정은 당신의 머신에서 당신의 카운터로 내려집니다. 아무것도 어디로도 보내지 않고, 의존성이 없으며, 설정은 텍스트 파일입니다.

CrowdSec은 두 부분으로 나뉘어 있고, 그것이 설치 전에 이해해야 할 핵심입니다. 에이전트 자체는 탐지만 합니다. 로그를 해석하고 시나리오를 적용해 결정을 자기 데이터베이스에 씁니다. 결정을 집행하는 것은 별도의 프로그램인 bouncer입니다. bouncer가 설치돼 있지 않으면 CrowdSec은 돌면서 경보를 보여 주고 결정 목록을 유지하되 — 아무것도 차단하지 않습니다.

첫 만남에서 가장 흔한 실망이 이것입니다. 도구는 설치됐고 공격은 보이는데 트래픽은 이전과 똑같이 흐릅니다.

sudo apt install crowdsec
sudo apt install crowdsec-firewall-bouncer-iptables
sudo cscli bouncers list

마지막 명령은 등록된 항목을 적어도 하나 보여 줘야 합니다. 빈 목록은 차단이 없다는 뜻입니다.

두 번째 차이: 공유 평판

Fail2ban은 당신 쪽에서 일어난 일만 압니다. 어제 다른 서버 백 대를 털고 다닌 주소도 당신의 문을 두드리기 전까지는 깨끗하며, 그 첫 다섯 번의 시도는 공짜입니다.

CrowdSec은 무엇이 걸렸는지에 대한 신호를 공유 네트워크로 보내고, 다른 사람들의 서버에서 목격된 주소 목록을 돌려받습니다. 실용적 효과는 이렇습니다. 추측 시도의 눈에 띄는 몫이 첫 시도 전에 잘려 나갑니다. 분산 공격에 대해 특히 중요합니다 — 각각 한 번씩만 시도하는 수천 개의 주소, 지역 카운터가 정의상 무력한 상황.

그리고 미리 알아 둘 것이 있습니다. 교환은 양방향입니다. 당신의 서버에서 나가는 것은 위반 주소와 걸린 시나리오의 종류입니다. 완전히 지역에서만 돌릴 수도 있습니다 — 클라우드 콘솔에 등록하지 않고 — 그러나 그러면 공유 목록도 당신에게 닿지 않고 주된 장점이 사라집니다. 그것은 설정의 세부가 아니라 의식적인 선택입니다.

일상적인 명령

sudo cscli metrics
sudo cscli alerts list
sudo cscli decisions list
sudo cscli decisions delete --ip 203.0.113.25

metrics는 로그가 아예 읽히고 있는지에 답합니다. 해석된 줄 수가 0이면 당신의 웹 서버를 위한 collection이 설치되지 않았거나 로그 경로가 틀린 것입니다. 「설치했는데 작동하지 않는다」의 두 번째로 흔한 경우입니다.

sudo cscli collections list
sudo cscli collections install crowdsecurity/nginx

자원

CrowdSec은 Go로 쓰였고 상태를 데이터베이스에 담습니다. 메모리 사용량은 100 MB 정도에 bouncer가 더해집니다. 메모리 1 GB짜리 서버에서는 눈에 띄고, 2 GB부터는 그렇지 않습니다. Fail2ban은 더 가볍고, 하는 일도 더 적습니다.

둘 다 돌릴 가치가 있는가

둘은 충돌하지 않습니다. 하나는 자기 규칙을 방화벽에 쓰고 다른 하나도 자기 것을 쓰며, 같은 주소를 두 번 차단해도 해가 없습니다. 합리적인 분담은 이렇습니다.

CrowdSec이 대량 트래픽을 맡습니다. SSH 추측, 웹 서버 스캔, 공유 목록의 알려진 나쁜 주소. Fail2ban은 자기 형식의 자기 로그가 있는 자리에 남습니다. 시나리오를 쓰기보다 정규식을 쓰기가 쉬운 곳 — 손수 만든 애플리케이션, 드문 서비스, 특정 로그인 폼.

하나만 골라야 한다면 기준은 이렇습니다. 끊임없이 탐색당하는 사이트가 있는 서버에서는 공유 목록 덕에 CrowdSec이 더 줍니다. 키로만 SSH로 당신만 닿는 서버에서는 둘의 차이가 작습니다 — 거기서 대부분의 일은 비밀번호를 끄면서 이미 끝났습니다.

둘이 공유하는 한계

어느 쪽도 애플리케이션의 취약점으로부터 지켜 주지 않습니다. 둘 다 요청 빈도와 주소 평판을 다루며, 깨끗한 주소에서 첫 시도에 플러그인의 구멍을 파고드는 요청은 둘 다 지나칩니다. 그것은 다른 도구의 일입니다 — 요청 수준의 WAF와 제때의 업데이트. 주소 차단은 원인이 아니라 배경 소음을 없앱니다.

어느 쪽이든 실용적 가치는 누군가 결과를 들여다보는지에 달렸습니다. 늘어나는 결정의 수, 처음으로 걸린 시나리오, 시도가 오는 국가의 변화 — 그 도구를 설치한 이유가 되는 정보가 그것입니다. 한 페이지에서 어떤 모습인지는 아래 데모에서.