개념 사전 · 프로그램

Fail2ban

페일투밴

은 로그에서 정해진 실패 조건을 찾고 일정한 기준에 이르면 방화벽 등의 action을 호출하는 도구다. 로그의 일치 수와 실제 로그인 시도 수는 같지 않을 수 있다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

01무엇이고, 어떤 일을 하나

  • 서비스별 실패 로그를 과 backend로 읽는다.
  • · 조건으로 주소별 일치를 누적한다.
  • 과 action으로 임시 제한을 집행하고 해제한다.

02어떤 순서로 동작하나

  1. 로그 수신

    Backend가 파일 위치 또는 journalmatch에 맞는 기록을 읽는다.

  2. 패턴·주소 추출

    가 신뢰할 수 있는 실패 패턴에서 대응할 주소를 추출한다. 사용자 문자열을 주소로 오인하면 오차단이 된다.

  3. 시간창 집계

    같은 대상의 일치 기록을 안에서 세어 조건을 평가한다. 기록 수는 사람의 시도 횟수와 같지 않을 수 있다.

  4. Ban Action

    설정된 action이 방화벽 등에 규칙을 반영한다. 논리적 Ban만으로 ·와 모든 통신 경로가 막히는 것은 아니다.

  5. 만료·해제

    또는 관리자의 해제에 따라 규칙을 제거하고 예외·오탐·재발 상태를 확인한다.

03먼저 알아둘 용어와 구성요소

대상 서비스·필터·로그 경로·차단 동작을 묶은 설정.
일치 이벤트를 집계하는 시간 범위.
설정한 시간 범위에서 차단 판단에 쓰는 일치 횟수 기준.
차단을 유지하는 시간으로 무제한 여부 등은 설정에 따른다.
실패 로그와 차단 대상 주소 등을 추출하는 패턴 정의.
LEARN THROUGH PRACTICE

SSH 실패 로그에서 Jail 집계와 실제 차단까지

주석 처리된 설정, 실행 중인 통계, 방화벽 action을 구분하여 차단 동작의 증거를 읽는다.

