Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

논리적 시스템상의 방화벽 필터

방화벽 필터는 인터페이스를 전송하는 패킷을 허용하거나 폐기하도록 정의하는 규칙을 제공합니다. 자세한 내용은 다음 주제를 참조하십시오.

표준 방화벽 필터 사용 방법 이해

표준 방화벽 필터를 사용하여 로컬 패킷에 영향

라우터에서 인터페이스에서 하나의 물리적 루프백 인터페이스, lo0 및 하나 이상의 주소를 구성할 수 있습니다. 루프백 인터페이스는 모든 제어 프로토콜을 실행하고 모니터링하는 Routing Engine의 인터페이스입니다. 루프백 인터페이스는 로컬 패킷만 전달합니다. 루프백 인터페이스에 적용되는 표준 방화벽 필터는 라우팅 엔진에서 전송하거나 전송되는 로컬 패킷에 영향을 줍니다.

참고:

추가 루프백 인터페이스를 만들면 라우팅 엔진이 보호되도록 필터를 적용하는 것이 중요합니다. 루프백 인터페이스에 필터를 적용할 때 적용 그룹 명령문을 포함하는 것이 좋습니다. 이를 통해 필터가 lo0 및 기타 루프백 인터페이스를 비롯한 모든 루프백 인터페이스에 자동으로 상속됩니다.

신뢰할 수 있는 소스

일반적으로 표준 스테이트리스 방화벽 필터 를 사용하는 것은 라우팅 엔진 프로세스와 리소스를 악의적 또는 신뢰할 수 없는 패킷으로부터 보호하는 것입니다. Routing Engine이 소유한 프로세스와 리소스를 보호하기 위해 어떤 프로토콜과 서비스 또는 애플리케이션이 라우팅 엔진에 도달할 수 있는지 지정하는 표준 스테이트리스 방화벽 필터를 사용할 수 있습니다. 루프백 인터페이스에 이러한 유형의 필터를 적용하면 로컬 패킷이 신뢰할 수 있는 소스에서 전송되도록 보장하고 외부 공격으로부터 라우팅 엔진에서 실행되는 프로세스를 보호합니다.

플러드 방지

라우팅 엔진으로 향하는 특정 TCP 및 ICMP 트래픽을 제한하는 표준 스테이트리스 방화벽 필터를 생성할 수 있습니다. 이러한 유형의 보호 기능이 없는 라우터는 DoS(Denial-of-Service) 공격이라고도 하는 TCP 및 ICMP 플러드 공격에 취약합니다. 예를 들어:

  • 연결 요청을 시작하는 SYN 패킷에 대한 TCP 플러드 공격은 장비가 더 이상 합법적인 연결 요청을 처리하지 못하면 서비스 거부가 발생할 수 있습니다.

  • ICMP 플러드는 많은 에코 요청(핑 요청)을 통해 디바이스에 과부하를 발생시켜 모든 리소스에 응답하고 더 이상 유효한 네트워크 트래픽을 처리할 수 없으므로 서비스 거부가 발생합니다.

적절한 방화벽 필터를 Routing Engine에 적용함으로써 이러한 유형의 공격을 차단할 수 있습니다.

표준 방화벽 필터를 사용하여 데이터 패킷에 영향을 미치는 경우

라우터의 전송 인터페이스에 적용하는 표준 방화벽 필터는 라우터가 소스에서 대상으로 전달될 때 라우터를 직접 다른 인터페이스로 전송하는 사용자 데이터 패킷만 평가합니다. 특정 인터페이스에서 승인되지 않은 액세스 및 기타 위협으로부터 네트워크를 전체적으로 보호하기 위해 방화벽 필터 라우터 전송 인터페이스를 적용할 수 있습니다.

예: ICMP 플러드로부터 논리적 시스템을 보호하기 위해 스테이트리스 방화벽 필터 구성

이 예에서는 논리적 시스템에서 ICMP 서비스 거부 공격을 방어하는 스테이트리스 방화벽 필터를 구성하는 방법을 보여줍니다.

요구 사항

이 예에서는 디바이스 초기화 이외에는 특별한 구성이 필요하지 않습니다.

개요

이 예에서는 ICMP 패킷을 정책으로 표시하는 protect-RE라는 스테이트리스 방화벽 필터를 보여 줍니다. icmp-policer ICMP 패킷의 트래픽 속도를 1,000,000bpps로 제한하고 버스트 크기는 15,000바이트로 제한합니다. 트래픽 속도를 초과하는 패킷은 폐기됩니다.

폴리서가 라는 필터 용어 icmp-term의 동작에 통합됩니다.

