소개
문서 팀은 보통 docs.approved.test에 파일을 업로드합니다. 작은 캡처에는 다른 목적지로의 업로드도 있습니다. 이 합성 통신을 위한 오프라인 탐지기를 만들 권한이 주어졌습니다.
패킷 캡처(PCAP)는 네트워크 패킷을 저장합니다. Suricata는 HTTP 요청을 재구성하고 탐지 규칙을 검사합니다. 여기서는 파일을 읽으며 해당 호스트에 접속하지 않습니다. 이름과 문서는 모두 가상입니다. 평문 HTTP여서 본문을 볼 수 있지만, 암호화된 HTTPS를 읽는 방법을 보여 주는 것은 아닙니다.
명령은 Analyst 탭에서 실행합니다. Traffic Reference 탭을 선택하면 traffic/requests.txt와 같은 준비된 요청을 보여 주는 참조 페이지가 바로 열립니다. 기록된 예제이며 실시간 토폴로지가 아닙니다. 기본 터미널 입력과 탭 전환만 알면 되며 IDS 경험은 필요하지 않습니다.
업로드 요청 알아보기
이 단계에서는 정상 업로드를 포함한 POST 요청을 찾는 첫 규칙을 만듭니다. 경고는 규칙 일치이며 침해의 증거가 아니고 트래픽을 차단하지도 않습니다.
이 단계를 시작하려면 실습 인터페이스에서 Analyst 탭을 선택합니다.
HTTP는 요청과 응답 프로토콜입니다. 메서드는 요청 작업을 나타냅니다. POST는 내용을 보내고 GET은 리소스를 요청합니다. Host 헤더는 대상 사이트, URI는 경로, 본문은 제출한 문서 필드를 담습니다. Traffic Reference 탭으로 전환하여 브라우저에서 준비된 HTTP 교환을 확인합니다. 이 페이지는 실시간 패킷 모니터가 아닌 참조 자료입니다. 이후 Analyst 탭으로 돌아가 같은 교환을 읽고 아래 모든 명령을 실행합니다. cat은 파일을 출력하며 경로는 파일의 위치를 나타냅니다.
다음 명령을 실행하기 전에 Analyst 탭으로 전환합니다.
cat traffic/requests.txt
docs.approved.test로 가는 정상 POST, 수집 대상의 GET, classification=internal을 포함한 POST를 비교하세요. 조직은 승인된 문서 서비스에 내부 문서를 보내는 것을 허용합니다. 수집 경로에는 공개 시연 문서를 보낼 수 있지만 내부 문서는 허용하지 않습니다. 목적지와 내용을 함께 판단해야 하며 낯선 호스트 이름만으로는 증거가 되지 않습니다.
Suricata 규칙은 헤더와 괄호 안의 옵션으로 이루어집니다. alert http는 분석된 HTTP에 대한 경고를 선택합니다. 두 쌍의 any any는 모든 출발지/목적지 주소와 포트를 허용하고 ->는 출발지에서 목적지 방향입니다. flow:established,to_server는 연결된 클라이언트의 요청으로 제한합니다. 세미콜론은 옵션을 끝냅니다. msg는 일치 설명, sid는 숫자 서명 식별자, rev는 개정 번호입니다. 각 규칙은 고유한 sid를 씁니다.
스티키 버퍼는 뒤따르는 content가 검사할 HTTP 필드를 선택합니다. http.method는 메서드입니다. content:"POST"로 문자열을 찾고 startswith와 endswith로 부분 문자열이 아닌 필드 전체를 일치시킵니다. 아래 규칙을 사용하세요.
cat > method.rules는 기존 내용을 덮어써 파일을 만듭니다. <<'RULE'은 여러 줄을 그대로 입력하기 시작하며 마지막 RULE은 한 줄에 단독으로 있어야 합니다. 간단한 편집 방법이며 오타가 나면 전체 블록을 다시 실행하면 됩니다.
cat > method.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.method; content:"POST"; startswith; endswith; sid:1000001; rev:1;)
RULE
캡처를 재생합니다. mkdir -p는 출력 디렉터리를 만들며 이미 있어도 괜찮습니다. --runmode single은 패킷 처리 스레드 하나를 사용합니다. -c는 설정, -S는 지정한 규칙 파일만 로드, -r은 PCAP 읽기, -l은 출력 위치입니다. --init-errors-fatal은 규칙을 로드할 수 없으면 중지합니다. 준비된 설정은 각 요청 본문의 최대 64 KB를 검사하며 모든 예제가 범위 안에 있습니다. 실제 배포의 제한은 별도 평가가 필요합니다.
mkdir -p method-output
suricata --runmode single -c suricata.yaml -S method.rules -r traffic/core.pcap -l method-output --init-errors-fatal
python3 /opt/c09/read-alerts.py method-output/eve.json
오프라인 파일 끝에서 Suricata가 중지 메시지를 내는 것은 정상입니다. eve.json은 이벤트마다 JSON 객체를 저장합니다. JSON은 이름 있는 필드를 쓰며 event_type: alert는 일치, signature_id는 규칙, HTTP 필드는 요청을 식별합니다. 제공된 Python 읽기 도구는 경고별 출발지 포트, 메서드, 호스트, URI, 서명 ID를 출력합니다. 출발지 포트는 참조 목록과 연결하는 값이며 정책 조건이 아닙니다.
예상 결과는 Alerts: 10입니다. 정상 문서 POST와 수집 대상 POST가 모두 나타나며 GET과 PUT은 조용합니다. 의도적으로 넓은 첫 탐지기로 메서드 일치를 배웁니다.
제공된 검사기는 수정하지 않은 규칙을 두 개의 작은 독립 데이터 집합에 대해 임시 출력 디렉터리에서 실행합니다. 저장한 로그를 무시하며 규칙과 캡처를 바꾸지 않습니다. 첫 메서드 탐지기를 검사하세요.
python3 /opt/c09/check.py method.rules method
두 줄 모두 의도한 통신 10개가 일치했다고 나와야 합니다. 구문 오류가 나면 따옴표, 세미콜론, 닫는 괄호를 비교하고 다시 작성하여 재시도하세요. 같은 출력 디렉터리에서 재생하면 이벤트가 추가되므로 개수를 비교할 때는 새 디렉터리를 사용합니다. 검사기는 항상 깨끗한 출력에서 시작합니다.
수집 대상 목적지 선택하기
이 단계에서는 메서드와 호스트 조건을 결합해 정상 문서 서비스 업로드를 제외합니다. 한 규칙의 여러 버퍼는 같은 HTTP 트랜잭션에서 모두 일치해야 합니다.
이 단계를 시작하려면 실습 인터페이스에서 Analyst 탭을 선택합니다.
목적지 사이트 이름은 본문 검색이 아닌 http.host에 넣습니다. 문서가 수집 대상을 언급해도 그곳에 전송한 것은 아닐 수 있습니다. Suricata는 호스트 버퍼를 소문자로 정규화합니다. 참조의 collector.example.test.other.test는 다른 호스트이며 필드 전체 일치로 구별합니다.
첫 탐지기를 비교용으로 보관하고 새 파일을 만드세요. 헤더와 메서드 조건은 유지하며 호스트 버퍼로 목적지 조건을 추가합니다.
다음 명령을 실행하기 전에 Analyst 탭으로 전환합니다.
cat > destination.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; sid:1000001; rev:1;)
RULE
mkdir -p destination-output
suricata --runmode single -c suricata.yaml -S destination.rules -r traffic/core.pcap -l destination-output --init-errors-fatal
python3 /opt/c09/read-alerts.py destination-output/eve.json
예상 결과는 Alerts: 6입니다. 승인된 서비스와 비슷한 이름의 호스트는 사라집니다. 아직 경로를 구별하지 않으므로 /status와 /collect-backup에 대한 POST는 일치합니다. 이는 조사하려는 동작 밖에서 발생한, 파악된 오탐입니다.
python3 /opt/c09/check.py destination.rules destination
두 데이터 집합 모두 메서드와 호스트가 맞는 통신 6개가 일치해야 합니다. 허용한 호스트에도 경고가 나면 호스트 내용 뒤의 startswith; endswith;를 확인하세요. 저장된 JSON 이벤트를 고쳐도 탐지기는 고쳐지지 않습니다. 규칙을 바꾸고 다시 재생하세요.
탐지를 업로드 경로로 제한하기
이 단계에서는 남아 있는 내용상의 한계를 이해하면서 경로 탐지기를 완성합니다. URI는 /collect 같은 요청 경로이며 호스트와 다릅니다.
이 단계를 시작하려면 실습 인터페이스에서 Analyst 탭을 선택합니다.
http.uri와 필드 전체 일치로 정확히 /collect를 선택합니다. /collect-backup은 다른 경로입니다. 상태 확인과 정상 목적지에 경고하지 않도록 메서드와 목적지 제한을 유지하세요.
다음 명령을 실행하기 전에 Analyst 탭으로 전환합니다.
cat > upload.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; sid:1000001; rev:1;)
RULE
mkdir -p route-output
suricata --runmode single -c suricata.yaml -S upload.rules -r traffic/core.pcap -l route-output --init-errors-fatal
python3 /opt/c09/read-alerts.py route-output/eve.json
예상 결과는 Alerts: 4이며 포트는 41002, 41003, 41007, 41011입니다. 참조에서 본문을 비교하면 내부 문서 2개와 공개 시연 문서 2개입니다. 모두 선택한 호스트와 경로에 대한 POST입니다. 경로 감시는 되지만 민감한 업로드 수를 과장합니다.
python3 /opt/c09/check.py upload.rules route
두 데이터 집합에서 의도한 경로 통신 4개가 일치해야 합니다. 검사기는 문서 이름과 출발지 포트도 바꿉니다. 이런 부수적인 값으로 탐지를 결정하면 안 됩니다. 경고를 공유할 때 규칙의 목적을 설명하세요. 다음 실습에서는 새 환경에서 문서 맥락을 더해 잡음 감소를 검사합니다.
요약
실제 Suricata 재생으로 메서드, 목적지, 경로 탐지기를 만들었습니다. 경고를 기록된 요청과 연결하고, 민감한 업로드를 탐지한다고 주장하기 전에 공개 문서의 오탐을 확인했습니다.
