원격 노트북에서 요청 하나를 따라가면 무언가가 그것을 검사할 수 있기 전에 여러 경계를 지납니다. 바깥 터널은 VPN 프로세스에서 끝나고, 안쪽 패킷은 인터페이스에 나타나며, 안쪽의 HTTPS 세션은 애플리케이션까지 이어집니다. 검사 도구는 패킷이 도달하는 지점에서 보이는 것만 봅니다. 그 지점을 정하지 않고 설치하면 로그는 잘못된 계층을 설명합니다.

패킷 하나가 여러 경계를 지난다

VPN 종료 이전에 관측자는 보통 VPN 포트로 향하며 주소와 크기는 보이지만 내부 구조는 없는 바깥 연결 하나를 봅니다. 종료 이후에는 내부 주소와 포트, 프로토콜이 그것을 넘겨주는 처리 지점에서 사용할 수 있습니다. 애플리케이션 자체의 TLS는 별도 설계가 종료하지 않는 한 암호화된 채로 남습니다. 이는 세 가지 가시성 수준이며, 패키지 이름은 어느 것을 샀는지 알려주지 않습니다.

경계를 표시한 경로를 그리고, 위치가 답의 일부이므로 질문에 답할 수 있는 선 위에 센서를 놓으십시오. 이름 붙일 수 없는 경계는 시험할 수 없는 경계입니다.

각 지점에서 무엇을 읽을 수 있는지 본다

아키텍처에 대한 어떤 설명도 믿기 전에 인터페이스와 짧은 캡처를 확인하십시오.

ip -br link
tcpdump -ni tun0 -c 10 'tcp port 443'

링크 목록은 존재하는 터널과 물리 인터페이스을 보여 주고, 캡처는 그곳에 연결된 센서가 정확히 무엇을 받을지 보여 줍니다. 내부 주소는 보이지만 HTTP 요청 줄이 보이지 않는다면, VPN 종료 이후이면서 아직 애플리케이션의 TLS 밖에 있는 것입니다. 그것은 네트워크 탐지에 알맞은 위치이고 본문 검사에는 잘못된 위치입니다. 다른 경계가 무엇을 드러내는지 비교하려면 바깥 인터페이스에서 캡처를 반복하십시오.

수동 탐지는 스스로 차단할 수 없다

Snort의 검사 문서는 수동 관측과 인라인 동작을 구분합니다. 수동 모드는 그 경로에서 트래픽을 멈추지 않고 경고할 수 있습니다.

snort -T -c /etc/snort/snort.lua

테스트 모드는 센서를 실행하지 않고 구성을 검증하며, 어떤 배포 전에도 올바른 첫 단계입니다. 인라인 동작에는 호환되는 패킷 수집 구성과 그에 맞는 적용 구성이 필요하며, 추가 플래그만으로는 충분하지 않습니다. 따라서 로그 기록은 요청이 막혔다는 증거가 아니며, 인라인처럼 보이는 옵션으로 시작한 프로세스는 실제로 전달되는 흐름이 그를 통과한다는 것을 증명하지 않습니다. 구현이 실제로 패킷을 어디에서 넘겨주는지 확인하십시오.

배포 전에 적용 모드를 고른다

둘은 실패 시 동작이 다르므로 요구 사항이 가시성인지 방지인지 결정하십시오. 죽은 수동 센서는 트래픽을 흐르게 두고 모니터링 공백을 만들지만, 죽은 인라인 장치는 트래픽을 통과시키거나 멈출 수 있으며 그 선택은 의도적이어야 합니다. 허용할 흐름 하나, 거부해야 할 흐름 하나, 센서가 실패할 때 원하는 동작을 합의하십시오. 관리 복구 경로를 검사 대상 경로와 분리해 두어, 센서의 실수가 접근 권한까지 없애지 않게 하십시오.

그다음 보이는 트래픽, 처리 지점, 적용 동작을 기록하십시오. 설치된 패키지가 아니라 이 세 가지 사실이 배포가 실제로 하는 일을 설명합니다.

관련 글