소개
문서 팀의 탐지기는 collector.example.test/collect에 대한 모든 POST에 경고합니다. 일부는 허용된 공개 시연입니다. 허용된 통신을 유지하면서 내부 문서 업로드에 경고를 집중해야 합니다.
독립 환경에는 이전 경로 탐지기 broad.rules와 완전한 합성 TCP/HTTP 캡처가 있습니다. 명령은 Analyst 탭에서 실행합니다. 기록된 요청을 보려면 Traffic Reference 탭을 선택합니다. 참조 페이지가 바로 열립니다. 같은 예제는 traffic/requests.txt에도 있습니다. 이전 VM 파일은 필요하지 않습니다. 본문 검사는 이 평문 HTTP 캡처에 적용되며 암호화된 HTTPS에는 적용되지 않습니다.
민감한 문서 맥락 찾기
이 단계에서는 요청 본문 단서가 유용하지만 단독으로 충분하지 않음을 확인합니다. classification=internal은 문서 취급 범주를 나타내는 합성 업무 필드이며 완료 표시가 아닙니다.
이 단계를 시작하려면 실습 인터페이스에서 Analyst 탭을 선택합니다.
Traffic Reference 탭으로 전환하여 요청 본문을 비교한 후 Analyst 탭으로 돌아갑니다. 참조 자료를 읽고 제공된 탐지기로 재생합니다. 명령 옵션은 이전과 같습니다. -S는 지정 규칙만 사용하고 -r은 입력 PCAP, -l은 출력 디렉터리를 지정합니다.
다음 명령을 실행하기 전에 Analyst 탭으로 전환합니다.
cat traffic/requests.txt
mkdir -p broad-output
suricata --runmode single -c suricata.yaml -S broad.rules -r traffic/core.pcap -l broad-output --init-errors-fatal
python3 /opt/c09/read-alerts.py broad-output/eve.json
공개 문서 2개를 포함한 경고 4개가 나옵니다. classification=public은 이 경로에서 공개 시연에 쓸 수 있는 내용입니다. 정책은 메서드, 목적지, 경로, 내부 분류를 조합합니다.
새 버퍼를 익히기 위해 본문만 보는 탐지기를 만듭니다. http.request_body 다음의 content는 바이트가 TCP 패킷에 나뉘어 있어도 재구성한 본문을 검사합니다. 재조립은 엔진이 하며 패킷별 문자열 검색과 같지 않습니다. 분류는 긴 본문의 한 필드이므로 버퍼 전체 경계 조건은 추가하지 않습니다.
이전처럼 여러 줄을 그대로 입력합니다. >는 파일을 덮어쓰고 끝의 RULE은 단독 줄이어야 합니다.
cat > body.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.request_body; content:"classification=internal"; sid:1000001; rev:1;)
RULE
mkdir -p body-output
suricata --runmode single -c suricata.yaml -S body.rules -r traffic/core.pcap -l body-output --init-errors-fatal
python3 /opt/c09/read-alerts.py body-output/eve.json
예상 결과는 Alerts: 9입니다. 승인된 목적지의 내부 문서, PUT, 수집 대상의 다른 경로도 경고합니다. 민감한 단어를 어디서나 찾는 조건은 너무 넓습니다. 결과는 실험으로 보관하며 최종 정책 탐지기로 쓰지 않습니다.
python3 /opt/c09/check.py body.rules body
두 데이터 집합에서 해당 본문을 가진 통신 9개가 일치해야 합니다. 구문 오류는 블록을 다시 작성해 복구할 수 있습니다. 추가된 이벤트로 개수를 혼동하지 않도록 새 출력 디렉터리에서 재시도하세요.
조건을 결합하고 균형 검사하기
이 단계에서는 배운 네 HTTP 필드를 유용한 탐지기로 결합합니다. POST, 정확한 수집 호스트와 업로드 경로를 유지하고 내부 분류 조건을 더합니다.
이 단계를 시작하려면 실습 인터페이스에서 Analyst 탭을 선택합니다.
최종 결과물인 local.rules를 만듭니다. 서로 다른 스티키 버퍼의 조건은 AND로 결합되므로 같은 트랜잭션이 모두 만족해야 합니다. sid:1000001은 고유한 로컬 식별자이며 활성 규칙 하나면 충분합니다.
다음 명령을 실행하기 전에 Analyst 탭으로 전환합니다.
cat > local.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.method; content:"POST"; startswith; endswith; http.host; content:"collector.example.test"; startswith; endswith; http.uri; content:"/collect"; startswith; endswith; http.request_body; content:"classification=internal"; sid:1000001; rev:1;)
RULE
재생 전에 -T로 구문을 검사합니다. 디렉터리와 -l은 구문 검사에도 쓰기 가능한 출력 위치를 제공합니다. 패킷을 읽지 않고 설정과 규칙을 로드합니다. 구문 성공만으로 탐지 품질을 알 수는 없습니다.
mkdir -p syntax-output
suricata -T -c suricata.yaml -S local.rules -l syntax-output --init-errors-fatal
mkdir -p final-output
suricata --runmode single -c suricata.yaml -S local.rules -r traffic/core.pcap -l final-output --init-errors-fatal
python3 /opt/c09/read-alerts.py final-output/eve.json
예상 결과는 Alerts: 2이며 포트는 41002와 41007입니다. 각각 내부 문서가 POST로 미승인 경로에 전송됩니다. 공개 시연, 승인된 업로드, 상태 확인, 다른 메서드와 경로는 조용합니다. 경고는 여전히 action: allowed를 표시합니다. 오프라인 경고는 관찰이며 업로드를 막지 않습니다.
정상 비교 사례를 포함한 회귀 검사기를 실행합니다. 회귀 검사는 변경 후 알려진 탐지 대상과 비대상을 다시 확인합니다. 표시한 데이터와 문서 이름·포트를 바꾼 예제를 깨끗한 출력에서 재생합니다. 과거 이벤트 개수가 아닌 규칙 자체를 검사합니다.
python3 /opt/c09/check.py local.rules final
두 줄 모두 의도한 통신 2개와 비교 통신의 비탐지를 보고해야 합니다. 다시 실행해도 결과와 캡처는 같아야 합니다. 누락은 지나치게 구체적인 조건이나 잘못된 버퍼, 뜻밖의 경고는 빠졌거나 넓은 조건을 의심하세요. local.rules를 다시 작성하고 재시도합니다. 엔진을 끄거나 정상 비교 트래픽을 삭제하지 마세요.
이는 범위가 한정된 정책 탐지기이며 범용 데이터 유출 탐지기가 아닙니다. 큰 본문, 암호화, 인코딩, 다른 프로토콜에는 별도 설계와 검사가 필요합니다. 다음 챌린지는 정책 사실을 바꾸고 같은 네 버퍼를 사용합니다.
요약
경로만 보는 탐지기와 본문만 보는 실험을 비교한 뒤 네 HTTP 필드를 결합했습니다. 깨끗한 출력 디렉터리에서 정상 비교 사례를 포함한 데이터로 규칙을 검사하고 가시성의 한계를 명시했습니다.
