사무실을 이전하고, 새로운 장소에 LAN/WAN 인프라를 구축했습니다.
내 서버(LAN이 아닌 클라우드에 있음)에 대한 SSH 연결을 시작하면 짧은 간격으로 처음 3~4개의 요청(예: 5초 내에 4개 호출)에 대해 제대로 작동하지만 추가 연결은 SYN_SENT 상태에서 중단됩니다. 나중에 요청은 시간 초과처럼 보일 때까지 SYN_SENT로 인해 모두 중단됩니다. 그 후에는 몇 번 다시 작동합니다.
서버는 변경되지 않았으며 다른 로컬 클라이언트는 이런 방식으로 작동합니다. 그래서 차이점은 두 엔드포인트가 아니라 IT 인프라에 있다고 생각합니다.
이 행동에 대해 어떤 가능한 설명이 있습니까? 어디에서 수정 사항을 찾아야 합니까?
우리는 재설정해야 했던 Zyxel ZyWall 방화벽을 사용합니다. 이 동작을 설명할 수 있는 필터가 있습니까?
답변1
서버의 iptables 규칙에는 "최근" 모듈을 사용하여 1분 내에 4번의 시도가 이루어진 후 연결을 끊는 "anti ssh bruteforce" 규칙 체인이 있습니다. 이 규칙에는 INPUT
체인에서 얼굴 IP의 모든 SSH를 허용하는 예외가 있습니다 . 이동하면서 얼굴 IP가 변경되었고 규칙도 조정되어야 했습니다. 참고로 저는 이렇게 했어요
모든 iptables 규칙 나열
# iptables -L --line-numbers
INPUT
(이전) 얼굴 IP 주소로부터의 모든 SSH 연결을 허용하도록 설정된 체인 의 수락 규칙 과 SSH_CHECK
체인에서 여러 번 시도한 후 SSH 연결을 삭제하는 무차별 대입 방지 규칙을 확인하세요.
Chain INPUT (policy ACCEPT)
num target prot opt source destination
...
14 ACCEPT tcp -- old.myISP.com anywhere tcp dpt:ssh
...
Chain SSH_CHECK (1 references)
num target prot opt source destination
...
3 DROP all -- anywhere anywhere recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: RECENT_SSH side: source
규칙 편집/etc/iptables.rules
변화
-A INPUT -s 123.45.67.8/32 -p tcp -m tcp --dport 22 -j ACCEPT
에게
-A INPUT -s 111.222.33.44 -p tcp -m tcp --dport 22 -j ACCEPT
여기서 111.222.33.44는 새 얼굴 IP입니다. 그리고 적용된 규칙을 읽어보세요.
# iptables-restore < /etc/iptables.rules