유나의 네트워크 탐험일지

58회 기출문제 2 (SQL)

YYUNA — Thu, 6 Aug 2026 22:02:59 +0900

**문제출처: https://yunamom.tistory.com/397 **

1. 문자열 처리함수

Oracle 기준

TRIM: 앞뒤의 x를 제거, SQL
RTRIM: 오른쪽 끝의 x만 제거, SQL
REPLACE: 인수 3개인데 마지막인수 생략 시 빈문자열로 대체 = 문자열 전체에서 X를 제거, SQL

근데 Oracle TRIM은 TRIM( - FROM - ) 형태라 애초에 틀림 ㅋㅋ 1번

2. 실행 시 추출되는 행의 개수

a_c, abc, acc 1개씩 존재한다는 가정

< LIKE 특수문자 >

%: 앞뒤 아무 문자열
_: 아무 글자 1개
\_: _를 특수문자가 아닌 진짜 밑줄 문자로 해석

< ESCAPE '\' >

앞으로 \는 이스케이프 문자로 쓰겠다.

해석하자면

" 앞뒤에 무엇이 있든 상관없이

문자열 안에 a_c가 그대로 포함되어 있어야 한다. "

ESCAPE가 없없다면 a_c, abc, acc 다 됨

13. 정규표현식

^: 문자열 시작
\w: 영문자, 숫자, 밑줄 _
*: 0개 이상 반복
$: 문자열 끝

해석하자면

전체 문자열이 영문자, 숫자, 밑줄로만 구성되어있어야 한다!

14.

58회 기출문제 1 (이론)

YYUNA — Thu, 6 Aug 2026 21:46:08 +0900

**문제출처: https://yunamom.tistory.com/397 **

1. 기본 엔티티

다른 엔티티의 존재에 의존하지 않고, 업무에 원래부터 존재하는 독립적인 엔티티

독립적으로 생성 가능
다른 엔티티로부터 발생하지 않음
여러 업무의 기준 정보가 됨

'프로젝트'는 보통 회사, 고객, 계약 등 업무가 발생하여 만들어짐
프로젝트는 업무의 중심에서 발생하므로 중심 엔티티로 분류

2. 제3정규형(3NF)

1NF: 컬럼 값을 원자값으로
2NF: 부분 함수 종속 제거
3NF: 이행 함수 종속 제거

ex) 이행 함수 종속: A->B, B->C 이면 A->C

사원번호 -> 부서번호, 부서번호 -> 부서명 이면
사원번호 -> 부서명 성립,,

이행 함수 종속성을 배제하지 않는다는 정반대 설명

"주식별자가 아닌 속성에 종속된 속성을 별도 테이블로 분리"

3. 데이터 모델링 View

데이터 관점: What, 어떤 데이터를 관리하는가 ex) 관리해야 할 고객 정보는 무엇인가
프로세스 관점: How, 업무가 어떻게 수행되는가 ex) 고객이 상품을 어떻게 주문하는가
상관 관점: Interaction, 서로 어떤 영향을 주고받는가 ex) 업무를 수행할때 어떤 데이터가 수정되는가

4. 중복성

같은 데이터를 여러 곳에 반복해서 저장하는 상태

부서명이 영업 1팀으로 바뀌었는데 고객 테이블만 수정하면

같은 부서인데 이름이 영업팀, 영업1팀 2개가 됨,,

중복성의 핵심 문제는

저장 공간 낭비
여러 곳을 함께 수정해야 함
일부만 수정 시 데이터 불일치 발생

5. 마더보트와 컴퓨터 간의 ERD 관계 해석

단, 관계선에 o 표시 존재

ERD 관계선 끝의 기호

o: 선택, 0개 가능
|: 반드시 1개
까마귀발: 여러 개

즉, o가 컴퓨터 쪽 관계에 붙어 있다면 컴퓨터 한 대에 연결되는 마더보드는

없을 수도 있다!

* 답: 컴퓨터에 마더보드를 장착할 수도 있고, 장착하지 않을 수도 있다.

6. 비식별자 관계

부모 엔티티의 주식별자가 자식에게 내려오긴 하지만,

자식의 주식별자에는 포함되지 않고 일반 속성인 FK로만 사용되는 관계

부서번호가 사원 테이블에 내려왔지만 사원의 PK는 사원번호,,

따라서 부서와 사원은 비식별자 관계!

