소개
SSH는 클라우드 서버에 연결하는 표준 방법입니다. 이는 견고하며, 새로운 암호화 표준이 개발될 때마다 이를 사용하여 새로운 SSH 키를 생성하여 핵심 프로토콜이 계속 안전하게 유지되도록 할 수 있습니다. 그러나 어떤 프로토콜이나 소프트웨어 스택도 완벽하지 않으며, SSH가 인터넷 전역에 걸쳐 널리 배포되어 있기 때문에 많은 사람들이 액세스를 시도할 수 있는 매우 예측 가능한 공격 표면 또는 공격 벡터로 작용합니다.
네트워크에 노출된 어떤 서비스도 이와 같은 방식으로 잠재적인 대상이 됩니다. 널리 액세스되는 서버에서 실행 중인 SSH 서비스의 로그를 검토하면 사용자 및 봇에 의한 반복적이고 체계적인 로그인 시도가 종종 나타납니다. 이러한 공격이 거의 제로에 가까운 성공 확률을 감소시키기 위해 SSH 키를 사용하여 암호 인증을 비활성화하는 등의 SSH 서비스를 최적화할 수 있지만, 이러한 공격은 여전히 소량의 지속적인 위협이 될 수 있습니다.
대규모 생산 배포에 대해 이러한 책임을 완전히 허용할 수 없는 경우 일반적으로 WireGuard와 같은 VPN을 구현하여 SSH 서비스 앞에 설치합니다. 이렇게 하면 외부 인터넷에서 기본 SSH 포트 22에 직접 연결하는 것이 추가 소프트웨어 추상화나 게이트웨이 없이는 불가능해집니다. 이러한 VPN 솔루션은 일반적으로 신뢰되지만, 복잡성이 증가하고 일부 자동화나 다른 작은 소프트웨어 훅을 망가뜨릴 수 있습니다.
전체 VPN 설정을 확정하기 전이나 추가로, Fail2ban이라는 도구를 구현할 수 있습니다. Fail2ban은 일정 횟수의 로그인 시도 실패 후 특정 IP를 금지하는 방화벽 구성을 자동으로 변경하는 규칙을 생성하여 대규모 공격을 크게 줄일 수 있습니다. 이렇게 하면 서버가 개입없이 액세스 시도에 대항하여 자체적으로 강화될 수 있습니다.
다른 자습서에서는 Fail2ban으로 SSH 보호하는 방법을 논의했습니다. 이 안내서에서는 Fail2ban의 작동 방식과 이 서비스의 동작을 수정하거나 확장하는 방법에 대해 자세히 다룰 것입니다.
Fail2ban의 기본 사항
Fail2ban의 목적은 일반적인 서비스 로그를 모니터하여 인증 실패의 패턴을 감지하는 것입니다.
fail2ban이 서비스 로그를 모니터링하도록 구성되면 해당 서비스에 대해 구성된 필터를 확인합니다. 필터는 해당 특정 서비스에 대한 인증 실패를 복잡한 정규 표현식을 사용하여 식별하도록 설계되었습니다. 정규 표현식은 패턴 매칭에 사용되는 일반적인 템플릿 언어입니다. 이것은 이러한 정규 표현식 패턴을 failregex라는 내부 변수로 정의합니다.
기본적으로 Fail2ban에는 일반적인 서비스에 대한 필터 파일이 포함되어 있습니다. 웹 서버와 같은 모든 서비스의 로그가 해당 필터의 failregex와 일치하는 경우, 해당 서비스에 대해 사전 정의된 조치가 실행됩니다. action은 관리자의 기호에 따라 여러 가지 다른 작업을 수행하도록 구성할 수 있는 변수입니다.
기본 작업은 로컬 방화벽 규칙을 수정하여 공격을 받는 호스트/IP 주소를 차단하는 것입니다. 예를 들어 이 작업을 확장하여 시스템 관리자에게 이메일을 보낼 수 있습니다.
기본적으로, 10분 동안에 인증 실패가 세 번 감지되면 작업이 수행되고, 기본 차단 시간은 10분입니다. 이는 구성 가능합니다.
기본 iptables 방화벽을 사용할 때, fail2ban은 서비스가 시작될 때 새로운 방화벽 규칙 집합, 또는 체인을 생성합니다. 포트 22로 전송된 모든 TCP 트래픽을 새로운 체인으로 보내는 INPUT 체인에 새로운 규칙을 추가합니다. 새로운 체인에서는 INPUT 체인으로 돌아가는 단일 규칙을 삽입합니다. Fail2ban 서비스가 중지되면 체인과 관련된 규칙이 제거됩니다.
Fail2ban 서비스 설정 탐색
Fail2ban은 /etc/fail2ban/ 디렉터리 아래의 계층 구조 내에 있는 여러 파일을 통해 구성됩니다.
fail2ban.conf 파일은 데몬이 정보를 로깅하는 방식 및 사용할 소켓 및 pid 파일과 같은 몇 가지 운영 설정을 구성합니다. 그러나 주 구성은 각 응용 프로그램의 “감옥”을 정의하는 파일에 지정됩니다.
기본적으로 fail2ban은 jail.conf 파일과 함께 제공됩니다. 그러나 이 파일은 업데이트에서 덮어쓰기가 될 수 있으므로 이 파일을 jail.local 파일로 복사하고 그곳에서 조정해야 합니다.
jail.local 파일이 이미 있는 경우 nano 또는 선호하는 텍스트 편집기를 사용하여 해당 파일을 엽니다.
이미 jail.local 파일이 없는 경우 또는 열린 파일이 비어 있는 경우 jail.conf 파일을 복사한 다음 새 파일을 엽니다.
여기서 가능한 옵션을 살펴보고 이 파일이 시스템의 다른 구성 파일과 상호 작용하는 방법을 확인하겠습니다.
기본 섹션
파일의 첫 부분은 fail2ban 정책의 기본값을 정의할 것입니다. 이러한 옵션은 각 서비스의 구성 섹션에서 재정의될 수 있습니다.
주석을 제거하면, 기본 섹션 전체는 다음과 같이 보입니다.
[DEFAULT]
ignoreip = 127.0.0.1/8
bantime = 10m
findtime = 10m
maxretry = 3
backend = auto
usedns = warn
destemail = root@localhost
sendername = Fail2Ban
banaction = iptables-multiport
mta = sendmail
protocol = tcp
chain = INPUT
action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-whois[name=%(__name__)s, dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s", sendername="%(sendername)s"]
action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s, chain="%(chain)s", sendername="%(sendername)s"]
action = %(action_)s
이것이 의미하는 바를 살펴보겠습니다:
- ignoreip: 이 매개변수는 금지 시스템에서 무시해야 하는 IP 주소를 식별합니다. 기본적으로 이는 기계 자체에서 오는 트래픽을 무시하도록 설정되어 있어 자신의 로그를 채우거나 자신을 잠금 처리하지 않도록 합니다.
- bantime: 이 매개변수는 금지 기간을 초 단위로 설정합니다. 기본값은 10분입니다.
- findtime: 이 매개변수는 Fail2ban이 반복된 인증 실패 시도를 찾을 때 주의를 기울일 시간 창을 설정합니다. 기본값은 10분으로, 소프트웨어가 지난 10분 동안의 실패한 시도 수를 계산합니다.
- maxretry: 이는 금지가 시행되기 전에
findtime창 내에서 허용되는 실패한 시도 수를 설정합니다. - backend: 이 항목은 Fail2ban이 로그 파일을 모니터링하는 방식을 지정합니다.
auto설정은 fail2ban이 먼저pyinotify를 시도하고, 그런 다음gamin을 시도하고, 사용 가능한 것에 따라 폴링 알고리즘을 사용합니다.inotify는 파일이 액세스될 때를 추적하는 내장된 리눅스 커널 기능이며, Fail2ban에서 사용되는inotify의 Python 인터페이스인pyinotify입니다. - usedns: 이것은 반대 DNS가 금지를 실행하는 데 도움이 되는지 여부를 정의합니다. 이것을 “no”로 설정하면 도메인 호스트 이름 대신 IP 자체가 금지됩니다.
warn설정은 호스트 이름을 조회하고 그 방법으로 금지를 시도하지만 활동을 로깅하여 검토합니다. - destemail: 알림 메일이 구성된 경우 이 주소로 알림 메일이 전송됩니다.
- sendername: 생성된 알림 이메일의 이메일 발신자 필드에 사용됩니다.
- banaction: 임계값에 도달했을 때 사용될 조치를 설정합니다. 이것은 실제로
/etc/fail2ban/action.d/에 위치한 파일인iptables-multiport.conf로의 경로입니다. 이것은 실제로iptables방화벽 조작을 처리하여 IP 주소를 금지합니다. 나중에 이를 살펴보겠습니다. - mta: 알림 이메일을 보내는 데 사용될 메일 전송 에이전트입니다.
- protocol: IP 금지가 실행될 때 드롭될 트래픽 유형입니다. 이것은 또한 새로운 iptables 체인에 보내는 트래픽 유형입니다.
- chain: 이것은 fail2ban 트랜잭션에 트래픽을 보내기 위한 점프 규칙으로 구성될 체인입니다.
나머지 매개 변수는 다양한 지정된 조치를 정의합니다. 이들은 변수 치환을 사용하여 이전에 정의한 일부 매개 변수를 텍스트 문자열 내에서 전달합니다. 다음과 같이:
%(var_name)s
위의 줄은 var_name의 내용으로 대체됩니다. 이를 통해 action 변수가 기본적으로 action_ 정의로 설정되어 있음을 알 수 있습니다(금지만, 메일 경고는 없음).
이는 차단을 수행하는 데 필요한 매개변수(서비스 이름, 포트, 프로토콜 및 체인) 목록을 사용하여 iptables-multiport 동작을 호출함으로써 구성됩니다. __name__은 아래 섹션 헤더에 지정된 서비스 이름으로 대체됩니다.
서비스별 섹션
기본 섹션 아래에는 기본 설정을 재정의하는 데 사용할 수 있는 특정 서비스에 대한 섹션이 있습니다. 이는 일반 값과 다른 매개변수만 수정하는 관습을 따릅니다(설정보다 관습).
각 섹션 헤더는 다음과 같이 지정됩니다:
[service_name]
enabled = true 라인을 포함하는 모든 섹션은 읽혀지고 활성화됩니다.
각 섹션 내에서 로그를 구문 분석하는 데 사용될 필터 파일(파일 확장자 제외) 및 로그 파일 위치를 포함하여 매개변수가 구성됩니다.
이를 기억하면, SSH 서비스에 대한 동작을 지정하는 섹션은 다음과 같습니다:
[SSH]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6
이 섹션을 활성화하고 포트를 기본 “ssh” 포트(port 22)로 설정합니다. 이 섹션에서 Fail2ban에게 이 로그를 보고 이 로그를 파싱하도록 지시하는 위치는 /etc/fail2ban/filters.d 디렉토리에 있는 sshd.conf라는 파일입니다. 이 섹션에서는 /var/log/auth.log에 있는 로그를 확인합니다.
필요한 모든 다른 정보는 [DEFAULT] 섹션에서 정의된 매개변수에서 가져옵니다. 예를 들어, 작업은 iptables-multiport banaction을 사용하여 공격을 받는 IP 주소를 차단하는 action_로 설정됩니다. 이는 /etc/fail2ban/action.d에서 찾을 수 있는 iptables-multiport.conf라는 파일을 참조합니다.
보시다시피, [DEFAULT] 섹션의 작업은 일반적이고 유연해야 합니다. 합리적인 기본값을 제공하는 매개변수와 함께 매개변수 대체를 사용하면 필요할 때 정의를 재정의할 수 있습니다.
필터 파일 검토
구성에서 무슨 일이 벌어지는지 이해하기 위해서는 주요 작업을 수행하는 필터 및 작업 파일을 이해해야 합니다.
필터 파일은 로그 파일에서 위반 특성을 식별하기 위해 fail2ban이 찾을 라인을 결정할 것입니다. 액션 파일은 서비스가 시작될 때 방화벽 구조를 구축하는 데 필요한 모든 작업을 구현하고, 규칙을 추가하고 삭제하며, 서비스가 중지될 때 방화벽 구조를 철거하는 등의 모든 작업을 수행합니다.
위의 구성에서 SSH 서비스가 호출하는 필터 파일을 살펴보겠습니다:
[INCLUDES]
before = common.conf
[Definition]
_daemon = sshd
failregex = ^%(__prefix_line)s(?:error: PAM: )?[aA]uthentication (?:failure|error) for .* from <HOST>( via \S+)?\s*$
^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from <HOST>\s*$
^%(__prefix_line)sFailed \S+ for .*? from <HOST>(?: port \d*)?(?: ssh\d*)?(: (ruser .*|(\S+ ID \S+ \(serial \d+\) CA )?\S+ %(__md5hex)s(, client user ".*", client host ".*")?))?\s*$
^%(__prefix_line)sROOT LOGIN REFUSED.* FROM <HOST>\s*$
^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from <HOST>\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because not listed in AllowUsers\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because listed in DenyUsers\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because not in any group\s*$
^%(__prefix_line)srefused connect from \S+ \(<HOST>\)\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because a group is listed in DenyGroups\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because none of user's groups are listed in AllowGroups\s*$
ignoreregex =
[INCLUDES] 섹션 헤더는 이 파일 이전이나 이후에 읽히는 다른 필터 파일을 지정합니다. 이 예에서는 common.conf 파일이 읽혀지고 이 파일의 다른 라인들 앞에 배치됩니다. 이는 구성에서 사용할 일부 매개변수를 설정합니다.
다음으로 실제 필터 일치 규칙을 정의하는 [Definition] 섹션이 있습니다. 먼저, 우리가 모니터링하는 데몬의 이름을 설정하는 _daemon 매개변수를 사용합니다.
그 후, 일치하는 로그 파일의 라인을 발견했을 때 트리거할 패턴을 설정하는 실제 failregex 정의를 진행합니다. 이는 사용자가 올바르게 인증하지 않았을 때 발생할 수 있는 다양한 오류와 실패에 기반한 정규 표현식입니다.
%(__prefix_line)s과 같은 라인의 일부는 소스로 사용된 common.conf 파일에서 설정된 매개변수의 값으로 대체됩니다. 이는 표준 방법을 사용하여 운영 체제가 로그 파일에 작성하는 다양한 선두 정보와 일치시키기 위해 사용됩니다. 예를 들어, /var/log/auth.log의 일부 라인은 다음과 같을 수 있습니다:
May 6 18:18:52 localhost sshd[3534]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=101.79.130.213
May 6 18:18:54 localhost sshd[3534]: Failed password for invalid user phil from 101.79.130.213 port 38354 ssh2
May 6 18:18:54 localhost sshd[3534]: Received disconnect from 101.79.130.213: 11: Bye Bye [preauth]
강조된 부분은 운영 체제가 더 많은 문맥을 제공하기 위해 삽입하는 표준 패턴입니다. 그 후에는 iptables 방화벽 서비스가 로그에 실패 시도를 기록하는 다양한 방법이 있습니다.
위의 처음 두 줄에서 두 가지 별개의 실패를 볼 수 있습니다 (PAM 인증 오류 및 암호 오류). 필터에서 정의된 정규 표현식은 가능한 모든 실패 라인과 일치하도록 설계되었습니다. 이러한 줄 중 어느 것도 수정할 필요가 없지만, 필터 파일을 직접 만들어야 할 때 어플리케이션의 무단 사용 오류를 나타내는 모든 로그 항목을 잡아야 함을 알고 있어야 합니다.
맨 아래에서 현재 공백인 ignoreregex 매개 변수를 볼 수 있습니다. 이것은 일반적으로 특정 시나리오에서 fail2ban의 실패 트리거를 부정하려는 경우에 실패 조건과 일치하는 더 구체적인 패턴을 제외하는 데 사용할 수 있습니다. 이것을 조정하지는 않을 것입니다.
파일 검토를 마쳤으면 저장하고 닫으십시오.
작업 파일 검토
이제 작업 파일을 살펴 보겠습니다. 이 파일은 악의적인 호스트를 금지하고 필요할 때 이러한 호스트를 추가하거나 제거하기 위한 구조로 방화벽을 설정하는 역할을 합니다.
우리 SSH 서비스가 호출하는 작업은 iptables-multiport입니다. 관련 파일을 엽니다:
이 파일에서 주석을 제거한 결과는 다음과 같습니다:
[INCLUDES]
before = iptables-blocktype.conf
[Definition]
actionstart = iptables -N fail2ban-<name>
iptables -A fail2ban-<name> -j RETURN
iptables -I <chain> -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
actionstop = iptables -D <chain> -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
actioncheck = iptables -n -L <chain> | grep -a 'fail2ban-<name>[ \t]'
actionban = iptables -I fail2ban-<name> 1 -s <ip> -j <blocktype>
actionunban = iptables -D fail2ban-<name> -s <ip> -j <blocktype>
[Init]
name = default
port = ssh
protocol = tcp
chain = INPUT
파일은 iptables-blocktype.conf라는 다른 작업 파일을 소스로 시작하여 blocktype 매개변수를 정의합니다. 이 매개변수는 클라이언트가 차단될 때 설정될 제한을 구성합니다. 기본적으로 blocktype은 패킷을 거부하도록 설정되어 있으며, 차단된 클라이언트가 보낸 핑에 대해 포트가 연결할 수 없다는 거부 메시지를 응답합니다. 이를 아래의 금지 규칙에서 사용합니다.
다음으로 규칙 정의로 넘어갑니다. actionstart 작업은 fail2ban 서비스가 시작될 때 iptables 방화벽을 설정합니다. 새로운 체인을 생성하고 해당 체인에 호출 체인으로 돌아가는 규칙을 추가한 다음, 올바른 프로토콜 및 포트 대상과 일치하는 트래픽을 새로운 체인으로 전달하는 INPUT 체인의 시작 부분에 규칙을 삽입합니다.
이는 우리가 jail.local 파일에서 정의한 action로 전달된 값들을 사용하여 수행됩니다. name은 각 서비스의 섹션 헤더에서 가져옵니다. chain, protocol, 및 port는 해당 파일의 action 라인 자체에서 가져옵니다.
여기서, 다른 파일에서 설정된 모든 매개변수는 매개변수 이름을 꺽쇠 괄호에 넣어 참조됩니다:
<param_name>
동반 actionstop 정의로 이동하면 방화벽 명령이 actionstart 명령의 반대로 구현되는 것을 볼 수 있습니다. Fail2ban 서비스가 중지되면 추가된 모든 방화벽 규칙이 깔끔하게 제거됩니다.
다른 작업인 actioncheck는 금지 규칙을 추가하기 전에 올바른 체인이 생성되었는지 확인합니다.
다음으로, 실제 금지 규칙인 actionban에 도달합니다. 이 규칙은 새로운 규칙을 생성된 체인에 추가함으로써 작동합니다. 이 규칙은 위반 클라이언트의 소스 IP 주소와 일치하며 – 이 매개변수는 권한 로그에서 maxretry 한도에 도달했을 때 읽힙니다. 이는 파일 맨 위의 [INCLUDE] 섹션에서 가져온 blocktype 매개변수로 정의된 차단을 시행합니다.
actionunban 규칙은 이 규칙을 제거합니다. 이는 금지 시간이 경과했을 때 fail2ban에 의해 자동으로 수행됩니다.
마지막으로, [Init] 섹션에 도달합니다. 이는 작업 파일이 모든 적절한 값을 전달하지 않고 호출될 경우 일부 기본값을 제공합니다.
Fail2ban 서비스가 금지를 시행하기 위해 구성 파일을 처리하는 방법
이제 세부 사항을 살펴보았으니 fail2ban이 시작될 때 발생하는 프로세스를 살펴보겠습니다.
초기 구성 파일 로드
먼저, 주요 fail2ban.conf 파일이 읽혀지며 주요 프로세스가 작동해야 하는 조건을 결정합니다. 필요한 경우 소켓, pid 및 로그 파일을 생성하고 사용을 시작합니다.
다음으로, fail2ban은 구성 세부 정보를 얻기 위해 jail.conf 파일을 읽습니다. 이후 jail.d 디렉토리에서 찾은 .conf로 끝나는 파일들을 알파벳 순서로 읽습니다. 이러한 파일에서 찾은 설정을 내부 구성에 추가하여 jail.conf 파일에 설명된 값보다 새 값이 우선합니다.
그런 다음 jail.local 파일을 찾아이 프로세스를 반복하고 새 값에 맞게 적응합니다. 마지막으로, 다시 jail.d 디렉토리를 검색하고 알파벳 순서로 .local로 끝나는 파일을 읽습니다.
우리의 경우, jail.conf 파일과 jail.local 파일만 있습니다. jail.local 파일에서는 jail.conf 파일과 다른 값만 정의하면 됩니다. 이제 fail2ban 프로세스에는 찾은 모든 파일의 조합을 나타내는 메모리로 로드된 지시문 집합이 있습니다.
각 섹션을 검토하고 enabled = true 지시문을 찾습니다. 찾으면 해당 섹션에 정의된 매개변수를 사용하여 정책을 작성하고 필요한 조치를 결정합니다. 서비스 섹션에 없는 매개변수는 [DEFAULT] 섹션에 정의된 매개변수를 사용합니다.
시작 조치 결정을 위한 작업 파일 구문 분석
Fail2ban은 금지/금지 해제 정책을 구현하기 위해 호출할 작업 스크립트를 결정하기 위해 action 지시문을 찾습니다. 찾을 수 없는 경우 위에서 결정된 기본 작업을 사용합니다.
작업 지시문은 해당 파일에서 필요한 매개변수를 전달하는 이름과 키-값 사전으로 구성됩니다. 이러한 값들은 종종 서비스 섹션에 구성된 설정을 참조하여 매개변수 대체 형식으로 제공됩니다. “name” 키에는 일반적으로 섹션 헤더의 값으로 설정될 특수한 __name__ 변수의 값을 전달합니다.
그런 다음 Fail2ban은 이 정보를 사용하여 action.d 디렉토리에서 해당 파일을 찾습니다. 먼저 .conf로 끝나는 관련 작업 파일을 찾은 다음 action.d 디렉토리에도 있는 동반된 .local 파일에 포함된 설정을 사용하여 찾은 정보를 수정합니다.
그 파일을 구문 분석하여 취해야 할 조치를 결정합니다. 환경을 설정하는 데 필요한 조치를 보려면 actionstart 값이 읽힙니다. 이는 대부분 향후 금지 규칙을 수용하기 위해 방화벽 구조를 생성하는 것을 포함합니다.
이 파일에 정의된 조치는 action 지시문에서 전달된 매개변수를 사용합니다. 이 값을 사용하여 적절한 규칙을 동적으로 생성합니다. 특정 변수가 설정되지 않았다면, 조치 파일에 설정된 기본 값들을 확인하여 빈칸을 채울 수 있습니다.
필터 파일을 구문 분석하여 필터링 규칙 결정하기
jail.* 파일에서 서비스에 대한 매개변수는 로그 파일의 위치뿐만 아니라 파일을 확인하는 데 사용해야 할 폴링 메커니즘도 포함됩니다(backend 매개변수로 정의됨). 또한 로그의 한 줄이 실패를 나타내는지 여부를 결정하는 필터도 포함됩니다.
Fail2ban은 일치하는 필터 파일을 찾기 위해 filter.d 디렉터리를 찾습니다. 그런 다음, 적층된 줄을 일치시킬 수 있는 패턴을 정의하기 위해 이 파일을 읽습니다. 그런 다음, 기본 매개변수 중 하나가 덮어쓰여 졌는지 확인하기 위해 .local로 끝나는 일치하는 필터 파일을 검색합니다.
서비스 로그 파일을 읽으면서 이 파일에 정의된 정규 표현식을 사용합니다. filter.d 파일에 정의된 각 failregex 라인을 서비스 로그 파일에 기록된 각 새로운 줄에 대해 시도합니다.
정규 표현식이 일치하는 경우, 해당 줄을 ignoreregex에 의해 정의된 정규 표현식과 비교합니다. 이 또한 일치하면 fail2ban은 무시합니다. 줄이 failregex의 표현식과 일치하지만 ignoreregex의 표현식과 일치하지 않는 경우, 해당 줄을 유발한 클라이언트에 대해 내부 카운터가 증가되고 관련 이벤트에 대한 연관 타임스탬프가 생성됩니다.
jail.* 파일의 findtime 매개변수에 의해 설정된 시간 창이 이벤트 타임스탬프에 의해 결정된 경우, 내부 카운터가 다시 감소되고 해당 이벤트는 더 이상 금지 정책과 관련이 없게 됩니다.
시간이 지남에 따라 추가 인증 실패가 기록되면 각 시도가 카운터를 증가시킵니다. 설정된 시간 창 내에 maxretry 매개변수로 설정된 값에 도달하면 fail2ban은 서비스에 대해 action.d/ 파일에 정의된 actioncheck 작업을 호출하여 금지를 시행합니다. 이는 actionstart 작업이 필요한 구조를 설정했는지 여부를 확인하기 위함입니다. 그런 다음 유해한 클라이언트를 금지하기 위해 actionban 작업을 호출합니다. 또한 이 이벤트에 대한 타임스탬프를 설정합니다.
bantime 매개변수로 지정된 시간이 경과하면 fail2ban은 actionunban 작업을 호출하여 클라이언트의 금지를 해제합니다.
결론
이제 당신은 fail2ban이 어떻게 작동하는지에 대해 상당히 깊은 이해를 가지고 있습니다. 표준 구성에서 벗어나게 되면 fail2ban이 어떻게 작동하는지를 알고 있다면 그 동작을 예측 가능한 방식으로 조작하는 데 도움이 됩니다.
다른 서비스를 fail2ban으로 보호하는 방법에 대해 알아보려면 Ubuntu 22.04에서 Fail2Ban을 사용하여 Nginx 서버를 보호하는 방법을 읽어보세요.