Suricata NAT Instance 기반 IPS/IDS 실습 랩 구축 (4편) : Suricata IPS 실습 – 실제 공격 트래픽으로 탐지 → 차단까지 확인하기

목적

이 편에서는 다음 흐름을 실제 트래픽 기준으로 직접 검증한다.

1. 내 PC에서 발생시킨 공격 요청
2. Suricata가 해당 공격을 Alert으로 탐지
3. 동일 룰을 Drop으로 전환했을 때 실제 통신 차단 확인 : IPS 기능 확인

즉, “룰이 존재한다”가 아니라 “룰이 네트워크 흐름을 실제로 제어한다”는 것을 증명하는 실습이다.

---

전체 실습 구조

1. 공격 테스트 전용 프라이빗 웹서버 구성
2. 공격 유형별 개념 + 취약 엔드포인트
3. 내 PC 브라우저에서 공격 발생
4. Suricata Alert 로그 확인
5. 룰을 Drop으로 전환
6. 동일 공격 재시도 → 차단 확인

---

1. 공격 테스트 전용 프라이빗 웹서버 구성

전제 조건

• 웹서버는 프라이빗 서브넷
• 퍼블릭 접근 ❌
• NAT Instance를 통해서만 외부 통신

ssh 접속 방식은 아래 방식중 선택

• NAT Instance Jump
• SSM
• Bastion

---

2. Apache + PHP 설치 (가볍고 테스트에 적합)

# apt update
# apt -y install apache2 php libapache2-mod-php curl
# systemctl enable apache2
# systemctl start apache2

확인:

# systemctl status apache2

---

3. 테스트용 웹 루트 구성

# cd /var/www/html
# rm -f index.html

3.1 정상 동작 확인용 기본 페이지

# tee /var/www/html/index.php <<'EOF'
<?php
echo "<h1>Suricata IPS/IDS Test Web Server</h1>";
echo "<p>Client IP: " . $_SERVER['REMOTE_ADDR'] . "</p>";
echo "<p>User-Agent: " . $_SERVER['HTTP_USER_AGENT'] . "</p>";
?>
EOF

이 페이지는 정상 HTTP 트래픽 기준선이다.
→ 이 요청에서는 Alert이 발생하면 안 된다.

---

4. 공격 테스트용 취약 엔드포인트 구성

⚠️ 아래 코드는 의도적으로 취약하게 만들었다.
실제 서비스에서는 절대 사용하면 안 된다.

---

4.1 SQL Injection 테스트

공격 개념 요약

SQL Injection은
사용자 입력값이 SQL 구문 일부로 해석되도록 유도하는 공격이다.

Suricata는 다음과 같은 패턴에 즉각 반응한다.

• OR 1=1
• UNION SELECT
• SQL 주석 패턴

취약 페이지 생성

# tee /var/www/html/sqli.php <<'EOF'
<?php
$id = $_GET['id'] ?? '1';
$query = "SELECT * FROM users WHERE id = $id";
echo "Query: $query";
?>
EOF

---

4.2 XSS (Cross-Site Scripting)

공격 개념 요약

XSS는
입력값을 그대로 HTML/JavaScript로 렌더링하게 만드는 공격이다.

Suricata는 다음 문자열을 매우 공격적으로 탐지한다.

