게이트웨이인가 전달된 클라이언트인가? 소스 주소 읽기

웹 서버는 하나의 주소를 기록하고, 모두가 그것이 게이트웨이 자체 프로세스의 것이라고 가정합니다. 번역 단계에서 사설 주소가 사라진 전달된 클라이언트의 것일 수 있습니다. 목적지는 보이는 네트워크 소스만 보고 그 이상은 보지 않습니다. 이것은 경계에 대한 진술이며, 출처를 결코 확립할 수 없다는 주장이 아닙니다.

목적지가 실제로 보는 것

10.20.0.7의 클라이언트, 외부 주소가 198.51.100.10인 게이트웨이, 인터넷의 목적지를 가정합니다. 게이트웨이가 클라이언트의 소스를 번역하면 목적지의 소켓은 198.51.100.10을 기록합니다. 사설 주소는 패킷에서 사라지고, 목적지는 그 헤더에서 다시 읽을 수 없습니다. 이 숫자들은 예시이며 여러분의 네트워크에서 캡처한 것이 아닙니다.

관찰은 여전히 유용하며, 목적지가 허용하거나 차단해야 할 네트워크 소스를 식별합니다. 다만 그 뒤에 있는 사람이나 프로세스를 식별하지는 않습니다. 목적지 운영자에게 이 구분은 차단이 네트워크 결정인지 계정 결정인지를 가릅니다.

번역 상태는 목적지에 보이지 않습니다

게이트웨이는 번역된 연결과 원래 클라이언트 사이의 매핑을 유지하며, 목적지에 없는 것이 바로 그 상태입니다. 전통적인 NAT 설명은 번역 기록을 나중에 보이는 헤더와 분리합니다. 한쪽을 읽는다고 다른 쪽이 주어지지는 않습니다.

설계가 다르면 증거도 다릅니다. 소스 주소가 보존된 라우팅 트래픽은 클라이언트의 실제 주소를 보여 주지만, 애플리케이션 프록시는 연결을 종료하고 새 연결을 만듭니다. 보존 소스 경로는 또한 클라이언트 주소가 목적지에서 역으로 라우팅될 수 있어야 하며, 모든 배포가 이를 제공하지는 않습니다. 로그 한 줄을 해석하기 전에 어떤 설계가 배포되었는지 물어보십시오.

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

TTL과 지문은 단서이지 증거가 아닙니다

IPv4의 TTL은 송신자가 선택한 초기 값과 패킷이 지난 홉 수에 따라 달라집니다. 두 사실이 없으면 값만으로 VPN 홉이 발생했다고 증명할 수 없습니다. 알려진 추가 라우팅 홉도 LAN 라우터, 터널 경로 또는 다른 전달 배치를 구분하지 못합니다. TTL 차이를 결론이 아니라 질문으로 다루십시오.

다른 신호도 같은 방식으로 작동합니다. User-Agent 헤더는 애플리케이션이 설정할 수 있고, 시간 유사성은 공유된 사람이 아니라 공유된 인프라를 반영할 수 있습니다. 여러 사용자가 하나의 출구를 공유할 수 있고, 한 사용자가 세션 사이에 경로를 바꿀 수 있습니다. 함께 모으면 여러 약한 신호가 게이트웨이 기록을 더 자세히 볼 근거가 될 수 있지만, 쌓인다고 강한 증거가 되지는 않습니다.

주소가 아니라 신원으로 권한을 부여하십시오

목적지가 게이트웨이 관리를 원격 사용자 활동과 분리해야 한다면, 그 역할에 별도의 인증된 신원과 허용된 작업을 부여하십시오. 공유된 공개 소스는 여전히 네트워크 제한으로 기능할 수 있지만, 사용자나 기기의 인증을 대체하지는 않습니다.

증거를 라벨과 함께 보관하십시오: 관찰된 소스, 인증된 계정, 시점, 그리고 검토 중인 추론. «여기에는 내부 소스가 보이지 않는다»를 «어디에서도 귀속이 불가능하다»로 번역하지 마십시오. 몇 달 후 조사에 참여하지 않은 사람이 기록을 읽을 때 라벨이 중요합니다.

관찰 날짜와 그것을 생성한 시스템을 기록하십시오. 귀속이 없는 로그 발췌는 나중에 방어하기 어렵습니다.