📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 157편
이전 글: 156. IDS란 무엇인가 · 다음 글: 158. Load Balancer란 무엇인가
1. 개념
IPS(Intrusion Prevention System, 침입 방지 시스템) 는 공격 징후를 탐지하는 데서 그치지 않고 해당 트래픽을 실시간으로 차단할 수 있는 장비입니다. 차단하려면 트래픽이 장비를 반드시 통과해야 하므로, IPS는 경로 위(인라인, In-line) 에 놓입니다.
156. IDS란 무엇인가가 복사본을 보는 "관찰자"라면, IPS는 통로 한가운데 선 "검문소"입니다. 이 글은 장비와 배치 수준만 다루며, IDS·IPS의 탐지 방식 비교와 차단 규칙, IPS Alert 분석은 06 영역 276. IPS란 무엇인가·277. IDS와 IPS 비교·284. IPS Alert에서 다룹니다.
| 항목 | IDS | IPS |
|---|---|---|
| 배치 | 대역 외(SPAN·TAP) | 인라인(경로 중간) |
| 트래픽 | 복사본 분석 | 원본을 받아 검사 후 전달 |
| 대응 | Alert 생성 | Alert + 패킷 폐기·세션 차단 |
| 장비 장애 영향 | 탐지 공백만 발생 | 설정에 따라 통신 단절 가능 |
| 오탐의 영향 | 불필요한 Alert | 정상 서비스 차단 |
2. 동작 원리
IPS는 보통 L2 브리지처럼 두 구간 사이에 끼워 넣습니다. 양쪽 장비의 IP 설정을 바꾸지 않고 삽입할 수 있어서입니다.
[경계 방화벽] ── 포트 A ┐
│ [IPS] 수신 → 검사 → 판정
[코어 스위치] ── 포트 B ┘ ├─ 정상 → 반대 포트로 전달
└─ 위협 → 폐기(Drop) / 세션 Reset + Alert인라인 장비에는 장애 시 동작이라는 설계 문제가 따라옵니다.
| 방식 | 장애 시 동작 | 선택 기준 |
|---|---|---|
| Fail-open | 검사 없이 트래픽을 통과 | 가용성 우선 (서비스 중단을 피함) |
| Fail-closed | 트래픽 차단 | 보안 우선 (검사 없는 통과를 막음) |
| 하드웨어 바이패스 | 전원·장애 시 포트가 물리적으로 직결 | 전용 NIC·바이패스 스위치로 구현 |
많은 IPS는 같은 장비를 모니터 모드(탐지만) 로도 운영할 수 있습니다. 새 규칙이나 새 장비를 도입할 때 먼저 모니터 모드로 오탐을 확인하고, 이후 차단 모드로 전환하는 방식이 일반적입니다.
3. 주요 특징
| 배치 위치 | 목적 | 고려 사항 |
|---|---|---|
| 경계 방화벽 안쪽 | 방화벽이 허용한 트래픽 속 공격 차단 | 가장 일반적인 위치, 검사 대상이 줄어 부하 감소 |
| DMZ 앞 | 공개 서버 보호 | 웹 공격은 WAF와 역할 분담 |
| 내부 구간 사이 | 사용자망 → 서버망 확산 차단 | 내부 트래픽 양이 많아 처리 성능 중요 |
| NGFW 내장 기능 | 방화벽과 IPS를 한 장비에서 | 장비 부하, 기능별 로그 위치 확인 필요 |
IPS 로그에서 관제자가 가장 먼저 보는 것은 조치(Action) 값입니다. 필드 이름은 제품마다 다르며, 아래는 형태 예시입니다.
| 조치 값(예) | 의미 | 관제 해석 |
|---|---|---|
| alert / allowed | 탐지했지만 통과 | 모니터 모드이거나 탐지 전용 규칙, 영향 확인 필요 |
| drop / blocked | 패킷 폐기 | 차단 성공 여부와 재시도 확인 |
| reset | TCP RST 전송으로 세션 종료 | 양쪽에 RST가 보일 수 있음 |
Suricata의 EVE JSON 로그에서는 alert.action 필드가 allowed 또는 blocked로 기록됩니다.
4. 예시
실습 예시 — 두 VMware 네트워크 사이에 Linux 브리지 VM을 두어 "인라인 위치"를 만드는 구성입니다. 이 위치에 Suricata 같은 엔진을 IPS 모드로 올리면 인라인 검사가 가능해집니다(Suricata는 Linux에서 NFQUEUE 방식이나 AF_PACKET 인라인 방식을 지원하며, 설정은 194. Suricata과 06 영역에서 다룸). IP·인터페이스는 예시(값은 환경마다 다름)입니다.
[방화벽 VM LAN 192.168.10.1] ── VMnet2 ── ens37 [IPS 역할 VM: br0] ens38 ── VMnet4 ── [서버 VM 192.168.10.21]
같은 서브넷 192.168.10.0/24 — IPS VM은 IP 없이 중간에 삽입# IPS 역할 VM (Rocky/Ubuntu 공통): 두 NIC를 브리지로 묶어 경로 중간에 삽입
sudo ip link add br0 type bridge
sudo ip link set ens37 master br0
sudo ip link set ens38 master br0
sudo ip link set ens37 up; sudo ip link set ens38 up; sudo ip link set br0 up
# 서버 VM에서: 게이트웨이(192.168.10.1)까지 통신이 IPS VM을 거치는지 확인
ping -c 3 192.168.10.1
# IPS 역할 VM에서: 브리지를 통과하는 트래픽 관찰
sudo tcpdump -ni br0 icmp -c 6"장애 시 동작"은 IPS 역할 VM의 브리지를 내려 보는 것으로 확인할 수 있습니다. 소프트웨어 구성에는 하드웨어 바이패스가 없으므로, 브리지가 멈추면 서버 VM의 통신이 끊기는 Fail-closed와 같은 결과가 됩니다.
sudo ip link set br0 down # 서버 VM의 ping이 실패하는지 확인
sudo ip link set br0 up📷 [실습 화면 삽입 위치] 브리지를 내린 순간 서버 VM의 ping이 끊기고, 다시 올린 뒤 복구되는 두 터미널 화면
5. 보안 관점
- IPS의 오탐은 곧 장애입니다. 정상 업무 트래픽이 차단될 수 있어 차단 규칙은 검증 후 단계적으로 적용합니다.
- IPS 처리 성능이 부족하면 지연·드롭이 생깁니다. 이 때문에 일부 트래픽을 검사 예외로 두는 경우가 있는데, 예외 구간은 공격자가 노릴 수 있는 틈이 됩니다.
- 암호화 트래픽은 IDS와 마찬가지로 내용 검사가 제한됩니다.
- IPS 장비의 우회 경로(이중화 회선 중 한쪽에만 IPS가 있는 경우 등)가 없는지 구성을 확인합니다.
6. SOC 관점
관제자가 확인할 질문
- 이 IPS 이벤트의 조치는 차단인가, 탐지만인가? 장비가 모니터 모드로 운영 중이지는 않은가?
- 차단된 뒤 같은 출발지에서 다른 방식·다른 포트로 재시도가 이어졌는가?
- 사건 시각에 IPS 장애·바이패스 전환 로그가 있었는가? 있었다면 그 시간 동안은 검사 없이 통과했을 수 있습니다.
- 사용자 불편 신고(접속 불가)가 IPS 차단 이벤트와 시간상 겹치지 않는가?
IPS 이벤트 수신
↓ action 확인
blocked → 재시도·우회 시도 여부 확인 → 필요 시 방화벽 차단 등록 검토
allowed → 서버·호스트 영향 확인 → 오탐/정탐 판단오탐 주의: "blocked"라고 해서 공격이 실제로 위험했다는 뜻은 아닙니다. 이미 패치된 취약점을 노린 요청이나 오탐 규칙에 걸린 정상 요청일 수 있습니다. 판단 방법은 285. False Positive에서 다룹니다.
7. 핵심 정리
- IPS는 탐지에 더해 트래픽을 차단할 수 있는 장비이며, 이를 위해 경로 중간(인라인)에 놓입니다.
- 인라인 장비이므로 Fail-open·Fail-closed·하드웨어 바이패스 같은 장애 시 동작을 설계해야 합니다.
- 모니터 모드로 오탐을 확인한 뒤 차단 모드로 전환하는 방식이 일반적입니다.
- IPS 로그의 핵심은 조치(Action) 값이며, 차단·탐지·세션 리셋을 구분해 해석합니다.
- 실습 예시로 Linux 브리지 VM을 경로 중간에 두면 인라인 위치와 장애 영향을 확인할 수 있습니다.
