Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

IDP 애플리케이션 식별

AppID(Application Identification)는 사전 정의된 애플리케이션 시그니처를 활용하여 비표준 포트에서 작동하는 애플리케이션을 탐지함으로써 위협 탐지와 정책 시행을 강화합니다. 이러한 시그니처는 주니퍼의 보안 패키지 업데이트에 포함되어 있습니다. AppID는 IDP 서비스가 활성화되면 자동으로 활성화됩니다.

IDP 시스템은 사전 정의된 서명을 사용하여 애플리케이션을 식별하여 탐지 및 정책 시행을 지원합니다. 이는 애플리케이션의 정확한 식별을 보장하여 보안을 강화합니다. AppID는 IDP 서비스가 켜져 있는 상태에서 자동으로 작동하여 원활한 탐지 및 시행을 보장합니다.

기능 탐색기를 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인하십시오. 추가 플랫폼도 지원될 수 있습니다.

플랫폼 별 IDP 애플리케이션 식별 동작 섹션에서 플랫폼과 관련된 참고 사항을 검토하십시오.

애플리케이션 식별 이해

주니퍼 네트웍스는 비표준 포트에서 실행되는 TCP(Transmission Control Protocol) 및 UDP(User Datagram Protocol) 애플리케이션을 감지하는 사전 정의된 애플리케이션 시그니처를 제공합니다. 이러한 애플리케이션을 식별하면 침입 탐지 및 방지(IDP)가 비표준 포트에서 실행되는 애플리케이션에 적절한 공격 객체를 적용할 수 있습니다. 또한 디코더가 없는 애플리케이션에 대한 공격 시그니처의 범위를 좁혀 성능을 향상시킵니다.

IDP 센서는 네트워크를 모니터링하고 IDP 규칙 베이스에 정의된 특정 규칙에 따라 의심스럽고 비정상적인 네트워크 트래픽을 탐지합니다. 프로토콜 또는 애플리케이션을 기반으로 트래픽에 공격 객체를 적용합니다. 애플리케이션 시그니처를 통해 센서는 비표준 포트에서 실행되는 알려진 애플리케이션과 알려지지 않은 애플리케이션을 식별하고 올바른 공격 개체를 적용할 수 있습니다.

애플리케이션 시그니처는 주니퍼 네트웍스에서 제공하는 보안 패키지의 일부로 제공됩니다. 보안 패키지 업데이트와 함께 사전 정의된 애플리케이션 서명을 다운로드합니다. 응용 프로그램 서명을 만들 수 없습니다. 보안 패키지 다운로드에 대한 자세한 내용은 IDP 서명 데이터베이스 수동 업데이트를 참조하십시오.

AppID는 IDP, AppFW, AppTrack 또는 AppQoS와 같은 요청 서비스가 호출하도록 설정된 경우에만 기본적으로 사용하도록 설정됩니다. AppID는 정책이나 구성이 없으면 자동으로 트리거되지 않습니다. 그러나 정책 규칙에서 애플리케이션을 지정할 때 IDP는 애플리케이션 식별 결과가 아닌 지정된 애플리케이션을 사용합니다. 정책 규칙에서 애플리케이션을 지정하는 방법에 대한 지침은 예: IDP 애플리케이션 및 서비스 구성을 참조하십시오.

애플리케이션 식별은 기본적으로 활성화됩니다. CLI를 사용하여 애플리케이션 식별을 비활성화하려면 Junos OS 애플리케이션 식별 비활성화 및 재활성화를 참조하십시오.

모든 브랜치 디바이스에서 IDP는 패킷이 아닌 컨텍스트에 대한 헤더 검사를 허용하지 않습니다.

액티브/액티브 및 액티브/패시브 섀시 클러스터에 배포된 IDP에는 다음과 같은 제한 사항이 있습니다.

  • 페일오버 또는 페일백되는 세션에 대한 검사가 없습니다.

  • IP 작업 테이블이 노드 간에 동기화되지 않습니다.

  • 보조 노드의 라우팅 엔진은 패킷 포워딩 엔진을 통해서만 도달할 수 있는 네트워크에 도달하지 못할 수 있습니다.

  • SSL 세션 ID 캐시는 노드 간에 동기화되지 않습니다. SSL 세션이 세션 ID를 재사용하고 세션 ID가 캐시된 노드가 아닌 다른 노드에서 처리되는 경우 SSL 세션을 해독할 수 없으며 IDP 검사를 위해 우회됩니다.

액티브/액티브 섀시 클러스터의 IDP에는 제한이 있습니다. 시간 바인딩 범위 소스 트래픽의 경우, 여러 대상이 있는 소스로부터의 공격이 탐지되지 않을 수 있습니다. 노드에 분산된 활성 세션은 시간 바인딩 카운팅이 로컬 노드 전용 보기를 갖기 때문에 이 문제를 일으킵니다. 이러한 종류의 공격을 탐지하려면 현재 지원되지 않는 시간 바인딩 상태의 RTO 동기화가 필요합니다.

