목차/06. Custom — 고급 설정

06Custom — 고급 설정Custom — 고급 설정

기본 프로파일·규칙을 넘어 엔진 수준에서 Threat Prevention을 다듬는 설정들을 모은 장입니다. 여기서는 검사 엔진의 동작 방식(Engine Settings), SNORT 시그니처 가져오기, IPS 성능 최적화, Allow List, VSX 게이트웨이 설정, SSH Deep Packet Inspection, 그리고 ThreatCloud 연동 까지, 깊은 튜닝과 운영에 필요한 고급 항목을 빠짐없이 풀어 둡니다. 대부분 SmartConsole의 Manage & Settings > Blades > Threat Prevention > Advanced Settings 창과 게이트웨이 명령줄에 흩어져 있으며, 세부 값은 Check Point Support의 SK 문서와 함께 신중히 다뤄야 합니다.

Threat Prevention 엔진 설정 (Engine Settings)

Engine Settings 창은 검사 엔진들의 동작 방식 을 한곳에서 조정하는 자리입니다. 검사 엔진, Check Point Online Web Service(ThreatCloud 저장소), 내부 이메일 화이트리스트, Threat Extraction·Threat Emulation의 파일 형식 지원 등이 모두 여기 모여 있습니다. 들어가는 길은 항상 같습니다 — Manage & Settings > Blades > Threat Prevention > Advanced Settings 를 누르면 Threat Prevention Engine Settings 창이 열립니다.

Fail Mode — 엔진이 과부하·실패할 때

Fail Mode 는 ThreatSpect 엔진이 검사 도중 과부하에 걸리거나 실패했을 때 트래픽을 어떻게 처리할지 를 정합니다. 예를 들어 Anti-Bot 검사가 내부 오류로 중간에 끊겼다고 합시다. 기본값은 그런 상황에서도 모든 트래픽을 통과 시키는 쪽입니다.

Allow all connections (Fail-open) — 엔진이 과부하·실패하면 모든 연결을 허용 합니다(기본값).
Block all connections (Fail-close) — 엔진이 과부하·실패하면 모든 연결을 차단 합니다.

기본적으로 하나의 Security Management Server가 관리하는 모든 Security Gateway는 그 관리 서버의 Fail Mode 설정을 똑같이 따릅니다. 그런데 R81.20부터는 malware_config 파일을 이용해 게이트웨이마다 따로 Fail Mode를 정할 수 있게 됐습니다. 이때 쓰는 값은 다음과 같습니다.

값	설명
`by_policy`	기본값. Fail Mode를 정책이 결정 합니다.
`open`	해당 게이트웨이는 엔진 과부하·실패 시 모든 연결을 허용 합니다.
`close`	해당 게이트웨이는 엔진 과부하·실패 시 모든 연결을 차단 합니다.

특정 게이트웨이의 Fail Mode를 바꾸는 절차는 이렇습니다.

해당 Security Gateway의 명령줄에 접속합니다.
Expert mode 로 들어갑니다.
현재 $FWDIR/conf/malware_config 파일을 먼저 백업합니다.

   [Expert@HostName]# cp $FWDIR/conf/malware_config $FWDIR/conf/malware_config_ORIGINAL

원하는 Fail Mode를 설정합니다.
- 정책이 결정하도록(by_policy):

     [Expert@HostName]# sed -ie 's/^fail_close=.*$/fail_close=by_policy/' $FWDIR/conf/malware_config

"open"으로:

     [Expert@HostName]# sed -ie 's/^fail_close=.*$/fail_close=open/' $FWDIR/conf/malware_config

"close"로:

     [Expert@HostName]# sed -ie 's/^fail_close=.*$/fail_close=close/' $FWDIR/conf/malware_config

Check Point Online Web Service

Check Point Online Web Service 는 ThreatSpect 엔진이 자원(리소스)을 최신 기준으로 분류할 때 조회하는 클라우드 서비스 입니다. 게이트웨이가 받은 응답은 로컬에 캐시 되어 성능을 끌어올리고, 캐시에 없는 경우에만 클라우드에 직접 묻습니다. Resource classification mode(자원 분류 모드)는 게이트웨이가 이 클라우드에 질의하는 동안 연결을 허용할지 보류할지 를 결정합니다.

Block connections when the web service is unavailable — 체크하면 클라우드에 연결되지 않을 때 연결을 차단 합니다. 체크를 해제하면(기본값) 연결이 불가능해도 연결을 허용 합니다.
Resource categorization mode — 자원 분류 모드(아래 Connection Unification 참고).

이 설정들은 Anti-Virus, Anti-Bot, Zero Phishing 에 적용됩니다.

분류 모드 — Background / Hold / Custom

캐시된 응답으로 분류할 수 없을 때 게이트웨이가 어떻게 행동할지를 세 가지로 고릅니다.

Background — 분류가 끝날 때까지 연결을 허용 — 캐시로 분류가 안 되면 "미분류(uncategorized)" 응답이 돌아옵니다. 연결은 일단 허용 하고, 뒤에서 Check Point Online Web Service가 분류를 계속합니다. 분류가 끝나면 "Detect" 로그가 만들어지는데, 거기에는 "Connection was allowed because background classification mode was set" 라는 설명이 붙습니다. 결과는 다음 요청을 위해 로컬에 캐시됩니다(기본값). 이 방식은 분류 과정의 지연(latency)을 줄여 줍니다.
Hold — 분류가 끝날 때까지 연결을 차단 — 캐시로 분류가 안 되면 Check Point Online Web Service가 분류를 끝낼 때까지 연결을 차단 한 채로 둡니다.
Custom — 서비스별로 다르게 설정 — Anti-Virus·Anti-Bot·Zero Phishing에 서로 다른 모드 를 줍니다. 예를 들어 Customize 를 눌러 Anti-Bot은 Hold, Anti-Virus와 Zero Phishing은 Background로 둘 수 있습니다.

Background를 Hold로 바꾸면, 게이트웨이는 파일을 붙잡아 두고 클라이언트 브라우저로 보내지 않 습니다. 브라우저에는 파일이 계속 다운로드되는 것처럼 보이지만 중간에 멈춥니다. 게이트웨이는 검사가 끝나거나 타임아웃이 나야 다운로드를 마저 진행하며, 파일이 악성이면 전송을 멈춥니다.