이 예에서는 핑이 직접 연결된 물리적 라우터에서 논리적 시스템에서 구성된 인터페이스로 전송됩니다. 이 논리적 시스템은 최대 1Mbps(대역폭 제한)의 속도로 수신되는 경우 ICMP 패킷을 허용합니다. 이 속도를 초과하면 논리적 시스템에서 모든 ICMP 패킷을 드롭합니다. 이 문은 burst-size-limit 최대 15Kbps의 트래픽 버스트를 허용합니다. 버스트가 이 한도를 초과하면 모든 패킷은 드롭됩니다. 플로우 속도가 가라앉으면 ICMP 패킷이 다시 수락됩니다.

토폴로지

그림 1 은 이 예에서 사용된 토폴로지입니다.

그림 1: 스테이트리스 방화벽 Logical System with a Stateless Firewall 이 있는 논리적 시스템

구성

CLI 빠른 구성

이 예제를 신속하게 구성하려면 다음 명령을 복사하여 텍스트 파일에 붙여넣고, 줄 바꿈을 제거하고, 네트워크 구성에 필요한 세부 정보를 변경한 다음, 명령을 복사하여 계층적 수준에서 CLI [edit] 에 붙여넣습니다.

절차

단계별 절차

다음 예제에서는 구성 계층에서 다양한 레벨을 탐색해야 합니다. CLI 탐색에 대한 자세한 내용은 CLI 사용자 가이드의 Configuration 모드에서 CLI Editor를 사용하십시오.

논리적 시스템에서 ICMP 방화벽 필터를 구성하려면 다음을 수행합니다.

  1. 논리적 시스템에서 인터페이스를 구성합니다.

  2. 인터페이스에서 ICMP 패킷을 명시적으로 수신할 수 있습니다.

  3. 폴리서 생성.

  4. 폴리서(policer)를 필터 용어에 적용합니다.

  5. 폴리서가 논리적 시스템 인터페이스에 적용됩니다.

  6. 디바이스 구성을 완료한 경우 구성을 커밋합니다.

결과

명령을 발행하여 구성을 show logical-systems LS1 확인합니다.

확인

구성이 올바르게 작동하는지 확인합니다.

한계를 초과하지 않는 한 핑이 작동하는지 검증

목적

논리적 시스템 인터페이스가 ICMP 기반 DoS 공격으로부터 보호되는지 확인합니다.

작업

논리적 시스템에 연결된 시스템에 로그인하여 명령을 실행합니다 ping .

의미

일반 핑을 보낼 때 패킷이 허용됩니다. 필터 제한을 초과하는 핑 패킷을 보낼 때 패킷은 폐기됩니다.

예: 논리적 시스템에서 필터 기반 포워딩 구성

이 예에서는 논리적 시스템 내에서 필터 기반 포워딩을 구성하는 방법을 보여줍니다. 필터는 패킷을 분류하여 수신 라우팅 디바이스 내에서 포워딩 경로를 결정합니다.

요구 사항

이 예에서는 디바이스 초기화 이외에는 특별한 구성이 필요하지 않습니다.

개요

필터 기반 포워딩은 IP 버전 4(IPv4) 및 IP 버전 6(IPv6)에 대해 지원됩니다.

다양한 ISP가 제공하는 인터넷 연결을 보유하고 있지만 공통 액세스 레이어를 공유할 때는 서비스 프로바이더를 선택할 수 있도록 필터 기반 포워딩을 사용합니다. 공유 미디어(예: 케이블 모뎀)를 사용하면 공통 액세스 레이어의 메커니즘이 레이어 2 또는 레이어 3 주소를 보고 고객을 구분합니다. Layer 2 스위치와 단일 라우터의 조합을 사용하여 공통 액세스 레이어를 구현할 때 필터 기반 포워딩을 사용할 수 있습니다.

필터 기반 포워딩을 사용하면 인터페이스에서 수신되는 모든 패킷이 고려됩니다. 각 패킷은 조건에 맞는 필터를 통과합니다. 필터에 대한 일치 조건이 충족되고 라우팅 인스턴스를 생성한 경우 필터 기반 포워딩이 패킷에 적용됩니다. 패킷은 라우팅 인스턴스에 지정된 다음 홉을 기준으로 포워딩됩니다. 정적 경로의 경우, 다음 홉은 특정 LSP일 수 있습니다.

참고:

소스 클래스 사용 필터 매칭 및 유니캐스트 역방향 경로 포워딩 검사는 필터 기반 포워딩(FBF)으로 구성된 인터페이스에서 지원되지 않습니다.

