본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.
Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.
Cisco ISR(Integrated Service Router)은 광범위한 애플리케이션에 대한 데이터 및 음성 네트워크 요구 사항을 해결할 수 있는 확장 가능한 플랫폼을 제공합니다.프라이빗 및 인터넷 연결 네트워크의 위협 환경은 매우 동적인 환경이지만, Cisco IOS® Firewall은 안전한 네트워크 상태를 정의하고 적용하는 동시에 비즈니스 기능과 연속성을 가능하게 하는 상태 기반 검사 및 AIC(Application Inspection and Control) 기능을 제공합니다.
이 문서에서는 특정 Cisco ISR 기반 데이터 및 음성 애플리케이션 시나리오의 방화벽 보안 측면에 대한 설계 및 구성 고려 사항에 대해 설명합니다.음성 서비스 및 방화벽에 대한 컨피그레이션은 각 애플리케이션 시나리오에 대해 제공됩니다.각 시나리오에서는 VoIP 및 보안 컨피그레이션을 개별적으로 설명하고 전체 라우터 컨피그레이션을 설명합니다.네트워크에서 음성 품질과 기밀성을 유지하기 위해 QoS, VPN 등의 서비스에 대한 다른 컨피그레이션이 필요할 수 있습니다.
이 문서에 대한 특정 요건이 없습니다.
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 규칙을 참조하십시오.
Cisco IOS 방화벽은 일반적으로 어플라이언스 방화벽의 구축 모델과 다른 애플리케이션 시나리오에 구축됩니다.일반적인 구축 환경으로는 Teleworker 애플리케이션, 소규모 또는 지사 사이트, 소매 애플리케이션 등이 있는데, 여기에는 낮은 장치 수, 여러 서비스의 통합, 낮은 성능 및 보안 기능 수준이 필요합니다.
ISR 제품의 다른 통합 서비스와 함께 방화벽 검사 애플리케이션이 비용 및 운영 측면에서 매력적인 것처럼 보일 수 있지만, 라우터 기반 방화벽이 적절한지 확인하기 위해 구체적인 고려 사항을 평가해야 합니다.각각의 추가 기능을 적용하면 메모리 및 처리 비용이 발생하며, 성능이 낮은 통합 라우터 기반 솔루션을 구축할 경우 최대 로드 기간 내에 전달 처리량 속도 감소, 패킷 레이턴시 증가, 기능 기능 손실의 원인이 될 수 있습니다.라우터와 어플라이언스를 결정할 때 다음 지침을 준수합니다.
여러 개의 통합 기능이 활성화된 라우터는 더 적은 수의 장치가 더 나은 솔루션을 제공하는 지사 또는 재택 근무 사이트에 가장 적합합니다.
일반적으로 고대역폭, 고성능 애플리케이션은 어플라이언스로 더 나은 주소를 제공합니다.Cisco ASA 및 Cisco Unified Call Manager Server는 NAT 및 보안 정책 애플리케이션 및 통화 처리를 처리하려면 적용되어야 하며, 라우터는 QoS 정책 애플리케이션, WAN 터미네이션 및 Site-to-Site VPN 연결 요구 사항을 해결합니다.
Cisco IOS Software 버전 12.4(20)T가 도입되기 전에 Classic Firewall 및 ZFW(Zone-Based Policy Firewall)는 VoIP 트래픽 및 라우터 기반 음성 서비스에 필요한 기능을 완벽하게 지원할 수 없었습니다. 이 경우 음성 트래픽을 수용하기 위해 보안 방화벽 정책에 큰 허점이 필요했으며, 진화하는 VoIP 신호 및 미디어 프로토콜에 대한 지원이 제한적었습니다.
다른 방화벽과 마찬가지로 Cisco IOS Zone-Based Policy Firewall은 보안 정책에 따라 네트워크의 보안 요구 사항을 파악하고 설명하는 경우에만 보안 방화벽을 제공할 수 있습니다.보안 정책에 도달하기 위한 두 가지 기본적인 접근 방식이 있습니다.의심스러운 관점과 대조적으로 신뢰하는 관점.
신뢰 관점은 모든 트래픽이 신뢰할 수 있다고 가정합니다. 단, 악성 또는 원치 않는 트래픽으로 구체적으로 식별될 수 있습니다.원하지 않는 트래픽만 거부하는 특정 정책이 구현됩니다.이 작업은 일반적으로 특정 액세스 제어 항목 또는 시그니처 또는 동작 기반 툴을 사용하여 수행합니다.이러한 접근 방식은 기존 애플리케이션에 방해가 되는 경향이 있지만, 위협 및 취약성 환경에 대한 포괄적인 지식이 필요하며, 새로운 위협과 익스플로잇을 나타나는 즉시 해결하기 위해 끊임없는 경계가 필요합니다.또한 사용자 커뮤니티는 적절한 보안 유지 관리에 큰 역할을 해야 합니다.거주자에 대한 제어가 거의 없는 광범위한 자유를 허용하는 환경은 부주의한 또는 악의적인 개인들로 인해 야기되는 문제에 상당한 기회를 제공합니다.이 접근 방식의 또 다른 문제는 모든 네트워크 트래픽에서 의심스러운 데이터를 모니터링하고 제어할 수 있는 충분한 유연성과 성능을 제공하는 효과적인 관리 툴과 애플리케이션 제어에 훨씬 더 많이 의존한다는 것입니다.현재 기술을 사용할 수 있지만 운영 부담이 대부분의 조직의 한계를 초과하는 경우가 많습니다.
의심스러운 관점은 특별히 식별된 양호한 트래픽을 제외하고 모든 네트워크 트래픽이 바람직하지 않다고 가정합니다.이는 명시적으로 허용된 것을 제외하고 모든 애플리케이션 트래픽을 거부하는 적용된 정책입니다.또한 AIC(Application Inspection and Control)를 구현하여 좋은 애플리케이션을 활용하기 위해 특별히 제작된 악성 트래픽과 좋은 트래픽으로 가장하는 원치 않는 트래픽을 식별하고 거부할 수 있습니다.애플리케이션 제어는 ACL(Access-Control List) 또는 ZFW(Zone-Based Policy Firewall) 정책과 같은 비정형 필터에 의해 제어되어야 하지만, 네트워크 운영에 대한 운영 및 성능 부담을 가중시킵니다. 따라서 AIC, IPS(Intrusion Prevention System) 또는 기타 서명 기반 제어(예: FPM) 또는 NBAR(Network-based Application Recognition)에 의해 처리되어야 하는 트래픽이 상당히 적습니다. 원하는 애플리케이션 포트(알려진 제어 연결 또는 세션으로 인해 발생하는 동적 미디어별 트래픽)만 특별히 허용될 경우, 네트워크에 존재하는 원치 않는 트래픽만 더 쉽게 인식되는 특정 하위 집합에 속해야 합니다. 이렇게 하면 원치 않는 트래픽에 대한 제어를 유지하기 위해 요구되는 엔지니어링 및 운영 부담이 줄어듭니다.
이 문서에서는 의심스러운 관점을 기반으로 VoIP 보안 컨피그레이션을 설명하므로 음성 네트워크 세그먼트에서 허용되는 트래픽만 허용됩니다.데이터 정책은 각 애플리케이션 시나리오의 컨피그레이션에 대한 메모에 설명된 대로 더욱 허용적입니다.
모든 보안 정책 구축은 폐쇄 루프 피드백 주기를 따라야 합니다.보안 구축은 일반적으로 기존 애플리케이션의 기능 및 기능에 영향을 미치며 이러한 영향을 최소화하거나 해결하기 위해 조정되어야 합니다.
Zone-Based Policy Firewall을 구성하기 위한 추가 배경이 필요한 경우 Zone Firewall Design and Application Guide를 검토합니다.
Zone Firewall Design and Application Guide에서는 라우터의 자체 영역에서 보안 정책을 사용하여 라우터 보안에 대해 간략히 설명하고 다양한 NFP(Network Foundation Protection) 기능을 통해 제공되는 대체 기능을 소개합니다.라우터 기반 VoIP 기능은 라우터의 자체 영역 내에서 호스팅되므로, 라우터를 보호하는 보안 정책은 Cisco Unified CallManager Express, Survivable Remote-Site Telephony 및 Voice Gateway 리소스에 의해 시작되거나 목적지가 지정된 음성 신호 및 미디어를 수용하기 위해 음성 트래픽에 대한 요구 사항을 인식해야 합니다.Cisco IOS Software Version 12.4(20)T 이전 버전에서는 Classic Firewall 및 Zone-Based Policy Firewall이 VoIP 트래픽의 요구 사항을 완전히 충족할 수 없었기 때문에 리소스를 완전히 보호할 수 있도록 방화벽 정책이 최적화되지 않았습니다.라우터 기반 VoIP 리소스를 보호하는 자체 영역 보안 정책은 12.4(20)T에 도입된 기능에 크게 의존합니다.
Cisco IOS Software Release 12.4(20)T는 공동 상주 Zone Firewall 및 음성 기능을 지원하기 위해 몇 가지 향상된 기능을 도입했습니다.보안 음성 애플리케이션에 3가지 주요 기능이 직접 적용됩니다.
SIP 개선 사항:애플리케이션 레이어 게이트웨이 및 애플리케이션 검사 및 제어
RFC 3261에 설명된 대로 SIP 버전 지원을 SIPv2에 업데이트
SIP 신호 지원을 확장하여 더 다양한 통화 흐름을 인식합니다.
특정 애플리케이션 레벨 취약성 및 익스플로잇을 해결하기 위해 세분화된 제어를 적용할 수 있는 SIP AIC(Application Inspection and Control)를 소개합니다.
자체 영역 검사를 확장하여 로컬에서/시작된 SIP 트래픽에서 발생하는 보조 신호 및 미디어 채널을 인식할 수 있습니다.
Skinny Local Traffic 및 CME 지원
SCCP 지원을 버전 16으로 업데이트(이전에 지원되었던 버전 9)
특정 애플리케이션 레벨 취약성 및 익스플로잇을 해결하기 위해 세분화된 제어를 적용할 수 있는 SCCP AIC(Application Inspection and Control)를 소개합니다.
자체 영역 검사를 확장하여 로컬에서/시작된 SCCP 트래픽에서 발생하는 보조 신호 및 미디어 채널을 인식할 수 있습니다.
버전 3 및 4에 대한 H.323 지원
버전 3 및 4에 H.323 지원 업데이트(이전에 지원되었던 버전 1 및 2)
특정 애플리케이션 레벨 취약성 및 익스플로잇을 해결하기 위해 세분화된 제어를 적용할 수 있는 H.323 AIC(Application Inspection and Control)를 소개합니다.
이 문서에 설명된 라우터 보안 컨피그레이션에는 정책에 의해 적용된 작업을 설명하는 설명과 함께 이러한 개선 사항이 제공하는 기능이 포함됩니다.개별 기능 문서에 대한 하이퍼링크는 음성 검사 기능의 전체 세부 정보를 검토하려는 경우 이 문서의 Related Information 섹션에서 사용할 수 있습니다.
앞서 언급한 포인트를 보강하기 위해 라우터 기반 음성 기능을 갖춘 Cisco IOS Firewall의 애플리케이션은 Zone-Based Policy Firewall을 적용해야 합니다.기존 IOS 방화벽에는 음성 트래픽의 신호 복잡성 또는 동작을 완전히 지원하는 데 필요한 기능이 포함되어 있지 않습니다.
Cisco IOS NAT(Network Address Translation)는 Cisco IOS Firewall과 함께 자주 구성됩니다. 특히 사설 네트워크가 인터넷과 연결되어야 하거나, 특히 IP 주소 공간이 겹치는 경우, 개별 사설 네트워크가 연결해야 하는 경우에 그렇습니다.Cisco IOS Software에는 SIP, Skinny 및 H.323용 NAT ALG(Application Layer Gateway)가 포함되어 있습니다. NAT는 문제 해결 및 보안 정책 애플리케이션에 대한 추가적인 복잡성을 초래하므로 IP 음성에 대한 네트워크 연결을 NAT의 응용 프로그램 없이 수용하는 것이 좋습니다. 특히 NAT 오버로드가 사용되는 경우 더욱 그렇습니다.NAT는 네트워크 연결 문제를 해결하기 위한 최종 사례 솔루션으로만 적용할 수 있습니다.
Cisco IOS Software Release 12.4(20)T1 현재 Zone 또는 Classic Firewall에서 CUPC를 지원하지 않으므로 이 문서에서는 IOS 방화벽에서 Cisco CUPC(Unified Presence Client) 사용을 지원하는 컨피그레이션에 대해 설명하지 않습니다. CUPC는 향후 Cisco IOS Software 릴리스에서 지원될 예정입니다.
이 시나리오에서는 이 문서의 앞부분에서 설명한 단일 사이트/분산 통화 처리/PSTN 연결 모델(PSTN에 연결되는 CME/CUE/GW 단일 사이트 또는 지사) 및 이 문서에 설명된 세 번째 시나리오에서 정의된 다중 사이트/중앙 통화 처리/통합 음성 및 데이터 네트워크 간에 절충이 가능합니다.이 시나리오에서는 여전히 로컬 Cisco Unified CallManager Express를 사용하지만, 장거리 전화 걸기 및 HQ/원격 사이트 텔레포니는 주로 사이트 간 SIP 트렁크를 통해 로컬 다이얼 및 로컬 PSTN 연결을 통한 긴급 전화 걸기를 사용합니다.기존 PSTN 연결의 대부분을 제거하는 경우에도 다이얼 플랜에 설명된 대로 WAN 기반 유료 바이패스 다이얼링 및 로컬 영역 다이얼링 장애를 수용하려면 기본 수준의 PSTN 용량을 사용하는 것이 좋습니다.또한 현지 법률은 일반적으로 긴급(911) 전화 걸기를 수용하기 위해 일종의 현지 PSTN 연결이 제공되어야 합니다.이 시나리오에서는 Cisco Unified CallManager Express SRND에 설명된 대로 혜택을 제공하고 모범 사례를 관찰하는 분산 통화 처리를 사용합니다.
조직은 다음과 같은 상황에서 이러한 유형의 애플리케이션 시나리오를 구현할 수 있습니다.
사이트 간에 서로 다른 VoIP 환경이 사용되지만 장거리 PSTN 대신 VoIP가 여전히 필요합니다.
다이얼 플랜 관리를 위해서는 사이트별 자율성이 필요합니다.
WAN의 가용성과 상관없이 완전한 통화 처리 기능이 필요합니다.
애플리케이션 시나리오에는 유선 전화(음성 VLAN), 유선 PC(데이터 VLAN) 및 무선 장치(IP Communicator와 같은 VoIP 장치 포함)가 통합되어 있습니다.
보안 컨피그레이션에서는 다음을 제공합니다.
CME와 로컬 전화(SCCP 및 SIP), CME와 원격 CUCM 클러스터(SIP) 간의 라우터에서 시작하는 신호 검사.
다음 간의 통신을 위한 음성 미디어 핀홀:
로컬 유무선 부문
MoH용 CME 및 로컬 전화
음성 메일에 대한 CUE 및 로컬 전화
전화 및 원격 통화 엔터티
AIC(Application Inspection and Control) - 이를 위해 적용할 수 있습니다.
초대 메시지 속도 제한
모든 SIP 트래픽에 대한 프로토콜 적합성 보장
이 애플리케이션은 WAN 데이터 링크에서 사이트 간 음성 트래픽을 전송하므로 비용 절감의 혜택을 제공합니다.
이 시나리오의 단점은 WAN 연결에 대한 보다 자세한 계획이 필요하다는 것입니다.사이트 간 통화 품질은 불법/원치 않는 트래픽(벌레, 바이러스, 피어 투 피어 파일 공유) 또는 캐리어 네트워크에서 트래픽 엔지니어링으로 인해 발생할 수 있는 레이턴시 문제를 식별하기 어려운 등 WAN의 여러 가지 요소에 의해 영향을 받을 수 있습니다.WAN 연결의 크기는 음성 및 데이터 트래픽 모두에 충분한 대역폭을 제공할 수 있도록 적절하게 조정되어야 합니다.대기 시간에 덜 민감한 데이터 트래픽(예: 이메일, SMB/CIFS 파일 트래픽)을 QoS의 낮은 우선 순위 트래픽으로 분류하여 음질을 유지할 수 있습니다.
이 시나리오의 또 다른 문제는 중앙 집중식 통화 처리 부족 및 통화 처리 실패 문제 해결에 발생할 수 있는 어려움입니다.따라서 이 시나리오는 중앙 집중식 통화 처리로의 마이그레이션의 중간 단계로서 대규모 조직에 가장 적합합니다.Cisco CallManager로의 마이그레이션이 완료됨에 따라 로컬 Cisco CME를 완전한 기능을 갖춘 SRST 대체(fallback) 역할을 하도록 변환할 수 있습니다.
보안 측면에서 볼 때, 이 환경의 복잡성이 증가하면 WAN을 통한 연결이나 공용 인터넷상의 VPN을 통한 연결이 위협 환경을 크게 증가시키기 때문에 효과적인 보안 구현 및 문제 해결이 더욱 어려워집니다. 특히 보안 정책이 신뢰 관점을 필요로 하는 경우, WAN을 통한 트래픽에 대한 제한이 거의 없는 경우가 더 어려워집니다.이 점을 염두에 두고, 이 문서에서 제공하는 컨피그레이션 예제는 특정 비즈니스 크리티컬 트래픽을 허용하는 좀 더 의심스러운 정책을 구현한 다음 프로토콜 적합성 확인을 통해 검사합니다.또한 특정 VoIP 작업, 즉 SIP INVITE는 VoIP 리소스와 사용성에 부정적인 영향을 주는 악성 또는 의도하지 않은 소프트웨어 악성코드의 가능성을 줄이는 데 제한됩니다.
이 섹션에는 이 문서에서 설명하는 기능을 구성하기 위한 정보가 표시됩니다.
이 문서에서는 다음 네트워크 설정을 사용합니다.
여기에 설명된 컨피그레이션은 Cisco 2851 Integrated Services Router를 보여줍니다.
이 문서에서는 다음 구성을 사용합니다.
CME 및 CUE 연결을 위한 음성 서비스 구성
영역 기반 정책 방화벽 컨피그레이션
보안 구성
CME 및 CUE 연결을 위한 음성 서비스 컨피그레이션입니다.
CME 및 CUE 연결을 위한 음성 서비스 구성 |
---|
! |
이는 유선 및 무선 LAN 세그먼트의 보안 영역, 전용 LAN(유무선 세그먼트로 구성), 신뢰할 수 있는 WAN 연결에 도달하는 WAN 세그먼트, 라우터의 음성 리소스가 있는 자체 영역으로 구성된 영역 기반 정책 방화벽 컨피그레이션입니다.
다음은 보안 컨피그레이션입니다.
보안 구성 |
---|
class-map type inspect match-all acl-cmap |
라우터 기반 IP 텔레포니 리소스와 Zone-Based Policy Firewall 모두에 대한 프로비저닝 및 컨피그레이션은 일반적으로 Cisco Configuration Professional과 함께 사용하는 것이 가장 좋습니다.Cisco Secure Manager는 영역 기반 정책 방화벽 또는 라우터 기반 IP 텔레포니를 지원하지 않습니다.
Cisco IOS Classic Firewall은 Cisco Unified Firewall MIB를 통한 SNMP 모니터링을 지원하지만 Zone-Based Policy Firewall은 Unified Firewall MIB에서 아직 지원되지 않습니다.따라서 라우터 CLI(Command Line Interface)의 통계를 통해 또는 Cisco Configuration Professional과 같은 GUI 툴을 사용하여 방화벽 모니터링을 처리해야 합니다.
Cisco CS-MARS(Secure Monitoring And Reporting System)는 CS-MARS에서 아직 완전히 지원되지 않는 12.4(15)T4/T5 및 12.4(20)T에서 구현된 트래픽에 대한 로그 메시지 상관관계를 개선한 로깅 변경 사항에도 불구하고 영역 기반 정책 방화벽을 기본적으로 지원합니다.
인도의 방화벽 통화 검사 성능 테스트 결과는 미정입니다.
현재 이 구성에 대해 사용 가능한 확인 절차가 없습니다.
Cisco IOS Zone Firewall은 방화벽 활동을 보고 모니터링하고 문제를 해결하기 위한 show 및 debug 명령을 제공합니다.이 섹션에서는 show 명령을 사용하여 기본 방화벽 활동을 모니터링하고, 컨피그레이션 문제를 해결하거나 기술 지원과 논의해야 하는 경우 영역 방화벽의 debug 명령 소개를 설명합니다.
Cisco IOS Firewall은 보안 정책 컨피그레이션 및 활동을 보기 위한 몇 가지 show 명령을 제공합니다.이러한 명령 중 다수는 alias 명령의 응용 프로그램을 통해 더 짧은 명령으로 대체할 수 있습니다.
참고: debug 명령을 사용하기 전에 디버그 명령에 대한 중요 정보를 참조하십시오.
디버그 명령은 암호화되지 않거나 지원되지 않는 컨피그레이션을 사용하는 경우 유용할 수 있으며, 상호 운용성 문제를 해결하기 위해 Cisco TAC 또는 기타 제품의 기술 지원 서비스와 함께 작업해야 하는 경우 유용합니다.
참고: debug 명령을 특정 기능 또는 트래픽에 적용하면 콘솔 메시지 수가 매우 많아 라우터 콘솔이 응답하지 않을 수 있습니다.디버깅해야 하는 경우에도 터미널 대화 상자를 모니터링하지 않는 텔넷 창과 같은 대체 명령줄 인터페이스 액세스를 제공할 수 있습니다.디버그가 라우터 성능에 큰 영향을 미칠 수 있으므로 오프라인(랩 환경) 장비 또는 계획된 유지 관리 기간 내에서만 디버깅을 활성화합니다.