FTD 사전 필터 정책 구성 및 운영

소개

이 문서에서는 FTD(Firepower Threat Defense) 사전 필터 정책의 컨피그레이션 및 작업에 대해 설명합니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

• FTD 코드 6.1.0-195를 실행하는 ASA5506X
• 15.2 이미지를 실행하는 2개의 3925 Cisco IOS® 라우터
• 6.1.0-195를 실행하는 FMC(FireSIGHT Management Center)

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

배경 정보

사전 필터 정책은 버전 6.1에 도입된 기능으로 다음 세 가지 주요 목적을 제공합니다.

1. 내부 및 외부 헤더를 기준으로 트래픽을 확인합니다.
2. 플로우가 Snort 엔진을 완전히 우회할 수 있는 조기 액세스 제어 기능 제공
3. ASA(Adaptive Security Appliance) 마이그레이션 툴에서 마이그레이션된 ACE(Access Control Entry)의 자리 표시자로 작동합니다.

구성

사전 필터 정책 사용 사례 1

사전 필터 정책은 FTD가 내부 및/또는 외부 IP 헤더 터널링 트래픽을 기반으로 필터링할 수 있도록 허용하는 터널 규칙 유형을 사용할 수 있습니다. 이 문서가 작성되었을 때 터널링된 트래픽은 다음을 나타냅니다.

• IP-in-IP
• IPv6-in-IP
• Teredo 포트 3544
• GRE(Generic Routing Encapsulation)

이미지에 표시된 대로 GRE 터널을 고려하십시오.

GRE 터널을 사용하여 R1에서 R2로 ping할 때 트래픽은 방화벽을 통과합니다.

방화벽이 ASA 디바이스인 경우 외부 IP 헤더를 확인합니다.

ASA# show conn
GRE OUTSIDE 192.168.76.39:0 INSIDE  192.168.75.39:0, idle 0:00:17, bytes 520, flags

방화벽이 Firepower 디바이스인 경우 내부 IP 헤더를 확인합니다.

프리필터 정책을 사용하면 FTD 디바이스는 내부 및 외부 헤더를 기반으로 트래픽을 매칭할 수 있습니다.

요점

사전 필터 정책 사용 사례 2

사전 필터 정책은 조기 액세스 제어를 제공하고 흐름이 Snort 엔진을 완전히 우회하도록 허용할 수 있는 사전 필터 규칙 유형을 사용할 수 있습니다.

작업 1: 기본 사전 필터 정책 확인

작업 요구 사항

기본 사전 필터 정책을 확인합니다.

솔루션

1. Policies(정책) > Access Control(액세스 제어) > Prefilter(사전 필터)로 이동합니다. 이 예에서는 기본 사전 필터 정책이 이미 있습니다.

2. 정책 설정을 보려면 편집을 선택합니다.

3. 사전 필터 정책이 액세스 제어 정책에 이미 연결되어 있습니다.

CLI(LINA) 확인

사전 필터 규칙이 ACL 위에 추가됩니다.

firepower# show access-list
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
            alert-interval 300
access-list CSM_FW_ACL_; 5 elements; name hash: 0x4a69e3f3
access-list CSM_FW_ACL_ line 1 remark rule-id 9998: PREFILTER POLICY: Default Tunnel and Priority Policy
access-list CSM_FW_ACL_ line 2 remark rule-id 9998: RULE: DEFAULT TUNNEL ACTION RULE
access-list CSM_FW_ACL_ line 3 advanced permit ipinip any any rule-id 9998 (hitcnt=0) 0xf5b597d6
access-list CSM_FW_ACL_ line 4 advanced permit 41 any any rule-id 9998 (hitcnt=0) 0x06095aba
access-list CSM_FW_ACL_ line 5 advanced permit gre any any rule-id 9998 (hitcnt=5) 0x52c7a066
access-list CSM_FW_ACL_ line 6 advanced permit udp any any eq 3544 rule-id 9998 (hitcnt=0) 0xcf6309bc

작업 2: 태그로 터널링된 트래픽 차단

작업 요구 사항

GRE 터널 내에서 터널링되는 ICMP 트래픽을 차단합니다.

솔루션

1. 이러한 ACP를 적용할 경우 GRE 터널을 통과하거나 통과하지 않더라도 ICMP(Internet Control Message Protocol) 트래픽이 차단되는 것을 볼 수 있습니다.

R1# ping 192.168.76.39
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.76.39, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R1# ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

이 예에서는 사전 필터 정책을 사용하여 작업 요구 사항을 충족할 수 있습니다. 논리는 다음과 같습니다.

• GRE 내부에서 캡슐화된 모든 패킷에 태그를 지정합니다.
• 태그가 지정된 패킷과 일치하고 ICMP를 차단하는 액세스 제어 정책을 생성합니다. 