필터 기반 포워딩을 구성하려면 다음 작업을 수행합니다.

  • 수신 라우터 또는 스위치에서 일치 필터를 만듭니다. 일치 필터를 지정하려면 계층 수준에서 명령문을 [edit firewall] 포함 filter filter-name 하십시오. 필터를 통과하는 패킷을 일련의 규칙과 비교하여 분류하고 집합에서 멤버쉽을 결정합니다. 일단 분류되면 패킷은 필터 설명 언어의 허용 동작에 지정된 라우팅 테이블로 전달됩니다. 그런 다음 라우팅 테이블은 테이블의 대상 주소 입력에 해당하는 다음 홉으로 패킷을 전달합니다.

  • 패킷이 포워딩되는 라우팅 테이블과 패킷이 전달되는 대상을 [edit logical-systems logical-system-name routing-instances] 지정하는 라우팅 인스턴스를 [edit routing-instances] 생성합니다. 예를 들어:

  • FBF(filter-based forwarding)와 기본 라우팅 인스턴스inet.0에 사용되는 포워딩 라우팅 인스턴스에 인터페이스 경로를 추가하는 라우팅 테이블 그룹을 생성합니다. 이 구성 부분은 라우팅 인스턴스에 설치된 경로를 해당 인터페이스의 다음 홉에 직접 연결하도록 해결합니다. 또는 [edit logical-systems logical-system-name routing-options] 계층 수준에서 라우팅 테이블 그룹을 [edit routing-options] 만듭니다.

참고:

인터페이스 경로가 임포트되는 라우팅 인스턴스 중 하나로 지정 inet.0 합니다. 기본 인스턴스 inet.0 가 지정되지 않으면 인터페이스 경로가 기본 라우팅 인스턴스로 가져오지 않습니다.

이 예에서는 패킷의 소스 주소를 기반으로 고객 트래픽을 도메인, SP 1 또는 SP 2의 넥스 홉 라우터로 전송하는 패킷 필터를 보여줍니다.

패킷에 SP 1 고객에게 할당된 소스 주소가 있는 경우 sp1-route-table.inet.0 라우팅 테이블을 사용하여 대상 기반 포워딩이 발생합니다. 패킷에 SP 2 고객에게 할당된 소스 주소가 있는 경우 sp2-route-table.inet.0 라우팅 테이블을 사용하여 대상 기반 포워딩이 발생합니다. 패킷이 이러한 조건 중 하나와 일치하지 않으면 필터가 패킷을 허용하며, 표준 inet.0 라우팅 테이블을 사용하여 대상 기반 포워딩이 수행됩니다.

논리적 시스템 내에서 필터 기반 포워딩 작업을 수행하는 한 가지 방법은 패킷을 수신하는 논리적 시스템에서 방화벽 필터를 구성하는 것입니다. 또 다른 방법은 주 라우터에서 방화벽 필터를 구성한 다음 방화벽 필터의 논리적 시스템을 참조하는 것입니다. 이 예에서는 두 번째 접근 방식을 사용합니다. 특정 라우팅 인스턴스는 논리적 시스템 내에서 구성됩니다. 각 라우팅 인스턴스에는 고유 라우팅 테이블이 있으므로 방화벽 필터에서도 라우팅 인스턴스를 참조해야 합니다. 구문은 다음과 같습니다.

토폴로지

그림 2 는 이 예에서 사용된 토폴로지입니다.

논리적 시스템 P1에서 입력 필터는 논리적 시스템 PE3 및 논리적 시스템 PE4로부터 받은 패킷을 분류합니다. 패킷은 소스 주소를 기반으로 라우팅됩니다. 10.1.1.0/24 및 10.1.2.0/24 네트워크에 소스 주소가 있는 패킷은 논리적 시스템 PE1로 라우팅됩니다. 10.2.1.0/24 및 10.2.2.0/24 네트워크에 소스 주소를 가진 패킷은 논리적 시스템 PE2로 라우팅됩니다.

그림 2: 필터 기반 포워딩을 지원하는 Logical Systems with Filter-Based Forwarding 논리적 시스템

연결을 설정하기 위해 OSPF는 모든 인터페이스에 구성됩니다. 데모를 위해 루프백 인터페이스 주소는 라우팅 디바이스에서 구성되어 클라우드의 네트워크를 나타냅니다.

CLI Quick Configuration 섹션에는 토폴로지의 모든 디바이스에 대한 전체 구성이 표시됩니다. 기본 라우터 섹션에서 논리적 시스템 P1에서 라우팅 인스턴스 구성방화벽 필터 구성은 수신 라우팅 디바이스인 논리적 시스템 P1의 단계별 구성을 보여줍니다.

구성

CLI 빠른 구성

이 예제를 신속하게 구성하려면 다음 명령을 복사하여 텍스트 파일에 붙여넣고, 줄 바꿈을 제거하고, 네트워크 구성에 필요한 세부 정보를 변경한 다음 [ 편집] 계층 수준에서 CLI에 명령을 복사하여 붙여넣습니다.

메인 라우터에서 방화벽 필터 구성

단계별 절차

다음 예제에서는 구성 계층에서 다양한 레벨을 탐색해야 합니다. CLI 탐색에 대한 자세한 내용은 CLI 사용자 가이드의 Configuration Mode에서 CLI Editor를 사용하는 것을 참조하십시오.

