Cisco ACL 차단 (ACL 구성, 암묵적 Deny, 동적 차단)

보안의 기초 ACL(Access Control List)로 특정 IP 차단 설정하기

새벽에 모니터링 알림이 울렸을 때, 솔직히 처음엔 오탐(false positive)이겠거니 했습니다. 그런데 로그를 열어보니 특정 IP 대역에서 SSH 포트로 수백 건의 접속 시도가 쏟아지고 있었습니다. 브루트포스 공격이었습니다. 새벽 두 시에 로그를 보면서 "이게 진짜구나"를 실감한 그 순간은 지금도 기억납니다. 라우터 ACL로 직접 막아본 그 경험을 바탕으로, ACL이 실제로 얼마나 유효한지, 그리고 어디서 한계를 드러내는지 정리해봤습니다.

ACL 구성과 암묵적 Deny

ACL(Access Control List)이란 라우터나 스위치에서 특정 트래픽을 허용하거나 차단하는 규칙 목록입니다. 쉽게 말해, 네트워크 관문에서 누가 들어오고 나갈 수 있는지를 결정하는 출입 명단과 같습니다. 개념은 단순하지만, 실제 구성에서는 순서 하나, 키워드 하나가 전체 서비스를 멈추게 할 수 있다는 점에서 주의가 필요합니다.

당시 저는 Cisco 라우터에서 확장 ACL을 생성했습니다. 확장 ACL이란 출발지 IP뿐 아니라 목적지 IP, 프로토콜, 포트 번호까지 조건으로 지정할 수 있는 방식으로, 표준 ACL보다 훨씬 세밀한 제어가 가능합니다. 공격 IP 대역 전체를 차단하는 deny 규칙을 먼저 넣고, 나머지 트래픽은 모두 허용하는 permit 규칙을 뒤에 배치했습니다. 그리고 이 ACL을 인터페이스의 인바운드 방향에 적용했습니다.

인바운드(inbound)란 외부에서 라우터 안쪽으로 들어오는 방향을 의미합니다. 공격 트래픽을 최대한 네트워크 입구에서 끊어내야 내부 자원 낭비를 줄일 수 있기 때문에, 아웃바운드가 아닌 인바운드에 적용하는 것이 원칙입니다. 이 방향 설정 하나가 생각보다 중요합니다. 아웃바운드에 잘못 걸면 내부 트래픽이 막히는 황당한 상황이 생깁니다.

그런데 제가 이 작업을 처음 배울 때 몰랐던 함정이 하나 있었습니다. Cisco ACL에는 암묵적 Deny All 규칙이 존재합니다. 이는 ACL 목록 맨 끝에 모든 트래픽을 차단하는 규칙이 자동으로 숨겨져 있는 것으로, 명시적으로 허용하지 않은 트래픽은 전부 차단된다는 의미입니다. 처음에 이 사실을 잊고 permit 규칙 없이 ACL을 인터페이스에 붙였다가 전체 서비스가 순식간에 끊긴 적이 있습니다. 당시 전화가 빗발쳤고, 그 이후로는 반드시 show access-lists 명령으로 규칙 목록을 재확인한 뒤 적용하는 습관을 들였습니다. 이 경험이 "설정 전 검토"를 몸에 박아준 가장 좋은 선생님이었습니다.

ACL 변경 작업 전 체크해야 할 핵심 포인트가 있습니다. deny 규칙과 permit 규칙의 순서와 누락 여부를 반드시 확인해야 하고, 변경 적용 전 롤백 타이머를 설정해 장애 발생 시 자동 복구 경로를 확보해야 합니다. deny 규칙 끝에 log 키워드를 붙여 차단 이벤트가 syslog에 기록되도록 하는 것도 필수입니다. Linux 환경이라면 iptables를 이용한 한 줄짜리 명령으로 동일한 효과를 구현할 수 있지만, 재부팅 시 규칙이 초기화될 수 있으므로 영속화 처리가 별도로 필요합니다.

NIST SP 800-41은 방화벽과 패킷 필터링 장비 운용 시 최소 권한 원칙(Least Privilege)을 적용하고, 규칙은 주기적으로 검토·정리할 것을 권고하고 있습니다. 여기서 최소 권한 원칙이란 꼭 필요한 트래픽만 허용하고 나머지는 기본적으로 차단하는 설계 철학을 뜻합니다. 당시 구성은 빠른 대응을 위해 permit any를 사용했지만, 이후에는 실제 허용할 포트와 프로토콜만 명시하는 방식으로 개선했습니다. 급할 때 만든 설정이 그대로 굳어버리는 일이 실무에서 생각보다 자주 일어납니다. 주기적 검토가 귀찮더라도 반드시 해야 하는 이유입니다.