공격 객체별 IDP 서비스 및 애플리케이션 바인딩

공격 객체는 다음과 같은 다양한 방식으로 애플리케이션 및 서비스에 바인딩될 수 있습니다.

  • 공격 객체는 암시적으로 애플리케이션에 바인딩될 수 있으며 서비스 정의가 없을 수 있습니다. 컨텍스트 또는 이상 항목의 이름을 기반으로 애플리케이션에 바인딩됩니다.

  • 공격 객체는 서비스 이름을 사용하여 서비스에 바인딩할 수 있습니다.

  • 공격 객체는 TCP 또는 UDP 포트, ICMP 유형 또는 코드 또는 RPC 프로그램 번호를 사용하여 서비스에 바인딩할 수 있습니다.

지정된 애플리케이션 또는 서비스 바인딩의 적용 여부는 전체 공격 객체 정의와 IDP 정책 구성에 따라 달라집니다.

  • 공격 개체 정의에서 애플리케이션을 지정하는 경우 서비스 필드는 무시됩니다. 공격 개체는 지정된 서비스 대신 응용 프로그램에 바인딩됩니다. 그러나 공격 개체 정의에 서비스를 지정하고 응용 프로그램을 지정하지 않으면 공격 개체가 서비스에 바인딩됩니다. 표 1 은 애플리케이션 식별을 사용한 애플리케이션 및 서비스 바인딩의 동작을 요약합니다.

    표 1: 애플리케이션 식별이 포함된 애플리케이션 및 서비스

    공격 객체 필드

    바인딩 동작

    애플리케이션 식별

    :application (http)

    :service (smtp)

    • 애플리케이션 HTTP에 바인딩합니다.

    • 서비스 필드는 무시됩니다.

    사용

    :service (http)

    애플리케이션 HTTP에 바인딩합니다.

    사용

    :service (tcp/80)

    TCP 포트 80에 바인딩됩니다.

    비활성화됨

    예를 들어, 다음 공격 개체 정의에서 공격 개체는 애플리케이션 HTTP에 바인딩되고, 애플리케이션 식별이 활성화되며, 서비스 필드 SMTP 는 무시됩니다.

  • 공격 개체가 서비스별 컨텍스트(예: http-url) 및 이상(예: tftp_file_name_too_long)을 기반으로 하는 경우 애플리케이션 및 서비스 필드는 모두 무시됩니다. 서비스 컨텍스트 및 이상은 애플리케이션을 의미합니다. 따라서 공격 객체에서 이를 지정하면 애플리케이션 식별이 적용됩니다.

  • 정책에서 특정 애플리케이션을 구성하면 공격 개체에 지정된 애플리케이션 바인딩을 덮어씁니다. 표 2 에는 IDP 정책의 애플리케이션 구성과의 바인딩이 요약되어 있습니다.

    표 2: IDP 정책의 애플리케이션 구성

    정책의 애플리케이션 유형

    바인딩 동작

    애플리케이션 식별

    Default

    공격 개체 정의에 구성된 애플리케이션 또는 서비스에 바인딩합니다.

    • 애플리케이션 기반 공격 객체에 대해 활성화

    • 서비스 기반 공격 개체에 대해 비활성화됨

    Specific application

    공격 개체 정의에 지정된 애플리케이션에 바인딩됩니다.

    비활성화됨

    Any

    모든 애플리케이션에 바인딩됩니다.

    비활성화됨

  • IDP 정책에서 애플리케이션을 지정하는 경우 공격 개체 정의와 IDP 정책에 구성된 애플리케이션 유형이 일치해야 합니다. 정책 규칙은 두 개의 서로 다른 애플리케이션(하나는 공격 개체에 있고 다른 하나는 정책에 있음)을 지정할 수 없습니다.

IDP 구성에서 다른 애플리케이션 기반 공격이 지정되어 커밋이 실패하면 애플리케이션이 있을 any 수 없습니다. 대신 기본값을 사용하십시오.

애플리케이션에 대한 IDS 규칙을 구성하는 동안 이 옵션은 any 더 이상 사용되지 않습니다.

그러나 IDP 구성에서 애플리케이션 any 과 사용자 지정 공격 그룹이 사용되는 경우 커밋이 성공적으로 진행됩니다. 따라서 커밋 검사는 이러한 경우를 감지하지 못합니다.

중첩된 애플리케이션에 대한 IDP 애플리케이션 식별

