📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 294편
이전 글: 293. Web Attack 탐지 · 다음 글: 295. IDS Alert의 Source/Destination 분석
1. 개념
비정상 Network Traffic 탐지는 특정 공격 문자열이 없어도 통신의 모양이 평소와 다르거나 규격에 맞지 않는 트래픽을 찾아내는 것입니다. 감염된 호스트의 C2 통신, 데이터 유출, 내부 확산은 페이로드가 암호화되어 있어도 통신 패턴에 흔적을 남기는 경우가 많습니다.
이상 탐지의 일반 원리는 281. Anomaly Detection에서, 패킷 수준의 비정상 TCP·외부 통신 분석은 03 영역 146. 비정상 TCP Traffic 분석, 147. 외부 비정상 통신 분석에서 다뤘습니다. 이 글은 보안장비가 어떤 조건으로 비정상을 판단하는가를 유형별로 정리합니다.
| 유형 | 탐지 조건(예) | 주로 쓰는 데이터 |
|---|---|---|
| 주기적 통신(Beaconing) | 같은 목적지로 일정 간격 반복 연결, 작은 크기 | 흐름 기록 집계 |
| 포트·프로토콜 불일치 | 443 포트인데 TLS가 아님, 53 포트인데 DNS가 아님 | IDS 프로토콜 식별 |
| 비정상 DNS | 매우 긴·무작위 형태 질의, NXDOMAIN 급증, TXT 질의 급증 | DNS 로그, IDS dns 이벤트 |
| 대량 외부 전송 | 평소 대비 큰 업로드, 업무 외 시간 | 흐름 기록, 방화벽 세션 바이트 |
| 내부 확산 | 워크스테이션 간 SMB·RDP·WinRM, 다수 내부 호스트 접속 | 내부 센서, 방화벽 내부 구간 로그 |
| 드문 목적지 | 조직에서 처음 보는 국가·도메인·ASN | 흐름 기록 + 위협 정보 |
2. 동작 원리
비정상 트래픽은 대부분 규칙 한 줄보다 집계 후 판단으로 탐지됩니다. IDS 규칙은 개별 조건(불일치, 길이)을, SIEM·NDR은 시간에 걸친 패턴(주기, 양)을 담당합니다.
[IDS 센서] [흐름 기록 / 방화벽 세션 로그]
프로토콜 식별·필드 길이·규격 이상 출발지·목적지·포트·바이트·시각
↓ 규칙 Alert (개별 이상) ↓ SIEM·NDR 집계
│ ├─ 간격의 규칙성 (주기 통신)
│ ├─ 바이트 합계 대비 기준선 (유출)
│ └─ 고유 내부 목적지 수 (확산)
└──────────────┬─────────────────────┘
↓
같은 호스트의 여러 신호를 모아 우선순위 결정주기적 통신은 연결 간격의 표준편차가 매우 작은 것을 단서로 봅니다. 다만 악성코드는 간격에 무작위 변동(jitter)을 넣기도 하고, 정상 소프트웨어(업데이트 확인, 모니터링 에이전트)도 규칙적으로 통신하므로, 목적지의 정체 확인이 반드시 뒤따라야 합니다.
3. 주요 특징
- 암호화에도 적용됩니다. 내용 대신 시각·크기·방향·목적지를 보므로 TLS 통신에도 유효합니다.
- 단독 신호는 약합니다. 비정상 신호 하나로 판단하기보다, 한 호스트에 여러 신호가 겹칠 때 우선순위를 높입니다.
- 기준은 조직마다 다릅니다. 개발망의 SSH는 정상이지만 회계 PC의 SSH는 이상입니다. 자산 역할별 기준이 필요합니다.
| 단일 신호 | 함께 나타나면 우선순위가 높아지는 신호 |
|---|---|
| 드문 외부 목적지 | 주기적 통신, 직접 IP 접속, 최근 등록 도메인 |
| 포트·프로토콜 불일치 | 업무 외 시간, 대량 전송 |
| 비정상 DNS 질의 | 같은 도메인 계열로 반복, 이후 TLS 연결 |
| 내부 SMB 접속 증가 | 인증 실패 반복, 관리자 계정 사용 |
4. 예시
IDS 규칙으로 표현할 수 있는 개별 이상 조건의 형식 예시입니다(Suricata 문법, 값은 환경마다 다름, 키워드 지원 여부는 버전별 확인).
# 형식 예시 — 443 포트로 가는 연결인데 TLS로 식별되지 않음
alert tcp $HOME_NET any -> $EXTERNAL_NET 443 (msg:"LOCAL non-TLS traffic to external port 443"; flow:established,to_server; app-layer-protocol:!tls; classtype:bad-unknown; sid:1001801; rev:1;)
# 형식 예시 — DNS 질의 이름이 비정상적으로 긴 경우 (bsize는 Suricata 5 이후)
alert dns $HOME_NET any -> any any (msg:"LOCAL unusually long DNS query name"; dns.query; bsize:>70; threshold:type limit, track by_src, count 1, seconds 300; classtype:bad-unknown; sid:1001802; rev:1;)주기 통신 후보를 흐름 기록에서 확인하는 실습 예시입니다(Suricata flow 이벤트, 본인 소유 실습망 기준).
# 특정 내부 호스트 → 특정 외부 목적지 연결 시작 시각 목록 (간격 규칙성 확인용)
sudo jq -r 'select(.event_type=="flow" and .src_ip=="192.168.10.63" and .dest_ip=="198.51.100.140") | .flow.start' \
/var/log/suricata/eve.json | sort | head -20분석 방법 — 시작 시각이 거의 정확히 같은 간격으로 이어지고, 각 흐름의 바이트 수가 작고 비슷하다면 주기 통신 후보입니다. 첫 규칙은 프로토콜 식별이 끝나기 전 단계나 식별 실패 흐름에서 오탐이 생길 수 있어, 적용 전 pcap 시험이 필요합니다.
5. 보안 관점
- 비정상 트래픽 탐지는 침투 이후 단계(C2, 확산, 유출)를 잡는 핵심 수단입니다. 경계에서 놓친 공격을 내부에서 다시 잡을 기회입니다.
- 공격자는 정상 서비스(클라우드 스토리지, 협업 도구, DNS)를 통신 채널로 써서 비정상을 정상처럼 보이게 합니다. 목적지 도메인만으로 신뢰하지 않습니다.
- 내부 구간에 센서나 흐름 기록이 없다면 내부 확산은 보이지 않습니다. 탐지 범위 설계에 내부 동서 트래픽을 포함합니다.
6. SOC 관점
관제자가 비정상 트래픽 Alert를 볼 때 확인할 질문
- 출발지 호스트의 역할에 비추어 이 통신은 설명되는가?
- 목적지는 누구인가? 도메인·인증서·소유 조직, 처음 보는 목적지인가?
- 같은 호스트에 다른 신호(시그니처 Alert, 인증 실패, 호스트 이벤트)가 겹치는가?
- 언제 시작되었는가? 시작 시점 직전에 이 호스트에서 무슨 일이 있었는가?
비정상 트래픽 Alert
↓ 호스트 역할·담당자 확인
↓ 목적지 정체 확인 (도메인·인증서·평판)
↓ 같은 호스트의 다른 신호 결합
설명됨 → 기준 예외 등록 (사유·기한)
설명 안 됨 → 시작 시점 역추적 → 호스트 조사 요청 → 사건 분석 전환오탐 주의: 백업·동기화, 소프트웨어 업데이트, 원격 지원 도구, 보안 에이전트 자체의 통신은 주기적이거나 대량인 경우가 많습니다. 조직 표준 소프트웨어의 통신 목적지 목록을 관리하면 판단이 빨라집니다. 출발지·목적지 분석은 295. IDS Alert의 Source/Destination 분석에서 이어집니다.
7. 핵심 정리
- 비정상 트래픽 탐지는 공격 문자열 대신 통신의 주기·크기·방향·프로토콜 일치 여부·목적지를 기준으로 합니다.
- IDS 규칙은 포트·프로토콜 불일치나 필드 길이 같은 개별 이상을, SIEM·NDR 집계는 주기·양·확산 패턴을 담당합니다.
- 암호화 트래픽에도 적용할 수 있지만 단독 신호는 약하므로 여러 신호의 결합으로 우선순위를 정합니다.
- 기준은 자산 역할별로 달라야 하며, 정상 소프트웨어의 통신 목록이 오탐을 줄입니다.
- 내부 구간의 센서·흐름 기록이 없으면 내부 확산을 탐지할 수 없습니다.
