ACL의 순서, 방향과 와일드카드

01ACL은 순서가 있는 조건과 동작의 목록

• 순서와 첫 일치ACL의 개별 항목인 ACE는 패킷의 필드를 조건과 비교해 permit 또는 deny를 결정한다. 일반적인 IOS IPv4 인터페이스 ACL은 위에서 아래로 검사하며 처음 일치한 항목에서 평가를 끝낸다.

  • 더 아래의 규칙이 더 구체적이라는 이유로 재평가하지 않는다.
  • 따라서 넓은 permit을 먼저 놓으면 뒤의 세부 deny가 가려지고, 앞의 deny는 뒤의 permit으로 뒤집히지 않는다.
• 암시적 거부마지막까지 일치하지 않은 패킷에는 묵시적 거부가 적용된다. permit을 한 개 넣었다는 사실은 허용할 범위를 정한 것이며 다른 통신이 필요하면 그 조건도 표현해야 한다.

  • 반대로 끝에 permit ip any any를 추가하면 그 앞에서 거부하지 않은 모든 IPv4가 허용된다.
  • 이는 편의상 항상 넣는 마무리 문장이 아니라 정책의 허용 범위를 바꾸는 명령이다.

02Standard와 Extended, 이름과 번호

• Standard·Extended표준 IPv4 ACL은 주로 출발지 주소를 조건으로 삼는다. 예를 들어 한 부서의 출발지 대역을 막으면 그 ACL이 적용된 지점을 지나는 여러 목적지 서비스가 함께 영향을 받는다.

  • 확장 ACL은 프로토콜, 출발지·목적지 주소, TCP/UDP 포트, ICMP 유형 등의 조건을 세분화한다.
  • IP·ICMP·GRE·ESP는 모두 같은 L4 포트 구조를 가지는 것이 아니므로 프로토콜에 없는 포트를 억지로 붙이지 않는다.
• 이름·번호번호는 목록 종류와 식별을 나타내는 전통적 방식이며 Standard 1–99와 Extended 100–199 외에 확장된 번호 범위도 있다. Named ACL은 의미 있는 이름과 sequence 번호로 순서를 관리한다.

  • remark는 설명 항목이며 패킷을 허용하지 않는다.
  • sequence는 평가 순서이지 패킷의 우선순위나 QoS 등급이 아니다.

03와일드카드를 비트 비교로 계산하기

• 비트 비교와일드카드의 0비트는 주소가 같아야 하는 위치, 1비트는 무시할 위치이다. 비교 식은 packet_address AND NOT wildcard = rule_address AND NOT wildcard로 생각할 수 있다.

  • 192.0.2.128 0.0.0.63은 마지막 6비트를 무시하므로 .128~.191이 맞는다.
  • 192.0.2.0 0.0.0.255는 /24 범위를 나타내고 host 192.0.2.10은 와일드카드 0.0.0.0과 같다.
• 연속·비연속 마스크연속 프리픽스를 표현할 때는 서브넷 마스크의 반전을 흔히 사용하지만 와일드카드는 비연속 비트도 허용한다. 예를 들어 192.0.2.0과 0.0.0.254는 마지막 옥텟의 최하위 비트만 비교하므로 그 /24의 짝수 주소에 맞는다.

  • 이것은 네트워크를 둘로 나누는 서브넷 마스크가 아니라 여러 개별 주소를 선택하는 조건이다.

05Source port와 Destination port의 위치

• TCP 포트 방향클라이언트 192.0.2.10:51000이 서버 203.0.113.20:443에 TCP 연결을 요청하면 목적지 포트는 443이다. 서버의 응답에서는 출발지 포트가 443이고 목적지 포트는 51000이다.

  • 한쪽 인터페이스에 요청용 destination eq 443 조건을 반대 방향 그대로 붙이면 응답에는 맞지 않는다.
• 조건의 위치확장 ACL에서 출발지 주소 다음의 포트 연산자는 출발지 포트를, 목적지 주소 다음의 연산자는 목적지 포트를 검사한다. eq·neq·lt·gt·range는 수치 비교 방식이다.

  • 포트 이름 대신 번호를 쓰면 어떤 프로토콜 값인지 더 명확하게 확인할 수 있다.
  • TCP와 UDP의 같은 포트 번호는 각각 별도의 프로토콜 조건이므로 UDP 53 허용이 TCP 53도 자동 허용하지 않는다.

06첫 일치 규칙으로 패킷을 판정하는 순서

• 정책 범위G0/0이 클라이언트 쪽이다. .10의 HTTPS만 서버 .20에 허용하고 그 서버행 다른 IPv4는 거부하며 다른 목적지는 허용하는 한 방향 예다.
• 예상 결과.10→.20 TCP 443은 sequence 10, .11→.20 TCP 443과 .10→.20 ICMP는 sequence 20에서 판정한다. .10→다른 서버 TCP 443은 sequence 30에서 허용된다.
• 의도된 거부이 정책에서 서버 .20의 ping 실패는 예상 결과다. 예제는 다른 방향과 전체 네트워크의 보안 정책을 대신하지 않는다.

1. 적용 지점 도착패킷이 G0/0의 ACL 적용 방향으로 들어온다. 출발지·목적지·프로토콜·포트를 규칙 조건과 비교한다.
2. Sequence 10 비교.10이 .20의 TCP 443으로 보내는 패킷이면 permit하고 검사를 끝낸다. 맞지 않으면 다음 항목으로 간다.
3. Sequence 20 비교앞에서 허용되지 않은 .20행 IPv4이면 deny하고 끝낸다. ICMP도 이 규칙에 해당한다.
4. Sequence 30 비교앞의 두 규칙에 해당하지 않는 IPv4를 permit한다. 실제 ACL에서는 끝까지 일치하지 않은 패킷의 암시적 deny도 고려한다.

