ACK 패킷의 conntrack NEW: 그것이 증명하지 않는 것
NEW 라벨이 붙은 ACK 는 트래커에 일치하는 상태가 없었다는 뜻이며, VPN 이 세션을 열었다는 뜻이 아닙니다. hook, tuple, 캡처 구간을 읽으세요.
방화벽 로그에 예상하지 못한 줄이 하나 있습니다. ACK 패킷, conntrack 상태 NEW, 내 것이 아닌 출발지 주소, 목적지 포트 열림. 이것을 아무도 승인하지 않은 새 인바운드 연결로 읽고 싶어집니다. 그러나 그 줄이 실제로 말하는 것은 더 좁습니다. 그 패킷이 이 hook 에 도달했을 때 트래커에 일치하는 상태가 없었고, 패킷은 ACK 를 실었습니다. 이것은 서로 다른 두 가지에 대한 두 사실이고, 어느 것도 핸드셰이크의 완전한 기록이 아닙니다. 결론을 내리기 전에 제가 거치는 순서는 다음과 같습니다.
판정이 아니라 패킷에서 시작하라
해석하기 전에 관찰을 분리하세요. TCP 플래그는 이 패킷을 설명하고, 트래커의 상태는 그 hook 에서 무엇을 알고 있었는지 설명하며, 당신의 캡처는 기록한 구간만 설명합니다.
이 셋을 뒤섞는 것이 ACK 를 “제공자가 누군가를 들여보냈다”로 만드는 방식입니다.
hook 에서 NEW 가 실제로 의미하는 것
iptables conntrack 매칭 은 NEW 를 연결을 시작하는 패킷, 또는 양방향 트래픽을 아직 보지 못한 연결에 속한 패킷으로 문서화합니다. ESTABLISHED 는 트래커가 양방향에서 패킷을 보았다는 뜻입니다. 어느 정의도 그 패킷이 SYN 이었다거나 이력 없이 도착했다고 말하지 않습니다.
흐름을 중간부터 관찰하기 시작한 트래커는 다음 패킷을 자신이 아는 것에 비추어 분류하며, 그것이 아무것도 아닐 수 있습니다. 이것은 트래커의 기억에 대한 진술이고, 원격 호스트의 의도에 대한 진술이 아닙니다.
느슨한 추적이 대부분의 ACK 놀라움을 설명한다
커널은 nf_conntrack_tcp_loose을 문서화하며, 이것은 트래커가 시작을 보지 못한 TCP 연결을 받아들이게 합니다. 설정이 기본값이면 흐름 중간의 ACK 가 확립된 흐름으로 채택될 수 있습니다. 끄면 같은 패킷은 NEW 대신 INVALID 로 분류될 가능성이 커집니다. 두 결과 모두 트래커의 규칙을 설명하며, 애플리케이션의 이력을 설명하지 않습니다.
그러니 라벨에 이론을 세우기 전에 그 설정을 확인하세요.
지루한 원인을 이 순서로 배제하라
제가 좇아온 NEW-on-ACK 사건 대부분은 이들 중 하나로 끝났고, 모두 확인 비용이 저렴합니다.
- conntrack 테이블이 비워졌거나 트래커가 재시작되었다.
- 호스트가 재부팅되었거나 흐름이 다른 namespace 나 장치로 옮겨졌다.
- 비대칭 라우팅이 SYN 을 당신이 캡처하지 않는 경로로 내보냈다.
- NAT 가 tuple 을 다시 썼으므로 항목이 더 이상 읽은 내용과 맞지 않는다.
- 캡처가 늦게 시작되어 시작 부분을 한 번도 보지 못했다.
각각은 이전 패킷을 트래커의 시야에서 없애고 이후 패킷은 그대로 둡니다. 재부팅이나 테이블 비우기는 uptime 과 로그로 확인하기 가장 쉽습니다. 비대칭 라우팅은 단방향 캡처로 나타납니다. NAT 는 교활한데, 트래커가 저장한 tuple 이 로그에 찍힌 tuple 이 아니기 때문입니다.
더 나아가기 전에 어느 것을 배제했고 어떻게 했는지 적어 두세요.
tuple, 인터페이스, hook 을 읽어라
conntrack 항목은 주소, 포트, 프로토콜로 키가 정해지므로 어떤 변환이든 어느 항목이 일치하는지를 바꿉니다. 인터페이스와 hook 도 기록하세요. 잘못된 인터페이스에서 또는 다른 체인 뒤에서 본 패킷은 경로가 그림과 같지 않다고 말해 줍니다. 사건이 VPN 과 관련되면, 안쪽 패킷을 보는지 바깥 운반체를 보는지 판단하라. 그다음 같은 다섯 요소 tuple 에 대해 게이트웨이가 기록한 것과 비교하세요.
한 흐름에 대한 상반된 두 시각은 어느 하나만보다 더 많은 것을 알려 줍니다.
언제 에스컬레이션할 가치가 있는가
접근 가능하고 접근 가능해서는 안 되는 서비스를 흐름, 그것을 허용한 정책, 양쪽 끝의 증거와 함께 보여 줄 수 있을 때 에스컬레이션하세요. 상태 라벨 하나나 부분 캡처 하나만으로 제공자 결함을 보고하지 마세요. 그 보고는 방금 읽은 설명과 함께 닫힐 것입니다. 서비스가 정말로 노출되어 있다면 그 경계의 소유자가 고칠 사람이며, 버그보다 위임된 포트 매핑이나 의도하지 않은 리스너가 더 그럴듯한 원인입니다.
그다음 한 패킷이 전체 세션처럼 보이게 한 가시성 구멍을 메우세요.