Connection Unification — 로그를 세션 단위로 묶기

게이트웨이 트래픽은 엄청난 양의 활동을 만들어 내므로, 로그가 감당할 수 없을 만큼 늘지 않도록 기본적으로 세션(session) 단위로 로그를 통합 합니다. 세션 은 사용자가 어떤 애플리케이션·사이트에 처음 접근한 순간 시작되는 기간으로, 그동안 게이트웨이는 사용자가 접근하는 애플리케이션·사이트마다 로그 하나 를 기록하고 그 안의 모든 활동을 그 로그에 담습니다. Anti-Bot·Threat Emulation·Anti-Virus가 허용·차단하는 연결의 기본 세션 길이는 10시간(600분) 입니다.

세션 길이는 이렇게 조정합니다.

단계	내용
1	Manage & Settings > Blades > Threat Prevention > Advanced Settings > General > Connection Unification > Session unification timeout (minutes) 로 이동합니다.
2	원하는 값을 입력합니다.
3	OK 를 누릅니다.

Anti-Bot 화이트리스트 설정

Suspicious Mail 엔진은 나가는 이메일을 검사 합니다. 여기에 Anti-Bot 검사를 면제할 이메일 주소·도메인 목록 을 만들 수 있습니다.

단계	내용
1	Manage & Settings > Blades > Threat Prevention > Advanced Settings > Anti-Bot 으로 이동합니다.
2	+ 기호를 눌러 주소·도메인을 추가합니다.

이 창에서 기존 항목을 편집·삭제 할 수도 있습니다.

Threat Emulation 파일 형식 선택

모든 Threat Prevention 프로파일을 대상으로 에뮬레이션에 보낼 파일 형식 을 고를 수 있습니다. 각 프로파일은 그 파일 형식에 Inspect(검사) 또는 Bypass(통과) 동작을 정의합니다.

단계	내용
1	SmartConsole에서 Manage & Settings > Blades 를 선택합니다.
2	Threat Prevention 영역에서 Advanced Settings 를 눌러 Engine Settings 창을 엽니다.
3	Threat Emulation Settings 영역에서 Configure file type support 를 누르면 File Types Support 창이 열립니다.
4	에뮬레이션에 보낼 파일 형식을 선택합니다. Emulation supported on 열은 그 형식을 지원하는 에뮬레이션 환경을 보여 줍니다.
5	OK 를 누르고 Engine Settings 창을 닫습니다.
6	Threat Prevention 정책을 설치합니다.

Threat Extraction 고급 엔진 설정

Threat Extraction에는 파일 형식 지원 과 메일 서명(mail signature) 을 다루는 고급 설정이 있습니다.

파일 형식 지원 설정 방법.

단계	내용
1	Manage & Settings > Blades > Threat Prevention > Advanced Settings 를 눌러 Engine Settings 창을 엽니다.
2	Threat Extraction 에서 Configure File Type Support 를 누르면 Threat Extraction Supported File Types 창이 열립니다.
3	목록에서 Threat Extraction blade가 지원할 파일 형식을 선택합니다.
4	OK 를 누릅니다.

메일 서명 설정 방법. Engine Settings 창의 Threat Extraction 에서 Configure Mail Signatures 를 누르면 Threat Extraction Mail Signatures 창이 열리고, 여기서 두 가지 서명 문구를 정합니다.

위협이 추출된 첨부가 있는 메일용 서명 — 위협이 추출된 메일에는 항상 첫 번째 서명이 붙 습니다. 수신자가 접근할 권한이 있으면 원본 파일로 가는 링크가 추가되며, 이 링크는 UserCheck Portal 을 열어 수신자가 내려받을 수 있는 첨부 목록을 보여 줍니다(UserCheck).
수정되지 않은 첨부용 서명 — Insert Field 버튼으로 참조 ID(reference ID) 를 서명 문구에 넣을 수 있습니다. 이 ID로 파일을 수신자에게 보낼 수 있고, 로그에서도 같은 ID를 찾을 수 있습니다. 게이트웨이에서는 다음 명령으로 원본 메일을 보냅니다.

  scrub send_orig_email

설정을 마치면 OK 를 누릅니다.

SNORT 시그니처 지원

SNORT 는 널리 쓰이는 오픈 소스 네트워크 침입 탐지 시스템(NIDS) 입니다(자세한 내용은 snort.org). Check Point는 GUI와 SmartDomain Manager API 양쪽에서 SNORT 규칙 사용을 지원하며, SNORT 규칙을 가져오면 IPS 데이터베이스의 일부 가 됩니다. 즉 업계 표준 시그니처를 IPS로 끌어와 외부 위협 인텔리전스를 폭넓게 받아들이는 셈입니다.

Check Point 관리 서버에서는 다음 작업을 할 수 있습니다.

파일에서 기존 SNORT 규칙을 가져오기(import) 합니다.
가져와 변환하고 나면 — SNORT 보호 이름은 원래 규칙의 msg 필드 값이 되고("Creating SNORT Rule Files" 참고), 가져온 SNORT 보호에는 다음 속성이 자동으로 붙습니다.
- Performance Impact — High
- Severity — High
- Confidence Level — Low 또는 Medium
기존 SNORT 규칙을 삭제 합니다.

Security Management Server로 SNORT 규칙 가져오기

먼저 SNORT 규칙 파일이 있어야 합니다 — SNORT 규칙을 담은 파일로 보통 확장자는 .rules 입니다. Multi-Domain 환경이라면 Security Management Server로 가져온 뒤 Global 정책을 Domain Management Server에 할당하면 새 SNORT 보호가 각 도메인으로 내려갑니다.

