14Security Gateway 특수 시나리오 — Monitor·Bridge ModeSecurity Gateway 특수 시나리오 — Monitor·Bridge Mode

Monitor Mode 는 운영 환경을 전혀 바꾸지 않고 네트워크 트래픽을 분석 하는 배포입니다. Check Point Security Gateway의 인터페이스 하나를 스위치의 Mirror Port(또는 Span Port)에 연결하면, 스위치가 오가는 모든 패킷을 복제해서 게이트웨이로 보내 줍니다. 게이트웨이는 이 복제 트래픽을 듣기만 하면서 활동 로그를 기록합니다. 이 인터페이스에서는 어떤 보안 정책도 집행하지 않고(prevent/drop/reject 같은 능동적 동작 없음), 도착한 패킷을 전부 종료(terminate)할 뿐 다시 내보내거나 전달하지 않 습니다. 즉 Monitor Mode 인터페이스로는 게이트웨이가 어떤 트래픽도 내보내지 않 습니다.

Monitor Mode를 쓰는 대표적인 두 가지 목적은 다음과 같습니다.

장점은 분명합니다.

Monitor Mode 토폴로지 예시

Monitor Mode에서 지원되는 Software Blade

단일 Security Gateway 배포에서 각 Software Blade가 Monitor Mode를 얼마나 지원하는지 정리한 표입니다.

Monitor Mode의 제약

다음 기능·배포는 Monitor Mode에서 지원되지 않습니다.

단일 Security Gateway를 Monitor Mode로 구성하기

1. Security Gateway 설치

최초 구성 마법사에서의 설정입니다.

2. 해당 인터페이스에 Monitor Mode 구성

Monitor Mode는 Gaia Portal 또는 Gaia Clish 에서 인터페이스에 설정할 수 있습니다.

Gaia Portal에서 구성

Ethernet 탭에서 다룰 항목은 다음과 같습니다.

Gaia Clish에서 구성

게이트웨이 명령줄에 접속해 Gaia Clish에 로그인한 뒤, 먼저 인터페이스 상태를 확인하고 IP 주소가 있으면 제거합니다.

show interface <물리 인터페이스 이름>

IPv4·IPv6 주소를 제거합니다(있는 경우).

delete interface <물리 인터페이스 이름> ipv4-address
delete interface <물리 인터페이스 이름> ipv6-address

물리 인터페이스에 Monitor Mode를 켜고, 필요한 다른 설정을 적용한 뒤 상태를 다시 확인하고 저장합니다.

set interface <물리 인터페이스 이름> monitor-mode on
set interface <물리 인터페이스 이름> ...
show interface <물리 인터페이스 이름>
save config

3. SmartConsole에서 Security Gateway 오브젝트 구성

SmartConsole에서 게이트웨이 오브젝트는 Wizard Mode 또는 Classic Mode 로 만들 수 있습니다.

Wizard Mode로 구성

Classic Mode로 구성

cpconfig에서 SIC를 다시 설정할 때 입력하는 옵션입니다.

cpconfig

Secure Internal Communication

4. 순서가 뒤바뀐 패킷을 처리하도록 게이트웨이 구성

Mirror/SPAN 포트로는 TCP [SYN]보다 [SYN-ACK]가 먼저 도착하는 등 패킷이 비정상적인 순서로 들어올 수 있습니다. 이를 대비해 PSL(Passive Streaming Layer) Tap Mode 와 Firewall Tap Mode 를 켭니다.

게이트웨이 Expert 모드에서 먼저 $FWDIR/boot/modules/fwkern.conf 를 수정합니다. 백업(없으면 생성)하고 편집합니다.

cp -v $FWDIR/boot/modules/fwkern.conf{,_BKP}
touch $FWDIR/boot/modules/fwkern.conf
vi $FWDIR/boot/modules/fwkern.conf

다음 두 줄을 추가합니다.

fw_tap_enable=1

이어 $PPKDIR/conf/simkern.conf 를 백업(없으면 생성)·편집합니다.

cp -v $PPKDIR/conf/simkern.conf{,_BKP}
touch $PPKDIR/conf/simkern.conf
vi $PPKDIR/conf/simkern.conf

다음 한 줄을 추가하고 저장 후 종료합니다.

fw_tap_enable=1

게이트웨이를 재부팅한 뒤, 새 구성이 적재됐는지 확인합니다.

fw ctl get int psl_tap_enable
fw ctl get int fw_tap_enable

각각 psl_tap_enable = 1, fw_tap_enable = 1 이 나와야 합니다.

5. SmartConsole에서 필요한 Global Properties 구성

Monitor Mode 트래픽은 게이트웨이를 실제로 통과하지 않 으므로, 상태(state) 정보가 기록되지 않습니다. 그래서 out-of-state로 드롭되지 않도록 전역 설정을 조정해야 합니다.