애플리케이션 프로토콜 캡슐화의 사용이 확대됨에 따라 동일한 레이어 7 프로토콜에서 실행되는 여러 애플리케이션의 식별을 지원해야 할 필요성이 대두되었습니다. 예를 들어 Facebook과 Yahoo Messenger와 같은 애플리케이션은 모두 HTTP를 통해 실행할 수 있지만 동일한 레이어 7 프로토콜에서 실행되는 두 개의 서로 다른 애플리케이션으로 식별할 필요가 있습니다. 이를 위해 현재 애플리케이션 식별 계층은 계층 7 애플리케이션과 계층 7 프로토콜의 두 계층으로 분할됩니다.

포함된 사전 정의된 애플리케이션 서명은 레이어 7 애플리케이션을 감지하도록 생성되었지만 기존 레이어 7 프로토콜 서명은 여전히 동일한 방식으로 작동합니다. 이러한 사전 정의된 애플리케이션 시그니처는 공격 객체에 사용될 수 있습니다.

예: 애플리케이션 식별을 위한 IDP 정책 구성

이 예에서는 애플리케이션 식별을 위해 IDP 정책을 구성하는 방법을 보여 줍니다.

요구 사항

시작하기 전에:

  • 네트워크 인터페이스를 구성합니다.

  • 애플리케이션 패키지를 다운로드합니다.

개요

이 예에서는 IDP 정책 ABC를 생성하고 IPS 규칙 베이스에서 규칙 123을 정의합니다. IDP 정책 규칙에서 기본값을 애플리케이션 유형으로 지정합니다. 기본값 대신 애플리케이션을 지정하면 이 규칙에 대해 AppID 기능이 비활성화되고 IDP는 트래픽을 지정된 애플리케이션 유형과 일치시킵니다. 애플리케이션 식별에 정의된 애플리케이션은 현재 직접 참조할 수 없습니다.

구성

절차

단계별 절차

애플리케이션 식별을 위한 IDP 정책 구성:

  1. IDP 정책을 생성합니다.

  2. 애플리케이션 유형을 지정합니다.

  3. 일치 조건이 충족될 때 수행할 작업을 지정합니다.

  4. 디바이스 구성을 완료하면 구성을 커밋합니다.

검증

구성이 제대로 작동하는지 확인하려면 명령을 입력합니다.show security idp

IDP 애플리케이션 식별을 위한 메모리 제한 설정

IDP 서명 데이터베이스를 사용하여 애플리케이션 서명을 만들 수는 없지만 AppID를 실행하는 세션 수를 제한하고 AppID에 대한 메모리 사용량을 제한하도록 센서 설정을 구성할 수 있습니다.

세션에 대한 메모리 제한 - 하나의 TCP 또는 UDP 세션에 대해 AppID에 대한 패킷을 저장하는 데 사용할 수 있는 최대 메모리 바이트를 구성할 수 있습니다. 애플리케이션 식별을 위해 전역 메모리 사용량에 대한 제한을 구성할 수도 있습니다. AppID는 시스템이 세션에 대해 지정된 메모리 제한에 도달한 후 세션에 대해 비활성화됩니다. 그러나 IDP는 패턴을 계속 일치시킵니다. 일치하는 애플리케이션은 다음 세션에서 사용할 수 있도록 캐시에 저장됩니다. 이는 의도적으로 대용량 클라이언트-서버 패킷을 전송하여 AppID를 우회하려는 공격자로부터 시스템을 보호합니다.

  • 세션 수 - AppID를 동시에 실행할 수 있는 최대 세션 수를 구성할 수 있습니다. AppID는 시스템이 지정된 세션 수에 도달한 후에 비활성화됩니다. 너무 많은 연결 요청이 시스템에 할당된 모든 리소스를 압도하고 소진할 때 발생하는 서비스 거부(DOS) 공격을 방지하기 위해 세션 수를 제한합니다.

기능 탐색기를 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인하십시오. 추가 플랫폼도 지원될 수 있습니다.

중앙 지점(CP) 세션 번호의 용량에 대한 자세한 정보는 추가 플랫폼 정보 섹션을 참조하십시오.

예: IDP 애플리케이션 식별 서비스에 대한 메모리 제한 설정

이 예에서는 IDP AppID 서비스에 대한 메모리 제한을 구성하는 방법을 보여 줍니다.

요구 사항

시작하기 전에:

개요

이 예에서는 하나의 TCP 세션에 대해 AppID에 대한 패킷을 저장하는 데 사용할 수 있는 최대 메모리 양으로 5000메모리 바이트를 구성합니다.

구성

절차

단계별 절차

IDP AppID 서비스에 대한 메모리 및 세션 제한을 구성하려면 다음을 수행합니다.

  1. 애플리케이션 식별을 위한 메모리 제한을 지정합니다.

  2. 디바이스 구성을 완료하면 구성을 커밋합니다.