단계	내용
1	해당 게이트웨이·클러스터를 관리하는 Security Management Server에 SmartConsole로 접속합니다.
2	Security Policies > Threat Prevention > Custom Policy 로 이동합니다.
3	아래쪽 Custom Policy Tools 영역에서 IPS Protections 를 누릅니다.
4	위쪽 도구 모음에서 Actions > Snort Protections > Import Snort rules 를 누릅니다.
5	SNORT 규칙 파일을 골라 Open — 도구가 규칙을 Check Point 구문으로 변환하고 보호 데이터베이스를 갱신합니다.
6	SmartConsole 세션을 Publish 합니다.
7	해당 게이트웨이·클러스터에 Threat Prevention 정책을 설치합니다.

특정 SNORT 보호에 대해 프로파일 설정을 덮어쓰려면 아래 Custom — 운영의 Action on SNORT Protection Rules 를 참고하세요.

Security Management Server에서 SNORT 규칙 삭제

단계	내용
1	해당 게이트웨이·클러스터를 관리하는 Security Management Server에 SmartConsole로 접속합니다.
2	왼쪽 탐색 패널에서 Security Policies > Threat Prevention > Custom Policy 로 이동합니다.
3	아래쪽 Custom Policy Tools 영역에서 IPS Protections 로 갑니다.
4	위쪽 도구 모음에서 Actions > Snort protections > Delete all snort protections 를 누릅니다.
5	SmartConsole 세션을 Publish 합니다.
6	해당 게이트웨이·클러스터에 Threat Prevention 정책을 설치합니다.

Multi-Domain Server로 SNORT 규칙 가져오기

Multi-Domain 환경에서는 Multi-Domain Server로 가져온 뒤 Global 정책을 도메인에 할당합니다.

단계	내용
1	Multi-Domain Server의 MDS 컨텍스트 에 SmartConsole로 접속합니다.
2	왼쪽 탐색 패널에서 Multi-Domain > Domains 를 누릅니다.
3	Global Domain 을 오른쪽 클릭하고 Connect to domain 을 선택합니다.
4	왼쪽 탐색 패널에서 Security Policies 를 누릅니다.
5	해당 Global 정책을 엽니다.
6	위쪽에서 Threat Prevention > Custom Policy 로 이동합니다.
7	아래쪽 Custom Policy Tools 영역에서 IPS Protections 를 누릅니다.
8	도구 모음에서 Actions > Snort Protections > Import Snort rules 를 누릅니다.
9	규칙 파일을 골라 Open — 도구가 Check Point 구문으로 변환하고 데이터베이스를 갱신합니다.
10	세션을 Publish 합니다.
11	Global Domain에 연결된 SmartConsole을 닫습니다.
12	왼쪽 탐색 패널에서 Multi Domain > Global Assignments 로 이동합니다.
13	Global 정책을 로컬 도메인에 다시 할당(reassign) 합니다.
14	해당 게이트웨이·클러스터를 관리하는 Domain Management Server에 SmartConsole로 접속합니다.
15	해당 게이트웨이·클러스터에 Threat Prevention 정책을 설치합니다.

Multi-Domain Server에서 SNORT 규칙 삭제

단계	내용
1	Multi-Domain Server의 MDS 컨텍스트에 SmartConsole로 접속합니다.
2	Multi Domain > Domains 를 누릅니다.
3	Global Domain 을 오른쪽 클릭하고 Connect to domain 을 선택합니다.
4	Security Policies 를 누릅니다.
5	해당 Global 정책을 엽니다.
6	위쪽 Threat Prevention 에서 Policy 를 누릅니다.
7	아래쪽 Custom Policy Tools 에서 IPS Protections 를 누릅니다.
8	도구 모음에서 Actions > Snort Protections > Delete all Snort protections 를 누릅니다.
9	세션을 Publish 합니다.
10	Global Domain에 연결된 SmartConsole을 닫습니다.
11	Multi Domain > Global Assignments 로 이동합니다.
12	Global 정책을 로컬 도메인에 다시 할당합니다.
13	해당 게이트웨이·클러스터를 관리하는 Multi-Domain Server에 SmartConsole로 접속합니다.
14	해당 게이트웨이·클러스터에 Threat Prevention 정책을 설치합니다.

SNORT 보호에 동작 지정 (Action on SNORT Protection Rules)

게이트웨이는 자신에게 설치된 프로파일에 따라 SNORT 보호 규칙을 적용합니다. 예를 들어 설치된 프로파일이 Optimized 라면, SNORT 보호는 Performance Impact가 High 인데 Optimized가 허용하는 한도는 Medium 이하이므로, 기본적으로 적용되지 않 습니다. 특정 SNORT 보호만 프로파일 설정을 덮어쓰려면 이렇게 합니다.

단계	내용
1	IPS Protections 에서 SNORT 보호를 오른쪽 클릭하고 Edit 를 선택합니다(이름은 "Snort imported"로 시작합니다).
2	프로파일을 오른쪽 클릭하고 Edit 를 선택합니다.
3	Main Action 영역에서 Override with 를 선택합니다.
4	드롭다운에서 원하는 동작을 고릅니다.
5	OK 를 누릅니다.
6	Close 를 누릅니다.
7	SmartConsole 세션을 Publish 합니다.
8	Threat Prevention 정책을 설치합니다.

명령줄·API로 SNORT 규칙 추가·삭제하기

GUI 말고도 관리 서버에서 mgmt_cli 도구, SmartConsole CLI, Gaia Clish, POST 요청 으로 SNORT 보호를 추가·삭제할 수 있습니다.

SNORT 규칙 추가 명령은 인자 두 개를 받습니다 — package-format(항상 문자열 "snort")과 package-path(보호 패키지 경로). 성공하면 0, 실패하면 1 과 오류를 설명하는 파라미터 가 돌아옵니다.

# mgmt_cli 도구에서
mgmt_cli add threat-protections package-path "/path/to/community.rules" package-format "snort" --version 1.2 --format json

# SmartConsole CLI에서
add threat-protections package-path "/path/to/community.rules" package-format "snort" --version 1.2 --format json

# Gaia Clish에서
mgmt add threat-protections package-path "/path/to/community.rules" package-format "snort" --version 1.2 --format json

POST 요청 방식은 다음을 지켜야 합니다.

URL https://<ip-address-of-mgmt-server>:<port>/web_api/v1.2/add-threat-protections 로 보냅니다.
요청 헤더 Content-Type 을 application/json, X-chkp-sid 를 로그인 시 받은 세션 식별자로 설정합니다.
요청 본문에 package-format·package-path 인자를 담습니다.

성공하면 상태 코드 200, 실패하면 해당 상태 코드 가 반환됩니다.

POST {{server}}/v1.2/add-threat-protections
Content-Type: application/json
X-chkp-sid: {{session}}
{
"package-path" : "/path/to/community.rules",
"package-format" : "snort"
}

SNORT 보호 삭제 명령은 인자 하나 package-format(항상 "snort")만 받고, 마찬가지로 성공 시 0, 실패 시 1 을 돌려줍니다.

# mgmt_cli 도구에서
mgmt_cli delete threat-protections package-format "snort" --version 1.2

# SmartConsole CLI에서
delete threat-protections package-format "snort" --version 1.2

# Gaia Clish에서
mgmt delete threat-protections package-format "snort" --version 1.2

삭제용 POST 요청 은 URL https://<IP-address-of-mgmt-server>:<port>/web_api/v1.2/delete-threat-protections 로 보내고, 같은 헤더 규칙을 따르며 본문에 package-format 만 담습니다. 성공 시 상태 코드 200, 실패 시 해당 상태 코드를 받습니다.

Content-Type: application/json
X-chkp-sid: {{session}}
{
"package-format" : "snort"
}

SNORT 규칙 파일 직접 만들기

직접 SNORT 규칙을 써서 관리 서버로 가져오면 IPS 보호가 됩니다. Check Point는 SNORT 2.9 버전 이하 를 지원합니다. SNORT 규칙은 시그니처로 공격을 정의하며 규칙 헤더(Rule Header)와 규칙 옵션(Rule Options) 으로 이루어집니다. 가져온 보호의 이름은 원래 규칙의 msg 필드 값이 됩니다.

한 규칙 안에 같은 값의 msg 문자열이 여러 개 있으면, 관리 서버가 그 값들을 하나의 IPS SNORT 보호로 묶 습니다.
같은 msg 문자열을 가진 규칙을 다른 시점에 다시 가져오면, 나중 것이 기존 보호를 덮어 씁니다.

SNORT 규칙 구문 은 다음과 같습니다.

<Action> <Protocol> <Source IP Address> <Source Port> <Direction> <Destination IP Address> <Destination Port> (msg:"<Text>"; <Keyword>:"<Option>";)

논리적으로 두 부분으로 나뉩니다.

# Rule Header
<Action> <Protocol> <Address> <Port> <Direction> <Address> <Port>

# Rule Options
<keyword>:"<option>"

예를 들어 이런 규칙이 있다면:

alert tcp any any -> any 1:65535 (msg:"Possible exploit"; content:"|90|";)

각 요소는 — Action = alert, Protocol = TCP, Source IP = any, Source Port = any, Direction = ->, Destination IP = any, Destination Port(범위) = 1:65535, IPS 보호 이름 = Possible exploit, Keyword = content, Option = |90| 입니다.

지원되는 SNORT 구문

일반적으로 지원되는 구문 요소는 다음과 같습니다(아래 "지원되지 않는 구문"의 제약도 함께 보세요).

키워드	설명
`length`	`protected_content` 규칙의 digest에 지정된 콘텐츠의 원래 길이를 지정합니다.
`pcre`	Perl 호환 정규식으로 규칙을 쓰게 합니다. 예: `content:"/foo.php?id="; pcre:"/\/foo.php?id=[0-9]{1,10}/iU";`
`flowbits`	전송 프로토콜 세션 동안 상태를 추적합니다. Session preprocessor의 대화 추적과 함께 씁니다.
`byte_test`	바이트 필드를 특정 값과(연산자로) 비교합니다. 예: `byte_test: 4, >, 1024, 1, relative;`
`byte_jump`	길이로 인코딩된 프로토콜의 특정 구간을 건너뛰고 매우 구체적인 위치에서 탐지하게 합니다.
`isdataat`	페이로드의 지정 위치에 데이터가 있는지 확인합니다. 예: `isdataat: 300,relative;`
`no_match`	규칙이 일치해도 트래픽을 차단하지 않 습니다. `flowbits` 와 함께 써서 차단 없이 플래그만 세웁니다.

지원되지 않는 SNORT 구문

다음은 지원되는 범위와 한계입니다.

지원되는 content 키워드 수정자 — nocase, rawbytes, depth, offset:, distance:, within, urilen
지원되는 Threshold 규칙 형식 — Threshold, Both (Limit은 미지원)
지원되는 매크로 — HTTP_PORTS (80·8080 포트로 해석)

디버깅 시에는 관리 서버의 $FWDIR/log/SnortConvertor.elg 파일에 마지막 변환 실행의 디버그 메시지가 기록됩니다. 실패한 규칙을 찾으려면 이 파일에서 Failed to convert rule 을 검색하세요.

아래 구문은 변환되지 않 습니다.

PCRE 수정자 G, O, A
룩어헤드 어설션 ?! 이 들어간 PCRE 정규식
연산자가 <, >, =, &, ^ 에 속하지 않는 byte_test
SNORT 규칙에서 http_method 가 유일한 http 수정자일 때
프로토콜 icmp, ip (all 은 UDP·TCP로 해석)
content 키워드가 없는 SNORT 규칙
HTTP_PORTS 를 제외한 모든 PORT 매크로
소스 포트 지정 (any 만 지원)
목적지 포트 any 지정 (정확한 포트 번호나 범위를 반드시 지정해야 함)

다음 매크로·구문은 동작이 바뀐 채 변환됩니다.

IP 주소 지정 — 모든 IP 주소에 적용됨
HOME_NET 매크로 — any IP로 해석
EXTERNAL_NET 매크로 — any IP로 해석
HTTP_SERVERS 매크로 — any IP로 해석

또 일부 키워드·수정자 조합은 SNORT와 다르게 IPS blade에서 구현 됩니다(예: rawbytes content, "U" PCRE 수정자, http_uri 와 함께 쓴 "B" PCRE, content 와 byte_test 동시 사용, {} 수량자가 든 PCRE 키워드 등).

특히 urilen 키워드는 — http_uri 와 "U" PCRE 수정자만 있는 규칙이면 디코딩·정규화된 버퍼의 크기 가 되고, http_raw_uri 와 "I" PCRE 수정자만 있으면 원시(raw) uri 버퍼의 크기 가 됩니다.

SSL Services 키워드

Check Point는 일반 메타데이터 서비스 옵션 외에 SSL 트래픽 전용 키워드 도 지원합니다. SSL 트래픽용 SNORT 규칙은 metadata 키워드로 정의하며, 규칙 옵션에 다음을 넣습니다.

metadata: service <ssl service>;

예:

alert tcp any any -> any 443 (msg:"Fake SSL Certificate"; content:"|08 e4 98 72 49 bc 45 07 48 a4 a7 81 33 cb f0 41 a3 51 00 33|"; metadata: service sslHello;)

<ssl service> 에 쓸 수 있는 값은 다음과 같습니다.

서비스	설명
`sslHello`	흐름에 따라 Client Hello 또는 Server Hello를 검색합니다.
`sslCertificate`	흐름에 따라 Client/Server Certificate를 검색합니다.
`sslKeyx`	흐름에 따라 Client/Server Key Exchange를 검색합니다.
`sslHeartbeat`	SSL heartbeat를 검색합니다.
`sslCiphersuite`	클라이언트가 보낸 Cipher Suite를 검색합니다.

sslHello·sslCertificate·sslKeyx 를 쓸 때는 흐름 방향을 flow: to_server 또는 flow: from_server 로 반드시 지정 해야 합니다.

IPS 최적화 (Optimizing IPS)

IPS는 네트워크를 위협에서 지키는 강력한 솔루션이며, 여기서 다루는 권고를 따르면 보안과 성능을 함께 최적 으로 유지할 수 있습니다. 튜닝할 때 한 가지 염두에 둘 점은, Check Point가 성능 영향과 심각도를 HTTP·DNS·SMTP 같은 프로토콜에 더 무게를 둔 업계 표준 트래픽 혼합 을 기준으로 평가한다는 사실입니다. 네트워크에 다른 프로토콜이 많다면 그 점을 감안해 검사 부담과 위험도를 따져야 합니다.

게이트웨이에서 IPS 문제 해결하기

Prevent로 설정된 게이트웨이의 보호가 트래픽을 차단하지 못하도록 일시적으로 멈출 수 있어, 트래픽 문제를 진단할 때 유용합니다. Activation Mode 영역에서 Detect only 를 누르면, 모든 보호가 트래픽은 통과시키되 Track 설정에 따라 위협을 계속 기록 합니다.

성능 영향 관리 — Bypass Under Load

게이트웨이는 네트워크를 지키려고 많은 기능을 수행하므로, 트래픽 부하가 높을 때는 빠른 통과 능력이 영향 을 받을 수 있습니다. IPS에는 보안 요구와 성능 요구의 균형을 잡는 기능들이 있습니다.

Bypass Under Load 를 게이트웨이에 켜면, 네트워크 사용량이 과도할 때 IPS 활동을 잠시 내려놓 습니다. 보통 패킷 검사 시간은 눈에 띄지 않지만 부하가 심하면 연결·성능에 결정적 영향을 줄 수 있는데, 이때 IPS는 검사 없이 트래픽을 통과시키고, 게이트웨이 자원이 정상으로 돌아오면 검사를 재개 합니다.

무거운 부하에서 IPS 검사를 우회시키는 절차는 다음과 같습니다.

단계	내용
1	SmartConsole에서 Gateways & Servers 를 누르고 해당 Security Gateway를 더블 클릭합니다.
2	탐색 트리에서 IPS 를 누릅니다.
3	Bypass IPS inspection when gateway is under heavy load 를 선택합니다.
4	IPS가 꺼진 동안의 활동을 기록하려면 Track 드롭다운에서 추적 방식을 고릅니다.
5	무거운 부하의 정의를 설정하려면 Advanced 를 누릅니다.
6	High 칸에 — 무거운 부하로 간주해 IPS 검사를 우회할 CPU·메모리 사용률(%) 을 입력합니다.
7	Low 칸에 — 무거운 부하에서 정상 부하로 돌아왔다고 볼 CPU·메모리 사용률(%) 을 입력합니다.
8	OK 로 Gateway Load Thresholds 창을 닫습니다.
9	OK 를 누릅니다.
10	Threat Prevention 정책을 설치합니다.

보호 튜닝 — IPS Policy 설정

IPS Policy 설정은 몇 가지 기본 결정만으로 보호 전체를 통제 합니다. 낮은 심각도·낮은 신뢰도까지 포함해 보호를 많이 켜면 폭넓은 공격을 막지만, 감당하기 어려운 양의 로그·경보 가 생길 수 있습니다. 그런 수준의 보안이 민감한 데이터에는 꼭 필요할 수 있어도, 그렇지 않은 자원에 적용하면 시스템 자원·로그 관리에 부담을 줍니다.

세 가지 집중 전략이 있습니다.

High Severity(높은 심각도) 보호에 집중 — 보호는 심각도로 분류됩니다. 어떤 공격은 위험이 낮다(low severity)고 판단된다면, 심각도가 높은 보호만 켜 위험이 큰 공격 방어에 자원·로깅을 모읍니다.
High Confidence Level(높은 신뢰도) 보호에 집중 — 까다로운 공격을 잡으려면 넓은 보호 정의가 필요한데, 신뢰도가 낮은 보호는 시스템 이상이나 자체 제작 애플리케이션을 실제 공격이 아닌데도 탐지·기록할 수 있습니다. 신뢰도가 높은 보호만 켜 확실한 공격에 집중하세요. IPS Network Exceptions 도 위협이 아닌 트래픽의 로깅을 피하는 데 도움이 됩니다.
Low Performance Impact(낮은 성능 영향) 보호에 집중 — IPS는 멀티 기가비트 처리량을 유지하도록 설계됐지만, 일부 보호는 더 많은 자원을 씁니다. 영향이 낮은 보호만 켜 게이트웨이 자원 사용을 줄일 수 있습니다.

자동 보호 활성화에 대해서는 정책과 프로파일의 Automatically Activating Protections 를 참고하세요.

Allow List (허용 목록) 사용하기

Allow List 는 신뢰하는 파일 목록 입니다. Check Point Threat Prevention 엔진은 신뢰 파일을 멀웨어·바이러스·봇 검사에서 제외 해 게이트웨이의 자원 사용을 줄입니다. 프로파일·규칙 구성의 예외 규칙이 "특정 보호를 끄는" 쪽이라면, Allow List는 특정 파일을 통째로 신뢰 하는 쪽입니다.

파일을 Allow List에 추가 하기.

단계	내용
1	Threat Prevention > Custom Policy Tools > Allow List Files 를 선택해 Allow List Files 페이지를 엽니다.
2	New 를 눌러 New File Exception 창을 엽니다.
3	새 파일 예외의 파라미터를 입력합니다 — Name, Comment(선택), MD5 signature, 색상(선택, 기본 검정).
4	OK 를 누릅니다.

파일 속성을 편집 하려면 같은 페이지에서 파일을 고르고 Edit 를 누른 뒤, 속성 창에서 고치고 OK 를 누릅니다. 삭제 하려면 파일을 하나 이상 골라 Delete 를 누릅니다.

VSX 게이트웨이에서의 Threat Prevention 설정

VSX 게이트웨이 에서는 가상 시스템(Virtual System)마다 보안이 독립 적이므로 Software Blade를 VSX와 각 Virtual System에 맞춰 켜야 합니다(VSX 가이드). 자세한 내용은 sk106496·sk79700을 참고하세요.

Anti-Bot · Anti-Virus · IPS 켜기

단계	내용
1	필요하면 SmartConsole에서 VS0·Virtual System(또는 둘 다)의 프록시를 설정합니다 — Gateways & Servers 에서 객체를 더블 클릭, 탐색 트리의 Topology > Proxy 에서 프록시를 구성하고 OK.
2	VS0(VSX 게이트웨이/클러스터)에서 Software Blade를 켭니다 — 객체를 더블 클릭, General Properties 의 Threat Prevention 탭에서 Anti-Bot·Anti-Virus·IPS 중 필요한 것을 선택합니다. First Time Activation 창이 열리면 According to the policy 또는 Detect only 를 고르고, 켠 blade를 구성한 뒤 OK.
3	해당 Virtual System 에서 같은 Software Blade를 켭니다 — VSX 객체를 펼쳐 Virtual System 객체를 더블 클릭, General Properties 의 Threat Prevention 탭에서 VS0에서 고른 것과 같은 blade를 선택하고 First Time Activation에서 According to the policy 또는 Detect only 를 고른 뒤 구성하고 OK.
4	VS0와 해당 Virtual System의 Threat Prevention 정책을 구성합니다.
5	VSX 게이트웨이/클러스터에 기본 VSX 정책을 설치합니다. 이름은 `<VSX 게이트웨이/클러스터 객체 이름>_VSX` 형태입니다.
6	Threat Prevention 정책을 VS0와 해당 Virtual System(필요하면 Access Control 정책도)에 설치합니다.

Threat Emulation 켜기

단계	내용
1	필요하면 VS0·Virtual System의 프록시를 설정합니다(Topology > Proxy).
2	해당 Virtual System 에서 Threat Emulation을 켭니다 — Virtual System 객체를 더블 클릭, General Properties 의 Custom Threat Prevention 탭에서 SandBlast Threat Emulation 을 선택하면 Threat Emulation First Time Activation Wizard 가 열립니다. Emulation Location 을 구성하고 Next, Activate Threat Extraction 페이지를 구성하고 Next, 요약에서 Finish, 켠 blade를 구성한 뒤 OK.
3	해당 Virtual System의 Threat Prevention 정책을 구성합니다.
4	해당 Virtual System(필요하면 Access Control 정책도)에 Threat Prevention 정책을 설치합니다.

Threat Extraction 켜기

단계	내용
1	필요하면 VS0·Virtual System의 프록시를 설정합니다(Topology > Proxy).
2	해당 Virtual System 에서 Threat Extraction을 켭니다 — Virtual System 객체를 더블 클릭, General Properties 의 Threat Prevention 탭에서 SandBlast Threat Extraction 을 선택하고 OK.
3	(선택) Threat Extraction을 켜면 HTTP·HTTPS 웹 트래픽 지원은 자동으로 켜집니다. 이메일 첨부까지 검사하려면 게이트웨이를 Mail Transfer Agent(MTA) 로 구성하세요(Anti-Spam과 메일).
4	VS0와 해당 Virtual System의 Threat Prevention 정책을 구성합니다.
5	VSX 게이트웨이/클러스터에 기본 VSX 정책(`<객체 이름>_VSX`)을 설치합니다.
6	Threat Prevention 정책을 VS0와 해당 Virtual System(필요하면 Access Control 정책도)에 설치합니다.

Legacy VSX에서는 Anti-Virus·Anti-Bot도 수동으로 켜야 합니다(Custom 시작하기 참고).

SSH Deep Packet Inspection (SSH DPI)

SSH Deep Packet Inspection(SSH DPI)은 SSH 트래픽을 복호화·재암호화 해 Threat Prevention이 고급 위협·봇·멀웨어를 검사 할 수 있게 하는 기능입니다. 동기와 목표는 분명합니다.

SSH 공격 차단
SCP·SFTP 프로토콜을 통한 바이러스 전송 차단
SSH/SFTP 서버에 대한 무차별 대입(brute force) 암호 크래킹 방지
위험한 SSH Port forwarding 사용 방지
"password" 같은 단순 암호 사용 방지
취약한 암호화(cryptography) 사용 방지
취약한 SSH 클라이언트·서버 사용 방지
22번 포트를 SSH 외 다른 프로토콜에 쓰는 것 방지

SSH DPI 구조

HTTPS Inspection과 비슷하게, SSH DPI는 중간자(man-in-the-middle) 로 동작합니다.

SSH_CLIENT <=> Security Gateway <=> SSH_SERVER

SSH DPI 켜기·끄기·상태 보기

게이트웨이에서 다음을 실행합니다.

cpssh_config ion       # SSH DPI 켜기
fw fetch local         # 정책 적용 (또는 SmartConsole에서 Access Control 정책 설치)

cpssh_config ioff      # SSH DPI 끄기
cpssh_config istatus   # SSH DPI 상태 보기

검사할 SSH 서버 추가하기

비투명(non-transparent) 방식은 게이트웨이가 새 공개 키로 서버를 클라이언트에 소개 합니다.

단계	내용
1	SSH 서버의 공개 키를 게이트웨이로 복사합니다(Linux에서 게이트웨이 키는 `/etc/ssh/ssh_host_rsa_key.pub`).
2	게이트웨이에서 다음을 실행합니다.<br>`cpssh_config -s -g SERVER_NAME -e /PATH/TO/RSA/KEY/THAT/YOU/COPIED.pub`
3	추가할 SSH 서버마다 1~2단계를 반복합니다.

예: 서버 호스트가 my_ssh_server_host.com 이고 키를 /home/admin/mykey.pub 로 복사했다면 —

cpssh_config -s -g my_ssh_server_host.com -e /home/admin/mykey.pub

투명(transparent) 방식은 게이트웨이가 원래 공개 키로 서버를 소개 합니다.

단계	내용
1	SSH 서버의 공개 키·개인 키를 게이트웨이로 복사합니다(게이트웨이 키: `/etc/ssh/ssh_host_rsa_key.pub`, `/etc/ssh/ssh_host_rsa_key`).
2	다음을 실행합니다.<br>`cpssh_config -s -a <SERVER_NAME> -e <...COPIED>.pub -i <...PRIVATE_KEY...>`
3	추가할 서버마다 1~2단계를 반복합니다.

예:

cpssh_config -s -a my_ssh_server_host.com -e /home/admin/mykey.pub -i /home/admin/mykey

SSH port forwarding 끄기 — 게이트웨이에서:

cpssh_config -w Global -y Port_fowarding_Enabled -u 0

비표준 포트에서 SSH DPI 실행하기

기본 TCP 22번이 아닌 포트에서 SSH DPI를 돌리려면 새 TCP 서비스를 만듭니다.

단계	내용
1	SmartConsole 오른쪽 패널에서 Objects > Services 를 선택합니다.
2	TCP 를 오른쪽 클릭하고 NEW TCP 를 고릅니다.
3	새 TCP 서비스 이름을 입력하고 — General > Protocol 을 SSH2 로, Match By > Customize to new port 에서 포트(예: `22222`)를 지정합니다.
4	Access Control 정책을 설치합니다.

IPS·Anti-Virus 검사 연동

SSH DPI에서 IPS 패키지 를 적용하려면 — SmartConsole에서 게이트웨이 객체와 해당 Threat Prevention 정책에 IPS Software Blade 를 켜고 Threat Prevention 정책을 설치합니다. Anti-Virus 검사도 같은 방식으로 게이트웨이 객체와 정책에 Anti-Virus blade를 켜고 정책을 설치합니다.

SSH DPI 설정 보기·변경

cpssh_config -q              # 모든 설정 보기
cpssh_config -w KeyExchange  # 키 교환 옵션 보기
cpssh_config -w Cipher       # 암호(cipher) 옵션 보기
cpssh_config -w Mac          # MAC 옵션 보기
cpssh_config -w Hostkey      # Hostkey 옵션 보기

옵션을 설정하려면 cpssh_config -w <영역> -y <OPTION> -u <VALUE> 형식을 씁니다. 예를 들어 aes128-cbc 를 끄려면:

cpssh_config -w Cipher -y aes128-cbc -u 0

클라이언트 인증 (키 기반, 암호 없이)

암호 대신 키로 인증 하도록 설정할 수 있습니다.

단계	내용
1	SSH 서버가 키로 인증하도록 설정합니다 — 클라이언트의 공개 키를 서버의 `~/.ssh/authorized_keys/` 에 복사합니다(자세한 내용은 askubuntu.com).
2	SSH 클라이언트의 공개·개인 키(`mykey.pub`, `mykey`)를 게이트웨이로 복사합니다.
3	SSH 서버의 공개 키(`serverkey.pub`)를 게이트웨이로 복사합니다.
4	다음을 실행합니다.<br>`cpssh_config -c -a <admin_username>@<my_ssh_server> -e /home/admin/mykey.pub -l /home/admin/serverkey.pub -i /home/admin/mykey`

여기서 — admin_username 은 SSH 서버의 사용자 이름, my_ssh_server 는 서버의 확인 가능한(resolvable) 호스트 이름·IP, mykey.pub·mykey 는 클라이언트 키 쌍입니다.

클러스터에서의 키 동기화

현재 클러스터 노드 간 키 자동 동기화는 지원되지 않 습니다. 키를 추가·수정·삭제한 뒤에는 수동으로 동기화해야 합니다. 키를 추가한 멤버에서 Expert mode로:

cd /etc/
tar -cvvf ssh.tar ssh
scp ssh.tar admin@<IP_OF_OTHER_CLUSTER_MEMBER>:/tmp

다른 클러스터 멤버에서 Expert mode로:

mv -v /tmp/ssh.tar /etc/
cd /etc/
mv -v ssh ssh_backup
tar -xvvf ssh.tar
killall -s HUP cpsshd

문제 해결과 디버깅

SSH DPI가 켜졌는지 확인하려면 telnet 으로 SSH 서버에 접속 해 봅니다. 출력에 SSH-2.0-cpssh 가 보이면 켜진 것입니다.

$ telnet 172.23.43.29 22
Trying 172.23.43.29...
Connected to 172.23.43.29.
Escape character is '^]'.
SSH-2.0-cpssh

커널 디버그 를 수집하려면 — 커널 디버그 모듈 fw 에서 디버그 플래그 cpsshi 를 켜고, 커널 디버그 모듈 CPSSH 의 모든 플래그를 켭니다(자세한 절차는 R82 Quantum Security Gateway Guide의 Kernel Debug 장 참고).

사용자 공간(User Space) 디버그 를 수집하려면 다음 스크립트를 만들어 실행합니다.

echo > $FWDIR/log/cpsshd.elg
for PROC in $(pidof cpsshd)
do
fw debug $PROC on ALL=6
done
tail -f $FWDIR/log/cpsshd.elg

출력을 멈추려면 CTRL+C 를 누릅니다. 문제를 재현(또는 발생을 기다림)한 뒤, 다음으로 사용자 공간 로그를 끕니다.

for PROC in $(pidof cpsshd) ; do fw debug $PROC off ALL=6 ; done

마지막으로 로그 파일 $FWDIR/log/cpsshd.elg* 를 살펴봅니다.

Check Point ThreatCloud

Check Point ThreatCloud 는 전 세계 위협 센서와, 위협 데이터를 공유하며 최신 멀웨어에 함께 맞서는 조직들 의 혁신적 글로벌 네트워크에 기반해 동적으로 갱신되는 서비스 입니다. 고객은 자신의 위협 데이터를 ThreatCloud에 보내 더 높은 보안·보호와 풍부해진 위협 인텔리전스를 누립니다. ThreatCloud는 공격 정보를 배포하고 제로데이 공격을 알려진 시그니처로 바꿔 Anti-Virus가 차단 할 수 있게 합니다. 이때 게이트웨이는 어떤 개인 정보도 수집·전송하지 않 습니다.

정보 수집에 참여하는 것은 Check Point 고객이 고급 보안 연구의 전략적 커뮤니티의 일원 이 되는 기회로, 이 연구는 보안 서비스의 적용 범위·품질·정확도를 높이는 것을 목표로 합니다.

ThreatCloud 저장소에는 봇 탐지를 위해 분석된 2억 5천만 개가 넘는 주소 와 2,000개 이상의 봇넷 통신 패턴 이 있고, ThreatSpect 엔진은 이 정보로 봇과 바이러스를 분류합니다. 또 ThreatSpect 엔진의 reputation·signature 계층을 위해 각 게이트웨이에는 다음이 있습니다.

로컬 Malware 데이터베이스 — 자주 쓰이는 시그니처·URL과 그 reputation을 담습니다. 자동 또는 예약 업데이트 를 설정할 수 있습니다.
로컬 캐시 — URL reputation 요청의 99% 에 답합니다. 캐시에 답이 없으면 ThreatCloud 저장소에 질의합니다 — Anti-Virus는 시그니처를 파일 분류용으로, Anti-Bot은 호스트 이름을 reputation 분류용으로 보냅니다.

ThreatCloud 저장소는 ThreatWiki 로 열람할 수 있습니다 — 웹 브라우저에서 Check Point ThreatWiki로 가거나, SmartConsole에서 Security Policies > Threat Prevention > Custom Policy 의 Custom Policy Tools 영역에서 ThreatWiki 를 누릅니다. 필요하면 SmartConsole에서 특정 멀웨어를 규칙 예외에 추가 할 수 있습니다 — Custom Policy에서 예외를 추가하고, 규칙 예외의 Protection 열에서 + 를 누른 뒤 해당 보호 옆의 + 를 누릅니다.

Check Point가 수집하는 데이터

정보 수집을 켜면 게이트웨이는 잠재적 보안 위험과 관련된 이벤트 ID, URL, 외부 IP 주소 를 수집해 Check Point Lab에 안전하게 제출합니다. 예시 이벤트는 다음과 같습니다.

<entry engineType="3" sigID="-1" attackName="CheckPoint - Testing Bot" sourceIP="7a1ec646fe17e2cd" destinationIP="d8c8f142" destinationPort="80" host="www.checkpoint.com" path="/za/images/threatwiki/pages/TestAntiBotBlade.html" numOfAttacks="20" />

이는 게이트웨이가 탐지한 이벤트의 예로 이벤트 ID·URL·외부 IP를 담지만, 기밀 데이터나 내부 자원 정보는 들어 있지 않 으며 소스 IP는 가려집니다. Check Point Lab으로 보낸 정보는 집계된 형태(aggregated form) 로 저장됩니다.

게이트웨이에서 ThreatCloud 구성하기

게이트웨이가 ThreatCloud와 정보를 공유하도록 설정하는 절차입니다.

단계	내용
1	Security Gateway를 더블 클릭해 General Properties 페이지를 엽니다.
2	Anti-Bot·Anti-Virus 설정 — 탐색 트리에서 Anti-Bot and Anti-Virus 를 누르고, Support the global community by sharing attack data with Check Point ThreatCloud 를 선택합니다. 체크하지 않으면 공격 정보가 공유되지 않습니다. 체크하면 어떤 정보를 노출할지 고를 수 있습니다 — Receive alerts about threats(모든 공격 정보 노출, 추가 최종 사용자 데이터 공유 필요), Anonymize collected data(기본 선택). 후자는 다시 End-user data(기본, 최종 사용자 정보는 익명화하되 게이트웨이는 노출)와 End-user data and customer identity(최종 사용자·게이트웨이 데이터 모두 숨김) 중 하나를 고릅니다.
3	IPS 설정 — 탐색 트리에서 IPS 를 누르고, Help Improve Check Point Threat Prevention product by sending anonymous information about feature usage, infections details and product customizations 를 선택합니다(IPS 정보 공유를 끄려면 이 옵션을 해제).
4	OK 를 누릅니다.

Check Point ThreatCloud Network 차단하기

파일을 ThreatCloud로 보내 에뮬레이션하면 최신 위협 정보와 운영체제 환경 을 받게 됩니다. ThreatCloud 연결은 기본으로 켜져 있고, 많은 관리 기능을 주므로 켜 두기를 권장 합니다. 다만 이 연결을 막고 싶으면 기본값을 바꿀 수 있습니다.

단계	내용
1	메뉴 바에서 Global Properties 를 누릅니다.
2	탐색 트리에서 Data Access Control 로 이동합니다.
3	Help Check Point Improve the product by sending anonymous information 을 해제합니다.
4	SmartConsole 세션을 Publish 합니다.
5	SmartConsole을 재시작합니다.
6	정책을 설치합니다.

이런 고급 설정과 운영 작업은 Custom — 운영에서 이어지는 일상 관리·모니터링과 함께 쓰입니다.