6. SmartConsole에서 필요한 Access Control 정책 구성

7. Software Blade용 Monitor Mode가 켜졌는지 확인

게이트웨이 Expert 모드에서, 설치된 정책에 fw_span_port_mode 파라미터가 들어갔는지 확인합니다.

grep -A 3 -r fw_span_port_mode $FWDIR/state/local/*

반환 결과에 다음이 나와야 합니다.

:val (true)

8. 게이트웨이를 스위치에 연결

게이트웨이의 Monitor Mode 인터페이스를 스위치의 mirror/SPAN 포트에 연결합니다. 더 자세한 내용은 R82 Gaia Administration Guide, R82 Security Management Administration Guide를 참고하세요.

단일 VSX Gateway를 Monitor Mode로 구성하기

VSX Gateway에도 Monitor Mode를 구성할 수 있습니다. 큰 흐름은 단일 게이트웨이와 같되, VSX 특유의 단계(Virtual System 구성, Anti-Spoofing 해제 등)가 더해집니다.

1. VSX Gateway 설치

Gaia OS 설치 → 최초 구성 마법사 진행은 단일 게이트웨이와 동일합니다. 마법사에서 Internet Connection 은 IP를 구성하지 않고, Products 는 Security Gateway만 + Clustering 해제, Dynamically Assigned IP 는 No, Secure Internal Communication 에 Activation Key(4~127자)를 입력합니다.

2. 해당 인터페이스에 Monitor Mode 구성

Gaia Portal·Gaia Clish 절차는 단일 Security Gateway와 동일 합니다(앞의 표·명령 참고). Portal에서는 인터페이스를 Enable하고 IPv4/IPv6 주소를 비운 채 Ethernet 탭에서 Monitor Mode 를 선택하며, Clish에서는 IP 주소 제거 후 set interface <이름> monitor-mode on → save config 를 실행합니다.

3. 순서가 뒤바뀐 패킷을 처리하도록 VSX Gateway 구성

$FWDIR/boot/modules/fwkern.conf 에 psl_tap_enable=1·fw_tap_enable=1 을, $PPKDIR/conf/simkern.conf 에 fw_tap_enable=1 을 추가하는 절차도 단일 게이트웨이와 동일합니다. 재부팅 후 fw ctl get int psl_tap_enable·fw ctl get int fw_tap_enable 로 각각 값이 1인지 확인합니다(참고 사항도 위와 같습니다 — 순서가 뒤바뀐 패킷 처리, 초기 10~30분 개선, 분리된 TX/RX 큐 환경 필수, 동작 중 즉시 변경 불가).

4. SmartConsole에서 VSX Gateway 오브젝트 구성

오브젝트 생성 전후로 VSX 구성을 점검하고, 기본 정책을 설치합니다. 명령줄 Expert 모드에서 다음을 실행합니다.

vsx stat -v

기본 정책 설치는 Install Policy → Policy 필드에서 <VSX Gateway 오브젝트 이름>_VSX 를 선택 → Install 입니다. SIC를 다시 설정할 때는 cpconfig 에서 Secure Internal Communication 옵션을 사용합니다.

5. SmartConsole에서 Virtual System(및 기타 Virtual Device) 구성

6. SmartConsole에서 Virtual System용 Global Properties 구성

단일 게이트웨이의 5단계와 동일합니다. Stateful Inspection 에서 TCP session timeout을 60초, TCP end timeout을 5초로 바꾸고 Out of state packets 의 모든 체크박스를 해제하며(해제하지 않으면 Virtual System이 out of state로 드롭함), Advanced > FireWall-1 > Stateful Inspection 에서 reject_x11_in_any 를 해제합니다. OK 후 Publish.

7. SmartConsole에서 Virtual System용 Access Control 정책 구성

새 정책·레이어를 만들고 모든 트래픽을 허용하는 규칙을 추가합니다.

Best Practice — 단일 게이트웨이와 동일하게 흔한 TCP 서비스에 Aggressive Aging(Specific 60초)을 권장합니다. 그다음 세션을 Publish하고, Virtual System 오브젝트에 Install Policy → 해당 정책 선택 → Install 합니다. 설치 후 vsx stat -v 로 구성을 다시 점검합니다.

8. Software Blade용 Monitor Mode가 켜졌는지 확인

VSX Gateway Expert 모드에서, 설치된 정책에 fw_span_port_mode 가 포함됐는지 확인합니다.

grep -A 3 -r fw_span_port_mode $FWDIR/state/local/*

결과에 :val (true) 가 나와야 합니다.

9. VSX Gateway를 스위치에 연결

Monitor Mode 인터페이스를 스위치의 mirror/SPAN 포트에 연결합니다. 자세한 내용은 R82 Gaia·VSX·Security Management Administration Guide를 참고하세요.

Monitor Mode용 개별 Software Blade 구성

Monitor Mode에서 특정 Blade를 쓸 때의 추가 설정입니다.

Threat Prevention Software Blade

IPS·Anti-Bot·Anti-Virus·Threat Emulation·Threat Extraction 중 하나라도 Monitor Mode 게이트웨이에서 켰다면 아래를 설정합니다.

자세한 내용은 R82 Threat Prevention Administration Guide를 참고하세요.

Application Control 및 URL Filtering

해당 Blade를 켰다면 — 관리 서버에서 Manage & Settings > Blades 로 가서 Application Control & URL Filtering 섹션의 Advanced Settings 를 엽니다.

OK로 닫고 게이트웨이 오브젝트에 Access Control Policy를 설치합니다(자세한 내용은 R82 Security Management Administration Guide, R82 Quantum Security Gateway Guide).

Data Loss Prevention(DLP)

DLP Blade를 켰다면 — Manage & Settings > Blades 의 Data Loss Prevention 섹션에서 Configure in SmartDashboard 를 엽니다.

게이트웨이가 SMTP Mirror Port Mode 를 켰는지 Expert 모드에서 확인합니다.

dlp_smtp_mirror_port status

커널 파라미터 dlp_force_smtp_kernel_inspection 값이 1인지 두 명령으로 확인합니다.

fw ctl get int dlp_force_smtp_kernel_inspection
grep dlp_force_smtp_kernel_inspection $FWDIR/boot/modules/fwkern.conf

자세한 내용은 R82 Data Loss Prevention Administration Guide를 참고하세요.

프록시 서버 뒤의 Monitor Mode 구성

Monitor Mode 게이트웨이와 스위치 사이에 Proxy Server 가 끼어 있으면, 로그에서 Source IP와 Source User 를 보려면 다음을 설정합니다.

기존 네트워크를 IP가 다른 여러 네트워크로 나눌 수 없을 때 Bridge Mode 로 게이트웨이(또는 ClusterXL)를 설치 합니다. Bridge Mode의 게이트웨이는 Layer 3 트래픽에 보이지 않 습니다 — 한 bridge subordinate 인터페이스로 트래픽이 들어오면 게이트웨이(또는 Cluster Member)가 그것을 검사한 뒤 두 번째 subordinate 인터페이스로 넘깁 니다. 즉 라우팅 구조를 다시 짜지 않고도 두 포트 사이에 보안 검사를 끼워 넣는, 두 포트짜리 Layer 2 스위치 같은 셈입니다.

Bridge Mode에서 지원되는 Software Blade

다음 표는 단일 Security Gateway, ClusterXL(스위치 한 대) Active/Active·Active/Standby, ClusterXL(스위치 네 대) 배포에 적용됩니다. 각 칸의 (1)·(2)·(3)은 아래 각주를 가리킵니다.

각주는 다음과 같습니다.

Bridge Mode의 제약

하나의 Bridge 인터페이스에는 subordinate 인터페이스를 두 개만 둘 수 있습니다 — 이 Bridge를 두 포트짜리 Layer 2 스위치로 생각하면 됩니다. 각 포트는 물리 인터페이스, VLAN 인터페이스, 또는 Bond 인터페이스가 될 수 있습니다.

Bridge Mode에서 지원되지 않는 것들입니다.

단일 Security Gateway를 Bridge Mode로 구성하기

토폴로지 예시

1. Security Gateway 설치

Gaia OS 설치 → 최초 구성 마법사 진행. 마법사 설정은 Monitor Mode 단일 게이트웨이와 동일합니다 — Management Connection에서 접속 인터페이스 선택, Internet Connection은 IP 미구성, Installation Type은 Security Gateway and/or Security Management, Products는 Security Gateway만 + Clustering 해제, Dynamically Assigned IP는 No, SIC에 Activation Key(4~127자) 입력.

2. Bridge 인터페이스 구성

Bridge 인터페이스는 Gaia Portal 또는 Gaia Clish 에서 만듭니다.

Gaia Portal에서 구성

5단계의 주의 사항입니다.

7단계(IPv6)의 중요 사항입니다.

Gaia Clish에서 구성

게이트웨이 명령줄에서 Gaia Clish에 로그인한 뒤, subordinate 인터페이스에 IP가 없는지 확인합니다.

show interface <인터페이스 이름> ipv4-address
show interface <인터페이스 이름> ipv6-address

새 bridging group을 만들고 subordinate 인터페이스 두 개를 추가합니다.

add bridging group <Bridge Group ID 0 - 1024>
add bridging group <Bridge Group ID> interface <첫 번째 subordinate 인터페이스 이름>
add bridging group <Bridge Group ID> interface <두 번째 subordinate 인터페이스 이름>

bridging group에 IP 주소를 할당합니다(IPv4 또는 IPv6, 자동 취득도 가능). IPv6는 먼저 IPv6 Support를 켜고 재부팅해야 합니다.

set interface <Bridge 인터페이스 이름> ipv4-address <IPv4 주소> {subnet-mask <마스크> | mask-length <마스크 길이>}
set interface <Bridge 인터페이스 이름> ipv6-address <IPv6 주소> mask-length <마스크 길이>

마지막으로 저장합니다.

save config

3. SmartConsole에서 Security Gateway 오브젝트 구성

Wizard Mode 또는 Classic Mode로 만듭니다. SIC 수립·Platform·Trust 단계는 Monitor Mode와 동일하며, Bridge에 특화된 차이 는 Software Blade 선택과 Topology입니다.

Wizard Mode — General Properties(이름·platform·Static IP)와 Trusted Communication, End 페이지를 거쳐 게이트웨이 속성을 엽니다. 그다음 General Properties 의 Network Security 탭과 Threat Prevention 탭에서 필요한 Blade를 켜고, Network Management 페이지에서 Bridge 인터페이스의 Topology 를 구성합니다. OK → Publish.

Classic Mode — Name·IPv4/IPv6 입력 → SIC 수립(필요 시 cpconfig 의 Secure Internal Communication으로 Key 재설정 후 Reset/Initialize) → Platform(Hardware/Version R82/OS Gaia) → Network Security·Threat Prevention 탭에서 Blade 활성화 → Network Management에서 Bridge Topology 구성 → OK → Publish.

4. SmartConsole에서 보안 정책 구성

관리 서버에 접속해 Security Policies 에서 새 정책·레이어를 만들고, Access Control과 Threat Prevention 정책에 필요한 규칙을 만듭니다(앞의 지원·제약 표 확인). 그다음 게이트웨이 오브젝트에 Access Control Policy 와 Threat Prevention Policy 를 각각 설치합니다. 자세한 내용은 R82 Gaia·Security Management Administration Guide와 R82 Home Page의 해당 가이드를 참고하세요.

ClusterXL을 Bridge Mode로 구성하기

ClusterXL은 다음 배포로 Bridge Mode를 구성할 수 있습니다.

Active/Standby — 스위치 두 대

토폴로지 예시(스위치 두 대)

1. 두 Cluster Member 설치 — Gaia OS 설치 → 최초 구성 마법사. Installation Type은 Security Gateway and/or Security Management, Products는 Security Gateway만, Clustering 섹션에서 Unit is a part of a cluster 와 ClusterXL 두 가지를 선택, SIC에 Activation Key 입력.

2. SmartConsole에서 High Availability ClusterXL 오브젝트 구성 — Wizard 또는 Classic Mode로 진행합니다.

Wizard Mode 큰 흐름은 다음과 같습니다.

Classic Mode는 마법사 없이 같은 항목(Machine/Platform/Cluster Members/ClusterXL and VRRP/Network Management)을 직접 설정하는 차이만 있고 내용은 동일합니다.

Network Type 설정(공통) — 각 인터페이스를 Edit → General 페이지의 Network Type 을 정합니다.

동기화 인터페이스의 규칙입니다.

Topology 섹션의 규칙입니다.

3. 보안 정책 구성 — 새 정책·레이어를 만들고 Access Control·Threat Prevention 규칙을 작성한 뒤(지원·제약 표 확인) ClusterXL 오브젝트에 각각 설치합니다.

4. 클러스터 구성 점검 — 각 Member 명령줄에서 상태와 인터페이스를 확인합니다.

show cluster state          # Gaia Clish
cphaprob state              # Expert mode

예시 출력입니다.

Member1> show cluster state
Cluster Mode: High Availability (Active Up) with IGMP Membership
ID            Unique Address   Assigned Load   State     Name
1 (local)     11.22.33.245     100%            ACTIVE    Member1
2             11.22.33.246     0%              STANDBY   Member2

인터페이스도 확인합니다.

show cluster members interfaces all     # Gaia Clish
cphaprob -a if                           # Expert mode

5. 두 Member에서 Active/Standby Bridge Mode 활성화 — 각 Member 명령줄에서 cpconfig 를 실행하고 Enable Check Point ClusterXL for Bridge Active/Standby 를 선택해 y 로 확인한 뒤 각 Member를 재부팅 합니다. 그다음 관리 서버에 접속해 이 클러스터 오브젝트에 Access Control Policy를 설치합니다.

cpconfig

6. 클러스터 구성 다시 점검 — 4단계와 같은 명령으로 확인합니다. 이번에는 Bridge Mode가 표시됩니다.

Member1> show cluster state
Cluster Mode: High Availability (Active Up, Bridge Mode) with IGMP Membership
ID            Unique Address   Assigned Load   State     Name
1 (local)     11.22.33.245     100%            ACTIVE    Member1
2             11.22.33.246     0%              STANDBY   Member2

Active/Active — 스위치 두 대 또는 네 대

Cluster Member에 Bridge 인터페이스를 정의하면 Active/Active Bridge Mode가 기본으로 켜집니다.

토폴로지 예시(스위치 두 대) — Active/Standby와 같되 두 Member 모두 Active 상태입니다.

토폴로지 예시(스위치 네 대)

1. 두 Cluster Member 설치 — Active/Standby와 동일합니다(Clustering 섹션에서 Unit is a part of a cluster + ClusterXL 선택).

2. 두 Member에 Bridge 인터페이스 구성 — Gaia Portal·Gaia Clish 절차는 단일 게이트웨이의 Bridge 인터페이스 구성과 동일 합니다. 단, Clish에서는 bridging group에 IP 주소를 할당하지 않 습니다(클러스터에서는 Bridge에 IP를 줄 수 없음). 이름 규칙(br<ID>), MTU 규칙, subordinate 두 개 제한, 관리 인터페이스 제외 규칙도 같습니다.

show interface <인터페이스 이름> ipv4-address
show interface <인터페이스 이름> ipv6-address
add bridging group <Bridge Group ID 0 - 1024>
add bridging group <Bridge Group ID> interface <첫 번째 subordinate 인터페이스 이름>
add bridging group <Bridge Group ID> interface <두 번째 subordinate 인터페이스 이름>
save config

3. SmartConsole에서 ClusterXL 오브젝트 구성 — Wizard 또는 Classic Mode. Active/Standby와 거의 같으나, Choose the Cluster's Solution 에서 Check Point ClusterXL 을 고른 뒤 High Availability 또는 Load Sharing 모드를 선택할 수 있고, ClusterXL and VRRP 페이지에서 High Availability and ClusterXL / Load Sharing and Multicast or Unicast / Active-Active 중에서 고릅니다.

선택한 모드별 Advanced Settings 옵션입니다.

Cluster Member recovery method(failover 후 정상 복귀 시 누구를 Active로 둘지)입니다.

연결 공유 방식(connection sharing method) — Load Sharing에서 각 Member가 어떤 연결을 검사할지 정합니다.

Network Management(Network Type/Sync 규칙/Member IPs/Topology)와 Bridge 인터페이스를 Topology에 넣지 않는다 는 중요 규칙은 Active/Standby와 동일합니다.

4. 보안 정책 구성 — Active/Standby의 3단계와 동일합니다(Access Control·Threat Prevention 작성·설치).

5. 클러스터 구성 점검 — 각 Member에서 상태·인터페이스를 확인합니다. Active/Active이므로 두 Member 모두 ACTIVE, Assigned Load 100%로 보입니다.

show cluster state          # Gaia Clish
cphaprob state              # Expert mode

Member1> show cluster state
Cluster Mode: High Availability (Active Up, Bridge Mode) with IGMP Membership
ID            Unique Address   Assigned Load   State     Name
1 (local)     11.22.33.245     100%            ACTIVE    Member1
2             11.22.33.246     100%            ACTIVE    Member2

추가로, MILS(Monitoring of the Interface Link State) 기능을 켜는 커널 파라미터 fwha_monitor_if_link_state 값이 1(기본)인지 확인합니다.

fw ctl get int fwha_monitor_if_link_state

1이 아니면 즉시 1로 설정하고 값을 다시 확인합니다.

fw ctl set int fwha_monitor_if_link_state 1

또한 이 파라미터가 영구 설정 파일에 잘못 들어가 있지 않은지 확인하고, 있으면 해당 줄 전체를 삭제합니다.

grep fwha_monitor_if_link_state $FWDIR/boot/modules/fwkern.conf
vi $FWDIR/boot/modules/fwkern.conf

특정 프로토콜의 Ethernet 프레임 허용·차단

Bridge Mode의 게이트웨이·클러스터·Scalable Platform Security Group은 기본적으로 IPv4(0x0800)·IPv6(0x86DD)·ARP(0x0806) 이외의 프로토콜을 실은 Ethernet 프레임도 허용합니다. 관리자는 이를 특정 프로토콜에 대해 허용·차단하도록 바꿀 수 있습니다.

Access Mode VLAN(VLAN translation) 이 구성되면, BPDU 프레임이 Bridge 인터페이스를 통해 잘못된 VLAN 번호로 스위치 포트에 도착할 수 있고, 이 불일치로 스위치 포트가 blocking 모드에 빠질 수 있습니다. Active/Standby Bridge Mode에서만 BPDU forwarding을 꺼서 이를 피할 수 있습니다.

게이트웨이·각 Cluster Member·Security Group의 Expert 모드에서 /etc/rc.d/init.d/network 파일을 백업합니다.

cp -v /etc/rc.d/init.d/network{,_BKP}        # 게이트웨이/각 Cluster Member
g_cp -v /etc/rc.d/init.d/network{,_BKP}      # Scalable Platform Security Group

파일을 편집해, ./etc/init.d/functions 줄 다음에 한 줄을 추가합니다.

vi /etc/rc.d/init.d/network

/sbin/sysctl -w net.bridge.bpdu_forwarding=0

저장 후, Scalable Platform이라면 수정 파일을 다른 Member에 복사합니다.

asg_cp2blades -b all /etc/rc.d/init.d/network

재부팅합니다.

reboot          # 게이트웨이/각 Cluster Member
g_reboot -a     # Scalable Platform Security Group

새 구성이 적재됐는지 확인합니다.

sysctl net.bridge.bpdu_forwarding                 # 게이트웨이/각 Cluster Member
g_all sysctl net.bridge.bpdu_forwarding           # Scalable Platform Security Group

다음이 나와야 합니다.

net.bridge.bpdu_forwarding = 0

라우팅과 Bridge 인터페이스

Bridge 인터페이스를 가진 Security Gateway는 bridge가 아닌 인터페이스에서 Layer 3 라우팅을 지원 할 수 있습니다. 게이트웨이(클러스터 아님) 의 Bridge 인터페이스에 IP 주소를 주면, 그 Bridge 인터페이스는 일반 Layer 3 인터페이스처럼 동작하며 게이트웨이의 IP 라우팅 결정에 참여합니다.

규칙은 다음과 같습니다.

Bridge 인터페이스를 통한 게이트웨이 관리

토폴로지 예시

패킷 흐름 — 이대로 두면 마지막에 재전송으로 오인되어 드롭 되는 문제가 있습니다.

해결 절차 — Bridge 인터페이스에서 패킷을 재라우팅하도록, 커널 파라미터 fwx_bridge_reroute_enabled 값을 1로 설정합니다. 그러면 게이트웨이는 관리 인터페이스를 떠나 Bridge 인터페이스로 들어오는 패킷의 MD5 해시가 같은지 확인하고, 그 연결의 나머지 패킷은 라우터를 거치지 않고 Bridge 인터페이스가 직접 처리합니다.

게이트웨이 Expert 모드에서 $FWDIR/boot/modules/fwkern.conf 를 백업(없으면 생성)·편집하고 한 줄을 추가합니다.

cp -v $FWDIR/boot/modules/fwkern.conf{,_BKP}
touch $FWDIR/boot/modules/fwkern.conf
vi $FWDIR/boot/modules/fwkern.conf

fwx_bridge_reroute_enabled=1

즉시 적용하고 값을 확인합니다.

fw ctl set int fwx_bridge_reroute_enabled 1
fw ctl get int fwx_bridge_reroute_enabled

fwx_bridge_reroute_enabled = 1 이 나와야 합니다. 가능할 때 게이트웨이를 재부팅하고, 재부팅 후 같은 명령으로 다시 값을 확인합니다.

IPv6 Neighbor Discovery

Neighbor discovery는 IPv4의 ARP에 해당 하는 ICMPv6 Neighbor Discovery 프로토콜로 동작합니다. 그런데 ARP 트래픽은 Layer 2 전용이라 Rule Base와 무관하게 허용되는 반면, ICMPv6 Neighbor Discovery는 모든 bridged 네트워크에 대해 Access Control Rule Base에서 명시적으로 허용 해야 합니다.

ICMPv6 Neighbor Discovery를 허용하는 명시적 규칙 예시입니다.

Ethernet 프로토콜 관리

Bridge 인터페이스를 가진 게이트웨이에서, IP 기반이 아닌 프로토콜(IPv4·IPv6·ARP가 아닌 것)이 bridge 인터페이스를 지날 때 허용·드롭할지 구성할 수 있습니다. 기본적으로 이런 프로토콜은 허용 됩니다.

비-IP 프레임이 허용되는 조건입니다.

IPv4·IPv6·ARP가 아닌 특정 프로토콜만 허용 하도록 구성하려면 다음을 따릅니다.

1단계 — 게이트웨이에서 fwaccept_unknown_protocol 을 0으로 설정합니다.

게이트웨이 Expert 모드에서 $FWDIR/boot/modules/fwkern.conf 를 백업·편집하고 한 줄을 추가(공백·주석 불가)한 뒤 게이트웨이를 재부팅합니다.

cp -v $FWDIR/boot/modules/fwkern.conf{,_BKP}
vi $FWDIR/boot/modules/fwkern.conf

fwaccept_unknown_protocol=0

지금 재부팅할 수 없다면 즉시 적용하고 확인합니다.

fw ctl set int fwaccept_unknown_protocol 0
fw ctl get int fwaccept_unknown_protocol

2단계 — 관리 서버에서 해당 user.def 파일을 편집 합니다.

파일을 백업·편집해 다음 directive를 추가합니다.

예시입니다.

$ifndef __user_def__
$define __user_def__
\\
\\ User defined INSPECT code
\\
allowed_ethernet_protocols={ <0x0800,0x86DD,0x0806>);
dropped_ethernet_protocols={ <0x8137,0x8847,0x9100>);
endif /*__user_def__*/

