ACL로 네트워크 트래픽을 제어하는 방법 — 현장에서 잘못 적용해서 SSH가 끊겼던 그날의 기록
들어가며
ACL 설정으로 가장 뼈아픈 경험을 하나 꼽으라면, 원격지 라우터에 ACL을 잘못 적용해서 SSH 접속이 끊겨버린 날입니다.
출장 중인 장비였는데, 방향을 in으로 해야 할 ACL을 out으로 적용하는 실수를 했습니다. 그 순간부터 SSH 연결이 완전히 차단됐고, 결국 현장에 직접 가서 콘솔 케이블로 접속해 수정해야 했습니다. 왕복 2시간짜리 실수였습니다.
그 이후로 ACL을 적용하기 전에는 반드시 종이에 트래픽 흐름과 방향을 먼저 그려보는 습관을 들였습니다. 이 글에서는 그 경험을 바탕으로 ACL의 핵심 원칙을 설명합니다.
ACL의 기본 동작 원리 — 반드시 알아야 할 두 가지 원칙
■ 원칙 1: 순서가 중요하다 (Top-Down Processing)
규칙은 위에서 아래로 순서대로 비교합니다.
한 번 일치하면 아래 규칙은 더 이상 확인하지 않습니다.
따라서 구체적인 규칙을 위에, 광범위한 규칙을 아래에 배치해야 합니다.
현장 실수 사례: permit 10.0.0.0/8 을 위에 두고 deny 10.10.10.0/24 를 아래에 두면,
10.10.10.x 주소도 위의 permit에 먼저 걸려 그냥 통과됩니다.
순서를 바꿔 deny를 위에, permit을 아래에 배치해야 합니다.
■ 원칙 2: 암묵적 Deny (Implicit Deny All)
모든 ACL의 마지막에는 눈에 보이지 않는 “deny all” 규칙이 있습니다.
ACL을 적용한 후 허용이 필요한 트래픽이 모두 명시적으로 허용되었는지 반드시 확인하십시오.
현장 경험: ACL을 처음 적용하고 나서 “왜 아무 것도 안 되지?”라는 상황이 오면, 암묵적 deny all이 모든 트래픽을 차단하고 있는 경우가 대부분입니다. permit 규칙을 하나도 추가하지 않았거나, permit 이후에 불필요한 deny all을 명시적으로 추가한 경우입니다.
Standard ACL — 출발지 IP만으로 제어
Standard ACL은 패킷의 출발지 IP 주소만을 기준으로 허용 또는 차단을 결정합니다.
ACL 번호 범위: 1 ~ 99, 1300 ~ 1999
■ 설정 예시
access-list 10 permit 192.168.1.0 0.0.0.255
access-list 10 deny any
interface GigabitEthernet0/1
ip access-group 10 out
■ Standard ACL 적용 위치 원칙
목적지에 가능한 가깝게 적용합니다.
출발지 IP만으로 차단하면, 잘못된 위치에 적용 시 다른 목적지로 가는 트래픽까지 차단될 수 있습니다.
Extended ACL — 프로토콜·포트까지 세밀하게 제어
Extended ACL은 출발지 IP, 목적지 IP, 프로토콜, 포트 번호를 조합하여 훨씬 세밀한 제어가 가능합니다.
ACL 번호 범위: 100 ~ 199, 2000 ~ 2699
■ 설정 예시 — 특정 IP에서 웹 서버(80번)만 허용
access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.50 eq 80
access-list 100 deny ip any any
현장 팁: Extended ACL을 처음 작성할 때 프로토콜을 ip로 설정하면 TCP, UDP, ICMP 모두 포함됩니다. 포트 번호 제어가 필요하면 반드시 tcp 또는 udp 로 명시해야 합니다.
■ 자주 사용하는 키워드
host [IP] : 특정 호스트 단일 지정
any : 모든 주소
eq [번호] : 특정 포트와 같음
range [시작] [끝] : 포트 범위
■ Extended ACL 적용 위치 원칙
출발지에 가능한 가깝게 적용합니다.
출발지 근처에서 차단해야 불필요한 트래픽이 네트워크를 통과하는 것을 방지할 수 있습니다.
와일드카드 마스크 계산법
ACL에서는 서브넷 마스크 대신 와일드카드 마스크를 사용합니다.
0은 “이 비트는 일치해야 한다”, 1은 “이 비트는 무시한다”를 의미합니다.
■ 계산 방법: 255.255.255.255에서 서브넷 마스크를 뺍니다
/24 (255.255.255.0) → 255.255.255.255 – 255.255.255.0 = 0.0.0.255
/16 (255.255.0.0) → 255.255.255.255 – 255.255.0.0 = 0.0.255.255
/30 (255.255.255.252) → 255.255.255.255 – 255.255.255.252 = 0.0.0.3
현장 팁: 와일드카드 마스크 계산이 헷갈리면 host 키워드(= 0.0.0.0)와 any 키워드(= 255.255.255.255) 두 가지 특수 표현부터 외우고, 나머지는 계산기를 활용하는 것을 권장합니다.
in 방향과 out 방향 — 가장 많이 실수하는 부분
ACL을 인터페이스에 적용할 때는 방향을 반드시 지정해야 합니다.
in → 해당 인터페이스로 들어오는 패킷에 적용
out → 해당 인터페이스에서 나가는 패킷에 적용
■ 라우터를 기준으로 생각해야 합니다
외부 인터넷에서 내부로 들어오는 트래픽을 차단하려면:
외부 인터페이스(GigabitEthernet0/1)의 in 방향에 ACL 적용
내부 특정 장비가 외부로 나가는 트래픽을 차단하려면:
내부 인터페이스(GigabitEthernet0/0)의 in 방향에 ACL 적용
■ SSH 끊김 방지 체크리스트 (ACL 적용 전 필수 확인)
- permit 규칙 중 SSH 관리 트래픽(TCP 22)이 포함되어 있는가?
- in/out 방향이 의도한 트래픽 흐름과 일치하는가?
- 원격 작업이라면 콘솔 접근 방법을 미리 확보해두었는가?
■ ACL 문제 시 수정 명령어
no ip access-group [번호] [방향] ← 인터페이스에서 ACL 제거
no access-list [번호] ← ACL 전체 삭제 (번호형)
ACL 확인 및 매치 카운터 활용 show access-lists ← 모든 ACL과 매치 카운터 확인
show access-lists 100 ← 특정 ACL 확인
show ip interface [포트명] ← 인터페이스에 적용된 ACL 확인
현장 팁: show access-lists 결과에서 각 규칙 옆 “(X matches)” 숫자가 핵심입니다. 예상보다 많은 트래픽이 특정 규칙에 걸리고 있다면 ACL 순서나 범위에 문제가 있다는 신호입니다. 이 숫자를 주기적으로 확인하는 것만으로도 많은 보안 이상 징후를 조기에 발견할 수 있습니다.
마무리 — ACL은 설정보다 ‘방향과 위치’가 더 중요하다
ACL 설정에서 가장 중요한 것은 문법이 아닙니다. 트래픽이 어느 방향으로 흐르는지, 어느 인터페이스에 적용해야 하는지를 정확히 파악하는 것이 핵심입니다.
ACL을 적용하기 전에는 반드시 트래픽 흐름을 종이에 그려보고, 원격 작업이라면 관리 트래픽(SSH)이 permit 목록에 있는지 이중으로 확인하십시오. 저처럼 SSH가 끊겨서 현장까지 달려가는 상황은 한 번만 경험하면 충분합니다.
