firepower 방화벽 캡처를 분석하여 네트워크 문제 해결
목차
소개
이 문서에서는 네트워크 문제를 효과적으로 해결하기 위한 다양한 패킷 캡처 분석 기술에 대해 설명합니다.
사전 요구 사항
요구 사항
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
- Firepower 플랫폼 아키텍처
- NGFW 로그
- NGFW 패킷 추적기
또한 패킷 캡처를 분석하기 전에 다음 요구 사항을 충족하는 것이 좋습니다.
- 프로토콜 작업 파악 - 캡처된 프로토콜의 작동 방식을 모르는 경우 패킷 캡처 확인을 시작하지 마십시오.
- 토폴로지 파악 - 전송 디바이스를 엔드 투 엔드로 알아야 합니다. 이 방법이 불가능한 경우 업스트림 및 다운스트림 디바이스라도 알아야 합니다.
- 어플라이언스 파악 - 디바이스에서 패킷을 처리하는 방법, 관련된 인터페이스(인그레스/이그레스)는 무엇인지, 디바이스 아키텍처는 무엇인지, 다양한 캡처 포인트는 무엇인지 알아야 합니다.
- 컨피그레이션 파악 - 디바이스에서 패킷 플로우를 처리하는 방법을 알아야 합니다.
- 라우팅/이그레스 인터페이스
- 정책 적용됨
- NAT(Network Address Translation)
- 사용 가능한 툴 파악 - 캡처와 함께 다른 툴 및 기술(로깅 및 추적기 등)을 적용할 준비를 하고 필요한 경우 캡처된 패킷과 상호 연결할 것을 권장합니다.
사용되는 구성 요소
이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
- 대부분의 시나리오는 FTD 소프트웨어 6.5.x를 실행하는 FP4140을 기반으로 합니다.
- 소프트웨어 6.5.x를 실행하는 FMC
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
배경 정보
패킷 캡처는 현재 제공되는 가장 간과된 문제 해결 툴 중 하나입니다. 매일 Cisco TAC는 캡처된 데이터 분석으로 많은 문제를 해결합니다.
이 문서의 목표는 주로 패킷 캡처 분석을 기반으로 네트워크 및 보안 엔지니어가 일반적인 네트워크 문제를 식별하고 해결할 수 있도록 지원하는 것입니다.
이 문서에 제시된 모든 시나리오는 Cisco TAC(Technical Assistance Center)에서 볼 수 있는 실제 사용자 사례를 기반으로 합니다.
이 문서에서는 Cisco NGFW(Next-Generation Firewall) 관점에서 패킷 캡처를 다루지만, 다른 디바이스 유형에도 동일한 개념이 적용됩니다.
NGFW 제품군에 대한 캡처를 수집하고 내보내는 방법
firepower 어플라이언스(1xxx, 21xx, 41xx, 93xx) 및 FTD(Firepower Threat Defense) 애플리케이션의 경우 그림과 같이 패킷 처리를 시각화할 수 있습니다.
- 패킷은 인그레스 인터페이스로 들어가고 섀시 내부 스위치에 의해 처리됩니다.
- 패킷은 주로 L3/L4 검사를 수행하는 FTD Lina 엔진에 들어갑니다.
- 정책에 따라 패킷이 Snort 엔진에 의해 검사되어야 하는 경우(주로 L7 검사).
- Snort 엔진이 패킷에 대한 판정을 반환합니다.
- LINA 엔진은 Snort 판정을 기반으로 패킷을 삭제하거나 전달합니다.
- 패킷이 내부 섀시 스위치를 통해 섀시를 이그레스(egress)합니다.
표시된 아키텍처를 기반으로 FTD 캡처는 세 가지 서로 다른 위치에서 수행할 수 있습니다.
- FXOS
- FTD Lina 엔진
- FTD Snort 엔진
FXOS 캡처 수집
이 문서에서는 이 프로세스에 대해 설명합니다.
FXOS 캡처는 여기 이미지에 표시된 내부 스위치 관점에서 인그레스 방향으로만 수행할 수 있습니다.
이 슬라이드에는 내부 스위치 아키텍처로 인해 방향당 2개의 캡처 지점이 나와 있습니다.
포인트 2, 3, 4의 캡처된 패킷에는 VNTag(가상 네트워크 태그)가 있습니다.
FTD Lina 캡처 활성화 및 수집
주요 캡처 지점:
- 인그레스 인터페이스
- 이그레스 인터페이스
- ASP(Accelerated Security Path)
FMC UI(Firepower Management Center User Interface) 또는 FTD CLI를 사용하여 FTD Lina 캡처를 활성화하고 수집할 수 있습니다.
INSIDE 인터페이스의 CLI에서 캡처를 활성화합니다.
firepower# capture CAPI interface INSIDE match icmp host 192.168.103.1 host 192.168.101.1
이 캡처는 양방향의 IP 192.168.103.1과 192.168.101.1 간의 트래픽과 일치합니다.
FTD Lina 엔진에서 삭제된 모든 패킷을 보려면 ASP 캡처를 활성화합니다.
firepower# capture ASP type asp-drop all
FTP 서버로 FTD Lina 캡처 내보내기:
firepower# copy /pcap capture:CAPI ftp://ftp_username:ftp_password@192.168.78.73/CAPI.pcap
FTD Lina 캡처를 TFTP 서버로 내보냅니다.
firepower# copy /pcap capture:CAPI tftp://192.168.78.73
FMC 6.2.x 버전에서처럼 FMC UI에서 FTD Lina 캡처를 활성화하고 수집할 수 있습니다.
FMC 관리 방화벽에서 FTD 캡처를 수집하는 또 다른 방법은 다음과 같습니다.
1단계
LINA 또는 ASP 캡처의 경우 캡처를 FTD 디스크에 복사합니다.
firepower# copy /pcap capture:capin disk0:capin.pcap Source capture name [capin]? Destination filename [capin.pcap]? !!!!
2단계
expert 모드로 이동하여 저장된 캡처를 찾은 다음 /ngfw/var/common 위치에 복사합니다.
firepower# Console connection detached. > expert admin@firepower:~$ sudo su Password: root@firepower:/home/admin# cd /mnt/disk0 root@firepower:/mnt/disk0# ls -al | grep pcap -rwxr-xr-x 1 root root 24 Apr 26 18:19 CAPI.pcap -rwxr-xr-x 1 root root 30110 Apr 8 14:10 capin.pcap -rwxr-xr-x 1 root root 6123 Apr 8 14:11 capin2.pcap root@firepower:/mnt/disk0# cp capin.pcap /ngfw/var/common
3단계
FTD를 관리하는 FMC에 로그인하고 Devices(디바이스) > Device Management(디바이스 관리)로 이동합니다. FTD 디바이스를 찾고 Troubleshoot(문제 해결) 아이콘을 선택합니다.
4단계
Advanced Troubleshooting(고급 트러블슈팅)을 선택합니다.
캡처 파일 이름을 지정하고 Download(다운로드)를 선택합니다.
FMC UI에서 캡처를 활성화/수집하는 방법에 대한 자세한 예는 이 문서를 참조하십시오.
FTD Snort 캡처 활성화 및 수집
여기 이미지에 캡처 지점이 표시됩니다.
Snort 레벨 캡처 활성화:
> 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 host 192.168.101.1
capture.pcap 이름을 가진 파일에 캡처를 쓰고 FTP를 통해 원격 서버에 복사하려면 다음을 수행합니다.
> 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: -w capture.pcap host 192.168.101.1 CTRL + C <- to stop the capture
> file copy 10.229.22.136 ftp / capture.pcap Enter password for ftp@10.229.22.136: Copying capture.pcap Copy successful. >
다른 캡처 필터를 포함하는 Snort 레벨 캡처 예제를 보려면 다음 문서를 확인하십시오.
문제 해결
사례 1. 이그레스 인터페이스에 TCP SYN 없음
토폴로지는 다음 이미지에 표시됩니다.
문제 설명: HTTP가 작동하지 않음
영향을 받는 흐름:
소스 IP: 192.168.0.100
Dst IP: 10.10.1.100
프로토콜: TCP 80
캡처 분석
FTD LINA 엔진에서 캡처를 활성화합니다.
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
캡처 - 기능 시나리오:
기준 요소로서 기능 시나리오의 캡처를 사용하는 것은 항상 매우 유용합니다.
NGFW INSIDE 인터페이스에서 캡처한 내용은 다음과 같습니다.
요점:
- TCP 3-way 핸드셰이크.
- 양방향 데이터 교환.
- 패킷 간의 시간 차이를 기준으로 패킷 간의 지연 없음
- 소스 MAC는 올바른 다운스트림 디바이스입니다.
NGFW OUTSIDE 인터페이스에서 캡처한 내용은 다음 이미지에 나와 있습니다.
요점:
- CAPI 캡처와 동일한 데이터.
- 대상 MAC는 올바른 업스트림 디바이스입니다.
캡처 - 작동하지 않는 시나리오
디바이스 CLI에서 캡처는 다음과 같습니다.
firepower# show capture capture CAPI type raw-data interface INSIDE [Capturing - 484 bytes] match ip host 192.168.0.100 host 10.10.1.100 capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes] match ip host 192.168.0.100 host 10.10.1.100
CAPI 내용:
firepower# show capture CAPI 6 packets captured 1: 11:47:46.911482 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 11:47:47.161902 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 11:47:49.907683 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 4: 11:47:50.162757 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 11:47:55.914640 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,nop,sackOK> 6: 11:47:56.164710 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,nop,sackOK>
firepower# show capture CAPO 0 packet captured 0 packet shown
다음은 Wireshark의 CAPI 캡처 이미지입니다.
요점:
- TCP SYN 패킷만 표시됩니다(TCP 3-way 핸드셰이크 없음).
- 설정할 수 없는 2개의 TCP 세션(소스 포트 3171 및 3172)이 있습니다. 소스 클라이언트가 TCP SYN 패킷을 다시 전송합니다. 이러한 재전송된 패킷은 Wireshark에 의해 TCP 재전송으로 식별됩니다.
- TCP 재전송은 3초 ~ 6초 간격으로 발생합니다.
- 소스 MAC 주소는 올바른 다운스트림 디바이스에서 가져옵니다.
2개의 캡처를 바탕으로 다음과 같은 결론을 내릴 수 있습니다.
- 특정 5튜플 패킷(src/dst IP, src/dst port, protocol)이 예상 인터페이스(INSIDE)의 방화벽에 도착합니다.
- 패킷이 필요한 인터페이스(OUTSIDE)의 방화벽을 벗어나지 않습니다.
권장 작업
이 섹션에 나와 있는 조치는 문제를 더 좁히기 위한 목적입니다.
작업 1. 에뮬레이트된 패킷의 추적을 확인합니다.
패킷 추적기 툴을 사용하여 패킷이 방화벽에 의해 처리되는 방식을 확인합니다. 패킷이 방화벽 액세스 정책에 의해 삭제되는 경우 에뮬레이트된 패킷의 추적은 이 출력과 유사합니다.
firepower# packet-tracer input INSIDE tcp 192.168.0.100 11111 10.10.1.100 80 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: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE 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 268439946 event-log flow-start access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE Additional Information: Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA
작업 2. 라이브 패킷의 추적을 확인합니다.
실제 TCP SYN 패킷이 방화벽에 의해 처리되는 방식을 확인하려면 패킷 추적을 활성화합니다. 기본적으로 처음 50개의 인그레스 패킷만 추적됩니다.
firepower# capture CAPI trace
캡처 버퍼를 지웁니다.
firepower# clear capture /all
패킷이 방화벽 액세스 정책에 의해 삭제된 경우 추적은 이 출력과 비슷합니다.
firepower# show capture CAPI packet-number 1 trace 6 packets captured 1: 12:45:36.279740 192.168.0.100.3630 > 10.10.1.100.80: S 2322685377:2322685377(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 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: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE 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 268439946 event-log flow-start access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE Additional Information: Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA 1 packet shown
작업 3. FTD Lina 로그를 확인합니다.
FMC를 통해 FTD에서 Syslog를 구성하려면 다음 문서를 확인하십시오.
FTD Lina 로그에 대해 외부 Syslog 서버를 구성하는 것이 좋습니다. 구성된 원격 Syslog 서버가 없는 경우, 문제를 해결하는 동안 방화벽에서 로컬 버퍼 로그를 활성화합니다. 이 예에 표시된 로그 컨피그레이션은 좋은 시작점입니다.
firepower# show run logging … logging enable logging timestamp logging buffer-size 1000000 logging buffered informational
터미널 페이저를 제어하려면 터미널 페이저를 24행으로 설정합니다.
firepower# terminal pager 24
캡처 버퍼를 지웁니다.
firepower# clear logging buffer
연결을 테스트하고 파서 필터로 로그를 확인합니다. 이 예에서는 패킷이 방화벽 액세스 정책에 의해 삭제됩니다.
firepower# show logging | include 10.10.1.100 Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]
작업 4. ASP가 삭제하는 방화벽을 확인합니다.
패킷이 방화벽에 의해 삭제된 것으로 의심되는 경우 소프트웨어 레벨에서 방화벽에 의해 삭제된 모든 패킷의 카운터를 볼 수 있습니다.
firepower# show asp drop Frame drop: No route to host (no-route) 234 Flow is denied by configured rule (acl-drop) 71 Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15 Flow drop: Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15
모든 ASP 소프트웨어 수준 삭제를 보려면 캡처를 활성화할 수 있습니다.
firepower# capture ASP type asp-drop all buffer 33554432 headers-only
캡처 내용을 확인하려면 필터를 사용하여 검색 범위를 좁힐 수 있습니다.
firepower# show capture ASP | include 10.10.1.100 18: 07:51:57.823672 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 19: 07:51:58.074291 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 26: 07:52:00.830370 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 29: 07:52:01.080394 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 45: 07:52:06.824282 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,nop,sackOK> 46: 07:52:07.074230 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,nop,sackOK>
이 경우 패킷은 이미 인터페이스 레벨에서 추적되므로 삭제 이유는 ASP 캡처에 언급되지 않습니다. 패킷은 한 곳에서만 추적할 수 있습니다(인그레스 인터페이스 또는 ASP 드롭). 이 경우 여러 ASP 삭제를 수행하고 특정 ASP 삭제 이유를 설정하는 것이 좋습니다. 권장 접근 방식은 다음과 같습니다.
1. 현재 ASP 삭제 카운터를 지웁니다.
firepower# clear asp drop
2. 방화벽을 통해 문제를 해결하는 흐름을 보냅니다(테스트 실행).
3. ASP 삭제 카운터를 다시 확인하고 증가되는 카운터를 적어 둡니다.
firepower# show asp drop Frame drop: No route to host (no-route) 234 Flow is denied by configured rule (acl-drop) 71
4. 표시된 특정 삭제에 대해 ASP 캡처를 활성화합니다.
firepower# capture ASP_NO_ROUTE type asp-drop no-route firepower# capture ASP_ACL_DROP type asp-drop acl-drop
5. 방화벽을 통해 문제를 해결하는 흐름을 보냅니다(테스트 실행).
6. ASP 캡처를 확인합니다. 이 경우 패킷이 누락된 경로로 인해 삭제되었습니다.
firepower# show capture ASP_NO_ROUTE | include 192.168.0.100.*10.10.1.100 93: 07:53:52.381663 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 95: 07:53:52.632337 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 101: 07:53:55.375392 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 102: 07:53:55.626386 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 116: 07:54:01.376231 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,nop,sackOK> 117: 07:54:01.626310 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,nop,sackOK>
작업 5. FTD Lina 연결 테이블을 확인합니다.
패킷이 이그레스 인터페이스 'X'에 도달하는 경우가 있을 수 있지만 어떤 이유에서든 인터페이스 'Y'를 이그레스(egress)합니다. 방화벽 이그레스 인터페이스 결정은 다음 작동 순서를 기반으로 합니다.
- 설정된 연결 조회
- NAT(Network Address Translation) 조회 - UN-NAT(destination NAT) 단계가 PBR 및 경로 조회보다 우선합니다.
- PBR(Policy-Based Routing)
- 라우팅 테이블 조회
FTD 연결 테이블을 확인하려면
firepower# show conn
2 in use, 4 most used
Inspect Snort:
preserve-connection: 2 enabled, 0 in effect, 4 most enabled, 0 most in effect
TCP DMZ 10.10.1.100:80 INSIDE 192.168.0.100:11694, idle 0:00:01, bytes 0, flags aA N1
TCP DMZ 10.10.1.100:80 INSIDE 192.168.0.100:11693, idle 0:00:01, bytes 0, flags aA N1
요점:
- 플래그(Aa)에 따라 연결이 원시(절반이 열림 - 방화벽에서 TCP SYN만 표시됨)입니다.
- 소스/목적지 포트에 따라 인그레스 인터페이스는 INSIDE이고 이그레스 인터페이스는 DMZ입니다.
다음 그림에서 시각화할 수 있습니다.
firepower# show interface detail | i Interface number is|Interface [P|E].*is up
...
Interface Ethernet1/2 "INSIDE", is up, line protocol is up
Interface number is 19
Interface Ethernet1/3.202 "OUTSIDE", is up, line protocol is up
Interface number is 20
Interface Ethernet1/3.203 "DMZ", is up, line protocol is up
Interface number is 22
출력 1:
firepower# show conn long ... TCP OUTSIDE: 192.168.2.200/80 (192.168.2.200/80) INSIDE: 192.168.1.100/46050 (192.168.1.100/46050), flags aA N1, idle 3s, uptime 6s, timeout 30s, bytes 0 Initiator: 192.168.1.100, Responder: 192.168.2.200 Connection lookup keyid: 228982375
출력 2:
firepower# show conn detail
...
TCP OUTSIDE: 192.168.2.200/80 INSIDE: 192.168.1.100/46050,
flags aA N1, idle 4s, uptime 11s, timeout 30s, bytes 0
Initiator: 192.168.1.100, Responder: 192.168.2.200
Connection lookup keyid: 228982375
또한 show conn long은 Network Address Translation의 경우 괄호 안에 NATed IP를 표시합니다.
firepower# show conn long ... TCP OUTSIDE: 192.168.2.222/80 (192.168.2.222/80) INSIDE: 192.168.1.100/34792 (192.168.2.150/34792), flags aA N1, idle 0s, uptime 0s, timeout 30s, bytes 0, xlate id 0x2b5a8a4314c0 Initiator: 192.168.1.100, Responder: 192.168.2.222 Connection lookup keyid: 262895
작업 6. 방화벽 ARP(Address Resolution Protocol) 캐시를 확인합니다.
방화벽에서 다음 홉을 확인할 수 없는 경우 방화벽은 원래 패킷(이 경우 TCP SYN)을 자동으로 삭제하고 다음 홉을 확인할 때까지 ARP 요청을 계속 전송합니다.
방화벽 ARP 캐시를 보려면 다음 명령을 사용합니다.
firepower# show arp
또한 확인되지 않은 호스트가 있는지 확인하려면 다음 명령을 사용할 수 있습니다.
firepower# show arp statistics
Number of ARP entries in ASA: 0
Dropped blocks in ARP: 84
Maximum Queued blocks: 3
Queued blocks: 0
Interface collision ARPs Received: 0
ARP-defense Gratuitous ARPS sent: 0
Total ARP retries: 182 < indicates a possible issue for some hosts
Unresolved hosts: 1 < this is the current status
Maximum Unresolved hosts: 2
ARP 작업을 더 자세히 확인하려는 경우 ARP별 캡처를 활성화할 수 있습니다.
firepower# capture ARP ethernet-type arp interface OUTSIDE firepower# show capture ARP ... 4: 07:15:16.877914 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50 5: 07:15:18.020033 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50
이 출력에서 방화벽(192.168.2.50)은 next-hop(192.168.2.72)을 확인하려고 하지만 ARP 응답이 없습니다
다음은 적절한 ARP 해결이 포함된 기능 시나리오의 출력입니다.
firepower# show capture ARP 2 packets captured 1: 07:17:19.495595 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50 2: 07:17:19.495946 802.1Q vlan#202 P0 arp reply 192.168.2.72 is-at 4c:4e:35:fc:fc:d8 2 packets shown
firepower# show arp
INSIDE 192.168.1.71 4c4e.35fc.fcd8 9
OUTSIDE 192.168.2.72 4c4e.35fc.fcd8 9
ARP 항목이 없는 경우 라이브 TCP SYN 패킷의 추적은 다음과 같습니다.
firepower# show capture CAPI packet-number 1 trace 6 packets captured 1: 07:03:43.270585 192.168.0.100.11997 > 10.10.1.100.80: S 4023707145:4023707145(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 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: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE … Phase: 14 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 4814, packet dispatched to next module … Phase: 17 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: allow
출력에서 볼 수 있는 것처럼 다음 홉에 연결할 수 없고 패킷이 방화벽에 의해 자동으로 삭제되는 경우에도 Action: allow(작업: 허용)가 추적에 표시됩니다. 이 경우 패킷 추적기 툴은 보다 정확한 출력을 제공하므로 반드시 확인해야 합니다.
firepower# packet-tracer input INSIDE tcp 192.168.0.100 1111 10.10.1.100 80 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: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE … Phase: 14 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 4816, packet dispatched to next module … Phase: 17 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (no-v4-adjacency) No valid V4 adjacency, Drop-location: frame 0x00005647a4e86109 flow (NA)/NA
최근 ASA/Firepower 버전에서는 이전 메시지가 다음으로 최적화되었습니다.
Drop-reason: (no-v4-adjacency) No valid V4 adjacency. Check ARP table (show arp) has entry for nexthop., Drop-location: f
가능한 원인 및 권장 조치 요약
인그레스 인터페이스의 TCP SYN 패킷만 표시되지만 예상 이그레스 인터페이스에서 전송된 TCP SYN 패킷이 없는 경우 다음과 같은 원인이 있을 수 있습니다.
| 가능한 원인 |
권장 작업 |
| 패킷은 방화벽 액세스 정책에 의해 삭제됩니다. |
|
| 캡처 필터가 잘못되었습니다. |
|
| 패킷은 다른 이그레스 인터페이스로 전송됩니다. |
패킷이 현재 연결과 일치하기 때문에 잘못된 인터페이스로 전송되는 경우 clear conn address 명령을 사용하고 지울 연결의 5-tuple을 지정합니다. |
| 목적지까지 가는 길이 없어요 |
|
| 이그레스 인터페이스에 ARP 항목이 없습니다. |
|
| 이그레스 인터페이스가 다운되었습니다. |
방화벽에서 show interface ip brief 명령의 출력을 확인하고 인터페이스 상태를 확인합니다. |
사례 2. 클라이언트의 TCP SYN, 서버의 TCP RST
이 그림에서는 토폴로지를 보여줍니다.
문제 설명: HTTP가 작동하지 않음
영향을 받는 흐름:
소스 IP: 192.168.0.100
Dst IP: 10.10.1.100
프로토콜: TCP 80
캡처 분석
FTD LINA 엔진에서 캡처를 활성화합니다.
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
캡처 - 작동하지 않는 시나리오:
디바이스 CLI에서 캡처의 모양은 다음과 같습니다.
firepower# show capture capture CAPI type raw-data trace interface INSIDE [Capturing - 834 bytes] match ip host 192.168.0.100 host 10.10.1.100 capture CAPO type raw-data interface OUTSIDE [Capturing - 878 bytes] match ip host 192.168.0.100 host 10.10.1.100
CAPI 내용:
firepower# show capture CAPI 1: 05:20:36.654217 192.168.0.100.22195 > 10.10.1.100.80: S 1397289928:1397289928(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 05:20:36.904311 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 05:20:36.905043 10.10.1.100.80 > 192.168.0.100.22196: R 1850052503:1850052503(0) ack 2171673259 win 0 4: 05:20:37.414132 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 05:20:37.414803 10.10.1.100.80 > 192.168.0.100.22196: R 31997177:31997177(0) ack 2171673259 win 0 6: 05:20:37.914183 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,nop,sackOK> ...
CAPO 내용:
firepower# show capture CAPO 1: 05:20:36.654507 802.1Q vlan#202 P0 192.168.0.100.22195 > 10.10.1.100.80: S 2866789268:2866789268(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 2: 05:20:36.904478 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4785344:4785344(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 3: 05:20:36.904997 802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4785345 win 0 4: 05:20:37.414269 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4235354730:4235354730(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 5: 05:20:37.414758 802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4235354731 win 0 6: 05:20:37.914305 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4118617832:4118617832(0) win 8192 <mss 1380,nop,nop,sackOK>
이 이미지는 Wireshark에서 CAPI를 캡처한 것을 보여줍니다.
요점:
- 소스가 TCP SYN 패킷을 전송합니다.
- TCP RST는 소스로 전송됩니다.
- 소스가 TCP SYN 패킷을 재전송합니다.
- MAC 주소가 정확합니다(소스 MAC 주소가 다운스트림 라우터에 속하는 인그레스 패킷에서는 대상 MAC 주소가 방화벽 INSIDE 인터페이스에 속함).
이 이미지는 Wireshark에서 CAPO를 캡처한 것을 보여줍니다.
요점:
- 소스가 TCP SYN 패킷을 전송합니다.
- TCP RST는 OUTSIDE 인터페이스에 도착합니다.
- 소스가 TCP SYN 패킷을 재전송합니다.
- MAC 주소가 정확합니다(이그레스 패킷에서는 방화벽 OUTSIDE가 소스 MAC이고 업스트림 라우터가 대상 MAC임).
2개의 캡처를 바탕으로 다음과 같은 결론을 내릴 수 있습니다.
- 클라이언트와 서버 간의 TCP 3-way 핸드셰이크가 완료되지 않습니다
- 방화벽 이그레스 인터페이스에 도착하는 TCP RST가 있습니다
- 방화벽이 적절한 업스트림 및 다운스트림 디바이스에 '연결'(MAC 주소 기반)
권장 작업
이 섹션에 나와 있는 조치는 문제를 더 좁히기 위한 목적입니다.
작업 1. TCP RST를 전송하는 소스 MAC 주소를 확인합니다.
TCP SYN 패킷에 표시된 대상 MAC이 TCP RST 패킷에 표시된 소스 MAC과 동일한지 확인합니다.
이 확인은 다음 2가지를 확인하는 데 목적이 있습니다.
- 비대칭 흐름이 없는지 확인합니다.
- MAC가 예상 업스트림 디바이스에 속하는지 확인합니다.
작업 2. 인그레스 패킷과 이그레스 패킷을 비교합니다.
Wireshark에서 2개의 패킷을 시각적으로 비교하여 방화벽에서 패킷을 수정/손상시키지 않는지 확인합니다. 예상되는 몇 가지 차이점이 강조 표시됩니다.
요점:
- 타임스탬프는 다릅니다. 반면 그 차이는 작고 합리적이어야 한다. 이는 패킷에 적용된 기능 및 정책 검사와 디바이스의 로드에 따라 달라집니다.
- 패킷의 길이는 특히 한쪽 면에서만 방화벽에 의해 추가/제거된 dot1Q 헤더가 있는 경우 달라집니다.
- MAC 주소가 다릅니다.
- 하위 인터페이스에서 캡처를 수행한 경우 dot1Q 헤더를 사용할 수 있습니다.
- NAT 또는 PAT(Port Address Translation)가 패킷에 적용되는 경우 IP 주소가 달라집니다.
- NAT 또는 PAT가 패킷에 적용되는 경우 소스 또는 목적지 포트가 다릅니다.
- Wireshark Relative Sequence Number 옵션을 비활성화하면 ISN(Initial Sequence Number) 임의 설정으로 인해 방화벽에 의해 TCP 시퀀스 번호/승인 번호가 수정됩니다.
- 일부 TCP 옵션은 덮어쓸 수 있습니다. 예를 들어, 트랜짓 경로의 패킷 단편화를 방지하기 위해 방화벽은 기본적으로 TCP MSS(Maximum Segment Size)를 1380으로 변경합니다.
작업 3. 목적지에서 캡처합니다.
가능하면 목적지에서 캡처합니다. 이것이 가능하지 않으면 최대한 목적지에 가까운 곳에 캡처를 취하십시오. 여기서 목표는 누가 TCP RST를 전송하는지 확인하는 것입니다(대상 서버 또는 경로에 있는 다른 디바이스?).
사례 3. TCP 3-Way 핸드셰이크 + 한 엔드포인트의 RST
이 그림에서는 토폴로지를 보여줍니다.
문제 설명: HTTP가 작동하지 않음
영향을 받는 흐름:
소스 IP: 192.168.0.100
Dst IP: 10.10.1.100
프로토콜: TCP 80
캡처 분석
FTD LINA 엔진에서 캡처를 활성화합니다.
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
캡처 - 작동하지 않는 시나리오:
이 문제가 캡처에서 나타날 수 있는 몇 가지 방법이 있습니다.
3.1 - TCP 3-way 핸드셰이크 + 클라이언트에서 지연된 RST
방화벽은 CAPI를 캡처하고 CAPO는 이미지에 표시된 것과 같은 패킷을 포함합니다.
요점:
- TCP 3-way 핸드셰이크는 방화벽을 통과합니다.
- 서버가 SYN/ACK를 다시 전송합니다.
- 클라이언트가 ACK를 재전송합니다.
- ~20초 후 클라이언트는 TCP RST를 포기하고 전송합니다.
권장 작업
이 섹션에 나와 있는 조치는 문제를 더 좁히기 위한 목적입니다.
작업 1. 가능한 한 두 엔드포인트 가까이에 캡처를 배치합니다.
방화벽 캡처는 클라이언트 ACK가 서버에서 처리되지 않았음을 나타냅니다. 이는 다음과 같은 사실을 기반으로 합니다.
- 서버가 SYN/ACK를 다시 전송합니다.
- 클라이언트가 ACK를 재전송합니다.
- 클라이언트는 데이터 이전에 TCP RST 또는 FIN/ACK를 전송합니다.
서버에서 캡처하면 문제가 표시됩니다. TCP 3-way 핸드셰이크의 클라이언트 ACK가 도착하지 않았습니다.
3.2 - TCP 3-way 핸드셰이크 + 클라이언트에서 지연된 FIN/ACK + 서버에서 지연된 RST
방화벽은 CAPI를 캡처하고 CAPO는 이미지에 표시된 것과 같은 패킷을 포함합니다.
요점:
- TCP 3-way 핸드셰이크는 방화벽을 통과합니다.
- ~5초 후에 클라이언트가 FIN/ACK을 전송합니다.
- ~20초 후에 서버가 중단되고 TCP RST를 전송합니다.
이 캡처에 따라 방화벽을 통과하는 TCP 3-way 핸드셰이크가 있지만 실제로 하나의 엔드포인트에서 완료되지 않는 것 같다고 결론을 내릴 수 있습니다(재전송 시 이를 나타냄).
권장 작업
case 3.1과 동일
3.3 - TCP 3-way 핸드셰이크 + 클라이언트에서 지연된 RST
방화벽은 CAPI를 캡처하고 CAPO는 이미지에 표시된 것과 같은 패킷을 포함합니다.
요점:
- TCP 3-way 핸드셰이크는 방화벽을 통과합니다.
- ~20초 후 클라이언트는 TCP RST를 포기하고 전송합니다.
이러한 캡처를 바탕으로 다음과 같은 결론을 내릴 수 있습니다.
- 5-20초 후에 한 엔드포인트가 연결을 종료하고 연결을 종료하기로 결정합니다.
권장 작업
case 3.1과 동일
3.4 - TCP 3-way 핸드셰이크 + 서버에서 즉시 RST
그림과 같이 두 방화벽 모두 CAPI와 CAPO에 이러한 패킷을 포함합니다.
요점:
- TCP 3-way 핸드셰이크는 방화벽을 통과합니다.
- ACK 패킷 이후 몇 밀리초 후에 서버의 TCP RST가 있습니다.
권장 작업
조치: 캡처를 가능한 한 서버에 가깝게 수행합니다.
서버의 즉각적인 TCP RST는 작동하지 않는 서버 또는 TCP RST를 전송하는 경로에 있는 디바이스를 나타낼 수 있습니다. 서버 자체에서 캡처를 수행하고 TCP RST의 소스를 확인합니다.
사례 4. 클라이언트의 TCP RST
이 그림에서는 토폴로지를 보여줍니다.
문제 설명: HTTP가 작동하지 않습니다.
영향을 받는 흐름:
소스 IP: 192.168.0.100
Dst IP: 10.10.1.100
프로토콜: TCP 80
캡처 분석
FTD LINA 엔진에서 캡처를 활성화합니다.
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
캡처 - 작동하지 않는 시나리오:
CAPI 내용입니다.
firepower# show capture CAPI 14 packets captured 1: 12:32:22.860627 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 12:32:23.111307 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 12:32:23.112390 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 4: 12:32:25.858109 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 12:32:25.868698 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 6: 12:32:26.108118 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 7: 12:32:26.109079 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 8: 12:32:26.118295 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 9: 12:32:31.859925 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,nop,sackOK> 10: 12:32:31.860902 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 11: 12:32:31.875229 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 12: 12:32:32.140632 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 13: 12:32:32.159995 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,nop,sackOK> 14: 12:32:32.160956 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 14 packets shown
다음은 CAPO 내용입니다.
firepower# show capture CAPO 11 packets captured 1: 12:32:22.860780 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 2: 12:32:23.111429 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3000518857:3000518857(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 3: 12:32:23.112405 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 3514091874:3514091874(0) win 0 4: 12:32:25.858125 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 5: 12:32:25.868729 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 2968892337:2968892337(0) win 0 6: 12:32:26.108240 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3822259745:3822259745(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 7: 12:32:26.109094 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 40865466:40865466(0) win 0 8: 12:32:31.860062 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 4294058752:4294058752(0) win 8192 <mss 1380,nop,nop,sackOK> 9: 12:32:31.860917 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 1581733941:1581733941(0) win 0 10: 12:32:32.160102 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 4284301197:4284301197(0) win 8192 <mss 1380,nop,nop,sackOK> 11: 12:32:32.160971 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 502906918:502906918(0) win 0 11 packets shown
방화벽 로그에 표시되는 내용은 다음과 같습니다.
firepower# show log | i 47741 Oct 13 2019 13:57:36: %FTD-6-302013: Built inbound TCP connection 4869 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:36: %FTD-6-302014: Teardown TCP connection 4869 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE Oct 13 2019 13:57:39: %FTD-6-302013: Built inbound TCP connection 4870 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:39: %FTD-6-302014: Teardown TCP connection 4870 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE Oct 13 2019 13:57:45: %FTD-6-302013: Built inbound TCP connection 4871 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:45: %FTD-6-302014: Teardown TCP connection 4871 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE
이 로그는 방화벽 INSIDE 인터페이스에 도착하는 TCP RST가 있음을 나타냅니다
Wireshark에서 CAPI 캡처:
이미지에 표시된 대로 첫 번째 TCP 스트림을 따릅니다.
Wireshark 아래에서 Edit(편집) > Preferences(환경 설정) > Protocols(프로토콜) > TCP로 이동하고 이미지에 표시된 Relative sequence numbers(상대 시퀀스 번호) 옵션의 선택을 취소합니다.
이 그림에서는 CAPI 캡처의 첫 번째 흐름의 내용을 보여 줍니다.
요점:
- 클라이언트는 TCP SYN 패킷을 전송합니다.
- 클라이언트는 TCP RST 패킷을 전송합니다.
- TCP SYN 패킷의 Sequence Number(시퀀스 번호) 값은 4098574664입니다.
CAPO 캡처의 동일한 플로우에는 다음이 포함됩니다.
요점:
- 클라이언트는 TCP SYN 패킷을 전송합니다. 방화벽은 ISN을 임의로 지정합니다.
- 클라이언트는 TCP RST 패킷을 전송합니다.
두 가지 캡처를 통해 다음과 같은 결론을 내릴 수 있습니다.
- 클라이언트와 서버 간에는 TCP 3-way 핸드셰이크가 없습니다.
- 클라이언트에서 오는 TCP RST가 있습니다. CAPI 캡처의 TCP RST 시퀀스 번호 값은 1386249853입니다.
권장 작업
이 섹션에 나와 있는 조치는 문제를 더 좁히기 위한 목적입니다.
작업 1. 클라이언트에 대한 캡처를 수행합니다.
방화벽에서 수집된 캡처를 기반으로 비대칭 플로우에 대한 확실한 지표가 있습니다. 이는 클라이언트가 1386249853(임의 ISN) 값을 사용하여 TCP RST를 전송한다는 사실을 기반으로 합니다.
요점:
- 클라이언트는 TCP SYN 패킷을 전송합니다. 시퀀스 번호는 4098574664이며 방화벽 CAPI(INSIDE interface)에 표시되는 것과 동일합니다
- ACK 번호가 1386249853(ISN 임의 지정으로 인해 예상됨)인 TCP SYN/ACK가 있습니다. 이 패킷은 방화벽 캡처에서 볼 수 없습니다
- 클라이언트는 ACK 번호 값이 4098574665인 SYN/ACK가 필요하지만 값이 1386249853인 SYN/ACK를 받았으므로 TCP RST를 보냅니다
이는 다음과 같이 시각화할 수 있습니다.
작업 2. 클라이언트와 방화벽 간의 라우팅을 확인합니다.
다음을 확인합니다.
- 캡처에 표시되는 MAC 주소는 예상된 주소입니다.
- 방화벽과 클라이언트 간의 라우팅이 대칭인지 확인합니다.
내부 네트워크에 비대칭 라우팅이 있는 동안 방화벽과 클라이언트 사이에 있는 디바이스에서 RST가 오는 시나리오가 있습니다. 일반적인 경우가 이미지에 표시됩니다.
이 경우 캡처에는 이 내용이 포함됩니다. TCP SYN 패킷의 소스 MAC 주소와 TCP RST의 소스 MAC 주소 및 TCP SYN/ACK 패킷의 목적지 MAC 주소 간의 차이를 확인합니다.
firepower# show capture CAPI detail
1: 13:57:36.730217 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66
192.168.0.100.47740 > 10.10.1.100.80: S [tcp sum ok] 3045001876:3045001876(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25661)
2: 13:57:36.981104 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66
192.168.0.100.47741 > 10.10.1.100.80: S [tcp sum ok] 3809380540:3809380540(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25662)
3: 13:57:36.981776 00be.75f6.1dae a023.9f92.2a4d 0x0800 Length: 66
10.10.1.100.80 > 192.168.0.100.47741: S [tcp sum ok] 1304153587:1304153587(0) ack 3809380541 win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK> (DF) (ttl 127, id 23339)
4: 13:57:36.982126 a023.9f92.2a4d 00be.75f6.1dae 0x0800 Length: 54
192.168.0.100.47741 > 10.10.1.100.80: R [tcp sum ok] 3809380541:3809380541(0) ack 1304153588 win 8192 (ttl 255, id 48501)
...
사례 5. 느린 TCP 전송(시나리오 1)
문제 설명:
호스트 10.11.4.171과 10.77.19.11 간의 SFTP 전송이 느립니다. 두 호스트 간의 최소 대역폭(BW)은 100Mbps이지만 전송 속도가 5Mbps를 넘지 않습니다.
이와 동시에 호스트 10.11.2.124와 172.25.18.134 간의 전송 속도는 상당히 더 빠릅니다.
배경 이론:
단일 TCP 플로우의 최대 전송 속도는 BDP(Bandwidth Delay Product)에 의해 결정됩니다. 사용된 공식이 이미지에 표시됩니다.
BDP에 대한 자세한 내용은 다음 리소스를 참조하십시오.
- 링크가 1Gbps인데 애플리케이션이 10Mbps만 사용하는 이유는 무엇입니까?
- BRKSEC-3021 - 고급 - 방화벽 성능 극대화
시나리오 1. 저속 전송
이 그림에서는 토폴로지를 보여줍니다.
영향을 받는 흐름:
소스 IP: 10.11.4.171
Dst IP: 10.77.19.11
프로토콜: SFTP(FTP over SSH)
캡처 분석
FTD LINA 엔진에서 캡처를 활성화합니다.
firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11 firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11
firepower# capture CAPI type raw-data trace interface inside match icmp any any WARNING: Running packet capture can have an adverse impact on performance.
권장 작업
이 섹션에 나와 있는 조치는 문제를 더 좁히기 위한 목적입니다.
RTT(왕복 시간) 계산
먼저, 전송 흐름을 파악하고 이를 따릅니다.
Wireshark 보기를 변경하여 이전에 표시된 패킷 이후 시간(초)을 표시합니다. 이렇게 하면 RTT를 쉽게 계산할 수 있습니다.
RTT는 2개의 패킷 교환(하나는 소스로 향하고 다른 하나는 목적지로 향함) 간의 시간 값을 더하여 계산할 수 있습니다. 이 경우 패킷 #2는 방화벽과 SYN/ACK 패킷을 전송한 디바이스(서버) 간의 RTT를 표시합니다. 패킷 #3는 방화벽과 ACK 패킷(클라이언트)을 보낸 디바이스 간의 RTT를 보여줍니다. 2개의 숫자를 추가하면 엔드 투 엔드 RTT에 대한 가견적이 양호합니다.
RTT ≈ 80 msec
TCP 창 크기 계산
TCP 패킷을 확장하고, TCP 헤더를 확장하고, Calculated(계산됨) 창 크기를 선택하고, Apply as Column(열로 적용)을 선택합니다.
Calculated window size value(계산된 창 크기 값) 열을 확인하여 TCP 세션 중에 최대 창 크기 값이 얼마였는지 확인합니다. 열 이름을 선택하고 값을 정렬할 수도 있습니다.
파일 다운로드를 테스트할 경우(server > client) 서버에서 광고하는 값을 확인해야 합니다. 서버가 광고하는 최대 윈도우 크기 값에 따라 최대 전송 속도가 결정됩니다.
이 경우 TCP 윈도우 크기는 ≈50000바이트입니다
이 값과 대역폭 지연 제품 공식을 사용하여 다음과 같은 조건에서 얻을 수 있는 이론상 최대 대역폭을 구합니다. 50000*8/0.08 = 5Mbps 최대 이론상 대역폭.
이는 이 사례에서 고객이 경험하는 것과 일치합니다.
TCP 3-way 핸드셰이크를 자세히 확인합니다. 양쪽 모두, 더 중요하게는 서버는 2^0 = 1(창 크기 조정 없음)을 의미하는 창 크기 값을 0으로 광고합니다. 이는 전송 속도에 부정적인 영향을 미칩니다.
이때 서버에서 캡처하고 윈도우 배율을 0으로 광고하는 대상인지 확인하고 다시 구성해야 합니다(이 방법은 서버 설명서를 참조하십시오).
시나리오 2. 빠른 전송
이제 좋은 시나리오(동일한 네트워크를 통한 빠른 전송)를 살펴보겠습니다.
토폴로지:
관심 흐름:
소스 IP: 10.11.2.124
Dst IP: 172.25.18.134
프로토콜: SFTP(FTP over SSH)
FTD LINA 엔진에서 캡처 활성화
firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134 firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134
RTT(Round Trip Time) 계산: 이 경우 RTT는 ≈ 300 msec입니다.
TCP 창 크기 계산: 서버에서 TCP 창 크기 계수 7을 알립니다.
서버의 TCP 창 크기는 ≈1600000바이트입니다.
Bandwidth Delay Product(대역폭 지연 제품) 공식은 다음 값을 기반으로 합니다.
1600000*8/0.3 = 43Mbps의 이론상 최대 전송 속도
사례 6. 느린 TCP 전송(시나리오 2)
문제 설명: 방화벽을 통한 FTP 파일 전송(다운로드)이 느립니다.
이 그림에서는 토폴로지를 보여줍니다.
영향을 받는 흐름:
소스 IP: 192.168.2.220
Dst IP: 192.168.1.220
프로토콜: FTP
캡처 분석
FTD LINA 엔진에서 캡처를 활성화합니다.
firepower# capture CAPI type raw-data buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 firepower# cap CAPO type raw-data buffer 33554432 interface OUTSIDE match tcp host 192.168.2.220 host 192.168.1.220
FTP-DATA 패킷을 선택하고 FTD INSIDE CAPTURE(CAPI)의 FTP Data Channel을 따릅니다.
FTP-DATA 스트림 콘텐츠:
CAPO는 다음과 같은 콘텐츠를 캡처합니다.
요점:
- TCP OOO(Out-Of-Order) 패킷이 있습니다.
- TCP 재전송이 있습니다.
- 패킷 손실(삭제된 패킷)을 나타냅니다.
권장 작업
이 섹션에 나와 있는 조치는 문제를 더 좁히기 위한 목적입니다.
작업 1. 패킷 손실 위치를 식별합니다.
이와 같은 경우 동시 캡처를 수행하고 Divide and Conquer 방법론을 사용하여 패킷 손실의 원인이 되는 네트워크 세그먼트를 식별해야 합니다. 방화벽 관점에서 보면 다음과 같은 3가지 주요 시나리오가 있습니다.
- 패킷 손실은 방화벽 자체로 인해 발생합니다.
- 패킷 손실은 방화벽 디바이스(서버에서 클라이언트로 가는 방향)의 다운스트림으로 발생합니다.
- 패킷 손실은 방화벽 디바이스 업스트림에서 발생합니다(클라이언트에서 서버로 방향).
방화벽으로 인한 패킷 손실: 패킷 손실이 방화벽으로 인한 것인지 확인하려면 인그레스 캡처를 이그레스 캡처와 비교해야 합니다. 두 개의 서로 다른 캡처를 비교하는 방법은 꽤 많다. 이 단원에서는 이 작업을 수행하는 한 가지 방법을 보여 줍니다.
패킷 손실을 식별하기 위해 2개의 캡처를 비교하는 절차
1단계. 2 캡처에 동일한 타임 윈도우의 패킷이 포함되어 있는지 확인합니다. 즉, 한 캡처에는 다른 캡처 전이나 후에 캡처된 패킷이 없어야 합니다. 다음과 같은 몇 가지 방법이 있습니다.
- 첫 번째와 마지막 패킷 IP ID(IP ID) 값을 확인합니다.
- 첫 번째 및 마지막 패킷 타임스탬프 값을 확인합니다.
이 예에서는 각 캡처의 첫 번째 패킷이 동일한 IP ID 값을 갖는다는 것을 확인할 수 있습니다.
동일하지 않은 경우 다음을 수행합니다.
- 각 캡처의 첫 번째 패킷에서 타임스탬프를 비교합니다.
- 최신 Timestamp가 있는 캡처에서 필터를 가져오면 Timestamp 필터가 ==부터 >=(첫 번째 패킷) 및 <=(마지막 패킷)로 변경됩니다. 예:
(frame.time >= "2019년 10월 16일 16:13:43.244692000") &&(frame.time <= "2019년 10월 16일 16:20:21.785130000")
3. 지정된 패킷을 새 캡처로 내보내고, File > Export Specified Packets를 선택한 다음 Displayed 패킷을 저장합니다. 이때 두 캡처에는 동일한 타임 윈도우를 커버하는 패킷이 포함되어야 합니다. 이제 2개의 캡처를 비교할 수 있습니다.
2단계. 두 캡처 간의 비교에 사용할 패킷 필드를 지정합니다. 사용할 수 있는 필드의 예:
- IP 식별
- RTP 시퀀스 번호
- ICMP 시퀀스 번호
1단계에서 지정한 각 패킷의 필드가 포함된 각 캡처의 텍스트 버전을 생성합니다. 이렇게 하려면 관심 있는 열만 남겨 둡니다. 예를 들어, IP ID를 기준으로 패킷을 비교하려는 경우 이미지에 표시된 대로 캡처를 수정합니다.
결과:
3단계. 이미지에 표시된 대로 캡처의 텍스트 버전(File > Export Packet Dissections > As Plain Text...)을 생성합니다.
이미지에 표시된 것처럼 표시된 필드의 값만 내보내려면 Include column headings and Packet details(열 머리글 및 패킷 세부사항 포함) 옵션의 선택을 취소합니다.
4단계. 파일의 패킷을 정렬합니다. Linux sort 명령을 사용하여 다음을 수행할 수 있습니다.
# sort CAPI_IDs > file1.sorted # sort CAPO_IDs > file2.sorted
5단계. 텍스트 비교 도구(예: WinMerge) 또는 Linux diff 명령을 사용하여 두 캡처 간의 차이를 확인합니다.
이 경우 FTP 데이터 트래픽에 대한 CAPI 및 CAPO 캡처는 동일합니다. 이는 패킷 손실이 방화벽에 의해 발생하지 않았음을 입증합니다.
업스트림/다운스트림 패킷 손실을 식별합니다.
요점:
1. 이 패킷은 TCP 재전송입니다. 특히 패시브 모드의 FTP 데이터에 대해 클라이언트에서 서버로 전송되는 TCP SYN 패킷입니다. 클라이언트가 패킷을 재전송하고 초기 SYN(패킷 #1)을 볼 수 있으므로 패킷이 방화벽으로 업스트림에서 손실되었습니다.
이 경우 SYN 패킷이 서버에 도착했지만 돌아오는 도중에 SYN/ACK 패킷이 손실되었을 수 있습니다.
2. 이전 세그먼트가 확인/캡처되지 않은 것으로 확인된 서버 및 Wireshark의 패킷이 있습니다. 캡처되지 않은 패킷이 서버에서 클라이언트로 전송되었으며 방화벽 캡처에서 보이지 않기 때문에 서버와 방화벽 간에 패킷이 손실되었습니다.
이는 FTP 서버와 방화벽 간에 패킷 손실이 있음을 나타냅니다.
작업 2. 추가 캡처
엔드포인트에서 캡처와 함께 추가 캡처를 생성합니다. 패킷 손실의 원인이 되는 문제가 있는 세그먼트를 더 격리하려면 Divide and Conquer 방법을 적용해 보십시오.
요점:
- 수신기(이 경우 FTP 클라이언트)는 들어오는 TCP 시퀀스 번호를 추적합니다. 패킷이 누락되었음을 감지하면(예상 시퀀스 번호를 건너뛰었음) ACK='건너뛴 예상 시퀀스 번호'로 ACK 패킷을 생성합니다. 이 예에서는 Ack=2224386800입니다.
- Dup ACK는 TCP 빠른 재전송(Duplicate ACK 수신 후 20msec 이내 재전송)을 트리거합니다.
중복 ACK는 무엇을 의미합니까?
- 몇 개의 중복 ACK가 있지만 실제 재전송이 없을 경우 무질서하게 도착하는 패킷이 있을 가능성이 높습니다.
- 실제 재전송이 뒤따르는 중복 ACK는 패킷 손실이 어느 정도 있음을 나타냅니다.
작업 3. 전송 패킷에 대한 방화벽 처리 시간을 계산합니다.
서로 다른 두 인터페이스에 동일한 캡처를 적용합니다.
firepower# capture CAPI buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 firepower# capture CAPI interface OUTSIDE
캡처 내보내기: 인그레스 패킷과 이그레스 패킷의 시간 차이 확인
사례 7. TCP 연결 문제(패킷 손상)
문제 설명:
무선 클라이언트(192.168.21.193)가 대상 서버(192.168.14.250 - HTTP)에 연결하려고 시도하며 두 가지 시나리오가 있습니다.
- 클라이언트가 액세스 포인트(AP) 'A'에 연결되면 HTTP 연결이 작동하지 않습니다.
- 클라이언트가 액세스 포인트(AP) 'B'에 연결되면 HTTP 연결이 작동합니다.
이 그림에서는 토폴로지를 보여줍니다.
영향을 받는 흐름:
소스 IP: 192.168.21.193
Dst IP: 192.168.14.250
프로토콜: TCP 80
캡처 분석
FTD LINA 엔진에서 캡처를 활성화합니다.
firepower# capture CAPI int INSIDE match ip host 192.168.21.193 host 192.168.14.250 firepower# capture CAPO int OUTSIDE match ip host 192.168.21.193 host 192.168.14.250
캡처 - 기능 시나리오:
베이스라인으로서 정상 작동이 확인된 시나리오의 캡처를 사용하는 것은 항상 매우 유용합니다.
이 그림에서는 NGFW INSIDE 인터페이스에서 캡처한 내용을 보여줍니다
이 그림에서는 NGFW OUTSIDE 인터페이스에서 캡처한 내용을 보여줍니다.
요점:
- 2개의 캡처는 거의 동일합니다(ISN 임의 지정 고려).
- 패킷 손실의 징후가 없습니다.
- OOO(No Out-Of-Order) 패킷
- 3개의 HTTP GET 요청이 있습니다. 첫 번째는 404 'Not Found', 두 번째는 200 'OK', 세 번째는 304 'Not Modified' 리디렉션 메시지를 받습니다.
캡처 - 알려진 결함 시나리오:
인그레스 캡처(CAPI) 내용입니다.
요점:
- TCP 3-way 핸드셰이크가 있습니다.
- TCP 재전송과 패킷 손실의 징후가 있습니다.
- Wireshark에 의해 형식이 잘못된 것으로 식별되는 패킷(TCP ACK)이 있습니다.
이 그림에서는 이그레스 캡처(CAPO) 내용을 보여 줍니다.
요점:
2개의 캡처는 거의 동일합니다(ISN 임의 지정 고려).
- TCP 3-way 핸드셰이크가 있습니다.
- TCP 재전송과 패킷 손실의 징후가 있습니다.
- Wireshark에 의해 형식이 잘못된 것으로 식별되는 패킷(TCP ACK)이 있습니다.
잘못된 형식의 패킷을 확인합니다.
요점:
- 패킷은 Wireshark에 의해 형식이 잘못된 것으로 식별됩니다.
- 길이는 2바이트입니다.
- 2바이트의 TCP 페이로드가 있습니다.
- 페이로드는 4개의 추가 0(00 00)입니다.
권장 작업
이 섹션에 나와 있는 조치는 문제를 더 좁히기 위한 목적입니다.
작업 1. 추가 캡처 수행 엔드포인트에 캡처를 포함하고 가능하면 분할 정복(divide and conquer) 방법을 적용하여 패킷 손상의 소스를 격리합니다. 예를 들면 다음과 같습니다.
이 경우 스위치 'A' 인터페이스 드라이버에 2바이트가 추가되었으며, 손상이 발생하는 스위치를 교체하는 것이 해결책이었습니다.
사례 8. UDP 연결 문제(누락된 패킷)
문제 설명: 대상 Syslog 서버에 Syslog(UDP 514) 메시지가 표시되지 않습니다.
이 그림에서는 토폴로지를 보여줍니다.
영향을 받는 흐름:
소스 IP: 192.168.1.81
Dst IP: 10.10.1.73
프로토콜: UDP 514
캡처 분석
FTD LINA 엔진에서 캡처를 활성화합니다.
firepower# capture CAPI int INSIDE trace match udp host 192.168.1.81 host 10.10.1.73 eq 514 firepower# capture CAPO int OUTSIDE match udp host 192.168.1.81 host 10.10.1.73 eq 514
FTD 캡처 시 패킷 표시 안 함:
firepower# show capture capture CAPI type raw-data trace interface INSIDE [Capturing - 0 bytes] match udp host 192.168.1.81 host 10.10.1.73 eq syslog capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes] match udp host 192.168.1.81 host 10.10.1.73 eq syslog
권장 작업
이 섹션에 나와 있는 조치는 문제를 더 좁히기 위한 목적입니다.
작업 1. FTD 연결 테이블을 확인합니다.
특정 연결을 확인하려면 다음 구문을 사용할 수 있습니다.
firepower# show conn address 192.168.1.81 port 514
10 in use, 3627189 most used
Inspect Snort:
preserve-connection: 6 enabled, 0 in effect, 74 most enabled, 0 most in effect
UDP INSIDE 10.10.1.73:514 INSIDE 192.168.1.81:514, idle 0:00:00, bytes 480379697, flags -oN1
요점:
- 인그레스(ingress) 및 이그레스(egress) 인터페이스가 동일합니다(U-turn).
- 바이트 수가 상당히 큰 값(~5GBytes)입니다.
- 플래그 'o'는 플로우 오프로드(HW accelerated flow)를 의미한다. 따라서 FTD 캡처에서 패킷을 표시하지 않습니다. 플로우 오프로드는 41xx 및 93xx 플랫폼에서만 지원됩니다. 이 경우 디바이스는 41xx입니다.
작업 2. 섀시 레벨 캡처를 수행합니다.
이미지에 표시된 대로 Firepower 섀시 관리자에 연결하고 인그레스 인터페이스(이 경우 E1/2) 및 백플레인 인터페이스(E1/9 및 E1/10)에서 캡처를 활성화합니다.
몇 초 후:
공격 전:
이후:
요점:
- 표시 필터는 패킷 중복을 제거하고 syslog만 표시하는 데 적용됩니다.
- 패킷 간의 차이는 마이크로초 수준입니다. 이는 매우 높은 패킷 속도를 나타냅니다.
- TTL(Time to Live) 값이 지속적으로 감소합니다. 패킷 루프를 나타냅니다.
작업 3. 패킷 추적기를 사용합니다.
패킷이 방화벽 LINA 엔진을 통과하지 않으므로 라이브 추적(캡처 w/trace)은 수행할 수 없지만 패킷 추적기를 사용하여 에뮬레이트된 패킷을 추적할 수 있습니다.
firepower# packet-tracer input INSIDE udp 10.10.1.73 514 192.168.1.81 514 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 25350892, using existing flow Phase: 4 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Verdict: (fast-forward) fast forward this flow Phase: 5 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.1.81 using egress ifc INSIDE Phase: 6 Type: ADJACENCY-LOOKUP Subtype: next-hop and adjacency Result: ALLOW Config: Additional Information: adjacency Active next-hop mac address a023.9f92.2a4d hits 1 reference 1 Phase: 7 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: INSIDE output-status: up output-line-status: up Action: allow
작업 4. FTD 라우팅을 확인합니다.
방화벽 라우팅 테이블에서 라우팅 문제가 있는지 확인합니다.
firepower# show route 10.10.1.73
Routing entry for 10.10.1.0 255.255.255.0
Known via "eigrp 1", distance 90, metric 3072, type internal
Redistributing via eigrp 1
Last update from 192.168.2.72 on OUTSIDE, 0:03:37 ago
Routing Descriptor Blocks:
* 192.168.2.72, from 192.168.2.72, 0:02:37 ago, via OUTSIDE
Route metric is 3072, traffic share count is 1
Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 29/255, Hops 1
요점:
- 경로가 올바른 이그레스 인터페이스를 가리킵니다.
- 경로는 몇 분 전에 학습되었습니다(0:02:37).
작업 5. 연결 가동 시간을 확인합니다.
연결 업타임을 확인하여 이 연결이 설정된 시간을 확인합니다.
firepower# show conn address 192.168.1.81 port 514 detail
21 in use, 3627189 most used
Inspect Snort:
preserve-connection: 19 enabled, 0 in effect, 74 most enabled, 0 most in effect
Flags: A - awaiting responder ACK to SYN, a - awaiting initiator ACK to SYN,
b - TCP state-bypass or nailed,
C - CTIQBE media, c - cluster centralized,
D - DNS, d - dump, E - outside back connection, e - semi-distributed,
F - initiator FIN, f - responder FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - initiator data,
i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
k - Skinny media, L - decap tunnel, M - SMTP data, m - SIP media
N - inspected by Snort (1 - preserve-connection enabled, 2 - preserve-connection in effect)
n - GUP, O - responder data, o - offloaded,
P - inside back connection, p - passenger flow
q - SQL*Net data, R - initiator acknowledged FIN,
R - UDP SUNRPC, r - responder acknowledged FIN,
T - SIP, t - SIP transient, U - up,
V - VPN orphan, v - M3UA W - WAAS,
w - secondary domain backup,
X - inspected by service module,
x - per session, Y - director stub flow, y - backup stub flow,
Z - Scansafe redirection, z - forwarding stub flow
UDP INSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514,
flags -oN1, idle 0s, uptime 3m49s, timeout 2m0s, bytes 4801148711
요점:
- 4분 전에 연결이 설정되었습니다(라우팅 테이블에서 EIGRP 경로 설치 전).
작업 6. 설정된 연결을 지웁니다.
이 경우 패킷은 설정된 연결과 일치하며 잘못된 이그레스 인터페이스로 라우팅됩니다. 이로 인해 루프가 발생합니다. 이는 방화벽 운영 순서 때문입니다.
- 설정된 연결 조회(전역 라우팅 테이블 조회에 우선함)
- NAT(Network Address Translation) 조회 - UN-NAT(destination NAT) 단계가 PBR 및 경로 조회보다 우선합니다.
- PBR(Policy-Based Routing)
- 전역 라우팅 테이블 조회
연결이 시간 초과되지 않으므로(UDP conn 유휴 시간 제한이 2분인 동안 Syslog 클라이언트가 지속적으로 패킷을 전송함) 연결을 수동으로 지워야 합니다.
firepower# clear conn address 10.10.1.73 address 192.168.1.81 protocol udp port 514 1 connection(s) deleted.
새 연결이 설정되었는지 확인합니다.
firepower# show conn address 192.168.1.81 port 514 detail | b 10.10.1.73.*192.168.1.81
UDP OUTSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514,
flags -oN1, idle 1m15s, uptime 1m15s, timeout 2m0s, bytes 408
작업 7. 부동 연결 시간 제한을 구성합니다.
이는 문제를 해결하고 특히 UDP 플로우의 경우 최적화되지 않은 라우팅을 방지하기 위한 적절한 솔루션입니다. Devices(디바이스) > Platform Settings(플랫폼 설정) > Timeouts(시간 제한)로 이동하여 값을 설정합니다.
부동 연결 시간 제한에 대한 자세한 내용은 명령 참조에서 확인할 수 있습니다.
사례 9. HTTPS 연결 문제(시나리오 1)
문제 설명: 클라이언트 192.168.201.105와 서버 192.168.202.101 간의 HTTPS 통신을 설정할 수 없습니다.
이 그림에서는 토폴로지를 보여줍니다.
영향을 받는 흐름:
소스 IP: 192.168.201.111
Dst IP: 192.168.202.111
프로토콜: TCP 443(HTTPS)
캡처 분석
FTD LINA 엔진에서 캡처를 활성화합니다.
OUTSIDE 캡처에 사용되는 IP는 Port-Address Translation 컨피그레이션으로 인해 달라집니다.
firepower# capture CAPI int INSIDE match ip host 192.168.201.111 host 192.168.202.111 firepower# capture CAPO int OUTSIDE match ip host 192.168.202.11 host 192.168.202.111
이 이미지는 NGFW INSIDE 인터페이스에서 캡처한 내용을 보여줍니다.
요점:
- TCP 3-way 핸드셰이크가 있습니다.
- SSL 협상이 시작됩니다. 클라이언트가 Client Hello 메시지를 보냅니다.
- 클라이언트로 전송된 TCP ACK가 있습니다.
- 클라이언트로 전송된 TCP RST가 있습니다.
이 그림에서는 NGFW OUTSIDE 인터페이스에서 캡처한 내용을 보여줍니다.
요점:
- TCP 3-way 핸드셰이크가 있습니다.
- SSL 협상이 시작됩니다. 클라이언트가 Client Hello 메시지를 보냅니다.
- 방화벽에서 서버로 전송되는 TCP 재전송이 있습니다.
- 서버로 전송된 TCP RST가 있습니다.
권장 작업
이 섹션에 나와 있는 조치는 문제를 더 좁히기 위한 목적입니다.
작업 1. 추가 캡처 수행
서버에서 캡처한 결과, 서버가 손상된 TCP 체크섬과 함께 TLS 클라이언트 Hello를 수신한 다음 이를 자동으로 삭제합니다(클라이언트에 대한 TCP RST 또는 기타 응답 패킷이 없음).
모든 것을 종합할 때
이 경우 Wireshark에서 Validate the TCP checksum if possible(TCP 체크섬 검증) 옵션을 활성화해야 합니다. 이미지에 표시된 대로 Edit(편집) > Preferences(환경 설정) > Protocols(프로토콜) > TCP로 이동합니다.
이 경우 전체 그림을 보려면 캡처를 나란히 배치하면 유용합니다.
요점:
- TCP 3-way 핸드셰이크가 있습니다. IP ID가 동일합니다. 이는 플로우가 방화벽에 의해 프록시되지 않았음을 의미합니다.
- TLS Client Hello는 IP ID가 12083인 클라이언트에서 제공됩니다. 패킷은 방화벽에 의해 프록시되고(이 경우 방화벽은 TLS 암호 해독 정책으로 구성됨) IP ID가 52534으로 변경됩니다. 또한 나중에 수정되는 소프트웨어 결함으로 인해 패킷 TCP 체크섬이 손상됩니다.
- 방화벽은 TCP 프록시 모드에 있으며, (서버를 스푸핑하는) 클라이언트에 ACK를 전송합니다.
- 방화벽은 서버에서 TCP ACK 패킷을 수신하지 않고 TLS Client Hello 메시지를 다시 전송합니다. 이는 방화벽이 활성화한 TCP 프록시 모드 때문입니다.
- ~30초 후 방화벽이 중단되고 클라이언트로 TCP RST를 전송합니다.
- 방화벽은 서버를 향해 TCP RST를 전송합니다.
참조:
사례 10. HTTPS 연결 문제(시나리오 2)
문제 설명: FMC Smart License 등록이 실패합니다.
이 그림에서는 토폴로지를 보여줍니다.
영향을 받는 흐름:
소스 IP: 192.168.0.100
Dst: tools.cisco.com
프로토콜: TCP 443(HTTPS)
캡처 분석
FMC 관리 인터페이스에서 캡처를 활성화합니다.
다시 등록해 보십시오. Error(오류) 메시지가 나타나면 Ctrl-C를 눌러 캡처를 중지합니다.
root@firepower:/Volume/home/admin# tcpdump -i eth0 port 443 -s 0 -w CAP.pcap HS_PACKET_BUFFER_SIZE is set to 4. tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes ^C264 packets captured <- CTRL-C 264 packets received by filter 0 packets dropped by kernel root@firepower:/Volume/home/admin#
이미지에 표시된 대로 FMC에서 캡처를 수집합니다(System > Health > Monitor, 디바이스 선택 및 Advanced Troubleshooting 선택).
이 그림에서는 Wireshark의 FMC 캡처를 보여 줍니다.
이미지에 표시된 대로 TCP 흐름 중 하나를 따릅니다(Follow > TCP Stream).
요점:
- TCP 3-way 핸드셰이크가 있습니다.
- 클라이언트(FMC)는 Smart Licensing 포털에 SSL Client Hello 메시지를 보냅니다.
- SSL 세션 ID는 0입니다. 다시 시작된 세션이 아님을 의미합니다.
- 대상 서버가 Server Hello, Certificate 및 Server Hello Done 메시지로 응답합니다.
- 클라이언트는 'Unknown CA'와 관련된 SSL Fatal Alert를 전송합니다.
- 클라이언트는 세션을 닫기 위해 TCP RST를 전송합니다.
- 전체 TCP 세션 기간(설정부터 종료까지)은 ~0.5초입니다.
Server Certificate(서버 인증서)를 선택하고 issuer(발급자) 필드를 확장하여 commonName을 확인합니다. 이 경우 Common Name(공통 이름)은 MITM(Man-in-the-middle)을 수행하는 디바이스를 나타냅니다.
이 그림에서는 다음과 같이 표시됩니다.
권장 작업
이 섹션에 나와 있는 조치는 문제를 더 좁히기 위한 목적입니다.
작업 1. 추가 캡처 수행
트랜짓 방화벽 디바이스에서 캡처 수행:
CAPI의 특징은 다음과 같습니다.
CAPO는 다음을 보여줍니다.
이러한 캡처는 트랜짓 방화벽이 MITM(서버 인증서)을 수정한다는 것을 입증합니다
작업 2. 디바이스 로그를 확인합니다.
이 문서에 설명된 대로 FMC TS 번들을 수집할 수 있습니다.
이 경우 /dir-archives/var-log/process_stdout.log 파일에는 다음과 같은 메시지가 표시됩니다.
SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-ERROR: ch_pf_curl_send_msg[494],
failed to perform, err code 60, err string "SSL peer certificate or SSH remote key was not OK" ...
SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-TRACE: ch_pf_curl_is_cert_issue[514],
cert issue checking, ret 60, url "https://tools.cisco.com/its/
권장 솔루션
FMC가 Smart Licensing 클라우드에 성공적으로 등록할 수 있도록 특정 흐름에 대해 MITM을 비활성화합니다.
사례 11. IPv6 연결 문제
문제 설명: 방화벽의 INSIDE 인터페이스 뒤에 있는 내부 호스트는 외부 호스트(방화벽의 OUTSIDE 인터페이스 뒤에 있는 호스트)와 통신할 수 없습니다.
이 그림에서는 토폴로지를 보여줍니다.
영향을 받는 흐름:
소스 IP: fc00:1:1:1::100
Dst IP: fc00:1:1:2::2
프로토콜: 모두
캡처 분석
FTD LINA 엔진에서 캡처를 활성화합니다.
firepower# capture CAPI int INSIDE match ip any6 any6 firepower# capture CAPO int OUTSIDE match ip any6 any6
캡처 - 작동하지 않는 시나리오
이러한 캡처는 IP fc00:1:1:1::100(내부 라우터)에서 IP fc00:1:1:2::2(업스트림 라우터)로의 ICMP 연결 테스트와 병행하여 수행되었습니다.
방화벽 INSIDE 인터페이스의 캡처에는 다음이 포함됩니다.
요점:
- 라우터가 IPv6 Neighbor Solicitation 메시지를 전송하고 업스트림 디바이스(IP fc00:1:1:1::1)의 MAC 주소를 요청합니다.
- 방화벽이 IPv6 네이버 알림으로 응답합니다.
- 라우터가 ICMP 에코 요청을 보냅니다.
- 방화벽은 IPv6 인접 디바이스 요청 메시지를 전송하고 다운스트림 디바이스의 MAC 주소를 요청합니다(fc00:1:1:1::100).
- 라우터가 IPv6 네이버 광고로 응답합니다.
- 라우터가 추가 IPv6 ICMP 에코 요청을 보냅니다.
방화벽 OUTSIDE 인터페이스의 캡처에는 다음이 포함됩니다.
요점:
- 방화벽은 업스트림 디바이스(IP fc00:1:1:2::2)의 MAC 주소를 묻는 IPv6 인접 디바이스 요청 메시지를 전송합니다.
- 라우터가 IPv6 네이버 광고로 응답합니다.
- 방화벽에서 IPv6 ICMP 에코 요청을 보냅니다.
- 업스트림 디바이스(라우터 fc00:1:1:2::2)는 IPv6 주소 fc00:1:1:1::100의 MAC 주소를 묻는 IPv6 Neighbor Solicitation 메시지를 보냅니다.
- 방화벽에서 추가 IPv6 ICMP 에코 요청을 보냅니다.
- 업스트림 라우터는 IPv6 주소 fc00:1:1:1::100의 MAC 주소를 묻는 추가 IPv6 Neighbor Solicitation 메시지를 보냅니다.
포인트 4는 매우 흥미롭습니다. 일반적으로 업스트림 라우터는 방화벽 OUTSIDE 인터페이스(fc00:1:1:2::2)의 MAC을 요청하지만, 대신 fc00:1:1:1::100을 요청합니다. 이는 컨피그레이션이 잘못되었음을 나타냅니다.
권장 작업
이 섹션에 나와 있는 조치는 문제를 더 좁히기 위한 목적입니다.
작업 1. IPv6 인접 디바이스 테이블을 확인합니다.
방화벽 IPv6 인접 디바이스 테이블이 제대로 채워집니다.
firepower# show ipv6 neighbor | i fc00 fc00:1:1:2::2 58 4c4e.35fc.fcd8 STALE OUTSIDE fc00:1:1:1::100 58 4c4e.35fc.fcd8 STALE INSIDE
작업 2. IPv6 컨피그레이션을 확인합니다.
이는 방화벽 컨피그레이션입니다.
firewall# show run int e1/2 ! interface Ethernet1/2 nameif INSIDE cts manual propagate sgt preserve-untag policy static sgt disabled trusted security-level 0 ip address 192.168.0.1 255.255.255.0 ipv6 address fc00:1:1:1::1/64 ipv6 enable firewall# show run int e1/3.202 ! interface Ethernet1/3.202 vlan 202 nameif OUTSIDE cts manual propagate sgt preserve-untag policy static sgt disabled trusted security-level 0 ip address 192.168.103.96 255.255.255.0 ipv6 address fc00:1:1:2::1/64 ipv6 enable
업스트림 디바이스 컨피그레이션에서 잘못된 컨피그레이션을 확인합니다.
Router# show run interface g0/0.202 ! interface GigabitEthernet0/0.202 encapsulation dot1Q 202 vrf forwarding VRF202 ip address 192.168.2.72 255.255.255.0 ipv6 address FC00:1:1:2::2/48
캡처 - 기능 시나리오
서브넷 마스크 변경(예: /48에서 /64로)으로 문제가 해결되었습니다. 기능 시나리오의 CAPI 캡처입니다.
요점:
- 라우터가 업스트림 디바이스(IP fc00:1:1:1::1)의 MAC 주소를 묻는 IPv6 Neighbor Solicitation 메시지를 보냅니다.
- 방화벽이 IPv6 네이버 알림으로 응답합니다.
- 라우터가 ICMP 에코 요청을 보내고 에코 응답을 받습니다.
CAPO 내용:
요점:
- 방화벽은 업스트림 디바이스(IP fc00:1:1:2::2)의 MAC 주소를 묻는 IPv6 인접 디바이스 요청 메시지를 전송합니다.
- 방화벽이 IPv6 네이버 알림으로 응답합니다.
- 방화벽에서 ICMP 에코 요청을 보냅니다.
- 라우터가 다운스트림 디바이스의 MAC 주소를 요청하는 IPv6 Neighbor Solicitation 메시지를 보냅니다(IP fc00:1:1:1::1).
- 방화벽이 IPv6 네이버 알림으로 응답합니다.
- 방화벽은 ICMP 에코 요청을 전송하고 에코 응답을 받습니다.
사례 12. 간헐적 연결 문제(ARP 중독)
문제 설명: 내부 호스트(192.168.0.x/24)에 동일한 서브넷에 있는 호스트와 가끔 연결 문제가 있습니다
이 그림에서는 토폴로지를 보여줍니다.
영향을 받는 흐름:
소스 IP: 192.168.0.x/24
Dst IP: 192.168.0.x/24
프로토콜: 모두
내부 호스트의 ARP 캐시가 다음과 같이 오염된 것 같습니다.
캡처 분석
FTD LINA 엔진에서 캡처 활성화
이 캡처는 INSIDE 인터페이스의 ARP 패킷만 캡처합니다.
firepower# capture CAPI_ARP interface INSIDE ethernet-type arp
캡처 - 비작동 시나리오:
방화벽 INSIDE 인터페이스의 캡처에는 다음이 포함됩니다.
요점:
- 방화벽은 192.168.0.x/24 네트워크 내의 IP에 대한 다양한 ARP 요청을 수신합니다
- 방화벽은 자신의 MAC 주소로 모든 응답(proxy-ARP)을 합니다
권장 작업
이 섹션에 나와 있는 조치는 문제를 더 좁히기 위한 목적입니다.
작업 1. NAT 컨피그레이션을 확인합니다.
NAT 컨피그레이션과 관련하여 no-proxy-arp 키워드가 이전 동작을 막을 수 있는 경우가 있습니다.
firepower# show run nat nat (INSIDE,OUTSIDE) source static NET_1.1.1.0 NET_2.2.2.0 destination static NET_192.168.0.0 NET_4.4.4.0 no-proxy-arp
작업 2. 방화벽 인터페이스에서 proxy-arp 기능을 비활성화합니다.
'no-proxy-arp' 키워드로 문제가 해결되지 않으면 인터페이스 자체에서 프록시 ARP를 비활성화해 보십시오. FTD의 경우, 이 쓰기 시점에 FlexConfig를 사용하여 명령을 구축해야 합니다(적절한 인터페이스 이름 지정).
sysopt noproxyarp INSIDE
사례 13. CPU 호그를 유발하는 SNMP OID(Object Identifier) 식별
이 사례에서는 SNMP 버전 3(SNMPv3) 패킷 캡처 분석을 기반으로 메모리 폴링을 위한 특정 SNMP OID가 CPU 호그의 근본 원인(성능 문제)으로 어떻게 식별되었는지 보여줍니다.
문제 설명: 데이터 인터페이스에서 오버런이 계속 증가합니다. 추가 조사 결과, 인터페이스 오버런의 근본 원인인 CPU 호그(SNMP 프로세스로 인해 발생함)도 발견되었습니다.
트러블슈팅 프로세스의 다음 단계는 SNMP 프로세스로 인해 발생한 CPU 홉의 근본 원인을 파악하는 것이었습니다. 특히 문제의 범위를 좁혀 SNMP OID(Object Identifier)를 파악합니다. OID를 폴링하면 CPU 홉이 발생할 수 있습니다.
현재 FTD LINA 엔진은 실시간으로 폴링되는 SNMP OID에 대해 'show' 명령을 제공하지 않습니다.
폴링을 위한 SNMP OID 목록은 SNMP 모니터링 툴에서 검색할 수 있지만, 이 경우 다음과 같은 예방 요인이 있습니다.
- FTD 관리자가 SNMP 모니터링 툴에 액세스할 수 없었습니다
- 프라이버시를 위한 인증 및 데이터 암호화가 포함된 SNMP 버전 3이 FTD에서 구성되었습니다
캡처 분석
FTD 관리자가 SNMP 버전 3 인증 및 데이터 암호화에 대한 자격 증명을 가지고 있으므로 다음 작업 계획을 제안했습니다.
- SNMP 패킷 캡처
- 캡처를 저장하고 Wireshark SNMP 프로토콜 기본 설정을 사용하여 SNMP 버전 3 자격 증명을 지정하여 SNMP 버전 3 패킷의 암호를 해독합니다. 해독된 캡처는 SNMP OID 분석 및 검색에 사용됩니다
snmp-server 호스트 컨피그레이션에 사용되는 인터페이스에서 SNMP 패킷 캡처를 구성합니다.
firepower# show run snmp-server | include host snmp-server host management 192.168.10.10 version 3 netmonv3 firepower# show ip address management System IP Address: Interface Name IP address Subnet mask Method Management0/0 management 192.168.5.254 255.255.255.0 CONFIG Current IP Address: Interface Name IP address Subnet mask Method Management0/0 management 192.168.5.254 255.255.255.0 CONFIG firepower# capture capsnmp interface management buffer 10000000 match udp host 192.168.10.10 host 192.168.5.254 eq snmp firepower# show capture capsnmp capture capsnmp type raw-data buffer 10000000 interface outside [Capturing - 9512 bytes] match udp host 192.168.10.10 host 192.168.5.254 eq snmp
요점:
- SNMP 소스 및 목적지 주소/포트.
- privKey가 Wireshark에 알려지지 않았으므로 SNMP 프로토콜 PDU를 디코딩할 수 없습니다.
- encryptedPDU primitive의 값입니다.
권장 작업
이 섹션에 나와 있는 조치는 문제를 더 좁히기 위한 목적입니다.
작업 1. SNMP 캡처를 해독합니다.
를 저장하고 Wireshark SNMP 프로토콜 기본 설정을 편집하여 패킷 해독을 위한 SNMP 버전 3 자격 증명을 지정합니다.
firepower# copy /pcap capture: tftp: Source capture name [capsnmp]? Address or name of remote host []? 192.168.10.253 Destination filename [capsnmp]? capsnmp.pcap !!!!!! 64 packets copied in 0.40 secs
이미지에 표시된 대로 Wireshark에서 캡처 파일을 열고 SNMP 패킷을 선택하고 Protocol Preferences > Users Table로 이동합니다.
SNMP Users(SNMP 사용자) 테이블에 SNMP 버전 3 사용자 이름, 인증 모델, 인증 비밀번호, 프라이버시 프로토콜 및 프라이버시 비밀번호가 지정되었습니다(실제 자격 증명은 아래에 표시되지 않음).
SNMP 사용자 설정이 적용되면 Wireshark는 암호 해독된 SNMP PDU를 보여줬습니다.
요점:
- SNMP 모니터링 도구는 SNMP getBulkRequest를 사용하여 상위 OID 1.3.6.1.4.1.9.9.221.1 및 관련 OID를 쿼리하고 해당 OID를 탐색했습니다.
- FTD는 1.3.6.1.4.1.9.9.221.1과 관련된 OID를 포함하는 get-response로 각 getBulkRequest에 응답했습니다.
작업 2. SNMP OID를 식별합니다.
SNMP Object Navigator에서는 다음과 같이 OID 1.3.6.1.4.1.9.9.221.1이 CISCO-ENHANCED-MEMPOOL-MIB라는 MIB(Management Information Base)에 속한다는 것을 보여 주었습니다.
Wireshark에서 사람이 읽을 수 있는 형식으로 OID를 표시하려면
- 그림과 같이 MIB CISCO-ENHANCED-MEMPOOL-MIB 및 해당 종속성을 다운로드합니다.
2. Wireshark의 편집 > 기본 설정 > 이름 확인 창에서 OID 확인 사용이 선택됩니다. SMI(MIB 및 PIB 경로) 창에서 다운로드된 MIB가 있는 폴더와 SMI(MIB 및 PIB 모듈)를 지정합니다. CISCO-ENHANCED-MEMPOOL-MIB는 모듈 목록에 자동으로 추가됩니다.
3. Wireshark를 다시 시작하면 OID 확인이 활성화됩니다.
캡처 파일의 해독된 출력을 기반으로 SNMP 모니터링 도구는 FTD의 메모리 풀 사용률에 대한 데이터를 정기적으로(10초 간격) 폴링했습니다. TechNote 문서 ASA SNMP Polling for Memory-Related Statistics(메모리 관련 통계에 대한 ASA SNMP 폴링)에서 설명한 것처럼, SNMP로 GSP(전역 공유 풀) 활용률을 폴링하면 CPU 사용량이 높아집니다. 이 경우 캡처를 통해 글로벌 공유 풀 사용률이 SNMP getBulkRequest primitive의 일부로 주기적으로 폴링되었음을 확인할 수 있습니다.
SNMP 프로세스로 인한 CPU 호그를 최소화하기 위해 기사에 언급된 SNMP용 CPU 호그에 대한 완화 단계를 따르고 GSP와 관련된 OID를 폴링하지 않는 것이 좋습니다. GSP와 관련된 OID에 대한 SNMP 폴링이 없으면 SNMP 프로세스로 인한 CPU 홉이 관찰되지 않았으며 오버런 비율이 크게 감소했습니다.
관련 정보
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
3.0 |
31-Jul-2024 |
재인증, 대체 텍스트, 고정 헤더, 구두점 및 html SEO 최적화 |
2.0 |
02-Jun-2023 |
재인증 |
1.0 |
21-Nov-2019 |
최초 릴리스 |
피드백