SSH 및 VPN 인그레스 규칙: 허용 목록이 실제로 제어하는 것

규칙을 바꾸기 전에 한 번 연결해 보고 클라이언트가 멈추는지 아니면 즉시 거부되는지 기록하십시오. 그 한 가지 차이가 어느 결정이 패킷을 버렸는지 알려 주고 정책 파일을 읽는 한 시간을 아껴 줍니다. 나머지 경로는 짧습니다. 패킷은 훅을 지나 규칙과 일치하고 리스너에 도달하거나 도달하지 않습니다. 허용 목록은 그 세 가지 사실을 둘러싼 장부일 뿐입니다.

SSH 시도 하나를 입력 훅까지 따라가기

클라이언트는 호스트 주소의 포트 22로 SYN 을 보내고, 커널은 그 패킷이 로컬 서비스용인지 판단합니다. 그렇다면 입력 경로가 실행되고 규칙 집합이 패킷을 받아들이거나 버립니다. 침묵은 리스너가 보기 전에 SYN 이 죽었다는 뜻이고, 빠른 거부는 무언가가 리셋으로 응답했다는 뜻입니다. 서로 다른 규칙에서 나온 서로 다른 판정이며 둘 다 정당한 결과입니다.

다음으로 리스너를 확인하십시오. 없는 서비스를 구할 수 있는 규칙은 없습니다. ss -ltnp 를 실행해 기대하는 포트와 주소 패밀리에 무언가가 묶여 있는지 확인한 다음, 클라이언트에서 ssh -v 를 읽어 어디서 멈추는지 보십시오.

포워딩은 별개의 결정입니다

VPN 서버에서 더 흥미로운 훅은 forward 입니다. 클라이언트 트래픽이 머신에 전달되는 대신 머신을 거쳐 라우팅되기 때문입니다. 자체 VPN 클라이언트만 실행하는 호스트는 다른 사람의 패킷을 전달하는 호스트보다 훨씬 작은 규칙 집합이면 충분합니다. 두 설계를 한 머신에서 섞으면 올바르게 보이지만 아무것도 통과시키지 않는 규칙이 생깁니다.

내부 정책을 별도의 질문으로 쓰십시오. 어떤 클라이언트 주소가 터널을 통해 어떤 목적지에 도달할 수 있는가. 관리 경로, 예컨대 SSH 는 자체 출발지 제한과 함께 입력 경로에 두십시오. 시험 중에 추가한 관대한 forward 규칙은 시험보다 오래 사는 전형적인 결함이므로, 변경 후에는 편집한 한 줄이 아니라 규칙 집합 전체를 검토하십시오. 터널 리스너를 여는 것은 연결된 모든 클라이언트가 호스트를 관리할 권한이 아닙니다.

drop 과 reject 는 동작이며 정책이 아닙니다

기본 체인의 정책은 받아들이거나 버리는 것이며 선택의 전부입니다. nftables 참조 문서 가 그렇게 밝히고 있습니다. reject 는 응답을 고를 수 있는 규칙 동작으로 존재하므로, 이를 정책으로 쓰면 nftables 와 iptables 모두에서 실패합니다. 실제로 drop 은 클라이언트에 아무 정보도 주지 않고, reject 는 조치할 수 있는 오류를 줍니다.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

그 스케치는 붙여 넣을 파일이 아니라 결정의 형태로 읽으십시오. 주소 범위는 예시입니다. SSH 포트에 명시적 reject 를 두면 권한 없는 클라이언트가 타임아웃을 기다리지 않고 곧바로 실패하므로 자신의 디버깅이 짧아집니다. 침묵은 우발적 스캔을 억제하고 권한 있는 사용자에게는 아무것도 알려 주지 않습니다. 서비스마다 선택하고 이유를 적어 두십시오. 그렇지 않으면 다음 사람이 되돌려 놓습니다.

정말로 필요한 제어 트래픽은 남겨 두십시오

모든 ICMP 를 차단하는 것은 경로 MTU 탐색을 깨뜨리는 인기 있는 기본값이며, 증상은 연결이 맺어진 뒤 더 큰 패킷에서 멈추는 것입니다. IPv6 의 이웃 탐색은 자체 ICMPv6 유형에 의존하며, 이를 버리면 어떤 TCP 규칙도 조회되기 전에 링크가 끊깁니다. 둘 다 포괄적 허용이 아니라 이름 붙은 의존성으로 허용 목록에 속합니다. 탐색을 조용히 깨뜨리는 정책은 진단 트래픽을 조금 허용하는 정책보다 나쁩니다.

직접 시작한 연결에는 established 와 related 상태를 허용하고 응답은 상태 추적 엔진에 맡기십시오. 그런 다음 응답 경로가 더 바깥에서 차단되지 않았는지 확인하십시오. 상류에서 나가는 트래픽만 제한하면 호스트를 탓하려던 것과 같은 타임아웃이 생깁니다.

옛 경로를 폐기하기 전에 복구를 증명하십시오

콘솔 세션을 열어 둔 채 변경을 적용하고 다른 터미널에서 완전히 새로운 관리 연결을 여십시오. 기존 세션은 아무것도 증명하지 못합니다. 모든 새 로그인을 차단하는 규칙에서 살아남을 수 있기 때문이며, 이것이 방화벽 작업에서 가장 설득력 있는 가짜 양성이 됩니다. 모니터링 시스템이 호스트를 확인한다면 첫 경고 뒤가 아니라 변경 전에 그 출발지 주소를 추가하십시오. 그다음 큰 패킷과 작은 패킷을 하나씩 시험해 탐색이 여전히 작동함을 보이십시오.

VPN 서비스라면 한 번도 연결한 적 없는 클라이언트에서 반복하십시오. 재개된 세션은 새 세션이 협상해야 할 상태를 재사용할 수 있기 때문입니다. 통과한 정확한 규칙 집합을 체크섬이나 사본과 함께 기록해 두어 나중의 편집을 추측이 아니라 비교로 다루십시오. 규칙 순서를 소유한 사람과 조정하십시오. 앞선 규칙은 당신이 추가한 규칙을 조용히 이깁니다.