Suricata NAT Instance 기반 IPS/IDS 실습 랩 구축 – 마지막(7편) : Suricata 커스텀 Rule 작성과 검증

가상 공격 테스트와 alert → drop 전환 실습

이번 편에서는 Suricata에서 커스텀 룰을 직접 작성하고,
브라우저 환경에서 가상 공격 트래픽을 재현한 뒤,
alert 탐지 → drop 차단 → ELK 검증까지의 전체 흐름을 정리한다.

공격 시나리오는 아래 두 가지 유형을 다룬다.

• 유형 1: /search 경로의 입력값 (Parameter)을 악용한 웹 공격
• 유형 2: GET 요청 URI 내 UNION 기반 SQL Injection 공격

---

1. 커스텀 룰 관리 구조

1.1 룰 파일 위치

Suricata 패키지 설치 환경(Ubuntu 기준)에서
직접 작성하는 커스텀 룰은 다음 파일을 기준으로 관리한다.

/var/lib/suricata/rules/local.rules

• 자동 업데이트 대상 룰 파일(suricata.rules, emerging.rules 등)은 직접 수정하지 않는다.
• 커스텀 룰은 반드시 별도 파일로 분리한다.

1.2 suricata.yaml 로딩 확인

/etc/suricata/suricata.yaml

default-rule-path: /var/lib/suricata/rules
rule-files:
  - suricata.rules
  - local.rules

---

2. Suricata 룰 문법: 구조와 개념

Suricata 룰은 두 부분으로 구성된다.

1. Rule Header(헤더): 어떤 트래픽(프로토콜/출발지/목적지/포트/방향)에 적용할지 결정
2. Rule Options(옵션): 그 트래픽에서 무엇을 찾을지(HTTP 필드, 문자열, 정규식, 임계치 등) 정의

---

2.1 Rule Header(헤더) 문법

형식:

ACTION PROTO SRC_IP SRC_PORT -> DST_IP DST_PORT

예시:

alert http $EXTERNAL_NET any -> $HOME_NET any

각 구성요소 의미:

• ACTION
  • alert : 탐지만 수행. 트래픽은 통과한다.
  • drop : 인라인 IPS 환경에서 패킷을 차단한다.
    • drop이 의미 있으려면 Suricata가 인라인 모드(NFQUEUE, AF_PACKET IPS 등)로 동작해야 한다.
• PROTO
  • tcp/udp/icmp 같은 L4 프로토콜을 지정할 수도 있고,
  • http처럼 앱레이어 해석이 적용되는 트래픽을 대상으로 쓸 수도 있다.
    • 실무에서는 웹 공격 탐지에서 http를 많이 쓰고, 옵션 쪽에서 http.uri, http.method 등을 결합한다.
• SRC_IP / DST_IP
  • $EXTERNAL_NET, $HOME_NET은 suricata.yaml에서 정의한 변수
  • $EXTERNAL_NET any -> $HOME_NET any는 “외부에서 내부로 들어오는” 트래픽에 집중하는 형태
• SRC_PORT / DST_PORT
  • any로 전체 포트를 대상으로 하거나 특정 포트(80/443 등)로 제한할 수 있다.
  • 다만 HTTP는 80/443만 쓰는 게 아니므로(프록시/내부 포트) 포트 제한을 과하게 걸면 누락이 생길 수 있다.
• 방향(Direction)
  • ->는 “SRC에서 DST로”의 방향
  • 웹 요청 기준으로 클라이언트 → 서버를 의미하도록 설계하는 게 보통이다.

---

2.2 Rule Options(옵션) 문법

옵션은 괄호 안에 키:값; 형태로 나열한다.

(msg:"..."; flow:...; http.uri; content:"..."; sid:...; rev:...;)

옵션은 “실행 순서가 어느 정도 중요”하다.
특히 http.uri; 같은 스코핑 키워드는 “이후 매칭이 어디를 대상으로 하는지”를 바꾼다.

---

2.2.1 msg

msg:"LAB7 A1: Suspicious input pattern in /search";

• 이벤트에 남는 사람이 읽는 설명
• 운영에서는 룰 그룹/목적을 식별하도록 prefix를 통일하면 관리가 쉬워진다.

---

2.2.2 flow:to_server,established

flow:to_server,established;

이 옵션은 오탐을 줄이는 데 도움이 된다.

• to_server
  • 서버로 향하는 요청 방향만 검사한다.
  • 같은 세션의 응답 트래픽까지 검사하면 불필요한 매칭이 늘 수 있다.
• established
  • TCP 3-way handshake가 완료된 세션만 본다.
  • 스캔/반쯤 열린 연결에서 발생하는 잡음을 줄이는 효과가 있다.

---

2.2.3 HTTP 필드 스코핑(http.uri / http.method 등)

예:

http.uri;
content:"/search";

