257. ACL

📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 257편
이전 글: 256. Firewall Rule · 다음 글: 258. Source IP 정책

1. 개념

ACL(Access Control List, 접근 제어 목록) 은 "어떤 주체가 어떤 대상에 접근할 수 있는가"를 목록으로 적은 것입니다. 네트워크에서는 라우터·L3 스위치 인터페이스에 적용하는 패킷 필터 규칙 목록을 주로 가리킵니다. Standard·Extended ACL 문법, 와일드카드 마스크, 인터페이스 방향 설정은 04 영역 178. ACL에서 다뤘습니다.

이 글은 ACL이 방화벽 정책과 어떻게 다르고, ACL이 남긴 흔적을 어떻게 해석하는가를 다룹니다.

비교 항목	라우터·스위치 ACL	방화벽 정책
판단 방식	주로 Stateless (패킷 단위)	Stateful (세션 단위)
적용 단위	인터페이스 + 방향(in/out)	Zone 간, 정책 테이블
기본 동작	목록 끝의 암묵적 deny	기본 정책(보통 deny)
로그	선택 옵션, 요약 기록 경향	세션 시작·종료 로그
주 용도	세그먼트 간 1차 통제, 관리 접근 제한	경계·구역 간 정밀 통제

---

2. 동작 원리

ACL은 인터페이스를 지나는 패킷을 목록 순서대로 비교합니다.

패킷이 인터페이스 Gi0/1 (in 방향) 도착
   ↓
[ACL 항목 10] 일치? ─ 예 → permit/deny 적용, 종료
   ↓ 아니오
[ACL 항목 20] 일치? ─ 예 → permit/deny 적용, 종료
   ↓ 아니오
[목록 끝: 암묵적 deny any] → 폐기 (별도 로그 없음)

관제 관점에서 중요한 점은 다음과 같습니다.

• 암묵적 deny는 로그를 남기지 않습니다. 차단 흔적이 필요하면 마지막에 로그 옵션을 붙인 명시적 deny 항목을 둡니다.
• ACL은 방향별로 적용됩니다. 같은 인터페이스라도 in과 out은 별개의 목록이므로 "어느 인터페이스의 어느 방향 ACL이 막았는가"를 확인해야 합니다.
• Stateless이므로 응답 트래픽 처리가 방화벽과 다릅니다(253. Packet Filtering Firewall).

---

3. 주요 특징

ACL 개념은 온프레미스 장비 밖에서도 쓰입니다. 클라우드 환경에서는 상태 기반과 비저장 방식을 함께 제공하는 경우가 있습니다. AWS를 예로 들면 다음과 같습니다.

구분	보안 그룹(Security Group)	네트워크 ACL(NACL)
적용 대상	인스턴스(네트워크 인터페이스)	서브넷
상태	Stateful — 응답 자동 허용	Stateless — 응답 규칙 별도 필요
규칙 동작	허용 규칙만	허용·거부 규칙
평가	모든 규칙을 종합	규칙 번호 순서, 첫 일치

• ACL은 대상이 적고 조건이 단순한 통제에 적합합니다. 예: "관리망에서만 스위치 SSH 접속 허용".
• ACL 항목에는 이름·설명을 붙이기 어려운 장비가 많아, 번호와 설정 백업이 역추적의 근거가 됩니다.
• 많은 장비에서 ACL 로그는 모든 패킷을 기록하지 않고 첫 패킷 기록 후 일정 간격으로 요약하는 방식입니다(예: Cisco IOS의 기본 동작). 따라서 로그의 패킷 수가 실제보다 적어 보일 수 있습니다.

---

4. 예시

ACL 로그와 적중 수를 해석하는 형식 예시입니다(값은 환경마다 다름).

# 형식 예시 — ACL 로그 (첫 패킷 기록 후 요약 기록)
%SEC-6-IPACCESSLOGP: list MGMT-IN denied tcp 192.168.10.77(52110) -> 10.99.0.1(22), 1 packet
%SEC-6-IPACCESSLOGP: list MGMT-IN denied tcp 192.168.10.77(52110) -> 10.99.0.1(22), 14 packets

# 형식 예시 — ACL 적중 수 확인 결과
Extended IP access list MGMT-IN
    10 permit tcp 10.99.10.0 0.0.0.255 host 10.99.0.1 eq 22 (1520 matches)
    20 deny tcp any host 10.99.0.1 eq 22 log (15 matches)
    30 permit ip any any (98211 matches)

분석 방법

1. 사용자망(192.168.10.x)의 PC가 관리 대상 장비 SSH에 접속을 시도했고, 20번 항목에서 차단됐습니다.
2. 같은 5-tuple로 14패킷이 요약 기록된 것은 클라이언트가 SYN을 재전송한 것으로 해석할 수 있습니다(Drop 방식이라 응답을 받지 못함).
3. 이 PC가 관리 장비에 접속할 업무상 이유가 있는지, 같은 시간대 다른 장비에도 시도했는지 확인합니다.

---

5. 보안 관점

• ACL은 관리 평면 보호(장비 SSH·SNMP 접근 제한)에 효과적인 1차 통제 수단입니다.
• 마지막 permit ip any any처럼 넓은 허용 항목은 앞의 차단 항목 외 모든 트래픽을 통과시킵니다. 의도를 명확히 문서화합니다.
• Stateless ACL은 위조 출발지 포트·ACK 패킷에 취약하므로 경계의 유일한 통제 수단으로 쓰지 않습니다.
• ACL 변경은 네트워크 장애와 보안 공백을 동시에 만들 수 있어 변경 이력 관리가 필요합니다.

---

6. SOC 관점

관제자가 확인할 질문

• 어느 장비의 어느 인터페이스, 어느 방향 ACL에서 발생한 로그인가?
• 차단된 출발지가 내부 사용자 PC라면, 관리 장비·서버 대역으로 접근을 시도한 이유는 무엇인가? 내부 정찰(228. 내부망 정찰) 가능성을 봅니다.
• 요약 로그의 패킷 수는 실제 시도 횟수와 다를 수 있다는 점을 보고서에 반영했는가?

ACL 흔적	해석
관리 포트(22, 161, 443) 차단 로그	비인가 관리 접근 시도
적중 수가 0인 차단 항목	위에서 가려졌거나 실제로 시도가 없음
암묵적 deny만 있고 로그 없음	차단 사실을 로그로 입증 불가

오탐 주의: 모니터링 서버·백업 서버의 정기 접속이 ACL 변경 후 차단되는 경우가 흔합니다. 반복 주기가 일정하면 운영 도구일 가능성을 먼저 확인합니다.

---

7. 핵심 정리

• ACL은 인터페이스·방향별로 적용되는 순서 기반 접근 제어 목록이며 주로 Stateless로 동작합니다.
• 목록 끝의 암묵적 deny는 로그를 남기지 않으므로 필요하면 로그 옵션이 있는 명시적 deny를 둡니다.
• 클라우드에서도 Stateful(보안 그룹)과 Stateless(네트워크 ACL) 통제가 구분됩니다.
• ACL 로그는 요약 기록되는 경우가 많아 패킷 수를 실제 시도 횟수로 단정하지 않습니다.
• ACL 차단 로그는 관리 장비 접근 시도, 내부 정찰의 단서가 됩니다.