검증

구성이 제대로 작동하는지 확인하려면 명령을 입력합니다.show security idp memory

애플리케이션 식별 프로세스를 위한 IDP 카운터 확인

목적

AppID 프로세스에 대한 IDP 카운터를 확인합니다.

작업

CLI에서 명령을 입력합니다 show security idp counters application-identification .

샘플 출력

의미

출력에는 AppID 카운터의 요약이 표시됩니다. 다음 정보를 확인합니다.

카운터 설명

AI 캐시 히트

애플리케이션 식별 캐시의 히트 수를 표시합니다.
AI 캐시 누락 애플리케이션이 일치하지만 애플리케이션 식별 캐시 항목이 추가되지 않은 횟수를 표시합니다.
AI 매치 애플리케이션이 일치하는 횟수를 표시하고 애플리케이션 식별 캐시 항목이 추가됩니다.
AI 노매치 애플리케이션이 일치하지 않는 횟수를 표시합니다.
AI 지원 세션 애플리케이션 식별이 활성화된 세션 수를 표시합니다.
AI 비활성화 세션 애플리케이션 식별이 비활성화된 세션 수를 표시합니다.
캐시 적중으로 인한 AI 비활성화 세션 캐시 항목이 일치한 후 애플리케이션 식별이 비활성화된 세션 수를 표시합니다. 이 세션에서 애플리케이션 식별 프로세스가 중단됩니다.
구성으로 인한 AI 비활성화 세션 센서 구성으로 인해 애플리케이션 식별이 비활성화된 세션 수를 표시합니다.
프로토콜 재매핑으로 인해 AI 비활성화된 세션 IDP 정책 규칙 정의에서 특정 서비스를 구성했기 때문에 애플리케이션 식별이 비활성화된 세션 수를 표시합니다.
비 TCP/UDP 플로우로 인한 AI 비활성화 세션 세션이 TCP 또는 UDP 세션이 아니기 때문에 애플리케이션 식별이 비활성화된 세션 수를 표시합니다.
AI 서명이 없어 AI 비활성화된 세션 애플리케이션 식별 서명에서 일치하는 항목을 찾을 수 없기 때문에 애플리케이션 식별이 비활성화된 세션 수를 표시합니다.
세션 제한으로 인해 AI 비활성화 세션이 구성된 최대 제한에 도달했기 때문에 애플리케이션 식별이 비활성화된 세션 수를 표시합니다. 향후 세션에서도 애플리케이션 식별이 비활성화됩니다.
세션 패킷 메모리 제한으로 인해 AI 비활성화 세션이 TCP 또는 UDP 흐름의 최대 메모리 제한에 도달했기 때문에 애플리케이션 식별이 비활성화된 세션을 표시합니다. 향후 세션에서도 애플리케이션 식별이 비활성화됩니다.
글로벌 패킷 메모리 제한으로 인해 AI 비활성화 최대 메모리 제한에 도달하여 애플리케이션 식별이 비활성화된 세션을 표시합니다. 향후 세션에서도 애플리케이션 식별이 비활성화됩니다.

추가 플랫폼 정보

기능 탐색기를 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인하십시오. 추가 플랫폼이 지원될 수 있습니다.

다음 표를 사용하여 추가 플랫폼 정보를 검토하십시오.

SRX 시리즈 방화벽 최대 세션 수 센트럴 포인트(CP)
SRX5600

900만

225만

풀 CP

콤보 모드 CP

SRX5800

1,000만

225만

풀 CP

콤보 모드 CP

플랫폼별 IDP 애플리케이션 식별 동작

기능 탐색기를 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인하십시오.

다음 표를 사용하여 플랫폼의 플랫폼별 동작을 검토하십시오.

플랫폼

차이

SRX 시리즈 방화벽

  • IDP AppID를 지원하는 SRX320 방화벽은 최대 16,384개의 IDP 세션을 지원합니다.

  • IDP AppID를 지원하는 SRX345 방화벽은 최대 32,768개의 IDP 세션을 지원합니다.

  • 지원되는 최대 IDP 세션 수는 NFX150-C-S1 디바이스의 기본 프로필에서 8000개, NFX150-C-S1 디바이스의 SD-WAN 프로필에서 16,000개입니다.

  • 지원되는 최대 IDP 세션 수는 NFX150-S1의 기본 프로필에서 8000개, NFX150-S1 디바이스의 SD-WAN 프로필에서 64,000개입니다.

  • 모든 브랜치 SRX 시리즈 방화벽에서 ASC 테이블에서 지원되는 최대 항목 수는 100,000개입니다. 사용자 랜드 버퍼는 제한으로 1MB의 고정 크기를 갖기 때문에 테이블에는 최대 38,837개의 캐시 항목이 표시됩니다.