주 라우터에서 방화벽 필터를 구성하려면 다음을 수행합니다.

  1. SP1 고객을 위해 소스 주소를 구성합니다.

  2. 지정된 소스 주소로 패킷이 수신될 때 수행되는 작업을 구성합니다.

    방화벽 필터의 동작을 추적하기 위해 로그 작업이 구성됩니다. 논리적 시스템 P1의 sp1-route-table.inet.0 라우팅 테이블은 패킷을 라우팅합니다.

  3. SP2 고객을 위해 소스 주소를 구성합니다.

  4. 지정된 소스 주소로 패킷이 수신될 때 수행되는 작업을 구성합니다.

    방화벽 필터의 동작을 추적하기 위해 로그 작업이 구성됩니다. 논리적 시스템 P1의 sp2-route-table.inet.0 라우팅 테이블은 패킷을 라우팅합니다.

  5. 패킷이 다른 소스 주소로부터 수신될 때 수행할 작업을 구성합니다.

    이러한 모든 패킷은 기본 IPv4 유니캐스트 라우팅 테이블인 inet.0을 사용하여 간편하게 수락되고 라우팅됩니다.

논리적 시스템 P1에서 라우팅 인스턴스 구성

단계별 절차

다음 예제에서는 구성 계층에서 다양한 레벨을 탐색해야 합니다. CLI 탐색에 대한 자세한 내용은 CLI 사용자 가이드의 Configuration Mode에서 CLI Editor를 사용하는 것을 참조하십시오.

논리적 시스템에서 라우팅 인스턴스를 구성하려면 다음을 수행합니다.

  1. 논리적 시스템에서 인터페이스를 구성합니다.

  2. 방화벽 필터를 classify-customers 라우터 인터페이스 lt-1/2/0.10에 입력 패킷 필터로 할당합니다.

  3. 라우팅 프로토콜 또는 정적 라우팅을 사용하여 연결을 구성합니다.

    베스트 프랙티스로 관리 인터페이스에서 라우팅을 비활성화합니다.

  4. 라우팅 인스턴스를 만듭니다.

    이러한 라우팅 인스턴스는 방화벽 필터에서 classify-customers 참조됩니다.

    포워딩 인스턴스 유형은 인터페이스가 인스턴스와 연결되지 않은 필터 기반 포워딩을 지원합니다. 모든 인터페이스는 기본 인스턴스에 속하며, 이 경우 논리적 시스템 P1입니다.

  5. 라우팅 인스턴스에 설치된 경로를 해결하여 다음 홉에 직접 연결합니다.

  6. 라우팅 테이블을 함께 그룹화하여 라우팅 테이블 그룹을 구성합니다.

    첫 번째 라우팅 테이블인 inet.0은 기본 라우팅 테이블이며, 추가 라우팅 테이블은 보조 라우팅 테이블입니다.

    기본 라우팅 테이블은 라우팅 테이블 그룹의 주소 제품군(이 경우 IPv4)을 결정합니다.

  7. OSPF에 라우팅 테이블 그룹을 적용합니다.

    이로 인해 OSPF 경로가 그룹의 모든 라우팅 테이블에 설치됩니다.

  8. 디바이스 구성을 완료한 경우 구성을 커밋합니다.

결과

show logical-systems P1 명령을 발행하여 구성을 show firewall 확인합니다.

확인

구성이 올바르게 작동하는지 확인합니다.

지정된 소스 주소를 통한 핑

목적

방화벽 필터를 테스트하기 위해 네트워크를 통해 일부 ICMP 패킷을 보냅니다.

작업
  1. 논리적 시스템 PE3에 로그인합니다.

  2. 논리적 시스템 PE1에서 ping lo0.3 인터페이스를 ping하여 명령을 실행합니다.

    이 인터페이스에서 구성된 주소는 172.16.1.1입니다.

    논리 시스템 PE3의 lo0.1 인터페이스에 구성된 주소인 소스 주소 10.1.2.1을 지정합니다.

  3. 논리적 시스템 PE4에 로그인합니다.

  4. 논리적 시스템 PE2에서 ping lo0.4 인터페이스를 ping하여 명령을 실행합니다.

    이 인터페이스에서 구성된 주소는 172.16.2.2입니다.

    논리 시스템 PE4의 lo0.2 인터페이스에 구성된 주소인 소스 주소 10.2.1.1을 지정합니다.

의미

이러한 핑을 전송하여 방화벽 필터 작업을 활성화합니다.

방화벽 필터 검증

목적

방화벽 필터 작업이 적용되는지 확인합니다.

작업
  1. 논리적 시스템 P1에 로그인합니다.

  2. show firewall log 논리적 시스템 P1에서 명령을 실행합니다.