아키텍처 관점에서, 패킷은 LINA(LInux Natively) 사전 필터 규칙, Snort 사전 필터 규칙 및 ACP를 기준으로 검사되고, 마지막으로 Snort가 LINA에 삭제를 지시합니다. 첫 번째 패킷은 FTD 디바이스를 통과합니다.

1. 터널링된 트래픽에 대한 태그를 정의합니다.

2. Policies(정책) > Access Control(액세스 제어) > Prefilter(사전 필터)로 이동하여 새 사전 필터 정책을 생성합니다. 기본 사전 필터 정책은 편집할 수 없습니다.

사전 필터 정책 내에서 두 가지 유형의 규칙을 정의합니다.

• 터널 규칙
• 사전 필터 규칙

이 두 기능은 사전 필터 정책에서 구성할 수 있는 완전히 다른 기능이라고 생각할 수 있습니다. 이 작업을 위해 터널 규칙: 을(를) 정의해야 합니다.

이 표에서는 각 작업에 대한 간단한 설명과 함께 작업을 정의합니다.

2. 태그가 지정된 트래픽에 대한 액세스 제어 정책 정의

• 처음에는 직관적이지 않지만 액세스 제어 정책 규칙에서 터널 태그를 소스 영역으로 사용할 수 있습니다. Policies(정책) > Access Control(액세스 제어)로 이동하고 태그된 트래픽에 대해 ICMP를 차단하는 규칙을 생성합니다.

참고: 새 사전 필터 정책이 액세스 제어 정책에 연결됩니다.

확인

LINA 및 CLISH에서 캡처를 활성화합니다.

firepower# show capture
capture CAPI type raw-data trace interface inside [Capturing - 152 bytes]
capture CAPO type raw-data trace interface outside [Capturing - 152 bytes]

> capture-traffic
Please choose domain to capture traffic from:
  0 - br1
  1 - Router

Selection? 1

Please specify tcpdump options desired.
(or enter '?' for a list of supported options)
Options: -n

R1에서 원격 GRE 터널 엔드포인트에 ping을 시도합니다. ping이 실패합니다.

R1# ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

CLISH 캡처는 첫 번째 에코 요청이 FTD를 거쳤으며 응답이 차단되었음을 보여줍니다.

Options: -n
18:21:07.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 0, length 80
18:21:07.759939 IP 192.168.76.39 > 192.168.75.39: GREv0, length 104: IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 65, seq 0, length 80
18:21:09.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 1, length 80
18:21:11.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 2, length 80
18:21:13.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 3, length 80
18:21:15.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 4, length 80

LINA 캡처는 다음을 확인합니다.

> show capture CAPI | include ip-proto-47
 102: 18:21:07.767523  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
 107: 18:21:09.763739  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
 111: 18:21:11.763769  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
 115: 18:21:13.763784  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
 120: 18:21:15.763830  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
>
> show capture CAPO | include ip-proto-47
  93: 18:21:07.768133  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
  94: 18:21:07.768438  192.168.76.39 > 192.168.75.39:  ip-proto-47, length 104

CLISH firewall-engine-debug를 활성화하고 LINA ASP 삭제 카운터를 지우고 동일한 테스트를 완료합니다. CLISH 디버그는 Echo-Request에 대해 프리필터 규칙과 일치했으며 Echo-Reply에 대해 ACP 규칙을 매칭했음을 보여줍니다.

10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 New session
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 uses prefilter rule 268434441 with tunnel zone 1
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 Starting with minimum 0, id 0 and SrcZone first with zones 1 -> -1, geo 0 -> 0, vlan 0, sgt tag: 65535, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 8, icmpCode 0
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 pending rule order 3, 'Block ICMP', AppId
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 uses prefilter rule 268434441 with tunnel zone 1
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 Starting with minimum 0, id 0 and SrcZone first with zones 1 -> -1, geo 0 -> 0, vlan 0, sgt tag: 65535, svc 3501, payload 0, client 2000003501, misc 0, user 9999997, icmpType 0, icmpCode 0
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 match rule order 3, 'Block ICMP', action Block
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 deny action

ASP 삭제는 Snort가 패킷을 삭제한 것을 보여줍니다.

> show asp drop

Frame drop:
  No route to host (no-route)                                     366
  Reverse-path verify failed (rpf-violated)                         2
  Flow is denied by configured rule (acl-drop)                      2
  Snort requested to drop the frame (snort-drop)                    5

Connection Events(연결 이벤트)에서 매칭한 Prefilter Policy and Rule(사전 필터 정책 및 규칙)을 볼 수 있습니다.

작업 3: Fastpath Prefilter 규칙으로 Snort 엔진 우회