EtherType 번호 목록은 http://standards-oui.ieee.org/ethertype/eth.csv 를 참고합니다. 파일을 저장한 뒤,

3단계 — SmartConsole에서 이 게이트웨이 오브젝트에 Access Control Policy를 설치합니다.

Link State Propagation(LSP) 구성

Security Gateway 또는 ClusterXL Member로 동작하는 Check Point Appliance에서, Expansion Line Card 의 물리 포트 두 개를 Bridge Mode로 묶을 수 있습니다. 한쪽 bridged subordinate 포트의 링크가 내려가면 반대쪽 포트도 함께 내려가 므로, 스위치가 bridge 반대편(또는 네트워크 다른 부분)의 링크 장애를 더 빨리 감지·대응합니다. 이것이 LSP의 핵심입니다.

LSP를 지원하는 Expansion Line Card입니다.

LSP는 두 모드로 구성합니다.

자동 포트 감지로 LSP 구성 — 게이트웨이(또는 각 Member) Expert 모드에서 $FWDIR/boot/modules/fwkern.conf 를 백업(없으면 생성)·편집해 한 줄을 추가하고 재부팅합니다.

cp -v $FWDIR/boot/modules/fwkern.conf{,_BKP}
touch $FWDIR/boot/modules/fwkern.conf
vi $FWDIR/boot/modules/fwkern.conf

fw_link_state_propagation_enabled=1

재부팅 후 값을 확인합니다.

fw ctl get int fw_link_state_propagation_enabled

fw_link_state_propagation_enabled = 1 이 나와야 합니다.

수동 포트 감지로 LSP 구성 — 같은 파일에 다음 줄들을 추가합니다(포트 쌍 최대 4개).

fw_manual_link_state_propagation_enabled=1
fw_lsp_pair1="<interface_name_1,interface_name_2>"
fw_lsp_pair2="<interface_name_3,interface_name_4>"
fw_lsp_pair3="<interface_name_5,interface_name_6>"
fw_lsp_pair4="<interface_name_7,interface_name_8>"

예시입니다.

fw_lsp_pair2="eth3,eth4"

저장·재부팅 후 다음 명령들로 값을 확인합니다.

fw ctl get int fw_link_state_propagation_enabled              # = 1
fw ctl get int fw_manual_link_state_propagation_enabled       # = 1
fw ctl get str fw_lsp_pair1     # <interface_name_1,interface_name_2>
fw ctl get str fw_lsp_pair2     # <interface_name_3,interface_name_4>
fw ctl get str fw_lsp_pair3     # <interface_name_5,interface_name_6>
fw ctl get str fw_lsp_pair4     # <interface_name_7,interface_name_8>

게이트웨이가 정책을 아직 못 받은 순간에도 무방비여선 안 됩니다. Check Point Security Gateway는 그래서 기본(baseline) 보안 두 가지를 갖춥니다.

관련 명령들입니다(자세한 내용 R82 CLI Reference Guide).

Boot Security

Boot Security 는 부팅 동안 게이트웨이와 네트워크를 보호합니다 — Linux OS 커널의 IP Forwarding을 끄고, Default Filter Policy를 적재 합니다.

Default Filter Policy

Default Filter Policy(defaultfilter) 는 게이트웨이가 부팅한 순간부터 사용자 정의 보안 정책이 설치될 때까지 게이트웨이를 보호합니다. Boot Security는 IP Forwarding을 끄고 이 Default Filter Policy를 적재합니다. 게이트웨이에는 세 가지 Default Filter 템플릿이 있습니다.

Default Filter Policy 선택 — 먼저 게이트웨이에 보안 정책을 구성·설치해 두고, 명령줄 Expert 모드에서 현재 Default Filter Policy 파일을 백업합니다.

cp -v $FWDIR/conf/defaultfilter.pf{,_BKP}

원하는 템플릿으로 새 Default Filter Policy 파일을 만듭니다.

cp -v $FWDIR/lib/defaultfilter.boot $FWDIR/conf/defaultfilter.pf     # Boot Filter
cp -v $FWDIR/lib/defaultfilter.drop $FWDIR/conf/defaultfilter.pf     # Drop Filter
cp -v $FWDIR/lib/defaultfilter.dag  $FWDIR/conf/defaultfilter.pf     # DAG Filter

새 Default Filter를 컴파일합니다.

fw defaultgen

컴파일 결과는 IPv4용 $FWDIR/state/default.bin, IPv6용 $FWDIR/state/default.bin6 입니다. Default Filter Policy 파일의 경로를 확인합니다.

$FWDIR/boot/fwboot bootconf get_def

예시입니다.

[Expert@MyGW:0]# $FWDIR/boot/fwboot bootconf get_def
/etc/fw.boot/default.bin
[Expert@MyGW:0]#

컴파일된 파일을 그 경로로 복사합니다.

cp -v $FWDIR/state/default.bin  /etc/fw.boot/default.bin       # IPv4
cp -v $FWDIR/state/default.bin6 /etc/fw.boot/default.bin6      # IPv6

마지막으로 반드시 serial console로 접속 한 상태에서 게이트웨이를 재부팅합니다.

사용자 정의 Default Filter 만들기

Check Point INSPECT 언어를 아는 관리자는 Default Filter를 직접 정의할 수 있습니다.

절차는 위의 "Default Filter Policy 선택"과 거의 같습니다 — 보안 정책을 미리 설치하고, $FWDIR/conf/defaultfilter.pf 를 백업한 뒤, Boot/Drop/DAG 중 하나를 템플릿으로 복사합니다.

cp -v $FWDIR/conf/defaultfilter.pf{,_BKP}
cp -v $FWDIR/lib/defaultfilter.boot $FWDIR/conf/defaultfilter.pf     # Boot Filter 템플릿
cp -v $FWDIR/lib/defaultfilter.drop $FWDIR/conf/defaultfilter.pf     # Drop Filter 템플릿
cp -v $FWDIR/lib/defaultfilter.dag  $FWDIR/conf/defaultfilter.pf     # DAG Filter 템플릿

그다음 새 파일을 편집해 원하는 INSPECT 코드를 넣습니다.

컴파일·경로 확인·복사·재부팅은 위와 동일합니다.

fw defaultgen
$FWDIR/boot/fwboot bootconf get_def
cp -v $FWDIR/state/default.bin  /etc/fw.boot/default.bin       # IPv4
cp -v $FWDIR/state/default.bin6 /etc/fw.boot/default.bin6      # IPv6

마찬가지로 serial console로 접속한 상태에서 재부팅하며, 새 필터가 모든 접근을 막으면 unload 후 정상 정책을 설치할 수 있습니다.

유지 보수에 Default Filter Policy 활용

가끔은 유지 보수를 위해 게이트웨이를 멈춰야 하는데, 원격지 게이트웨이처럼 물리적으로 분리하기 어려울 때 가 있습니다. 보안을 유지하면서 멈추려면 다음 명령을 씁니다.

Initial Policy

게이트웨이 관리자가 처음으로 보안 정책을 설치하기 전까지 는 Initial Policy 가 보안을 집행합니다. Initial Policy는 Default Filter 정책에 사전 정의된 implied rule을 더해 동작합니다 — 이 implied rule들은 대부분의 통신을 막되, 보안 정책 설치에 필요한 통신만 허용 합니다.

Initial Policy는 또한 Check Point 제품 업그레이드, 게이트웨이의 SIC 인증서 리셋, 라이선스 만료 시에도 게이트웨이를 보호합니다.

게이트웨이가 부팅해 처음으로 보안 정책이 적재될 때까지 의 동작 순서입니다.

게이트웨이는 관리자가 사용자 정의 정책을 설치할 때까지 Initial Policy를 집행하며, 이후의 부팅에서는 Default Filter 정책 직후에 사용자 정의 정책을 바로 적재 합니다.

Standalone 구성과 분산(distributed) 구성의 Initial Policy는 다릅니다.

문제 해결 — 재부팅을 끝내지 못할 때

일부 구성에서는 Default Filter 정책 때문에 설치 후 재부팅을 끝내지 못 할 수 있습니다. 먼저 Default Filter가 부팅 절차에 필요한 트래픽을 허용하는지 살펴보세요. 그래도 부팅이 끝나지 않으면 Default Filter를 제거합니다.

cd /opt/CPsuite-<VERSION>/fw1/
./fwboot bootconf set_def

cd /opt/CPsuite-<VERSION>/fw1/
grep DEFAULT_FILTER_PATH boot/boot.conf

이로써 게이트웨이가 운영 길목, 관찰 전용, IP 무변경 끼워넣기, 그리고 정책이 없는 순간까지 어떤 배포·상태에서도 자신과 네트워크를 지키는 방법을 모두 다뤘습니다. 다음은 환경 전반을 떠받치는 라이선스 관리와 클라우드 서비스입니다.