ip access-list extended CLIENT-SERVER
 5 remark Only client-10 may use HTTPS on server-20
 10 permit tcp host 192.0.2.10 host 203.0.113.20 eq 443
 20 deny ip any host 203.0.113.20
 30 permit ip any any
interface GigabitEthernet0/0
 ip access-group CLIENT-SERVER in
end

IOS Named Extended ACL. 실제 인터페이스와 정책을 가정한 문서용 예이다.

08In/Out은 장비 인터페이스 기준이다

• 인터페이스 In·Out클라이언트가 외부 서버로 요청할 때 내부 인터페이스에서는 in이고 외부 인터페이스에서는 out이다. 응답은 외부에서 in, 내부로 out이다.

  • 사용자 관점의 업로드·다운로드와 인터페이스 방향 이름을 바로 대응시키면 정책이 반대쪽에 붙을 수 있다.
  • 기본적인 라우터 전달에서 inbound는 경로 선택 전에, outbound는 출력 인터페이스 결정 뒤에 적용된다.
• 배치와 응답표준 ACL은 목적지 구분이 약하므로 통상 목적지 가까이, 확장 ACL은 불필요한 전달을 일찍 줄이도록 출발지 가까이 두는 원칙이 있다. 이것은 항상 지켜야 할 문법 조건이 아니다.

  • 공통 경계, 비대칭 경로, 관리 목적에 따라 위치가 달라진다.
  • NAT가 함께 있으면 제품 처리 순서에서 해당 ACL이 변환 전후 어느 주소를 보는지도 달라진다.

09패킷 필터와 연결 상태의 차이

• Stateless 필터전통적인 ACL은 각 패킷의 필드를 비교하며 TCP 세션의 정상 시작·순서·종료를 완전하게 추적하지 않는다. IOS의 TCP established 키워드는 ACK 또는 RST 비트 조건을 이용하는 방식이지 앞선 SYN 교환이 정상적으로 있었음을 기억하는 상태 방화벽이 아니다.

  • 일반 패킷 필터의 허용 결과만으로 상대가 인증되었다고 볼 수도 없다.
• 후속 조각IPv4의 후속 fragment에는 TCP/UDP 헤더가 없을 수 있어 포트 조건을 같은 방법으로 읽을 수 없다. 플랫폼의 fragment 평가 규칙이 있으며 단순히 모든 조각에도 같은 포트가 있다고 설명하면 안 된다.

  • 반사 ACL, 시간 기반 ACL, 상태 방화벽은 별도 기능이며 이 글의 기본 ACL 예와 동작 범위가 다르다.
  • IPv6 ACL에는 ND 등 제어 메시지와 관련된 기본 동작 차이가 있으므로 IPv4 규칙을 그대로 복사하지 않는다.

10정의·적용·일치 카운터를 함께 읽기

• 정의·적용ACL 목록을 만들기만 하면 인터페이스 필터로 동작하지 않는다. ip access-group으로 특정 인터페이스와 방향에 연결해야 한다.

  • show ip interface는 실제 적용 목록을, show access-lists는 ACE와 match 수를 보여준다.
  • 삭제 역시 인터페이스 참조를 해제하는 것과 ACL 정의를 지우는 것이 별개이다.
  • 같은 ACL을 NAT나 다른 기능도 참조할 수 있다.
• 일치 카운터예시 정책으로 .10의 HTTPS 시험을 했는데 sequence 10 카운터가 증가하면 해당 조건에 맞았음을 뜻한다. 애플리케이션 성공 전체를 입증하는 것은 아니다.

  • 카운터가 0이면 패킷이 다른 인터페이스를 지났거나 주소·방향·포트 조건이 다른 가능성이 있다.
  • 누적값 한 번보다 시험 전후 증가량을 비교하면 여러 시험이 섞이는 문제를 줄일 수 있다.

show ip interface GigabitEthernet0/0
! Inbound access list is CLIENT-SERVER
show access-lists CLIENT-SERVER
! 10 permit tcp host 192.0.2.10 host 203.0.113.20 eq 443 (3 matches)
! 20 deny ip any host 203.0.113.20 (2 matches)
! 30 permit ip any any (5 matches)
show running-config interface GigabitEthernet0/0

조회 명령과 기대되는 형식 예. 숫자는 해석용이다.

11다른 기능이 ACL을 참조할 때의 의미

• NAT·라우팅 참조NAT의 분류 ACL에서 permit은 변환 대상, deny는 그 규칙의 변환 대상에서 제외한다는 뜻이다. 라우팅의 distribute-list나 route-map이 참조하면 대상은 사용자 데이터 패킷이 아니라 경로 정보일 수 있다.

  • 같은 단어 permit을 사용해도 어떤 기능이 목록을 소비하는지에 따라 결과가 다르다.
  • “ACL에서 deny이므로 모든 위치에서 패킷을 폐기한다”는 설명은 성립하지 않는다.
• iSCSI ACL스토리지 수업의 iSCSI ACL은 initiator의 IQN 접근 허용을 다룬다. 라우터의 IP 패킷 ACL과 이름은 같지만 검사하는 대상이 다르다.

  • ASA의 장비 자체를 향한 ICMP 허용 명령과 통과 트래픽의 ICMP inspection 역시 별개이다.
  • 같은 ACL의 permit도 참조한 기능에 따라 의미가 달라진다.