하나의 banaction, 두 개의 전송: fail2ban-VPN-jail 고치기
ban은 그 액션의 프로토콜만큼만 넓습니다. 체인 카운터를 수신기와 비교하고, 그다음 jail 안에서 두 전송을 모두 덮으세요.
fail2ban 자체는 패킷을 하나도 버리지 않습니다: 액션을 호출하며, 그 액션이 프로토콜과 포트를 지정합니다. jail이 ban을 보고하는데 데몬이 계속 로그인을 받아들인다면, 그 ban은 대개 실제이며 로그가 시사하는 것보다 좁습니다. 다른 전송으로 다시 연결하는 클라이언트는 설치된 규칙을 결코 만나지 않습니다. 무엇이든 바꾸기 전에 액션이 무엇을 설치했는지와 데몬이 무엇을 수신하는지 비교하세요. 증거는 액션이 기록한 방화벽 체인에 있고 jail 목록에는 없기 때문입니다.
jail 요약이 아니라 체인을 읽으세요
fail2ban은 서비스 체인 앞에 자체 체인을 삽입하므로 카운터 목록은 존재하는 것을 정확히 보여줍니다. jail의 이름을 딴 체인이 프로토콜 열이 udp로 표시된 규칙 하나를 담고 있다면, 그것이 계속 도착하는 TCP 로그인에 대한 완전한 설명입니다. 금지된 출발지의 UDP 패킷만 거부됩니다. 서비스에는 TCP 수신기가 있고, 그 체인에서 어떤 것도 그것을 건드리지 않습니다.
이웃 jail의 효과도 주의하세요. 한 호스트가 완벽하게 구성된 것처럼 보일 수 있는 것은 다른 jail이 빠진 절반을 공급하기 때문일 뿐이며, 같은 빌드는 그 jail이 설치되지 않은 곳에서는 아무것도 하지 않습니다.
액션은 하나의 프로토콜만 지목하며, 바로 거기서 깨집니다
각 banaction은 방화벽 명령 템플릿이며, 프로토콜은 그 자리 표시자 중 하나에 들어 있습니다. 좁음은 의도된 것으로, 웹 jail과 DNS jail이 같은 포트를 막을 이유는 없습니다. 서비스가 둘 이상의 전송을 수신할 때 함정이 되며, VPN 데몬은 흔히 그렇게 합니다. 필터가 두 전송의 실패 로그인을 지켜봐도 액션은 하나만 덮습니다.
SoftEther와 OpenVPN 배포는 보통 UDP와 TCP를 동시에 수신하며, 로그 줄이 두 경우 모두 같아 보이므로 필터는 둘 다 지켜봅니다. 비대칭은 jail 자체 보고서에는 결코 나타나지 않습니다. fail2ban은 실패를 정확히 세고 나서 그 실패가 도착한 트래픽의 절반에만 적용되는 규칙을 설치했습니다.
ban이 두 전송을 모두 덮게 하세요
대신 jail 정의에서 고치세요; 손으로 쓴 규칙은 다음 재적재에서 뒤섞입니다. 프로토콜마다 하나씩 두 액션을 명시하세요:
action = %(banaction)s[name=%(__name__)s-tcp, actionname=%(__name__)s-tcp, protocol="tcp", port="%(port)s", chain="%(chain)s"]
%(banaction)s[name=%(__name__)s-udp, actionname=%(__name__)s-udp, protocol="udp", port="%(port)s", chain="%(chain)s"]
protocol = all로 줄이려고 하지 마세요. 기본 banaction은 multiport 액션이며 -p <protocol> -m multiport --dports <port>로 확장됩니다. L4 프로토콜이 없으면 포트 일치가 시험할 것이 없으므로 iptables는 규칙을 거부하고, jail은 여전히 성공한 ban을 보고합니다. iptables-allports나 nftables-allports 같은 전체 포트 액션은 항목 하나를 받아들이지만 그 출발지의 모든 포트를 막으며, 이는 다른 결정이고 자체적인 정당화가 필요합니다. protocol은 tcp나 udp로 두고 두 항목을 받아들이세요.
설정을 믿지 말고 규칙이 존재함을 증명하세요. 설정은 체인이 그것을 붙들 때까지 의도에 불과합니다:
iptables -S f2b-vpn-tcp
iptables -S f2b-vpn-udp
각 체인은 규칙 하나를 나열해야 하며, 첫 번째에 -p tcp, 두 번째에 -p udp이 들어가고 둘 다 금지된 주소를 지정합니다. 그다음 같은 주소가 두 전송 모두에서 거부되는지 확인하세요. 체인에서 보지 못한 ban은 희망일 뿐이며, 같은 증상의 다음 보고는 다시 같은 한 시간을 치르게 합니다.
ban이 여전히 놓치는 것, 그리고 다음 사례
액션이 하는 일은 단일 출발지를 거부하는 것이고, 그것도 그 안에 나열된 포트에서만입니다. 주소를 돌리는 공격자에게는 아무 효과가 없고, 수백 명의 사용자가 공유하는 통신사급 NAT 출구에서 적대적 기계를 분리할 수도 없습니다. 그곳에서는 ban 하나가 아무것도 하지 않은 사람들을 차단합니다. 필터가 클라이언트가 실제로 가진 주소를 읽도록 하세요. 전달된 헤더나 프록시 주소가 아닙니다. 실수가 스스로 만료되도록 창을 충분히 짧게 유지하세요.
이 중 어느 것도 프로토콜 수정을 건너뛰자는 주장이 아닙니다; 두 생각을 동시에 붙들자는 주장입니다. ban은 jail 요약이 시사하는 것보다 좁고, 완전한 ban조차 위협보다 좁습니다. 방화벽 체인을 데몬의 수신기 목록 옆에 두고 프로토콜별로 비교하세요. ban이 서비스에 도달할 수 있는지 자체를 그 두 목록이 결정하기 때문입니다.
재적재 명령과 체인 목록을 jail 옆 런북에 남기세요. 다음 사람은 둘 다 필요하지만 jail 요약은 어느 것도 알려주지 않습니다.