📚 네트워크 · 패킷 분석 › 05. 네트워크 스캔 징후 분석 — 248편
이전 글: 247. Incident Timeline 작성 · 다음 글: 249. Detection → Analysis → Response
1. 개념
네트워크 정찰 Incident 분석은 스캔 이벤트가 단순한 배경 소음이 아니라 대응이 필요한 사건으로 판단되었을 때, 그 범위·영향·원인을 밝히고 대응을 요청하는 과정입니다. 이 글은 247. Incident Timeline 작성에서 만든 가상 시나리오 타임라인을 이어서 분석합니다.
모든 스캔이 사건이 되지는 않습니다. 인터넷에서 오는 스캔 대부분은 기록으로 끝납니다. 정찰이 사건으로 전환되는 일반적인 기준은 다음과 같습니다(조직 절차가 우선).
| 전환 기준 | 이유 |
|---|---|
| 내부 출발지의 내부 대역 스캔 | 경계 안쪽의 정찰 → 침해 후 활동 가능성 |
| 스캔 뒤 같은 행위자의 공격 시도 | 정찰이 실제 공격으로 진행 |
| 중요 자산의 예상 밖 노출 발견 | 스캔 결과가 곧 취약점 |
| 인증 성공이 뒤따름 | 계정 탈취 의심 |
| 여러 출발지의 동시 정찰 | 조직적 활동 가능성 |
2. 동작 원리
정찰 사건 분석의 흐름입니다.
[전환] 스캔 Alert → 전환 기준 충족 → 사건 번호, 최초 근거 기록
↓
[범위] 출발지(단말·사용자), 대상 범위, 기간 확정 → IOC로 과거·다른 구간 재검색
↓
[영향] 열린 포트 / 이후 연결 / 인증 결과 → 성공 흔적 유무
↓
[원인 가설] 출발지는 왜 스캔했는가?
├─ 승인되지 않은 도구 사용(내부 사용자)
├─ 악성코드 감염(자동 확산 준비)
└─ 원격 조종(침해된 단말을 통한 정찰)
↓
[대응 요청] 담당별 분리: 단말 격리·조사 / 정책 수정 / 계정 조치
↓
[보고·개선] 결론, 근거, 탐지 공백, 재발 방지관제 조직의 역할은 보통 탐지·분석·대응 요청이며, 단말 포렌식이나 사용자 면담은 대응 조직·인사 절차와 역할을 나눕니다.
3. 주요 특징
⚠️ 아래 분석은 가상 시나리오를 대상으로 합니다. 값은 형식 예시입니다(값은 환경마다 다름).
247편 가상 시나리오의 핵심 사실은 다음과 같습니다.
| 항목 | 확인된 사실 | 판단 |
|---|---|---|
| 출발지 | 192.168.30.45 = 재무팀 단말(DHCP 기준), 새벽 시간 | 업무 시간 외 내부 출발 |
| 범위 | 서버 대역 38개 호스트, 고유 포트 1,000개, 16분 | 도구의 상위 포트 목록 스캔 모양 |
| 노출 | DB(3306), 파일 서버(445) 응답 | 사용자 단말에서 DB 포트 직접 접근이 허용된 정책 |
| 이후 연결 | 3306 인증 실패 12건, 445 로그온 실패 3건 | 시도, 성공 흔적 없음 |
| 공백 | 02:21~02:45 방화벽 로그 없음 | 해당 구간 활동 판단 불가 |
원인 가설 비교가 이 사건의 핵심입니다. 새벽 시간, 사용자 부재 가능성, 스캔 직후 여러 서비스에 짧은 인증 시도라는 패턴은 자동화된 도구를 가리킵니다. 사용자의 수동 행위인지, 감염된 단말의 자동 활동인지는 네트워크 로그만으로는 확정할 수 없으므로 단말 조사(EDR·프로세스 기록) 를 요청해야 합니다. 보고서에는 "감염"이 아니라 "감염 또는 무단 도구 사용 의심, 단말 조사 필요"로 씁니다.
4. 예시
가상 시나리오의 대응 요청과 보고서 요약 형식 예시입니다(값은 환경마다 다름).
# 형식 예시 — 대응 요청 (담당별 분리)
[단말 담당] 192.168.30.45(PC-FIN-017) 네트워크 격리 검토, 02:00~03:00 실행 프로세스·예약 작업 조사
[방화벽 담당] 사용자 대역 → 서버 대역 3306·445 직접 접근 허용 여부 재검토 (업무 필요 확인)
[DB 담당] 192.168.20.30 인증 실패 계정 목록 확인, 성공 로그인 부재 재확인
[관제] IOC(192.168.30.45 행위 특징)로 다른 사용자 대역 재검색, 격리 전까지 감시 강화# 형식 예시 — 보고서 요약
결론 : 내부 단말의 서버 대역 정찰 및 DB·파일 서버 인증 시도(성공 흔적 없음)
근거 : FW 차단·허용 세션, IDS sid 1001502, DB·파일 서버 인증 로그 (타임라인 첨부)
영향 : 데이터 접근 흔적 없음. 02:21~02:45 방화벽 로그 공백으로 해당 구간 판단 제한
원인 : 단말 조사 결과 대기 (감염 또는 무단 도구 사용 의심)
개선 : 사용자→서버 대역 DB 포트 차단, 내부 스캔 임계치 규칙 유지, 로그 수집기 이중화실습 예시 — 본인 소유 실습 환경에서 같은 행위 특징(고유 포트 다수 × 내부 출발)을 보인 다른 출발지를 찾는 방어 측 명령입니다.
# 내부 출발지별 고유 (목적지, 포트) 수 상위 — 범위 확장 여부 확인
sudo jq -r 'select(.event_type=="flow" and ((.src_ip // "")|startswith("192.168.30.")))
| "\(.src_ip) \(.dest_ip):\(.dest_port)"' /var/log/suricata/eve.json \
| sort -u | awk '{print $1}' | uniq -c | sort -rn | head5. 보안 관점
- 내부 정찰 사건의 가장 큰 교훈은 대개 내부 구간의 과도한 허용입니다. 사용자 단말이 서버의 DB·관리 포트에 직접 닿을 수 있었다는 사실이 스캔 자체보다 중요한 발견입니다(179. Network Segmentation).
- 성공 흔적이 없더라도 로그 공백 구간이 있다면 "침해 없음"으로 단정하지 않고 판단의 한계를 보고서에 적습니다.
- 사용자 관련 조사는 개인정보·인사 절차와 연결될 수 있으므로, 관제 보고서는 관찰된 사실과 기술적 판단에 한정합니다.
6. SOC 관점
관제자가 확인할 질문
- 사건 전환의 근거는 무엇이며 기록되었는가?
- 범위 재검색으로 다른 단말에서 같은 행위가 발견되었는가?
- 성공 흔적(인증 성공, 데이터 전송)은 있는가? 판단할 수 없는 구간은?
- 대응 요청이 담당별로 명확하게 전달되었고, 조치 결과를 확인했는가?
- 원인 가설을 네트워크 로그로 확정할 수 있는 범위를 넘어 단정하지 않았는가?
전환 → 범위(재검색) → 영향(성공 흔적) → 원인 가설
↓
대응 요청(단말·방화벽·DB) → 결과 확인
↓
보고서(결론·근거·영향·원인·개선) → 규칙·정책·수집 개선오탐 주의: 내부 스캔의 상당수는 IT 부서의 자산 조사, 승인된 점검, 새로 도입된 관리 에이전트입니다. 사건으로 전환하기 전에 변경 관리 기록과 점검 일정을 확인하고, 전환 후에도 확인되면 판단을 수정합니다.
7. 핵심 정리
- 내부 출발 스캔, 스캔 뒤 공격 시도, 중요 자산 노출, 인증 성공, 다수 출발지 동시 정찰이 사건 전환 기준입니다.
- 분석은 전환, 범위, 영향, 원인 가설, 대응 요청, 보고·개선 순으로 진행합니다.
- 원인은 네트워크 로그만으로 확정하기 어려워 단말 조사 요청과 함께 "의심"으로 기록합니다.
- 로그 공백 구간은 판단 한계로 명시하고 수집 개선 과제로 연결합니다.
- 내부 구간의 과도한 허용 정책은 스캔 자체보다 중요한 발견인 경우가 많습니다.