실습 구성과 전제

  • 자신의 격리 SSH 서버에서 관리 접속을 복구할 콘솔과 정상 접속원을 준비한다.
  • 그림은 설정 설명과 실행 상태를 비교한 자료다. 보이는 통계를 특정 시험 횟수와 자동으로 같다고 간주하지 않는다.
  1. 설정 설명과 활성 Jail을 구분하기

    • 설정 행 앞의 #은 주석이다. 예제에 enabled=true라는 글자가 있더라도 주석이면 그 행 자체가 을 활성화하지 않는다.
    • 실제로 적용된 값은 .local 덮어쓰기와 다른 설정 파일을 합친 결과다. 배포본 파일의 한 부분만 보는 대신 실행 중인 목록과 ··을 조회한다.
    bash
    sudo fail2ban-client status sshd
    sudo fail2ban-client get sshd maxretry
    sudo fail2ban-client get sshd findtime
    sudo fail2ban-client get sshd bantime

    실행 중인 의 상태와 시간 조건을 조회하는 예. 인증 실패 트래픽을 생성하지 않는다.

    Fail2ban 탐지·차단 설정과 상태원본 크기로 보기 ↗
    • # [sshd]와 # enabled = true 앞에 주석 기호가 보인다. 이 두 줄만으로 sshd Jail이 켜졌다고 판단할 수 없다.
    • 주석 옆에는 enabled와 filter 등의 역할을 설명하는 메모가 있다. 옵션 설명과 현재 유효 설정을 구분해 읽어야 한다.
    확인 기준

    sshd 이 목록에 있고 유효 설정이 의도한 값인지 확인한다. 설정 파일 수정 후에는 문법 검사와 해당 재적용이 필요하다.

  2. 로그 일치 건수와 차단 건수를 나누어 읽기

    • 가 로그에서 뽑아낸 주소별 실패 이벤트를 범위에서 집계한다. 한 번의 로그인 시도에서 여러 줄이 발생할 수 있으므로 Total failed를 사람이 입력한 비밀번호 횟수와 동일시하지 않는다.
    • backend는 journalmatch로 저널 항목을 고른다. 서비스 이름과 프로그램 이름이 실제 로그와 다르면 파일이 존재해도 이 에 이벤트가 들어오지 않을 수 있다.
    Fail2ban 탐지·차단 설정과 상태원본 크기로 보기 ↗
    • 상태 출력은 Currently failed 1, Total failed 12와 Currently banned 1, Total banned 1을 별도 구역에 표시한다.
    • Journal matches에 sshd.service와 sshd·sshd-session 조건이 보인다. 파일 경로 하나를 tail하는 방식과 입력 선택 조건이 다르다.
    확인 기준

    같은 시간대의 인증 로그·Found·Ban 사건을 대응시킨다. 통계가 증가했어도 현재 차단 주소와 시험 주소가 같은지는 별도 확인한다.

  3. action에서 실제 패킷 경로로 내려가기

    • action_은 banaction 이름을 참조하고, action_mw는 여기에 메일 보고 동작 등을 묶는다. 템플릿에 적힌 이름만으로 실제 방화벽 백엔드를 iptables라고 고정하면 안 된다.
    • 내부의 Ban 상태와 커널의 차단 규칙은 서로 다른 확인 지점이다. 설치 환경의 action과 규칙을 읽고, 시험 접속원의 접근 제한과 정상 접속원의 유지 여부를 함께 검증한다.
    bash
    sudo fail2ban-client get sshd actions
    sudo journalctl -u fail2ban --since '-10 min' --no-pager

    선택된 action과 최근 서비스 기록을 조회한다. 운영 주소나 인증 비밀을 결과 보고서에 복사하지 않는다.

    Fail2ban 탐지·차단 설정과 상태원본 크기로 보기 ↗
    • action_ 정의가 %(banaction)s를 참조하므로 실제 실행할 차단 방식은 치환된 설정에 달려 있다.
    • action_mw는 차단 템플릿 다음에 메일 관련 동작을 붙인다. 알림 발송과 패킷 차단이 하나의 성공 조건은 아니다.
    확인 기준

    자동 해제 시간이 지난 뒤 상태와 방화벽 규칙이 함께 해제되는지도 확인한다. 규칙만 사라졌다면 방화벽 reload와 action 오류를 조사한다.

실습에서 확인한 동작 원리

  • 설정 설명→유효 →로그 일치→Ban 상태→방화벽 규칙→접속 결과를 순서대로 연결한다.
  • 실패 로그 수, 로그인 시도 수, 고유 주소 수는 서로 다른 지표다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • 시험 조건: =5·=10분이고 주소 A의 이력이 비어 있다고 가정한다. 한 동작이 필터에 맞는 네 레코드를 생성했다.
  • 첫 동작 집계: 필터가 네 레코드를 모두 실패로 인정하면 카운터는 4다. 사용자가 한 번 입력했다는 사실과 집계 단위가 다르다.
  • 다음 레코드: 같은 주소에서 10분 안에 일치 레코드 하나가 추가되면 5에 도달하여 설정된 차단 조건을 만족한다.
  • 다른 주소: 주소 B의 레코드는 A의 이력에 더하지 않는다. 주소 추출이 잘못되면 이 분리가 깨질 수 있다.
  • 실제 효과: Ban 로그 뒤 action 성공·규칙 존재·새 연결의 처리 결과를 따로 확인한다. 이미 성립한 연결과 새 연결의 영향이 같다고 가정하지 않는다.

05혼동하기 쉬운 점과 확인 기준

  • 로그 원천: backend의 journalmatch와 파일 backend의 경로를 혼동하지 않았는지 본다. 가 맞아도 다른 로그를 읽으면 이력이 쌓이지 않는다.
  • 시각 파싱: 레코드의 시각·시간대·서버 현재 시각이 맞는지 확인한다. 오래된 것으로 판단된 레코드가 밖으로 빠질 수 있다.
  • 주소 신뢰: 사용자가 조작할 수 있는 본문 문자열을 신뢰 주소처럼 추출하지 않는다. 프록시 앞뒤에서 어느 주소를 차단해야 하는지도 명시한다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.