여러 엔티티가 하나로 통합되었더라도 각 엔티티가 별도의 관계를 가짐
자식 엔티티에서 받은 속성이 반드시 필수가 아니어도 무방
자식 엔티티에서 주식별자로 사용 가능하더라도 별도의 주식별자 생성

각 엔티티의 데이터 생명주기를 동일하게 관리하는 경우

생명주기가 동일하면 부모와 자식의 결합도가 강하다는 뜻

따라서 부모 PK를 자식 PK에 포함하는 식별자 관계가 더 적합

키워드: 생명주기 동일, 존재 종속

-> 이러면 식별자 관계!

7. 정규화

1정규화: 반복 속성 제거, 원자값
2정규화: 부분 함수 종속 제거
3정규화: 이행 함수 종속 제거
BCNF 정규화: 모든 결정자가 후보키가 되도록 정리

8. 상호배타적 관계

하나의 상위 엔티티가 여러 하위 엔티티 중 오직 하나에만 속하는 관계

차량 한 대는 법인차량, 개인차량 둘 중 하나일뿐

동시에 둘 다일 수는 없다!

9. 학생과 수강 엔티티 간의 ERD

ERD(Entity Relationship Diagram)

: 데이터베이스 설계도

데이터베이스에 어떤 데이터가 있고, 데이터끼리 어떻게 연결되는지를 그림으로 나타냄

학생 한 명은 여러 과목을 수강할 수 있고,

과목 하나에도 여러 학생이 들어올 수 있음

학생과 과목은 원래 다대다 관계인데 중간에 수강 엔티티를 두는 구조

수강번호는 학생별로 중복되어 부여될 수 있다.

주식별자가 하나가 아니라 (학생번호, 수강번호) 두 속성의 조합으로 구성됨.

이걸 복합 식별자 aka 복합키라고 부른다.

10. 트랜잭션(Transaction)

원자성: 더 이상 나눌 수 없다. A
일관성: 트랜잭션 전후에도 규칙이 유지돼야 한다. C
고립성: 동시에 실행 시 서로 방해하지 않아야 한다. I
지속성: 한번 커밋된 결과는 장애가 나도 보존돼야 한다. D

1401 - Bypass

YYUNA — Fri, 20 Mar 2026 17:31:43 +0900

코드를 분석해보자!

이번 문제는 실행환경과 소스코드를 함께 받아온 케이스다.

docker-compose.yml : 컨테이너를 어떻게 띄울지 포트, 폴더, 서비스 이름 정의
deploy/Dockerfile : 컨테이너 이미지를 어떻게 만들지 설치, 실행 명령 정의
deploy/app.js : 메인 서버 코드

docker-compose.yml

version: "3.9"
services:
  nginx:
    image: nginx:1.22.0
    ports:
      - "8000:80"
    volumes:
      - ./deploy/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - app
  app:
    build:
      context: ./deploy/app

8000 접속 시 먼저 nginx를 거친 후 app에 들어간다는 것을 알 수 있다.

nginx.conf

events {
    worker_connections  1024;
}

http {
    server {
        listen 80;
        listen [::]:80;
        server_name  _;
        
        location = /shop {
            deny all;
        }

        location = /shop/ {
            deny all;
        }

        location / {
            proxy_pass http://app:3000/;
        }

    }

}

/shop 요청과 /shop/ 요청을 차단한다.

하지만 완전히 동일한 문자열만 막으므로 대소문자나 슬래시 변형, 문자 추가로 통과할 수 있다.

app.js

