애플리케이션 제어와 관련해서 다음의 지침과 제한 사항에 유의해야 합니다.
적응형 프로파일링을 사용하는지 확인
적응형 프로파일을 사용하지 않고 기본 상태로 유지된 경우 액세스 제어 규칙은 애플리케이션 제어를 수행할 수 없습니다.
애플리케이션 탐지기 자동 활성화
탐지하려는 애플리케이션에 대해 탐지기를 사용하고 있지 않으면 시스템은 해당 애플리케이션에 대해 모든 시스템 제공 탐지기를 자동으로 사용합니다. 시스템 제공 탐지기가 없으면 시스템은 가장 최근에 수정된 사용자 정의 탐지기를
애플리케이션에 대해 사용합니다.
애플리케이션이 식별되기 전에 통과해야 하는 패킷을 검사하도록 정책 설정
시스템은 다음의 두 가지 조건을 만족하지 않는 경우 인텔리전트 애플리케이션 우회(IAB) 및 속도 제한을 포함한 애플리케이션 제어를 수행할 수 없습니다.
-
클라이언트와 서버 간에 모니터링된 연결 설정
-
시스템이 세션에서 애플리케이션 식별
이 식별은 3~5개 패킷 내에서 이루어지거나 트래픽이 암호화된 경우 SSL 핸드세이크의 서버 인증 교환 이후에 이루어져야 합니다.
중요! 시스템에서 이러한 초기 패킷을 검사하도록 하려면 트래픽 식별 전에 통과하는 패킷을 처리할 정책 지정의 내용을 참조하십시오.
초기 트래픽이 기타 모든 기준과는 일치하는데 애플리케이션 식별이 불완전한 경우 시스템은 패킷 통과 및 연결 설정 또는 SSL 핸드셰이크 완료를 허용합니다. 시스템은 식별을 완료하면 나머지 세션 트래픽에 적절한 작업을 적용합니다.
![](https://www.cisco.com/content/dam/en/us/td/i/templates/note.gif)
참고
|
시스템에서 서버를 인식하려면 서버가 애플리케이션의 프로토콜 요구 사항을 준수해야 합니다. 예를 들어 ACK가 예상될 때 ACK 대신 keep-alive 패킷을 전송하는 서버가 있는 경우 해당 애플리케이션이 식별되지 않을
수 있으며 연결이 애플리케이션 기반 규칙과 일치하지 않습니다. 대신, 일치하는 다른 규칙 또는 기본 작업에 의해 처리됩니다. 이는 허용하려는 연결이 대신 거부될 수 있음을 의미할 수 있습니다. 이 문제가 발생하고 프로토콜
표준을 따르도록 서버를 수정할 수 없는 경우, 예를 들어 IP 주소 및 포트 번호를 일치시켜 해당 서버에 대한 트래픽을 다루는 비 애플리케이션 기반 규칙을 작성해야 합니다.
|
URL 및 애플리케이션 필터링용 별도의 규칙 생성
애플리케이션과 URL 기준을 결합하면 특히 암호화된 트래픽에 대해 예기치 않은 결과가 발생할 수 있으므로 가능하면 URL 및 애플리케이션 필터링에 대한 별도의 규칙을 만듭니다.
애플리케이션+URL 규칙이 더 일반적인 애플리케이션 전용 또는 URL 전용 규칙에 대한 예외 역할을 하지 않는 한, 애플리케이션 및 URL 기준을 모두 포함하는 규칙은 애플리케이션 전용 또는 URL 전용 규칙 뒤에 와야
합니다.
애플리케이션 및 기타 규칙 이전의 URL 규칙
가장 효과적인 URL 일치를 위해 특히 URL 규칙이 차단 규칙이고 다른 규칙이 다음 조건을 모두 만족하는 경우 다른 규칙 전에 URL 조건을 포함하는 규칙을 배치합니다.
-
애플리케이션 조건을 포함합니다.
-
검사할 트래픽은 암호화되어야 합니다.
암호화된 트래픽과 암호 해독된 트래픽에 대한 애플리케이션 제어
시스템은 암호화된 트래픽과 암호 해독된 트래픽을 식별하고 필터링할 수 있습니다.
-
암호화된 트래픽 - 시스템은 SMTPS, POPS, FTPS, TelnetS, IMAPS를 비롯하여 StartTLS로 암호화된 애플리케이션 트래픽을 탐지할 수 있습니다. 또한, TLS ClientHello 메시지 내 서버
이름 지표 또는 서버 인증서의 주체로 구별되는 이름 값에 따라 암호화된 특정 애플리케이션을 식별할 수 있습니다. 이러한 애플리케이션은 SSL 프로토콜 태그가 지정됩니다. SSL 규칙에서는 이런 애플리케이션만 선택할 수 있습니다. 이 태그가 없는 애플리케이션은 암호화되지 않은 트래픽 또는 해독된 트래픽에서만 탐지할 수 있습니다.
-
암호 해독된 트래픽 - 시스템은 암호화되거나 암호화되지 않은 트래픽이 아닌 암호 해독된 트래픽에서만 탐지할 수 있는 애플리케이션에 decrypted traffic 태그를 할당합니다.
TLS 서버 ID 검색 및 애플리케이션 제어
RFC 8446에서 정의한 TLS(Transport Layer Security) 프로토콜 1.3의 최신 버전은 보안 통신을 제공하기 위해 많은 웹 서버에서 선호하는 프로토콜입니다. TLS 1.3 프로토콜은 추가 보안을 위해 서버의 인증서를
암호화하며, 액세스 제어 규칙의 애플리케이션 및 URL 필터링 기준과 일치하는 데 인증서가 필요하므로 Firepower System은 전체 패킷의 암호를 해독하지 않고 서버 인증서를 추출하는 방법을 제공합니다.
애플리케이션 또는 URL 기준에서 일치시키려는 트래픽에 대해 특히 트래픽을 심층 검사하려는 경우, 이를 활성화하는 것이 좋습니다. 해독 정책에는 서버 인증서를 추출하는 과정에서 트래픽이 암호 해독되지 않으므로 SSL 정책이 필요하지 않습니다.
자세한 내용은 액세스 제어 정책 고급 설정를 참고하십시오.
활성 권한 부여에서 애플리케이션 제외
ID 정책에서는 특정 애플리케이션을 액티브 인증에서 제외하여 트래픽이 액세스 제어로 계속 이동하도록 허용할 수 있습니다. 이러한 애플리케이션에는 User-Agent Exclusion 태그가 지정됩니다. ID 규칙에서는 이러한 애플리케이션만 선택할 수 있습니다.
페이로드 없이 애플리케이션 트래픽 패킷 처리
액세스 제어를 수행할 때 시스템은 애플리케이션이 식별된 연결에서 페이로드가 없는 패킷에 기본 정책 작업을 적용합니다.
참조된 애플리케이션 트래픽 처리
광고물 트래픽과 같이 웹 서버에서 참조된 트래픽을 처리하려면 참조하는 애플리케이션이 아닌 참조되는 애플리케이션의 일치 여부를 확인합니다.
다중 프로토콜을 사용하는 애플리케이션(Skype, Zoho)의 애플리케이션 트래픽 제어
일부 애플리케이션은 다중 프로토콜을 사용합니다. 해당 트래픽을 제어하려면 액세스 제어 정책이 모든 관련 옵션을 포함하는지 확인합니다. 예를 들면 다음과 같습니다.
-
Skype - Skype 트래픽을 제어하려면 개별 애플리케이션을 선택하는 대신 Application Filters(애플리케이션 필터) 항목에서 Skype 태그를 선택합니다. 이렇게 하면 시스템이 동일한 방법으로 모든 Skype 트래픽을 탐지하고 제어할 수 있도록 할 수 있습니다.
-
Zoho - Zoho 메일을 제어하려면 사용 가능한 애플리케이션 목록에서 Zoho 및 Zoho mail을 모두 선택합니다.
콘텐츠 제한 기능용으로 지원되는 검색 엔진
시스템은 특정 검색 엔진에 대해서만 안전 검색 필터링을 지원합니다. 이러한 검색 엔진의 애플리케이션 트래픽에는 safesearch supported 태그가 할당됩니다.