대형 PCAP를 분할하고 문제 해결 컨텍스트를 잃지 않고 하나의 대화 추출

대용량 PCAP 파일은 열기도 어렵고, 공유하기도 어렵고, 검토하기도 어렵습니다. 사용량이 많은 서버, 카메라 게이트웨이, USB-over-IP 연구소 또는 생산 사고로 인한 캡처는 빠르게 기가바이트로 늘어날 수 있습니다. 확실한 해결책은 파일을 분할하거나 하나의 대화를 추출하는 것입니다. 위험은 실패를 설명하는 맥락을 잘라내는 것입니다.

올바른 질문은 "어떻게 PCAP를 더 작게 만들 수 있습니까?"만이 아닙니다. "더 작은 캡처가 여전히 유용하려면 어떤 컨텍스트가 살아남아야 합니까?"입니다.

대규모 캡처를 사용하기 어려운 이유

대규모 캡처는 실질적인 문제를 야기합니다.

• 패킷 분석기 메모리 부족
• 느린 인덱싱
• 포털을 지원하기 위한 업로드가 어려움
• 관련이 없는 민감한 트래픽
• 대화가 너무 많아
• 오랜 시간
• 실제 사건 주변의 중복된 소음

크기별로 분할하면 파일을 관리하기 쉽게 만들 수 있습니다. 대화를 추출하면 증거에 집중할 수 있습니다. 그러나 두 작업 모두 중요한 설정, DNS, ARP, TLS 또는 재전송 컨텍스트를 숨길 수 있습니다.

대화를 추출하려면 5개 이상의 튜플이 필요함

TCP 또는 UDP 대화는 소스 IP, 대상 IP, 포트 및 프로토콜로 식별되는 경우가 많습니다. 좋은 시작이네요. 그러나 문제 해결에는 다음이 필요할 수도 있습니다.

• 연결 전 DNS 조회
• ARP 또는 이웃 검색
• TCP 핸드셰이크
• TLS 핸드셰이크
• ICMP 오류
• 눈에 띄는 실패가 발생하기 전에 재전송
• 관련 제어 채널
• 클라이언트 재시도 후 서버 응답

응용 프로그램 오류 발생 후 패킷만 추출할 경우 수신자는 실제 원인을 놓칠 수 있습니다.

크기별 분할과 시간별 분할

파일 크기별로 분할하는 것은 도구 호환성 및 업로드 제한에 유용합니다. 시간별로 분할하는 것은 인시던트 창에 유용합니다. 대화로 분할하는 것은 집중적인 디버깅에 유용합니다. 각각 장단점이 있습니다.

묻다:

• 수신 도구에 파일 크기 제한이 있습니까?
• 사건 시간 창이 중요합니까?
• 하나의 흐름이 전체 사례를 나타내나요?
• 여러 관련 흐름이 필요합니까?
• 타임스탬프는 원본을 유지해야 합니까?
• 패킷 번호를 보존해야 합니까, 아니면 다시 매핑해야 합니까?

출력에는 어떤 분할 전략이 사용되었는지 문서화되어야 합니다.

원본 패킷 증거 보존

더 작은 파일을 생성할 때 원본 캡처를 그대로 유지하세요. 파생 캡처는 재현 가능해야 합니다. 나중에 지원 팀이 추출된 창 이전에 패킷을 요청하는 경우 원본이 여전히 존재해야 합니다.

유용한 메타데이터:

• 원본 파일 이름 및 해시
• 분할 또는 추출 필터
• 시간 창
• 전후의 패킷 수
• 대화가 포함됨
• 의도적으로 삭제된 패킷
• 출력 파일 해시

이는 "파일을 잘라냈습니다"를 방어 가능한 작업으로 바꿉니다.

PCAP 수술이 적합한 곳

PCAP 수술은 증거 검토 및 통제된 편집을 위해 설계되었습니다. 대규모 캡처 처리가 그 일부입니다. 먼저 검사하고, 두 번째로 최소 출력을 선택하고, 세 번째로 작업을 문서화합니다.

대규모 PCAP 작업 흐름의 경우 PCAP 수술은 다음과 같은 답변을 제공해야 합니다.

• 어떤 대화가 존재합니까?
• 어떤 흐름에 실패가 포함되어 있나요?
• 얼마나 많은 맥락이 그것을 둘러싸고 있습니까?
• 무엇이 추출됐나요?
• 의도적으로 제외된 것은 무엇입니까?
• 파생 캡처를 재생성할 수 있나요?

검색어가 "대형 pcap 분할" 또는 "pcap에서 tcp 대화 추출"인 경우 파일 크기에만 최적화하지 마세요. 여전히 실패를 설명하는 더 작은 캡처에 맞게 최적화합니다.