일부 개인적인 목적을 위해 추가 정보로 HTTP 헤더를 강화해야 합니다(HTTP 서버 측 앱에서 처리함). 기본 아이디어는 수신된 패킷을 수정하여 대상으로 보내고 응답에는 신경 쓰지 않는 것입니다. 매우 단순화된 교통 경로 체계는 다음과 같습니다.
+---+ +------+ +---+
| +<<-----o MDFY +<<------o |
| R | +------+ | S |
| C | | N |
| V | | D |
| o--------------------->>+ |
+---+ +---+
문제는 TCP SEQ/ACK 번호와 관련이 있습니다. TCP 핸드셰이크 후 Sender는 길이가 22로 변경된 Modifier로 4바이트 길이의 패킷을 보낸 다음 패킷이 Receiver에 도착하고 ACK 번호 +23을 보내고 Sender는 +5를 기대합니다. 이로 인해 보낸 사람의 마음이 아프고 세션이 동기화되지 않습니다. 예를 들어 테스트를 위해 netcat을 시도할 때 이러한 현상이 나타납니다. 수정되지 않은 패킷의 경우 데이터 교환 직후 세션이 닫히고 수정된 패킷의 경우 세션이 오랫동안 유지됩니다(실제로는 Ctrl-C를 눌러 중지합니다).
이 상황을 처리하는 쉬운 방법은 없습니다. 중간에 수정된 것처럼 보이면 발신자는 시퀀스 번호의 수정에 대해 아무것도 모르고 자신의 번호에 의존하기 때문에 전체 세션을 수정자에 의해 처리되어야 합니다. 이렇게 하면 성능에 큰 영향을 미치고 복잡성이 증가합니다. 모든 세션의 상태를 유지하고 SEQ/ACK 번호를 유지하기 위해 양쪽에서 들어오는 모든 패킷을 수정해야 하기 때문입니다.
자체 DPI를 작성하는 것 외에는 다른 방법이 없을 수도 있습니까? :-) 모든 지식, 아이디어 및 제안에 감사드립니다.
감사합니다.
답변1
내가 볼 수 있는 유일한 간단한 옵션은 투명 프록시를 사용하는 것입니다.
이 경우 클라이언트는 대상 서버로 요청을 보냅니다. 프록시 서버는 요청을 캡처하고 헤더를 추가하며 대상 서버에 다른 요청을 생성합니다. 대상 서버는 프록시에 응답을 반환한 다음 이를 클라이언트에 반환합니다.
여기서 단점은 서버가 클라이언트의 원래 IP 주소가 아니라 프록시의 IP 주소를 본다는 것입니다.
그런 다음 TCP 수준 MITM 접근 방식의 경우 전체 구현이 필요하지 않도록 필요한 기능을 구현하는 툴킷이 있을 수 있습니다.
답변2
이것은 일종의 중간 NAT처럼 보입니다. 문제는 정확히 절반 정도만 되어 있다는 것입니다.
TCP 패킷 흐름의 한 방향만 MITM할 수는 없습니다. 이와 같은 상황을 정확하게 처리하려면 두 흐름을 모두 처리해야 합니다(표준 NAT는 일반적으로 소스 및 대상 주소/포트에만 관심이 있지만 원칙은 동일합니다. 전송 중에 패킷을 변조하고 싶고 이 변조가 두 끝점 모두에 투명해지도록 하려면 다음을 수행해야 합니다.모든 것오른쪽).
모든 것을 고려하기 시작하면 곧 본격적인 NAT를 갖게 될 것입니다. 그러면 바퀴를 다시 만들 필요가 없으며 원하는 대로 패킷을 조작할 수 있는 구현이 많이 있습니다.
물론 실제 사용 가능한 옵션은 사용 중인 운영 체제 및 라우팅/방화벽 소프트웨어에 따라 달라집니다.