• http.uri;를 선언하면 이후 content, pcre가 URI 문자열 영역을 기준으로 동작한다.
• http.method; content:"POST";는 요청 메서드가 POST인지 확인한다.
• 이 스코핑을 쓰면 “패킷 전체에서 찾기”가 아니라 “필드 단위로 찾기”가 되어 정확도가 확 올라간다.

---

2.2.4 content

content:"/login"; nocase;

• 가장 기본적인 문자열 매칭
• nocase로 대소문자 무시 가능
• 실무에서 content는 “범위 제한/필터 역할”로 많이 쓰인다.
  • 예: /login 경로로 좁히고 그 다음 임계치를 적용한다.

---

2.2.5 pcre (정규식)

pcre:"/union\s+select/Ui";

• 복잡한 패턴 탐지용
• \s+는 공백 1개 이상을 의미한다.
• U는 언그리디, i는 대소문자 무시
• 정규식은 강력하지만 비용이 더 들 수 있으므로, 보통 앞단에 content로 범위를 좁혀둔다.

---

2.2.6 threshold (반복/남용 패턴)

threshold:type both, track by_src, count 10, seconds 60;

• 로그인 시도/스캐너/플러딩처럼 “짧은 시간 반복”에 적합하다.
• 해석:
  • track by_src : 소스 IP별로 카운트
  • count 10, seconds 60 : 60초 동안 10회 이상이면 트리거
  • type both : 발생/리밋 동작 방식(환경 따라 튜닝 가능)

---

2.2.7 classtype / sid / rev

classtype:attempted-admin; sid:1007002; rev:1;

rev : 룰 변경 버전. 룰을 수정할 때마다 올린다.

classtype : 분류. 대시보드에서 그룹핑할 때 유용

sid : 룰 고유 ID. 커스텀은 충돌 방지를 위해 사내 대역 고정

---

3. 실습용 커스텀 룰 작성 (alert 단계)

/var/lib/suricata/rules/local.rules 에 아래 내용 설정

3.1 공격 유형 1(LAB A1) — /search 경로의 입력값
(Parameter)을 악용한 웹 공격

대상 엔드포인트: /search?q=...

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"LAB A1: Suspicious input pattern in /search"; flow:to_server,established; content:"/search"; http_uri; content:".."; http_raw_uri; pcre:"/(\.\.\/|%2e%2e%2f|union\s+select|%75%6e%69%6f%6e\s+%73%65%6c%65%63%74)/i"; classtype:web-application-attack; sid:1007001; rev:2;)

rule 해석:

---

3.2 공격 유형 2(LAB B1) — GET 요청 URI 내 UNION 기반 SQL Injection 공격

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"LAB B1: SQL Injection Attempt"; flow:to_server,established; http.method; content:"GET"; http.uri; content:"union select"; nocase; classtype:attempted-user; sid:1007002; rev:1;)

rule 해석:

---

4. 룰 문법 검사 및 적용

1. rule 문법 검사
# suricata -T -c /etc/suricata/suricata.yaml

2. inline 백그라운드 실행중인 suricata 프로세스 종료
# 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

---

5. 공격 트래픽 테스트

로그 확인 명령어를 터미널에서 먼저 입력한 후 브라우저에서 가상 공격을
시도하도록 한다

5.1 브라우저

주소창 입력:

LAB A1 :
http://<TARGET_IP>/search?q=../../../../etc/passwd     => 결과 404

LAB B1 : 
http://<TARGET_IP>/search?q=1%20union%20select%201,2,3   => 결과 404

---

5.2 로그 확인

LAB A1 :
# tail -f /var/log/suricata/eve.json | grep "1007001"

LAB B1 :
# tail -f /var/log/suricata/eve.json | grep "1007002"

---

5.3 Kibana Dashboard 확인

LAB A1 탐지 :

LAB B1 탐지 :

---

7. alert → drop 전환

공격 유형 2 (LAB B1) — Alert -> drop 전환 : 기존 rule drop 으로 수정

drop http $EXTERNAL_NET any -> $HOME_NET any (msg:"LAB B1: SQL Injection Attempt"; flow:to_server,established; http.method; content:"GET"; http.uri; content:"union select"; nocase; classtype:attempted-user; sid:1007002; rev:1;)

적용:

# ps -ef | grep suricata | grep -v grep | awk '{print $2}' | xargs kill -9 2>/dev/null

# rm -f /var/run/suricata.pid

# suricata -c /etc/suricata/suricata.yaml -q 0 -D

브라우저 창을 새로 띄워서 공격 시도를 하고
kibana dashboard 에서 drop 이벤트 또는 차단 표시를 확인한다.

---

8. 정리

이 시점에서 다음 흐름이 완성된다.

1. 가상 공격 트래픽 재현
2. alert 기반 탐지 검증
3. 룰 drop 전환
4. ELK에서 차단 효과 확인

🛠 마지막 수정일: 2025.12.23