app.post("/shop",(req, res)=>{
    const leg = req.body.leg

    if (leg == 'FLAG'){
        return res.status(403).send("Access Denied")
    }

leg는 사용자 입력값에서 꺼낸다는 것을 알 수 있다.

app은 정확히 "FLAG"를 403으로 접근을 차단한다.

const obj = search(words,leg)

--------------------------------------------------------------

function search(words, leg) {
	return words.find(word => word.name === leg.toUpperCase())
}

사용자가 입력한 값을 대문자로 변환한 후, words 배열에서 name이 일치하는 데이터를 찾아 반환한다.

const words = require("./ag")

words 배열은 ag.js에서 가져온다!

ag.js

module.exports = [
    {
        "id": 1,
        "name": "FLAG",
        "description": "DH{fake_flag}"
    }
    
    ...

name 값을 기준으로 대문자로 변환된 입력값과 비교하여 FLAG 데이터를 찾을 수 있다.

⭐ 취약점

if (leg == 'FLAG'){
  return res.status(403).send("Access Denied")

사용자가 입력한 값이 정확히 "FLAG"인 경우에만 차단한다.

function search(words, leg) {
	return words.find(word => word.name === leg.toUpperCase())
}

search 함수가 실행되어 어떤 대소문자의 조합의 flag도 다 FLAG로 바뀐다.

필터는 원본 기준이나 검색은 대문자로 변환되는 것이 문제다.

필터는 FLAG만 막지만 입력은 대문자로 바꿔서 사용하므로 사용 기준이 다르다.

f12를 눌러 콘솔 탭에 들어간다.

fetch('/shop', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/x-www-form-urlencoded'
  },
  body: 'leg=flag'
})
.then(r => r.text())
.then(console.log)

브라우저에서 /shop으로 요청을 보내면 403 응답으로 접근을 차단한다.

응답에서 알 수 있듯이 이는 nginx에서 막은 것이다.

브라우저는 이미 정상 경로(/shop)으로 요청을 보내기 때문에

요청을 내가 직접 바꿔서 보낼 수 있어야 한다.

원하는 요청을 직접 만들 수 있는 curl 을 활용 할 수 있다!

curl -X POST "http://host3.dreamhack.games:19225/SHOP" -d "leg=flag"

/shop 대신 /SHOP 으로 입력 시

nginx는 다른 경로라고 생각하고 이를 통과시킨다.

Express는 경로 대소문자를 엄격히 구분하지 않아서 /SHOP 요청을 /shop 요청으로 받는다.

또한 정확히 "FLAG"만 막기에 "flag"는 통과하는 취약점이 발생한다.

문제 해결 성공!

768 - Command Injection

YYUNA — Fri, 20 Mar 2026 15:11:03 +0900

코드를 분석해보자!

#!/usr/bin/env python3
import subprocess

from flask import Flask, request, render_template, redirect

from flag import FLAG

APP = Flask(__name__)

Flask 웹 앱을 만들기 위해 필요한 모듈을 불러오고 앱을 만든다.

@APP.route('/')
def index():
	return render_template('index.html')

사용자가 / 주소로 접속하면 index() 함수가 실행된다.

templates/index.html 파일을 읽어서 홈 화면을 띄워준다

Flask는 보통 HTML 파일을 render_template()로 렌더링한다!

@APP.route('/ping', methods=['GET', 'POST'])
def ping():

/ping 주소를 담당하는 함수이다.

페이지를 열거나(GET), 폼 데이터를 제출(POST)할 수 있다.

⭐ 취약점

if request.method == 'POST':
	host = request.form.get('host')
        cmd = f'ping -c 3 {host}'

사용자가 제출한 폼 데이터에 따라 host 값이 바뀐다.

해당값을 ping 명령어에 끼워 넣게 되므로 host에 이상한 문자를 넣어도 그대로 들어간다.

try:
   output = subprocess.check_output(['/bin/sh', '-c', cmd], timeout=5)

subprocess.check_output() 는 외부 명령어를 실행하고 출력 결과를 받아오는 함수다.

셸(/bin/sh)을 열고 cmd 문자열을 명령어로 해석해서 실행하라는 뜻으로

셸에게 전체 문자열 해석을 맡기게 되는 구조다.

셸은 ; && || 등을 입력하더라도 명령어로 해석될 수 있으므로 Command Injection이 가능해진다.

return render_template('ping_result.html', data=output.decode('utf-8'))

명령이 성공적으로 실행되면 그 결과를 HTML에 넣어서 보여준다.

check_output() 의 결과는 보통 바이트(byte) 형태로 decode를 통해 사람이 읽을 수 있는 문자열로 바꾼다.

render_template를 통해 사용자는 브라우저에서 ping 결과를 보게 된다.

공격이 성공하면 ping 결과뿐 아니라 cat flag.py 같은 추가 명령의 출력도 같이 보일 수 있다!

우선 정상값을 확인하자.

8.8.8.8 입력시 ping -c 3 8.8.8.8 이 실행되는 것을 확인할 수 있다.

; 는 리눅스 명령어 구분자로 앞 명령이 끝나면 다음 명령도 실행시킨다.

그래서 서버 입장에서는 ping -c 3 8.8.8.8, cat flag.py를 순서대로 실행한다.

host = request.form.get('host')
cmd = f'ping -c 3 {host}'
subprocess.check_output(['/bin/sh', '-c', cmd])

사용자에게 입력받은 host를 명령어로 실행해버리는 취약점을 악용한 전형적인 Command Injection 공격이 가능해진다.

입력값 검증도 전혀 없고, 셸로 실행하기에 ; 를 활용한 공격이다.

문제 해결 성공!

769 - SQL Injection

YYUNA — Fri, 20 Mar 2026 14:00:01 +0900

우선 코드를 분석해보자!

from flask import Flask, request, render_template, g
import sqlite3
import os
import binascii

app = Flask(__name__)
app.secret_key = os.urandom(32)

Flask 웹앱을 생성한다.

try:
    FLAG = open('./flag.txt', 'r').read()
except:
    FLAG = '[**FLAG**]'

현재 폴더의 flag.txt.를 읽어서 FLAG 변수에 저장한다. 없으면 임시값 [**FLAG**] 을 넣는다.

DATABASE = "database.db"
if os.path.exists(DATABASE) == False:
    db = sqlite3.connect(DATABASE)
    db.execute('create table users(userid char(100), userpassword char(100), userlevel integer);')
    db.execute(f'insert into users(userid, userpassword, userlevel) values ("guest", "guest", 0), ("admin", "{binascii.hexlify(os.urandom(16)).decode("utf8")}", 0);')
    db.commit()
    db.close()

DB가 없으면 새로 만들고 users 테이블을 생성한다.

컬럼은 userid, userpasswor, userlevel 총 3개를 생성한다.

초기 데이터는 ("guest", "guest",0), ("admin", 랜덤비밀번호, 0) 총 2개를 넣는다.

admin 비밀번호는 랜덤이라 정상 로그인으로는 맞출 수 없다.

그런데 admin의 userlevel도 0인 것을 보아 SQL Injection으로 admin 행을 끌어오게 만드는 문제일 가능성이 높다.

def query_db(query, one=True):
    cur = get_db().execute(query)
    rv = cur.fetchall()
    cur.close()
    return (rv[0] if rv else None) if one else rv

쿼리 실행 함수이다.

전달받은 query 문자열을 그대로 실행한다. 파라미터 바인딩이 없기에

사용자 입력이 SQL문 안으로 그대로 들어가면 SQL Injection이 가능하다.

@app.route('/login', methods=['GET', 'POST'])
def login():
    if request.method == 'GET':
        return render_template('login.html')
    else:
        userlevel = request.form.get('userlevel')
        res = query_db(f"select * from users where userlevel='{userlevel}'")
        if res:
            userid = res[0]
            userlevel = res[2]
            print(userid, userlevel)
            if userid == 'admin' and userlevel == 0:
                return f'hello {userid} flag is {FLAG}'
            return f'<script>alert("hello {userid}");history.go(-1);</script>'
        return '<script>alert("wrong");history.go(-1);</script>'

request.form.get() 는 사용자가 웹에서 입력한 값을 가져오는 함수다.

⭐ 사용자가 POST로 보낸값은 userlevel = request.form.get('userlevel') 뿐이다.

이 값을 SQL에 그대로 넣는다.

보통 로그인이라면 아이디, 비밀번호도 받아야 하는데 해당 문제는 userlevel만 받는다.

이를 통해 이 문제는 특정 조건을 만족하는 행을 DB에서 뽑아오게 하는 문제임을 알 수 있다.

⭐ 취약점

res = query_db(f"select * from users where userlevel='{userlevel}'")

사용자 입력을 SQL 문자열에 직접 이어붙였기 때문에 취약하다.

예를 들어 입력값에 따옴표를 끊고 SQL 문법을 섞으면 원래 개발자가 의도한 조건을 바꿀 수 있다.

해당 구조가 전형적인 SQL Injection 이다.

⭐ 플래그가 나오는 조건

if userid == 'admin' and userlevel == 0:
	return f'hello {userid} flag is {FLAG}'

플래그를 얻으려면 res에 들어온 첫번째 행이 userid == 'admin', userlevel == 0 이어야 한다.

DB에 이미 ("admin", 랜덤비밀번호, 0) 행이 존재하므로

쿼리 결과의 첫번째 행을 admin으로 만들면 된다!

주어진 주소에 들어간다.

코드를 해석했던대로 입력값은 userlevel만 존재한다.

정상값인 0 을 입력할 경우, guest로 정상 로그인된다.

우리는 플래그 조건을 참고하여 admin 행이 나오게 해야 한다.

⭐ SQL Injection 공격

select * from users whrere userlevel='입력값'

원래 쿼리에서 입력값으로 WHERE 조건을 바꿔야한다.

0' AND userid='admin' --

우리의 목표는 admin이 첫번째로 출력되게 하는 것이다.

해당값을 입력하면 select * from users wherer userlevel='0' AND userid='admin' -- 쿼리가 실행된다.

0'을 입력하여 문자열을 강제로 닫고 AND 조건을 추가하여

"userlevel이 0이면서 admin" 인 데이터만 가져오게 된다.

기존에 '가 남아있으므로 -- 을 통해 뒤 코드를 다 무시하게 하여 문법 에러를 방지한다.

--을 빼면 Ineternal Server Error가 뜨는 것을 확인할 수 있다.

플래그값을 확인할 수 있다.

문제 해결 성공!

ASA SSH, Telnet 접속

YYUNA — Mon, 24 Nov 2025 17:31:18 +0900

PC로 핑이 안가서 윈도우 방화벽 파일프린터및 공유 ICMPv4 규칙 사용

했더니 핑됨

ASA (Adaptive Security Appliance)

YYUNA — Mon, 17 Nov 2025 06:32:32 +0900

❤️ ASA

ASA는 방화벽 + VPN + 침입 방지 + 트래픽 제어 기능을 한 장비에 통합한 보안 게이트웨이 이다.

주요 기능

방화벽(Firewall): 상태기반 검사로 트래픽을 제어한다. 세션 정보를 기억해서 응답 패킷만 허용한다.
NAT: 내부 사설 IP를 외부 공인 IP로 변환한다.
IPS: 비정상 트래픽을 탐지, 차단한다.

인터페이스 이름이 Inside 이면 기본적으로 보안 레벨이 가장 높은 100을 적용한다.

나머지 인터페이스 이름들은 보안 레벨이 가장 낮은 0을 적용한다.

보안 레벨이 높은 곳에서 낮은 곳으로의 트래픽 흐름은 기본적으로 모두 허용된다.

보안 레벨이 같은 곳에서 서로의 트래픽 흐름은 기본적으로 모두 거부된다.

ASA 명령어

방화벽 모드

Router Mode(L3): 기본값
Transparent Mode(L2): 스위치처럼 작동

no firewall transparent  # Router Mode

firewall transparent  # Transparent Mode

show firewall  # 확인

컨텍스트 모드

하나의 ASA를 여러 개의 가상 방화벽으로 나눌 수 있다.

mode single  # 단일 사용(Default)

mode multiple  # 멀티 사용

기본 설정

ASA는 인터페이스에 반드시 이름과 보안 등급을 설정해야 한다.

nameif: 인터페잇의 논리적 역할 지정
Security Level: 0~100, 높은 레벨에서 낮은 레벨 방향은 허용, 반대는 차단, inside=100~outside=0

int e0
nameif inside
security-level 100
ip address 1.1.2.0 255.255.255.0

ASA Routing

ASA는 라우터처럼 보이지만 OSPF에서 와일드 마스크를 사용하지 않고 서브넷 마스크만 사용한다.

router ospf 1
network 1.1.20.0 255.255.255.0 area 0  # 서브넷 마스크만 사용

HTTP 활성화

PC에서 http 접속이 가능하게 설정한다.

ip http server
ip http authentication enable
ip http authentication local
username cisco privilege 15 password cisco

정보/ 모니터링 명령어

show interface ip brief  # 인터페이스 확인

show route  # 라우팅 테이블 확인

show conn all  # 연결된 세션 확인

clear config all  # 초기 설정 지우기

command-alias exec c conf t  # 단추 명령 추가

logging enable  # 로그 활성화

ZFW (Zone-based Policy Firewall)

YYUNA — Fri, 7 Nov 2025 12:30:12 +0900

❤️ ZFW

Cisco 라우터에서 방화벽 기능을 구현하는 방식으로 기존 CBAC보다 발전된 형태이다.

ASA/PIX 방화벽처럼 Zone 단위로 트래픽 정책을 관리한다.

주요 용어

Zone: 논리적 보안 영역
Zone-pair: 두 Zone 간의 트래픽 방향 정의
Policy-map: 어떤 트래픽을 허용/차단할지 정의
Class-map: 어떤 트래픽을 Policy-map에서 참조할지 지정

ZFW은 인터페이스 기반인 CBAC보다 훨씬 세분화된 정책 관리가 가능하다.

ZFW 실습

1. zone 생성, 각 인터페이스에 할당

ZFW에서는 인터페이스를 zone으로 묶어 관리한다.

zone security 명령으로 보안 영역을 만들고 zone-member security 명령으로 인터페이스를 해당 zone에 할당한다.

# R2
zone security inside
zone security outside

int s1/0
zone-member security inside
exit

int s1/1
zone-member security outside
exit

# 확인
do show zone security

생성된 zone 확인

2. Zone-pair를 만든다.

ZFW는 기본적으로 zone 간 트래픽을 차단하기 때문에 통신을 허용하거나 차단하려면

Zone-pair로 두 zone을 묶어 트래픽 방향을 정의해야 한다.

# R2(config)
zone-pair security Outbound source inside destination outside

# 확인
do show zone-pair security

3. CPL(Cisco Policy Language)을 이용하여 보안정책을 정의한다.

클래스맵은 어떤 트래픽을 정책에 적용할 것인지를 정의한다.

해당 클래스맵은 ACL이 허용한대로 모든 트래픽에 정책이 매칭된다.

# R2
ip access-list extended acl-out
permit ip any any 
exit

# 클래스맵 생성
class-map type inspect class-outbound
match access-group name acl-out
exit

폴리시맵은 매칭된 트래픽을 어떻게 처리할지 정의한다.

inspect로 설정 시 트래픽을 검사하고 세션을 추적하여 통신을 살릴 수 있다.

# 폴리시맵 생성
policy-map type inspect policy-outbound
class type inspect class-outbound
inspect

클래스맵에서 특정 프로토콜을 지정하지 않아서 모든 프로토콜을 검사 대상으로 처리한다.

4. Zone-pair에 보안정책을 적용한다.

service-policy 명령을 이용해 보안정책(policy-map)을 Zone-pair에 적용한다.

이로써 ZFW는 실제로 트래픽을 검사하고 제어할 수 있게 된다!

zone-pair security Outbound
service-policy type inspect policy-outbound

내부>외부는 가능

외부>내부는 불가능

R3>R1(외부>내부) Telnet 허용하기

외부>내부로 들어오는 인바운드 트래픽 중

Telnet 트래픽만 대상으로(클래스 맵) inspect 하도록 정책을 설정(폴리시 맵)하면 된다.

이후 zone-pair를 통해 서로 다른 zone 간의 트래픽 방향과 정책을 연결하면

지정된 방향으로만(source>destination) 정책이 적용된다!

# R2
# 클래스맵 생성
class-map type inspect class-inbound
match protocol telnet
exit

# 폴리시맵 생성
policy-map type inspect policy-inbound
class type inspect class-inbound
inspect
exit
exit

# Inbound zone-pair 생성 및 적용
zone-pair security Inbound source outside destination inside
service-policy type inspect policy-inbound

외부>내부(Inbound) Telnet 허용된걸 확인

CBAC (Context-Based Access Control)

YYUNA — Fri, 7 Nov 2025 10:51:52 +0900

❤️ CBAC

CBAC은 Stateful Firewall 기능을 갖추어 L7 트래픽이 제어 가능한 ACL이다.

Stateful Firewall

세션 상태를 추적하여 내부에서 시작된 트래픽의 응답만 허용하고

외부에서 시작된 트래픽은 차단한다.

동작방식

내부 > 외부 트래픽 감시: 내부에서 출발한 패킷을 CBAC가 감시한다. (state tracking)
임시 ACL 생성: CBAC이 설정된 인터페이스 방향으로 송수신 발생 시 임시 ACL이 자동 생성된다.
세션 종료 시 ACL 삭제: 세션 종료 시 해당 임시 ACL이 제거된다.

세션 종료 조건

TCP: FIN 패킷 후 5초 경과
UDP: 30초간 트래픽 X
DNS: 질의 후 5초 이내 응답 없으면 제거, 응답 시 즉시 제거
ICMP: 10초 이내 응답 없으면 제거

RACL vs CBAC

CBAC는 Stateful 기능으로 세션을 추적하여 ACL을 자동 생성하여 L7 까지 제어가 가능하다.

RACL과 달리 동적으로 ACL이 생성되므로 보안성, 유연성이 높다.

테스트 환경 구축

R2 s1/1 인터페이스에 CBAC을 설정하여

R2가 내부(1.1.12.0)에서 외부(1.1.23.0)로 나가는 트래픽을 검사하여 정상적인 응답만 돌아올 수 있도록 허용하고

나머지 외부 요청은 차단해보자! (Stateful Firewall 역할 수행)

패킷 검사 규칙 정의

CBAC이 감시해야 하는 프로토콜을 정의한다.

내부>외부로 나가는 TCP, UDP, ICMP 트래픽을 감시하고 세션 정보를 저장한다.

# R2
ip inspect name mycbac tcp
ip inspect name mycbac udp
ip inspect name mycbac icmp

외부에서 들어올 트래픽 기본 ACL 정의

외부(1.1.23.3)와의 OSPF 통신은 항상 허용한다.

해당 ACL은 CBAC과 함께 적용된다. 나머지는 CBAC이 동적으로 임시 ACL을 생성해 허용한다.

# R2
ip access-list extended acl-in
permit ospf host 1.1.23.3 any

인터페이스 적용

s1/1 인터페이스를 통해 외부로 나가는 트래픽을 추적하도록 설정한다.

외부>내부로 들어오는 트래픽은 acl-in + CBAC이 만든 임시 ACL 규칙으로 제어한다.

# R2
int s1/1
ip inspect mycbac out
ip access-group acl-in in

R3 테스트용 서버 구축

# R3(config)
line vty 0 15
password cisco
login
transport input telnet

ip http server

테스트 결과 확인

R1 > R3 Telnet 테스트(내부 > 외부)

성공한다.

show ip inspect sessions detail

CBAC이 현재 추적 중인 세션 목록을 상세히 확인할 수 있다.

telnet 세션을 종료하면 CBAC은 자동으로 삭제된다.

R3 > R1 PING, Telnet 테스트(외부 > 내부)

외부에서 내부로 접근하는 트래픽은 CBAC이 감지하여 자동 차단된다.

내부에서 외부로 나가는 tcp 요청은 다 허용해서 http 응답도 온다.

telnet은 거부하고, http만 허용하게 설정도 가능하다.

CBAC이 tcp가 아닌 http(포트 80)만 감시하도록 설정하면 된다!

# 이전 CBAC 삭제
no ip inspect name mycbac

# 새로운 CBAC 생성
ip inspect name mycbac http

int s1/1
ip inspect mycbac out

telnet 접속 거부

http만 동적으로 허용

Extended ACL(Access Control List) 문법 핵심 정리

YYUNA — Fri, 7 Nov 2025 09:13:51 +0900

ip access-list extended [ACL이름] 
permit [프로토콜] [출발지] [목적지] [옵션]
deny [프로토콜] [출발지] [목적지] [옵션]

프로토콜

L3: ip, ospf, icmp
L4: tcp, udp
L7: http(80/tcp), ssh(22/tcp), dns(53/udp) 포트로 식별

ip 차단 시 ICMP, OSPF, TCP, UDP 등 모든 IP 패킷이 차단된다!

예제1. PING 거부, 라우팅(OSPF) 허용, TCP 허용

ip access-list extended ACL-IN
permit ospf any any
permit tcp any any established
deny icmp any any
permit ip any any

permit ospf: 라우터 간 OSPF Neighbor 관계 허용
permit tcp - established: 내부에서 먼저 시작한 세션의 응답 허용
deny icmp: PING 차단
permit ip: 나머지 IP 트래픽 허용

예제2. 내부 서버(192.168.10.10)에 대한 외부 Telnet 접속만 허용

ip access-list extended TELNET-IN
permit tcp any 192.168.10.10 eq 23

permit tcp [any] [목적지] eq 23: 외부에서 telnet 192.168.10.10 가능
deny ip: 다른 트래픽(ping, ftp, http 등)은 전부 차단

*모든 ACL에는 맨 아래에 deny ip any any 가 암묵적으로 존재하여 명시하지 않아도 나머지는 전부 차단!