• <script>
• alert(
• 이벤트 핸들러(onerror=, onload=)

취약 페이지 생성

# tee /var/www/html/xss.php <<'EOF'
<?php
echo "Input: " . ($_GET['q'] ?? '');
?>
EOF

---

4.3 Command Injection

공격 개념 요약

Command Injection은
웹 요청을 통해 OS 명령을 실행시키는 공격이다.

IPS 기준으로는 즉시 차단 대상에 해당한다.

취약 페이지 생성

# tee /var/www/html/cmd.php <<'EOF'
<?php
$cmd = $_GET['cmd'] ?? 'id';
system($cmd);
?>
EOF

---

5. 내 PC에서 직접 공격 트래픽 발생시키기

모든 공격은 내 PC → NAT Instance → Suricata → 프라이빗 웹서버 흐름으로 발생시킨다.

---

5.1 정상 페이지 확인

내 PC 브라우저에서:

http://<NAT_PUBLIC_IP>/

정상 페이지 출력 확인.

---

5.2 SQL Injection 공격

브라우저 주소창에 직접 입력:

http://<NAT_PUBLIC_IP>/sqli.php?id=1' UNION SELECT 1,version() --

---

5.3 XSS 공격

http://<NAT_PUBLIC_IP>/xss.php?q=<script>alert(1)</script>

---

5.4 Command Injection 공격

http://<NAT_PUBLIC_IP>/cmd.php?cmd=cat /etc/passwd

---

5.5 악성 User-Agent 공격

(명령어)

- mac / linux rlwns
# curl -A "sqlmap/1.7" http://<NAT_PUBLIC_IP>/

- 윈도우 파워쉘 기준
PS C:\Users\User> curl.exe -A "sqlmap/1.7" http://<NAT_PUBLIC_IP>/

---

6. Suricata Alert 로그 확인

Suricata 이벤트 로그 필터링 :

# jq 'select(.event_type=="alert") | .alert.signature' /var/log/suricata/eve.json

모든 이벤트가 아래와 같이 비슷하게 나올 것이다.

---

7. Alert → Drop 으로 전환

앞 단계까지는 Suricata가 공격 트래픽을 정상적으로 탐지(Alert) 하는 것까지 확인했다.
이제 동일한 공격을 실제로 차단(Drop) 하도록 전환한다.

다만, 여기서 중요한 점은
기존 suricata.rules 파일을 직접 수정하지 않는다는 것이다.

suricata.rules 는 suricata-update 실행 시마다 자동으로 덮어쓰기 되므로,
실습과 운영 모두에서 직접 수정 대상이 아니다.

따라서 이 실습에서는
로컬 커스텀 룰 파일(local.rules)을 사용해 Drop 룰을 정의하는 방식으로 진행한다.

---

7.1 Suricata 룰 로딩 구조 확인

먼저 Suricata가 어디에서 룰을 로딩하는지 확인한다.

# grep -nE 'default-rule-path|rule-files' /etc/suricata/suricata.yaml

출력:

이는 Suricata가
/var/lib/suricata/rules 디렉터리를 기준으로 룰 파일을 찾으며,
rule-files 항목에 명시된 파일만 로딩한다는 의미다.

---

7.2 local.rules 파일 생성

Drop 룰을 작성할 로컬 전용 룰 파일을 생성한다.

# touch /var/lib/suricata/rules/local.rules
# chmod 644 /var/lib/suricata/rules/local.rules

이 시점에서는 파일만 존재할 뿐,
아직 Suricata가 이 파일을 읽지는 않는다.

---

7.3 suricata.yaml 에 local.rules 로딩 설정 추가

이제 Suricata에게
local.rules 파일을 룰로 인식하라고 명시적으로 알려줘야 한다.

# vi /etc/suricata/suricata.yaml

아래 항목을 찾는다.

default-rule-path: /var/lib/suricata/rules

rule-files:

그리고 rule-files 아래를 다음과 같이 수정한다.

의미는 다음과 같다.

• suricata.rules : ET 기본 룰 (Alert 위주, 자동 업데이트 대상)
• local.rules : 직접 관리하는 커스텀 룰 (Drop 포함)

local.rules 를 뒤에 배치함으로써,
동일한 조건의 룰이 있을 경우 로컬 룰이 우선 적용된다.

---

7.4 Drop 룰 작성 (local.rules)

이제 실제로 차단할 룰을 작성한다.

# vi /var/lib/suricata/rules/local.rules

SQL Injection 테스트용 Drop 룰 예시

drop http any any -> $HOME_NET any (msg:"LOCAL DROP SQLi UNION SELECT"; content:"UNION SELECT"; http_uri; nocase; sid:9000003; rev:1;)

이 룰은 다음 조건을 만족하면 즉시 패킷을 차단한다.

• HTTP 트래픽
• 요청 내용에 OR 1=1 포함
• 대상이 내부 네트워크($HOME_NET)

---

악성 User-Agent (sqlmap) Drop 룰 예시

drop http any any -> $HOME_NET any (msg:"LOCAL DROP sqlmap User-Agent"; content:"sqlmap"; http_user_agent; nocase; sid:9000002; rev:1;)

---

7.5 룰 문법 검사

룰을 반영하기 전에 반드시 문법 검사를 수행한다.

# suricata -T -c /etc/suricata/suricata.yaml -v

아래와 같은 메시지가 나오면 정상이다.

문법 오류가 발생하면 절대 다음 단계로 진행하지 않도록 한다.

---

7.6 Suricata 재시작

1. 기존 서비스 중지 (systemd 관리 하에 있는 경우 대비)
# systemctl stop suricata

2. 확실하게 프로세스 종료 (수동 실행된 녀석들 정리)
# ps -ef | grep suricata | grep -v grep | awk '{print $2}' | xargs kill -9 2>/dev/null

3. 좀비 파일(PID) 삭제 (재실행 에러 방지)
# rm -f /var/run/suricata.pid

4. 인라인 모드로 백그라운드 실행
# suricata -c /etc/suricata/suricata.yaml -q 0 -D

5. 실행 확인
# ps -ef | grep suricata

---

7.7 Drop 동작 확인

이제 다시 내 PC에서 동일한 공격을 발생시킨다.

1. 브라우저
http://<NAT_PUBLIC_IP>/sqli.php?id=1' UNION SELECT 1,version() --

2. 윈도우 파워쉘
PS C:\Users\User> curl.exe -A "sqlmap/1.7" http://<NAT_PUBLIC_IP>/

결과:

• 브라우저에서 페이지 로딩 실패
• 연결이 중간에 끊기거나 reset

Suricata 로그 확인:

# jq 'select(.event_type=="alert") | .alert.signature' /var/log/suricata/eve.json

---

7.8 정리

이 단계에서 확인한 것은 다음과 같다.

• 공격 트래픽이 Alert 단계에서 관측되었고
• 동일한 조건의 룰을 Drop으로 전환했으며
• 실제 네트워크 흐름이 즉시 차단되었다

즉, Suricata가
단순 IDS가 아니라 인라인 IPS로 정상 동작 중임을 검증한 셈이다.

---

8. 정리

이 실습의 핵심은 다음 한 줄이다.

외부에서 발생한 공격 트래픽이
NAT Instance를 통과해
Suricata 인라인 IPS에 의해
실제로 차단된다.

이제 다음 편에서는 이 트래픽을

• Log 필터링 및 시각화를 하기 위해 ElK stack 설치 가이드에 대한 글이다.

🛠 마지막 수정일: 2025.12.23