simsong/tcpflowTCP/IP 패킷 역다중화기. 다운로드:
다운로드 디렉토리: http://digitalcorpora.org/downloads/tcpflow/
대부분의 일반적인 GNU/Linux 배포판은 저장소에 tcpflow를 포함하고 있습니다. 따라서 Debian/Ubuntu 등에서는 다음 명령어로 설치할 수 있습니다.
sudo apt-get install tcpflow
Fedora/RedHat/CentOS 등에서는 다음 명령어를 사용합니다.
sudo dnf install tcpflow
그게 전부입니다. 어떤 이유로 이 방법이 충분하지 않다면, 소스에서 빌드할 수 있습니다:
Linux에서 컴파일하려면
필요한 전제 조건이 설치되어 있는지 확인하십시오. 루트 디렉토리에는 호스트 운영 체제에 따라 이를 자동으로 수행하는 스크립트 파일이 있습니다:
CONFIGURE_ARCH_17_8.sh CONFIGURE_FEDORA_18.sh CONFIGURE_FEDORA_26.sh CONFIGURE_UBUNTU_16_04.sh
운영 체제에 따라 다음을 실행하십시오:
# sudo bash CONFIGURE_<YOUROS>.sh
OS를 구성한 후, 다음 명령어로 컴파일 및 설치합니다:
./configure
make
sudo make install
git을 사용하여 개발 트리를 다운로드하려면, --recursive 플래그로 완전한 체크아웃을 수행한 후 bootstrap.sh, configure, make를 실행하십시오:
git clone --recursive https://github.com/simsong/tcpflow.git
cd tcpflow
bash bootstrap.sh
./configure
make
sudo make install
Amazon AMI용 다운로드 및 컴파일:
ssh ec2-user@<your ec2 instance>
sudo bash yum -y install git make gcc-c++ automake autoconf boost-devel cairo-devel libpcap-devel openssl-devel zlib-devel
git clone --recursive https://github.com/simsong/tcpflow.git
sh bootstrap.sh
Fedora Core에서 mingw를 사용하여 Windows용 컴파일:
yum -y install mingw64-gcc mingw64-gcc-c++ mingw64-boost mingw64-cairo mingw64-zlib
mingw64-configure
make
CMake를 사용하려면 자세한 지침: cmake/README.md
일반 사용자(루트가 아님)로 깨끗한 저장소에서:
./bootstrap.sh # ./configure 파일 생성
./configure # tcpflow.spec 파일 생성
rpmbuild -bb tcpflow.spec --build-in-place
specfile과 생성된 RPM 확인:
rpmlint tcpflow.spec
rpmlint ~/rpmbuild/RPMS/x86_64/tcpflow-....rpm
설치:
sudo dnf install ~/rpmbuild/RPMS/x86_64/tcpflow-....rpm
tcpflow는 TCP 연결(플로우)의 일부로 전송된 데이터를 캡처하고, 프로토콜 분석 및 디버깅에 편리한 방식으로 데이터를 저장하는 프로그램입니다. 각 TCP 플로우는 별도의 파일에 저장됩니다. 따라서 일반적인 TCP 플로우는 각 방향에 대해 하나씩 두 개의 파일로 저장됩니다. tcpflow는 저장된 'tcpdump' 패킷 플로우도 처리할 수 있습니다.
tcpflow는 캡처된 모든 데이터를 다음과 같은 형식의 파일 이름으로 저장합니다:
[timestampT]sourceip.sourceport-destip.destport[--VLAN][cNNNN]
여기서: timestamp는 첫 번째 패킷이 관찰된 시간의 선택적 타임스탬프 T는 타임스탬프가 제공되었음을 나타내는 구분자 sourceip는 소스 IP 주소 sourceport는 소스 포트 destip는 대상 IP 주소 destport는 대상 포트 VLAN은 VLAN 포트 c는 여러 연결이 있음을 나타내는 구분자 NNNN은 동일한 [시간]/sourceip/sourceport/destip/destport 조합을 가진 여러 연결이 있을 때의 연결 카운터입니다. 타임스탬프 접두사가 수행될 때 연결 카운팅이 거의 발생하지 않습니다.
다음은 몇 가지 예시입니다:
128.129.130.131.02345-010.011.012.013.45103
위 파일의 내용은 호스트 128.129.131.131 포트 2345에서 호스트 10.11.12.13 포트 45103으로 전송된 데이터입니다.
128.129.130.131.02345-010.011.012.013.45103c0005
128.129.131.131 포트 2345에서 호스트 10.11.12.13 포트 45103으로의 여섯 번째 연결입니다.
1325542703T128.129.130.131.02345-010.011.012.013.45103
2012년 1월 2일 오후 5:19(-0500)에 시작된, 128.129.131.131 포트 2345에서 호스트 10.11.12.13 포트 45103으로의 연결입니다.
128.129.130.131.02345-010.011.012.013.45103--3
VLAN 포트 3에서 관찰된, 128.129.131.131 포트 2345에서 호스트 10.11.12.13 포트 45103으로의 연결입니다.
-F 및 -T 옵션을 사용하여 파일 이름 생성에 사용되는 템플릿을 변경할 수 있습니다. 템플릿에 디렉토리가 나타나면 해당 디렉토리가 자동으로 생성됩니다.
-a 옵션을 사용하면 tcpflow가 HTTP 응답을 자동으로 해석합니다.
출력 파일이 다음과 같은 경우
208.111.153.175.00080-192.168.001.064.37314,
후처리 시 다음과 같은 파일이 생성됩니다:
208.111.153.175.00080-192.168.001.064.37314-HTTP
208.111.153.175.00080-192.168.001.064.37314-HTTPBODY
HTTPBODY가 GZIP으로 압축된 경우 세 번째 파일도 생성될 수 있습니다:
208.111.153.175.00080-192.168.001.064.37314-HTTPBODY-GZIP
이러한 스트림에 대한 추가 정보(예: MD5 해시 값)도 DFXML 파일에 기록됩니다.
tcpflow는 'tcpdump'와 유사합니다. 둘 다 네트워크 또는 저장된 파일에서 패킷을 처리합니다. 그러나 차이점은 tcpflow가 실제 데이터 스트림을 재구성하고 각 플로우를 별도의 파일에 저장하여 나중에 분석할 수 있도록 한다는 점입니다.
tcpflow는 시퀀스 번호를 이해하며 재전송이나 순서에 맞지 않는 전달에도 불구하고 데이터 스트림을 올바르게 재구성합니다. 그러나 현재 tcpflow는 IP 조각을 이해하지 못합니다. IP 조각을 포함하는 플로우는 올바르게 기록되지 않습니다.
tcpflow는 DFXML 형식의 요약 보고서 파일을 출력할 수 있습니다. 이 파일에는 tcpflow 프로그램이 컴파일된 시스템에 대한 정보, 실행 위치, 모든 TCP 플로우(소스 및 대상 IP 주소와 포트, 바이트 수, 패킷 수, (선택적으로) 각 바이트스트림의 MD5 해시)가 포함됩니다.
tcpflow는 LBL 패킷 캡처 라이브러리(ftp://ftp.ee.lbl.gov/libpcap.tar.Z에서 제공)를 사용하므로 'tcpdump'와 같은 프로그램이 지원하는 동일한 풍부한 필터링 표현식을 지원합니다. 대부분의 인기 있는 UNIX 버전에서 컴파일되어야 합니다. 자세한 내용은 INSTALL 파일을 참조하십시오.
tcpflow는 네트워크 패킷 플로우를 이해하고 네트워크 포렌식을 수행하는 데 유용한 도구입니다. 많은 패킷이나 단일 TCP 연결을 보여주는 WireShark와 같은 프로그램과 달리 tcpflow는 수백, 수천 또는 수십만 개의 TCP 연결을 상황에 맞게 보여줄 수 있습니다.
tcpflow의 일반적인 용도는 HTTP 세션의 내용을 드러내는 것입니다. tcpflow를 사용하면 HTTP를 통해 다운로드된 웹 페이지를 재구성할 수 있습니다. '드라이브 바이 다운로드'로 전달된 악성 코드를 추출할 수도 있습니다.
Jeremy Elson은 원래 이 프로그램을 작성하여 문서화되지 않은 네트워크 프로토콜을 사용하는 다양한 프로그램이 보내는 데이터를 캡처하여 해당 프로토콜을 리버스 엔지니어링하려고 했습니다. RealPlayer(및 대부분의 다른 스트리밍 미디어 플레이어), ICQ, AOL IM이 이러한 유형의 애플리케이션에 대한 좋은 예입니다. 나중에 HTTP 프로토콜 분석에 사용되었습니다.
Simson Garfinkel은 1998년 Sandstorm Enterprises를 설립했습니다. Sandstorm은 TCPDEMUX라는 tcpflow와 유사한 프로그램과 NetIntercept라는 다른 버전의 프로그램을 만들었습니다. 이러한 프로그램은 상용 프로그램입니다. Simson이 Sandstorm을 떠난 후 TCP 플로우 재조립 프로그램이 필요했습니다. 그는 tcpflow를 발견하고 유지 관리를 인수했습니다.
버그는 github 이슈 트래커에 제출해 주십시오.
tcpflow는 현재 IP 조각을 이해하지 못합니다. IP 조각을 포함하는 플로우는 올바르게 기록되지 않습니다. IP 조각화는 점점 드문 현상이므로 심각한 문제는 아닌 것으로 보입니다.
tcpflow에 관한 논문을 작성하신다면, 다음 기술 보고서를 인용해 주십시오:
Simson L. Garfinkel [email protected]
저는 계속해서 bulk_extractor, tcpflow, be13_api 및 dfxml을 최신 C++로 포팅하고 있습니다. 표준을 조사한 결과 C++14가 아닌 C++17로 결정했습니다. 17에 대한 지원이 이제 널리 보급되었기 때문입니다. (20은 필요하지 않을 것 같습니다). autotools를 고수하고 있지만 CMake로 전환해야 할 강력한 이유가 있는 것 같습니다. be13_api와 dfxml을 독립 라이브러리로 링크하는 대신 Python 스타일로 포함된 모듈로 유지하고 있습니다. 그러나 이것이 올바른 결정인지 100% 확신하지는 않습니다.
프로젝트는 예상보다 오래 걸리고 있습니다. 일반적인 코드 리팩토링도 함께 진행 중이기 때문입니다. 시간이 많이 걸리는 주요 작업은 파서 옵션 및 구성과 관련된 모든 C++ 객체를 분리하는 방법을 파악하는 것입니다.
tcpflow와 bulk_extractor가 모두 be13_api를 사용하기 때문에, 더 간단한 프로그램인 tcpflow를 사용하여 be13_api를 작동시키는 데 집중하고 있습니다. 현재 약 3/4 정도 진행되었습니다. 2020년 말 이전에 완료할 것으로 예상합니다.
--- Simson Garfinkel, 2020년 10월 18일
감사합니다: