HADA — 상용 Anti-DDoS 장비 뒤에 Snort를 붙여서 L7 탐지 공백을 메운 이야기

졸업논문으로 시작한 HADA(Hierarchical Anti-DDoS Architecture)가 JKIICE Vol.30 No.7 (2026) 에 실렸습니다. 학부 첫 학술지 논문이라 완성 자체가 목표였는데, 되돌아보면 최종본은 초기 아이디어와 절반쯤 다릅니다.

• DOI: 10.6109/jkiice.2026.30.7.1262
• 저자: 임현빈, 전상훈(교신)
• 대상 학술지: 한국정보통신학회논문지 (KCI 등재)

이 글은 공격 시나리오가 두 번 바뀐 과정과 왜 그렇게 바뀌었는지의 기록입니다.

---

원래 하고 싶었던 것

L3·L4 볼륨 공격은 상용 Anti-DDoS 장비가 잘 막습니다. 문제는 L7 저속 자원 고갈. 정상 요청과 겉으로는 구분이 안 되는데, 서버 리소스는 갉아먹습니다.

상용 장비를 뜯어고칠 순 없으니, 뒤에 Snort IPS를 인라인으로 붙이자. 이게 처음 아이디어였고 최종본까지 살아남았습니다.

살아남지 못한 건 그 뒤였습니다.

---

V5·V6 — Snort를 앞에 두고, 기형 패킷으로 상용 장비 무력화

첫 그림은 이랬습니다.

공격자 → [Snort] → [상용 Anti-DDoS] → 서버

RFC 규격 위반 기형 패킷(Malformed Packet)으로 상용 장비의 Slow Path를 고갈시킬 수 있다는 가설. Snort가 앞에서 걸러주면 상용 장비가 부담 안 함.

문제는 4장(성능 평가)이 표만 있고 결과 자체가 비어 있었다는 점. V6에서 Table 3(RTT/Throughput/HTTP 오버헤드)을 겨우 채웠지만 나머지는 서술만 있고 수치가 없었습니다.

여기서 첫 번째 지적: “Snort가 앞에 있으면 상용 장비의 존재 가치가 뭐냐?” 대답을 못 했습니다.

---

V7 — 시나리오 180도 회전, Snort를 뒤로

공격을 GoldenEye 기반 L7 HTTP Keep-Alive Flooding으로 바꾸고, Snort 배치도 뒤로 옮겼습니다.

공격자 → [상용 Anti-DDoS] → [Snort] → 서버

이러면 상용 장비가 볼륨 공격 흡수, Snort가 통과된 L7 공격 처리. 책임 분리가 명확해집니다.

라즈베리파이 6대로 봇넷 실측을 시작. 그런데 4장에 여전히 “그래프 추가 예정” 플레이스홀더가 남았습니다.

---

V8 — 공격 6종으로 확장, 사전실험으로 3종 선정

봇넷 10대로 증설. 공격을 6종으로 확장:

공격	유형
Hash Collision	연산 자원 부하
RUDY	연결 점유
Slow Read	연결 점유
Invalid Method	연산 자원 부하
Bulk Transaction	처리 부하
Abnormal Status	프로토콜 왜곡

여기서 사전실험으로 상위 3종(Hash Collision, Bulk Transaction, Abnormal Status) 선정.

지표도 정의:

• 시스템 자원 포화도 S
• 보안장비 투과율 R

이제 뭔가 논문처럼 보이기 시작했습니다.

---

V10 — 4종 재정의 + 다기준 우세 분석으로 2종

여기서 진짜 전환이 일어났습니다. V9의 지적은 이거였습니다:

“3종 선정한 기준의 정량적 근거가 없다. 왜 이 셋인가?”

정성적으로 “이게 가장 파괴적으로 보였다”는 답은 통하지 않았습니다. 그래서 V10에서는:

1. 공격을 4종으로 재정의: RUDY, Slow Read, Invalid Method, Abnormal Status
2. 다기준 우세 분석(Multi-Criteria Dominance Analysis) 로 상위 2종 선정
3. 기준: 피크 CPU 사용률, 피크 활성 연결 수, 미탐지율
4. 결과: Invalid Method(연산 자원 부하형) + RUDY(연결 자원 점유형)

이제 “왜 이 둘이냐”에 대해 표로 답할 수 있게 됐습니다. 하나가 자원 종류가 다른 다른 하나에 대해 우세하지 않다면, 둘 다 대표로 남깁니다.

봇넷 10대 산정 근거도 사전실험 수치로 뒷받침. 국문/영문 요약, 키워드, 저자 소속까지 갖춘 학회 투고 형식이 처음으로 완성됐습니다.

---

탐지 규칙 — Flowbits 다단계

Snort 룰의 핵심은 flowbits로 상태를 추적하면서 단계별로 결정하는 구조.

S1 (신호 1) → set flowbit rudy_stage1
S2 (신호 2) → check flowbit rudy_stage1, set rudy_stage2
S3 (신호 3) → check flowbit rudy_stage2, alert + drop

RUDY 룰 예 (구조만):

alert tcp any any -> $HOME_NET 80 (
    msg:"RUDY-S1"; flow:established,to_server;
    content:"Content-Length|3a| "; nocase; dsize:<50;
    flowbits:set,rudy_stage1; flowbits:noalert;
    sid:1000001;
)

alert tcp any any -> $HOME_NET 80 (
    msg:"RUDY-S2"; flow:established,to_server;
    detection_filter:track by_src, count 3, seconds 30;
    flowbits:isset,rudy_stage1; flowbits:set,rudy_stage2;
    sid:1000002;
)

drop tcp any any -> $HOME_NET 80 (
    msg:"RUDY-S3"; flow:established,to_server;
    flowbits:isset,rudy_stage2;
    rate_filter:track by_src, count 1, seconds 10;
    sid:1000003;
)

• S1: 특정 시그니처 처음 등장 시 flowbit만 set (경보 X)
• S2: S1 이후 반복 관찰되면 두 번째 단계로 승격
• S3: 확정. drop.

rate_filter로 최종 drop을 동적으로 조절해서 정상 트래픽 오탐 방지. detection_filter로 진입 문턱 관리. dsize<50으로 저속 공격 특성 활용.

Invalid Method, Abnormal Status에도 같은 구조. 총 flowbits 45줄의 다단계 규칙.

---

실측 결과

공격 트래픽 통과 후:
  - 서버 CPU 부하 감소 (측정치는 논문 표 5)
  - 활성 연결 수 감소
  - RTT / 처리량 변화는 운영상 수용 가능 범위 내

정확한 숫자는 논문 표 참고. 요약: Snort 추가로 인한 오버헤드가 실제 공격 흡수 이득보다 작다는 게 결론.

alert_fast 로그에서 실제 차단 기록:

[drop][1:1000003][RUDY-S3] ...
[1:1000002][RUDY-S2] ...
[1:1000001][RUDY-S1] ...

이게 논문 Table 3~5 만든 원본 로그입니다.

---

심사에서 반복해서 맞은 지적

V5부터 V10까지 지도교수(전상훈 교수님)한테 같은 지적을 여러 번 맞았습니다:

1. 제안 → 결과 매핑 — “제안한 걸 정확히 그 결과가 증명하나?”
2. 비교군 없는 자체 수치 금지 — “이 수치가 좋은 건지 나쁜 건지 비교 대상 없이 어떻게 아나?”
3. 기준 정량 근거 — “선정 기준을 정량적으로 뒷받침해라”
4. subsection 압축 — “4장 하위 절이 너무 많다. 탐지율/리소스사용량 2개로 압축”
5. Table 용어 일관성 — “Attack Type vs Attack Scenario 혼용 금지”
6. Fig.2 실물 사진 — V8→V10까지 미반영

이 중 5·6번은 마감 직전에야 반영. 지적 자체가 복잡하기보다 같은 패턴이 반복되는 게 힘들었습니다.

이후 MECA 논문지 확장에서도 비슷한 패턴이 나와서, 이게 특정 논문 문제가 아니라 제 논문 작성 습관 문제라는 걸 알게 됐습니다.

---

되돌아보며

시나리오는 여러 번 바뀝니다. V5 아이디어를 지키려고 애쓰지 말 걸 그랬습니다. V7에서 앞뒤 순서 뒤집을 때 이미 늦었었고, V10에서 다기준 우세 분석을 들여올 때는 이미 8개월이 지난 뒤였습니다.

정량 근거가 없으면 심사에서 절대 통과 못 합니다. “이 셋이 대표성이 있다”는 주장에는 반드시 “왜 이 셋이 다른 것에 비해 우세한지” 표가 있어야 합니다. 이게 학부 논문의 가장 큰 벽이었습니다.

Flowbits는 얕게 배우면 안 됩니다. set, isset, unset, noalert의 조합이 다단계 탐지의 전부입니다. Snort 매뉴얼에서 flowbits 절을 반복해서 읽는 것 외에는 대체할 방법이 없었습니다.

---

후속

이 논문의 방법론(Snort 계층형 방어) 자체는 완성이지만, 후단 Snort의 부하 한계가 명확한 다음 작업 후보입니다. 봇넷 30대·50대로 늘리면 Snort가 먼저 죽는지, 상용 장비가 먼저 죽는지 — 그 경계가 정의되지 않았습니다.

논문에는 “향후 과제”로만 적어 뒀습니다. 실제로 해볼 지는 미정.

---

서지정보

• 제목: HADA: A Hierarchical Anti-DDoS Architecture for Mitigating L7 Detection Gaps
• 저자: 임현빈, 전상훈
• 저널: 한국정보통신학회논문지 (JKIICE), Vol.30 No.7, pp.1262–1274
• 연도: 2026
• DOI: 10.6109/jkiice.2026.30.7.1262
• KCI: 원문 링크