동적 차단과 ACL의 한계

솔직히 ACL을 적용한 직후에는 뿌듯했습니다. 로그에서 공격 IP 대역이 깔끔하게 차단되는 것을 확인했을 때는 효과적이라는 확신도 들었습니다. 그런데 며칠 후, 공격자가 다른 IP 대역으로 갈아타서 다시 시도해왔습니다. ACL은 정적 규칙 기반이라 공격자가 출발지 IP를 바꾸는 순간 무력화됩니다. 제 경험상 이 점이 ACL의 가장 뼈아픈 한계입니다. 방어하는 쪽은 모든 경우를 막아야 하고, 공격하는 쪽은 하나만 뚫으면 된다는 비대칭성이 여기서 명확하게 드러납니다.

일반적으로 ACL만으로도 기본 보안이 충분하다고 생각하는 분들도 있는데, 실제로 운영해보니 전혀 그렇지 않았습니다. 특히 DDoS(분산 서비스 거부 공격)처럼 수백, 수천 개의 IP에서 동시에 트래픽이 쏟아지는 상황에서는 IP 하나하나를 ACL에 추가하는 방식은 현실적으로 불가능합니다. DDoS란 여러 장소에 분산된 좀비 PC나 서버가 특정 대상을 향해 동시에 대량의 트래픽을 보내 서비스를 마비시키는 공격 방식입니다.

이런 상황에 대비해 이후에 Fail2ban을 도입했습니다. Fail2ban이란 로그 파일을 실시간으로 감시하다가 일정 횟수 이상 인증 실패가 감지된 IP를 자동으로 iptables 규칙에 추가해 차단하는 도구입니다. 정적 ACL이 수동으로 차단 명단을 작성하는 방식이라면, Fail2ban은 패턴을 인식해 스스로 차단 명단을 업데이트하는 방식에 가깝습니다. 이 차이가 실무에서는 생각보다 큰 차이를 만들어냅니다.

더 나아가 실질적인 방어 체계를 갖추려면 IDS/IPS와의 연동이 필요합니다. IDS(침입 탐지 시스템)란 네트워크나 호스트에서 비정상적인 패턴을 감지하고 경보를 발생시키는 시스템이며, IPS(침입 방지 시스템)는 탐지와 동시에 자동으로 트래픽을 차단하는 기능까지 수행합니다. 이 두 시스템을 SIEM(보안 정보 및 이벤트 관리 시스템)과 연결하면, 여러 보안 장비에서 수집한 로그를 통합 분석해 공격 패턴을 더 빠르게 파악하고 대응할 수 있습니다.

이러한 접근 방식을 Defense in Depth, 즉 심층 방어 전략이라고 부릅니다. 단일 방어선이 뚫렸을 때 다음 방어선이 작동하도록 여러 겹의 보안 레이어를 쌓는 개념입니다. Cisco의 공식 보안 구성 가이드 역시 ACL을 단독 방어 수단이 아닌 다층 보안 구조의 첫 번째 필터링 레이어로 위치시킵니다. 제 경험에도 완전히 부합하는 관점입니다. ACL은 필요하지만, 충분하지 않습니다. 이 두 가지를 혼동하지 않는 것이 보안 설계의 출발점입니다.

마치며

결국 ACL은 네트워크 보안의 출발점이지 도착점이 아닙니다. 브루트포스 공격 하나를 막은 경험이 오히려 단독 ACL의 한계를 뚜렷하게 보여줬습니다. 지금은 ACL로 기본 필터링을 유지하면서, Fail2ban과 IPS를 통한 동적 차단, 그리고 SIEM을 통한 이벤트 통합 모니터링을 함께 운영하고 있습니다. 처음 보안 구성을 잡는 분이라면, ACL부터 올바르게 이해하되 이것이 전부라는 착각은 반드시 버려야 한다고 생각합니다. 작은 설정 하나가 전체 서비스를 멈추게 할 수 있다는 점, 저처럼 직접 겪어보기 전에 미리 알아두셨으면 합니다.

---

참고 출처

• Cisco - Configuring IP Access Lists : https://www.cisco.com/c/en/us/support/docs/ip/access-lists/26448-ACLsamples.html
• Linux man page - iptables(8) : https://linux.die.net/man/8/iptables
• Ubuntu Documentation - UFW : https://help.ubuntu.com/community/UFW
• AWS Docs - Network ACLs : https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html
• AWS Docs - Security Groups : https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html
• Cisco Networking Academy - CCNA Study Materials : https://www.netacad.com
• nftables Wiki : https://wiki.nftables.org