네트워크 다이어그램

작업 요구 사항

1. 현재 액세스 제어 정책 규칙을 제거하고 모든 트래픽을 차단하는 액세스 제어 정책 규칙을 추가합니다.
2. 192.168.75.0/24 네트워크에서 소싱된 트래픽에 대해 Snort Engine을 우회하는 Prefilter Policy 규칙을 구성합니다.

솔루션

1. 모든 트래픽을 차단하는 액세스 제어 정책:

2. 소스 네트워크 192.168.75.0/24에 대한 작업으로 Fastpath가 포함된 사전 필터 규칙을 추가합니다.

3. 다음 이미지에 결과가 표시됩니다.

4. 저장 및 배포.

두 FTD 인터페이스에서 추적을 사용하여 캡처를 활성화합니다.

firepower# capture CAPI int inside trace match icmp any any
firepower# capture CAPO int outsid trace match icmp any any

FTD를 통해 R1(192.168.75.39)에서 R2(192.168.76.39)로 ping을 시도합니다. ping 실패:

R1# ping 192.168.76.39
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.76.39, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

내부 인터페이스의 캡처에는 다음이 표시됩니다.

firepower# show capture CAPI

5 packets captured

   1: 23:35:07.281738   192.168.75.39 > 192.168.76.39: icmp: echo request
   2: 23:35:09.278641   192.168.75.39 > 192.168.76.39: icmp: echo request
   3: 23:35:11.279251   192.168.75.39 > 192.168.76.39: icmp: echo request
   4: 23:35:13.278778   192.168.75.39 > 192.168.76.39: icmp: echo request
   5: 23:35:15.279282   192.168.75.39 > 192.168.76.39: icmp: echo request
5 packets shown

첫 번째 패킷의 추적(echo-request)은 (강조된 중요 사항):

외부 인터페이스의 캡처 기능은 다음과 같습니다.

firepower# show capture CAPO

10 packets captured

   1: 23:35:07.282044   192.168.75.39 > 192.168.76.39: icmp: echo request
   2: 23:35:07.282227   192.168.76.39 > 192.168.75.39: icmp: echo reply
   3: 23:35:09.278717   192.168.75.39 > 192.168.76.39: icmp: echo request
   4: 23:35:09.278962   192.168.76.39 > 192.168.75.39: icmp: echo reply
   5: 23:35:11.279343   192.168.75.39 > 192.168.76.39: icmp: echo request
   6: 23:35:11.279541   192.168.76.39 > 192.168.75.39: icmp: echo reply
   7: 23:35:13.278870   192.168.75.39 > 192.168.76.39: icmp: echo request
   8: 23:35:13.279023   192.168.76.39 > 192.168.75.39: icmp: echo reply
   9: 23:35:15.279373   192.168.75.39 > 192.168.76.39: icmp: echo request
  10: 23:35:15.279541   192.168.76.39 > 192.168.75.39: icmp: echo reply
10 packets shown

반환 패킷의 추적은 현재 흐름(52)과 일치하지만 ACL에 의해 차단됨을 보여줍니다.

firepower# show capture CAPO packet-number 2 trace

10 packets captured

   2: 23:35:07.282227       192.168.76.39 > 192.168.75.39: icmp: echo reply
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found flow with id 52, uses current flow

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268434432 event-log flow-start
access-list CSM_FW_ACL_ remark rule-id 268434432: ACCESS POLICY: ACP_5506-1 - Default/1
access-list CSM_FW_ACL_ remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

5. 반환 트래픽에 대한 사전 필터 규칙을 하나 더 추가하면 다음 이미지에 결과가 표시됩니다

이제 표시되는 반환 패킷을 추적합니다(중요 포인트가 강조 표시됨).

다음을 확인합니다.

이 섹션을 사용하여 구성이 제대로 작동하는지 확인하십시오. 확인에 대해서는 각 작업 섹션에서 설명했습니다.

문제 해결

현재 이 구성의 문제를 해결하는 데 사용할 수 있는 특정 정보가 없습니다.

관련 정보

• 모든 버전의 Cisco Firepower Management Center 컨피그레이션 가이드는 Navigating the Cisco Secure Firewall Threat Defense Documentation에서 찾을 수 있습니다

• Cisco TAC(Global Technical Assistance Center)에서는 Cisco FTD(Firepower 위협 방어)에 따라 이 문서에서 언급한 기술을 포함하여 Cisco Firepower Next Generation Security 기술에 대한 심층적인 실무 지식을 얻을 수 있도록 이 시각적 가이드를 적극 권장합니다

• 모든 컨피그레이션 및 트러블슈팅 TechNotes는 Cisco Secure Firewall Management Center를 참조하십시오

• 기술 지원 및 문서 − Cisco Systems