Checkpoint - Advanced Firewall-1 Management CCSE Student User Guide

Advanced FireWall-1
Management (CCSE)
Student User Guide
Ve r s i o n 4 . 0 R e v i s i o n B
Document # CPTS-DOC-C1012 Rev. B
© Copyright 1999 Check Point Software Technologies Ltd.
All rights reserved. This product and related documentation are protected by copyright
and distribution under licensing restricting their use, copy, and distribution. No part of
this documentation may be reproduced in any form or by any means without prior
written authorization of Check Point Software Inc. While every precaution has been
taken in the preparation of this document, Check Point assumes no responsibility for
errors or omissions. This document and features described herein are subject to
change without notice.
Trademarks:
FireWall-1, SecuRemote, Stateful Inspection, INSPECT, Check Point and the Check
Point logo are trademarks or registered trademarks of Check Point Software
Technologies Ltd. Sun, SPARC, Solaris, and SunOS are trademarks of Sun
Microsystems, Inc. UNIX and OPEN LOOK are registered trademarks of UNIX
System Laboratories.
All other products or services mentioned herein are trademarks or registered

trademarks of their respective owners.
Check Point Software Technology Ltd.
International Headquarters: U.S. Headquarters: Dallas Courseware Development:

3A Jabotinsky Street Three Lagoon Drive, Suite 400 2505 N. Highway 360, Suite 700
Ramat Gan 52520 Israel Redwood City, CA 94065 Grand Prairie, TX. 75050
Tel: 972-3-613 1833 Tel: 650-628-2000 Tel: 817-606-6600
Fax: 972-3-575 9256 Fax: 650-654-4233 Fax: 817-652-4757
E-mail: info@checkpoint.com HTTP://www.checkpoint.com
Please direct any comments concerning Check Point courseware to

courseware@us.checkpoint.com.
Rev. B Document # CPTS-DOC-C1012

Document CPTS-DOC-C1012 Rev. B
v
Introduction to Advanced FireWall-1 Management (CCSE) 1
CCSE Course Description .................................................................................... 1

Course Objectives ........................................................................................................................ 1
CCSE Course Layout ........................................................................................... 2
Course Requirements .................................................................................................................. 2
Prerequisites ................................................................................................................................ 2
CCSI Course ................................................................................................................................ 2
Course Map .......................................................................................................... 3
Day 1 ............................................................................................................................................ 3
Day 2 ............................................................................................................................................ 3
FireWall-1 Lab Setup (Windows NT Server and Solaris) ..................................... 4
Lab Setup ..................................................................................................................................... 4
Lab Topology ............................................................................................................................... 4
IP Addresses ................................................................................................................................ 5
Lab Terms .................................................................................................................................... 5
Site-Number Table ....................................................................................................................... 5
What’s New in FireWall-1 Version 4.0 .................................................................. 6
New Platforms .............................................................................................................................. 6
Encryption .................................................................................................................................... 6
Enterprise Management ............................................................................................................... 6
Authentication .............................................................................................................................. 6
Client Authentication .................................................................................................................... 6
Security Servers ........................................................................................................................... 6
Support for New Services ............................................................................................................ 6
Unit I — Chapter 1:
The Firewall Challenge 7
Introduction ........................................................................................................... 7
The Firewall Challenge ......................................................................................... 8
The Enterprise Security Challenge .............................................................................................. 9
Evolution of Security Management .............................................................................................. 9
Building Enterprise Security ....................................................................................................... 10
OPSEC ...................................................................................................................................... 11
FireWall-1 Year 2000 Compliance ............................................................................................. 13
Backup ....................................................................................................................................... 13

vi
Unit I - Chapter 2:
FireWall-1 Architecture Overview 15
FireWall-1 Architecture ....................................................................................... 15

FireWall-1 Advantages ............................................................................................................... 15
How FireWall-1 Works ........................................................................................ 16
Inspect Engine in the Kernel Module ......................................................................................... 16
Packet Inspected in Kernel Module ........................................................................................... 17
Inspect Allowing Packets ........................................................................................................... 17
The Kernel Component ...................................................................................... 19
Kernel Attachment ..................................................................................................................... 19
Kernel Virtual Machine ............................................................................................................... 19
Kernel Address Translation ........................................................................................................ 19
Kernel Encryption ....................................................................................................................... 20
Kernel Logging ........................................................................................................................... 20
Kernel loctl Handler .................................................................................................................... 20
The Daemon Component ................................................................................... 21
Daemon Command Handler ...................................................................................................... 21
Daemon Logging ........................................................................................................................ 21
Daemon Kernel Trap Handler .................................................................................................... 21
Daemon IOCTL .......................................................................................................................... 21
Daemon Inet .............................................................................................................................. 21
Daemon Communicator ............................................................................................................. 22
Unit I — Chapter 3
Product Overview 23
Introduction ........................................................................................................ 23
Objectives .................................................................................................................................. 23
Key Terms .................................................................................................................................. 23
FireWall-1 Product Type ..................................................................................... 24
FireWall-1 Products ................................................................................................................... 24
Product Types ............................................................................................................................ 24
Modules ..................................................................................................................................... 24
Single Products .......................................................................................................................... 25
Enterprise Products ................................................................................................................... 25
Add-On Modules ........................................................................................................................ 26
Installation Considerations ......................................................................................................... 26
Segmented Networks ................................................................................................................. 27

vii
Review ................................................................................................................ 29
Summary .................................................................................................................................... 29
Review Questions ...................................................................................................................... 29
Unit II — Chapter 1:
Advanced Security Policy 33
Introduction ......................................................................................................... 33
Objectives .................................................................................................................................. 33
Key Terms .................................................................................................................................. 34
Security Policy Overview ........................................................................................................... 34
Masking Rules .................................................................................................... 35
Overview .................................................................................................................................... 35
Hiding Rules ............................................................................................................................... 35
Viewing Hidden Rules ................................................................................................................ 37
Unhiding Hidden Rules .............................................................................................................. 38
Querying the Rule Base ..................................................................................... 39
Query Screens ........................................................................................................................... 39
Adding Query to a Rule Base .................................................................................................... 42
Disabling Rules ................................................................................................... 44
Overview .................................................................................................................................... 44
Disabling Rules .......................................................................................................................... 44
Enabling a Disabled Rule ........................................................................................................... 45
Lab 1: Policy Editor ............................................................................................. 46
Blocking Connections ......................................................................................... 54
Starting the Log Viewer .............................................................................................................. 54
Block Intruder ............................................................................................................................. 54
The Block Intruder Screen ......................................................................................................... 55
Block Request ............................................................................................................................ 56
Using Block Request .................................................................................................................. 56
Lab 2: Block Intruder ......................................................................................... 58
Uninstalling a Security Policy ............................................................................. 60
The Uninstall Security Policy Screen ......................................................................................... 60
Steps for Uninstalling a Security Policy ..................................................................................... 60
Security Policy File ............................................................................................. 62
Guidelines for Improving FireWall-1 Performance via a Security Policy ............ 65
Management Module ................................................................................................................. 65
Firewall Module .......................................................................................................................... 65
Unnecessary Services ............................................................................................................... 66

viii
Review ................................................................................................................ 67
Summary .................................................................................................................................... 67
User Defined Tracking 69
Introduction ......................................................................................................... 69
Objectives .................................................................................................................................. 69
Key Terms .................................................................................................................................. 69
User Defined Tracking ........................................................................................ 70
Configuring a Rule ..................................................................................................................... 71
The Log and Alert Tab ............................................................................................................... 72
Setting up User Defined Tracking .............................................................................................. 73
Adding User Defined Tracking to the Security Policy ................................................................ 74
alertf ........................................................................................................................................... 74
Lab 3: User Defined Tracking with alertf ............................................................ 76
Review ................................................................................................................ 77
Summary .................................................................................................................................... 77
SYNDefender 79
Overview ............................................................................................................. 79
Objectives .................................................................................................................................. 79
Keywords ................................................................................................................................... 79
TCP/IP Three-Step Handshake .......................................................................... 80
Normal Handshake .................................................................................................................... 80
The SYN Flooding Attack ................................................................................... 81
Network Attack ........................................................................................................................... 81
The Backlog Queue ................................................................................................................... 81
Guidelines for Deploying SYNDefender with FireWall-1 .................................... 83
Deploying SYNDefender Gateway ............................................................................................. 83
Defending Against SYN Flooding Attacks .......................................................... 84
The SYNDefender Properties Screen ........................................................................................ 84

ix
Configuring SYNDefender ......................................................................................................... 85

SYNDefender Gateway ...................................................................................... 86
SYN Gateway Handshake ......................................................................................................... 86
Passive SYNDefender Gateway ................................................................................................ 87
Passive SYN Gateway Handshake .......................................................................................................87
Review ................................................................................................................ 89
Summary .................................................................................................................................... 89
Content Security 91
Introduction ......................................................................................................... 91
Objectives .................................................................................................................................. 91
Key Terms .................................................................................................................................. 91
Understanding Content Security ......................................................................... 92
Content Security ........................................................................................................................ 92
Content Vectoring Protocol (CVP) ...................................................................... 94
Anti-Virus Inspection .................................................................................................................. 94
Implementing Anti-Virus Inspection ....................................................................................................95
URL Filtering Protocol (UFP) .............................................................................. 96
How UFP Works ........................................................................................................................ 96
Implementing Content Security .......................................................................... 97
HTTP Security Server ................................................................................................................ 97
SMTP Security Server ............................................................................................................... 97
FTP Security Server ................................................................................................................... 97
Java and ActiveX Stripping ........................................................................................................ 97
CVP and UFP Servers ........................................................................................ 98
Creating a New Resource ................................................................................ 100
Add a Resource to a Rule ................................................................................ 102
SMTP, HTTP, FTP Content Security ................................................................ 104
URI Resource .......................................................................................................................... 104
Wild Card Specification Type ................................................................................................... 104
File Specification Type ............................................................................................................. 107
UFP Specification Type ........................................................................................................... 110
SMTP Security Server ............................................................................................................. 112
FTP Security Server ................................................................................................................. 117
RADIUS Server ................................................................................................ 120

x
Lab 4: Anti-Virus Checking for Incoming E-Mail ............................................... 122

Lab 5: URL Blocking for HTTP ......................................................................... 126
Lab 6: URL Screening by Wildcard .................................................................. 128
Lab 7: FTP Content Security ............................................................................ 130
Lab 8: Java Blocking ........................................................................................ 132
Lab 9: URL Screening by File ........................................................................... 134
Review .............................................................................................................. 136
Summary .................................................................................................................................. 136
Review Questions .................................................................................................................... 136
Unit III — Chapter 1:

Encryption and Virtual Private Networks 141
Introduction ....................................................................................................... 141

Overview .................................................................................................................................. 141
Objectives ................................................................................................................................ 141
Key Terms ................................................................................................................................ 142
How Encryption Works ..................................................................................... 143
Overview .................................................................................................................................. 143
Virtual Private Networks (VPNs) .............................................................................................. 143
Firewall-to-Firewall VPN .......................................................................................................... 144
Client-to-Firewall VPN (SecuRemote) ..................................................................................... 144
FireWall-1 Encryption Schemes ............................................................................................... 146
FireWall-1 Encryption Algorithms ..................................................................... 147
Overview .................................................................................................................................. 147
FWZ-1 ...................................................................................................................................... 147
DES (International Customers) ................................................................................................ 148
Four Encryption Levels ............................................................................................................ 148
Encryption Technologies .................................................................................. 149
Overview .................................................................................................................................. 149
Symmetric Encryption (Shared Key) ........................................................................................ 149
Asymmetric Encryption (Public Key) ........................................................................................ 150
What to Encrypt? .............................................................................................. 152
Packet Headers Versus Data ................................................................................................... 152
Tunneling-Mode Versus In-Place Encryption ........................................................................... 152
Digital Signatures ............................................................................................. 155
Definitions ................................................................................................................................ 155
Using Digital Signatures ........................................................................................................... 155

xi
Creating the Digital Signature .................................................................................................. 156

Applying Digital Signatures/Certificates ................................................................................... 156
Certificate Authority .......................................................................................... 158
The CA and DH Keys ............................................................................................................... 158
Creating the CA Key ................................................................................................................ 158
Creating the DH Key ................................................................................................................ 162
Review .............................................................................................................. 165
Summary .................................................................................................................................. 165

Encryption Schemes 167
Introduction ....................................................................................................... 167

Overview .................................................................................................................................. 167
Objectives ................................................................................................................................ 167
Key Terms ................................................................................................................................ 167
FireWall-1 Encryption Schemes ....................................................................... 168
Overview .................................................................................................................................. 168
FWZ .................................................................................................................. 169
Reliable Datagram Protocol ..................................................................................................... 169
FWZ Encryption Screens ......................................................................................................... 169
Configuring FWZ Encryption .................................................................................................... 173
Lab 10: Configuring an FWZ VPN ................................................................... 184
IPSec (Manual IPSec) ...................................................................................... 187
Manual IPSec Encryption Screens .......................................................................................... 188
Configuring IPSec Encryption .................................................................................................. 192
Lab 11: Setting up an IPSec VPN ................................................................... 199
ISAKMP/Oakley (Internet Key Exchange) ........................................................ 201
ISAKMP/Oakley (IKE) Encryption ............................................................................................ 201
Oakley (IKE) Encryption ........................................................................................................... 201
ISAKMP/Oakley Encryption Screens ....................................................................................... 201
Configuring ISAKMP/Oakley Encryption .................................................................................. 205
Lab 12: Adding ISAKMP/Oakley (IKE) Encryption .......................................... 212
SKIP (Simple Key Management for Internet Protocols) ................................... 216
SKIP Encryption Screens ......................................................................................................... 216
Configuring SKIP Encryption ................................................................................................... 220
Lab 13: Configuring a SKIP VPN ..................................................................... 230

xii
Review .............................................................................................................. 233

Summary .................................................................................................................................. 233

SecuRemote 235
Introduction ....................................................................................................... 235

Overview .................................................................................................................................. 235
Objectives ................................................................................................................................ 235
Key Terms ................................................................................................................................ 235
SecuRemote ..................................................................................................... 236
SecuRemote and VPNs ........................................................................................................... 236
SecuRemote User .................................................................................................................... 237
Client-to-Firewall VPN (How SecuRemote Works) .................................................................. 237
SecuRemote Service ............................................................................................................... 238
Configuring the Firewall for SecuRemote ......................................................... 239
The FireWall-1 GUI Screens .................................................................................................... 239
Configuring SecuRemote ......................................................................................................... 242
A Note about Routing ............................................................................................................... 244
FWZ Encapsulation .................................................................................................................. 244
Before Installing SecuRemote ......................................................................... 246
Software and Hardware Requirements .................................................................................... 246
SecuRemote Topology Requirements ..................................................................................... 246
Installing SecuRemote Client ........................................................................... 247
Configuring SecuRemote Client ....................................................................... 250
The SecuRemote Client GUI and Screens .............................................................................. 250
Pull Down Menus ..................................................................................................................... 250
Icons ........................................................................................................................................ 251
The Sites Screen ..................................................................................................................... 253
Configuring SecuRemote Client ............................................................................................... 254
Authenticating with SecuRemote ............................................................................................. 254
Other Considerations for SecuRemote ............................................................. 255
Support for Public Key Infrastructures ..................................................................................... 255
Other Firewalls ......................................................................................................................... 255
Control Properties .................................................................................................................... 255
Lab 14: SecuRemote in a VPN (using FWZ Encryption) ................................. 256
Configuring a Network with SecuRemote ................................................................................ 256
Review .............................................................................................................. 260

xiii
Summary .................................................................................................................................. 260

Unit IV — Chapter 1:
Router Management 263
Introduction ....................................................................................................... 263

Objectives ................................................................................................................................ 263
Key Terms ................................................................................................................................ 264
The FireWall-1 Solution to Router Management Problems .............................. 265
Setting up Router Management ........................................................................ 266
Router Interfaces Screens ....................................................................................................... 266
Steps for Creating Router Interfaces ....................................................................................... 269
Configuring SNMP ................................................................................................................... 269
Defining the Enable Password (Cisco) .................................................................................... 270
Defining Access Control List Properties ................................................................................... 271
Adding Router-Enforced Rules to a Security Policy ................................................................. 273
Installing a Security Policy on a Router ................................................................................... 273
Lab 15: Router Security Management ............................................................. 275
Router Logging Support ................................................................................... 276
Overview .................................................................................................................................. 276
Router-Logging Screens .......................................................................................................... 276
Enabling Router Logging ......................................................................................................... 278
Lab 16: Importing Router Access Lists into the Rule Base (Solaris Only) ....... 281
Review .............................................................................................................. 283
Summary .................................................................................................................................. 283
Account Management Client 285
Introduction ....................................................................................................... 285

Objectives ................................................................................................................................ 285
Key Terms ................................................................................................................................ 285
Lightweight Directory Access Protocol ............................................................. 287
X.500 History ........................................................................................................................... 287

xiv
Multiple LDAP Servers ............................................................................................................. 288

Distinguished Name ................................................................................................................. 288
Account Management Client Installation .......................................................... 290
Windows Installation Screens .................................................................................................. 290
Installing the AMC .................................................................................................................... 291
A Note About Starting the Account Management Client ................................... 293
Adding LDAP Authentication Properties to a Security Policy ........................... 295
The Security Policy Properties Setup screen ........................................................................... 295
LDAP Account Unit Properties ................................................................................................. 296
Adding LDAP Authentication .................................................................................................... 297
Starting Account Management Client ............................................................... 298
Windows .................................................................................................................................. 298
Solaris ...................................................................................................................................... 298
Account Management Configuration ................................................................ 299
The Account Unit Properties Screen ........................................................................................ 299
The General Tab ...................................................................................................................... 300
The Authentication Tab ............................................................................................................ 301
The Encryption Tab .................................................................................................................. 302
External User Group Screen .................................................................................................... 303
Configuring Account Management ........................................................................................... 303
AMC Logon Screen .................................................................................................................. 304
Creating an Object ............................................................................................ 306
Navigating the Account Management Client .................................................... 307
The Organizational Unit .................................................................................... 308
Creating an Organizational Unit ............................................................................................... 308
Deleting an Organizational Unit ............................................................................................... 309
Defining Users .................................................................................................. 311
The New User Screen .............................................................................................................. 311
Adding Account Management to New Users ........................................................................... 317
Managing Templates ........................................................................................ 318
The New Template Screen ...................................................................................................... 318
Defining a New Template ......................................................................................................... 319
Managing Groups ............................................................................................. 320
Defining a New Group .............................................................................................................. 320
Lab 17: Using LDAP ......................................................................................... 321
Review .............................................................................................................. 323
Summary .................................................................................................................................. 323

xv
Load Balancing 325
Introduction ....................................................................................................... 325

Objectives ................................................................................................................................ 325
Key Terms ................................................................................................................................ 326
How Load Balancing Works ............................................................................. 327
Load Balancing Components ................................................................................................... 328
Logical Server Types ........................................................................................ 330
HTTP Redirect ......................................................................................................................... 330
Other Load Balancing .............................................................................................................. 331
Load Balancing Algorithms ............................................................................... 332
Load Measuring ....................................................................................................................... 336
Configuring Load Measuring .................................................................................................... 337
Setting up Load Balancing Algorithms .............................................................. 338
The Logical Server Properties Screen ..................................................................................... 338
Setting up Load-Balancing Algorithms ..................................................................................... 339
HTTP Logical Server ........................................................................................ 340
The Workstation Properties Screen ......................................................................................... 340
Creating a Server Object ......................................................................................................... 341
The Group Properties Screen .................................................................................................. 342
Creating a Server Group .......................................................................................................... 343
The Logical Server Properties Screen ..................................................................................... 345
Creating a Logical Server ........................................................................................................ 345
Lab 18: HTTP Logical Server ........................................................................... 348
Load Balancing on Other Logical Servers ........................................................ 350
Overview .................................................................................................................................. 350
Address Resolution Protocol (ARP) ......................................................................................... 351
Load Balancing for Other Services .......................................................................................... 352
Lab 19: FTP Logical Server ............................................................................. 354
Rule Base Order and Load Balancing .............................................................. 356
HTTP Logical Servers in a Rule Base ..................................................................................... 356
Other Logical Servers in a Rule ............................................................................................... 356
Troubleshooting Load Balancing — HTTP Logical Server ............................... 357
Problem .................................................................................................................................... 357
Solution .................................................................................................................................... 357
Review .............................................................................................................. 358
Summary .................................................................................................................................. 358

xvi
Remote Management 361
Introduction ....................................................................................................... 361

Objectives ................................................................................................................................ 361
Key Terms ................................................................................................................................ 361
Remote Management Architecture ................................................................... 362
Overview .................................................................................................................................. 362
Setup Considerations ............................................................................................................... 363
A Note about the User Database ............................................................................................. 366
Configuring the Remote GUI ............................................................................ 367
GUIs and Screens .................................................................................................................... 367
Remote GUI Configuration Steps ............................................................................................ 371
Lab 20: GUI Client Management ..................................................................... 374
Management Station and Firewall Configuration (Remote Management) ........ 375
Remote Management Limitations ............................................................................................ 375
Management Station and Firewall Configuration ..................................................................... 375
Configuration Screens ............................................................................................................. 376
Remote Management Configuration ........................................................................................ 378
Lab 21: Remote Management ......................................................................... 381
Running the System Status GUI ....................................................................... 384
A Note about Removing Remote Management ................................................ 385
Managing a Security Policy Remotely .............................................................. 386
Steps for Managing a Remote Security Policy ......................................................................... 386
Review .............................................................................................................. 388
Summary .................................................................................................................................. 388
Unit V — Chapter 1:
Troubleshooting 393
Introduction ....................................................................................................... 393

Objectives ................................................................................................................................ 393
Troubleshooting Error Messages ..................................................................... 394
SMTP Mail-Server Error ........................................................................................................... 394
FireWall-1 Cannot Resolve a Name and Address ................................................................... 394
Installing SecuRemote ............................................................................................................. 394

xvii
Troubleshooting Load Balancing and HTTP Logical Servers .................................................. 394

FireWall-1 Displays an Account Management Client Authentication Error .............................. 395
Deleting an Organizational Unit ............................................................................................... 395
Account Management .............................................................................................................. 396
User not Found ........................................................................................................................ 396
Changes Made in the Account Management Client Do not Affect FireWall-1 ......................... 396
User Authentication .................................................................................................................. 396
Authentication .......................................................................................................................... 396
Troubleshooting Resources .............................................................................. 399
Internet Resources ................................................................................................................... 399
Debugging Tools .............................................................................................. 401
Overview .................................................................................................................................. 401
The -d switch ............................................................................................................................ 401
Using fwinfo as a Debugging Tool ........................................................................................... 404
Appendix A:
Account Management Client Installation on HP UX and IBM AIX 409
HP-UX Installation .................................................................................................................... 409

IBM AIX Installation .................................................................................................................. 410
Appendix B:
Security Considerations 413
Solaris Notes ............................................................................................................................ 413

Additional Information .............................................................................................................. 413
Appendix C:
Solaris Command-Line Interface 415
Solaris/NT Syntax Differences ................................................................................................. 415

Setup ........................................................................................................................................ 415
fwinstall .................................................................................................................................... 417
fwuninstall ................................................................................................................................ 417
fwstart ...................................................................................................................................... 417

xviii
fwstop ....................................................................................................................................... 417

fw ............................................................................................................................................. 418
Control ..................................................................................................................................... 418
fw load ...................................................................................................................................... 418
fw unload .................................................................................................................................. 420
fw fetch ..................................................................................................................................... 420
fw logswitch .............................................................................................................................. 421
fw putkey .................................................................................................................................. 423
fw putlic .................................................................................................................................... 423
fw dbload .................................................................................................................................. 424
Monitor .............................................................................................................. 425
fw stat ....................................................................................................................................... 425
fw lichosts ................................................................................................................................ 425
fw logexport .............................................................................................................................. 427
fw ver ....................................................................................................................................... 427
fw printlic .................................................................................................................................. 427
fw sam ...................................................................................................................................... 428
Utilities .............................................................................................................. 430
fwciscoload .............................................................................................................................. 430
fw ctl ......................................................................................................................................... 431
fstat .......................................................................................................................................... 432
FP Forwarding ......................................................................................................................... 434
Enabling and Disabling IP Forwarding ..................................................................................... 434
fw gen ...................................................................................................................................... 436
fw kill ........................................................................................................................................ 436
fwc ............................................................................................................................................ 437
fwm .......................................................................................................................................... 437
fwell .......................................................................................................................................... 438
Individual Interface Loading for Bay Routers (Wellfleet) .......................................................... 439
fw tab ....................................................................................................................................... 440
fwxlconf .................................................................................................................................... 440
snmp_trap ................................................................................................................................ 440
status_alert .............................................................................................................................. 441
User Database: Importing and Exporting ............................................................................... 441

xix
Appendix D:
Check Point Product License Features for Version 4.0 447
Evaluation Products........................................................................................... 447

Single Gateway Products .................................................................................. 448
Enterprise Products ........................................................................................... 448
Inspection Module ............................................................................................. 448
FireWall Modules............................................................................................... 449
Add On Modules................................................................................................ 449
Management Consoles...................................................................................... 451
Open Security Extension/Open Security Manager ............................................ 451
FireWall-1 Basic Features ................................................................................. 452
FireWall-1 Combined Features.......................................................................... 452
Glossary 457

xx

Unit I — FireWall-1 Overview
Chapter 1: The Firewall Challenge
Chapter 2: FireWall-1 Architecture Overview
Chapter 3: Product Overview
Rev. B Document CPTS-DOC-C1012

Intro
Introduction to CCSE
Introduction to Advanced
FireWall-1 Management
(CCSE)
CCSE Course Description
Welcome to the Advanced FireWall-1 Management Check Point Certified Security

Engineer (CCSE) course. This class is intended to provide you with an understanding
of key concepts and skills necessary to manage your firewalled network — both on
local, internal networks and external networks — gain the maximum security out of
your firewall, and resolve firewall performance issues. You will also learn the new
features of FireWall-1 version 4.0. You are encouraged to follow along in the manual
as the class progresses and take notes for reference.
Course Objectives • Understand the FireWall-1 product as an enterprise-management solution

• Understand and address FireWall-1 security issues, including the following topics:
Advanced security policy setup
Using the log viewer and user defined tracking
Using SYNDefender
Understanding content security
Understanding encryption and VPNs
Using SecuRemote
• Understand advanced FireWall-1 management, including the following topics:
Setting up router management
Using the FireWall-1 Account Management Client
Setting up load balancing
Managing FireWall-1 and its security policies remotely
• Using FireWall-1 diagnostics tools:
Using the System Status GUI
Troubleshooting FireWall-1
1
2 CCSE Course Layout
CCSE Course Layout I-1
Introduction to CCSA
Course This course is designed for administrators and resellers who require in-depth
Requirements knowledge of FireWall-1 that goes beyond basic installation, setup and
methodologies.
Prerequisites Before taking this course, we suggest that you have the following knowledge base:
You must complete and pass Check Point’s FireWall-1 CCSA test before
taking the CCSE course.
• Working knowledge of firewall technologies

• Working knowledge of TCP/IP and internet communications
• Working knowledge of client/server configurations
• Working knowledge of network ideologies including routers, gateways and
servers
• Working knowledge of WindowsNT, Windows and/or Solaris and command-line
interface
CCSI Course The CCSI course is designed for security engineers and resellers who seek Check
Point Security Instructor certification.
CCSE and CCSI courses will no longer provide certification to students

who participate in these courses. The student will be required to take and
pass a certification exam to obtain certification.

Course Map Intro
Day 1 Unit I
Chapter 1: The Firewall Challenge
Chapter 2: FireWall-1 Architecture
Chapter 3: Product Overview
Unit II
Chapter 1: Advanced Security Policy
Chapter 2: User Defined Tracking
Chapter 3: SYNDefender
Chapter 4: Content Security
Day 2 Unit III

Chapter 1: Encryption and VPNs
Chapter 2: Encryption Schemes
Chapter 3: SecuRemote
Unit IV
Chapter 1: Router Management
Chapter 2: Account Management Client
Chapter 3: Load Balancing
Chapter 4: Remote Management
Unit V
Chapter 1: Troubleshooting FireWall-1

4 Course Map
FireWall-1 Lab Setup (Windows NT Server and Solaris) I-1
Lab Setup The following is the setup of your lab:
• Firewalled servers (www.yourcity.com) not connected to Internet
• Unique IP address for each firewalled server
• Root password to all systems: _______________________________________
(Your instructor will give you this password. Be careful with root access!)
• OpenWindows mouse-button controls (Solaris only):
Left - selects objects
Middle - selects additional objects or deselects objects
Right - displays menus
Lab Topology Figure 1 is a sample eight-station lab topology.
Detroit Firewall Server: Chicago Firewall Server:

fw.detroit.com fw.chicago.com
204.32.38.101 204.32.38.102
192.168.1.101 192.168.2.102
Internet Server: Internet Server:
www.detroit.com www.chicago.com
192.168.1.1 192.168.2.1
London Firewall Server: NewYork Firewall Server:

fw.london.com fw.newyork.com
204.32.38.103 204.32.38.104
192.168.3.103 192.168.4.104
www.london.com www.newyork.com
192.168.3.1 192.168.4.1
Hub:
Paris Firewall Server: Tokyo Firewall Server: 204.32.38.0
fw.paris.com fw.tokyo.com
204.32.38.105 204.32.38.106
192.168.5.105 192.168.6.106
www.paris.com www.tokyo.com
192.168.5.1 192.168.6.1
Moscow Firewall Server: Berlin Firewall Server:

fw.moscow.com fw.berlin.com
204.32.38.107 204.32.38.108
192.168.7.107 192.168.8.108
www.moscow.com www.berlin.com
192.168.7.1 192.168.8.1
Figure 1: Lab topology.

IP Addresses Table 1 lists the IP addresses for the FireWall-1 lab: Intro
Table 1: IP Addresses for FireWall-1 Lab
FireWall-1 Server IP Address Internet Server IP Address
fw.detroit.com 204.32.38.101 www.detroit.com 192.168.1.1
fw.chicago.com 204.32.38.102 www.chicago.com 192.168.2.1
fw.london.com 204.32.38.103 www.london.com 192.168.3.1
fw.newyork.com 204.32.38.104 www.newyork.com 192.168.4.1
fw.paris.com 204.32.38.105 www.paris.com 192.168.5.1

fw.tokyo.com 204.32.38.106 www.tokyo.com 192.168.6.1
fw.moscow.com 204.32.38.107 www.moscow.com 192.168.7.1
fw.berlin.com 204.32.38.108 www.berlin.com 192.168.8.1
Lab Terms • Yourcity — the city name for your workstation pair
• Partnercity — the name of your partner city
• Site number — a number between 1 and 8 assigned to your workstation pair
Site-Number Table Table 2 lists site numbers for each of the lab stations.
Table 2: Lab Site Numbers
Site Name Site Number

Detroit 1
Chicago 2
London 3
New York 4
Paris 5
Tokyo 6
Moscow 7
Berlin 8

6 What’s New in FireWall-1 Version 4.0
What’s New in FireWall-1 Version 4.0 I-1
New Platforms Firewall modules can now be installed on Ipsilon and TimeStep PERMIT/Gate
platforms.
Encryption ISAKMP/Oakley is now supported for VPNs and SecuRemote, including ENTRUST
PKI, and is exportable worldwide.
Enterprise The Account Management Client, an independent Firewall module, is included to

Management manage LDAP servers.
Authentication A number of major improvements have been implemented in the FireWall-1 version
4.0 authentication feature:
• Support for TACACS/TACACS+

• Support for RADIUS Version 2
• Support for MD5 in S/Key
• Secondary (backup) AXENT servers are supported
Client Authentication can now be performed using a Web browser. The following new
Authentication features are available:
• Implicit client authentication

• Automatic client authentication sign-off
Security Servers All FireWall-1 security servers now support OPSEC version 1.0. The HTTP security
server supports FTP and HTTPS.
Support for New Network address translation now supports H-323, NetShow, VXtreme and many other
Services services that were not supported in earlier versions of FireWall-1. This further extends
FireWall-1’s impressive list of over 120 out-of-box supported services.

Unit I — Chapter 1:
The Firewall Challenge
Introduction
The main challenge in any network is security. A security engineer’s dilemma is how
to protect the network not only from outside intrusion but from internal breaches, too.
Passwords alone are not enough. They can be broken, intercepted and given to
individuals within a corporate hierarchy. Other methods of securing a network must be
employed: encryption, router management, security policies and content-vectoring
protocols. FireWall-1 gives you these tools, and more, in order to build a safe, secure I-1
network.

The Check Point Certified Security Engineer course wishes you to consider and
explore what you can do to secure your network from internal and external intrusions
by considering the following:
• Consider placement of FireWall-1 throughout the network
• Describe new thinking in network security
• Plan security structure
• Discover OPSEC
• Year 2000 Compliance
• Understanding the importance of backups
7
8 The Firewall Challenge
FireWall-1 is an enterprise product that reaches beyond a singular device that protects
networks from outside attacks. FireWall-1 can be integrated within a network
structure to deny or allow passage from one section of a network to another.
Corporate Intranet
Manufacturing
Marketing
Router
Firewall
Accounting
Legal
Figure 2: Single Firewall Protects Network
Example
Figure 2 demonstrates the singular approach to network security. Although

the network is protected from external influences, each segment of the
network — manufacturing, marketing and so forth — are free to move from
one area to the other.

Unit I — Chapter 1: The Firewall Challenge 9
The Enterprise The next challenge is how to design the network with firewall technology and assure
Security Challenge that the network is protected from internal attacks or those just snooping around.
Corporate Intranet
Marketing
Manufacturing Internet
Router
I-1
Legal

Accounting
Figure 3: Network Protected by Multiple Firewalls
Example
Figure 3 is an example that demonstrates how the use of multiple firewalls

protects inter-network access and how remote networks are protected.
Evolution of Back in the old days, the emphasis on network security was quite restrictive, but
Security network security worked. With the evolution and popularity of the Internet, security
Management risks became greater. Security engineers have had to rethink security needs and adapt
them to their networks. Figure 4 illustrates a comparison that was the accepted
paradigm, with what is now considered to be current network considerations.
Rev. B. Document # CPTS-DOC-C1012

Category Old Paradigm New Paradigm

Security Restrict Access Enable Secure
Connectivity
Technology Conservative and Open and Extensible
Proprietary
User Interface Manage Features Define Policy
Network Management Manage Network Devices Manage Network Traffic
Figure 4: Network Security: Old vs. New
The structure of a secure network starts with forethought and planning before the
actual installation and implementation of the firewall. Given that, there are many
issues to consider for security needs. Selection of a firewall should be based on the
following:
• Open, flexible system design
• Scalable for enterprise growth
• Rapid extensibility to securely manage new applications and protocols
• Simple to customize
• Integrated via policy-based management:
Define an enterprise-wide security policy
Distribute it to multiple network access points
Centrally manage the policy
Building Enterprise Within an organization, the following steps for building the firewall might be part of
Security the planning process:
Defining
Policy Component
Definition
Education
Enforcement
Reinforcement
Implementing
Technology Component Access control
Standards-compliant authentication and encryption

Defining
Network address translation
Anti-virus, URL and Java/ActiveX screening
Connection control
Enterprise Management
Monitoring
Auditing and Monitoring
Monitoring security status
Configuring changes
Scanning for holes
OPSEC OPSEC allows the FireWall-1 product line to be enhanced with the addition of third
party commercial or customer developed applications. Additionally, OPSEC enables
FireWall-1’s product line to be integrated into existing enterprise management,
application and security environments. I-1
The base of the OPSEC development environment is provided by OPSEC services

integrated into the FireWall-1 product line starting with version 3.0b. (3.0b requires
patch 3064.) Without the appropriate version of FireWall-1, there is no OPSEC
environment or capability. The base OPSEC environment is provided by a collection
of OPSEC clients and servers in the FireWall-1 Module and Management Server as
shown in Figure 5.

Figure 5: FireWall-1 OPSEC Services
Table 3: Management Server OPSEC Services
Service Description
LEA Server Provides FireWall-1 log records, in batch or real-time, to an
LEA Client.
OMI Server Provides rule and object information (associated with the
firewalls controlled by the Management Server local to the
OMI Server) to an OMI Client.
UFP Dictionary & Requests the categorization levels offered by the server.
Description Request These categories are then used by the Management
Client Server to build rules associated with the server’s
categorization criteria.
New security-related applications and systems are created by writing special purpose
clients and servers that interact with their corresponding OPSEC clients and servers
on FireWall-1.

FireWall-1 Year 2000 FireWall-1 version 4.x is year 2000 compliant. FireWall-1 uses a four-digit year
Compliance representation in all date fields. This will take effect when the computer system date
changes from the year 1999 to the year 2000. All leap-year date calculations will be
handled properly both before and after the year 2000.
Backup To back up FireWall-1 setup information, you should save the following files:
• Network Objects: $FWDIR/conf/objects.C
• Rule base: $FWDIR/conf/*.W
• Rule bases (on NT or all platforms with version 4.x): $FWDIR/conf/rulebases.fws
• User database: $FWDIR/conf/fwauth.NDB*
Ideally, the FW directory should be backed up on a daily basis.

I-1


Unit I - Chapter 2:
FireWall-1 Architecture
Overview
FireWall-1’s architecture is based upon two components: Stateful Inspection and the
FireWall-1 Inspection Module. Stateful Inspection, which is the technology upon
which FireWall-1’s enterprise security solution is based, assures the highest level of
network security.
FireWall-1’s Inspection Module analyzes all packet communication layers, and

extracts the relevant communication and application state information. The Inspection
Module resides in an operating system’s kernel, but does not modify the system’s
kernel files. (The kernel is the core of the Solaris and NT operating systems,
managing memory, files and peripheral devices; maintaining time and date; launching
applications; and allocating system resources.) Instead, the Inspection Module adds a
kernel driver, loaded between the second and third levels, which are the network
interface card (NIC) driver and TDI layer (in Windows NT). All traffic is transferred
to the Inspection Engine by the NIC driver before traffic reaches an operating
system’s TCP/IP stack.
FireWall-1 defines how packets are transferred through an internal network.
FireWall-1 The following lists the advantages of FireWall-1 architecture:

Advantages I-2
• By inspecting communications at this level, the Inspection Module intercepts and
analyzes all packets before they reach the operating system
• No packet is processed by any of the higher protocol layers unless FireWall-1
verifies that it complies with the enterprise security policy
• The Inspection Module stores and updates state and context information in
dynamic connections tables
Overview
• Dynamic connection tables are continually updated, providing cumulative data

against which FireWall-1 checks subsequent communications
15
16 How FireWall-1 Works
How FireWall-1 Works
Because it processes packets in the operating system’s kernel, FireWall-1 saves

system processing time and resources. Applications and processes above the kernel
layer suffer little (if any) performance problems. And by placing its kernel module
between the NICs and the TCP/IP stack, FireWall-1 solves the problem of protecting
the TCP/IP stack itself (Figure 6):
Figure 6: FireWall-1 Architecture
Inspect Engine in When packets pass through an internal NIC, as shown in Figure 7, the FireWall-1
the Kernel Module kernel module inspects the packets by accessing its rule base and checks the packets
against the control properties (Figure 7):
The inspect engine in the kernel module

inspects packets by accessing its rule base
and checks the packets against the
control properties.
Figure 7: FireWall-1 Rule Base and Inspect Engine

Unit I - Chapter 2: FireWall-1 Architecture Overview 17
Packet Inspected in The FireWall-1 kernel module uses the INSPECT engine to control traffic passing
Kernel Module between networks. The FireWall-1 kernel module has access to the lowest level of
communication, and can inspect all layers of a packet and its data.
Inspect Allowing If packets pass FireWall-1 inspection, the Firewall Module passes the packets through
Packets the TCP/IP stack and to their destination. Packets pass through the NIC to the
INSPECT engine and on up the network stack. Some packets are destined for the
operating system’s local processes. In this case, the Firewall Module inspects the
packets and passes them through the TCP/IP stack to the processes (Figure 8):
If packets do not pass inspection, they are rejected or dropped, according to the
FireWall-1 rule base (Figure 8):
If packets do not pass inspection, they are

rejected or dropped, according to the
rule base.
Figure 8: Inspect Engine Drops or Rejects Packet
I-2
Overview

18 How FireWall-1 Works
A detailed flow of the packets through the INSPECT engine is shown in Figure 9:
Figure 9: INSPECT Engine Flow

The Kernel Component
Sitting at the bottom of the TCP/IP protocol stack, the kernel component receives
packets just before or just after a network card receives them. It is responsible for
inspection, encryption and network address translation.
Kernel Attachment This basic component of the kernel handles the kernel attachment, to ensure that
FireWall-1 inspects all packets passing through the TCP/IP protocol stack. It also
ensures that these packets have a chance to enter the system. Due to the differences in
kernel structure, this part is written differently to every operating system. It is written
with streams to NT and Solaris.
Kernel Virtual The virtual machine executes the INSPECT machine-language code. This is the
Machine compiled form of the firewall flow policy, on packets received by the
Kernel.Attachment. The virtual machine decides on an action and possibly generates
log entries and alerts. It is a stack machine with additional memory in the form of
tables, segment registers, and packet data.
The Kernel.Attachment basic component also includes the virtual defragmentation

mechanism. The basic component is security enforcing.
Kernel Address The Kernel.Address_Translation basic component translates the source and
Translation destination IP addresses and the TCP/UDP port numbers, or sequence numbers in
ICMP packets. Address translation rules can come from the following sources:
• Explicit definition in the security policy
• Content security
Two separate mechanisms perform address translation: the first packet of a connection
is checked against the address translation rules table, and is “address translated”
according to the first rule that it matches. The address translation might include the I-2
allocation of a port number. The Kernel.Address_Translation basic component also
records the exact translation in a table. This is then used to translate further packets
belonging to the same TCP/UDP connection or ICMP virtual connection.
The basic component is also responsible for special protocol support with network
address translation, such as FTP port commands. This is necessary because some
protocols send port numbers and/or IP addresses as part of the data payload.
Overview

20 The Kernel Component
Kernel Encryption This basic encryption component is used to encrypt and decrypt packets according to
an encryption mechanism and keys determined by the FireWall-1 daemon. It supports
FWZ (with both DES and FWZ-1, a proprietary Check Point algorithm), Manual
IPSec, SKIP and ISAKMP/Oakley (IKE).
Kernel Logging The Kernel.Logging basic component transfers log entries, alerts and kernel traps
from the kernel component to the daemon for further handling. The entries are written
either to a circular buffer or to a stream, which stores them in a buffer.
Kernel loctl Handler When the daemon needs to tell the kernel module to do something, it does so by
issuing ioctl commands. This basic component then receives the ioctl command and
acts accordingly.

The Daemon Component
The FireWall-1 daemon component does what all kernel components cannot do
because of their limitations. For example, a kernel component cannot open a file or
initiate an IP packet. The daemon, however, can read the log entries from the kernel,
write them to the log file, or send them to the Management Server.
The daemon component works in user or application space.
The FireWall-1 daemon also replicates some of the command line utilities code. This
replication makes it possible to execute the same operation remotely without logging
into the firewalled computer. Code is both a part of the FireWall-1 daemon and the
command line utilities.
Daemon Command The Daemon.Command_Handler receives the commands from the

Handler Daemon.Communicator, and calls the code in the command line utilities to execute
them. It uses strong authentication, as well as encryption (in encryption-enabled
systems), to prevent masquerading.
Daemon Logging The Daemon.Logging basic component reads entries from the FireWall-1
Kernel.Logging basic component. It then acts according to the entry, generates a log
entry, issues an alert or calls the Daemon.Kernel_Trap_Handler basic component.
In firewalled computers that are remotely managed, the logging mechanism attempts
to send the log entries and alerts to the Management Station. The logging mechanism
only logs locally if it fails. This connection is also authenticated, and if possible,
encrypted.
Daemon Kernel Trap The Daemon.Kernel_Trap_Handler accepts kernel traps and performs them on behalf
Handler of the kernel component. For example, there is a kernel trap to ask the daemon to I-2
negotiate encryption keys with another firewall.
Daemon IOCTL This basic component contacts the Kernel.IOCTL_Handler basic component directly FireWall-1 Architecture
when the daemon needs to tell something to the kernel component and there is no
utility with the same functionality.
Overview

22 The Daemon Component
Daemon Inet Similar to the Solaris inet daemon, this basic component of FireWall-1 listens for
connections coming to the ports that belong to the content security servers. When it
detects a connection, the daemon inet either runs the relevant content security server,
or (if it’s already running) transfers the connection to the content security server.
Daemon In a distributed management configuration, the daemon and utilities components on

Communicator the Firewall Module and Management Station need to talk to each other to transfer
commands, alerts, log entries, and the security policy. This functionality is provided
by the Daemon.Communicator basic component.
For security purposes, the Daemon.Communicator basic component performs

authentication, and possibly encryption, on each connection.
UDP Applications
UDP is a packet-based, connectionless protocol. Unlike connection based protocols
(such as TCP), there is no distinction between the originator of the request and the
response to it. UDP based applications (like WAIS, Archie, and Domain Name
Services) are therefore difficult to filter. Old packet-filtering techniques simply
eliminated UDP connections or opened a large portion of the UDP range to bi-
directional communication, exposing the internal network to attacks.
Solution
FireWall-1solves the problem by keeping a virtual connection on top of UDP
communications. This is achieved by keeping state information for each UDP
connection on the gateway. Every UDP request packet permitted to cross the firewall
is recorded.
Each incoming UDP packet is looked up in the list of pending connections. Packets
are delivered only if they are a response to a request, ensuring that all attacks are
blocked while UDP applications are in use.

I-3
Unit I — Chapter 3
Product Overview
Product Overview
Introduction
This chapter describes the various FireWall-1 products available in an enterprise

configuration and in single products/modules. This chapter describes each product
with reference to what it contains and how it is used. The Enterprise Product, by far, is
the most commonly used product of FireWall-1. This chapter also discusses
considerations when a network needs an additional module installed, but does not
need entire features of the Enterprise Product.
This chapter also describes various thought processes in planning the firewalled
network: where to install the various modules, if needed, and how a company benefits
from a segmented network.
Objectives • Identify the FireWall-1 products

• Discuss how certain configurations need various products
• Discuss segmented network and benefits
Key Terms • Enterprise Product

• high availability
• segmented network
23
24 FireWall-1 Product Type
FireWall-1 Product Type
FireWall-1 Products The FireWall-1 Enterprise Product contains the Management Module and the Firewall
Module. Both modules can be installed on separate machines. The enterprise product
can manage any number of Firewall Modules and Inspection Modules installed on
other machines, as well as routers and switches.
Product Types Figure 10 displays products available during FireWall-1 installation:
Figure 10: Product Types
Modules Firewall modules operate independently of the firewall. Modules can operate on
additional Internet gateways, inter-departmental gateways and critical servers.
Management Module
A single Management Module can control and monitor multiple Firewall Modules.
The Graphical User Interface (GUI) Client is the front-end of the Management Server,
which manages the FireWall-1 database: the rule base, network objects, services,
users, and more.
Firewall Module
The Firewall Module includes the Inspection Module, the Security Servers and the
high availability features, where one firewalled gateway fails and another one takes
its place. The Firewall Module is also known as the firewalled gateway or firewalled
host.

Unit I — Chapter 3 Product Overview 25
Single Products The FireWall-1 line of single products includes the Inspection Module, Firewall-1 I-3
daemons and the FireWall-1 Security Server.
FireWall-1 Single Gateway Product

This product includes the Management Module and the Firewall Module. You may
Product Overview
control up to 250 internal nodes (IP addresses) using the single gateway product,
depending upon which node license you purchase.
It is important to note that if you add additional nodes on your network,

and the additional nodes exceed your installed license, FireWall-1 will
continue to function; however, it will continually warn you that you need
to upgrade your license.
FireWall-1 Firewall Module

Same as the Inspection Module, but includes Security Server and high availability
features. This product is installed on a firewalled gateway that is controlled by a
remote Management Station. The Firewall Module provides access control for one
gateway.
Inspection Module
The Inspection Module is identical to the Firewall Module, but it does not include the
Security Servers or high availability features. The Inspection Module can be installed
on a gateway, if these features are not required.
Enterprise Products Enterprise Management Console products provide several software options for
console locations including:
• A stand-alone Management Console offering that can manage multiple security
enforcement points
• Management Module license updates for managing by single router extension
• Management Module license updates for managing an unlimited number of
routers
• A stand-alone centralized Management Console that enables security
management for 3Com, Bay Networks, Cisco and Microsoft NT routers and Cisco
PIX firewalls

Add-On Modules Add-on modules provide optional encryption and/or increased quality of service
capabilities. Add-on modules are added and installed at security enforcement points,
and work in conjunction with and require one of the following:
• Enterprise Products
• Firewall Modules
• Inspection Modules
The Firewall and Inspection Add-On Modules can be purchased with

25-user, 50-user or unlimited-user licenses.
Installation The FireWall-1 Enterprise Product consists of the GUI Client, Management Module
Considerations and Firewall Module. The need to decide where the modules and GUI client reside
should be determined before installing FireWall-1. Security engineers need to plan the
installation of FireWall-1 carefully to assure maximum security.
Client/Server Configuration
With the Enterprise Product, security engineers may separate modules on different
machines. In Figure 11 the GUI Client resides on a separate machine, as does the
Management and Firewalled Modules. This provides the ability to control features of
a firewall from a remote site.
Router
GUI Management Firewall Internet
Module: Module:
Management Firewalled
Server Gateway
Figure 11: FireWall-1 Client-Server Configuration

Figure 12 displays a client/server distributed configuration in which a Management I-3

Module controls two FireWall Modules. Each module is on a different platform that
protects the networks.
Product Overview
Figure 12: Two Internal Networks Protected by Two Firewalled Gateways
Segmented Security policy rules may be simplified if some logical form of segmentation is used
Networks at the client site. While network equipment manufacturing has been the easy
implementation and support of “flat” IP networks, modern network management
methodologies prescribe a level of hierarchical segmentation.
In hierarchical segmentation the network is divided into subnets along some form of
physical or logical boundaries. Subnets along physical boundaries might have a
different subnet per floor. Subnets along logical boundaries might have a different
subnet per business department. The more sophisticated networks will have
syntactical nomenclature systems, where the values of the different octets within the
address space can be encoded to the point that a great deal of information can be
determined just by the address. The most recent trend is in management links, IP
addressing, and host-naming nomenclature systems, where the name of a machine can
be determined by its network address and vice versa. This is becoming more common
as network address translation (NAT) and private addressing become more popular.
(Refer to RFC 1918.)

A simple example of the most recent trend in network nomenclature and general
management would be as follows:
Class A private address (10.a.b.c) sub-netted to Class-B (255.255.0.0) and Class-C
(255.255.255.0)
Where:
Octet (a) = Physical Site0 = the Collapsed backbone
1 = Headquarters
2 = Atlanta
etc….
Octet (b) = department0 = Site Backbone
1 = Executive
2 = Sales
3 = Data Entry
etc….
Octet (c) = Node type1-10 = servers
11-19 = Access Servers
20-30 = Printers
etc….
100 – 200 = User Workstations
201 – 254 = routers/switches
In this example, if the customer wanted to restrict the data entry staff in Atlanta from
having any outside access — or access anywhere internally in the case of internal
firewalling — it would be easier, and much more efficient from the firewall point of
view, to deny network 10.2.3.0 from reaching the outside with one single rule. The
alternative would be to restrict access on a list of hosts, some kind of user
authentication or other complicated mechanism.
The customer’s network operations staff should be consulted to determine if there is a

form of network segmentation in place. If not, there is an opportunity for network
security to be involved with network operations if there is a division along these lines
to resegment the network to achieve this goal. This is especially true if the customer is
converting to RFC 1918 private address space and using NAT. In this particular case,
FireWall-1 may be the enabling technology that the customer is using to make the
address conversion, so this is the perfect time for such considerations.

Review I-3
Summary FireWall-1 expanse of products provides:
Product Overview
Management Module
• Centralized graphical security management
• Single or unlimited security enforcement points
Inspection Module
• Access control
• Client and session authentication
• Network address translation
• Auditing
Firewall Module
• Inspection Module capabilities (above)
• User authentication
• Multiple firewall synchronization
• Content security
Review Questions 1. What are the products in the FireWall-1 product line?
2. What is a segmented network and what is its benefit to a network?
3. Which FireWall-1 products apply to which network configurations?

30 Review

Unit 2 — FireWall-1 Security
Chapter 1: Advanced Security Policy
Chapter 2: User Defined Tracking
Chapter 3: SYNDefender
Chapter 4: Content Security

III-3
Advanced Security Policy

Introduction
Rules are made to be broken. That idea might work well in grade school, but when
you want a secure network, the rules cannot be made to break. FireWall-1 gives you
the ability to maintain your rule base by giving you the following tools:
• Masking (hiding) rules
• Viewing hidden rules II-1
• Creating masks
• Unhiding rules
Advanced Security
• Using query to find specific rules
• Disabling rules
In addition to hiding and unhiding rules, FireWall-1 allows you to do the following:
• Block intruders by using three blocking options
Policy
• Install and uninstall a security policy
• Improving FireWall-1’s performance via a security policy
Objectives • Demonstrate how to do the following:

Hide and unhide rules
View hidden rules
Define a rule mask
Apply rule masks
• Demonstrate how to query a rule base
• Show how to disable and enable rules
• Show how to install and uninstall a security policy
• List the guidelines for improving FireWall-1 performance using a security policy
• Describe the steps needed to block an intruder
33
34
• List the three blocking scope options and their uses

• Describe how block request is used
Key Terms • rule mask

• hide rule
• disable rule
• query
• negate query
• explicit
• security policy file (SPF)
• block intruder
• block request
Security Policy The following defines security policy concepts:

Overview Security policy — A set of rules that defines an internal network’s security.
Rule — Individual rules that define an internal network’s security.
Rule base — Translates a security policy to a collection of individual rules.
Rule-base editor — Creates rules to define a security policy.

Unit II — Chapter 1: Advanced Security Policy 35
Masking Rules III-3

Overview During rule creation, deletion or troubleshooting, you can make viewing a rule base
easier by hiding rules you do not want to see. In FireWall-1, this is called masking
rules. Masking rules is useful for viewing only a few rules without being distracted by
other rules. Hidden rules remain part of the rule base and are installed when the
security policy is installed.
Hiding Rules To hide a rule, do the following:

1. Select the rule by clicking on its number (Figure 13):
II-1
Advanced Security
Figure 13: Rule Number
2. Select Mask (hiding rules) from the View menu (Figure 14):
Policy
Figure 14: Selecting Mask

36 Masking Rules
3. Select Hide Rule (Figure 15):
Figure 15: Selecting Hide Rule
4. The rule is now hidden, but it is still part of the rule base and will be installed
when the security policy is installed.
Figure 16 shows a rule before being hidden. Figure 17 shows the same rule
after it is hidden.
Figure 16: Rule Before it is Hidden
Figure 17: Rule After it is Hidden
When hiding rule 1 in Figure 17, rules 2 and 3 remain visible, but the rule
numbers do not change.
Example
Two organizations (within the same internal network) share the same security
policy, because they both share the same firewalled device. To hide the rules
for the second organization and display only the first organization’s rules,
security engineers use masking rules.

Figure 18 displays a rule base with all rules displayed for Org (organization) 1 III-3
and Org 2:

Figure 18: Rules for Both Organizations
Figure 19 displays the rule base with the Org 2’s rules hidden and only Org
1’s rules displayed:
II-1
Advanced Security
Figure 19: Rules for Org 1 Only
Policy
Viewing Hidden If Show Hidden in the Mask menu is checked, then all hidden rules are displayed in
Rules the rule base together with the other rules. Figure 20 is the Show Hidden menu option
under Mask (hiding rules):
Figure 20: Show Hidden Option

38 Masking Rules
When they are revealed, hidden rules are colored differently from other
rules. Different coloring makes it easy to identify hidden rules when they
are revealed (Figure 21):
Figure 21: Hidden Rules Displayed
If Show Hidden is not checked, the hidden rules are not displayed. A thick, colored
horizontal line indicates the presence of hidden rules (Figure 22):
Thick Line
Figure 22: Hidden Rules Not Displayed (note thick line)
Whether they are displayed or not, hidden rules are installed when the
security policy is installed.
Unhiding Hidden To unhide all hidden rules, select Clear Mask from the Mask menu (Figure 23):
Rules
Figure 23: Selecting Clear Mask

Querying the Rule Base III-3

You can query a rule base and display only the rules that satisfy the criteria specified
in the query, hiding all other rules. To add a query to a rule base, follow these steps:
1. Add a rule base query.
2. Add a rule base query clause.
3. View the rule base for queried rules only.
Query Screens To add a rule base query to FireWall-1, you will utilize the following screens:
• Rule Base Queries
• Rule Base Query
• Rule Base Query Clause
II-1
The Rule Base Queries Screen
The Rule Base Queries screen lists all defined queries, and allows you to add edit,
delete and apply queries (Figure 24):
Advanced Security
Policy
Figure 24: The Rule Base Queries Screen
The Rule Base Queries options are as follows:

Add — New query.
Edit — The selected query.
Delete — The selected query.
Use as Mask — The selected query as a mask, first clearing all other masks.

40 Querying the Rule Base
And Mask — The selected query as a mask, ANDing it with any masks currently
applied.
Or Mask — The selected query as a mask, ORing it with any masks currently
applied. The difference between And Mask and Or Mask is as follows:
And Mask hides the (zero or more) rules that satisfy the query, in addition to any rules
that are already hidden.
Or Mask unhides the (zero or more) hidden rules that satisfy the query, in addition to
any rules that are already not hidden.
The Rule Base Query Screen

Create a new rule-base query in the Rule Base Query screen (Figure 25):
Figure 25: Naming a Rule-Base Query
The following are the Rule Base Query options:

Name — The query’s name.
Negate Query — Negates all query clauses; for example, if the query specifies that
Source is localnet, then the negated query specifies that Source is not localnet. If
Negate Query is checked, then the meaning of And and Or is:
And — Query specifies NOT (Source is localnet and Service is FTP).
Or — Query specifies NOT (Source is localnet or Service is FTP).

Operation On Criteria — Click And or Or to select the following: III-3

And — The query’s clauses ANDed together.
Or — The query’s clauses ORed together.
The Rule Base Query Clause Screen

The Rule Base Query Clause screen allows you to select specific network objects to
query (Figure 26):
II-1
Advanced Security
Policy
Figure 26: The Rule Base Query Clause Screen
The following lists the Rule Base Query Clause options:

Negate — Negates query-clause criteria; for example, if the query clause specifies
Service is FTP, the clause (when negated) is taken to specify NOT (Service is FTP).
Explicit — Only rules that explicitly include the object satisfy the criteria. If the rule
includes a group of which the object is a member, then the rule does not satisfy the
criteria. Also, if the rule includes an object which is a member of a group specified in
the criteria, then the rule does not satisfy the criteria.
For example, the standard FireWall-1 service definitions include a group named
Authenticated, of which FTP and HTTP are members. If Explicit is checked, then a
rule does not satisfy the criteria in the following two cases:

42 Querying the Rule Base
• Specifies Authenticated and the rule includes FTP

• Specifies FTP and the rule includes Authenticated.
Column — The rule-base column that fits this query clause.
The completed Rule Base Query screen appears, and the query clause is listed (Figure
27):
Figure 27: Completed Rule Base Query Screen
Adding Query to a To add queries to a rule base, follow these steps:

Rule Base
1. Click View > Queries from the Security Policy GUI main screen. The Rule Base
Queries screen appears (Figure 24 on page 39).
2. Click Add to create the query; the Rule Base Query screen appears (Figure 25 on
page 40).
3. Enter a name for the query in the Name option (Figure 25 on page 40) and click
Add.
4. Select specific network objects to query (Figure 26 on page 41). Click OK when
finished.
5. The query just defined appears in the Rule Base Query screen (Figure 27).
6. Click OK. The query is used as a mask for hiding the rules that do not satisfy the
query criteria.

The Queried Rule Base III-3

The rule base is displayed (Figure 28):

Figure 28: Queried Rule Base
The only rules that are displayed, that is, the only rules that are not hidden, are those
whose Source includes localnet. Note that the Rule Base Queries screen is still open, II-1
allowing you to continue to define or use additional queries.
Example
Advanced Security
Refine a query so that the only rules displayed are those that satisfy the
following criteria. Source includes localnet and Service includes FTP:
1. Modify the query by adding an additional clause to specify both of the

above criteria.
Policy
2. Define a new query that specifies only the second criterion and apply both
queries, one after the other.
Figure 29 displays a rule base with the above two criteria applied:
Figure 29: New Query

44 Disabling Rules
Disabling Rules
Overview When security engineers disable a rule, the rule is no longer part of the rule base and is
not installed when the security policy is installed. However, the rule is still displayed
in the rule base, and you can re-enable it any time. This feature is useful for
experimenting with the rule base.
For example, you can do the following:

• Disable rules
• Install a security policy
• Analyze the effects of the new security policy
• Re-enable rules without having to re-enter them
• Reinstall the security policy.
Failure to reinstall the security policy disables re-enabled rules.
Disabling Rules To disable a rule, follow these steps:

1. Select the rule by clicking on its number.
2. Right-click on the rule number and select Disable Rule (Figure 30):
Figure 30: Selecting Disable Rule

When a rule is disabled, a large red cross is drawn over its rule number (Figure 31): III-3

Figure 31: Disabled Rule
Enabling a Disabled To enable a disabled rule, follow these steps:

Rule
1. Select the disabled rule by clicking on its number.
2. Right-click and select Disable Rule to deselect (Figure 32):
II-1
Advanced Security
Policy
Figure 32: Right-Click to Deselect Disable Rule

46 Lab 1: Policy Editor
Lab 1: Policy Editor
Objective: Use some of the new features in the policy editor. New features covered
will be disabling of individual rules, hiding of rules, queries and viewing implied
rules.
In this lab, use FTP instead of TELNET, if your web server is not running
the TELNET client.
4Define a host access rule

Define a rule that allows any host on your internal network to get to any host outside
of your network using HTTP, HTTPS, FTP, and Gopher:
1. Pull down the Edit menu, and select Add Rule and Top.
2. Right-click in the Source column of the new rule and select Add.
3. A dialog box listing the defined network objects appears. Select the net_yourcity
network object and click OK.
4. Right-click in the Destination column of the new rule and select Add.
5. A dialog box listing the defined network objects appears. Select the net_yourcity
object for your local network and click OK.
6. Right-click in the Destination column again and select Negate.
7. Right-click in the Service column of the new rule and select Add.
8. A dialog box listing the defined services/protocols appears. Scroll down the
dialog box screen, select HTTP and click OK.
9. Repeat the previous step for each of the other services (HTTPS, FTP and Gopher).
10. Right-click in the Action column of the new rule and select Accept.
11. Leave the Track field empty.
12. In the Comment column, double-click and enter an appropriate description of the
rule in the text box that appears.
13. Click OK.

4Define a Web access rule III-3

Define a rule that allows your Web server (www.yourcity.com) to get to any host

outside of your network using an FTP service:
1. Pull down the Edit menu, select Add Rule and After.
3. A dialog box listing the defined network objects appears. Select the Web server
(www.yourcity.com) and click OK.
5. A dialog box listing the defined network objects appears. Select the network
object for your local network (net_yourcity) and click OK.
dialog box screen, select FTP and click OK. II-1
Advanced Security
11. Click OK.
4Define an external host rule
Policy
Define a rule that allows any host outside of your network to get to your Web server
using an FTP service:
1. Pull down the Edit menu, and select Add Rule and After.
4. Right-click in the Source column again and select Negate.
6. A dialog box listing the defined network objects appears. Select the Web server
and click OK.
8. A dialog box listing the defined services/protocols appears. Scroll the dialog box
screen down, select FTP and click OK.

11. Click OK.
4Define an e-mail access rule

Define a rule that allows any host outside of your network to get to your e-mail server
using an SMTP service:
6. A dialog box listing the defined network objects appears. Select the e-mail server
and click OK.
dialog box screen, select SMTP and click OK.
rule in the text box that appears
11. Click OK.
4Define an e-mail server rule

Define a rule that allows your e-mail server to get to any host outside of your network
using an SMTP service:
3. A dialog box listing the defined network objects appears. Select the e-mail server
and click OK.

8. A dialog box listing the defined services/protocols appears. Scroll the dialog box III-3
screen down and select SMTP and click OK.

11. Click OK.
4Define a stealth rule

Define a rule that drops any attempts to connect to your firewall from any host:
1. Pull down the Edit menu, and select Add Rule and Bottom.
3. A dialog box listing the defined network objects appears. Select your firewall
object and click OK.
II-1
4. Right-click in the Action column of the new rule and select Drop.
5. Right-click in the Track column of the new rule and select Long.
Advanced Security
7. Click OK.
4Define a cleanup rule
Policy
Define a clean-up rule (one that rejects all traffic) as the last rule in your rule base:
1. Pull down the Edit menu, and select Add Rule and Bottom.
2. Right-click in the Action column of the new rule and select Reject.
4. Click OK.
4Save and install the policy

1. Save the policy: Pull down the File menu and select Save.
2. Install the policy: Pull down the Policy menu and select Install.

4Verify the policy

Verify that you can connect using FTP from www.yourcity.com to
www.yourpartnercity.com:
1. On www.yourcity.com, FTP to www.yourpartnercity.com with the following
command: ftp www.yourpartnercity.com.
2. If you are successful, cancel the FTP session.
3. If you are not successful, ask your instructor for assistance.
4Hide the second rule

1. Right-click the second rule (outgoing FTP from www.yourcity.com) in the No. 2
column. A menu appears.
2. Select Hide Rule from the menu.
4Save and install the policy (second time)

1. Save the policy: Pull down the File menu and select Save.
2. Install the policy: Pull down the Policy menu and select Install.
4Verify the policy (second time)

Once again, verify that you can FTP from www.yourcity.com to
www.yourpartnercity.com: On www.yourcity.com, FTP to www.yourpartnercity.com
with the following command:
ftp www.yourpartnercity.com
Does it work? (It should).
4Unhide the second rule

1. Pull down the View menu and select the Masks (hiding rules) submenu.
2. Select Clear Mask from the Masks (hiding rules) submenu.
3. When prompted if you want to unhide all rules, select Yes.
4Disable the second rule

2. Select Disable Rule from the menu.

4Save and install the policy III-3

4Connect to your partnercity
Once again, check to see if you can FTP from www.yourcity.com to
www.yourpartnercity.com: On www.yourcity.com, FTP to www.yourpartnercity.com
with the following command:
Does it work? (It should not).

4Re-enable the second rule
2. Remove the check mark from the Disable Rule menu item by clicking it with your
mouse or pointer button.
II-1
4Save and install the policy
Advanced Security
4Connect to your partnercity
Verify that you can FTP from www.yourcity.com to www.yourpartnercity.com. On
www.yourcity.com, FTP to www.yourpartnercity.com with the following command:
Policy
Does it work? (It should).
4Create HTTPrules query
Create a query called HTTPrules that will cause the rule-base editor to display only
rules that contain the HTTP service:
1. Pull down the View menu and select the Queries menu item. The Rule Base
Queries dialog appears.
2. Click the Add button from the Rule Base Queries dialog. The Rule Base Query
dialog box appears.
3. Enter the name HTTPrules for this query and click the Add button to add criteria.
This will cause the Rule Base Query Clause dialog to appear.
4. In the Clause Statement box, pull down the Column list and select services. This
will cause the left box (Not in list) to contain a list of the services available to
FireWall-1.
5. Select the HTTP service from the left box and click Add. This will transfer the

HTTPservice to the right box (In list).

6. Click OK.
7. In the Rule Base Query dialog, click OK.
8. In the Rule Base Queries dialog, click Apply and OK.
4List visible rules

Make a note of the rules that are still visible in the rule base.
4Clear query mask

Clear the mask that resulted when the query was applied:
1. Pull down the View menu and select the Masks (hiding rules) submenu.
2. Select Clear Mask from the Masks (hiding rules) submenu.
3. When asked if you want to unhide all rules, select Yes.
4Modify HTTPrules query

Modify the HTTPrules query such that the HTTP service must be shown explicitly in
the rule (not a part of some group):
1. Pull down the View menu and select the Queries menu item. The Rule Base
Queries dialog appears.
2. Select the HTTPrules query and click the Edit query button from the Rule Base
Queries dialog. The Rule Base Query dialog box appears.
3. Click the Edit clause button to change the criteria. This will cause the Rule Base
Query Clause dialog to appear.
4. In the Clause Statement box, click the check box labeled Explicit.
5. Click OK.
7. In the Rule Base Queries dialog, click Apply.
4List visible rules

List the rules that are still visible in the rule base: Move the Rule Base Queries dialog
screen so that you can see the rules in the rule base.
4Clear the mask

Clear the mask that resulted when the query was applied: Click the Clear button in the
Masks box in the Rule Base Queries screen.

4Create DenialRules query III-3

Create a query called DenialRules, that will display only the rules that do a drop or a

reject:
1. Click the Add button from the Rule Base Queries screen. The Rule Base Query
dialog box appears.
2. Enter the name Denialrules for this query and click the Add button to add criteria.
This will cause the Rule Base Query Clause dialog to appear.
3. In the Clause Statement box, pull down the Column list and select action. This
will cause the left box (Not in list) to contain a list of the actions available to
FireWall-1 Rule Base.
4. Select Drop from the left box and click Add. This will transfer Drop to the right
box (In list).
5. Select Reject from the left box and click Add. This will transfer Reject to the right
box (In list).
6. Click OK. II-1
8. In the Rule Base Queries dialog, click Apply.
Advanced Security
4List visible rules
List the rules that are still visible in the rule base: Move the Rule Base Queries screen
so that you can see the rules in the rule base.
Policy
4Use HTTPRules query
Use the HTTPrules query as well to show rules that have HTTP in them:
1. Select the HTTPrules query in the Rule Base Queries screen.
2. Click the Or button in the Masks box of the Rule Base Queries screen.
4List visible rules

List the rules that are still visible in the rule base: Move the Rule Base Queries screen
so that you can see the rules in the rule base.
4Clear the mask

Clear the mask that resulted when the query was applied: Click the Clear button in the
asks box in the Rule Base Queries screen.

54 Blocking Connections
Blocking Connections
To block connections, use the FireWall-1 Log Viewer (Figure 33):
Figure 33: Log Viewer
Starting the Log To start the Log Viewer, follow these steps:
Viewer
Windows 95 or NT
1. Click Start> Programs> FireWall-1, or choose Log from the view menu in the
security policy window.
2. Select Log Viewer.
Solaris
1. Run $FWDIR/bin/fwlog.
Block Intruder FireWall-1 allows you to terminate and block any connection from or to a specific IP
address. There are two ways to terminate a connection: Block Intruder and Block
Request.

The Block Intruder The Block Intruder screen allows you to set the parameters to block out an intruder III-3
Screen (Figure 34):

II-1
Advanced Security
Figure 34: Block Intruder Widow
The fields you may set on the Block Intruder screen are as follows:
Policy
Connection ID and Connection Parameters — Those of the selected connection.
Blocking Scope — Select one of the options:
Block only this connection — The selected connection is terminated, and all
further attempts to establish a connection from the same source IP address to the
same destination IP address and port will be blocked.
Block access of this source — The selected connection is terminated, and all
further attempts to establish connections from the source IP address of the
selected connection will be denied.
Block access to this destination — The selected connection is terminated, and all
further attempts to establish connections to the destination IP address of the
selected connection will be denied.
Blocking Timeout — Select one of the options:
Indefinite — Block all further access until the firewall is stopped.
For... minutes — Block all further access attempts for the specified number of
minutes.

56 Blocking Connections
Force this blocking — Select one of the options:

Only on... — Block access attempts through the indicated Firewall Module.
On any Firewall Module — Block access attempts through all Firewall Modules
which are defined as internal, firewalled gateways or hosts on this Management
Server.
Terminating a Connection Using Block Intruder

To terminate a connection using the Block Intruder window, follow these steps:
1. Change the viewer to Active mode.
2. Select the connection you want to block.
3. Select Block Intruder from the Select menu, or select the Block Intruder icon from
the toolbar.
4. Click OK.
Block Request Block Request (Figure 35) is an option if the connection ID of the user is known. This
eliminates the need to search for the connection in the Log Viewer, and allows a
simple entry of the connection ID to access the Block Intruder screen.
Figure 35: Block Request Screen
The Block Request screen has only one field:

Block Intruder from Connection ID — This is the connection ID with which the
intruder has connected.
Using Block To block an intruder, follow these steps:

Request
1. From the menu select Block Intruders, or click the Block Intruder icon from the
toolbar.
2. Enter the Connection ID of the connection you want to terminate or block; click
OK.
3. Enter the parameters in the Block Intruder window.
4. When finished, click OK.

Lab 2: Block Intruder III-3

Objective: Verify that you have an installed rule that allows incoming TELNET
sessions to your Web server (www.yourcity.com). If not, then define a rule that allows
your Web server (www.yourcity.com) to get to any host outside of your network using
the TELNET service.
Scenario: Someone from outside your internal network has initiated a TELNET
session into your Web server (www.yourcity.com). You wish to kill the TELNET
connection because you suspect it was sent with malicious intent.
1. Pull down the Edit menu, select Add Rule and then select After.
2. Right-click in the Source field of the new rule and select Add.
3. A dialog box listing the defined network objects will appear. Select the Web
server (www.yourcity.com) and click OK.
II-1
4. Right-click in the Destination field of the new rule and select Add.
5. A dialog box listing the defined network objects will appear. Select the network
object for your local network and then click OK.
Advanced Security
6. Right-click in the Destination field again and select Negate.
8. A dialog box listing the defined services/protocols will appear. Scroll the dialog
box screen down and select TELNET and click OK.
Policy
rule in the text box that appears. Click OK.
4Allow incoming TELNET sessions to your Web server
Verify that you have an installed rule that allows incoming TELNET sessions directed
to your www.yourcity.com machine. If not, then define a rule that allows any host
outside of your network to get to your Web server using the TELNET service:
1. Pull down the Edit menu, select Add Rule and then select After.
2. Right-click in the Source field of the new rule and select Add.
4. Right-click in the Source field again and select Negate.
5. Right-click in the Destination field of the new rule and select Add.
6. A dialog box listing the defined network objects will appear. Select the Web
server and click OK.

58 Lab 2: Block Intruder
8. A dialog box listing the defined services/protocols will appear. Scroll the dialog
box screen down and select TELNET and click OK.
rule in the text box that appears. Click OK.
11. Save and install the policy.
4TELNET to an external host

Have yourpartnercity TELNET or FTP to your web server and log on:
1. On your FireWall-1 GUI client, Open the Log Viewer application.
2. Switch from Log mode to Active mode using the pull-down menu on the tool bar.
3. Locate the TELNET connection that is being made from yourpartnercity to your
Web server and note the connection number.
4Block intruder traffic

Block all traffic from the source of the Intruder (Log Viewer).
1. Pull down the Select menu and select the Block Intruder menu item.
2. The Blocking Request By Connection ID dialog box will appear.
3. Enter the connection number in the text box marked Block intruder with
connection ID.
4. The Block Intruder dialog will appear. Check the radio button labeled Block
access of this source.
5. Check the radio button labeled For ____ minutes and enter 1 minute into the box.
6. In the Force this blocking area, Check the radio button labeled On any FW-1.
7. Click OK to initiate the Block.
4Check for active TELNET session

Check with yourpartnercity to see if his TELNET session is still active:
1. Ask yourpartnercity to attempt to TELNET again.
2. After one minute has elapsed, ask yourpartnercity to attempt to connect to your
Web server again.

Uninstalling a Security Policy III-3

Security engineers uninstall security policies when they need to stop FireWall-1.
When you install new security policies, do not delete the original policy.
Deleting the original policy could provide a way for external hackers to
threaten an internal network.
The Uninstall The Uninstall Security Policy screen (Figure 36) lists all internal, firewalled hosts and
Security Policy routers. By default, all internal, firewalled hosts and routers are already selected.
Screen
II-1
Advanced Security
Policy
Figure 36: The Uninstall Security Policy Screen
Steps for To uninstall a security policy, follow these steps:

Uninstalling a
1. Click Policy > Uninstall from the Security Policy GUI main screen.
Security Policy
2. Click Clear to deselect all items in the screen.
3. Click All to select all the items in the screen. You may deselect specific items. The
security policy will not be removed on deselected items.
4. Click OK. FireWall-1 issues a warning if there is an inconsistent rule in the rule
base.

60 Uninstalling a Security Policy
5. FireWall-1 uninstalls the security policy (Figure 37):
Figure 37: Uninstalling a Security Policy

Security Policy File III-3

The FireWall-1 security policy file (SPF), which is the file (default.W) containing all
security-policy parameters, is kept in the c:\winnt\fw\conf directory (Windows) and
$fwdir/fw/conf directory (Solaris). The default.W file contains the following syntax
(Figure 38):
II-1
Advanced Security
Figure 38: The Default SPF
Policy
Security policy rules are kept in an individual SPF on the Management Station or
combined with rules of other FireWall-1 modules into a combined SPF.

62 Security Policy File
Example
Name an SPF something that relates it to the Firewall Module. For example
the Detroit Firewall Module’s SPF (fw.detroit.com) could be named detroit.W
and would contain the options appearing in Figure 39:
Figure 39: detroit.W SPF with Firewall Module Defined
In the Install On column of a rule base, specify the target as the Firewall
Module (Figure 40). The security engineer cannot accidentally load the SPF
onto the wrong Firewall Module.
Figure 40: Target Defined in a Rule Base

You can combine SPFs by including combined rules of multiple Firewall III-3
Modules (Figure 41):

II-1
Figure 41: SPF with Combined Rules
Advanced Security
In the Install On column of each rule, specify the targets as the Firewall
Module (Figure 42):
Policy
Figure 42: Multiple Targets in a Rule Base

64 Guidelines for Improving FireWall-1 Performance via a Security Policy
Guidelines for Improving FireWall-1 Performance via a Security Policy
Management Installation time for creating network objects can often be decreased by listing
Module machine names and IP addresses in the hosts files:
• /etc/hosts (Solaris)
• /winnt/system32/drivers/etc/hosts (Windows)
If installing a security policy on a Windows computer, using the hosts file

will be faster.
Firewall Module FireWall-1 performance depends on the hardware, the security policy, and the
characteristics of the network traffic. While the Firewall Module is inspecting packets,
the amount of time a packet spends in the kernel increases. The conclusion is that
Firewall-1 has a greater impact on latency — connection latency or transaction
latency — and less on bandwidth.
The following suggestions regarding security policies should improve performance as

well:
Rule base — Keep the rule base simple. Performance degrades when there is a very
large number of rules, or when the rules are complex.
Try to position the most frequently applied rules first in the rule base. For example, if
most connections are HTTP packets, the rule that accepts HTTP should be the first
rule in the rule base (Figure 43). Be sure to keep this rule as simple as possible.
Figure 43: HTTP Rule First in Rule Base
Accounting and Live Connections — When using Accounting (Log Viewer), your
system performance may decrease (for NT, up to 10%; for Solaris, up to 13%). To
alleviate decreased performance, disable Accounting.
Figure 44 displays Account as part of the Track option for a specific rule:

III-3

Figure 44: Tracking using Account
Unnecessary When setting up security policy properties, do not include unnecessary services, such
Services as Real-Audio (Figure 45). You can add services to the rule base as needed.
II-1
Advanced Security
Policy
Figure 45: Real-Audio Service

66 Review
Review
Summary It can become cumbersome when working with the rule base if you apply many
different rules that have many different functions. To make the rule base more
manageable, security engineers can apply rule masks, which allow engineers to see
only the rules they want to see. Masking involves hiding and unhiding rules. You may
even disable rules temporarily without deleting them from the rule base.
FireWall-1 also gives you the ability to query the rule base in order to find rules that
match specific criteria. This is a useful tool for rule bases that have many rules, or to
find rules that are very specific in their function.
You can create a security policy that specifies the types of rules that are to be
followed. A security policy can be shared among other firewalled systems. If the
security policy contains rules that do not apply to a certain system, those rules can be
hidden or disabled for that system. You may also uninstall a security policy, if
necessary. You may also find an improvement in FireWall-1’s performance if you
follow the guidelines for implementing a security policy.
When necessary you may specify that an intruder be blocked. You can block the
intruder in one of three ways:
• Block only this connection.
• Block access of this source.
• Block access to this destination.
If the intruder’s connection ID is known, then the Block Request option can be used.
This eliminates the need to search for the connection in the Log Viewer, and allows a
simple entry of the connection ID to access the Block Intruder window.
Review Questions 1. List the steps for hiding and unhiding rules.
2. List the steps for disabling and enabling rules.
3. How does using a rule mask help in maintaining a rule base?

4. Explain the process for sharing and maintaining a security policy between two III-3
different organizations within the same network.

5. Explain the use of query.
6. What three methods of blocking an intruder can be used? How are they different
from each other?
II-1
7. What option could you use when the intruder’s connection ID is known?
Advanced Security
8. What data file is used to store the security policy? Where is the file located?
Policy
9. Define some guidelines for improving FireWall-1’s performance via a security
policy.

68 Review

U s e r D e f i n e d Tr a c k i n g
Introduction
FireWall-1 provides you with the ability to extend the alert handling capabilities
beyond what is typically provided with the firewall. Security engineers have the
option of writing their own custom alert handlers. This allows you to generate more
detailed, custom messages in alert situations, as well as associating priority/actions
with the alert handler. For example, you may want an audible alarm when spoofing is
detected on an external network interface, but only record some information to a file if
spoofing occurs on your internal network.
Objectives • Be able to list the needs for user defined tracking

• Explain how user defined tracking works
• Demonstrate how to configure user defined tracking
• Define alertf and explain how it is used
Key Terms • user defined tracking

• alertf
II-2
User Defined Tracking
69
70 User Defined Tracking
User defined tracking is the process by which the option of an alert or log is
established. For example: Figure 46 shows the process of creating a mail (SMTP)
definition. The parameters are defined and alert is selected as the Exception Track.
Security engineers need to define how they will be notified by the alert.
The difference between FireWall-1 logs and user-defined alerts is that logging allows
you to view connection information, for example, viewing an IP address for an
incoming packet. Alerts are usually custom-written, and can be applied to any of the
user defined tracking properties of a security policy.
A user-defined alert is one type of alert or log tracking. Other trackings

include short and long log formats; accounting; and alert, mail alert and
SNMP track. These topics are covered in the Log Viewer chapter of this
guide.
Add logs and alerts to user defined tracking to allow the following:
• Custom log filter programs to log screen entries generated by a specific rule
• Alerts when a complex condition is met
• A single rule to generate different types of alarms for different conditions
Example
Add alerts or logs to a mail (SMTP) definition screen (Figure 46):
Figure 46: Example: Exception Track Log, Alert

Unit II — Chapter 2: User Defined Tracking 71
The User Defined Tracking (Exception Track) options are as follows:

None — Do not log or alter.
Log — Log the event.
Alert — Issue an alert.
Configuring a Rule Configuring a rule for user-defined alerts involves the following steps:
1. Write the user defined application script and install it on the firewall.
The user defined application must be placed in $FWDIR/bin.
2. Specify the application name in the User Defined property field, located in the
Control Properties under the Log and Alert tab.
3. Add/modify a rule for User Defined Alert (a rule whose tracking field is
configured for UserDefined).
User-defined applications can be compiled or written using the following:
• C/C++
• Perl
• Bourne Shell
• C-Shell
Do not use ActiveX.
II-2

The Log and Alert To set up user defined tracking, modify the Log and Alert tab of the Properties Setup
Tab screen (Figure 47):
Figure 47: Log and Alert Tab
Excessive Log Grace Period — Click on the arrow to set the minimum amount of
time (in seconds) between consecutive logs of similar packets.
Popup Alert Command — Type the operating-system command to execute on the
firewalled machine when an alert is issued. If you change this command, you may not
become aware of the condition that caused the alert. The default directory is $FWDIR/
bin/alert.
Mail Alert Command — Type the operating-system command to execute on the
firewalled machine when mail is the specified track of a rule. You can specify
commands other than mail.
SNMP Trap Alert Command — Type the operating-system command to be
executed on the firewalled machine when SNMP Trap is specified as the action in a
rule.
User Defined Alert Command — Type the operating-system command to be
executed when User-Defined is specified as the action in a rule.
The User Defined Alert Command is the option where security engineers
add the executable for the user-defined alert.

Anti Spoof Alert Command — Type the operating-system command to be executed

(default is $FWDIR/bin/fwalert) on the firewalled machine when Alert is specified for
Anti-Spoofing detection in the Interface Properties window.
User Authentication Alert Command — Type the operating-system command to
execute on the firewalled machine when an alert is specified for any of the following:
• Authentication Failure Track in the screen of the Properties Setup screen
• Successful Authentication Tracking in the General tab of the Authentication
Action Properties screen
IP Options Drop Track — Select the action to take when a packet with IP Options is
encountered. None, Log or Alert. FireWall-1 always drops these packets, but you can
log them or issue an alert.
Log Established TCP Packets — Check to log TCP packets for previously
established TCP connections or packets whose connections have timed out.
Setting up User To set up user defined tracking, follow these steps:

Defined Tracking
1. Write the script and place it in the $FWDIR/bin directory on the firewall.
2. Click Properties> Policy from the Security Policy GUI main screen.
3. Enter definitions in the necessary fields shown in Figure 47 on page 72.
4. Click OK when finished.
II-2

Adding User When the UserDefined property is set up, write it to the security policy (Figure 48):
Defined Tracking to
the Security Policy
Figure 48: Track Rule
alertf The user defined program alertf can be used to monitor the logging activity of a rule
and issue a specific alert when a condition is met.
The syntax of the command is:
alertf N-seconds N-alerts alert-command arg#1 arg #2

arg#3...
N-seconds — The number of seconds.
N-alerts — The number of alerts.
alert-command — The actual command to execute to invoke an alert.

Example
alertf 60 4 fwalert
Will run the normal alert script if there are four or more alerts in the last sixty
seconds.
The alertf program will generate a log entry (in the log directory) for each alert
in the N seconds in c:\winnt\system32\alertf.log. For Solaris administrators,
alertf generates a log entry in the directory where the firewall was started.
A standard FireWall-1 alert (fwalert) runs if four or more user-defined

alerts are generated in less than a minute.
II-2

76 Lab 3: User Defined Tracking with alertf
Lab 3: User Defined Tracking with alertf
4Specify User Defined Alert command

Specify the User Defined Alert command in the Control Properties screen:
1. From the Security Policy GUI, open the Control Properties/Log and Alert screen.
2. In the User Defined Alert Command field, replace the fwalert command with the
following:
alertf 60 5 fwalert
3. Click OK.
4Add User Defined tracking (if you already have a stealth rule skip this
step)
Add user defined tracking to the security policy:
1. Add a stealth rule: Pull down the Edit menu, and select Add Rule and Top.
2. In the Destination column of the new rule, right-click, select Add and Select your
firewall object. Click OK.
3. In the Action column, right-click and select Reject.
The stealth rule tracking is changed to reject for just this exercise. It
should normally be set to drop.
4. In the Track column, right-click and select User Defined.

6. Click OK.
4Verify and install the security policy
4Activate the System Status
4Test the rule

From your Web server, connect to your firewall through FTP five times. All FTP
attempts will be logged. An alert will be generated only if you attempt to connect your
firewall five or more times within a 60-second period.

Review
Summary Firewall-1 provides security engineers the ability to write custom applications to be
invoked as alerts. Applications can summon a very simple alert, such as a notification
that shows up on the monitor or complex alerts that, perhaps, notify you through a
pager.
User defined alerts allow the following:

• Custom log filter programs to log screen entries generated by a specific rule
• Alerts when a complex condition is met
• A single rule to generate different types of alarms for different conditions
Review Questions 1. Why would you need to use user defined tracking? Be specific.
2. Explain how user defined tracking works.
3. What is alertf? How is it used?
4. Under what circumstances would you use user defined tracking in your network? II-2
5. What alert displays if SNMP is not installed in a firewalled network?

78 Review

Unit II — Chapter 3: II-3
SYNDefender
Overview
SYNDefender
Protecting your network is not the same as using shields to protect the starship
Enterprise from an alien attack. There will be people who will want to bring down
your network by attacking it from the inside as well as the outside. If successful, they
will bring down all network communications, leaving you unable to communicate
both externally and internally.
FireWall-1’s SYNDefender component is designed to stop SYN Flood attacks. In this

chapter, we will examine the way SYNDefender protects networks by discussing the
following:
• The TCP/IP three-step handshake
• The SYN flooding attack
• FireWall-1 and SYNDefender Gateway
• FireWall-1 and Passive SYNDefender Gateway
Objectives • Identify the components of a SYN flooding attack

• Understand how attacks occur and their results on networks
• Describe SYNDefender options
• Describe how to apply SYNDefender to a security policy
Keywords • SYN flooding attack

• SYN/ACK
• denial of service
• backlog queue
• SYNDefender
79
80 TCP/IP Three-Step Handshake
TCP/IP Three-Step Handshake
With a normal TCP handshake, a client starts a connection to the server asking for
permission to talk. The server, in return, sends the client an acknowledgment. The
next step from the client is to return that acknowledgment to the server and thus begin
the communication.
Normal Handshake In a normal three-way handshake, both the client and server acknowledge and allow
communications (Figure 49):
I want Server
to talk
1.
SYN
Client
I’m
ready
Server
2.
SYN/ACK
Client
Let’s
go!
Server
3.
ACK
Client
Figure 49: Normal 3-Way TCP Handshake
1 Client initiates a request to the server: “I want to talk.” (SYN)

2 Server replies, “I’m ready.” (SYN/ACK)
3 Client sends acknowledgment to establish connection: “Let’s go!” (ACK)

Unit II — Chapter 3: SYNDefender 81
The SYN Flooding Attack
A SYN flooding attack is a type of attack against a service that is designed to make
the service unavailable. The SYN flooding attack exploits the limitations of TCP/IP
protocols. II-3
Network Attack Figure 50 illustrates a SYN flooding attack that sends multiple SYN requests to a
server:
SYNDefender
Figure 50: SYN Flooding Attack
1 A SYN flood, from the client, puts the server on hold by sending multiple SYN
packets that have spoofed invalid IP addresses.
2 For each SYN packet, the server computer keeps waiting for a response to its
SYN/ACK packet until the connection attempts time out. The backlog queue’s
buffers fill up with the connection attempts and the server becomes unreachable
by legitimate clients.
3 ACK is not received from Client.
The Backlog Queue Each time a SYN packet arrives on a valid port, the packet must be allocated. If there
were no limit, a busy server could easily exhaust all of its memory just trying to
process TCP connections. However, there is an upper limit to the amount of
concurrent connection requests a given connection can have outstanding for a port.
This limit is the backlog queue, which is the length of the queue where incoming
connections are kept. The backlog queue refers to how the server deals with TCP.

82 The SYN Flooding Attack
This queue limit applies to both the number of incomplete connections (the three-way
handshake has not been completed), and the number of completed connections that
have not been pulled from the queue by the application through the accept call.
If this backlog limit is reached, the network server silently discards all incoming
connection requests until the pending connections can be dealt with. The backlog is
not large.
Normally, TCP is quite expedient in establishing connections. Even if a connection

arrives while the queue is full, when the client retransmits its connection request
segment, the receiving TCP will have room again in its queue.

Guidelines for Deploying SYNDefender with FireWall-1
While there are no strict rules for when to use either of the SYNDefender solutions,
some basic guidelines will help you establish the appropriate policy for a given
situation. II-3
Deploying SYNDefender Gateway has two primary advantages:

SYNDefender
1. The first advantage is that users establishing valid connections with a protected
SYNDefender
server will not incur any delay in connection setup time.
2. The second advantage is that there is very little overhead on FireWall-1. However,
since connections are being established on the server, that is, moved from the
backlog queue, it is important to consider how many established connections the
protected server can support relative to the normal load handled by the server.

84 Defending Against SYN Flooding Attacks
Defending Against SYN Flooding Attacks
SYNDefender provides two different defenses against SYN flooding attacks:

• SYDefender Gateway
• SYDefender Passive Gateway
The SYNDefender To set up defenses against SYN attacks, modify the SYNDefender properties screen in
Properties Screen the FireWall-1 Security Policy GUI (Figure 51):
Figure 51: SYNDefender Properties Setup Screen
The following are SYNDefender options:

Method
None — SYNDefender is not deployed.
SYN Gateway — SYNDefender makes the firewall open a connection to the
server, but waits for the ACK from the client before allowing the connection to
take place.
Passive SYN Gateway — SYNDefender allows the connection to the server. If
an ACK is not received within a certain amount of time, FireWall-1 sends a reset
(RST) to the server to terminate the connection.

Timeout — Specifies how long FireWall-1 waits for the ACK from the client before
terminating the connection.
Maximum Sessions — Specifies the maximum number of protected sessions from
one connection. The maximum sessions allowed are the number of pending sessions
FireWall-1 allows from outside a network. If the value is changed, the new value will II-3
not take effect until the security policy is reinstalled.
For Solaris platforms, additional actions must be taken for the new value to take
effect. After the security policy is installed type, the following at the command
prompt:
$FWDIR/bin
SYNDefender
# fwstop
rem_drv fw
sync
add_drv fw
sync
fwstart
Display Warning Messages — Displays warnings to the system’s console in Solaris
and the Event Viewer in Windows NT.
Configuring To configure SYNDefender properties, follow these steps:

SYNDefender
1. Click Policy > Properties from the Security Policy GUI main screen.
2. Click the SYNDefender tab and modify the options, as shown in Figure 51.

86 SYNDefender Gateway
SYNDefender Gateway
FireWall-1 tracks the state of the handshaking process (it does not perform any
handshaking on behalf of the server), and will reset "invalid" connection attempts as
necessary.
FireWall-1’s SYNDefender component translates connection sequence numbers that

are different for each half of a connection. SYNDefender is a high-performance
kernel-level process that acts as a relay mechanism at the connection-level. If
FireWall-1 does not get anything in any of the communication steps for several
seconds, or if it gets a RST when an ACK or a SYN/ACK is expected, it terminates
the connection immediately.
SYN Gateway Figure 52 illustrates how FireWall-1 handles the SYN gateway handshake:
Handshake
Firewall keeps track of handshake

When time expires while waiting for ACK packet, reset packet sent to server to close connection
Clients Servers
SYN
SYN
SYN/ACK
SYN/ACK
Start time
ACK
ACK
End time
if no ACK:
RST (reset)
Figure 52: SYN Gateway Handshake
1 Client attempts to make a connection to the server. FireWall-1 intercepts the SYN
packet and passes it to the server.

2 The server returns a SYN/ACK to the firewall and FireWall-1 sends the SYN/
ACK to the client, starts it’s timer and compares it to the corresponding SYN
packet sent by the client.
3 If the client returns an ACK packet, the firewall allows it through to the server and
the TCP handshake is complete; stopping the timer. II-3
4 If the client does not return and ACK packet, then the firewall will send a RST to
the server after the timeout period.
Passive The Passive SYN Gateway tracks the state of the handshake. The primary difference
SYNDefender
SYNDefender between the two modes is that the Passive SYN Gateway will not “open” the
Gateway connection to the server without receiving the final ACK from the client. This means
connections may open unnecessarily, but they will be reset if SYNDefender does not
see the final ACK packet from the client.
Passive SYN Gateway Handshake

Figure 53 illustrates the passive SYN gateway handshake:
Firewall allows connection to original destination
Waits for the ACK from the source before allowing connection
Clients Servers
SYN SYN
SYN/ACK SYN/ACK
Start time
ACK ACK
End time
if no ACK:
RST (reset)
Figure 53: Passive SYN Gateway Handshake

88 SYNDefender Gateway
1 Client attempts to make a connection to the server. FireWall-1 intercepts the SYN
packet and passes it to the server.
2 The server returns a SYN/ACK to the firewall, allowing the SYN/ACK to pass to
the client.
3 The firewall sends an ACK to the server to complete the TCP handshake, starting
the timer.
4 If the firewall receives an ACK from the client, the connection is complete and the
timer stops.
5 If the firewall does not receive an ACK from the client, it will send a RST to the
server after the timeout period.

Review
Summary The SYN flooding attack is a type of attack on a server that is designed to bring a
server to its knees by flooding it with useless traffic. Such attacks can quickly fill up II-3
the backlog queue, preventing legitimate clients from reaching the server.
SYNDefender provides two defenses against SYN flooding attacks:

• SYDefender Gateway
• SYDefender Passive Gateway
SYNDefender
SYDefender Gateway instructs the firewall to open a connection by sending its own
ACK to a server. The Passive SYN Gateway is similar to the SYNDefender Gateway.
The difference is SYNDefender Passive Gateway makes the firewall wait for a
response to the SYN/ACK before any connection is made to the server.
Review Questions 1. What happens to the backlog queue during a SYN attack?
2. What is the difference between SYNDefender Gateway and SYNDefender

Passive Gateway?
3. What is the server looking for when a client makes a communication attempt?
4. What steps would you need to take if a client’s ACK needs 20 seconds to reach a
firewall?

90 Review

Content Security
Introduction
Content security is a generic process for verifying the content of FTP, HTTP or SMTP
data passed through the firewall. Content security is comprised of FireWall-1’s
Content Vectoring Protocol (CVP) and URI Filtering Protocol (UFP) which
integrate third-party content inspection programs, as well as being implemented at the II-4
firewall without the use of a third-party server.
FireWall-1’s content security may be implemented at the firewall without the use of a
Content Security
content vectoring server. The security server by itself matches certain schemes and
methods that allow HTML weeding and JAVA blocking actions.
Content security is an integral part of the FireWall-1 system. Without it there is limited
protection against malicious intrusions via e-mail, the Web and FTP accesses. Content
security specifies what users cannot download and ensures that what they download is
secure.
FireWall-1’s content security feature allows the administrator to define content

security and enforce it throughout an internal network. Other advantages include the
following:
• Defining content security once
• Distributing content security to multiple firewalled gateways throughout a system
• Screening URLs and blocking suspicious Web data
• Detecting, curing and reporting viruses found in e-mail or files
• Provide auditing capabilities and detailed reports
• Controlling FTP gets and puts
Objectives • List requirements and services affected by content security

• Successfully configure third-party Content Vectoring Protocol (CVP)
• Explain and implement anti-virus inspection to reduce the vulnerability of internal
networks
• Successfully configure Uniform Resource Identifier (URI) content security
• Implement Uniform Resource Locator (URL) filtering
91
92 Introduction
Key Terms • Content Vectoring Protocol (CVP)

• anti-virus inspection
• URL Filtering Protocol (UFP)
• Uniform Resource Locator (URL)
• Uniform Resource Identifier (URI)

Unit II — Chapter 4: Content Security 93
Understanding Content Security II-4
Content Security Content security works by inspecting data at the highest protocol, achieving highly
Content Security
tuned access control to network resources. FireWall-1 provides content security for
HTTP, FTP and SMTP. For each connection established through the security server,
the administrator is able to control specific access according to fields that belong to a
specific service: URLs, file names, PUT/GET (FTP commands), type of requests and
others.
Content security enables intelligent inspection of communications content and

protects users from various hazards, including the following:
• Computer viruses
• Java Applets and ActiveX code
II-4
• Undesirable Web content
When a rule specifies a resource in the service field of the rule base, the FireWall-1
Content Security
Inspection Module diverts all packets in the connection to the corresponding security
server, which performs the required content security inspection. If the connection is
allowed, the security server opens a second connection to the final destination
(Figure 54):
smtp.detroit.com
SMTP
Anti-Virus Server
email.detroit.com
3 Original
2 SMTP Server
Incoming 1 4
SMTP e-mail Recipients on
from Internet Intranet
fw.detroit.com
Figure 54: Anti-Virus Checking of Incoming E-Mail
In Figure 54 the SMTP anti-virus server checks incoming e-mail as follows:

1 Inbound e-mail is received by the SMTP security server on the firewall
fw.detroit.com.
2 SMTP security server sends e-mail to SMTP anti-virus server via CVP.

94 Understanding Content Security
3 After scanning e-mail for viruses, e-mail is passed from the firewall and onto the
SMTP server.
4 The SMTP server receives e-mail and stores it until Intranet users retrieve it.
Security enhancements enabled by the content security feature are anti-virus checking
for files transferred and URL filtering. When a resource specifies anti-virus checking
or URL screening, the security server diverts the connection to one of the following
servers:
Content Vectoring Protocol (CVP) — A CVP server providing anti-virus inspection
for files transferred.
URL Filtering Protocol (UFP) — A server maintaining a list of URL’s and their
categories.

Content Vectoring Protocol (CVP) II-4
CVP uses port 18181 and is designed to reroute data streams (packets) to an external
virus-scanning server. With CVP accessing this server, the security is further enhanced
Content Security
by allowing virus detection capabilities.
In a CVP compliant application, FireWall-1 passes the file to a virus-scanning server

for inspection. This occurs if you specified that a file undergo a virus check before you
allow it to be sent to the client.
Anti-Virus FireWall-1’s content security allows anti-virus inspection, reducing the vulnerability
Inspection of hosts and gateways. With the use of an external anti-virus module or a CVP server,
the anti-virus option checks all files transferred for HTTP, FTP and SMTP protocols.
The configuration, including which files to check and how to handle infected files, is II-4
available for URI, SMTP and FTP resources. Figure 55 illustrates how FireWall-1
CVP allows for virus checking in an FTP connection:
Content Security
4
fw.london.com
3 Files
al FTP
Origin Anti-Virus
FTP ort 18181)
CVP (P
iles Server
Security FTP F
Clean (av.london.com)
Server
5
FTP Client FTP Server
6
(www.detroit.com) 2 (ftp.london.com)
1 1
Port 21: FTP Commands
INSPECT
Engine
Port 20: FTP Data Transfer
2 6
Figure 55: FTP to Anti-Virus Server Process
FireWall-1 implements CVP (in Figure 55) by following these steps:

1 The FTP client establishes a connection via port 21 to the FTP server. The
INSPECT engine monitors port 21 for FTP GET and PUT commands.
2 When the client initiates a data transfer over port 20, the INSPECT engine folds
the connection into the FTP Security Server.
3 The FTP data stream is relayed to the anti-virus server.
4 The anti-virus server scans FTP files for viruses. Logging regarding viruses
found is sent back to the firewall via CVP.
5 The clean FTP file is sent back to the FTP Security Server via CVP.

96 Content Vectoring Protocol (CVP)
6 The FTP Security Server then relays the FTP file on to the FTP server
ftp.london.com.
Implementing Anti-Virus Inspection

Anti-virus checking is implemented by content vectoring servers. To implement anti-
virus inspection, follow these steps:
1. Define a CVP server.
2. Define resource objects that specify anti-virus checking for the relevant protocols.
3. Define rules in the rule base that specify the action taken on connections that
invoke each resource.
The following anti-virus inspection options are available for all resource definitions:
None — No anti-virus checking is performed.
Read only (Check) — A retrieved file is checked for viruses. If the file contains a
virus, it is not retrieved.
Read/Write (Cure) — A retrieved file is checked for viruses. Detected viruses are
removed and the file retrieval continues.

URL Filtering Protocol (UFP) II-4
URL Filtering Protocol (UFP) is a Check Point-developed application programming

interface that enables the integration of third-party applications to categorize and
Content Security
control access to specific URL addresses through the OPSEC security management
framework.
A UFP server is used to specify a list of URLs. A UFP server has a predefined list of
categories, which can be downloaded. You can select individual categories from the
list in the definition of the resource that uses this UFP server.
UFP uses port 18182 and is designed to reroute data streams (packets) to an external
web-scanning server (Figure 56):
II-4
Firewalled gateway
Content Security
Client
Third Party
Content
Security Server Server
FireWall-1
Inspection
Server Module
Figure 56: Simple UFP to Content Server Process
How UFP Works FireWall-1 implements UFP by following these steps:

1 Client invokes connection through the FireWall-1 module.
2 FireWall-1 security server uses UFP to send the third-party content server the
packet to be inspected.
3 The third-party content server inspects the file and returns a Validation Result
message notifying the security server of the result of the inspection.
4 The content server optionally returns a repaired version of the file to the firewall.
5 The firewall takes the action defined for the resource, either allowing or
disallowing the file transfer.

98 Implementing Content Security
Implementing Content Security
To implement content security, follow these steps:

1. Define a network object for the third-party server.
2. Define a UFP/CVP server object for the third-party server.
3. Define a resource that specifies matching and what type of content checking
action.
4. Define rules that specify an action taken for the resource.
HTTP Security The HTTP security server provides Uniform Resource Locator (URL) filtering for
Server control over Web access, allowing administrators to define undesirable Web pages. A
URL is an address format used by Internet communications protocols such as HTTP
and typically identifies the type of service required to access an item, its location on an
Internet host and the file name or item name on that machine. Implement HTTP
security server with a URI resource.
SMTP Security The SMTP protocol provides control over SMTP connections. The SMTP resource
Server definition allows hiding of internal IP addresses from outgoing e-mail, strips specific
attachment types, drops messages above a given size, and rewrites e-mail addresses.
Implement SMTP security server with a SMTP resource.
FTP Security Server The FTP security server provides authentication services and content security based
on FTP commands (PUT/GET), file name restrictions and anti-virus checking for
files. (The PUT command uploads files from a host to an FTP server; the GET
command downloads files from an FTP server to a host.) Implement FTP security
server with a FTP resource.
Java and ActiveX Administrators can control incoming Java and ActiveX code according to specific
Stripping conditions, such as host, URL or authenticated user name.
Capabilities of Java and ActiveX screening include the following:

• Stripping Java applet tags from HTML pages
• Blocking Java attacks by blocking suspicious back connections
• Stripping ActiveX tags from HTML pages
Implement Java and ActiveX Stripping with a URI resource.

CVP and UFP Servers II-4
Servers must be defined before you can use them in content security. To access
Servers, follow these steps:
Content Security
1. Select Servers from the Manage menu.
2. The Servers screen appears (Figure 57):
II-4
Content Security
Figure 57: Servers New Menu

100 CVP and UFP Servers
3. Click New and select the type of server you want to create from the menu (Figure
58):
Figure 58: CVP and UFP Server Properties
4. Define the server and click OK.

Creating a New Resource II-4
A FireWall-1 resource is used in conjunction with content security. FireWall-1

resource specification defines further protocol-specific matching as well as actions to
Content Security
be performed at the protocol specific level in a data packet. You can define FireWall-1
Resources for use with the following protocols: HTTP, FTP and SMTP.
Anti-virus checking, URL screening and e-mail address translations are major security
enhancements enabled by the content security. These options are enforced using UFP
and CVP server objects.
To set up a new Resource, follow these steps:

1. Select Resources from the Manage menu (Figure 59):
II-4
Content Security
Figure 59: Manage Menu
2. The Resources screen appears (Figure 60):
Figure 60: Resources Screen

102 Creating a New Resource
3. Click New and select a resource to create from the menu.

4. Select each tab and complete the fields.
5. Click OK to save your settings.
The resource can now be used in a rule. If the source and destination meet in
a rule, the service must comply with what is outlined in the URI as a match
and action.

Add a Resource to a Rule II-4
To add a resource to a rule after defining your URI, follow these steps:
Content Security
1. Create or select an established rule base.
2. Position the cursor under the Service heading and right-click to display the
shortcut menu (Figure 61):
II-4
Content Security
Figure 61: Rule Base Editor with Shortcut Menu
3. Select Add With Resource and the Service with Resource screen appears (Figure
62). Select the service and resource.
Figure 62: Service with Resource Screen
4. Click OK to save your changes.

104 Add a Resource to a Rule
The new rule base appears (Figure 63). Notice that the Service column displays the
name as defined when the General tab information was entered in the URI definition.
Figure 63: Rule Base with Defined Server

SMTP, HTTP, FTP Content Security II-4
The content security setup is in many ways the same procedure for all services.
Screens in the setup process vary depending on the service being installed.
Content Security
The following sections illustrate the URI/HTTP content security setup.
URI Resource A Uniform Resource Identifier (URI) resource is an extension of the rule base. The
URI goes beyond the source, destination and service fields and provides more details
about the content of the service. HTTP security servers must be installed with default
options for the URI to work.
After creating a CVP or UFP server object if required, you must define the resource
for HTTP to create a URI resource. II-4
Wild Card If you select Wild Cards specification type in the General tab, the following
Content Security
Specification Type information is necessary (Figure 64):
Figure 64: URI General Tab for Wild Cards Specification
Name — Type in the name you want for the URI definition.
Comment — Type in the comment for the URI definition.
Color — Defines the color scheme of the object.
Connection Methods — Check the methods of connection. Your choices are:
Transparent, Proxy and Tunneling.

106 SMTP, HTTP, FTP Content Security
Exception Track — Select the method of reporting. Your choices are: None, Log and
Alert.
URI Match Specification Type — Check the specification type. Your choices are:
Wild Cards, File and UFP.
If you select Wild Cards specification type, the following information is necessary in
the Match tab (Figure 65):
Figure 65: URI Match Tab for Wild Cards Specification
Schemes — Check http and type in a wildcard (*) in the Other text box.
Methods — Type in a wildcard (*) in the Other text box.
Host, Path and Query — Type in wildcards (*) in these text boxes.

If you select Wild Cards specification type, the following action criteria can be II-4
defined in the action tab. Action is what the URI will do if all other criteria are met. In
the Action tab, the following information is necessary (Figure 66):
Content Security
II-4
Content Security
Figure 66: URI Action Tab for Wild Cards Specification
Replacement URI — Type in your alternate IP address to be sent back to any

unauthorized source.
HTML Weeding — Check Strip Script Tags, Strip Applet Tags and Strip ActiveX
tags. This weeds out tags so they are not displayed. If a CVP server is present, the
choice to select the server and the action that the server takes is available.
Response Scanning — Check Block JAVA Code.
CVP — Specify the inspection options for the third-party CVP server.
None — The file is not inspected.
Read Only — The file is inspected by the CVP server. If the CVP server rejects
the file, it is not retrieved.
Read/Write — The file is inspected by the CVP server. If the CVP server detects
that the file is invalid (perhaps because it contains a virus), the CVP server
corrects the file before returning it to the firewall.

File Specification If you select File specification type in the General tab, the following information is
Type necessary (Figure 67):
Figure 67: URI General Tab for File Specification
Alert.

If you select File specification type, the following information is necessary in the II-4
Match tab (Figure 68):
Content Security
II-4
Content Security
Figure 68: URI Match Tab for File Specification
Import — Click to import a URI specification file (a list of URIs to which access will
be denied or allowed, depending on the Action in the rule).
Export — Click to export a previously imported URI specification file. You will be
asked to specify a file name under which the file will be saved.

If you select File specification type, the following action criteria can be defined in the
action tab. Action is what the URI will do if all other criteria are met. In the Action
tab, the following information is necessary (Figure 69):
www.checkpoint.com/warning.html
Figure 69: URI Action Tab for File Specification
Replacement URI — Type in your alternate IP address to be sent back to any


UFP Specification If you select UFP specification type in the General tab, the following information is II-4
Type necessary (Figure 70):
Content Security
II-4
Content Security
Figure 70: URI General Tab for UFP Specification
Alert.

If you select UFP specification type, the following information is necessary in the
Match tab (Figure 71):
Figure 71: URI Match Tab for UFP Specification
UFP Server — Select the UFP server from the menu. The UFP server should have
already been defined in the Servers manager.
Categories — Check the categories you wish to include in the resource definition.
If you select UFP specification type, the following action criteria must be defined in
the Action tab. Action is what the URI will do if all other criteria are met. In the
Action tab, the following information is necessary (Figure 72):
www.checkpoint.com/warning.html
Figure 72: URI Action Tab for UFP Specification

Replacement URI — Type in your alternate IP address to be sent back to any II-4
Content Security
that the file is invalid (for example, it may contain a virus), the CVP server
corrects the file before returning it to the firewall. II-4
SMTP Security The SMTP protocol provides control over SMTP connections. The SMTP resource
Content Security
Server definition allows hiding of internal IP addresses from outgoing e-mail, strips specific
attachment types, drops messages above a given size, and rewrites e-mail addresses.
Implement SMTP security server with a SMTP resource.
In the SMTP General tab, the following information is necessary (Figure 73):
Figure 73: SMTP General Tab screen
Name — The resource’s name.

Comment — Descriptive text.

Mail Server — Mail is forwarded to this server.

Error Handling Server — If Notify Sender on Error is checked, then:
If Error Handling Server is empty, the error notification is sent to the server
specified under default_server in: $FWDIR/conf/smtp.conf.
If default_server in $FWDIR/conf/smtp.conf is not specified, then the error
notification is sent to the originator of the mail.
If Notify Sender on Error is not checked, then no error notification is generated. If
multiple servers are defined, then they are tried until successful.
Exception Track — This option determines if an action taken as a result of a resource
definition is logged. Select one of the following:
None — No logging or alerting.
Alert — Issue and alert.
Notify Sender on Error — Notify the sender if the message was not delivered.
In the SMTP Match tab, the following information is necessary (Figure 74):
Figure 74: SMTP Match Tab screen
Sender — The From field in the envelope.

Recipient — The To field in the envelope.
You may use wild card characters in specifying these fields.

The Action1 tab defines transformations to be performed on the given fields. The data II-4
in the field is modified in accordance with the defined transformation. The left part of
the transformation is a match field. The right part specifies the form of the new
transformed data. In the SMTP Action1 tab, the following information is necessary
Content Security
(Figure 75):
II-4
Content Security
Figure 75: SMTP Action1 Tab screen
Sender — The From field in the header.

Recipient — The To field in the header.
It is recommended that the transformed data not include embedded spaces.
Field — The name of a field in the SMTP header (case-sensitive).

Contents — The contents of the specified field.
Stripping fields such as From and To is discouraged, since it makes it
impossible to deliver the mail message.

In the SMTP Action2 tab, the following information is necessary (Figure 76):
Figure 76: SMTP Action2 Tab screen
Strip MIME of Type — MIME attachments of the specified type will be stripped
from the message. Allowed types are: text, multipart, message, image, audio, video
and application. If you strip MIME of type text, the text in the body of the message is
not stripped.
Don’t Accept Mail Larger Than — Mail messages larger than this size will not be
allowed to pass.
Server — Select the CVP server from the menu. The CVP server should have already
been defined in the Servers manager.
CVP — Select one of the following:
Allowed Characters — Select one of the following:
8 bit — Allow 8 bit ASCII.
7 bit — Allow only 7 bit ASCII (but no control characters).

FTP Security Server The FTP security server provides authentication services and content security based II-4
on FTP commands (PUT/GET), file name restrictions and anti-virus checking for
files. (The PUT command uploads files from a host to an FTP server; the GET
command downloads files from an FTP server to a host.) Implement FTP security
Content Security
server with a FTP resource.
In the FTP General tab, the following information is necessary (Figure 77):
II-4
Content Security
Figure 77: FTP General Tab screen
Name — The resource’s name.

Comment —Descriptive text.
Exception Track — This option determines if an action (specified in the Action tab)
taken as a result of a resource definition is logged. Select one of the following:
None — No logging or alerting.
Alert — Issue an alert.

In the FTP Match tab, the following information is necessary (Figure 78):
Figure 78: FTP Match Tab screen
Path — Full path name of the file.

Methods — Select one of the following:
GET — Getting a file from the server to the client.
PUT — Sending a file from the client to the server.
In the FTP Action tab, the following information is necessary (Figure 79):
Figure 79: FTP Action Tab screen

Server — Select the CVP server from the menu. The CVP server should have already II-4
been defined in the Servers manager.
CVP — Select one of the options:
Content Security
that the file is invalid (for example, because it may contain a virus), the CVP
server corrects the file before returning it to the firewall.
II-4
Content Security

120 RADIUS Server
RADIUS Server
Short for Remote Authentication Dial-In User Service, RADIUS is an authentication

and accounting system used by many Internet Service Providers (ISPs). When you
connect to an ISP, you must enter your username and password. This information is
passed to a RADIUS server, which checks that the information is correct and
authorizes access to the ISP system.
Figure 80 displays the RADIUS Server Properties screen:
Figure 80: RADIUS Server Properties Screen
The RADIUS Server screen contains the following information:

Name — The name of the RADIUS server.
Comment — Any comment for the RADIUS server.
Host — Choose from the menu the host on which the server is running. The host
should have already been defined as a network object.
Priority — When more than one RADIUS server is contacted (when a group of
RADIUS servers or Any is specified for a RADIUS user) then they are contacted in
the sequence defined by their priorities, where a lower number specifies a higher
priority.
Service — Choose from the menu the service for communication with the server. For
RADIUS servers, the service is RADIUS.

Shared Secret — Enter a string of up to 15 nonspace characters to create a shared II-4

secret. A shared secret is a key that authenticates communication between the
firewalled machine and the RADIUS server. You must use the same shared secret you
defined in the clients file on the RADIUS server.
Content Security
Version — Choose from the menu the version of the RADIUS server (either RADIUS
Version 1.0 or Version 2.0).
II-4
Content Security

122 Lab 4: Anti-Virus Checking for Incoming E-Mail
Lab 4: Anti-Virus Checking for Incoming E-Mail
Objective: You will modify the firewall, such that the SMTP security server will
redirect incoming mail to a CVP compliant anti-virus application server. Once the
incoming e-mail has been scanned/disinfected, the firewall will forward the e-mail to
the internal e-mail server.
Scenario: Due to the number of viruses that have come into the company network via
e-mail, you will set up an anti-virus check for incoming e-mail. A new server has been
purchased and it has anti-virus software that is CVP compliant. The name of the CVP
server will be ccheck.yourcity.com. Modify your security policy to implement this
change in business rules.
4Set up the information for the anti-virus server

Add a new workstation object for the anti-virus server:
1. Click Manage > Network Objects > New and specify workstation.
2. Name it ccheck.yourcity.com, with an address appropriate for the lab network.
Add a new server (CVP) for the anti-virus service on ccheck.yourcity.com:

3. Click Manage > Servers > New and specify CVP.
4. Name it Virus_Checker.
5. Give it an appropriate comment and color.
6. In the Host field, pull down and select ccheck.yourcity.com.
7. Make sure that the Service column has FW1_cvp showing.
8.
4Set up e-mail using SMTP security server

Set up e-mail using an SMTP Security Server in the Policy Editor.

Define a new SMTP RESOURCE: II-4

1. Click Manage > Resources > New > SMTP.
2. Give the resource a name like Yourcity_Internet_Email.
Content Security
3. Enter the IP address or name of your internal e-mail server in Mail Server field.
4. Enter the IP address or name of your internal e-mail server in Error Handling
Server field.
5. Next select the Match tab and specify a sender of “*” and a recipient of
*@yourcity.com.
6. Next select the Action2 tab and size limitation on incoming mail to 5 MB.
7. In the CVP box, pull down the Server list and select Virus_Checker.
8. Make sure that the Read/Write button is selected beneath the Server field.
II-4
9. Click OK.
Define a rule that allows any host outside of your network to get to your firewall using
Content Security
the SMTP service with the Yourcity_Internet_Email resource:
10. Click Edit, select Add Rule and then select After.
11. Right-click in the Source column of the new rule and select Add from the menu
that appears.
14. Right-click in the Destination column of the new rule and select Add from the
menu that appears.
object for your firewall and click OK.
16. Right-click in the Service column of the new rule and select Add With Resource
from the menu that appears.
17. A dialog box listing the defined services that have associated resources will
appear. Select SMTP for the Service and select the Yourcity_Internet_Email
Resource in the Resource box. Click OK.
18. Right-click in the Action column of the new rule and select Accept from the menu
that appears.
19. Right-click in the Track column of the new rule and select Long from the menu
that appears.
rule in the text box that appears. Then click OK.

124 Lab 4: Anti-Virus Checking for Incoming E-Mail
4Allow your firewall to connect to internal e-mail

Define a rule that allows your firewall to get to your internal e-mail server using
SMTP:
that appears.
object for your firewall and then click OK.
menu that appears.
object for your e-mail server and click OK.
6. Right-click in the Service column of the new rule and select Add from the menu
that appears.
7. A dialog box listing the defined services will appear. Select SMTP. Click OK.
that appears.
that appears.
4Allow your internal e-mail server to connect to external hosts

Define a rule that allows your internal e-mail server to get to any host outside of your
network using the SMTP service:
that appears.
object for your e-mail server and then click OK.
4. Right-click in the Service column of the new rule and select Add from the menu
that appears.
5. A dialog box listing the defined services will appear. Select SMTP. Click OK.
that appears.

7. Right-click in the Track column of the new rule and select Long from the menu II-4
that appears.
Content Security
4Log attempts on internal e-mail
Define a rule that logs any attempts on your internal e-mail server from any host
outside of your network using any protocol/service:
that appears.
object for your local network and then click OK. II-4
Content Security
menu that appears.
object for your e-mail server and click OK.
7. Right-click in the Action column of the new rule and select Drop from the menu
that appears.
that appears.
4Verify and install the policy

For Internet e-mail to be directed to your firewall, it may be necessary to
have the DNS MX record for your external Internet domain name pointing to
your firewall. The DNS MX record tells SMTP servers where to direct email
for your domain. Since the firewall will be acting as a relay, all Internet
SMTP servers with mail for your domain should send it to the firewall.

126 Lab 5: URL Blocking for HTTP
Lab 5: URL Blocking for HTTP
Objective: You will modify the firewall to make use of a UFP server to block Web
browser access to adult sites on the Internet/World Wide Web.
Scenario: Management wants to block Web browser access to adult sites on the
Internet. Your company has purchased UFP type software and has loaded it onto
ccheck.yourcity.com. Use an HTTP resource check for attempted access to the
restricted sites. Also, if access is attempted, redirect the user’s browser to an internal
Web page that presents a warning.
If you are not able to perform this lab, then this becomes a discussion lab.
4Set up the information for the UFP server

Since the UFP software has been loaded on ccheck.yourcity.com, we will not need to
define a new workstation object for the UFP Server.
1. Add a new server (UFP) for the UFP service on ccheck.yourcity.com.
2. Click Manage > Servers > New and specify UFP.
3. Name it URL_Checker.
4. Give it an appropriate comment and color.
5. In the Host field, pull down and select ccheck.yourcity.com.
6. Make sure that the Service column has FW1_ufp showing.
4Define a new HTTP Resource

1. Click Manage > Resources > New > URI.
2. Give the resource a name like Adult_filter.
3. Select UFP for a URI Match Specification Type.
4. Select the Match tab and pull down the UFP Server list and select URL_Checker.
5. Select the Action tab.
6. In the Replacement Uri field, put the following value: HTTP://www.yourcity.com/
messages/adult_warning.html.
7. Click OK.

4Use the HTTP service with the Adult_filter resource II-4

Add or modify a rule that allows any host on your internal network to get to hosts
outside your network using the HTTP service with the Adult_filter resource. The
Action column should have Reject:
Content Security
1. Click Edit, select Add Rule and then select Top.
that appears.
object for your local network (net-yourcity) and then click OK.
menu that appears.
object for your local network (net-yourcity) and click OK. II-4
7. Right-click in the Service column of the new rule and select Add With Resource
Content Security
8. A dialog box listing the defined services that have associated resources will
appear. Select HTTP. Click OK.
9. In the Resource section, select HTTP for the Service and select the Adult_filter
Resource in the Resource box.
10. Right-click in the Action column of the new rule and select Reject from the menu
that appears.
that appears.
4Verify and install the policy

128 Lab 6: URL Screening by Wildcard
Lab 6: URL Screening by Wildcard
browser access to adult sites on the Internet/World Wide Web.
4Create a URI resource

Create a URI resource named “badweb”:
1. Open the Resource Manager and create a new URI resource from the New menu.
2. In the name field of the General tab, type badweb.
3. In the URI Match Specification Type field, click Wildcard.
4. Click the Match tab:
Schemes: http
Methods: GET, POST and PUT
Host: www.boogeyman.com
Path: /warez/illegal.html
Query: * (asterisk)
5. Click the Action tab.
6. In the Replacement URI field, type: http://www.yourcity.com/bad.html.
4Define a URL screening rule

Add a new rule to the top of the rule base:
Source: Any
Destination: Any
Service: http->badweb
Action: reject

4Verify and install the security policy II-4

1. Install the new security policy.
2. Remove your HTTP authentication rule, and replace it with an anything outbound
Content Security
rule.
3. Test by connecting to www.boogeyman.com.
4. Click the Warez link. What is the result?
II-4
Content Security

130 Lab 7: FTP Content Security
Lab 7: FTP Content Security
Objective: You will modify the firewall to make use of a UFP server to restrict access
to FTP sites on the Internet/World Wide Web.
ccheck.yourcity.com. Use an HTTP resource check for attempted access to the FTP
sites.
4Create an FTP resource

Create an FTP resource named “get-only”:
1. Open the Resource Manager.
2. Create a new Resource of type FTP. The FTP Definition screen appears.
3. In the Name field of the General tab, type get-only.
4. Click the Match tab.
5. In the Path field, type * (asterisk); for Methods, click the GET check box only.
6. Click OK at the bottom of the FTP Definition screen.
4Define an FTP GET only rule

Source: net-yourcity
Service: Add With Resource
FTP: Service
Resource: get-only
Action: Accept
4Verify and install the security policy
4Test the security policy

Test by authentication for FTP to www.boogeyman.com:

Username: student II-4

Password: fw1
1. Get the file private.txt. Did it work?
Content Security
2. Try to put a file on www.boogeyman.com. Did it work?
II-4
Content Security

132 Lab 8: Java Blocking
Lab 8: Java Blocking
browser access to java applets on the Internet/World Wide Web.
Scenario: Management wants to block Web browser access to java applets on the
ccheck.yourcity.com. Use an HTTP resource check to filter java applets.

Create a URI resource named “decaf”:
1. Open the Resource Manager and create a new URI resource from the New menu:
Name: decaf
URI Header Specification Type: Wildcard
Schemes: http
Host: * (asterisk)
Path: *
Query: *
3. Click the Action tab:
Response Scanning: Block JAVA Code
HTML Weeding: Strip Script Tags and Strip Applet Tags
4. Click OK.
4Block Java in the rule base

Add a new rule to the top of your rule base:
Service: Add With Resource — http (service), decaf (Resource)
Action: accept

4Verify and install the rule base II-4
4Test Java blocking
Content Security
Connect to www.boogeyman.com and select the Java link.
II-4
Content Security

134 Lab 9: URL Screening by File
Lab 9: URL Screening by File
browser access to restricted sites on the Internet/World Wide Web.
Scenario: Management wants to block Web browser access to restricted sites on the

Create a URI resource named “badweb2”:
1. Open the Resource Manager and create a new URI resource from the New menu.
2. In the name field of the General tab, type badweb2.
3. In the URI Match Specification Type field, click UFP.
Schemes: http
Host: www.boogeyman.com
Path: /warez/illegal.html
Query: * (asterisk)
5. Click the Action tab.
6. In the Replacement URI field, type http://www.yourcity.com/bad.html.
4Define a URL screening rule

Source: Any
Destination: Any
Service: http->badweb2
Action: reject

4Verify and install the security policy II-4

Content Security
4Test the security policy
1. Remove your HTTP authentication rule, and replace it with an anything outbound
rule.
2. Test by connecting to www.boogeyman.com.
3. Press the Warez link. What is the result?
II-4
Content Security

136 Review
Review
Summary Content security is necessary in a firewalled system, because without it, internal
networks have limited protection against external attacks. Content security allows
system administrators to specify what can and cannot enter or exit internal networks.
Content security works by inspecting data at the highest protocol. And content
security allows administrators to control network access according to specified
services, such as anti-virus applications.
Content security works by inspecting data at the highest protocol, achieving highly
tuned access control to network resources. FireWall-1 provides content security for
HTTP, FTP and SMTP. Content security enables intelligent inspection of
communications content and protects users from various hazards, including the
following:
• Computer viruses
• Java Applets and ActiveX code
• Undesirable Web content
Review Questions 1. What is content security?
2. From which types of hazards does content security protect internal networks?
3. Can you use FireWall-1’s content vectoring protocol without the use of a content
vectoring server? Why or why not?
4. What are the steps for setting up anti-virus inspection?

5. What does URL filtering provide? II-4
Content Security
II-4
Content Security

138 Review

Unit 3 — FireWall-1 Encryption
Chapter 1: Encryption and Virtual Private Networks
Chapter 2: Encryption Schemes
Chapter 3: SecuRemote

II-4

Encryption and Virtual
Private Networks
Introduction
Overview Encryption is a method of modifying packet data so that the data can only be
decrypted with an encryption key. You can use FW-1 to build VPN’s, which provides
secure communications between two defined participants by encrypting packets
across the Internet. FireWall-1’s encryption works through the use of four encryption
schemes: FWZ, Manual IPSec, ISAKMP/Oakley (IKE) and SKIP.
In addition to these encryption schemes, security engineers can use SecuRemote to

protect communications through VPNs. SecuRemote enables mobile and remote
Windows 95 or NT users to connect to their enterprise networks through dial-up
Internet connections. Users connect either directly to the server or through Internet
Service Providers, and communicate sensitive corporate data as safely and securely as
from behind the corporate Internet firewall. FireWall-1 SecuRemote extends the VPN
to the desktop and portable computer.
Objectives • Explain why encryption is important for a virtual private network

• Be able to define shared secret key
• Compare and contrast asymmetric and symmetric encryption
III-1
• Explain the difference between encrypting packet header versus data
• Compare and contrast tunneling versus in-place encryption
Encryption and VPNs

• Define certificate authority
• Discuss how to set up a VPN between two networks
• Discuss how VPNs allow security engineers to manage firewalled networks
remotely
141
142
Key Terms • encryption

• virtual private network (VPN)
• encrypt
• plaintext
• ciphertext
• decrypt
• key
• shared secret key
• tunneling-mode encryption
• in-place mode encryption
• asymmetric (public-key) encryption
• symmetric (shared-key) encryption
• digital signature
• public key cryptography
• public-key infrastructure
• certificate authority

Unit III — Chapter 1: Encryption and Virtual Private Networks 143
How Encryption Works II-4
decrypted with an encryption key. You use encryption with FireWall-1 through a
virtual private network (VPN). A VPN provides secured connections between points
where encrypted data may travel through the Internet.
Encryption
Encryption works by encrypting data with encryption software and a secret key, which
is known only to the recipient and those VPNs authorized to view the data. This
shared secret key is used to verify and decrypt the encrypted packet.
Figure 81 is an example of encryption using symmetric encryption:
Figure 81: How Encryption Works
1 The original data (cleartext) is passed through an encryption algorithm that uses
the secret key to uniquely scramble the data.
2 The result is called ciphertext.
3 The VPN receives the cipher text and uses a secret key to decrypt the text.
Virtual Private Encryption in a VPN provides secured connections between points where encrypted
Networks (VPNs) data travels along unsecured portions of a network. A VPN typically uses the Internet
as the transport backbone to establish secure links with business partners, extend
communications to regional and isolated offices, and significantly decrease the cost of III-1
communications for an increasingly mobile workforce.
In FireWall-1 there are two types of VPNs:

Encryption and VPNs
Firewall-to-Firewall VPN — Using FWZ, Manual IPSec, ISKAMP/Oakley (IKE)
and SKIP encryption schemes.
Client-to-Firewall VPN — Using FireWall-1 SecuRemote.

144 How Encryption Works
The typical setup for a VPN, includes the following:

• Internal network VPNs between internal corporate departments and branch offices
• Remote access VPNs between a corporation and remote or mobile employees
• External network VPNs between a corporation and its partners, customers and
suppliers
Firewall-to-Firewall FireWall-1 VPNs support the following encryption schemes. These encryption
VPN schemes are security engineers’ tools for creating and configuring VPNs:
• FWZ
• Manual IPSec
• ISAKMP/Oakley (IKE)
• SKIP
As shown in Figure 82, data traveling from the Detroit network to the Chicago
network is encrypted. (Data arriving from protected networks is authenticated and
then decrypted.)
FireWall-1 encrypts data between firewalls that protect each encryption

domain.
Firewall Firewall
Module Module
#1 #2
Not Encrypted Encrypted Not Encrypted

Payroll Sales
PRIVATE PUBLIC PRIVATE
Figure 82: VPN Example
Client-to-Firewall FireWall-1 SecuRemote, which is a separate Check Point product and is based on a
VPN (SecuRemote) technology called client encryption, allows remote network users secure access to
their internal networks. This is called client-to-firewall VPN encryption and is used
for remote access. Using SecuRemote is not the same as managing a network
remotely.
SecuRemote does the following:

• Encrypts data before it leaves a remote computer
• Transparently encrypts any TCP/IP communications

• Interfaces with any existing adapter and TCP/IP stack II-4

• Enables access for FireWall-1 SecuRemote users through the rule base editor
• Enforces security features, including authentication servers, logging and alerts, on
FireWall-1 SecuRemote connections
• Includes support for dynamic IP addressing, necessary for dial up communication
• Includes stronger authentication using Diffie-Hellman and RSA algorithms, as
Encryption
well as strong encryption using FWZ-1 and DES
A Note about SecuRemote Configuration

SecuRemote requires that a VPN be configured so that both of the following
conditions are true:
• The encryption domains of all SecuRemote users in the VPN do not overlap,
that is, no host is included in more than one encryption domain
• If there is more than one firewalled computer along the path from a
SecuRemote client to its destination, only one of the firewalls can be a
SecuRemote server
Figure 83 illustrates how SecuRemote allows a remote user to access their network:
1 SecuRemote user logs on to the firewalled gateway;

SecuRemote Client is installed on the laptop
2 Firewall allows client connection and decrypts communication

3 Firewall passes the connection to the destination
Firewalled Gateway SecuRemote

Client Installed
III-1
Encryption and VPNs

Figure 83: SecuRemote User Connecting to Firewalled Network
In Figure 83 the following happens:

1 The SecuRemote user logs on to the firewalled gateway. SecuRemote Client is
installed on the end user’s portable computer.
2 The firewall allows the user’s connection and decrypts their communication.

146 How Encryption Works
SecuRemote encrypts and decrypts depending on the communication

direction.
3 The firewall passes the connection to the destination computer.
FireWall-1 FWZ
Encryption FWZ is Check Point’s proprietary encryption scheme, which utilizes both asymmetric
Schemes and symmetric keys during key management and encryption. FWZ manages
encryption keys automatically, including updating public keys.
Manual IPSec
Short for IP Security, IPSec (and Manual IPSec) is a set of protocols that supports
secure exchange of packets at the IP layer. For IPsec to work, the sending and
receiving devices must decide upon a unique public key and then manually generate
that key.
ISAKMP/Oakley (IKE)
Internet Security Association and Key Management Protocol (ISAKMP) —
otherwise known as IKE (Internet Key Exchange) — is the encryption standard of the
Internet Engineering Task Force (IETF), the main standards organization for the
Internet. The ISAKMP protocol provides a consistent framework for transferring key
and authentication data, independent of the encryption and authentication
mechanisms.
Oakley (IKE) is an Internet encryption protocol that enables two authenticated parties
to agree on secure and secret keying material. The basic mechanism is the Diffie-
Hellman key exchange algorithm, where one firewall’s public key and another
firewall’s private key creates a shared secret key. The Oakley protocol supports
compatibility with the ISAKMP protocol for encryption.
SKIP
Simple Key Management for Internet Protocols (SKIP) provides a hierarchy of keys
that change over time. These keys are used to encrypt connections as well as to
implement a key management protocol. SKIP also includes ESP and AH and adds its
own header to packets. ESP and AH are: The protocol formats for the IP
Authentication Header (AH) and IP Encapsulating Security Payload (ESP) will be
independent of the cryptographic algorithm. The preliminary goals will specifically
pursue host-to-host security followed by subnet-to-subnet and host-to-subnet
topologies.

FireWall-1 Encryption Algorithms II-4
Overview The encryption schemes discussed earlier include Manual IPSec, SKIP, FWZ and
ISAKMP/Oakley (IKE). FireWall-1 security engineers set up these encryption
schemes. Encryption algorithms are FireWall-1’s way of determining how to encrypt
data.
Encryption
FireWall-1 supports the following encryption algorithms:
• FWZ-1
• DES
• Triple DES
• DES-40 (bit), RC2-40, RC4-40
International FireWall-1 security engineers must read the DES section in

this chapter to understand licensing implications.
FWZ-1 FWZ-1 is Check Point’s proprietary symmetric encryption algorithm. FWZ-1

manages key encryption automatically, including updating public keys, since FWZ-1
is a shared-key scheme. The FWZ-1 algorithm does the following:
• Encrypts all data behind the IP and TCP headers (Figure 89 on page 157)
• Uses reliable-data protocol (RDP) to manage VPN session keys, encryption
methods and data integrity
• Uses in-place encryption (Figure 91 on page 157)
• Gets certified Diffie-Hellman public keys from a trusted certificate authority,
which is a trusted third party from whom a public key can be obtained reliably
• Supports FWZ-1 encryption, using a 40-bit encryption key, that is exportable
outside the U.S. III-1
FireWall-1 S/Key authentication uses the FWZ-1 scheme to authenticate
Encryption and VPNs

passwords. Each time a connection is made to the firewall, S/Key
authentication requires a different password. S/Key authentication is
based on a table of 100 random passwords. Once one table of passwords
is complete, S/Key generates a new table. In this way, encryption is
secure.

148 FireWall-1 Encryption Algorithms
DES (International Short for Data Encryption Standard, DES (and Triple DES) is a symmetric key
Customers) encryption method that uses a 56-bit key and is illegal to export out of the United
States or Canada. DES allows interoperability with other ISAKMP and SKIP
compliant firewalls, and provides one standard for encryption.
Triple DES addresses security concerns resulting from its relatively short, 56-bit key
length. Triple DES encrypts under three different DES keys in succession, equivalent
to doubling the DES key length to 112 bits.
Four Encryption FireWall-1 offers four levels of encryption, including Triple DES (Table 4):
Levels
Table 4: Four Levels of Encryption in FireWall-1 Version 4.0
Level Encryption
Locations Allowed
Algorithms
1. None None Anywhere
2. VPN FWZ-1, DES-40, Most of the world’s countries

RC2-40, RC4-40a
3. VPN+DES DES, plus VPN To financial institutions throughout most

countries of the world; other customers
with special permits
4. Strong Triple DES United States and Canada

(3DES), plus
VPN+DES
a. The “40” in these algorithms refers to 40 bits.

Encryption Technologies II-4
Overview FireWall-1 supports the following encryption technologies:

• Asymmetric and symmetric encryption
• Diffie-Hellman key management
Encryption
• Digital signatures
Symmetric Symmetric encryption, in which the same key is used to encrypt and decrypt data, is
Encryption (Shared also called shared key encryption. Symmetric encryption is used primarily for faster
Key) encryption performance. An example of symmetric encryption is shown in Figure 84:
Figure 84: Symmetric Encryption
1 The cleartext message is encrypted using the shared key.

2 The encrypted packet passes through the insecure network.
3 On the gateway on the other side, the same shared key is used to decrypt the
ciphertext.
III-1
Symmetric Encryption Issues
Because symmetric encryption uses one shared key, you must consider the following
issues before implementing symmetric encryption in FireWall-1:
• Keys must be kept secret Encryption and VPNs
• Keys should be changed periodically
• In large environments, key generation, distribution and protection become more
complex (4,950 keys for 100 nodes, for example)
• Sharing secret keys between VPN partners is inherently insecure

150 Encryption Technologies
Do not send private keys through unsecured networks, such as the Internet.
Use “sneaker-net”: Mail, fax or phone the private key to a certificate
authority.
Asymmetric Asymmetric encryption, which uses one key to encrypt a message and another to
Encryption (Public decrypt the message, is a FireWall-1 encryption technology used for the following:
Key)
• Secure key exchange mechanisms
• Authentication
• Data-integrity checking
Asymmetric encryption is called public-key encryption, because the encryption
scheme uses two keys: one private and one public. These keys are created using the
Diffie-Hellman key scheme, where one firewall’s public key and another firewall’s
private key creates a shared secret key. This shared secret key is used to verify and
decrypt the encrypted packet. It is mathematically impossible to derive the private key
from the public key.
Figure 85 demonstrates asymmetric encryption as follows:
Figure 85: Diffie-Hellman Encryption

1 The Detroit firewall sends its public key to the Chicago firewall. The Chicago II-4
key shares the same public key.
2 The private key is combined with the receiver’s public key, using the Diffie-
Hellman algorithm to generate the shared secret key.
3 Encryption is secure because no one, except Detroit and Chicago, can derive the
shared secret key.
Encryption
Due to performance issues, asymmetric cryptography, which is 1,000
times slower than symmetric cryptography, is typically used to encrypt
small amounts of data, such as keys, for symmetric cryptography.
III-1
Encryption and VPNs

152 Digital Signatures
Digital Signatures
Definitions Digital Signature

A digital signature is a code that can be attached to an electronically transmitted
message that uniquely identifies the sender. Like a written signature, the purpose of a
digital signature is to guarantee that the individual sending the message really is who
they claim to be. Digital signatures are especially important for electronic commerce
and are a key component of most authentication schemes. To be effective, digital
signatures must be unforgeable.
Digital signatures use public key cryptography, which uses two different but
mathematically related keys: the first key is used to encrypt the data, and the second
key is used to verify the signature or decrypt the data. The process is similar to
assymetric cryptography.
Hash Functions
Hash functions are used to create and verify digital signatures. A hash function is an
algorithm that creates a digital representation or "fingerprint" in the form of a "hash
value" or "hash result" of a standard length. The hash value is usually much smaller
than the message but nevertheless substantially unique to it. If any changes to a
message occur, the hash result will be different, indicating the message has been
tampered with.
In the case of a secure hash function, also called a one-way hash function, it is
mathematically infeasible to derive the original message from the resulting hash
value.
Using Digital The use of digital signatures usually involves two processes, one performed by the
Signatures signer and the other by the receiver of the digital signature:
1. Digital signature creation uses a hash result derived from and unique to both the
signed message and a given private key. For the hash result to be secure, there
must be only a negligible possibility that the same digital signature could be
created by the combination of any other message or private key.
2. Digital signature verification is the process of checking a digital signature by
reference to an original message and a given public key, thereby determining
whether the digital signature was created for that same message using the private
key that corresponds to the referenced public key.

Creating the Digital A digital key is created using the one way hash function, as follows: II-4
Signature
1 The original message is created (Figure 86):
Encryption
Figure 86: One Way Hash Function
2 The result is a cryptographic function that receives a variable length message as

input and generates a fixed-size hash.
The benefits of using the one way hash function are as follows:
• Easy to compute and irreversible
• Combined with the sender’s private key, the message digest becomes the digital
signature
• Also used for providing data integrity
Examples: MD4 (128 bits), MD5 (128 bits), SHA-1 (160 bits)
Applying Digital A digital signature is applied to a document or other information, using the following
Signatures/ process (Figure 87 on page 154):
Certificates
1 The signer delimits the borders of what is to be signed (the document) using their
private key.
2 The signer’s software using the hash function computes a unique hash result.
3 The signer’s software transforms the hash result into a digital signature, which is
unique to both the document and the private key used to generate it.
4 The digital signature is verified using the hash function of the software used to III-1
create the digital signature.
5 The verifier uses the public key to verify:
a. Whether the digital signature was created using the associated private key Encryption and VPNs
b. Whether the newly computed hash result matches the original hash result
6 If both hash results match, then the digital signature is verified as authentic.

154 Digital Signatures
Figure 87: Applying Digital Signatures to Certificates

Certificate Authority II-4
A certificate authority (CA) is a trusted third party from whom a public key can be
obtained reliably, even via the Internet. The CA certifies a public key by generating a
certificate. The digital signature acts as proof of the sender’s identity. A digital
signature is created using a public encryption key scheme.
Encryption
Manual IPSec is the only encryption scheme that does not use a CA.
The following lists the actions taken by a CA:

1. A sender sends their public key to a CA in a secure manner.
2. The CA signs the public key with its own private key.
3. The CA sends its public key to a receiver.
4. The receiver uses the CA’s public key, which was received by other means, to
verify the signature on the sender’s public key.
The CA and DH When you configure encryption for a network object, you must choose to generate a
Keys certificate authority (CA) or Diffie-Hellman (DH) key. In public-key encryption, keys
are created using the Diffie-Hellman key scheme, where one firewall’s public key and
another firewall’s private key creates a shared secret key. This shared secret key is
used to verify and decrypt the encrypted packet.
Creating the CA Key To create a CA key, security engineers must modify options in the following screens
and tabs. These screens and tabs are located within the Workstation Properties screen:
• Encryption tab
• CA Key tab
III-1
• Certificate Authority Key screen
Encryption and VPNs

156 What to Encrypt?
What to Encrypt?
Packet Headers Before encrypting data, it is important to understand what part of a packet to encrypt.
Versus Data Figure 88 displays the IP header being encrypted. The IPSec encryption scheme adds
a new IPSec and IP header to a packet. IPSec encrypts the new headers while
authenticating the IP and TCP header and packet data.
New Header New IPSec Header IP Header TCP Header Packet Data
Figure 88: Encrypted IP Header
Figure 89 displays the data being encrypted, not the IP header. This means the IP and
TCP headers within the packet will not be encrypted. Therefore, the packet will be
able to reach its destination. Only the data is encrypted.
New New IPSEC IP TCP Packet

Header Header Header Header Data
Figure 89: Encrypted Data
Tunneling-Mode FireWall-1 uses two encryption modes, depending upon the encryption scheme
Versus In-Place chosen: tunneling-mode and in-place encryption (Table 5 on page 158).
Encryption

Tunneling-mode encryption works by encrypting a packet, then encapsulating the II-4

packet within the encryption protocol header. Tunneling-mode encryption does this by
embedding its own network protocol within a packet’s TCP/IP headers. You can
envision tunneling-mode encryption as follows:
1. You write a message and place it in an envelope (packet).
2. You address the outside of the envelope (packet) with the destination address and
the return address.
Encryption
3. You then place the addressed envelope (packet) into an another envelope that
contains a different destination address and return address.
4. The envelope is then mailed.
A drawback to using tunneling-mode encryption is that packet size is increased since
you have encapsulated the original packet with the decryption protocol header;
however, the security of the packet is increased (Figure 90):
IP HEADER TCP HEADER DATA
ENCRYPTION PROTOCOL HEADER sdfklj98a475$
Figure 90: Tunneling-Mode Encryption
In-place encryption encrypts the payload portion of the packet and leaves the header
intact (Figure 91). This allows for greater performance than that provided by Manual
IPSec, ISAKMP/Oakley (IKE) or SKIP encryption.
III-1
Encryption and VPNs
Figure 91: In-Place Encryption

A drawback to using in-place encryption is the header remains intact, indicating the
origin IP address and destination IP address; however, there is no performance
degradation since the packet size has not changed.
Difference Between Tunneling and In-Place Modes

Table 5 lists the differences between tunneling-mode and in-place encryption:
Table 5: Tunneling and In-Place Mode
Tunneling-Mode In-Place Mode

Encryption Encryption
Supports all Only supports the FWZ-1
algorithms except algorithm
FWZ-1
Encrypts IP and TCP Does not encrypt IP and

headers TCP/UDP headers
Adds new IP (first) Does not increase packet

header and IPSec size
(second) header in a
packet
Can be used in VPNs Cannot be used in VPNs

that use illegal/ with illegal/reserved IP
reserved IP addresses
addresses without
needing address
translation or proxying

The Encryption Tab II-4

In the Encryption tab, security engineers select an encryption method and domain
(Figure 92):
Encryption
Figure 92: The Encryption Tab
The encryption options are as follows:

Encryption Methods Defined — Encryption schemes defined for a device.
Encryption Domain — A network object (usually a network or domain) for which
this gateway performs encryption.
The encryption domain is defined as those network objects that are to

participate in the VPN.
III-1
Encryption and VPNs

The CA Key Tab

After selecting an encryption method, security engineers must edit that method’s
properties in the CA Key tab (Figure 93):
Figure 93: FWZ Properties — CA Key Tab
The CA key options are as follows:

Local/Remote — Specifies whether the certificate authority resides on the firewalled
device or some other object in the internal network:
Local — Using FWZ encryption, the CA is the management station of the
firewall.
Remote — The remote firewalled device is the certificate authority.
Generate — Creates the CA’s key or replace its existing key (available when CA is
local).
Get — Gets the remote device’s Diffie-Hellman key from its CA (available when CA
is remote).

The Certificate Authority Key Screen II-4

Once the CA key has been generated, exponent and modulus appear in the Certificate
Authority Key screen (Figure 94):
Encryption
Figure 94: Generated CA Key
The Certificate Authority Key selections are as follows:

KeyID — A cryptographic checksum of the public key (useful for out-of-band
verification).
Date — The date and time the key was generated.
Exponent and Modulus — Read only fields that make up the actual public key.
Creating a CA Key
The following are the steps for creating a CA Key: III-1
1. Click Manage > Network Objects from the FireWall-1 Security Policy main
menu.
2. Highlight the firewalled device to which you want to add the certificate authority. Encryption and VPNs
Click Edit.
3. Click the Encryption tab.
4. Click Other under Encryption Domain and select the network to be encrypted.
5. Click the encryption method defined and click Edit. The CA Key tab displays
(Figure 93 on page 160).

Creating the DH Key To create a DH key, security engineers must modify options in the following screens
and tabs. These screens and tabs are located within the Workstation Properties screen:
• Encryption tab
• DH Key tab
• Diffie-Hellman Key screen
The Encryption Tab

In the Encryption tab, security engineers select an encryption method and domain
(Figure 95):
The encryption options are as follows:

Encryption Methods Defined — Encryption schemes defined for a device.
this gateway performs encryption.
The encryption domain is defined as those network objects that are to

participate in the VPN.

The DH Key Tab II-4

After selecting an encryption method, security engineers must edit that method’s
properties in the DH Key tab (Figure 96):
Encryption
Figure 96: DH Key Tab
The DH key options are as follows:

Local/Remote — Specifies whether the certificate authority resides on the firewalled
device or some other object in the internal network:
Local — Using FWZ encryption, the CA is the management station of the
firewall.
Remote — The remote firewalled device is the certificate authority.
Generate — Creates the CA’s key or replace its existing key (available when CA is III-1
local).
Get — Gets the remote device’s Diffie-Hellman key from its CA (available when CA
Encryption and VPNs

is remote).

The Diffie-Hellman Key Screen

Once the DH key has been generated, exponent and modulus display in the Diffie-
Hellman Key screen (Figure 94):
Figure 97: Certificate Authority Key Screen
The Diffie-Hellman Key selections are as follows:

KeyID — A cryptographic checksum of the public key (useful for out-of-band
verification).
Exponent and Modulus — Read only fields that make up the actual public key.
Creating a DH Key
The following are the steps for creating a DH Key:
1. Click Manage > Network Objects from the FireWall-1 Security Policy main
menu.
2. Highlight the firewalled device to which you want to add the certificate authority.
Click Edit.
4. Click Other under Encryption Domain and select the network to be encrypted.
5. Click the encryption method defined and click Edit. The DH Key tab displays

Review II-4
Summary For a more secure network over an insecure Internet, encryption is a vital part of
communication. Encryption is FireWall-1’s technology for modifying packet data so
that the data can only be decrypted with an encryption key, which decrypts encrypted
data. Encryption allows communication via a virtual private network (VPN), which is
Encryption
a private network that provides secured connections between points where encrypted
data travels through the Internet. Encryption works by passing data via a shared secret
key. This key decrypts data so that the receiver can view the data. It is important that
data be encrypted but not the packet header; otherwise, the packet cannot reach its
destination.
FireWall-1 uses two encryption modes, depending upon the encryption scheme
chosen: tunneling-mode and in-place encryption. Tunneling-mode encryption works
by encapsulating a network protocol within packets carried by a second network.
Tunneling-mode encryption does this by embedding its own network protocol within a
packet’s TCP/IP headers. In-place encryption encrypts just the data portion of the
packet, leaving the original IPSEC and IP headers intact. This allows for greater
performance than that provided by the other encryption algorithms since it does not
cause packet fragmentation.
VPNs provide a way to secure data traveling from internal to external networks safely.
You can remotely manage a firewall through a VPN, as well as communicate using
Check Point’s SecuRemote application in conjunction with a VPN. You also set up a
VPN between two networks, using SKIP encryption.
Review Questions 1. Why is encrypting the data better than encrypting the packet header?
III-1
2. What is a shared key used for?
Encryption and VPNs
3. Explain how encryption secures a virtual private network?

166 Review
4. What is the difference between tunneling mode and in-place encryption? Which is
best?
5. How are asymmetric and symmetric encryption different? Which is best?
6. What are the steps for generating a certificate authority?

II-4
Encryption Schemes
Encryption Schemes
Introduction
Overview FireWall-1’s encryption works through the use of four encryption schemes: FWZ,
Manual IPSec, ISAKMP/Oakley (IKE) and SKIP. FireWall-1’s SecuRemote product
is another way for security engineers to ensure that remote communications traveling
through unsecured lines are encrypted.
Objectives • List FireWall-1’s four encryption schemes

• Demonstrate how to configure the encryption schemes applicable to your network
• Discuss how to set up a VPN between two networks
Key Terms • public key cryptography

• public-key infrastructure
• encryption algorithms
167
168 FireWall-1 Encryption Schemes
FireWall-1 Encryption Schemes
Overview In this section you will learn how FireWall-1 incorporates the concepts described
previously to define the four encryption schemes it supports. You will learn specifics
about how these schemes relate to VPNs. And you will configure and test each of
these schemes to understand how FireWall-1 VPNs work.
As previously discussed, FireWall-1 supports four encryption schemes. Table 6

displays the FireWall-1 encryption schemes, with a brief definition of each scheme:
Table 6: FireWall-1 Encryption Schemes
Scheme What it is
FWZ Proprietary Check Point software encryption
Manual IPSec Internet encryption standard
ISAKMP/Oakley (IKE) Newest Internet encryption standard;

automated IPSec scheme
SKIP Automated IPSec scheme
Document #CPTS-DOC-C1012 Rev. B

Unit II — Chapter 4: Encryption Schemes 169
FWZ II-4
FWZ is Check Point’s proprietary symmetric-encryption scheme. FWZ manages key
Encryption Schemes
encryption automatically, including updating public keys. FWZ encryption does the
following:
• Encrypts all data behind the IP and TCP headers, using in-place encryption
(Figure 116 on page 187)
• Uses reliable-data protocol to manage VPN session keys, encryption methods and
data integrity
• Gets certified Diffie-Hellman (DH) public keys from a trusted certificate authority
(CA)
• Supports FWZ-1, DES and Triple DES algorithms, using a 40-bit encryption key
that is exportable outside the US
In the VPN+DES+STRONG version of 4.0, the only scheme that can use
3DES is ISAKMP. 3DES is not a current option for the encryption
algorithm when using FWZ, SKIP or Manual IPSec.
• Authenticate passwords:
Each time a connection is made to the firewall, S/Key authentication requires a
different password. S/Key authentication is a FireWall-1 authentication method
that uses the FWZ-1 encryption algorithm to authenticate passwords. S/Key
authentication is based on a table of 100 random passwords. Once one table of
passwords is complete, S/Key generates a new table. In this way, encryption is
secure.
Reliable Datagram Reliable datagram protocol (RDP) is used by FireWall-1 to agree on encryption
Protocol parameters. RDP is used for out-of-band sessions and the following:
• Negotiate session keys
• Agree on encryption algorithms (DES or FWZ-1) for a session
• Decide whether MD5 data integrity will be used for sessions
• Ensure all dropped UDP packets are retransmitted
Rev. B Document #CPTS-DOC-C1012

170 FWZ
FWZ Encryption The FWZ Screens

Screens When configuring FWZ encryption, you will use the following screens and tabs:
• Encryption tab
• FWZ Properties screen
• Encryption Properties screen
• (Rule base) FWZ Properties screen
Encryption Tab
When defining encryption for a firewall, you use the Encryption tab of the
Workstation Properties screen (Figure 98):

FWZ Properties screen II-4

After selecting FWZ encryption in the Encryption tab, you will use the FWZ
Properties screen (Figure 99). The CA Key and DH Key tabs allow you to specify
Encryption Schemes
local and remote CA and DH keys.
Figure 99: FWZ Properties Screen
The following are the FWZ Properties screen options:

Local/Remote — Specifies whether the CA is the machine’s Management Station or
some other computer: If you select Local, then this object’s Management Station is its
CA. If you select Remote, choose the object’s CA from the menu. The items in the
menu are all the firewalled objects, with the exception of this object’s Management
Station.
Generate — Generate the CA’s key or replace its existing key (available when CA is
Local).
Get — Get this object’s DH key from its CA (available when CA is Remote).
KeyID — A unique ID (a cryptographic hash function of the public key value)
identifying this object’s key.
Exponent and Modulus — These read-only fields make up the actual key.

172 FWZ
Encryption Properties Screen

When configuring a rule to allow FWZ encryption, you must edit the Action element.
You do so using the Encryption Properties screen (Figure 100):
Figure 100: Encryption Properties Screen
Rule Base FWZ Properties Screen

When you edit the encryption scheme in a rule base, you use the FWZ Properties
screen (Figure 101):
Figure 101: (Rule Base) FWZ Properties Screen

The following are the options for the FWZ Properties screen: II-4
Session Key Encryption Method — Specifies the encryption algorithm for session
keys.
Encryption Schemes
Data Encryption Method — Specifies the encryption algorithm for communications
packets. The available choices depend on the encryption algorithms installed. You
can also choose Clear (meaning no encryption) or Any (meaning the data encryption
method is chosen by the other party).
Data Integrity Method — Specifies the cryptographic checksum method to be used
for ensuring data integrity.
Allowed Peer Gateway — Specifies the gateways with which a gateway encrypting
under this rule is prepared to conduct an encrypted session. This field can be set to the
following values:
Any — Each gateway is prepared to conduct encrypted sessions with all other
gateways.
Gateway name or group of gateways and/or hosts — Each gateway is prepared
to conduct encrypted sessions only with the named gateway or with a gateway
belonging to the given group.
In both cases, a gateway is prepared to conduct encrypted sessions with another
gateway only if the packet’s source IP address (for decryption) or destination IP
address (for encryption) is in the other gateway’s encryption domain.

174 FWZ
Configuring FWZ To configure FWZ encryption follow these steps:

Encryption
1. Start encryption: Click Manage > Network Objects from the Security Policy GUI.
2. Select your firewall and click Edit. The Workstation Properties screen appears
(Figure 102):
Figure 102: The Workstation Properties Screen
3. Specify encryption domain: Click the Encryption tab (Figure 103). Select an
encryption domain as either Valid Addresses (all internal objects’ IP addresses).
Or select Other and specify the network or group object that represents the hosts
in the encryption domain.

II-4
Encryption Schemes
Figure 103: Encryption Tab
4. Specify encryption method and generate a CA public key for FWZ. Click Local
to select the local firewall and Generate to begin creating the CA key (Figure
104):
Figure 104: Generating the CA Key

176 FWZ
5. FireWall-1 displays the following message before generating the local CA key:
Click Yes to continue.
6. Once FireWall-1 has created the local CA key, it displays a completion message:
Click OK to continue.
7. The generated local CA key appears (Figure 105):

8. Generate the DH public key for FWZ: Select the DH Key tab and click Generate II-4
to generate the DH key (Figure 106). When asked if you want to generate a new
key, click Yes.
Encryption Schemes
Figure 106: Generated DH Key
9. Install the policy for key exchange. After the public keys have been created, the
security policy needs to be reinstalled so the remote firewall (on the other side of
the VPN) can retrieve the keys. Click OK twice and Close.
10. Click Policy > Install from the Security Policy GUI. When prompted for the
firewall on which to install the policy, select your firewall and click OK.

178 FWZ
11. When FireWall-1 has installed the security policy, you will see a completion
message (Figure 107). Click Close to continue.
Figure 107: Security Policy Installed
12. Get public keys (CA and DH) from a remote gateway: Click Manage > Network
Objects and select your local firewall.
13. Click Edit and the Encryption tab. Select FWZ and click Edit.

14. In the FWZ Properties screen, click Remote and select the remote gateway from II-4
whom you want to retrieve the remote CA key (Figure 108). Click Get to retrieve
the remote CA key.
Encryption Schemes
Figure 108: Getting the Remote CA Key
15. Click Close. Select the DH Key tab and click Get to retrieve the remote DH key
(Figure 109):
Figure 109: Getting the Remote DH Key

180 FWZ
16. Close the DH Key tab, and click OK and Close. Add an encryption rule to the
security policy (Figure 110): Select the local and remote networks as destination
and source. Select Encrypt as the action.
Figure 110: Encryption Rule
17. Define FWZ encryption for a VPN rule: Right-click the Action column and select
Edit properties (Figure 111):
Figure 111: Edit Properties Pull-Down Menu

18. The Encryption Properties screen appears (Figure 112): II-4
Encryption Schemes
19. Select FWZ as the encryption scheme and click Edit. Edit invokes the FWZ
Properties screen (Figure 113):

182 FWZ
20. Once finished modifying the FWZ Properties screen, click OK twice to exit to the
rule base.
21. Verify and install the rule base: From the Security Policy GUI, click Policy >
Verify and wait for the “OK” message, then click Close to continue.
22. Install the rule base by clicking Policy > Install. When prompted to select a
firewall on which to install the policy, select your local firewall (Figure 114):
Figure 114: Selecting Firewall

23. Click OK to continue. When FireWall-1 has installed the rule base, the II-4
completion screen appears (Figure 115):
Encryption Schemes
Figure 115: Installed Security Policy
24. Click Close and save the security policy: Click File > Save from the Security
Policy GUI menu.

184 Lab 10: Configuring an FWZ VPN
Lab 10: Configuring an FWZ VPN
Objective: You and your partner will configure your firewalls to be a part of a VPN.
Scenario: You are a part of an organization that has corporate sites in multiple
locations. You wish to link your LANs into a WAN, and use FWZ encryption to
safeguard your transmissions across the Web.
4Specify the encryption domain

Specify the encryption domain for your firewall:
1. From the Network Object Manager, highlight your firewall object (that is,
fw.yourcity.com) and click Edit. Your firewall’s Workstation Properties screen
appears.
3. In the Encryption Domain field, click Other.
4. In the menu below Other, select your city’s network object (that is, net-yourcity).
The encryption domain for your firewall is now set to net-yourcity.
4Specify FWZ encryption

Specify FWZ as your firewall’s encryption method and generate the FWZ CA and DH
keys for your firewall:
1. In the Encryption Method Defined field, click the FWZ check box.
2. Click Edit. The FWZ Properties screen appears.
3. Click Generate. This generates the FWZ CA key for your firewall.
4. Click the DH Key tab.
5. Click Generate. This generates the FWZ CA key for your firewall. Click OK.
6. Reinstall the rule base. This is needed to update the FWZ CA and DH keys on the
firewall, so that they can be retrieved by your partner.
4Specify encryption domain

Specify the encryption domain for your partner’s firewall object:
1. From the Network Object Manager, highlight your partner’s firewall object (that
is, fw.partnercity.com) and click Edit. That firewall’s Workstation Properties
screen appears.
3. In the Encryption Domain field, click Other.

4. In the menu next to Other, select your partner’s network object (that is, II-4
partnercity-net). The encryption domain for your partner’s firewall is now set to
partnercity-net.
Encryption Schemes
4Retrieve the FWZ CA and DH keys
Before proceeding, be sure your partner (fw.partnercity.com) has completed the steps
in the “Specify FWZ encryption” section of this lab. You cannot retrieve the CA and
DH keys from another firewall until they have been generated and the rule base
reinstalled.
Disable your stealth rule!
1. In the Encryption Method Defined field of your partner’s firewall, click the FWZ
check box.
2. Click Edit. The FWZ Properties screen appears.
3. Click Remote, then select your partner’s firewall form the menu at the right (that
is, fw.partnercity.com).
4. Click Get. This retrieves the FWZ CA public key from your partner’s firewall.
5. Click the DH Key tab.
6. Click Get. This retrieves the FWZ Diffie-Hellman public key from your partner’s
firewall.
7. Click OK.
4Add a VPN rule

Add a VPN (encryption) rule to the rule base and install:
1. Add a rule to the top of the rule base:
Destination: net-yourcity and partnercity-net
Source: net-yourcity and partnercity-net
Service: Any
Action: Encryption
Track: Long
You can view the encrypted/decrypted packets being logged in the Log
Viewer.

186 Lab 10: Configuring an FWZ VPN
2. With the cursor positioned over the Encryption icon in the Action column of the
new rule, click the right mouse button. In the menu that appears, select Edit
properties. The rule’s Encryption Properties screen appears:
Encryption Method: FWZ
Protocol Diagnostics: Log
3. Click OK.
4. Verify and install the rule base.
4Test the VPN
1. Test by viewing your partner’s Web page from your Internet server (that is,
www.yourcity.com).
2. Look at the log entries. Encrypted packets will have blue lines and decrypted
packets will have purple lines. If you do not see this, check the information
generated in the Info column of the rule base.
If the encryption does not work, you may need to remove your firewall
objects for your city and your partner’s city, then rebuild these objects.

IPSec (Manual IPSec) II-4
Short for IP Security, IPSec is a set of protocols that supports secure exchange of
Encryption Schemes
packets at the IP layer. For IPsec to work, the sending and receiving devices must
decide upon a unique public key and then manually generate that key.
IPSec can be used manually (Manual IPSec) or with encryption schemes such as
ISAKMP and SKIP. The IPSec scheme of encryption adds a new IPSec and IP header
to a packet. IPSec then encrypts the new headers, while authenticating the IP and TCP
header and packet data (Figure 116):
Authenticated
Encrypted
IP Header AH Header ESP Header Orig IP Header

SRC: fw.london.com SPI: 01ffab34 SPI: 01ffab34 SRC: www.london.com
DST: fw. newyork.com DIGEST: x%! IV: #$d23!‘9k DST: www.newyork.com
Original Data
Proto: IPSec (AH) Proto: TCP
Encapsulation Headers Original Packet
Figure 116: IPSec Encryption
IPSec uses Security Association (SA), which is the encryption standard of the
Internet, to define the security parameters for a specific IP host:
• Usage of encryption and/or data integrity
• Encryption and/or data integrity methods
• Encryption and/or data integrity keys
• The SA is identified using a Security Parameters Index (SPI), which is a 32-bit
number that refers to a specific SA; the SA is generated manually and assigned a
SPI (Figure 117):
SPI 0x32fd567f
Encryption (ESP): DES
Authentication (AH): SHA-1
DES Key (64 bits): 0x2983a7b31abb5f3e
SHA-1 Key (160 bits): 0x354354afbd354ad4354ceaca35c639aec98fbbb8
Figure 117: Generated SA

188 IPSec (Manual IPSec)
• Two IPSec headers each contain an SPI reference to identify the relevant SA:
• Authentication Header (AH), containing the message digest
• Encapsulating Security Payload (ESP), containing a per packet initialization
vector (IV), used as an auxiliary key to enhance security
Manual IPSec The Manual IPSec Screens

Encryption Screens When configuring IPSec encryption, you will use the following tab and screens:
• Encryption tab
• Manual IPSEC screen
• Manual IPSec Properties screen
Encryption Tab
Figure 118: IPSec Encryption Tab

Manual IPSEC Screen II-4

After adding Manual IPSec encryption to your local firewall, you will create an IPSec
SPI key using the Manual IPSEC screen (Figure 119):
Encryption Schemes
Figure 119: Manual IPSEC SPI Screen
The Manual IPSec options are as follows:

SPI value — A unique identifying hexadecimal key. When typing an SPI value, enter
leading 0x greater than 0x100.
Comment — A description of the SPI key.
Color — The color of the key’s icon.
IPSec Options:
ESP — Encryption defined for this SPI; check ESP and choose an Encryption
Algorithm from the drop-down list.
AH — Authentication defined for this SPI; check AH and choose an
Authentication Algorithm from the drop-down list.

Keys:
By Seed — Value for Seed; if ESP is checked under IPSec Options, an encryption
key is generated and displayed in Encryption Key. If AH is checked under IPSec
Options, an authentication key is generated and displayed in Authentication Key.
Manually — The typed value of the key.
Encryption Key — ESP checked under IPSec Options; the encryption key will be
read-only unless Manually selected. The encryption key is 16 hex bytes long.
Authentication Key — AH checked under IPSec Options; the authentication key will
be read-only unless Manually selected. The authentication key is 40 hex bytes long.
Creating the SPI Key

Things to remember when creating the SPI key:
• An SPI identifies the IPSec methods and keys
• Manually specify the key values
• Identify whether encryption and/or authentication is to be used
• Define corresponding algorithms on VPN gateway pair
• Implementation Flow:
• When the first IPSec encapsulated packet arrives at a firewall, it is caught
prior to rule base lookup and processed in the FireWall-1 daemon
• If SPI is found, it creates an entry in a Virtual Machine (VM) table that
includes the SPI and key
• All subsequent packets flow through the VM

Manual IPSEC Properties Screen II-4

The Manual IPSEC Properties screen allows you to specify an SPI for an encryption
rule (Figure 120):
Encryption Schemes
Figure 120: Manual IPSec Properties Screen
The following are the options in the Manual IPSec Properties screen:
SPI — A number that uniquely identifies a group of security parameter definitions.
Select an SPI from the drop-down list.
following values:
Any — FireWall-1 will attempt to find a suitable gateway based on encryption
domains.
Gateway Name — FireWall-1 will conduct encrypted sessions only with the
named gateway.
gateway only if the packet’s source IP address (for decryption) or destination IP
address (for encryption) is in the other gateway’s encryption domain.

Configuring IPSec To configure IPSEC encryption follow these steps:

Encryption
(Figure 121):

3. Specify encryption domain: Click the Encryption tab (Figure 122). Select an II-4
encryption domain as either Valid Addresses (all internal objects’ IP addresses),
or select Other and specify the network or group object that represents the hosts in
Encryption Schemes
the encryption domain.
4. Specify encryption method (Figure 123): Select Manual IPSec and click OK and
Close.
Figure 123: Encryption Methods

5. Create the IPSec SPI key: Click OK and Close to return to the Security Policy
main menu. Click Manage > Keys to enter the Encryption Keys screen (Figure
124):
Figure 124: Encryption Keys Screen

6. Click New > SPI (from the New pull-down menu). The Manual IPSec screen II-4
appears (Figure 125):
Encryption Schemes
Figure 125: Manual IPSec Screen
7. Complete the Options for your SPI key. Then click OK and Close to return to the
Security Policy GUI main menu.
8. Add two rules to the security policy: One rule with Manual IPSec and the other
rule for a VPN. For the first rule, select the local and remote networks as
destination and source. Select IPSEC as the service and accept as the action.

9. For the second rule, select the local and remote networks as destination and
source. Select Encrypt as the action. Figure 126 shows the completed rule base:
Figure 126: IPSEC and VPN Rules
10. Modify the VPN encryption rule: Right-click the Action column and select Edit
properties from the pull-down menu (Figure 127):
Figure 127: Edit Properties Menu

11. Select Manual IPSec from the Encryption Properties screen (Figure 128): II-4
Encryption Schemes
12. Click Edit to continue. The Manual IPSec Properties screen appears (Figure 129):
Figure 129: Manual IPSEC Properties Screen

13. Specify the SPI key for this VPN Pair. In Figure 129 the SPI key is the previously
defined IPSec key 0x111222. Associate one SPI per peer, then specify exactly
who that peer is in the Allowed Peer Gateway field.
14. Click OK to apply and continue.
Figure 130: Selecting a Local Firewall
17. Click OK to continue. When FireWall-1 has installed the rule base, the
completion screen appears.
Policy GUI menu.

Lab 11: Setting up an IPSec VPN II-4
4Specify Manual IPSec
Encryption Schemes
Specify Manual IPSec as the Encryption Method on each gateway:
1. From the Network Object Manager, highlight your firewall object
(fw.yourcity.com) and click Edit.
2. In the Workstation Properties window, select the Encryption tab. (The encryption
domain should be net-yourcity.)
3. In the Encryption Method Defined field, select the Manual IPSEC check box.
4. Click OK. The Workstation Properties window disappears.
5. Highlight your partner’s firewall object (fw.partnerycity.com) and click Edit.
domain should be net-yourpartnercity).
7. In the Encryption Method Defined field, select Manual IPSEC.
8. Click OK.
4Define an SPI key

Define the SPI key to be used for the VPN between your firewall and your partner
city’s firewall:
1. From the Manage menu in the Security Policy GUI, click Keys. The Encryption
Keys window appears.
2. Click New and choose the SPI. The Manual IPSec window appears.
3. Type 0x111222 in the SPI value (hex) field. SPIs are agreed upon between
partners and need to be identical for encryption/decryption to take place.
4. In the Comment field, type “SPI for yourcity and partnercity VPN.”
5. For IPSec Options, select ESP and AH. Encryption Algorithm should be set to
DES, and Authentication set to SHA1.
6. In the Key section select the By Seed button. In the Seed field, type “abc123.”
7. Click Generate. The encryption and authentication keys appear.
8. Select the OK button.
4Add VPN (encryption) rule to rule base

1. Before proceeding, delete any SKIP and VPN rules from previous labs.
2. Add a rule to the top of the rule base.

200 Lab 11: Setting up an IPSec VPN
3. For Destination, specify both net-yourcity and partnercity-net.

4. For Source, specify both net-yourcity and partnercity-net.
5. For Service, specify Any.
6. For Action, specify Encryption.
7. For Track, specify Long. You will see the encrypted/decrypted packets being
logged in the Log Viewer.
4Specify the SPI key in the VPN rule properties

1. Right-click Encrypt in the Action column of the new VPN rule. In the menu that
appears, select the Edit properties menu item at the top. The rule’s Encryption
Properties window appears.
2. Select Manual IPSEC as the encryption method. Select Log as the Protocol
Diagnostics. Click Edit. The Manual IPSEC Properties window appears.
3. In the Manual IPSEC Properties window, select 0x111222 from the SPI menu.
4. In the Allowed Peer Gateway menu, specify fw.partnercity.com. This allows only
fw.partnercity.com to establish an IPSec VPN with your firewall in this rule.
5. Click OK.
4Add an IPSec rule

Add an IPSec rule to the top of the rule base and install:
1. Add a new rule to the top of the rule base.
2. For Destination, specify both fw.yourcity.com and fw.partnercity.com.
3. For Source, specify both fw.yourcity.com and fw.partnercity.com.
4. For Service, specify IPSEC.
5. For Action, specify accept.
6. For Track, specify Long.
4Test VPN
Test by viewing your partner’s web page from your Internet server
(www.yourcity.com). Look at the log entries. Encrypted packets will have blue lines
and decrypted packets will have purple lines. If you do not see these lines, check the
information generated in the Info column.

II-4
Encryption Schemes

202 ISAKMP/Oakley (Internet Key Exchange)
Encryption Tab

ISAKMP Properties Screen (within a Firewall Object) II-4

After selecting ISAKMP/Oakley encryption in the Encryption tab, you will use the
ISAKMP Properties screen (Figure 132). You will add ISAKMP/Oakley properties to
Encryption Schemes
the firewalled object itself.
Figure 132: ISAKMP Properties Screen
The ISAKMP options define how the ISAKMP/Oakley key exchange is encrypted:
Encryption Method — Check at least one of the methods.
Hash Method — Check at least one of the methods.
Authentication Method — Check at least one of the methods:
Pre-Shared Secret — This workstation can authenticate itself by a pre-shared
secret. If you check Pre-Shared Secrets, click Edit Secrets to display the Shared
Secrets window in which you can define or modify the pre-shared secret.
Public Key Signatures — This workstation can authenticate itself by a public
key signature. If you check Public Key Signatures, click Configure to display the
Public Key Configuration window. You can generate a public key for the
workstation and define the matching criteria.
Supports Aggressive Mode — If checked, the standard six packet ISAKMP Phase 1
exchange is replaced by a three packet exchange.

ISAKMP Properties Screen (within a Rule)

The final step in configuring ISAKMP/Oakley is to modify the ISAKMP Properties
Screen within a rule base (Figure 133):
Figure 133: ISAKMP Properties Screen (Rule)
The ISAKMP properties in this window define how packets are encrypted:
Transform — Check one of the following:
Encryption + Data Integrity (ESP) — The Security Association will include
both encryption and data integrity (authentication).
Data Integrity Only (AH) — The Security Association will include only data
integrity (authentication).
Encryption Algorithm — Specifies the encryption algorithm for the traffic. The
available choices depend on the encryption algorithms installed. You can also choose
Clear (meaning no encryption) or Any (meaning the data encryption method is chosen
by the other party).
Data Integrity — Specifies the cryptographic checksum method to be used for
ensuring data integrity.
following values:
Any — Each gateway is prepared to conduct encrypted sessions with all other
gateways.

Gateway name or group of gateways and/or hosts — Each gateway is prepared II-4
to conduct encrypted sessions only with the named gateway or with a gateway
belonging to the given group.
Encryption Schemes
gateway only if the packet's source IP address (for decryption) or destination IP
address (for encryption) is in the other gateway's encryption domain.
Use Perfect Forward Security — Perfect Forward Security ensures that an
eavesdropper who uncovers a long-term encryption key will be unable to use it to
decrypt traffic sent in the past.
Configuring To configure ISAKMP/Oakley encryption follow these steps:

ISAKMP/Oakley
Encryption
(Figure 134):

3. Specify encryption domain: Click the Encryption tab (Figure 135). Select an
4. Specify encryption method: Select ISAKMP/OAKLEY and click Edit.

5. The ISKAMP Properties screen appears (Figure 136). Modify the options as
needed.

II-4
Encryption Schemes
Figure 136: ISAKMP Properties (within a Firewall Object)
6. When finished modifying the properties, click OK to exit.

7. Click OK and Close to return to the Security Policy GUI main menu.
8. Add two encryption rules to the security policy — one to add ISAKMP to a rule,
the second to add VPN encryption. For the first rule, select the local and remote
networks as destination and source and add ISAKMP as a service and accept as
the action.
9. For the second rule, select the local and remote firewalls as destination and
source, and add Encrypt as the action. The final rule base appears in Figure 137:
Figure 137: ISAKMP Rule Base

10. Define ISAKMP/Oakley encryption: Right-click the Action column (in the VPN
rule) and select Edit properties from the pull-down menu (Figure 138):
Figure 138: Edit Properties

11. Select ISAKMP/OAKLEY from the Encryption Properties screen (Figure 139) II-4
and click Edit:
Encryption Schemes
12. Click Edit to continue and the ISAKMP Properties screen appears (Figure 140):
Figure 140: ISAKMP Properties Screen
13. Once finished modifying the properties, click OK twice to continue.

Click OK to continue. When FireWall-1 has installed the rule base, the completion
screen appears (Figure 142):

16. Click Close and save the security policy: Click File > Save from the Security II-4
Policy GUI menu.
Encryption Schemes

212 Lab 12: Adding ISAKMP/Oakley (IKE) Encryption
Lab 12: Adding ISAKMP/Oakley (IKE) Encryption
Objectives: Establish a VPN between two networks. The traffic exchanged

between the two networks will be encrypted using the ISAKMP/Oakley (IKE)
features of FireWall-1.
Scenario: Your company has several remote offices that access the Internet.
Company management wants to use the Internet to link the corporate network
with the remote office network. Management is concerned about protecting
traffic flowing between the corporate and remote network and therefore wants
the traffic to be encrypted. Since both networks are protected from the Internet
by FireWall-1 machines, you will create a VPN and implement an ISAKMP/
Oakley encryption scheme. You will use a shared secret to implement
ISAKMP/Oakley between the two firewalls.
Remove or disable your previous encryption rule before proceeding with this
lab.
These steps should be performed by your partner city as well.
4Set up encryption for your firewall

Create or edit the network object for your firewall and set up the encryption domain,
encryption scheme and encryption-scheme parameters:
3. Specify the encryption domain by selecting Other in the Encryption Domain box
and using the pull down list to select yourcity_net.
4. Specify ISAKMP/Oakley in the Encryption Methods Defined box and click Edit.
The ISAKMP Properties General dialog appears.
5. Specify the Encryption Methods and Hash Methods.
6. Select Pre-Shared Secret in the Authentication Method box.
7. Click OK until you have exited all screens and are back to the rule-base editor.

4Set up encryption for your partner’s firewall II-4

Create or edit the network object for yourpartnercity’s firewall and set up the
encryption domain, encryption scheme and encryption-scheme parameters:
Encryption Schemes
3. Specify the encryption domain by selecting Other in the Encryption Domain box
and using the pull-down list to select yourpartnercity_net.
4. Specify ISAKMP/Oakley in the Encryption Methods Defined box and click Edit.
The ISAKMP Properties General dialog appears.
5. Specify the Encryption Methods and Hash Methods.
6. Select Pre-Shared Secret in the Authentication Method box.
7. Click the Edit Secrets button: The Shared Secret screen appears. Select your
firewall from the peer list and click Edit.
8. The Enter secret box appears. Type abc123 in the box and click Set.
9. Click OK until you have exited all the dialog boxes and are back to the rule-base
editor.
4Specify encryption rule

Create a rule specifying traffic originating from either network to the other network be
encrypted using ISAKMP/Oakley:
1. Pull down the Edit menu, select Add Rule and Top.
2. Right click your mouse or pointer button in the Source field of the new rule and
select Add from the menu that appears.
3. A screen listing the defined network objects appears. Select the yourcity_net
4. Right click the mouse or button in the Source field of the new rule again and select
Add from the menu that appears.
5. A screen listing defined network objects appear. Select the yourpartnercity_net
6. Right click the mouse or button in the Destination field of the new rule and select
7. A screen listing defined network objects appears. Select the yourcity_net object
for your local network and click OK.

214 Lab 12: Adding ISAKMP/Oakley (IKE) Encryption
8. Right click the mouse or button in the Destination field of the new rule again and
select Add from the menu that appears.
9. A screen listing defined network objects will appear again. Select the
yourpartnercity_net object for your local network and click OK.
10. Right click the mouse or button in the Action column of the new rule and select
Encrypt from the menu that appears.
11. Right click the mouse or button in the Track column of the new rule and select
Long from the menu that appears.
12. In the Comment column, double click the mouse or button and enter an
appropriate description of the rule in the text box that appears.
13. Click OK.
14. Right click the mouse or button in the Action column and select Edit properties
15. The Encryption Properties dialog appears. Select Log from the Protocol
Diagnostics box.
16. Select ISAKMP/Oakley from the Encryption schemes defined box, then click
Edit.
17. The ISAKMP Properties screen appears. Select Encryption + Data Integrity (ESP)
in the Transform box.
18. Specify methods for the Encryption Algorithm and Data Integrity.
19. Click OK until you are back at the rule-base editor.
4Install the policy

Pull down the Policy menu and select Install. Once the previous steps have been
implemented on the firewalls of both your city and your partner city, proceed to the
next section.

4Test the policy II-4

1. Have your partner city attempt to access your Web server.
Encryption Schemes
2. Attempt to access your partner city’s Web server.
3. Use the Log Viewer to view the log entries related to encryption, decryption and
key exchange.

216 SKIP (Simple Key Management for Internet Protocols)
SKIP (Simple Key Management for Internet Protocols)
SKIP provides a hierarchy of keys used to encrypt connections as well as to

implement key management protocols. SKIP also includes ESP and AH, and adds its
own header to a packet. The encryption and authentication keys are derived from a
session key, which changes at fixed intervals or when the amount of data encrypted
exceeds a given threshold.
The SKIP key management hierarchy is as follows:

Kij — Diffie-Hellman shared secret. Used to derive Kijn.
Kijn — A longer-term key (changed every hour) that is used to encrypt Kp. Derived
by computing MD5 over Kij and the number of hours since Jan 1, 1995.
Kp — Packet encrypting key that is used to derive encryption and/or authentication
keys (equivalent to FWZ session key). By default, key is changed every two minutes/
10MBytes of data. Inserted into the SKIP header using Kijn.
The newly changed session key is communicated by encrypting it with the Kij key.
The Kij key changes once every hour and is derived from the Diffie-Hellman shared
secret Kij key, using a cryptographic hash function. Each sender obtains the public
part of a receiver’s Diffie-Hellman (DH) key from a certificate authority (CA), which
signs the transmission with its own RSA key. SKIP includes a protocol (Certificate
Discovery Protocol) for this exchange of public keys. However, this protocol is not
supported by FireWall-1, which uses instead a proprietary protocol for key exchange.
FireWall-1 also supports manual key exchange.
The SKIP scheme is shown in Figure 143:
Authenticated
Encrypted
IP Header SKIP Header AH Header ESP Header Orig IP Header

Encrypted Kp: 0*!a!‘f&*
SRC: fw.london.com SPI: 1 SPI: 1 SRC: www.london.com
DST: fw.newyork.com
Methods: DES, SHA-1,...
DIGEST: x%! IV: #$d23!‘9k DST: www.newyork.com
Original Data
Public Keys ID: 0513, 5621
Proto: SKIP Hours: 16745 Proto: TCP
Encapsulation Headers Original Packet
Figure 143: The SKIP Scheme
SKIP Encryption The SKIP Screens

Screens When configuring SKIP encryption, you will use the following screens and tabs:
• Encryption tab
• SKIP Properties screen

• (Rule base) SKIP Properties screen II-4

Encryption Tab
Encryption Schemes

SKIP Properties Screen

After selecting SKIP encryption in the encryption tab, you will use the SKIP
Properties screen (Figure 145). The CA Key and DH Key tabs allow you to specify
local and remote CA and DH keys.
Figure 145: SKIP Properties Screen
The following are the SKIP Properties screen options:

Local/Remote — Specifies whether the CA is the machine’s Management Station or
some other computer: If you select Local, then this object’s Management Station is its
CA. If you select Remote, choose the object’s CA from the menu. The items in the
menu are all the firewalled objects, with the exception of this object’s Management
Station.
Generate — Generate the CA’s key or replace its existing key (available when CA is
Local).
Get — Get this object’s DH key from its CA (available when CA is Remote).
KeyID — A unique ID (a cryptographic hash function of the public key value)
identifying this object’s key.
Exponent and Modulus — These read-only fields make up the actual key.

SKIP Properties (Rule Base) Screen II-4

When you edit the encryption scheme in a rule base, you use the SKIP Properties
screen (Figure 146):
Encryption Schemes
Figure 146: SKIP Properties (Rule Base) Screen
The following are the options for the SKIP Properties screen:
Crypt Algorithm — The data encryption algorithm.
MAC Algorithm — The data authentication algorithm.
Allowed Peer Gateway — Specifies the gateways with whom a gateway encrypting
following values:
Any — FireWall-1 will attempt to find a suitable gateway based on Encryption
Domains.
Gateway Name — FireWall-1 will conduct encrypted sessions only with the
named gateway.
gateway only if the packet's source IP address (for decryption) or destination IP
address (for encryption) is in the other gateway's encryption domain.
If both gateways are firewalled (FireWall-1 is installed on them both), then there
must be two rules — each one specifying encryption in one direction — and only
one rule must be installed on each of the gateways.

NSID — Name Space ID, the domain from which key IDs in the header are taken.
Select one of the following:
None — The keys are explicitly included in the header.
SKIP MD5 — The KeyIDs are an MD5 hash of the Diffie-Hellman public keys
IPSec Options — At least one option must be checked:
ESP — Encrypt.
AH — Authenticate.
Configuring SKIP To configure SKIP encryption follow these steps:

Encryption
(Figure 147):

3. Specify encryption domain: Click the Encryption tab (Figure 148). Select an II-4
Encryption Schemes
4. Specify encryption method: Select SKIP and click Edit.

5. Generate a CA public key for SKIP: Click Local to select the local firewall and
Generate to begin creating the CA key (Figure 149).
Figure 149: Generating the CA Key
6. Once FireWall-1 has finished generating the CA key, click OK to continue. The
generated CA key appears (Figure 150):

7. Generate the DH public key for SKIP: Select the DH Key tab and click Generate II-4
to generate the DH key (Figure 151). When asked if you want to generate a new
key, click Yes.
Encryption Schemes
Figure 151: SKIP DH Key Tab
8. Install the policy for key exchange: After the public keys have been created, the
security policy needs to be reinstalled so the remote firewall (on the other side of
the VPN) can retrieve the keys: Click OK twice and Close.
9. Click Policy > Install from the Security Policy GUI. When prompted for the
firewall on which to install the policy, select your firewall and click OK.

10. When FireWall-1 has installed the security policy, you will see a completion
message (Figure 152). Click Close to continue.
,QVWDOO6HFXULW\3ROLF\
6.,3BHQFU\SWLRQBSROLF\JHQHUDWHGLQWR6.,3BHQFU\SWLRQBSROLF\SI
&RPSLOHG2.
,QVWDOOLQJ6HFXULW\3ROLF\6.,3BHQFU\SWLRQBSROLF\SIRQDOODOO#IZ
,QVWDOOLQJ6HFXULW\3ROLF\RQIZ,PLDPLFRPVXFFHHGHG
'RQH
&ORVH
Figure 152: Security Policy Installed
11. Get public keys (CA and DH) from a remote gateway: Click Manage > Network
Objects and select your local firewall.
12. Click Edit and the Encryption tab. Select SKIP and click Edit.

13. In the SKIP Properties screen, click Remote and select the remote gateway from II-4
whom you want to retrieve the remote CA key (Figure 153). Click Get to retrieve
the remote CA key.
Encryption Schemes
Figure 153: Getting the Remote CA Key
14. Select the DH Key tab and click Get to retrieve the remote DH key (Figure 154):
Figure 154: Getting the Remote DH Key

15. Add two rules to the rule base: The first rule will define SKIP as a service with
accept as the action. The second rule will define VPN encryption with Encrypt as
the action. For both rules, select the local and remote networks as destination and
source. The final rule base appears in Figure 155:
Figure 155: SKIP Encryption Rule
16. Define SKIP encryption for a VPN rule: Right-click the Action column and select
Edit properties (Figure 156):
Figure 156: Edit Properties Pull-Down Menu

17. The Encryption Properties screen appears (Figure 157): II-4
Encryption Schemes
18. Select SKIP as the encryption scheme and click Edit. Edit invokes the SKIP

19. Once finished modifying the SKIP Properties screen, click OK twice to exit to the
rule base.

22. Click OK to continue. When FireWall-1 has installed the rule base, the II-4
completion screen appears (Figure 160):
Encryption Schemes
Policy GUI menu.

230 Lab 13: Configuring a SKIP VPN
Lab 13: Configuring a SKIP VPN
4Generate SKIP CA and DH keys

Generate the SKIP CA and DH keys for your firewall:
1. From the Network Object Manager, highlight your firewall object (that is,
fw.yourcity.com) and click Edit. Your firewall’s Workstation Properties screen
appears.
The encryption domain should still be set to net-yourcity.
3. In the Encryption Method Defined option, click the SKIP check box.
4. Click Edit. The SKIP Properties screen appears.
5. Click the Generate button. This will generate the SKIP CA key for your firewall.
6. Click the DH Key tab and the Generate button. This will generate the SKIP
Diffie-Hellman key for your firewall.
7. Click OK.
8. Reinstall the rule base. This is needed to update the SKIP CA and DH keys on the
firewall, so your partner can retrieve them.
4Retrieve SKIP keys
Specify SKIP and retrieve the SKIP CA and DH public keys from your partner’s
firewall.
Before proceeding, make sure your partner (fw.partnercity.com) has
completed all steps in the “Generate SKIP CA and DH keys” section in
this lab. You cannot retrieve the CA and DH keys from another firewall
until they have been generated and the rule base has been reinstalled.
1. In the Encryption Method Defined option of your partner’s firewall Workstation
Properties screen, click the SKIP check box. (The encryption domain should still
be set to partnercity-net.)
2. Click Edit. The SKIP Properties screen appears.
3. Click the Remote button. Select your partner’s firewall from the menu at the right
(that is, fw.partnercity.com).
4. Click the Get button. This will retrieve the SKIP CA public key from your
partner’s firewall.
5. Click the DH Key tab and the Get button. This will retrieve the SKIP Diffie-
Hellman public key from your partner’s firewall.
6. Click OK.

4Add VPN rule II-4

Add a VPN (encryption) rule to the rule base. Before proceeding, delete any IPSec
VPN rules that you may have created in previous labs:
Encryption Schemes
1. Add a rule to the top of the rule base:
Destination: net-yourcity and partnercity-net
Source: net-yourcity and partnercity-net
Service: Any
Action: Encryption
Track: Long (You can see the encrypted/decrypted packets being logged in the
Log Viewer.)
2. With the cursor positioned over the Encryption icon in the Action column of the
new rule, click the right mouse button.
3. Select Edit Properties. The rule’s Encryption Properties screen appears.
4. Click SKIP as the Encryption Method.
5. Click Log as the Protocol Diagnostics.
6. Click OK.
4Add SKIP rule
1. Add a SKIP rule to the top of the rule base and install:
Destination: fwyourcity.com and fw.partnercity
Source: fw.yourcity.com and fw.partnercity.com
Service: SKIP
Action: accept
Track: Long
4Test VPN
Test the VPN by viewing your partner’s Web page from your Internet server (that is,
www.yourcity.com). Look at the log entries. Encrypted packets will have blue lines
and decrypted packets will have purple lines. If you do not see this, check the
information generated in the Info column.

232 Review
Review
Summary FireWall-1’s encryption works through the use of four encryption schemes: FWZ,
Manual IPSec, ISAKMP/Oakley (IKE) and SKIP.
FWZ is Check Point’s proprietary symmetric-encryption scheme. FWZ manages key

encryption automatically, including updating public keys. FWZ encryption does the
following:
• Encrypts all data behind the IP and TCP headers, using in-place encryption
(Figure 116 on page 187)
• Uses reliable-data protocol to manage VPN session keys, encryption methods and
data integrity
• Gets certified Diffie-Hellman (DH) public keys from a trusted certificate authority
(CA)
• Supports FWZ-1, DES and Triple DES algorithms, using a 40-bit encryption key
that is exportable outside the US
• Authenticate passwords
Short for IP Security, IPSec is a set of protocols that supports secure exchange of
packets at the IP layer. For IPsec to work, the sending and receiving devices must
share a public key.
IPSec can be used manually (Manual IPSec) or with encryption schemes such as
ISAKMP and SKIP. The IPSec scheme of encryption adds a new IPSec and IP header
to a packet. IPSec then encrypts the new headers, while authenticating the IP and TCP
header and packet data.
ISAKMP, or Internet Security Association and Key Management Protocol, is the

encryption standard of the Internet Engineering Task Force (IETF), the main standards
organization for the Internet. The ISAKMP protocol provides a consistent framework
for transferring key and authentication data, independent of the encryption and
authentication mechanisms.
SKIP provides a hierarchy of keys used to encrypt connections as well as to

implement key management protocols. SKIP also includes ESP and AH, and adds its
own header to a packet. The encryption and authentication keys are derived from a
session key, which changes at fixed intervals or when the amount of data encrypted
exceeds a given threshold.
The SKIP key management hierarchy is as follows:

Kij — Diffie-Hellman shared secret. Used to derive Kijn.

Kijn — A longer-term key (changed every hour) that is used to encrypt Kp. Derived II-4
by computing MD5 over Kij and the number of hours since Jan 1, 1995.
Kp — Packet encrypting key that is used to derive encryption and/or authentication
Encryption Schemes
keys (equivalent to FWZ session key). By default, key is changed every two minutes/
10MBytes of data. Inserted into the SKIP header using Kijn.
FireWall-1’s SecuRemote product is another way for security engineers to ensure that
remote communications traveling through unsecured lines are encrypted.
Review Questions 1. What are the four types of encryption scheme? Which one is applicable to your
network?
2. What are the basic steps for setting up a VPN?

234 Review

II-4

SecuRemote
Introduction
decrypted with an encryption key. You use encryption with FireWall-1 through a
virtual private network, which provides secured connections between points where
encrypted data travels through the Internet.
FireWall-1’s SecuRemote product is another way for security engineers to ensure that
remote communications traveling through unsecured lines are encrypted.
Objectives • Demonstrate how to install and configure SecuRemote Client

• Demonstrate how to configure SecuRemote
• Discuss how to configure a VPN for SecuRemote
III-3
Key Terms • client encryption

• Client-to-firewall VPN
• SecuRemote kernel module
SecuRemote
• SecuRemote Client
• SecuRemote service
• encapsulation
235
236 SecuRemote
SecuRemote
SecuRemote and FireWall-1 SecuRemote allows remote network users secure access to their internal
VPNs networks. This is called client-to-firewall VPN encryption and is used for remote
access.
SecuRemote does the following:

• Encrypts data before it leaves a remote computer
• Transparently encrypts any TCP/IP communications
• Interfaces with any existing adapter and TCP/IP stack
• Enables access for FireWall-1 SecuRemote users through the rule base editor
• Enforces security features, including authentication servers, logging and alerts, on
FireWall-1 SecuRemote connections
• Includes support for dynamic IP addressing, necessary for dial up communication
• Includes stronger authentication using Diffie-Hellman and RSA algorithms, as
well as strong encryption using FWZ-1 and DES
A Note about SecuRemote Configuration

SecuRemote requires that a VPN be configured so that both of the following
conditions are true:
1. The encryption domains of all SecuRemote users in the VPN do not overlap, that
is, no host is included in more than one encryption domain.
2. If there is more than one firewalled computer along the path from a SecuRemote
client to its destination, only one of the firewalls can be a SecuRemote server.

Unit III — Chapter 3: SecuRemote 237
SecuRemote User Figure 161 illustrates how SecuRemote allows a remote user to access their network: II-4
SecuRemote user logs on to the firewalled gateway

SecuRemote Client is installed on the laptop
Firewall allows client connection and decrypts communication
Firewall passes the connection to the destination
Encryption
Firewalled Gateway SecuRemote
Client Installed
Figure 161: SecuRemote User Connecting to Firewalled Network
In Figure 161 the following happens:

1 SecuRemote Client is installed on the user’s portable computer. The SecuRemote
user logs on to the firewalled gateway.
2 The firewall allows the user’s connection and decrypts their communication.
III-3
SecuRemote encrypts and decrypts depending on the communication
direction.
3. The firewall passes the connection to the destination PC within the network.
SecuRemote
Client-to-Firewall SecuRemote runs on a remote client computer. The SecuRemote software on the
VPN (How client is called SecuRemote Client, and it communicates with the firewalled computer
SecuRemote Works) (Figure 162):
Firewall Module SecuRemote Client

with Encryption
Figure 162: SecuRemote Server and Client

238 SecuRemote
SecuRemote The SecuRemote service is the SecuRemote application that runs when Windows 95
Service or NT on the client computer starts. The SecuRemote service does the following:
• Loads the SecuRemote kernel module with information about all known firewalls
and their encryption domains; the SecuRemote kernel module is the core of the
SecuRemote service, and performs encryption functions
• Provides a GUI for adding, updating and removing sites (firewalled computers)
• Maintains a site list

Configuring the Firewall for SecuRemote II-4
To configure SecuRemote, security engineers must define SecuRemote users, user

authentication, encryption and routing. Engineers then add SecuRemote to a rule base
to ensure SecuRemote users always use SecuRemote when they connect to an internal
network.
Encryption
The FireWall-1 GUI Use the following FireWall-1 Security Policy GUI screens to configure SecuRemote:
Screens
• Workstation Properties (Encryption and Authentication tabs)
• User Properties (Authentication and Encryption tabs)
The Workstation Properties Screen (Encryption Tab)
III-3
Figure 163: Workstation Properties — Encryption Tab
SecuRemote
Encryption options for the firewall are as follows:
Encryption Methods Defined — Encryption schemes defined for a firewall.
this firewall performs encryption.

240 Configuring the Firewall for SecuRemote
Security engineers use the Workstation Properties (Authentication Tab) screen (Figure
164) to configure a firewall with authentication for SecuRemote:
Figure 164: Workstation Properties — Authentication Tab
The Authentication tab options for the firewall are as follows:

S/Key — The value of the requested S/Key iteration.
SecurID — The number displayed on the Security Dynamics SecurID card.
O/S Password — The firewall password.
FireWall-1 Password — The internal FireWall-1 password on the gateway.
RADIUS — Defined by the radius server.
Axent Pathways Defender — Defined by the Axent Defender server.
TACACS — Defined by the TACACS or TACACS+ server.
Encrypted versus Unencrypted Topology Downloads

Versions 4.0 and higher of SecuRemote Client allows security engineers to download
a site’s topology in encrypted format. Earlier versions of the application do not.
To allow downloads of an encrypted topology, click “Respond to unauthenticated

cleartext topology requests” in the Encryption tab of the SecuRemote server’s
Workstation Properties screen, as shown in Figure 165. To allow unencrypted
topologies, click “Respond ... ” to deselect.

II-4
Encryption
Figure 165: Encrypted Topology Selected
The User Properties Screen

In the User Properties screen, you set up authentication and encryption for
SecuRemote users. Figure 166 is the Authentication tab of the User Properties screen:
III-3
SecuRemote
Figure 166: User Properties — Authentication Tab

The Authentication tab options are as follows:

S/Key — The value of the requested S/Key iteration.
SecurID — The number displayed on the Security Dynamics SecurID card.
O/S Password — The user’s OS password.
FireWall-1 Password — The user’s internal FireWall-1 password on the gateway.
RADIUS — Defined by the radius server.
Axent Pathways Defender — Defined by the Axent Defender server.
TACACS — Defined by the TACACS or TACACS+ server.
The Encryption tab appears in Figure 167:
Figure 167: User Properties — Encryption Tab
The Encryption tab defines the client encryption properties for SecuRemote users:
Client Encryption Methods — FWZ or ISAKMP/Oakley.
Successful Authentication Track — Logging options for Encryption attempts.
Configuring The following lists the steps for configuring the firewall for SecuRemote:
SecuRemote
1. Define user authentication and encryption.
2. Configure the firewall.
3. Install the security policy.

Defining User Authentication and Encryption II-4

When SecuRemote connects to a new encryption domain (after the server reboots),
SecuRemote users must first authenticate themselves to the SecuRemote server. The
authentication method depends on each user’s authentication scheme.
1. From the FireWall-1 Security Policy screen, click Manage > Users.
2. Click New if you are setting up a new user; or select a user and click Edit to open
the User Properties screen.
Encryption
3. Click the Authentication tab and choose an authentication scheme (Figure 166 on
page 241).
4. Click the Encryption tab to display the user’s encryption scheme (Figure 167 on
page 242).
5. Click the appropriate encryption scheme to enable it for the user. Click OK and
Close to continue.
Configuring the Firewall

1. Click Manage > Network Objects from the FireWall-1 Security Policy GUI.
2. Highlight your firewall and click Edit.
3. Click the Exportable option in the General tab of the Workstation Properties
screen.
Export a site’s topology when a firewalled computer’s encryption keys and

domain change. III-3
4. Enable the authentication scheme by clicking FireWall-1 Password in the

Authentication tab (Figure 164 on page 240). Click OK and Close to continue.
5. Install the security policy. To ensure SecuRemote users always use SecuRemote
when they connect to the internal network, define a rule (in the FireWall-1
SecuRemote
Security Policy GUI) whose action is Client Encrypt (Figure 168).
Figure 168: SecuRemote in a Rule Base
The rules are defined as follows:

Source — Remote users
Destination — Internal network

Services — Any
Action — Client encrypt for SecuRemote
Track — Short
Install On — Firewalled gateways
Time — Any time
Comment — VPN for all remote users
6. Save and install the security policy.
A Note about Default routing must ensure that reply packets returning to the SecuRemote client are
Routing routed through the same encrypting gateway through which the original packets were
routed.
If this is not the case, force reply packets back through the gateway via network
address translation on the gateway, hiding all outside addresses not in the internal
network behind the gateway.
This solution is more suitable when a single gateway is dedicated to

handling SecuRemote sessions.
FWZ Encapsulation Encapsulation is a form of FireWall-1 encryption. Encapsulation encrypts packet IP

and TCP headers but not data. This means the data will be able to reach the packet’s
destination. Encapsulation allows SecuRemote users to connect to hosts inside an
encryption domain. This is for remote users who do now know the IP address of a
destination device in an internal network or for whom the IP address is illegal. If a
destination device has an illegal IP address, SecuRemote can resolve internal names
with legal IP addresses.

Implementing Encapsulation II-4

Check the Encapsulate SecuRemote connections in the encapsulating gateway’s
Encapsulation tab in its FWZ Encryption Properties screen (Figure 169):
Encryption
Figure 169: Specifying Encapsulation
III-3
SecuRemote

246 Before Installing SecuRemote
Before Installing SecuRemote
Software and The following lists the software and hardware requirements for installing
Hardware SecuRemote:
Requirements
• Windows 95 or NT (Intel x86)
• 6 MB disk space
• 24 MB memory (Windows 95); 32 MB memory (Windows NT)
• Microsoft MSTCP TCP/IP support
• CD-ROM or Internet capability
SecuRemote Before installing SecuRemote, you must know the topology of the site to which
Topology SecuRemote Client will connect by doing one of the following:
Requirements
1. Defining a site and downloading the topology. Download the site’s topology
when it changes at the initial setup and when the firewalled computer’s encryption
keys change.
2. Installing a standard userc.C file for SecuRemote users. This allows SecuRemote
Client to run transparently to end users. End users do not need to download the
topology of the sites to which they will connect.
userc.C must be on the SecuRemote Client.
Installing userc.C
To install userc.C, copy a standard userc.C file to the SecuRemote installation disk. If
you install SecuRemote from CD-ROM, copy userc.C to the
C:\WINNT\FW\DATABASE directory. userc.C ensures that all end users have the
same site configuration for SecuRemote Client. This file contains the following:
(
:options (
:default_key_scheme (isakmp)
:expire (15)
)
:gws ()
:managers ()
)
userc.C has no topology configured at the time of SecuRemote initial

configuration. Fetch the topology to one SecuRemote device and
distribute that devices’s userc.C file to all other SecuRemote devices.

Installing SecuRemote Client II-4
Since SecuRemote Client is not installed during FireWall-1 installation, you must
install SecuRemote Client on a remote device (such as a laptop computer). You must
install the Windows 95 version on Windows 95 only, and the Windows NT version on
Windows NT only.
1. Insert the disk or CD-ROM and click Start > Run. Browse the CD-ROM or disk
Encryption
for the file setup.exe. Click OK to begin the installation. The setup wizard
appears (Figure 170).
Figure 170: SecuRemote Setup Screen
2. The first installation screen appears (Figure 171). Click Next to continue.
III-3
SecuRemote
Figure 171: The Installation Screen

248 Installing SecuRemote Client
3. At the Software License Agreement screen, click Yes to continue (Figure 172).
Figure 172: The License-Agreement Screen
4. Select the destination directory for SecuRemote (Figure 173). Click Next to
continue.
Figure 173: The Destination Screen
5. When the installation completes, click OK to restart your computer.

II-4
After rebooting, the client PC displays the SecuRemote icon in the lower
right-hand corner of your task bar.
Encryption
III-3
SecuRemote

250 Configuring SecuRemote Client
Configuring SecuRemote Client
In this section you will learn how to configure a SecuRemote site so that a remote user
can connect to the internal firewalled network.
The SecuRemote To configure SecuRemote Client, security engineers use the FireWall-1 SecuRemote
Client GUI and Client GUI (Figure 174) and Sites screen (Figure 176):
Screens
Figure 174: The SecuRemote Client GUI
Pull Down Menus This section describes the SecuRemote pull-down menus and icons. They are as
follows:
File:
Close — Close the SecuRemote daemon. The daemon remains active, but its screen is
closed. To open it again, click on its icon.
Kill— Deactivate the SecuRemote daemon. The kernel remains in the stack but it
does nothing.
View:
Toolbar — Toggle the display of the SecuRemote Client toolbar.

Status Bar — Toggle the display of the SecuRemote Client status bar. II-4
Large Icons — Display sites as large icons.
Small Icons — Display sites as small icons.
List — Display sites as a list.
Details — Display sites as a list showing details.
Encryption
Sites:
Make New — Create a site.
Delete — Delete a site.
Properties — Display a site’s properties.
Passwords:
Set Password — Enter a new password to be used for the next authentication.
Erase Password — Erase all passwords from the SecuRemote daemon’s memory.
Tools:
Options — Display the Options screen.
Entrust:
Create User — Create a user profile.
Recover User — Recover a user profile.
Select INI File — Specify the location of an ENTRUST.INI file. III-3
Configure INI File — Configure an ENTRUST.INI file.
Icons Figure 175 displays the SecuRemote icons:
SecuRemote
Figure 175: SecuRemote Icons

The icon functions appear in Table 7:
Table 7: SecuRemote Icons
Icon Function
Sites/Make New
Sites/Delete
Sites/Properties
Passwords/Set
Password
Passwords/Erase
Passwords

The Sites Screen The Sites screen defines the IP address of the firewall with which SecuRemote must II-4
communicate (Figure 176):
Encryption
Figure 176: The Sites Screen
The following are the Sites options:
Name — Name of the site. III-3

IP Address — The IP address of the firewall with which SecuRemote must
communicate.
Last Update — The last time SecuRemote received the keys and topology from a
firewall.
SecuRemote
Last Update is useful to know when updating SecuRemote.

Configuring Configuring SecuRemote Client involves adding client sites and specifying the
SecuRemote Client firewall with which SecuRemote connects, as follows:
1. Click Sites > New from the FireWall-1 SecuRemote Client GUI’s main menu
2. Type the name or IP address of the firewall with which SecuRemote must
communicate (Figure 176). Click OK when finished.
3. The final SecuRemote screen displays the firewalled computer as a site, with its
IP address displayed.
Authenticating with When you start a session that requires authentication by SecuRemote, the screen seen
SecuRemote in Figure 177 appears.
Figure 177: SecuRemote Client GUI
To authenticate your current session, follow these steps:
1. At the User option enter the user name. Press Tab.

2. At the Password field type the password.
3. Click OK.
Users must be defined on the firewalled system before you can use SecuRemote. See
“Other Considerations for SecuRemote” on page 255.

Other Considerations for SecuRemote II-4
Support for Public SecuRemote supports public-key infrastructures using X.509 digital certificates and
Key Infrastructures Entrust certificate authority. SecuRemote can request and validate Entrust certificates
on a user’s behalf to initial an Internet key exchange (IKE) key negotiating with a
FireWall-1 gateway.
Encryption
SecuRemote supports the public-key cryptography standard (PKCS) #11 interface for
accessing information contained in hardware or software tokens. PKCS #11-
compatible tokens provide secure storage of private keys used for data encryption and
digital signatures.
Other Firewalls If there are other firewalls along the path connecting the SecuRemote client and
SecuRemote server, configure the other firewalls to allow SecuRemote Client and
SecuRemote Server to connect.
For FWZ encryption, allow RDP (UDP on port 259). For ISAKMP/Oakley, you
should allow IPSec and ISAKMP/Oakley UDP on port 500.
Control Properties Some services provided by a server inside an encryption domain are configured, by
default, for SecuRemote users. These services are in the Properties Setup screen in
the FireWall-1 Security Policy GUI, as follows:
III-3
• FTP
• RealAudio
• VDOLive
• RPC
SecuRemote

256 Lab 14: SecuRemote in a VPN (using FWZ Encryption)
Lab 14: SecuRemote in a VPN (using FWZ Encryption)
Configuring a Objective: Set up a firewall to accept secure connections from SecuRemote clients.
Network with The traffic exchanged between the firewall and the SecuRemote client will be
SecuRemote encrypted using FireWall-1’s proprietary FWZ encryption features.
Scenario: Your company has several sales persons that access the Internet while they
are on the road. Company management wants to allow these sales persons to use the
Internet to link with the corporate network. Management is concerned about
protecting traffic flowing between the corporate network and these individual
machines on the Internet, and therefore wants the traffic to be encrypted. In order to
implement this, the clients will have SecuRemote client software installed. The
firewall and client will be configured to implement an FWZ encryption scheme.
4Yourcity firewall
On the firewall for yourcity, do the following:
4Edit your firewall’s network object

Create or edit the network object for your firewall and set up the encryption domain,
encryption scheme and encryption-scheme parameters:
3. Click on Exportable.
Select an object color that corresponds to this type of object.
4. Click the Encryption tab:
Specify the encryption domain by selecting Other in the Encryption Domain box
and using the pull-down list to select net-yourcity.
Specify FWZ in the Encryption Methods Defined box and click Edit. The FWZ
Properties CA Key screen appears.
Click the CA Key tab (if it is not already selected) and click Local.
Generate a certificate-authority key for your firewall by clicking the Generate
button.

Generate a Diffie-Hellman key by clicking the DH Key tab and clicking Generate. II-4
5. Click the OK button until you have exited all screens and are back to the rule-base
editor.
4Create user “guest”

1. Click Manage > Users > New > Standard User (or Default). The User Properties
Encryption
screen appears:
Enter user name guest.
Select the appropriate color.
Leave the Expiration Date field empty.
Select the Authentication tab and verify that FireWall-1 password is selected as
the authentication method.
Enter password abc123 for the user.
2. Select the Encryption Tab:
In the Successful Authentication Track box, click Log.
In the Client Encryption Methods box, click the check box by FWZ. Then click
the Edit button. The FWZ Properties FWZ Encryption dialog will appear.
Verify that the session-key encryption method and data-encryption method are
both set to FWZ1.
In the Data Integrity Method box, click MD5. III-3
3. Click OK.
4Create a client encryption rule

1. Pull down the Edit menu, select Add Rule and Top.
SecuRemote
2. Right click your mouse or pointer button in the Source field of the new rule and
select Add User Access from the menu that appears.
3. A dialog box listing the defined user and user group objects will appear. Select
the All Users user group object and click OK.
4. Right click the mouse or button in the Destination field of the new rule and select
5. A dialog box listing the defined network objects appears. Select the net-yourcity
object for your local network and click OK.
6. Right click the mouse or button in the Action column of the new rule and select
Client Encrypt from the menu that appears.
7. Right click the mouse or button in the Track column of the new rule and select

258 Lab 14: SecuRemote in a VPN (using FWZ Encryption)
Long from the menu that appears.

8. In the Comment column, double click the mouse or button and enter an
appropriate description of the rule in the text box that appears. Click OK.
9. Right click the mouse or button in the Action column and select Edit properties
from the menu that appears. The User Encryption Action Properties dialog
appears.
10. Verify that Source and Destination are set to intersect with user database.
11. Click OK until you are back at the rule-base editor.
4Install the policy

Pull down the Policy menu and select Install.

4Test the policy II-4

Have the student configure SecuRemote on the instructor’s presentation machine to
set up an encrypted session in her internal network.
4Use Log Viewer

Use the Log Viewer to view log entries related to encrypting, decrypting and key
exchange.
Encryption
III-3
SecuRemote

260 Review
Review
Summary In this chapter you learned about SecuRemote, a type of virtual private network
(VPN), which is a secured (private) network overlaid on an unsecured (public) IP
network infrastructure such as the Internet. SecuRemote provides secured
connections between points where encrypted communications travel along the
Internet. A VPN typically uses the Internet as the transport backbone to establish
secure links with business partners, extend communications to regional and isolated
offices, and significantly decrease the cost of communications for an increasingly
mobile workforce.
Review Questions 1. How do security engineers configure VPNs for use with SecuRemote?
2. How do security engineers set up encryption in a VPN?
3. How do you install and configure SecuRemote Client? (Summarize.)
4. How do you configure SecuRemote? (Summarize.)
5. What are the differences between SecuRemote Client and SecuRemote?

Unit 4 — FireWall-1 Management
Chapter 1: Router Management
Chapter 2: Account Management Client
Chapter 3: Load Balancing
Chapter 4: Remote Management

III-1
Router Management
Router Management
Introduction
Routers are an integral part of an enterprise network, often sitting at the edge of
network boundaries. As you have already learned, routers can be used to filter
unwanted network traffic and are considered to be first-generation firewalls,
performing rudimentary packet filtering.
For the most part, router interfaces have not changed, still relying heavily on
character-based interfaces. Defining router specifications and filters can be difficult,
time consuming and error-prone. Because router commands are typically based on
sets of key words in combination with IP addresses, a high level of skill in router
configuration is required in order to set up a router filter list. And each router typically
has to be managed separately, providing no overall view of a network’s filtering.
FireWall-1 allows security engineers to do the following to manage routers:

• Generate router filtering and configuration specifications for 3Com, Bay
Networks, Microsoft RAS (Steelhead), and Cisco routers, using FireWall-1's
Security Policy GUI
• Define routers as network objects — with logical names — and manage them
within the rules of a security policy
• Set up routers in security policies to define, generate and manage router access
control lists
• Import access control lists from routers, maintaining existing router security IV-1
policies through FireWall-1’s security-policy editor
• Log events on routers that support logging
• Make changes to all routers when making changes to multiple routers Router Management
Objectives • Demonstrate the need for FireWall-1 router management

• Configure router management in FireWall-1
• Implement router security using FireWall-1
263
264
Key Terms • access control list

Unit IV — Chapter 1: Router Management 265
The FireWall-1 Solution to Router Management Problems III-1
FireWall-1 allows security engineers to maintain security on routers, thus
Router Management
reducing the load on network firewalls and adding efficiency to router-security
management. Figure 178 displays two external networks using routers to
communicate through the Internet:
Figure 178: Router Management in a Firewalled Network
FireWall-1 supports the following routers and features:

• Bay Networks routers, versions 7.x - 12.x
• Cisco routers, IOS versions 9 - 11
• Cisco PIX Firewall, versions 3.0 and 4.0
• 3Com NetBuilder, version 9.x
• Microsoft RAS (Steelhead) Routers for Windows NT server 4.X
Supported Features
• Cisco PIX Import Security Policy
• PIX, Cisco, 3Com Logging
IV-1
Router Management

266 Setting up Router Management
Setting up Router Management
To configure router management for a firewalled network, security engineers must

create network objects for existing, supported routers that use access lists and are
installed in security policies.
To set up router management on a firewalled network, do the following:

1. Create a router interface on a router.
Follow the steps specified by the router manufacturer to install router

interfaces.
2. Configure a router to be managed remotely.

3. Define access-list properties.
4. Define a router object.
5. Add security rules for the router.
6. Install a security policy on the router (in the FireWall-1 security-policy editor).
Router Interfaces Before configuring interfaces, security engineers must create a router object in the
Screens FireWall-1 Security Policy GUI. After defining the general router properties, security
engineers can create the appropriate interfaces.

The Router Properties Screen III-1

To configure a router interface, you will use the Router Properties screen (Figure 179):
Router Management
Figure 179: The General Tab of the Router Properties Screen
The router options are as follows:

Name — The router’s name.
Get Address — The address that resolves the router’s name to its IP address.
Comment — Descriptive text used to describe this router.
Color — The color of the router’s icon.
Location: Internal/External — This selection relevant if router enforces part of a
security policy.
IV-1
A router is internal to its own management station and external to other
management stations. You cannot install a security policy on an object
from a management station where that object is defined as external. Only
Router Management
internal routers appear in the Log Viewer; security engineers can only
modify or control internal routers.
Type — The appropriate third-party vendor from the drop-down list.

The Interfaces Tab

Set up interfaces by clicking the Interfaces tab, then the Add button, in the Router
Figure 180: Interface Properties screen
The Interface Properties options are as follows:

Name — The name of the router interface; for example, Ethernet0 or Serial1 (for
Cisco routers).
Net Address — A 32-bit address that uniquely identifies this interface.
Net Mask — Does not need to be specified if the network is a standard Class A, B, or
C network.
Valid Addresses — Options for spoof tracking; each option is available only if
routers support anti-spoofing:
Any — (Default) no spoof tracking.
No Security Policy! — No security policy at all is installed on this interface; use
with extreme caution.
Others — All packets are allowed, except those whose source IP addresses
belong to the networks listed under Valid Addresses for this object’s other
interfaces.
Others + — All packets are allowed, except those whose source IP addresses
belong to the networks listed under Valid Addresses for this object’s other
interfaces.

This Net — Only packets whose source IP addresses are part of the network III-1
connected to this interface are allowed.
Specific — Only packets from this object allowed.
Router Management
Spoof Tracking Box — Options for spoof tracking; each option is available only if
routers support anti-spoofing:
None — No additional action taken.
Log — Spoofing attempt is logged; available only if router supports logging.
Alert — Action specified in the Anti Spoof Alert Command field in the Log and
Alert tab of the Properties Setup screen is taken; available only if router supports
logging.
Steps for Creating Set up router properties as follows:

Router Interfaces
1. Click Manage > Network Objects > New > Router from the Security Policy main
menu.
2. In the General tab, select the options as described earlier (Figure 179 on page
267).
4. In the Interface Properties screen, select the options as described earlier (Figure
180 on page 268).
Configuring SNMP Enable SNMP on a router so that FireWall-1 can get and set SNMP information from
a router. SNMP read and write passwords need to be chosen and added to the router
manually. Figure 181 shows the SNMP tab of the Router Properties screen.
Security engineers can configure SNMP only if a router supports SNMP.
IV-1
Router Management

Figure 181: The Router Properties screen
The router properties for SNMP are as follows:

sysName — The router’s name.
sysLocation — The router’s location.
sysContact — The name of a contact person.
Read Community — Set up for security engineers, systems administrators and users
whose password allows read-only access.
Write Community — Set up for security engineers, systems administrators and users
whose password allows read/write access.
Get — Retrieve and display information about this router.
Get fetches the SNMP information from the router and displays it in the fields
provided.
Set — Accept router’s properties as shown in this screen.
Defining the Enable To define the enable password on a Cisco router follow these steps:
Password (Cisco)
1. Select Setup on the Router Properties screen (Figure 182).

III-1
Router Management
Figure 182: Router Properties for a Cisco Router
The Enable Password options are as follows.
Select each option from the pull-down menu.
None — When no password needed (optional).

Known — The password kept in the FireWall-1 database.
Prompt — User prompted to enter a password whenever a security policy is to be
installed on a Cisco router.
To enable the password on the Cisco router follow these steps:
1. On a Cisco router, add the administrator’s password and the enable password
(Figure 182). IV-1
Defining Access A router access control list is a list of rules to be enforced on the routers. The access Router Management
Control List list contains the rules in the order in which they are to be enforced. All properties set
Properties up for an access control list affect routers in the same way that the security-policy
properties affect FireWall-1. The router term “access control list” is equivalent to the
FireWall-1 term “security policy.”

Figure 183 shows the Access Lists tab of the Properties Setup screen in the FireWall-1
Security Policy GUI.
Only options relevant for routers are available.
Figure 183: Properties Setup for Access Lists
The Access Lists options are as follows.
A rule that is first is applied before all other rules. A rule that is before last
allows security engineers to define more detailed router-related rules that
will be enforced before the last rule is enforced. The cleanup rule is always
last in a rule base.
Accept Established TCP Connections — First, Last or Before Last to accept packets
of established TCP connections. Routers do not contain connection tables. FireWall-1
allows all packets that claim to be part of an established TCP connection through
(unless they are spoofed). This does not pose a security risk, however, because the
firewall’s operating system would discard packets not part of an established
connection.

Accept RIP — First, Last or Before Last for routing-information protocol (RIP) used III-1
by the routed daemon. RIP maintains information about reachable systems and routes
to those systems. Normally, you will use RIP.
Accept Domain Name Queries (UDP) — First, Last or Before Last for domain-name
Router Management
queries used by named.
Accept Domain Name Download (TCP) — First, Last or Before Last to upload the
domain name-resolving tables.
Accept ICMP — First or Before Last to accept Internet control messages.
Adding Set the Install On column to install on a router in the rule base in your security policy
Router-Enforced (Figure 184).
Rules to a Security
Policy
Figure 184: Rule Base Containing Router-Enforced Rules
In Figure 184 the router rule allows any communications destined for the local
network. The router accepts all communications and logs it in long format (if it
supports logging).
Installing a Security To install the security policy on a router,

Policy on a Router
1. Click Policy > Install on the FireWall-1 Security Policy main screen.
IV-1
Router Management
Figure 185: The Install Security Policy Module Screen
2. The Install screen lists all internal firewalled hosts and routers. By default, all
internal firewalled hosts and routers are already selected (Figure 185).

3. Complete this screen by selecting an action from the following:

a. Click Clear to unselect all the items in the listbox, or
b. Click All to select all the items in the listbox.
You can clear specific items. The security policy will not be installed on
cleared items.
4. Click OK to install the security policy on all selected hosts.

5. You will then see the installation progress screen, as shown in Figure 186.
Figure 186: Installation Progress

Lab 15: Router Security Management III-1
Objective: You need to define a router that you will add to your FireWall-1 Network
Router Management
objects.
4Define a router object

1. Create a router object called router-yourcity:
IP address: router_IP_address
Type: Cisco Systems
SNMP Tab
Write Community string: abc123
Read community string: abc123
2. Ask the instructor for the Enable password and the firmware version the router is
running. This is configured on the Setup tab.
4Add a rule and install
1. Add a new rule to the rule base:
Source: any
Destination: net-yourcity
Service: TELNET
Action: accept
2. Install on router-yourcity. (Select Specific Target from the Install On column to
list applicable objects.)
3. Remove Gateway from the Target list.
4. Verify and install the rule base.
IV-1
Router Management

276 Router Logging Support
Router Logging Support
Overview Setting up access lists allows FireWall-1 to provide router-logging support. The
FireWall-1 Log Viewer displays system log messages for supported routers and
security devices.
FireWall-1 supports router logging only on a gateway on which a Firewall

Module and the Management Module are both installed.
The steps for enabling router logging are as follows:

1. Configure router properties.
2. Configure syslog properties.
3. Create a security policy with router logging enabled.
4. Import a router access list.
Router-Logging To add router logging to FireWall-1, security engineers modify the following screens:
Screens
• Router Properties
• UDP Service Properties
• Router Access List Operations
The Router Properties Screen

The options for the router properties screen are described on page 267.
Figure 187: The Router Properties Screen

The UDP Service Properties Screen III-1
Router Management
Figure 188: UDP Service Properties
The following are the syslog options:

Name — Add the syslog service’s name.
Comment — Text to describe syslog (used for router logging).
Color — The color of the syslog icon.
Port — The number of the syslog port (514).
Source Port Range — the datagram whose source port field is in this range is
considered to belong to syslog; leave empty
The Router Access List Operations Screen

Access lists imported to a rule base are displayed in terms of source, destination,
service, the router interface and direction to which each rule applies. Imported access
lists can be modified in a rule base and installed on the appropriate router interface.
IV-1
Router Management

Figure 189: Router Access List Operations
To import routers, security engineers click Import Access List and specify the routers
by selecting them from the Router pull-down menu.
Enabling Router The following steps enable router logging:

Logging
1. Solaris only: Stop syslogd on the gateway, using the following commands (where
180 is an example):
# ps -ef | grep syslogd | grep -v grep
# kill -HUP 180

2. Start FireWall-1 and open the FireWall-1 Security Policy GUI.
3. Define a router, as explained on page 269.
4. Install a FireWall-1 security policy that allows syslog service (UDP port 514)
from the router to the gateway (Figure 190):
Figure 190: syslog Service in a Security Policy

5. Define and install a security policy on your router, in which at least one rule is III-1
enforced by the router. Define the Track field as Long (Figure 191). The router
sends logs to the gateway; view the log with the FireWall-1 Log Viewer.
Router Management
Figure 191: Long Tracking in a Security Policy
Importing a Router Access List

The last step in enabling router access is to import a router access list, as follows:
1. From the Security Policy main screen, choose Policy > Access Lists. The Router
Access Lists Operations screen appears (Figure 189 on page 278).
2. Check Import Access Lists. The Access List screen changes (Figure 192).
Figure 192: Router Access List Operations screen.

IV-1
3. Specify the following options:
Router — Select a router from the drop-down list.
Interface — Select an interface. Router Management
4. The drop-down list displays all the interfaces available for the selected router:
Direction — Check a direction.
Eitherbound — Eitherbound means both inbound and outbound.
5. Select a display type by checking one of the following:
Ascii Access Lists — Check to display the access list to the screen.

Graphical Rule Base — Check to display the access list in the rule base.
6. Click OK to finish.

Lab 16: Importing Router Access Lists into the Rule Base (Solaris Only) III-1
Objective: Use the router access-list importation feature to turn a router’s access list
Router Management
into a rule base. This lab only works for Solaris.
Scenario: In order to bring an existing Cisco router under the control of a security
policy, you will import the router's access list and turn it into rules in a rule base.
If you cannot perform this lab in class, then this becomes a discussion lab.
4Create a router object

Define the network object for the Cisco router:
1. Pull down the Manage menu and choose Network Objects.
2. Click New and select Router:
Specify the name of the router and the IP address of the closest interface.
Next specify the type of the router. Use the list box to select CISCO.
Location should be Internal.
Select a color for the router network object.
Select the Interfaces tab and add any additional interfaces using the Add button.
3. Select the Setup tab.
4. Enter the management information for the router: access-list number, username,
password, enable username, enable password, IOS version and interface
directions.
5. Click OK.
4Import the router’s access list IV-1
1. Pull down the Policy menu and choose Access Lists.
2. Click the Import Access List radio button.
3. Indicate the network object for the router from which you will be importing the Router Management
access list by pulling down the list box labeled Router:
Select an Interface by pulling down the list box labeled Interface.
Select a direction.
Choose a display type for the access list using the buttons under Display Type.
4. Check the rule base for unknown network objects and edit these objects and

282 Lab 16: Importing Router Access Lists into the Rule Base (Solaris Only)
complete their information. Do this by double clicking the mouse or pointer

button on the unknown object.
4Save the rule base for the router access list

Review III-1
Summary Routers are an integral part of an enterprise network, often sitting at the edge of
Router Management
network boundaries. FireWall-1 allows security engineers to manage a variety of
routers, manage the security policies of routers within security policies, and manage
multiple routers. FireWall-1 allows security engineers to maintain security on routers,
thus reducing the load on network firewalls and adding efficiency to router-security
management. FireWall-1 supports the following routers and features:
• Bay Networks routers, versions 7.x - 12.x

• Cisco routers, IOS versions 9 - 11
• Cisco PIX Firewall, versions 3.0 and 4.0
• 3Com NetBuilder, version 9.x
• Microsoft RAS (Steelhead) Routers for Windows NT server 4.0
• Cisco PIX Import Security Policy
• PIX, Cisco, 3Com Logging
In addition, FireWall-1 provides the means to add extra security by using routers in a
firewalled network.
Review Questions 1. Why is router management important in a firewalled network?
2. How do you set up router management in FireWall-1?
IV-1
3. How do you implement router security using FireWall-1?
Router Management
4. What router features does FireWall-1 include?

284 Review
5. What relationship does an access list have with a router?
6. What are the steps to enable router logging?

II-2
Navigating In FireWall-1
Unit IV — Chapter 2: IV-2
Account Management
Account Management
Client
Introduction
Client
Account management for a large network can be a daunting task. Maintaining
synchronized user databases is a time consuming chore. Organizations that have
multiple user databases in one firewalled network can appreciate a process where all
databases are maintained from one location. FireWall-1 allows such a process through
the use of the Account Management Client.
Security engineers have the ability to define and maintain databases through the
Account Management Client using the Lightweight Directory Access Protocol
(LDAP). The Account Management Client is an independent module used to integrate
an LDAP server with FireWall-1 user authentication. This chapter includes the
following topics:
• Definition of LDAP and X.500 Standard
• Installation and set up of Account Management Client
• Application of Account Management Client to the FireWall-1 security policy
Objectives • Recite a brief history of LDAP and the X.500 standard

• Define distinguished name
• Demonstrate how to install the Account Management Client
• Demonstrate how to create users, groups, and templates using the Account
Management Client GUI
• Demonstrate how to apply the Account Management Client to a security policy
Key Terms • LDAP

• X.500
• distinguished name
285
286
• Account Management Client

• account unit
• schema checking

Unit IV — Chapter 2: Account Management Client 287
Lightweight Directory Access Protocol II-2
Lightweight Directory Access Protocol (LDAP) is used to communicate with a server
that holds information about users and items within an organization. LDAP is the
lightweight version of the X.500 ISO standard. Each LDAP server is called an IV-2
“Account Unit.” Three features of LDAP are as follows:
Account Management
• LDAP is based on a client/server model in which an LDAP client makes a TCP
connection to an LDAP server
• Each entry has a unique distinguished name
• Default port numbers are 389 for a standard connection and 636 for a Secure
Sockets Layer (SSL) connection.
Client
X.500 History The purpose of electronic directories is not much different from that of printed
directories. Printed directories provide names, locations and other information about
people and organizations. In a LAN or WAN, this directory information may be used
for e-mail addressing, user authentication (such as logging on and passwords), or
network security (such as user-access rights). A directory may also contain
information on the physical devices on a network (such as PCs, servers, printers,
routers and communication servers) and the services available on a specific device
(such as operating systems, applications, shared-file systems and print queues). This
information may be accessible to applications and end users.
Early network directories were most often developed specifically for particular
applications. In these proprietary directories, system developers had little or no
incentive to work with any other system. But systems users, in an effort to rationalize
their ever-increasing workload, sought ways to share access to and maintenance of
directory databases with more than one application. This dilemma engendered the
concept of the directory as a collection of open systems that cooperate to hold a
logical database of information. In this view, users of the directory, including people
and computer programs, would be able to read or modify the information or parts of it,
as long as they had the authorization to do so. This idea grew into the definition of
X.500.
In the client-server environment of the application layer of the Open Systems

Interconnection (OSI) model, directory functionality (directory administration,
authentication and access control), was initially developed to handle management of
e-mail addresses in conjunction with the OSI Message Handling application (X.400).
However, it was recognized as having potential use with many applications and,
therefore, was defined as a separate module or standard: ITU-T Recommendation
X.500 (also known as ISO/IEC 9594: Information Technology — Open Systems
Interconnection — The Directory).

288 Lightweight Directory Access Protocol
Multiple LDAP There are several advantages in using more than one LDAP server, including the
Servers following:
• Compartmentalization by allowing a large number of users to be distributed
across several servers
• High availability by duplicating information on several servers
• Remote sites can have their own LDAP servers that contain the database, thus
speed up access time
Distinguished Name A globally unique name for an entry, called a distinguished name (DN), is made by
associating the sequence of DNs from the lowest level of a hierarchal structure to the
root; the root becomes the relative DN. This structure becomes apparent when setting
up the Account Management Client (AMC), which manages multiple user databases
in one firewalled network.
Example
If searching for the name John Brown, the search path would start with John
Brown’s commonName. You would then narrow the search from that point, to
the organization he works for, to the country. In Figure 193, if John Brown
(commonName) works for the ABC Company, the DN syntax is:
“cn=John Brown, o=ABC Company, c=US”

II-2
root
IV-2
Account Management
US UK
country
(c)
ABC 123
Co. organization Co.
Client
(o)
John
John John
Brown commonName Brown
(cn)
Figure 193: Distinguished Name Hierarchy Example
The syntax “John Brown of ABC Company in the United States” composes
John Brown’s DN. A different John Brown who works at the 123 Company
could have a DN of the following:
“cn=John Brown, o=123 Company, c=UK”
The two common names “John Brown” belong to two different organizations
with different DNs.

290 Account Management Client Installation
Account Management Client Installation
To install and configure the Account Management module of FireWall-1, three

components are required. The following describes each component:
• An LDAP server containing user, group and template information
• FireWall-1
• Account Management Client (AMC)
Check Point does not provide an LDAP server. An evaluation copy of

Netscape’s LDAP Directory Server is included on the CD-ROM of
FireWall-1.
Windows The AMC application, included with FireWall-1, can be installed directly from the
Installation Screens CD-ROM or copied to the directory of choice and installed.
The Browse Screen

The Browse screen (Figure 194) allows you to specify the drive for the CD-ROM or
directory for the AMC to be installed:
Figure 194: Browse Screen

The Run Installation Program Screen II-2

The Run Installation Program screen (Figure 195) ensures the installation program
starts from the correct drive or directory:
IV-2
Account Management
Client
Figure 195: Run Installation Program Screen
Installing the AMC Windows

To install the AMC on a Windows NT or 95 workstation, follow these steps:
1. Click the Start menu and choose Settings.
2. Choose Control Panel.
3. Double-click on Add/Remove Programs.
4. Click the Install button.
5. Click Next.
6. In the command line screen, click Browse and enter the drive letter for the CD-
ROM.
7. Double-click the Windows folder.
8. Double-click the amc folder.
9. Double-click Setup.exe to start the installation process for AMC. You will see the
command line displayed in the New Installation Program screen.
10. Click Finish to begin the installation.

292 Account Management Client Installation
Solaris
To install AMC on a Solaris platform:
1. Become superuser.
2. Change to the directory in which the installation files are located (either on CD-
ROM or on the hard disk).
3. Type the following to install the AMC:
hostname# # pkgadd -d .
4. Select number 1 to install the AMC. Choices are as follows:
1) AMC Check Point Account Management Client (sparc) 1.0
2) CKPagent Check Point FireWall-1 Load Agent (sparc) 4.0
3) CKPfw Check Point FireWall-1 (sparc) 4.0
4) CKPfwgui Check Point FireWall-1 GUI (sparc) 4.0
5) CKPfwmap FireWall-1 HP OpenView Extension (sparc) 4.0,REV=98.01.26
Select package(s) you wish to process (or ’all’ to process all packages). (default:
all)

A Note About Starting the Account Management Client II-2
The LDAP server must be running in the background before starting the
AMC. The server and management client must bind with each other before
being able to talk to one another. IV-2
Before starting the AMC, you must do the following:
Account Management
1. Ensure Use LDAP Account Management is checked in the LDAP tab of the
Security Policy GUI’s Properties Setup Screen (Figure 196):
Client
Figure 196: The LDAP Tab
2. Create a host with the IP address of your LDAP server.

294 A Note About Starting the Account Management Client
3. Create a server object for an LDAP server using the LDAP Account Unit
Properties tabs (Figure 197):
Figure 197: LDAP Account Unit Properties Screen
4. Use the same logon DN that you created when you created the Netscape LDAP
server (cn=loginname, no spaces).

Adding LDAP Authentication Properties to a Security Policy II-2
To add LDAP authentication to the security policy, security engineers use the
following screens:
IV-2
• Security Policy Properties Setup
• LDAP Account Unit Properties
Account Management
The Security Policy Modify the LDAP tab of the Security Policy Properties Setup screen to add LDAP
Properties Setup authentication (Figure 198):
screen
Client
Figure 198: LDAP Properties Setup
The LDAP tab options are as follows:
Use LDAP Account Management — Check this option if User Authentication will
use LDAP Account Units, in addition to the FireWall-1 internal User Database.
If this option is checked, the other options in the screen are enabled. If this option
is not checked, User Authentication will use only the FireWall internal user
database.
Time-out on LDAP Requests: — An LDAP request will be considered to have timed
out after this period (specified in seconds).
Time-out on Cached Users — A cached user will be considered to no longer be valid
after this period (specified in seconds), and will be fetched again from the LDAP
Server.

296 Adding LDAP Authentication Properties to a Security Policy
Cache Size (Users) — This option specifies the number of users that will be cached.
Days before passwords Expire — Is the password specified in the General tab of the
Account Unit Properties screen expire after this period (specified in days).
This option is enabled when the checkbox is checked.
Number of entriesAU can return: — This option specifies the number of users that
can be returned in response to a single query to the account unit.
Display user’s DN at login: — Displays the user’s Distinguished Name at login. For
security purposes, it is recommended that this option not be enabled.
LDAP Account Unit Modify the LDAP Account Unit Properties screen to add LDAP authentication to a
Properties network object (Figure 199):
Figure 199: Setting up the LDAP Server
The LDAP Server options are as follows:

Name — The LDAP server’s name.
Comment — Descriptive text.
Host — The host on which the LDAP Server is running.
Port — The port on which the LDAP Server is listening.
Login DN — The DN that will be used to bind to the LDAP Server.
Password — The LDAP password.

LDAP Rights — Privileges on the LDAP Server. Make sure that Read and Write are II-2
both checked.
Color — The color of the server’s icon.
Priority — This account unit’s priority in relation to other account units.
IV-2
Branches — The branches of the LDAP directory which will be available when
connecting to this LDAP Server.
Account Management
Adding LDAP Add LDAP authentication as follows:
Authentication
1. Launch the FireWall-1 Security Policy GUI.
2. Select Policy, Properties from the main screen.
Client
3. Click the LDAP tab and modify the appropriate options.
4. Click OK and exit the Security Policy Properties Setup screen.

298 Starting Account Management Client
Starting Account Management Client
Whether using the Solaris or NT platform, be sure the LDAP server is

running before trying to connect the AMC to the server.
Windows To start the AMC in Windows NT or 95, do the following:

1. Click Start > Programs from the Windows desktop.
2. Click Account Management Client (Figure 200):
Figure 200: Accessing the AMC (Windows)
Solaris To run the AMC, type the following command:
hostname# /opt/AMC/accountMgm

Account Management Configuration II-2
The first time you access the AMC, there is no account unit set up. The AMC must
bind to the LDAP server. You will be prompted to set up the parameters for the
General, Encryption and Authentication tabs (Figure 201 on page 300, Figure 202 on IV-2
page 301, and Figure 203 on page 302).
Account Management
The Account Unit
Properties Screen Access this screen from the FireWall-1 Security Policy GUI.
The Account Unit Properties screen defines how to access an account unit on an
Client
LDAP server. By entering the DN, the AMC will connect to the server with the
specific DN for the branches that were set up in the LDAP database.
To configure account management, use the following tabs on the Account Unit
Properties screen:
• General
• Authentication
• Encryption

300 Account Management Configuration
The General Tab The General tab sets up the host and account unit for the AMC (Figure 201):
Figure 201: Account Unit Properties — General Tab
The following are the General tab options:

Name — The name of the LDAP server (account unit).
Comment — Any descriptive text about this LDAP server.
Host — The LDAP server’s IP address or hostname.
Port — 389 for a standard connection and 636 for an SSL connection.
Login DN — The Distinguished Name (DN) used to bind to the LDAP server and the
AMC.
Password — The Host password.
LDAP Rights — The Management Station’s privileges on the LDAP server. Check R
or W or both.
Color — The color of the server’s icon.
Priority — This account unit’s priority in relation to other account units.
Branches — Branches of the directory tree retrieved after the Client binds to the
LDAP Server.
Fetch — Retrieve defined branches by clicking the Fetch button:
Add — The LDAP Branch Definition window is displayed. In the LDAP Branch
Definition window, enter the new branch added to the list box.
Edit — To change a branch definition, select the branch and click Edit.

Delete — To delete a branch from the list, select the branch and click Delete. II-2
The Authentication The Authentication tab sets up authentication properties for the LDAP server (Figure
Tab 202): IV-2
Account Management
Client
Figure 202: Account Unit Properties — Authentication Tab
The Authentication tab specifies the authentication schemes that will be supported by
the Firewall Module for users defined on this LDAP account unit.
The default scheme is the authentication scheme used when the LDAP server does not
provide a user’s authentication scheme. When an authentication scheme for the user is
defined on the account unit, but is not one of those checked in this window, then the
user will always fail authentication. However, if the LDAP server is read-only, then it
does not contain any FireWall-1-specific information (for example, authentication
schemes). The default scheme specifies which authentication scheme to use in this
case.

The Encryption Tab The Encryption tab sets up encryption properties for the LDAP server (Figure 203):
Figure 203: Account Unit Properties — Encryption Tab
The Encryption tab options are as follows:

Use Encryption (SSL) — Whether to connect to this server using SSL.
Server’s fingerprint — The server’s DN or key. FireWall-1 does not use a certificate
authority to obtain or confirm LDAP server keys. Before your first SSL connection,
you should obtain this data by fax or telephone or some other non-network means and
then enter the data in this field manually.
On subsequent SSL connections to the LDAP server, FireWall-1 requests the server’s
key and compares it to the one it previously obtained and stored. If there is a
discrepancy, an error message is issued. The DN is not considered to be secure, so it is
recommended to use a key instead.
Encryption Port — The port on the LDAP Server to which to connect. The default
port numbers are 389 for a standard connection and 636 for an SSL connection.
Min/Max Encryption Strength — Select the weakest (under Min) and strongest
(under Max) encryption method the account unit is prepared to use:
Authentication — The weakest method.
Export — The strongest exportable method.
Strong — The strongest method.

External User Group An external group is a user group whose members are defined in an external LDAP II-2
Screen directory server. You will add an external user group to your rule base.
IV-2
Account Management
Client
Figure 204: External User Group (LDAP) Screen
Name —The group’s name. This is the name that you will use in a rule base.
Color — The color of the group’s icon.
Account Unit — The account unit (LDAP server) on which the users in the external
group are defined. Select an account unit from the drop-down list. The account units
listed are those that were defined as LDAP account units in the LDAP Account Unit
Properties window. There are three possible ways of defining an external group based
on the users defined on the account unit:
All Account Unit’s Users — The external group includes all the users defined on
the account unit.
Only Branch — The external group includes all the users defined in the specified
branch on the account unit.
Only Group in Branch — The external group includes all the users defined in
the specified group on the account unit.
Configuring Configure Account Management in the Security Policy GUI:

Account
1. Select Manage > Servers from, the main screen.
Management
2. Click New and choose LDAP Account Unit. The LDAP Account Unit Screen
appears.
3. Modify the General tab (Figure 201 on page 300).
4. Click the Authentication tab and modify (Figure 202 on page 301).

5. Click the Encryption tab and modify (Figure 203 on page 302).
7. Click Manage > Users > New > External Group to create an external user group
Before entering a new user, group or organizational unit, make sure that ‘schema
checking’ is disabled in the LDAP server. When schema checking is turned off, restart
both the LDAP server and the AMC before trying to enter information. If not, you get
the error seen in Figure 205.
Figure 205: Schema Checking Error
AMC Logon Screen To start the AMC follow these steps:

1. Make sure the correct account unit is displayed in the Account Unit option or use
the drop-down list if multiple units are installed.
Figure 206: Account Management Client Logon Screen

2. Type the password. The password comes from the LDAP account unit that was II-2
installed and set up before installing the AMC.
3. Click OK.
IV-2
Account Management
Client

306 Creating an Object
Creating an Object
When the AMC first binds to the account unit (the LDAP server), the account unit
name appears with a red X next to its icon (Figure 207). The X indicates that the
account unit has not been created within the AMC.
X marks the spot!
Figure 207: AMC Binds to the LDAP Server
To create the new account unit, follow these steps:

1. Right-click on the red X that is over the name of the account unit.
2. When asked if you want to create this object, click Yes. The red X disappears;
now you can add organizational units, groups, templates and users.

Navigating the Account Management Client II-2
The toolbar buttons are shortcuts for menu commands. The actions of the buttons
duplicate actions that are available in the menus. To see a description for each button,
pass the mouse pointer slowly over the button. IV-2
Account Management
Figure 208: Account Management Client Toolbar Buttons
Button Menu Command Description
Client
File > New User Add a new user to the organization.
File > New Template Create a template for users.
File > New Group Create a group to encompass users.
File > Delete Table Entry Delete users, groups or templates.
File > Properties View user or group properties.
File > New Organizational

Create a new organizational unit.
Unit
File > Create Tree Object Create an object on the tree.
Edit > Query Search for users or groups.
Show all organizational units, users

Edit > Show All
and groups.
Edit > Sort by Full Name Sort users by full names.
Edit > Sort by Login Name Sort users by login names.
Help > Help Contents Displays help contents.

308 The Organizational Unit
The Organizational Unit
An organizational unit is created to hold lists of users, groups and templates. After
connecting to the LDAP server, the Account Management screen allows
organizational units, users, groups, and templates to exist as part of the LDAP
database. Likewise; if users and organizational units are created in the LDAP server
itself, they will also appear in the AMC database.
Figure 209: Account Management Screen
The left pane displays organizations and units within an organization. The right pane
displays all the users, groups and templates defined below the highlighted unit in the
tree shown in the left pane.
Creating an After creating the initial account unit, the next step is to add an organizational unit.
Organizational Unit Typically, an organizational unit is a major department name, but an organization is
represented by a company name, such as “Check Point.”
To create an organizational unit:

1. Right-click on the object created (the LDAP account unit) in the left pane of the
Account Management screen (Figure 209).

2. Select Add an Organizational Unit to open the New Organizational Unit screen II-2
(Figure 210):
IV-2
Account Management
Figure 210: Adding a New Organizational Unit
Client
3. Type the name (ou=organizational unit) of the new unit.
If you make a mistake while typing the organizational-unit name, use an
editor in Solaris or Windows NT to delete the incorrect organizational unit
in the LDAP server. Once you have done so, restart the above process. You
will not be able to correct a mistyped name after you press Add.
4. Click Add.
Deleting an The AMC does not allow deletion of an organizational unit from the GUI (true for
Organizational Unit Netscape’s LDAP server). The organizational unit is part of the directory setup and
must be edited/deleted with the command line in both NT and Solaris (Figure 211):
Figure 211: Deleting an Organizational Unit using a DOS Editor

310 The Organizational Unit
To delete the organizational unit from the AMC:

1. Start the appropriate command-line interface.
2. Locate ldapmodify.exe (Windows) or ldapmodify (Solaris).
3. Type the following command at the prompt:
ldapmodify -h <host> -d “cn=<your root>” -w <root
password>
4. Press Enter (ldapmodify will wait for input statements terminated by control-d).
5. To delete a branch, enter the following statements with this syntax:
dn: ou=name,o=name
changetype: delete
^d (to end input)
6. The following message appears:
deleting entry ou=name,o=name
7. Close and restart AMC to reflect the changes.

Defining Users II-2
Before creating a user, group, or organizational unit, be certain that Schema Checking
is disabled in the LDAP server (see page 304).
IV-2
The New User Use the New User screen (Figure 212) to set up AMC for each network user. The
Account Management
Screen following tabs are part of the New User screen:
• Identification
• General
• Authentication
Client
• Location
• Time
• Encryption
• Groups
Identification Tab
This initial screen (Figure 212) is the starting point to identify and set up properties for
each user. Users can be defined individually or you can add users to a group.
Figure 212: New User — Identification Tab

312 Defining Users
The following options are available for adding new users:

Login Name — User’s login name
Last Name — User’s last name
Full Name — User’s full name
Branch — Branch on the tree in which the user resides
Link to Template — Template to which the user’s definition is linked
General Tab
The General tab (Figure 213) allows you to add information about selected or new
users.
Figure 213: New User — General Tab
The General tab requires the following information:
User expires on (dd-mmm-yyyy): — Enter the month, date and year the user’s
access will expire.
From Template — If the user acquires properties from a defined template, select
From Template to implement the expiration date of this user.
Comment: — Enter comments regarding the user.
From Template — If the user acquires its properties from a defined template,
select From Template to pull comments from the previously-defined template.
Email: — Enter the user’s e-mail address.

Authentication Tab II-2

Select a scheme for each user from the Authentication Scheme list. For some schemes,
additional data is required. After selecting a scheme, the content of the screen changes
and displays the required options.
IV-2
Account Management
Client
Figure 214: New User — Authentication Tab
The following list options are available on the Authentication tab:

S/Key — User is challenged to enter the value of the requested S/Key iteration.
SecurID — User is challenged to enter the number displayed on the Security
Dynamics SecurID card.
O/S Password — User is challenged to enter their operating system password.
Internal Password — User is challenged to enter their internal FireWall-1 password
on the gateway.
RADIUS — User is challenged for a response defined by the radius server.
Axent Pathways Defender — User is challenged for a response defined by the Axent
Defender server.
TACACS — User is challenged for a response defined by the TACACS or TACACS+
server.

314 Defining Users
Location Tab
The location tab (Figure 215) controls a user’s allowed source and destination. You
can control which users are prohibited from certain segments of the network. For
example, a user may be allowed in the human resources area, but not in the accounting
area.
Figure 215: New User — Location Tab
The following are the Location tab options:

Source — If Any is checked, no restriction exists on the user’s source. If From List is
selected, the user is allowed to connect only to the listed network object(s). To add a
host to the list of allowed hosts, enter the host IP address or name in the text box next
to the Add > Source button and click Add.
Destination — The lower part of the tab specifies allowed destinations. If Any is
checked, the user has unrestricted access to any destination that is allowed by the rule
base.

Time Tab II-2

The Time tab (Figure 216) specifies the days of the week and the times of day that the
user is allowed to connect.
IV-2
Account Management
Client
Figure 216: New User — Time Tab
The following options are available on the Time tab:

User may connect at — Check the days of the week to specify days the user may
access the LDAP database. To allow everyday access, check all check boxes.
From (hh:mm): — Enter the start time of the time range in which the user has access
to the database.
To (hh:mm): — Enter the end time of hours the user has access to the database.
Examples for setting access times:
To allow the user access from 8:00 A.M. to 5:00 P.M., set the From time as 08:00
and the To time as 17:00.
To allow the user 24-hour (unlimited) access, set the From time as 00:00 and the
To time as 23:59.
If certain days are selected with a certain time period, the time period
applies to all selected days.
From Template — Check this option to use the template given in the Link to
Template option in the Identification tab of the New User screen.

316 Defining Users
Encryption Tab
The Encryption tab (Figure 217) specifies the encryption and data integrity methods
for Client Encryption (SecuRemote) for the user:
Figure 217: New User — Encryption Tab
The following options are available on the Encryption tab:
FWZ Settings
Session Key Encryption Method — The encryption algorithm for session keys.
Available choices depend on the encryption algorithms installed.
Clear — Means no encryption.
Any — Means the session key encryption method is chosen by another party.
FWZ1 — Signifies the encryption algorithm for session-key encryption and data
encryption.
Data Encryption Method — is the encryption algorithm for communication packets.
Available choices depend on the encryption algorithms installed.
Clear — Means no encryption.
Any — Means the session key encryption method is chosen by another party.
DES and Triple DES — Signifies the encryption algorithm for session-key
encryption and data encryption.
Data Integrity Method — Sets the cryptographic checksum method used for
ensuring data integrity.

Password expires after — Sets the time (minutes) after which the password will II-2
expire, if you use a single-use password.
Successful Authentication Track — Sets the tracking method.
Groups Tab IV-2

The Groups tab (Figure 218) lists the groups to which the user belongs. You must
define the group name and any properties before adding users to the group.
Account Management
Client
Figure 218: New User — Groups Tab
Available Groups: — The groups available (previously defined) to this user.
Belongs to Groups: — The groups to which this user belongs.
Add Template’s Groups — The groups defined in the template given in the Link to
Template option in the Identification tab.
Adding Account To add account management to new users:

Management to New
1. Select New User from the File menu.
Users
2. Enter the relevant information on the various tabs.
Users can inherit data from a template by specifying the name of the
template on the Identification tab and checking From Template in each tab.

318 Managing Templates
Managing Templates
A definition of a user can be based on a template from which the user inherits outlined
properties. In AMC, a template is “live,” which means that changes made to a
template are applied to all users who continue to inherit at least some of their
properties from the template.
The tabs and options of the New Template screen correspond to those of the New User
screen. Security engineers set up the Identification tab based on the needs of a global
template.
The New Template In the New Template Screen (Figure 219), security engineers modify the Identification
Screen tab to add user templates:
Figure 219: New Template Screen — Identification Tab
The following are the Identification tab options:

Full Name: — The template’s name
Branch: — The organizational unit to which this templates belongs; use the drop-
down list to find the correct unit.

New User with Template II-2

When adding new users to the database, you may apply template parameters.
Templates are defined and listed in the Link to Template option (Figure 220). Click
the drop-down list to view and select template to apply to the user.
IV-2
Account Management
Client
Figure 220: New User to Template
Defining a New To define a new template, follow these steps:

Template
1. Select New Template in the File menu.
2. Enter the name of the new template.
3. Accept or select a branch in which to apply the template.
4. Click Save when finished.

320 Managing Groups
Managing Groups
Groups are used as a single holding place for users with like properties. To define a
new group, use the New Group screen (Figure 221):
Figure 221: New Group Screen
The following are the New Group options:

Group Name: — The group’s name
Branch: — The organizational unit to which this group belongs; use the drop-down
list to find the correct unit. When FireWall-1 logs on to the gateway location, the
location has immediate access to the required authentication information in the
FireWall-1 user database. However, if an LDAP user logs on and must be
authenticated, the location communicates with the LDAP server to get the required
information.
Defining a New To define a new group, follow these steps:

Group
1. Select New Group from the File menu.
2. Enter a full name for the group.
3. Enter a branch for the group.
4. Click Save.
When installed, the user database, containing the proprietary information about
FireWall-1 users, is downloaded to where the gateway resides.

Lab 17: Using LDAP II-2
Objective: Student will set up the firewall to use LDAP to access a directory server
(X.500) for a user database.
IV-2
Scenario: Your company has begun using LDAP to manage its resources. You will
modify the firewall to use LDAP for external user groups in authentication.
Account Management
4Enable LDAP Account Management
Check to verify that LDAP Account Management is enabled:
1. Click Policy > Properties and click the LDAP tab.
2. Verify that Use LDAP Account Management is checked.
Client
3. Check the option for Display User’s DN at Login (for classroom purposes).
4. Click OK.
4Define an LDAP network object

Make sure your LDAP server is defined as a network object:
1. Click Manage > Network Objects > New.
2. Select Workstation from the New menu.
3. Enter the information for the network machine that hosts your LDAP server.
4Define your LDAP accounting unit

1. Click Manage > Servers > New.
2. Select LDAP Account Unit from the New menu.
3. In the LDAP Account Unit Properties dialog, type the Name and select the host
machine that you defined in the previous step.
4. Type the Login DN, Password, Rights, Priority, and so on.
5. Add or Fetch the branches to be used from the LDAP Account Unit.
6. Specify authentication and encryption parameters using the respective tabs in the
LDAP Account Unit Properties screen.

322 Lab 17: Using LDAP
4Set up external LDAP groups

Set up external groups as LDAP groups:
1. Click Manage > Users > New > External Group.
2. In the External User Group (LDAP) screen, name the group (such as Testgrp) and
color.
3. From the Accounting Unit pull-down list, select the Accounting Unit that you
defined previously.
4. Set the group’s scope in the respective box. Specify all users, subtrees or specific
groups.
4Create LDAP user account with AMC

1. Launch AMC.
2. Click Manage > Users.
3. From the Accounting Unit pull-down list, select the LDAP Accounting Unit
created above and click Manage.
4. In the AMC GUI, click File > New User.
5. Configure the Identification tab, including Login Name, Last Name and Full
Name.
6. Configure the Authentication tab:
uncheck the From Template checkbox
for Authentication Scheme, select Internal Password
enter New Password in the Settings window
select Save at the bottom of the window
4Create the authentication rule in the security policy

1. Click Edit > Add Rule > Top.
2. Configure Source as: external_group@internal_net (for the external_group use
the external group name created above, for the internal_net use the network object
created for your city’s internal network)
3. Configure Destination as: Any
4. Configure Service as: Any
5. Configure Action as: Client Authentication

4Install and test new security policy II-2

1. Install security policy.
2. Telnet to port 259 of firewall from the internal client.
3. Enter LDAP login name and password. IV-2
Account Management
The firewall should authenticate successfully.
Client

324 Review
Review
Summary The Account Management Client (AMC) is a means of authenticating and managing
users through a Lightweight Directory Access Protocol (LDAP) server. Individual and
multiple LDAP servers can be used. The benefit of multiple servers includes:
• Compartmentalization by allowing a large number of users to be distributed
across several servers
• High availability by duplicating information on several servers
• Remote sites can have their own LDAP servers that contain the database, thus
speeding up access time
A globally unique name for an entry, called a distinguished name (DN), is made by
associating the sequence of DNs from the lowest level of a hierarchal structure up to
the root that becomes the relative distinguished name. Organizational units are part of
the root and are built upon with additions of company names and departments. Users
and groups of users are added to departments.
Templates are used to apply features to users without having to recreate those features
for each user.
Review Questions 1. What is the purpose of the AMC?
2. What is an object?
3. How do you create an object?
4. What is a distinguished name?

III-4
Load Balancing
Load Balancing
Introduction
Consider the following scenario: A network uses one server that cannot handle the
amount of traffic flowing through it. The security engineer obtains additional servers
to handle the load, but this creates another problem. Most of the network traffic is still
flowing through only one of the servers.
IV-3
To alleviate this problem, FireWall-1 load balancing redirects traffic and distributes it
among several servers. This reduces the load on any one server. Load balancing helps
security engineers manage network traffic from one firewalled computer.
Load Balancing
FireWall-1 load balancing tools include the following:
• HTTP redirect
• Load measuring
• HTTP logical server
• Load balancing algorithms
• Rule base order
Objectives • Define load balancing

• List and explain the three load balancing components
• Identify the steps necessary to set up HTTP redirect
• Demonstrate how to configure load balancing
• Demonstrate how to create an HTTP logical server
• Compare and contrast the different load balancing algorithms
• Describe “others” load balancing
• Explain why rule base order is important when using load balancing
325
326
Key Terms • load balancing

• logical server
• persistent server mode
• Connect Control Module
• HTTP redirect
• load measuring
• server group
• load balancing algorithms
• load balancing daemon
• load measuring agent
• address resolution protocol

Unit IV — Chapter 3: Load Balancing 327
How Load Balancing Works III-4
Load balancing allows several servers to share and distribute the network load. The
FireWall-1 security engineer does this by creating a network objects of physical
servers, which is a group of physical servers that distributes network traffic among its
Load Balancing
group. Each server has a unique IP address, which is the address of the device through
which packets are routed for load balancing. Using address resolution protocol
(ARP), which is a TCP/IP protocol used to convert an IP address into a physical
address, FireWall-1 load balancing ensures packets destined to the IP address of a
logical server pass through the Firewall Module and to the appropriate physical server.
Figure 222 illustrates how load balancing works in FireWall-1: When a packet comes
through the Firewall Module, FireWall-1 decides to which physical server to send the
packet. Using a specified load balancing method, FireWall-1 routes the packet to the
specific physical server — whether in Group A, B or C — depending upon which
logical server is contacted. IV-3
Load Balancing
Packets flow
through the
firewall to the
logical servers.
Logical Logical Logical

Server 1 Server 2 Server 3
Group A Group C
Group B
Figure 222: Load Balancing in FireWall-1

328
Load Balancing There are several load balancing components in FireWall-1. Each component has a
Components different function for managing traffic in a firewalled network. The Connect Control
Module is the FireWall-1 module containing the load balancing algorithms.
FireWall-1 load balancing algorithms determine which physical server will fulfill a
communication request. Connect Control provides a redirection mechanism, ensuring
that all traffic (from the same connection) is directed to the same server.
The FireWall-1 load balancing components are:

• Load balancing daemon
• Load balancing algorithms
The Load Balancing Daemon

The Connect Control load balancing daemon resides on the firewalled computer.
(The load balancing daemon is used to generate HTTP redirect requests to make a
Web browser initiate a new connection to a physical server’s IP address.) The daemon
directs client packets to a server and notifies the client that all remaining connections
must be directed to the IP address of the selected server. Once a client has established
a connection and the load balancing daemon has determined that the incoming packet
must be load balanced, the remainder of the client’s communication is conducted
without the load balancing daemon’s intervention.
Persistent server mode allows a session to retain its load balancing method
until the session has ended (See “Logical Server Properties Screen” on
page 345). One example of this is loading multiple Web pages from one
site. Because each page is from the same site, FireWall-1 does not require a
new session to re-establish the original load balancing algorithm.
Load-Balancing Algorithms
When a communication request to a logical server’s IP address reaches the Firewall
Module, the FireWall-1 load balancing algorithm determines which physical server
will fulfill the request. FireWall-1 includes five load balancing algorithms. Each
algorithm prevents any server from handling a disproportionate volume of traffic.
The FireWall-1 load balancing algorithms are:

Server Load — Determines the load of each physical server.
Server Load requires a load measuring agent installed on each server.
Round Trip — Determines round trips between the firewall and each physical
server.
Round Robin — Chooses the next physical server in the server group.

Random — Chooses the physical server closest to the client, based on domain III-4
name; this is only useful for HTTP load balancing, because “others” load
balancing requires connections to pass through the firewall.
Domain — Chooses the physical server closest to the client, based on domain
name; this is only useful for HTTP load balancing, because “others” load
balancing requires connections to pass through the firewall.
Load Balancing
Connect Control is used for HTTP load balancing; all other load
balancing uses dynamic address translation.
IV-3
Load Balancing

330 Logical Server Types
Logical Server Types
HTTP Redirect HTTP load balancing uses a redirection mechanism ensuring that all communication
requests are directed to the appropriate server. This is vital for many Web applications,
such as HTTP applications. HTTP redirect is FireWall-1’s mechanism for directing
HTTP requests destined for a single HTTP logical server to multiple HTTP physical
servers.
When a client initiates communication with a logical server, HTTP redirects the
connection to the proper physical server, through the load balancing daemon. The
daemon notifies the client that subsequent connections should be directed to the IP
address of the selected server, rather than the IP address of the logical server.
The remainder of the session is conducted without the load balancing daemon’s
intervention. All operations are transparent to security engineers and end users (Figure
223).
n Step 1:
Client Ø Firewall Ø Daemon
Firewall with
Load
Balancing
Daemon
n Step 2:
Daemon Ø Server
Server 3
Server 1
n Step 3: Redirect Server 2

client request to
server
Figure 223: HTTP Redirect
1 FireWall-1 detects an HTTP request to a logical server and redirects the request to
the load balancing daemon, which resides on the firewalled computer.
2 The daemon notifies the client that the request is being redirected to the
destination physical (HTTP) server.

3 The rest of the session is conducted between the client and the destination server, III-4
without the intervention of the load balancing daemon.
If you are using HTTP redirect on the firewall, you must create two rules:
the first rule specifies the logical server for the HTTP session to connect.
The second rule specifies the physical server group that will communicate
Load Balancing
directly with the client throughout the remainder of the session.
Other Load Other load balancing places entries in the FireWall-1 address translation tables for a
Balancing connection. Other load balancing allows a server’s IP address to be a logical server’s
address from a firewall to a client, and a physical server’s IP address from a server to
the firewall.
IV-3
Load Balancing

332 Load Balancing Algorithms
Load Balancing Algorithms
The Connect Control Module is built into FireWall-1 and contains the load balancing
algorithms. FireWall-1 load balancing algorithms determine which physical server
will fulfill a communication request. When a service request reaches a firewalled
computer, the FireWall-1 load balancing daemon uses an algorithm to determine
which load balancing method to use.
The FireWall-1 load balancing algorithm prevents any server from handling a
disproportionate volume of traffic. In the case of the server load algorithm, each
incoming connection request is directed to the server with the lightest load.
Once an algorithm is established, a session retains its load balancing

method until the session has ended. One example of this is loading
multiple Web pages from one site. Because each page is from the same
site, FireWall-1 does not require a new session to re-establish the original
load balancing algorithm.
Server load and round trip are HTTP load balancing algorithms. The main difference
between the two is that server load uses FireWall-1 load measuring — and therefore
requires the FireWall-1 load measuring agent installed on the physical servers — and
round trip does not.
Server Load (HTTP)

The server load algorithm queries all physical servers in a logical server group to
determine which is best able to handle a communication request. Load measuring
must be installed on each physical server. Figure 224 illustrates how the server load
algorithm distributes communication requests.
n Step 1: Client
sends HTTP request n Step 2: Load Balancing Daemon uses
Firewall with
Load
Server-Load Algorithm to query traffic
Balancing on the physical servers
Daemon
Client
Server 1
with Load Measuring
n Step 3: Redirect Server 2
with Load Measuring
client request to server
Server 3
with Load Measuring
Figure 224: The Server Load Algorithm

1 A client sends an HTTP communication request to a logical server. III-4

2 The load balancing daemon queries traffic on the HTTP physical servers through
Logical Server 3, using the server load algorithm. The load balancing daemon
then sends a redirect to the client with the IP address of the chosen physical server,
the first server in Figure 224.
Load Balancing
3 The client communicates directly with the physical server, assuming the server is
using persistent-server mode.
Round Trip (HTTP)

The round trip algorithm uses PING to determine the round trips between the firewall
and each physical server and chooses the server with the shortest round-trip time.
Security engineers use the round trip algorithm when there is no load
measuring agent installed. When an internal network is not using an
architecture supported by FireWall-1, such as LINUX, HP MPE or IBM
IV-3
AS/400, load measuring cannot be installed. Figure 225 illustrates how the
round trip algorithm distributes communication requests.
n Step 1: Client n Step 2: Load Balancing Daemon

sends request
Load Balancing
PINGs each server 3 times and
Firewall with
Load averages the shortest round-trip time
Balancing
Daemon
Server 3
Server 2 Server 1
n Step 3: Redirect
client request to server with
shortest round-trip time
Figure 225: Round-Trip Load Balancing
1 A client sends an FTP communication request to a firewalled computer.

2 The load balancing daemon sends a PING to each of the servers that belong to an
FTP logical server.
3 The daemon notifies the Firewall Module which server has the shortest round trip
time. The daemon then allows requests to the appropriate physical server.

Round Robin
With round robin load balancing, the FireWall-1 daemon chooses the next server in
the list. (Round robin is a sequential algorithm.) The round robin algorithm assumes
that all physical servers are equally capable of servicing connection requests,
regardless of location or server loading. Requests are directed to servers in sequential
order. If a server fails or is unreachable, the daemon ceases directing connections to
that server until it is available.
Figure 226 illustrates round robin load balancing:
n Step 1: Client
sends request n Step 2: Load Balancing Daemon
Firewall with chooses next server in sequence
Load
Balancing
Daemon
Client 1H[W
Server 3
Server 2 Server 1
n Step 3: Redirect
client request to selected server
Figure 226: Round Robin Load Balancing
Random
The load balancing daemon chooses a server at random. When all other network
variables are deemed equal, the daemon directs connection requests to servers on a
random basis.

Figure 227 illustrates random load balancing: III-4
n Step 1: Client
sends request n Step 2: Load Balancing Daemon
Firewall with chooses a server at random
Load Balancing
Load
Balancing
Daemon
Client 5ROOWKHGLFH
Server 3
Server 2 Server 1
n Step 3: Redirect
client request to selected server
IV-3
Figure 227: Random Load Balancing
Domain
In this load balancing algorithm, FireWall-1 chooses the closest server based on
domain names. This algorithm is useful outside a network, such as when a domain
Load Balancing
name identifies the location of a remote device.
Figure 228 illustrates domain load balancing:
n Step 2: Load
n Step 1: Client Balancing Daemon
sends request notifies client of
Firewall with
Load redirection based on
Balancing domain name
Daemon
*REDFN
Client DQRWKHU
n Step 3: Redirect ZD\
client request to a closer domain
Figure 228: Domain Load Balancing

Load Measuring Load measuring is the FireWall-1 load balancing component that is installed on any
type of server using the server load algorithm for load balancing. Using load
measuring, the firewall is able to direct communication requests to a server with the
lightest traffic.
The Load Measuring Agent

The only way for the firewall to know the server’s load, and to what extent this server
can handle additional communication requests, is for security engineers to install a
load measuring agent on each server. A load measuring agent is an application that
allows the load balancing daemon to query a server’s load.
When an internal network is not using an architecture supported by FireWall-1 (such

as LINUX, HP MPE or IBM AS/400), security engineers cannot install Check Point’s
load measuring agent.
The Miscellaneous Tab

To configure load measuring, use the Miscellaneous tab in the Security Policy
Properties Setup screen (Figure 229).
Figure 229: Load Measuring in the Security Policy GUI
The load measuring options are as follows:

Load Agents Port — Set up load measuring on the port number (predefined in
FireWall-1) specified in Load Agents Port. This port returns information about the
server’s load to FireWall-1. All load measuring servers in a configuration must use the
same port number.

Load Measurement Interval — The interval at which load measurement measures III-4
the network load. FireWall-1 provides the default interval.
Log Viewer Resolver Properties — The Firewall load balancing daemon that
monitors load balancing. Security engineers do not view this directly.
Load Balancing
Configuring Load Load measuring is installed on the firewall during the FireWall-1 installation. To
Measuring configure load measuring, follow these steps:
1. Click Policy > Properties from the Security Policy GUI main screen.
2. Click the Miscellaneous tab and select options (Figure 229).
IV-3
Load Balancing

338 Setting up Load Balancing Algorithms
Setting up Load Balancing Algorithms
Use the FireWall-1 Security Policy GUI to choose which load balancing algorithm to
use. Figure 230 shows the round robin algorithm for an FTP server selected in the
Logical Server Properties screen.
The Logical Server The set up load balancing algorithms, modify the Logical Server Properties screen
Properties Screen (Figure 230):
Figure 230: Server Load Algorithm
The Logical Server Properties screen options are as follows:
Name — The object’s name.

IP Address — A 32-bit address that uniquely identifies this interface.
Get Address — Resolves the server’s name to an IP address.
Comment — Text displayed on the bottom of the Network Object screen when this
server is selected.
Color — Color of the server’s icon.
Server’s Type — HTTP or Other.
Persistent Server Mode — Once a client is connected to a physical server, the client
continues to connect to that server for the duration of a session.
Servers — The server group already defined in the Servers screen.

Balance Method — Server Load, Round Trip, Round Robin, Random or Domain. III-4
Setting up To set up load balancing algorithms, follow these steps:

Load-Balancing
1. Click Manage > Network Objects > from the Security Policy GUI main screen.
Algorithms
Load Balancing
2. Select the appropriate logical server and click Edit.
3. Click the appropriate balance method.
IV-3
Load Balancing

340 HTTP Logical Server
HTTP Logical Server
Load balancing allows several servers in one network to share and distribute the load
among themselves, all while being protected by one firewalled computer. FireWall-1
does this through a logical server, which represents a group of servers that provide the
same services. The logical server is a legal IP address that is mapped to the external
interface of your firewall. The logical server points to a group of servers on which
your firewall is performing load balancing.
To create an HTTP logical server, follow these steps:

1. Create a network object(s) for the physical server.
2. Create an HTTP server group.
3. Create an HTTP logical server.
The Workstation Before creating a logical server, define the physical servers that will be part of the
Properties Screen logical server group. Add a network object to create an HTTP server (Figure 231).
Figure 231: HTTP_Server_1
The Workstation Properties screen options are as follows:

Name — The name of the server.
IP Address — The IP address that identifies this server.

Get Address — Retrieves the IP address; reduces the possibility of entering the III-4
address incorrectly.
Comment — Any information that describes this server.
Location — Internal objects on the server appear as external to other management
servers:
Load Balancing
Internal — Protected by the firewall.
External — Outside the firewall.
Type — Defines the type of server:
Host — A server with a single IP address.
Gateway — A server with multiple IP addresses.
FireWall-1 Installed — Indicates a FireWall-1 module is installed on the server.
Exportable — Allows remote users access to the server.
IV-3
Version — The FireWall-1 version installed on the server.
Creating a Server To create the server object, follow these steps:

Object
1. Click Manage > Network Objects > New > Workstation from the FireWall-1
Load Balancing
Security Policy main screen.
2. On the General tab, select the appropriate options (Figure 231 on page 340).
3. Repeat for additional HTTP servers, for example: HTTP_Server_2,
HTTP_Server_3, and so on.

The Group To create an HTTP server group, include all physical servers providing the same
Properties Screen services in the Group Properties screen (Figure 232):
Figure 232: HTTP-Server Group Properties
The following are the Group Properties options:

Name — The group’s name.
Comment — Text displayed at the bottom of the Network Object screen when this
group is selected.
Color — Color of the group’s icon.
Not In Group — Objects which do not belong to the group.
In Group — Objects included in the group.

Creating a Server To create a new server group, follow these steps: III-4
Group
1. Click Manage > Network Objects from the Security Policy GUI main screen.
2. Select New and Group from the Network Objects pull-down menu.
3. The Group Properties screen appears (Figure 233):
Load Balancing
IV-3
Load Balancing
Figure 233: The Group Properties Screen
4. Type the server group’s name in the Name field.
Identify the server group by naming it as explicitly as possible, such as

HTTP_LS_Group. Doing this eliminates any confusion between server
groups and logical servers.

5. Enter a description of the server group in the Comment field. This text is
displayed on the bottom of the Network Object screen when this group is selected
(Figure 234):
Figure 234: Comment for a Server
6. Select the color of the server group’s icon.

7. Add the appropriate servers to this group:
a. Highlight a server in the Not in Group option.
b. Click Add.
c. Highlight additional servers and click Add
8. The new server group appears (Figure 232 on page 342).

The Logical Server The logical server is the server controlling the group of physical servers and displays III-4
Properties Screen in the Logical Server Properties screen (Figure 235):
Load Balancing
IV-3
Figure 235: Logical Server Properties Screen
Load Balancing
Refer to Figure 230 on page 338 for a description of each of the Logical
Server Properties option.
Creating a Logical To create a logical server, follow these steps:

Server
1. Click Manage > Network Objects from the Security Policy GUI main screen.

2. Click New > Logical Server. The Logical Server Properties screen appears
3. Type an object (server) name in the Name option.
Identify the logical server by naming it as explicitly as possible, such as

HTTP_LS_Server. Doing this eliminates any confusion between logical
servers and server groups. The logical server is a legal IP address that is
mapped to the external interface of your firewall. The logical server points
to a group of servers on which your firewall is performing load balancing.
4. Enter the server’s IP Address in the IP Address field. (The logical server’s IP
address is the address of the device routed to the Firewall Module or the device
through which packets are routed for load balancing.)
5. Click Get Address to resolve the server’s name and IP address. If FireWall-1
cannot resolve the name and address, an error message appears (Figure 236):
Figure 236: Address-Resolution Error Message
The above error message is a symptom of a DNS problem, assuming the IP

address is correct.
6. Add descriptive text to the Comment field, if necessary. This text displays at the
bottom of the network-object screen (Figure 234 on page 344) when you highlight
the logical server.
7. Select the color of the server’s icon from the pull-down Color menu.
8. Select the server type, in this case, HTTP.
9. Click or deselect Persistent Server Mode.
If this option is checked, once a client connects to a physical server in the

internal network, the client will continue to connect to that server for the
duration of the session.

10. Choose a server group from the pull-down Servers menu (Figure 237): III-4
Load Balancing
IV-3
Figure 237: Server Group in the Logical Server Properties screen
11. Choose the Balance Method.
Load Balancing
12. The completed Logical Server Properties screen is shown in Figure 238:
Figure 238: Logical Server Properties screen

348 Lab 18: HTTP Logical Server
Lab 18: HTTP Logical Server
Turn off persistent server mode, if necessary.
4Define a server group

1. Define a group object called http-group.
2. Place in the group all Web server objects in the classroom.
3. Click OK.
4Define a logical server object

1. Define a logical server object named http-farm:
IP address: 204.32.38.100
Servers: http-group
Server’s Type: HTTP
Balance Method: Round Robin
2. Click OK.
4Add inbound HTTP rule

Destination: www.yourcity.com
Services: http
Action: accept
4Add outbound HTTP rule

Destination: http-group
Services: http
Action: accept

4Add load balancing rule III-4

Destination: http-farm
Services: http
Load Balancing
Action: accept
4Install and test the rule base

1. Install the rule base.
2. From your Internet server, access http://204.32.38.100 repeatedly.
IV-3
Load Balancing

350 Load Balancing on Other Logical Servers
Load Balancing on Other Logical Servers
Overview In the Logical Server Properties screen, choose Other when the server is an FTP
(Figure 239):
Figure 239: FTP Logical Server
When you need to create other server types, you must understand how FireWall-1
handles load balancing. FTP (or other) load balancing is different from HTTP load
balancing. When Other is chosen under Server’s Type, load balancing is performed
using network address translation (Figure 240):
Figure 240: Address Translation in Load Balancing

In Figure 240, the following applies: III-4

85.10.1.4 — The client’s IP address.
204.32.38.101 — The logical-server’s IP address.
192.168.1.1 — The physical server.
Load Balancing
1 The client sends a packet to the firewall; the packet is sent to the FTP logical
server, using IP address 204.32.38.101.
2 The load balancing daemon ensures the packet is load balanced via address
translation. The kernel translates the packet to the physical server’s IP address
(192.168.1.1), so that it can be properly load balanced.
3 When the packet exits the network, the load balancing kernel translates the packet
from 192.168.1.1 to 85.10.1.4 using backward address translation. The kernel
does this so the client will be able to match the reply IP address to its original IP
address.
IV-3
Address Resolution As mentioned earlier, in load balancing for other services, the IP address for a logical
Protocol (ARP) server is routed to the Firewall Module or the device through which packets are routed
for load balancing. Using ARP, the load balancing daemon ensures packets destined to
the IP address of a logical server pass through the Firewall Module and to the
Load Balancing
appropriate physical server.
To enable ARP:
1. Solaris engineers — On the gateway, link the IP address of your network’s router
to the physical address of the gateway’s external interface, as shown below:
arp -s 199.203.73.3 <MAC Address> pub
199.203.73.3 is a sample IP address for the network router.
2. NT engineers — Create a text file named local.arp in the $FWDIR\state

directory. Each line in the file should be of the form:
<Physical Address> <IP Address>

352 Load Balancing on Other Logical Servers
Load Balancing for As described earlier, before creating another logical server, define a server group and
Other Services the physical servers that comprise it. Figure 241 and Figure 242 display the properties
for an FTP server group and FTP logical server:
Figure 241: FTP Server Group
Figure 242: FTP Logical Server
The logical server’s properties are as follows:

• Server’s Type = Other (FTP)

• Server uses Persistent Server Mode III-4

When this option is checked, a client who connects to a physical server in
the internal network will continue to connect to that server for the duration
of the session.
• Server group part of this logical server = FTP_Server_Group
Load Balancing
• Balance Method = Round Trip
• Color = the predefined color for logical servers
IV-3
Load Balancing

354 Lab 19: FTP Logical Server
Lab 19: FTP Logical Server
Turn off persistent server mode, if necessary.
4Define a server group

1. Define a group object called ftp-group.
2. Place in the group all Web server objects but your own.
3. Click OK.
4Define a logical server object

1. Define a logical server object named ftp-farm:
IP address: 204.32.38.99
Servers: ftp-group
Server’s Type: Other
Balance Method: Round Robin
2. Click OK.
4Clean out rule base

Delete all rules in the rule base, except the cleanup (last) rule.
4Add FTP rule

Destination: www.yourcity.com
Services: ftp
Action: accept
4Add load balancing rule

Destination: ftp-farm
Services: ftp
Action: accept

4Install and test the rule base III-4

1. Install the rule base.
2. From your Internet server, connect to 204.32.38.99 through FTP repeatedly.
Load Balancing
IV-3
Load Balancing

356 Rule Base Order and Load Balancing
Rule Base Order and Load Balancing
HTTP Logical When adding load balancing to a security policy, security engineers must consider rule
Servers in a Rule base order. In FireWall-1, packets are matched against the first three components of a
Base rule: Source, Destination and Service. Because rules are examined sequentially per
each packet, only packets not described by previous rules are examined by the
FireWall-1 implicit rule, which drops all packets not covered by previous rule bases.
To add HTTP load balancing to a rule base, follow these steps:

1. When an HTTP logical server is the destination in a rule, the rule’s action refers to
the connection between the Firewall Module and the client (the connection that
serves to redirect the client to the proper server). This action must be either accept
or encrypt (Figure 243):
Figure 243: HTTP Server as Destination in a Rule Base
2. There must be a different rule that allows the connection between the client and
the HTTP logical server (group). That rule can specify another action, for
example, client authentication (Figure 244):
Source Destination Service Action Track Install On Time Comment

www.detroit.com HTTP_LS_Server http accept Long Gateways Any Load balancing rule
Any HTTP_Server_Grouhttp accept Long Gateways Any Authenticate all
rfremote network
sessions coming
through the HTTP
logical server
Any Any Any Drop Short Gateways Any Clean-up rule
Figure 244: Client authentication with a Logical Server
Other Logical There are no special considerations for using FTP or other logical servers in a rule.
Servers in a Rule One rule, with the logical server as destination, is sufficient (Figure 245):
Figure 245: FTP Logical Server as Destination

Troubleshooting Load Balancing — HTTP Logical Server III-4
Problem You wish to hide the true IP address of the physical server to which your HTTP
redirect rule directs HTTP traffic. HTTP load balancing always rewrites the HTTP
logical server’s name when you tie several logical server names to one IP address. The
Load Balancing
HTTP protocol has a feature that uses a server’s name in the HTTP request. HTTP
load balancing rewrites the logical server name to the actual physical server it
represents.
Solution The way to solve this problem is to choose Server’s Type: Other for HTTP logical
servers sharing the same IP address (Figure 246):
IV-3
Load Balancing
Figure 246: HTTP Logical Server Configured as Other Server Type

358 Review
Review
Summary Load balancing allows several servers in one network to share and distribute traffic
among themselves, thus using network resources efficiently.
Using load balancing allows security engineers to configure communication requests

to be routed to a single HTTP logical server. Load balancing directs communication
requests to the server with the lightest traffic. In addition, using load balancing
algorithms, such as server load and round trip algorithms, ensures requests to a server
are fulfilled by the appropriate server.
In a rule base, packets are matched against the first three components of the rule base:
Source, Destination and Service. Since rules are examined sequentially per each
packet, only packets not described by previous rules are examined by the FireWall-1
clean-up rule, which drops all packets not covered by previous rules.
Review Questions 1. What are the three load balancing components?
2. What are the steps for setting up HTTP redirect?
3. How do you create a logical server?
4. What are the load balancing algorithms and how are they used?
5. How does an FTP logical server perform load balancing?

6. Why is rule base order an important consideration when setting up load III-4
balancing?
Load Balancing
IV-3
Load Balancing

360 Review

IV-2
Remote Management
Remote Management
Introduction
Some organizations are spread over a wide area, comprising the use of LANs and
WANs to aid in day-to-day operations. Many internal networks can be firewalled to
protect parts of the networks from internal intrusions, as well as protecting the
networks from outside attacks. With so many parts of an organization protected by
firewalls, it is important to give the security engineer the ability to control each
firewall from a central point.
FireWall-1’s remote management capabilities allow security engineers to manage

firewalled systems on both an internal and external network.
Objectives • Be able to identify the components of the remote management architecture

• Demonstrate how to configure the Management Modules for remote management
• Demonstrate how to configure the FireWall module to be managed remotely
• Identify the reason why “bouncing the firewall” is important in remote
management
Key Terms • remote management (only with Enterprise Product)

• Management Module
IV-4
• Firewall Module
• access control rights
• remote access Remote Management
361
362 Remote Management Architecture
Remote Management Architecture
Overview FireWall-1 remote management allows management of FireWall modules. This

consists of FireWall-1’s Management Module and of Firewall Module(s) (Figure 247):
• Sun & HP
• Windows NT Multiple Firewall Modules
• IBM RS/6000
• Bay Networks, Cisco and • Enforces security policy
• Reports status and log data
3Com Routers to its management server
• Xylan and Ipsilon Switches
• SunOS4
• Solaris2 • Manages object DBs, rule
• Solaris x86 bases, log files.
• HP-UX • Concurrent administrative
• Windows NT Management Module access with varying rights
• AIX
• Windows 95/NT
• X/Motif (Sun, HP & AIX) • Builds objects, rules.
• Views logs and FW status.
Multiple GUI Clients
Figure 247: Remote Management Architecture
The modules are defined as follows:

Management Module — The GUI client and the Management Server that
controls up to 50 firewalled devices; keeps databases and log files and compiles
security policies.
Firewall Module — Contains FireWall-1 inspection engine that resides on a
firewalled gateway or host; enforces security.
The Firewall Module can reside on internal and external gateways or hosts.

Unit IV — Chapter 4: Remote Management 363
Figure 248 displays a management module controlling internal and external firewalls: IV-2
Remote Management
Management
Module with GUI
Firewall
Module
EXTERNAL REMOTE
INTERNAL REMOTE
Firewall
Firewall Firewall Firewall Module
Module Module Module
Accounting Sales Marketing
Figure 248: External Remote-Firewall Module
In Figure 249 the Firewall Modules are considered remote, even though they are
inside the network.
Remote management provides internal security by encrypting data traveling from a

Management Module to a Firewall Module. In addition, remote management allows
security engineers to do the following:
• Enforce a security policy remotely
IV-4
• Report receive status and log data
• Manage object databases, rule bases and log files
• Allow administrators and security engineers various access rights Remote Management
Setup The following are key points to consider when setting up remote management within a
Considerations firewalled network:
1. The Remote Management Module provides security between your network and
your firewall module by using encryption.

2. The Management Module creates a security policy which is downloaded to the

remote firewall(s).
External Networks and Remote Management

As previously stated, FireWall-1 allows for remote management. In Figure 249, USA
and Israel are not part of the same network. However, they are part of the same
FireWall-1 network, as they are both controlled by the same management module.
Figure 249: Remote Management through Different Networks
Redundant Remote Management

Scenario: Your network contains several firewalls that have the same exact policies,
and several management modules that manages those firewalls. If Management
Module A fails, Management Module B could take control of Management Module
A’s firewall. This would be known as redundant remote management (Figure 250).
It is important to note that in order to have redundant remote management,

you must maintain the same exact policies on each of the individually
managed Firewall Modules. This means that your firewall maintenance
must be constant.
This is not the same as one Management Module managing several

firewalls. Firewall Modules do not have to have the same security policies,
but the Management Module database must be the same (on both
databases). FireWall-1 has no built-in replication.
Figure 250: Redundant Remote Management

Remote Communications IV-2

Figure 248 on page 363 illustrates how a management module can control
communications between a Firewall Module and a GUI client:
Remote Management
1 There are two firewalls between the Firewall Module and Management Module
(on the Management Station), and between the Management Module and the GUI
client. This is so that external hackers cannot access the Management Module.
2 The GUI client has multiple-user access, but is only allowed read access to the
Management Module.
3 With one Management Module, the FireWall-1 database is updated on the
Management Module only.
Advanced Security and Authentication

With remote management, security engineers can authenticate users by access control
rights, which provide multi-level access control to security engineers as follows:
1 The GUI client sends a security engineer’s username, password, and IP Address to
the Management Console (Figure 251):
username and password
Figure 251: GUI Client Communicating with Management Module
2 After validating the GUI client’s IP address in the $FWDIR\conf\gui-clients file

(NT) or the &FWDIR/conf/gui-clients file (Solaris), the Management Station
authenticates the engineer’s username and password.
3 If the username and password are authenticated, the Firewall Module assigns the
GUI client its access control rights and sends along the appropriate database
information — security policy, and object and log database — (Figure 252).
IV-4
Remote Management
access rights and database info
Figure 252: Management Module Communicating with the GUI Client

The IP address is for the client who can access the Management Console.
A Note about the The FireWall-1 user database contains information about each user defined in
User Database FireWall-1, including authentication schemes and encryption keys. The user
database resides on the Management Station and on the firewalled devices.
A FireWall-1 user database does not contain information about users defined
externally to FireWall-1 (for example, users in external groups). But the database does
contain information about the external group (for example, on which account unit the
external group is defined). For this reason, changes to external groups take effect only
after a security policy is installed or a user database is downloaded.

Configuring the Remote GUI IV-2
To configure the remote GUI, you will set up a Management Station and a remote
Remote Management
Firewall Module. This ensures that the Firewall Module and Management Station are
connecting.
The steps for configuring the remote GUI are as follows:

1. Create administrator account(s).
2. Define allowed GUI Clients.
3. Load the GUI software on the GUI client machine and log into GUI client.
GUIs and Screens When configuring a Management Station, use the following FireWall-1 GUIs, tabs
and screens:
• The Configuration GUI and the following tabs:
Administrators
GUI Clients
Remote Modules
• The Security Policy GUI and the following tabs:
General
Interfaces
• The System Status GUI
The Configuration GUI

The FireWall-1 Configuration GUI allows security engineers to do the following:
• Add administrators and assign access rights
• Specify remote clients
IV-4
• Specify remote firewalls
Remote Management

368 Configuring the Remote GUI
Figure 253 displays the opening tab of the Windows NT FireWall-1 Configuration
screen:
Figure 253: The FireWall-1 Configuration GUI

The Administrators Tab IV-2

The Administrators tab (Figure 254) specifies which administrators are allowed
access to a management server:
Remote Management
Figure 254: The Administrators Tab
The Add Administrator Screen

When security engineers add an administrator, the Add Administrator screen appears
(Figure 255):
IV-4
Remote Management
Figure 255: The Add Administrator Screen

The Add Administrator options are as follows:

Administrator Name — The name of the administrator for the firewalled network.
Password — The administrator’s password.
Confirm Password — The password retyped.
Permissions — Multi-level access control provides the following access rights:
Read/Write — All permissions but only one FireWall-1 security engineer logged
as Read/Write at a time.
User — Modify user information; all other information is read-only.
Read Only — Read-only access to the security-policy editor; some security
engineers with higher access levels log in at this access level.
Monitor Only — Lightest access level; only allows access to Log Viewer and
System Status.
The GUI Clients Tab

The GUI Clients tab (Figure 256) allows you to enter the name or IP address of a
remote client. Add as many remote GUI clients as necessary.
Figure 256: The GUI Clients Tab

Remote GUI 1. Start the FireWall-1 Configuration GUI. The FireWall-1 Configuration screen IV-2
Configuration Steps appears (Figure 253 on page 368).
2. Click the Administrators tab. The Administrators tab information opens (Figure
Remote Management
254 on page 369).
3. Click Add and the Add Administrator screen appears (Figure 255 on page 369).
4. Enter the administrator name, password and select the access level (Figure 257).
Click OK to continue.
Select the
Administrators tab
and press Add …
A pop-up box will

appear. Fill in the
necessary information
and press OK.
Figure 257: Adding Administrator Name
Solaris Engineers
IV-4
To add an administrator account in Solaris, run the following command:
# fwm -a
Remote Management
Select additional options as follows:
User — fwadmin
Permissions ([M]onitor-only,[R]ead-only,[U]sers-edit,read/[W]rite) — w
Password — abc123
5. Click the GUI Clients tab (Figure 256 on page 370).

6. Type the name or IP address of the remote host and click Add. Add as many
remote GUI clients as necessary and click OK to finish (Figure 258):
Type the hostname or IP

address of the remote host
and press Add >
Select OK
Figure 258: Add the GUI Client
Solaris Engineers
To add the GUI client hostname to the gui-clients file, use the following commands:
# cat > /etc/fw/conf/gui-clients

www.localfirewall.com
<Control-D>
7. Load the GUI and software on the GUI client machine.

8. Log on to the GUI client (Figure 259): IV-2
Remote Management
Check the Read Only box
if the administrator has this
access level.
Figure 259: Logging on to the GUI Client
IV-4
Remote Management

374 Lab 20: GUI Client Management
Lab 20: GUI Client Management
Objective: You will attempt to manage a firewall that has been installed on a remote
(your partner’s) machine.
Scenario: Your company has multiple firewalls but only one firewall administrator.
Instead of physically moving to each firewall to administer the rule base you will
control each of the firewall’s remotely.
4Create the Administrator account

On the Management Station (that is, fw.yourcity.com), create a new FireWall-1
administrator:
Name: guiadmin
Password: abc123 (read/write privileges)
4Enable access for remote client

Add the hostname of the GUI client through the FireWall-1 Configuration Manager.
4Log on from remote client

From your GUI client host (www.yourcity.com), start the Security Policy GUI and log
on to the Management Station:
1. Log in as guiadmin (password abc123).
2. Click the read-only box.

Management Station and Firewall Configuration (Remote Management) IV-2
Remote Management
Remote Configuring the Management Station and Firewall has its limitations:
Management
• Single bundled products (licensed limited versions) do not support the separation
Limitations
of the Firewall Module and the Management Station.
• GUI Client access is supported for remotely accessing the Management Station on
all bundled products, including single bundled products.
Management Station Configuring the Management Station and firewall is a seven-step process:
and Firewall
1. On the Firewall Module, define the Management Station authentication key.
Configuration
2. Create the masters file on the firewall. Add the IP address of the Management
Station allowed to remotely manage the firewall.
3. Stop (fwstop) and start (fwstart) the firewall.
4. Create the firewall’s authentication key on the Management Station.
5. Define the Firewall Module workstation object in the Network Objects Manager.
6. Define a rule base on Management Station.
7. Install the rule base on Firewall Module gateway.
IV-4
Remote Management

376 Management Station and Firewall Configuration (Remote Management)
Configuration The Remote Modules Tab

Screens The Remote Modules tab (Figure 260) allows you to enter a name for the remote
firewall:
Figure 260: The Remote Modules Tab

The General Tab IV-2

The General tab (Figure 261) configures the remote firewall, including its IP address
and specifications:
Remote Management
Figure 261: The General Tab of the Workstation Properties screen
The Firewall Module must be defined as an internal object in order to be

managed remotely.
The following are the remote firewall options:

Name — The module’s name
IP Address — The 32-bit address that uniquely identifies the remote device
Get Address — Resolves the module’s name to its IP address
IV-4
Comment — A description of the Firewall Module
Color — The color of the module’s icon
Remote Management
FireWall-1 Installed — The Firewall Module with FireWall-1 installed
Exportable — Information about this module can be made available to SecuRemote
clients
Location — Internal for this Firewall Module
Type — Gateway for this Firewall Module
Version — The Firewall Module version

Remote The following lists the steps for configuring the Management Station and Firewall:
Management
1. Click the Remote Modules tab (Figure 260 on page 376).
Configuration
2. Type the host name for the remote Firewall Modules.
3. Click Add to add each name.
4. Click OK to exit the Configuration screen.
5. Configure the key (password) that the master and remote devices will use to
authentication sessions:
a. From the OS prompt, change to the $FWDIR\bin directory. (Solaris
engineers, switch to the cd $FWDIR/bin directory.)
b. Add the authorization key that will allow the master device to authenticate to
the remote device (where abc123 is a sample external password, and
204.32.38.101 is a sample IP address):
fw putkey abc123 204.32.38.101
6. Edit the masters file on the firewalled computer, as follows:
a. From the OS prompt, change to the $FWDIR\conf directory.
b. Add the IP address of the Management Station that remotely manages the
firewalled computer; add the address to the masters file as follows (where
204.32.38.101 is an example IP address):
echo 204.32.38.101 > masters
c. Solaris engineers, create or edit the masters file, as follows:
cat | $FWDIR/conf/masters
204.32.38.101
^D
7. Stop and start the firewall: This causes the Firewall Module to reread the local
masters file and allow the Management Station to remotely install security
policies:
a. From the OS prompt, change to the $FWDIR\bin directory.
b. Type fwstop and press Enter; type fwstart and press Enter.
Solaris: ./fwstop and ./fwstart
c. When you see the message FW-1 started, exit the OS.
8. Create an authentication key: On the Management Console, an authentication key
needs to be created for each Firewall Module that this Management Console will
remotely manage. This is done using the fw putkey command with the following
arguments:
fw putkey -p password firewall-module-ipaddress

Solaris engineers IV-2

# fw putkey -p abc123 204.32.38.10n
9. Define the firewall module (Figure 262). The Firewall Module object must be
Remote Management
defined as an Internal object in order to be remotely managed.
Figure 262: Defining the Firewall Module
10. Start the FireWall-1 Security Policy GUI. On the Login screen, click the Read
Only box for administrators or security engineers with read-only access (Figure
263):
IV-4
Remote Management
Figure 263: The Security Policy Login screen

11. Create and install the security policy. After compiling the security policy, fwd on
the Management Station initiates a connection to fwd on the firewall and sends the
encrypted putkey password (Figure 264):
encrypted putkey password
Figure 264: Encrypted putkey Password
After validating the Management Station’s IP address in the $FWDIR/conf/masters

file, fwd on the firewall then authenticates the putkey password. If authenticated, fwd
on the firewall will accept the compiled internal user databases and security policy
and install it in the Inspection engine (Figure 265):
compiled user DBs and security policy
Figure 265: Installing Databases and Policy

Lab 21: Remote Management IV-2
Objective: Configure the local management module and a remote FireWall Module in
Remote Management
order to have the local management module manage both the local and remote firewall
modules.
Scenario: Your company has remote networks in other cities. The networks at the
remote sites are protected by FireWall-1. You will administer the remote FireWall
Module at the selected cities as well as the local firewall. With your partner city
decide which one will be the master and which one will be the remote.
4Configure the Master

Add the remote module’s external IP address to the remote module’s list in your
management module’s configuration:
1. Start the FireWall-1 configuration program.

2. Click on the Remote Modules tab.
3. Add the remote module’s IP address. When prompted for a password, enter
abc123, then confirm with abc123.
4. Click OK and exit the configuration program.
4Configure the Remote

Configure the key (password) that the management module and remote module will
use to authenticate sessions.
1. Open a terminal (Solaris) or a DOS screen. Change directory to $FWDIR/bin
(Solaris) or $FWDIR\bin (Windows NT).
2. Enter the following command:
NT
> fw putkey 204.32.38.n (external IP address of the
Master) IV-4
> Enter secret key: abc123
> Again secret key: abc123
Solaris Remote Management

# /.fw putkey 204.32.38.n (external IP address of the
Master)
# Enter secret key: abc123
# Again secret key: abc123
3. Add the address of the management module to the masters file in the
$FWDIR\conf directory by using the following commands:

382 Lab 21: Remote Management
NT
> cd $FWDIR\conf
> echo 204.32.38.n > masters
Solaris
# cd $FWDIR/conf
# cat | masters
# 204.32.38.n
# ^D
4. Restart the remote module:
NT
> cd $FWDIR\bin
> fwstop
> fwstart
Solaris
# cd $FWDIR/bin
# ./fwstop
# ./fwstart
4Configure Network Object on Master

Edit the remote module’s network object to ensure that it is setup correctly.
1. Select Manage > Network

2. Select the remote firewall object. Click Edit
3. Verify and/or change the following elements:
IP Address: remote module’s external address
Location: Internal
Type: Gateway
FireWall-1 Installed: Make sure this option is checked
4. Click the Interfaces tab and verify the interfaces are there. If not, add them.
5. Exit the Network Objects manager.
4Alter the Rule Base
1. Modify your cleanup rule to install only on your local firewall:

Target: fw.yourcity.com (delete Gateway)

2. Create a remote cleanup rule by altering the following fields: IV-2

Track: Alert
Install On: fw.partnercity.com (delete Gateway)
Remote Management
4Verify and Install the Policy
4Test the Policy
1. TELNET to an address behind the remote module that is not allowed by another
rule.
2. Use the Log Viewer to view the log entries. Are there any entries from the remote
module? (If you don’t see any check with the instructor.)
3. Start the System Status GUI. What do you see on the status screen? (You should
see both systems (Master and Remote) behind the firewall.)
IV-4
Remote Management

384 Running the System Status GUI
Running the System Status GUI
1. Start the System Status GUI. Type the name of your firewall server, your user
name and password, when prompted at the System Status login screen. Solaris
engineers, type the following command:
# $FWDIR/bin/fwstatus &
2. The Status screen appears (Figure 266). The GUI displays all remote devices,
allowing you to confirm that FireWall-1 recognizes all remote clients and
firewalls.
Figure 266: The System Status GUI

A Note about Removing Remote Management IV-2
To remove remote management from a remotely controlled firewall, do the following:
Remote Management
1. Remove the masters file from the $FWDIR/conf directory of the Firewall Module.
2. Bounce the firewall.
3. Start the Security Policy GUI; change the location of the Firewall Module to
external in the FireWall-1 Security Policy GUI.
IV-4
Remote Management

386 Managing a Security Policy Remotely
Managing a Security Policy Remotely
Using FireWall-1, security engineers can manage security policies among several
FireWall-1 applications in geographically different areas. Figure 267 displays the
concept of remote-security management:
Figure 267: Remote Security Policy
Steps for Managing When configuring a security policy to manage a remote network, security engineers
a Remote Security create a security policy on the Management Module, as follows:
Policy
1 Create a security policy on the Management Module. In Figure 267 the security
policy is installed on the US FireWall-1 computer.
2 Install FireWall-1 remotely. In Figure 267 FireWall-1 is installed on a Firewall
Module in Israel.
3 Set up a security policy for a remote location. In Figure 267 the security policy is
set up for the Israel router.
Creating a Remote Security Policy

1. From within the rule base, right-click on the Install On column. Select Add
(Figure 268):
Figure 268: The Install On Column
2. Select Targets.

3. Choose the remote location object (Figure 269 and Figure 270): IV-2
Remote Management
Figure 269: Adding a Remote Firewalled Location
Figure 270: Selecting a Remote Firewall
4. The remote security policy reflects the remote firewall (Figure 271):
Figure 271: The Remote Security Policy IV-4
Remote Management

388 Review
Review
Summary The remote management capabilities of FireWall-1 are integral to the management of
firewalled systems from one centrally located management module. The components
that make up the remote management architecture are the Management Module, the
remote Firewall Module, and the Management Station.
Remote management allows security engineers to do the following:

• Enforce a security policy remotely
• Report status and log data
• Manage object databases, rule bases and log files
• Allow administrators and security engineers various access rights
FireWall-1 allows for remote and distributed management through its Management
Module, which can control up to 50 firewalls per network. The Management Module
resides on the Management Station, which is separate from the FireWall-1
workstation. If an internal network’s service is interrupted, the Firewall Module can
do the work of the Management Module by maintaining Viewer and Status Logs and
the FireWall-1 database. With remote management, security engineers can
authenticate users by access control rights, which provide multi-level access control to
administrators and security engineers.
Review Questions 1. What are the components of the remote management architecture?
2. Why must you configure both the remote management and Firewall management?
3. Why should you “bounce” the system after removing remote management?
4. How would you authenticate users with remote management?

5. When are changes to the external groups take effect? IV-2
Remote Management
IV-4
Remote Management

390 Review

Unit 5 — FireWall-1 Diagnostic Tools
Chapter 1: Troubleshooting

V-1
Chapter 1: Trouble-
Unit V — Chapter 1: V-1
Tro u b l e s h o o t i n g
shooting
Troubleshooting
Introduction
This chapter covers some common FireWall-1 problems and offers solutions. This
material is not a comprehensive list of all potential problems. It is only meant to
initiate discussion.
This chapter covers the following topics:

• Troubleshooting error messages
• Troubleshooting resources
• Debugging FireWall-1
Objectives • Discuss FireWall-1 troubleshooting techniques

• Discuss and resolve FireWall-1 error messages
• Identify Check Point troubleshooting resources, including Internet resources
• Discuss FireWall-1 debugging tools, including tools for both Solaris and Windows
393
394 Troubleshooting Error Messages
Troubleshooting Error Messages
SMTP Mail-Server This error is an error-handling message that lists an error for the server, not the actual
Error firewalled device. In the event of the error Error Handling Server, the server is
notified.
FireWall-1 Cannot If FireWall-1 cannot resolve a name and address in a security policy, check the domain
Resolve a Name and name for the object to ensure the IP address is correct.
Address
Every time you use a domain name, a domain-name service (DNS)
translates the name into the corresponding IP address. For example, the
domain name www.example.com might translate to 198.105.232.4.
Installing SecuRemote 4.0 Beta-1 installs a defunct (beta) version of the Entrust API DLL
SecuRemote (kmpapi32.dll). Later versions of SecuRemote install a later version of the DLL, but
do not overwrite the older one, since both DLLs use the same version number.
Solution
If security engineers have installed SecuRemote 4.0 Beta-1 and are now installing a
later version, they must delete the kmpapi32.dll file from their SecuRemote device’s
c:\Windows\System directory (System32 on a Windows NT Server device).
All known SecuRemote problems related to SecuRemote Release 2 can be avoided by

installing SecuRemote on Dialup Only.
Troubleshooting HTTP load balancing always rewrites the HTTP logical server’s name (URL). When
Load Balancing and security engineers tie several logical-server names to one IP address, FireWall-1 does
HTTP Logical the following:
Servers
1. The HTTP protocol has a feature that uses a server’s name in the HTTP URL
request.
2. HTTP load balancing, which redirects the HTTP request to a different IP address,
rewrites the logical-server name to the actual physical server it represents.

Unit V — Chapter 1: Troubleshooting 395
Solution V-1
To solve this problem, security engineers must choose other load balancing with
HTTP logical servers sharing the same IP address:
Chapter 1: Trouble-
Select Server Type Other in the Logical Server Properties screen (Figure 272). V-1
shooting
Troubleshooting
Figure 272: Logical Server Properties Screen
FireWall-1 Displays When systems administrators try to view the contents that were entered in the Account
an Account Management Client (AMC) and in the actual LDAP server, they may receive an
Management Client authentication error regarding the administration server. This error means the
Authentication Error Netscape Directory Server has not been set up completely.
Solution
1. Enter the directory manager’s password in the SuiteSpot settings.
2. Confirm the administrator’s name and password. This establishes
communications between the LDAP and administration server.
Do not change the administrator’s name or password. The previous step is

done to establish communications between the Directory Server and the
Administration Server.
Deleting an Security engineers cannot delete organizational units in Account Management Client,
Organizational Unit once they are created.

Solution
Use an editor to do the following:
1. Delete the wrong name.
2. Open Account Management Client and re-enter the name.
Account FireWall-1 rejects the user’s password. This might happen if the user is defined
Management differently in the FireWall-1 user database, or in an Account Unit with a higher
priority.
Solution
Check the Display user’s DN at login field in the LDAP tab of the Properties Setup
screen and try again. The user’s DN appears and you can determine from where
FireWall-1 is getting the user’s password.
User not Found 1. Make sure that Use LDAP Account Management in the LDAP tab of the
Properties Setup screen is checked.
2. Using the Account Management Client, verify that the user is indeed defined in
the Account Unit.
Changes Made in Changes take effect only after one of the following happens:
the Account
• The cache times out
Management Client
Do not Affect • The Security Policy is installed
FireWall-1 • The User Database is downloaded
User Authentication If user authentication fails when you or a user attempts to connect, check the
following:
(Solaris) $FWDIR/tmp/<name of content security server>.pid

(NT Server) $FWDIR\tmp\<name of content security server>.pid
If this process is not running, start it. Check the process soon after user authentication
fails.
Authentication The two most common types of computers which run FireWall-1 are Management
Modules and Firewall Modules. Several possible scenarios exist for problems with
authentication. Each of the scenarios below present possible solutions.

Scenario A V-1
The key is not matched. In this case, when the fwstart command is issued on the
Management Module, the Firewall Module would report that the log connection could
not be authenticated.
Chapter 1: Trouble-
The Management Module message is: V-1
fwd: Log Authentication failed from <name of module>
To solve this problem, use the fw putkey command to synchronize the keys:
shooting
Troubleshooting
4Type fw putkey <target> [-p password]
Scenario B
The Firewall Module does not recognize the Management Module. In this case,
attempting to install the security policy on the Firewall Module, would create the
following error:
Authentication for command load failed

Failed to Load Security Policy on <module>: Unauthorized action
To resolve this problem,

1. Type fwconfig (Solaris) or fw-1 configuration (NT Server) Firewall Module, and
add the name of the Management Module to the stations allowed to control it:
2. Use the fw putkey command (see syntax above in Scenario A) at the Firewall
Module.
3. Use the fw putkey command (see syntax above in Scenario A) at the Management
Module.
Or, follow the authentication command procedure below:

1. Add the name of the Management Module to the $FWDIR/conf/masters file on
the Firewall Module.
2. Use fw putkey command (see syntax above in Scenario A) at the Firewall
Module.
3. Use fw putkey command (see syntax above in Scenario A) at the Management
Module.
4. Use the fwstart command to restart the Firewall Module.
Scenario C
Sometimes it is necessary to control a non-VPN Module from a VPN Management.
Since by default the Management would attempt to encrypt the communication with
the Firewall Module, which cannot decrypt it, this could cause a problem.

In this case, edit the file $FWDIR/lib/control.map as follows:

1. Find the following paragraph:
MASTERS : stat,getkey,gettopo/none opsec/fwn1 */fwa1
CLIENT: load,db_download,fetch,log/fwa1 opsec/fwn1 */none
*: stat,getkey,gettopo/none
unload,ioctl,load,db_download/deny opsec/fwn1 */fwa1
2. Copy the line that begins with the word CLIENT and place the copy above the
CLIENT line.
3. In the new line, replace the word CLIENT with the IP address of the Firewall
Module main interface.
4. In the new line, replace the word fwa1 with the word skey.
The new line should now look like the example below:
MASTERS : stat,getkey,gettopo/none opsec/fwn1 */fwa1
123.122.133.3: load,db_download,fetch,log/skey opsec/fwn1 */none
CLIENT: load,db_download,fetch,log/fwa1 opsec/fwn1 */none
* : stat,getkey,gettopo/none
unload,ioctl,load,db_download/deny opsec/fwn1 */fwa1

Troubleshooting Resources V-1
Internet Resources There are several Internet resources available to FireWall-1 security engineers. Figure
Chapter 1: Trouble-
273 displays the Check Point Resource Library Web page. V-1
shooting
Troubleshooting
Figure 273: Check Point Library Web Page
Other Check Point Web and Internet sites of interest include the following:
• www.checkpoint.com/products/technology/prodtec.html — Check Point
product technology
• www.checkpoint.com/corporate/contact_list.html — how to contact Check
Point in Israel and the US, including relevant e-mail addresses
• http://www.checkpoint.com/services/mailing.html — Check Point’s mailing
list

400 Troubleshooting Resources
• www.checkpoint.com/forms/search.html — Check Point’s search engine,

allows you to search for help based on the following:
Entire site, excluding the technical-support knowledge base
Entire site, excluding the technical-support knowledge base and press releases
Press releases only
Technical-support knowledge base only
• www.checkpoint.com/~joe — Check Point’s quick reference area to common
questions.
• http://titanium.us.checkpoint.com/kb/techkb.nsf — Also a Check Point search
engine
Encryption
The following Web sites are useful resources for help with ISAKMP/Oakley (IKE)
and IPSec encryption:
• www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-ipsec-oakley-02.txt
• www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-ipsec-isakmp-09.txt
• www.ietf.cnri.reston.va.us/html.charters/ipsec-charter.html

Debugging Tools V-1
Overview This section will introduce you to two tools to help you debug FireWall-1: the -d
Chapter 1: Trouble-
switch and fwinfo. V-1
The -d switch A strong debugging tool is the -d option when added to the fwd, fwm and snmpd
shooting
To execute:
Troubleshooting
1. Kill the daemons, using the following commands:
fw kill fwd, fw kill fwm, fw kill snmpd
2. Rerun the daemons using the -d option, using the following commands for
Solaris:
fwd -d, fwm -d, snmpd -d
Use the following for Windows NT Server:
fw d -d fw m -m
Example
fwd -d (when using logical server)

Output:
1. [fwd@anka] fwbalance_invoke: tupple=<c0a86e05,1097,c7cb471e,21,6>
rule=2 pkt=599e0
2. [fwd@anka] fwbalance_invoke: found dst c7cb471e in logical_server
3. [fwd@anka] fwbalance_handle_round_robin: selecting server c7cb47db
4. [fwd@anka] fwbalance_do: translated <c0a86e05,449,c7cb471e,15,6>
to<c7cb47db,15> type other
The following explains the above example:
1. A connection starts from c0a86e05 (192.168.110.5) port 1097 to c7cb471e

(199.203.71.30) port 21, ip protocol 6 (TCP) the connection passed according
to rule=2 (rule 2) the packet id is 599e0 (pkt=599e0).
2. The destination of the connection was found to be inside a logical server

and should be processed accordingly.
3. Using the round-robin method of load balancing, the connection’s

destination was changed to c7cb47db (199.203.71.219).
4. The connection that was from c0a86e05 (192.168.110.5) port 449 (1097) to
c7cb471e (199.203.71.30) port 15 (21) ip protocol 6 (TCP) was translated to
(the destination) c7cb47db (199.203.71.219) port 15 (21), using type other
(server type as defined in the logical server).

402 Debugging Tools
Example: fwm -d (for completing user database installation)

Output:
[fwm@anka] Write set to fd 6:
(
:type (notification)
:subject (operation-done)
:operation (database-download)
:seq (24)
:body (
:operation-ok (true)
)
:status (ok)
)
After a successful user database installation is complete the fwm sends a

notification that the operation "database-download" was done and finished
successfully.
Environment Variables
Some processes, like security servers, do not print to the console, and therefore cannot
be seen by the fwd -d or fwm -d options. In these cases you will need an environment
variable.
Environment variables are set before the daemon begins running. To set environment
variables, do the following:
1. Kill the daemon.
2. Set env variable.
3. Restart daemon.
When variables are set, they write to a file and that information can be analyzed:
FWACLIENTD_DEBUG: Prints debug information into the aclientd.log file.
$FWDIR/log dir: Performs a sleep of 20 (default) on Solaris, and on NT Server
activates the debugger.
FWAFTPD_DEBUG: Prints debug information to $FWDIR/log/aftpd.log
FWAHTTPD_DEBUG: Prints debug information into the ahttpd.log file in the
$FWDIR/log dir. Performs a sleep of 20 (default) on Solaris, and on NT Server
activates the debugger.
HTTP_DEBUG: Prints debug information to the $FWDIR/log/ahttpd.log
HTTP_SLEEP: Performs a sleep of 20 seconds (by default, can be changed).

FWARLOGIND_DEBUG: Prints debug information into the arlogind.log file in V-1

the $FWDIR/log dir. Performs a sleep of 20 (default) on Solaris, and on NT
Server activates the debugger.
FWATELNETD_DEBUG: Prints debug information into the atelnetd.log file in
Chapter 1: Trouble-
the $FWDIR/log dir. Performs a sleep of 20 (default) on Solaris, and on NT V-1
Server activates the debugger.
FUNCCHAIN_DEBUG: This switch shows the debugging information of the
processes that are initiated by the procchain such as secureID authentication and
shooting
http resolving.
Troubleshooting
FUNCCHAIN_SLEEP: Sets the funcchain to a certain sleep period that a
debugger can be initiated.
FW_RESOLVE_DEBUG 1: Outputs debug information to consol regarding the
FireWall-1 resolving mechanism.
FWMDQ_DEBUG: Records all major actions (errors, AV handling, File
handling) to consol
MDQ_DEBUG: When set allows interactive debugging on NT Server (waits for
the debugger)
SMTP_DEBUG: Valid values are 1-3. When set outputs verbose information on
the smtp information to the file asmtpd.log.
If the latest smtp patch is installed, SMTP_DEBUG and MDQ_DEBUG can be
used in another way:
• Insert these switches into the $FWDIR/conf/smtp.conf file
• Kill the process using the -USR1 switch
• The debugging information will start immediately without the need to restart
the daemons
NT Server Issues
In addition to the debugging tools that are built into FireWall-1, some other methods
can be used to debug problems that are FireWall-1 related. On Solaris, use the core
dump and crash dump, and on NT Server, their equivalents: Dr. Watson and
memory.dmp.
Example
This example is a typical Dr. Watson which shows a FireWall-1 that crashed:
Microsoft (R) Windows NT (TM) Version 4.00 DrWtsn32

Copyright (C) 1985-1996 Microsoft Corp. All rights reserved.
Application exception occurred:
App: WIN32/fw.exe (pid=132)
When: 10/7/1997 @ 8:40:9.60

404 Debugging Tools
Exception number: c0000005 (access violation)

Explanation:
The application fw.exe had an access violation (segmentation fault) caused
by a problematic fw.exe (in most cases due to a bug).
Using fwinfo as a This section will show you how to use fwinfo as a debugging tool.
Debugging Tool
Reproducing Configuration
Check the following:
1. What is the exact version of FireWall-1? Use fw ver to determine the version.
2. On what OS is FireWall -1 installed? If it is NT Server, then tar is not used. If it is
Solaris, this can be verified by looking for a Solaris command (date, hostname,
uname -a, w -u,…) being issued at the beginning of the fwinfo file.
3. Are the Firewall Module and the Control Module on the same machine? Check
this by looking at $FWDIR/conf/product.conf
To reproduce the policy we need to put a few files on our FireWall-1. Copy the policy
file, the object network file and the users file.
Copying the files
The firewall must be stopped before copying the files.
Copying files in Solaris platform is done after opening the fw.tar by regular cp.
1. In NT Server, open an empty new file and copy/paste from the fwinfo. The policy
file and object file will be in the fwinfo under "FireWall-1 Configuration, database
and state". The user files are under "Users Files".
The Policy file is in $FWDIRwdir\conf. It will usually be in the file rulebases.fws.
This file holds all the policies together.
2. This file is copied to $FWDIR\conf on your machine.
If you want to know the last policy that was installed and compiled, go to
$FWDIR\state\local.fc file. You will find the date, time and name of the last policy.
Example
The last policy compiled is rule.w. This file (rule.w)needs to be on the

firewalled device at $FWDIR\conf. Add this file to rulebases.fws, as follows:
1. On NT Server platform: $FWDIR\bin fw m -g ..\conf\rule.W

V-1
2. On Solaris platform: $FWDIR/bin fwm -g ../conf/rule.W
3. Object network file is in $FWDIR\conf in the file object.C. Copy this file to
the firewalled device to the same place. The user’s file is copied only if it is
Chapter 1: Trouble-
being used in the policy. V-1
4. In Solaris, the file to be copied is fwauth.NDB (from the directory /conf) after
doing tar xvf to fw.tar to your machine. The backup files on the firewalled
shooting
device need to be deleted. These are: fwauth.NDBBKP from $FWDIR/conf
Troubleshooting
and fwuth.NDB from $FWDIR/database
5. Back up those three files on your machine before copying the files from the
fwinfo.
6. In NT Server, create the file by using copy/paste to a "file" (the user’s data
will be in the fwinfo under the title - "user files").
7. Issue the command: fw dbimport -r -f "file", which will put the user’s data in
the file fwauth.NDB. (Delete all other user data files).
More object.c and object.c.bak files are in the $FWDIR/conf and

$FWDIR/database. Security engineers should delete these files from the
firewalled device, so that only the object.c that copied from the fwinfo will
exist.

406 Debugging Tools

Appendixes and Glossary
Appendix A: Account Management Client Installation

on HP UX and IBM AIX
Appendix B: Security Considerations
Appendix C: Solaris Command-Line Interface

A-E
Appendix E: AMC Instal0

lation on UX and AIX
Appendix A: Account
Management Client
Installation on HP UX and
IBM AIX
HP-UX Installation To install the Account Management Client (AMC) for HP-UX, use the swinstall
application, as follows:
2. Change to the directory in which the installation files are located (either the CD-
3. Enter the following command to register FireWall-1:
hostname# swreg -1 depot -x select_local=true -x\
target_directory=/directory_name
directory_name is the name of the directory in which the installation files

are located.
4. Enter the following command to install the AMC:

hostname# swinstall &
5. The SD Install _ Software Selection screen is displayed and then the Specify
Source screen is displayed on top of it.
6. Click on Source Depot Path.
7. In the depot path screen, select the directory in which the installation files are
located.
8. Click OK to close the Depot Path screen.
9. Click OK to close Specify Source screen.
10. In the SD Install - Software Selection screen, select Account Management Client.
11. From the Actions menu, select Install (analysis).
12. When the analysis phase completes, click OK.
13. When the installation phase completes, click OK.
14. From the File menu, select Exit.
409
410
15. To run the AMC, type the following command:

hostname# /opt/amc/accountMgm
IBM AIX Installation To install the Account Management Client (AMC) for IBM AIX.
2. Change to the directory in which the installation files are located (either the CD-
3. Enter the following command to register the directory for the installation process:
hostname# smit &
4. Click on Software Installation and Maintenance.
5. Click on Install/Update Software.
6. Click on Install/Update Selectable Software (Custom Install).
7. Click on Install Software Products at Latest Level.
8. Click on New Software Products at Latest Level.
9. In the New Software Products at Latest Level screen, enter the input device or the
name of the directory where the FireWall-1 installation files are located.
A dialog box is displayed in which to review the installation parameters

and confirm them.
10. In SOFTWARE to install, click List.

11. Select Account Management Client.
12. Click OK to start the installation process. When installation completes, exit smit.
13. To run the Account Management Client, type the following command:
hostname# /user/lpp/AMC/accountMgm
Special Note for AIX

The AMC installation procedure does not install the Java Runtime Environment (JRE)
on AIX. You must install Java version 1.1.2 or higher before you can use the AMC.
On some version of AIX, JRE is on the installation CD-ROM. It is also available

from IBM on the World Wide Web.
After installation of the JRE, a symbolic link must be created as follows:

1. Change to Account Management Client directory:
hostname# cd /usr/lpp/AMC

Appendix A: Account Management Client Installation on HP UX and IBM AIX 411
2. Type the following command: A-E

hostname# ln -s /usr/jdk1.1.2 java
Appendix E: AMC Instal-

3. Enter the following command to confirm that the symbolic was successfully
lation on UX and AIX

created:
hostname# ls -1
hostname# java >/usr/jdk1.1.2

412

A-F
Appendix F: Security
Appendix B: Security
Considerations
Considerations
Solaris Notes The Security Association expiration time that the gateway sends in its IPSec proposals
(ISAKMP phase 2) can be configured using an environmental variable. Security
engineers do so with the following Solaris commands:
fw stop
setenv FWISAKMP_SAEXPIRE n
fwstart
n is the expiration time in seconds.
Additional 1. Security engineers must modify the cms.ini file on all machines running the
Information Firewall Module.
2. Security engineers must enable the connection between the FireWall-1 daemon
and the PKI, as part of the security policy. This can be done easily by defining
two TCP services for the CA and for the LDAP server and enabling them in the
rule base. (The TCP ports of these services are defined in the cms.ini file.)
3. The daemon which communicates with the PKI uses some run-time libraries
which are available in the $FWDIR/lib directory after FireWall-1 installation.
4. The environmental variable LD_LIBRARY_PATH has to be defined and
$FWDIR/lib must be specified as one of the directories in the list on each Firewall
Module to enable the FireWall-1 daemon to function.
413
414

Appendix C: Solaris
Command-Line Interface
Solaris/NT Syntax The command line syntax presented in this section is in Solaris syntax. Differences
Differences between Solaris and NT command line syntax are illustrated in the table below:
Table 8: Solaris/NT Syntax Differences
Solaris NT
/ in file names \ in file names
fwm fw m (space after fw)
fwd fw d (space after fw)
Setup Setup commands are used to reconfigure existing setups, install or uninstall
FireWall-1 software and to load/or kill various FireWall daemons.
fwconfig
fwconfig reconfigures an existing FireWall-1 installation.
Syntax
fwconfig
Windows NT
In Windows NT, the reconfiguration application is a GUI application that displays all
the configuration screens from the FireWall-1 installation as tabs in the same screen.
415
416
Figure 274: FireWall-1 Configuration screen
To reconfigure an option, select the appropriate tab and modify the fields as required.
Click OK to apply the changes.
Solaris
fwconfig displays the following screen. Choose the configuration options you
wish to reconfigure.
Welcome to FireWall-1 Configuration Program.

==========================
This program will let you re-configure your FireWall-1 configuration.
Configuration Options:
----------------------
(1) Licenses
(2) Administrators
(3) GUI clients
(4) Remote Modules
(5) Security Servers
(6) SMTP Server
(7) SNMP Extension
(8) Groups
(9) IP Forwarding
(10) Default Filter
(11) Random Pool
(12) CA Keys
(13) Exit
Enter your choice (1-13):
Thank You...

Appendix C: Solaris Command-Line Interface 417
fwconfig Configuration Options
fwinstall fwinstall installs the FireWall-1 software from the files extracted from the distribution
media. The configure option of fwinstall can be used to modify an existing
configuration, and the upgrade option can be used to upgrade to a newer version of
FireWall-1.
fwuninstall fwuninstall does the following:

• Runs fwstop
• Removes FireWall-1 from the kernel and .rc file(s)
• Restores inetd.conf
fwuninstall does not remove the FireWall-1 software from your hard disk. If you want
to reinstall FireWall-1 after running fwuninstall, you can run fwinstall and choose the
reconfigure option, or run fwconfig.
fwinstall and fwuninstall are UNIX only commands.
fwstart fwstart does the following:

• Loads the FireWall-1 FireWall Module
• Starts the FireWall-1 daemon (fwd)
• Starts the FireWall-1 SNMP daemon (snmpd)
• Starts the authentication daemons
• Starts fwm, the Management Server
fwstop fwstop kills the FireWall-1 daemon (fwd), the Management Server (fwm), the
FireWall-1 SNMP daemon (snmpd), and the authentication daemons, and then
unloads the FireWall Module. It tells the Kernel Module to detach itself from the TCP/
IP protocol stack and removes it from the kernel in architectures where possible.
This component is security enforcing.

418
fw The fw program manages the system. Its specific action is determined by the first
command line argument. Commands may have a subject (target). Three options
(parameters) specify the targets. If more than one is used, the command executes on
the combination of targets.
Control The control commands compile and install a Security Policy and Inspection Script as
well as create Log Files, install FireWall-1 authentication passwords and licenses and
download user database objects.
fw load fw load compiles INSPECT code. It then installs the security policy on the target
computers, using either ioctl’s (if it needs to install the security policy on the local
computer), or calling a remote fwd (if it needs to install the security policy on remote
computers). The same functionality is also available in the daemon and the
Management. This component is security enforcing.
Syntax
fw load [-all | -conf confile] [filter-file | rule-base] targets
fw load compiles and installs an Inspection Script (*.pf) file into the targets’ FireWall
Modules. It converts a Rule Base (*.W) file created by the GUI into an Inspection
Script (*.pf) file and performs the above operations. If no target is specified, the
Inspection Code is installed on the local host.
Targets
-conf confile — the command is executed on targets specified in confile; each line
in confile has the syntax of a target in a target.
-all — the command is executed on all targets specified in the default system
configuration file ($FWDIR/conf/sys.conf).
targets — the command is executed on the specific named target; the dot (.) and
the at-sign (@) are part of the format; spaces around them are not allowed.
For each option, it is sufficient to type the first character.
If the first argument is “-d” then debug information is generated as fw runs.
Formats
interface.direction@host
host
interface.direction

Example
le0.in@host1
all@host2
host3
all.out
all.all
Parameters
interface — name of an interface on the target host; if all is specified, all configured
interfaces on the target host are loaded. Examples: le0; lo0; all.
direction — in, out, or all; the reference point for the direction is the target host.
host — target host specified using the host’s name (the name returned by the
hostname command) or its IP address
all — different meanings according to its place; may specify both directions, all
interfaces or both directions on all interfaces.
If host is not specified, localhost is assumed. If only host is specified, all is assumed
(meaning both directions on all interfaces).
Several targets may be specified in various formats. Command line separators are
subject to the rules of the shell. Spaces and tabs are the most common separators.
The format of configuration files is identical to the format of targets. In configuration
files, the following separators may be used:
Space,
Tab
Comma
New Line
Before loading any interface of a target host, FireWall-1 first completely unloads it.
Hence, some interfaces on a target host might be left unloaded (if the new Rule Base
or compiled FireWall Module does not contain a rule for them).
The scope of a set of rules in a Rule Base and the targets of a Rule Base
installation are not the same. The system will install the entire Rule Base
on the designated targets. However, only the rules whose scope includes
the target system are actually enforced on a target.

420
To protect a target, you must load a Rule Base that contains rules whose scope
matches the target. If none of the rules are enforced on the target, then all traffic
through the target is blocked.
Example
fw load my_rules.W
fw load gateway.pf gateway1
fw load -all complex_rules.pf
fw unload fw unload uninstalls the currently loaded Inspection Code from selected targets.
Syntax
fw unload [-all | -conf confile] targets
Example
fw unload gateway1
fw unload -a
fw fetch fw fetch fetches the last Inspection Code installed on the local host. You must specify
the Master where the Inspection Code is found. Use “localhost” if there is no Master
or if the Master is down. You may specify a list of Masters, which are then searched in
the order listed. It is security relevant.
Syntax
fw fetch targets
Example
fw fetch gateway1

fw logswitch fw logswitch creates a new Log File. The current Log File is closed and renamed
$FWDIR/log/fw.log current date, and a new Log File with the default name
($FWDIR/log/fw.log) is created. Old Log Files are located in the same directory. You
must have the appropriate file privileges to run fw logswitch . In addition, a
Management Station can use fw logswitch to switch a Log File on a remote machine
and transfer the Log File to the Management Station. The module is security
enforcing. The same functionality is available in the FireWall Management Module.
Syntax
fw logswitch [-h target] [+|-][“” | old_log]
Parameters
target — the resolvable name or IP address of the remote machine (running either a
FireWall Module or a FireWall Management Module) on which the Log File is
located. The Management Station (on which the fw logswitch command is executed)
must be defined as one of target’s Management Stations. In addition, you must
perform fw putkey to establish a control channel between the Management Station and
target.
+ — the Log File is transferred from target to the Management Station. The
transferred Log File is compressed and encrypted. The name of the copied Log File on
the Management Station is prefixed by target. This parameter is ignored if target is not
specified. There should be no spaces between this parameter and the next one.
- — the same as +, but the Log File is deleted on target.
“” — delete the current Log File (on target if specified; otherwise on the Management
Station).
old_log — the new name of the old Log File.
The following tables list the files created in the $FWDIR/log directory on both target
and the Management Station when the + or - parameters are specified. Note that if “-”
is specified, the Log File on target is deleted rather than renamed.
If target is specified:
Table 9:
old_log specified old_log not specified

422
Table 10:
On target, the old Log On target, the new name

File is renamed to is current date. For
old_log. On the Manage- example, 04Feb98-
ment Station. The copied 10:04:20 in Solaris and
file has the same name 04Feb98-100420 in NT.
but is prefixed by target’s On the Management
name. For example, the Station, the copied file
command fw logswitch - has the same name but
h venus +xyz creates a is prefixed by target’s
file named venus.xyz on name (target.04Feb98-
the Management Station. 10:04:20 in Solaris and
target.04Feb98-100420
in NT.)
Table 11:
If target is not specified:
Table 12:
old_log specified old_log not specified
Table 13:
On the Management On the Management Sta-

Station, the old Log tion, the old Log File is
File is renamed to renamed to current date.
old_log.
If either the Management Station or target is an NT machine, the files are created
using the NT naming convention.
Example
The following command creates a new Log File and moves (renames) the old
Log File to old.log:
fw logswitch old.log

fw putkey fw putkey installs a FireWall-1 authentication password on a host. This specifies

which authentication (and possibly encryption) key to use between two firewalled
computers.
In stage A, this basic component is security irrelevant. In stage B, where fw putkey is

necessary for distributed management, this will be security relevant.
Syntax
fw putkey <target> [-p password]
This password is used to authenticate internal communications between FireWall

Modules and between a FireWall Module and its Management Center. The password
authenticates the control channel the first time communication is established. Enter
the password on the command line (using the -p argument), or interactively.
Parameters
target — the resolvable name of the machine on which you are installing the key
(password); this is not necessarily the “closest” interface to you. If you use the wrong
interface, then you will get error messages such as the following:
“./fwd: Authentication with hostname for command sync failed”
- p password — the key (password)
You will be prompted for this if you do not enter it on the command line.
fw putlic putlic installs a FireWall-1 license on a host. You can also configure licenses with the
fwconfig command.
This component is security irrelevant since the FireWall won’t stop protecting a
network because of an invalid license.
Syntax
fw putlic [-overwrite]
[-check-only] [-check-one] [-f licensefile]
[-n netmask] [-kernelonly]
hostname|ip-addr|hostid|eval
k1-k2-k3 features
Parameters
-overwrite — overwrite any existing licenses with the new license.
-check-only — verify the license.
-check-one -
-f licensefile — is the name of the file with the license text.

424
-kernelonly — copy the user level license to the kernel; takes no parameters.
hostname — is the host’s name (the name returned by the hostname command).
ip-addr — is the host’s IP address.
hostid — on Solaris systems, this is the EPROM number uniquely identifying the
host; on HP-UX systems, this is a hex number preceded by “0x”; on NT systems,
this is the IP address.
eval — is the evaluation license.
k1-k2-k3 — is the license.
features — are the license features.
Example
Typing:
fw putlic eval 2f540abb-d3bcb001-7e54513e std routers
produces output similar to the following:
Type Expiration Features

Eval 1Mar95 std routers
License file updated
Putting license in /etc/fw/modules/fwmod.XXX.o
fw dbload fw dbload downloads the user database and network objects information (for example,
encryption keys) to selected targets. If no target is specified, then the database is
downloaded to localhost.
Syntax
fw dbload [targets]

Monitor
Monitor commands display the status of target hosts, print lists of hosts protected,
display or export the content of Log Files, display the version number, and print
license details.
fw stat fw stat displays the status of target hosts in various formats. This is security irrelevant.
Syntax
fw stat [-all | -conf confile] [-long] [-short]

[-inactive] targets
The default format displays the following information for each host: host name, Rule
Base (or FireWall Module) file name, date and time loaded, and the interface and
direction loaded. If no target is specified, the status of localhost is shown.
Parameters
-short — use short format; for each direction and interface displays: host name,
direction, interface, Rule Base file name and loading date. This is the default format.
-long — use long format; in addition to short format, displays number of packets in
each of the following categories: total, rejected, dropped, accepted, and logged.
-inactive — displays status of inactive interfaces (using the selected format); an

inactive interface is an interface that had no packet flow since the last time the Rule
Base was loaded on that interface.
Example
fw stat
fw stat -s -a
fw stat -l gateway1
fw lichosts fw lichosts prints a list of hosts protected by the FireWall-1/n products.

The list of hosts is in the file $FWDIR/database/fwd.h.
Syntax
fw lichosts

426 Monitor
fw log
fw log displays the content of Log files.
This component is partially security enforcing and partially security relevant. Similar
functionality is also available in fwm.
Syntax
fw log [-f[t]] [-c action] [-l] [-start time] [-end time]
[-b stime etime]][-h hostname] [log-file] [-n]
The default Log file is $FWDIR/log/fw.log.
Parameters
-f — after current display is completed, do not exit but continue to monitor the Log
File and display it while it is being written.
-ft — same as -f but does not display the current Log, only new events.
-c action — displays only events whose action is action, that is, accept, drop, reject,
authorize, deauthorize, encrypt and decrypt; control actions are always displayed.
-start time — displays only events that were logged after time; time may be a date, a
time, or both. If date is omitted, then today’s date is assumed.
-end time — displays only events that were logged before time; time may be a date, a
time, or both.
-b stime etime — displays only events that were logged between stime and etime,
each of which may be a date, a time, or both; if date is omitted, then today’s date is
assumed.
-l — displays the date for each record.
-h hostname — displays only log entries sent by the firewalled machine hostname.
-n — does not perform DNS resolution of the IP addresses in the Log File (this option
significantly speeds up the processing)
logfile — use logfile instead of the default Log File.

Example
fw log
fw log | more
fw log -c reject
fw log -s Jan1
fw log -f -s 16:00
fw logexport fw logexport exports the Log File to an ASCII file.

This component is partially security enforcing and partially security relevant. Similar
functionality is also available in fwm.
Syntax
fw logexport [-d delimiter] [-i inputfile] [-o
outputfile]
[-r record_chunk_size] [-n]
Parameters
-d delimiter — output fields will be separated by this character; the default is comma
(,).
-i inputfile — is the name of the input Log File.
-o outputfile — is the name of the output ASCII file.
-r record_chunk_size — determines how many records should be read into the

internal buffer for processing during a single access to the Log File.
-n — does not perform DNS resolution of the IP addresses in the Log File. (This
option significantly speeds the processing.)
fw ver fw ver displays the FireWall-1 version number. This is the version of the FireWall-1
daemon, the compiler and the Inspection Script generator (fw gen). The version of the
GUI is displayed in the opening screen, and can be viewed at any time from the Help
menu. This component is security irrelevant.
Syntax
fw ver

428 Monitor
fw printlic printlic prints details of the FireWall-1 license.
This component is security irrelevant since the FireWall won’t stop protecting a
network because of an invalid license.
Syntax
fw printlic [-k]
Parameter
-k - Print the license in the Kernel ModuleExample
fw sam fw sam enables blocking connections to and from specific IP addresses without
changing the Rule Base.
Syntax
fw sam [-f FireWall-1 module] [-t timeout]
<-s src sport dst dport proto | -i ipaddr | -u ipaddr>
Explanation
The -f FireWall-1 module parameter specifies the FireWall Modules on which to
enforce the action.
Table 14:
If the value is… The action will be enforced

on ...
IP address (dot The specified FireWall

format) or
resolvable name
All All the FireWalls which are

defined as gateways or hosts
on the machine on which the
fw sam command is executed
Localhost The machine on which the fw

sam command is executed
Gateways All the FireWalls which are

defined as gateways on the
machine on which the fw
sam command is executed

-t timeout specifies the time period (in seconds) for which the action will be enforced.
The default is forever.
When the parameter -s src sport dst dport proto | -i ipaddr | -u ipaddr is used, the
connection with the given parameters is closed.
The following parameters are available for use with this parameter:
src — source IP address (dot format) or resolvable name
sport — source port (integer)
dst — destination IP address (dot format) or resolvable name
dport — destination port (integer)
proto — protocol (integer)
-i ipaddr — connections to and from this address (in dot format or resolvable
name) inhibited
-u ipaddr — inhibited connections to and from this address (in dot format or
resolvable name) uninhibited.

430 Utilities
Utilities
The Utilities commands perform various actions such as download security policy to a
specific router type, generate alerts, import or export the user database.
fwciscoload fwciscoload downloads a Security Policy to a Cisco router. This component is security
irrelevant unless routers controlled have an E3 certification.
Syntax
If only a password and an enable password are required, then the syntax is:
fwciscoload machine-name conf-file LoginPassword
EnablePassword
Parameters
machine-name — router name
conf-file — security policy file (must be in $FWDIR/conf)
LoginPassword — login password for the Cisco router
EnablePassword — enable password for the Cisco router
If the Cisco router uses the TACACS protocol. If a user name is required in addition to
the password and enable-password, then the syntax is:
fwciscoload machine-name conf-file UserName LoginPassword
EnableName EnablePassword
TACACS Parameters
machine-name — router name
conf-file — security policy file (must be in $FWDIR/conf)
UserName — user name
LoginPassword — login password for the Cisco router
EnableName — enable name
EnablePassword — enable password for the Cisco router
Each of the last four parameters can be XXX to indicate that it is unneeded, or
PROMPT to indicate that the user should be prompted for the parameter. Use
PROMPT when you do not want a password to appear on the command line or if the
password is not fixed (for example, with SecurID).
Alternatively, you can download the Security Policy using a TELNET-like interactive
session. You should use this option when the enable-login is not covered by the above
options. In this case, type:
fwciscoload machine-name conf-file -t

The interactive session will begin. Enter enable mode manually. Type Ctrl-C to exit
fwciscoload.
Type Ctrl-] to return to fwciscoload, which then downloads the Security Policy and
exits.
XXX and PROMPT are case-insensitive and cannot be used as either name
or password. If the TACACS authentication connection between the Cisco
router and the TACACS server passes through a firewalled machine, you
must enable the connection in the Rule Base.
Example
The command:
fwciscoload cis cis.cl XXX 1234 abcd PROMPT
downloads the policy file cis.cl (in $FWDIR/conf) to the router cis.
The login password is 1234.
There is no UserName.
EnableName is abcd.
The user is prompted for a password (for example, a SecureID password).
fw ctl fw ctlcommands send control information to the FireWall-1 Kernel Module. The
fw ctl debugging commands are presented in the debugging section of this
appendix.
Syntax
fw ctl [ip_forwarding option] | pstat | install |
uninstall
Parameters
ip_forwarding never — indicates that FireWall-1 does not control (and thus
never changes) the status of IP Forwarding.
ip_forwarding always — indicates that FireWall-1 controls the status of IP
Forwarding as described below.

432 Utilities
ip_forwarding default — indicates that FireWall-1 controls the status of IP

Forwarding only if IP Forwarding is disabled in the kernel; otherwise, FireWall-1
does not control (and thus does not change) the status of IP Forwarding. This is
the default setting.
pstat — display FireWall-1 internal statistics.
install — install the FireWall-1 kernel.
uninstall — uninstall the FireWall-1 kernel.
iflist — prints the interface list as seen by the fw.
Examples:
0: lo0
1:en
2:en10
fstat pstat prints statistical information gathered by the kernel module since the driver was
installed.
Syntax
fw ctl pstat
Example
Memory: 524288 bytes, 512224 avail, Requests: 637830 alloc, 637635 free,
0 reject
Inspect: 1853775 packets, 215915927 operations, 5098022 lookups, 241118

record, 94958150 extract
Cookies: 1972405 total, 411870 alloc, 411870 free, 30001 dup, 4344704 get,
120861 put, 2038056 len
Fragments: 142389 fragments, 0 expired, 24012 packets
Encryption: 39948 encryption, 38797 decryption, 22348 short, 0 failures
Translation: 245/1023021 forw, 222/829627 bckw, 467 tcpudp, 0 icmp, 36-31

alloc
fw ctl pstat output
Use Table 15 to interpret the pstat output.

Table 15:
Output Explanation
Memory: 524288 bytes, 512224 A pool of 524288 bytes were allocated by the FireWall-1 mod-
avail, Requests: 637830 alloc, ule kernel for its needs (mainly for internal dynamic and static
637635 free, 0 reject kernel tables). 512224 bytes are available in that pool. There
are 637830 allocation operations and 637635 free operations
while none had to be rejected due to memory exhaustion.
Inspct: 1853775 packets, This information relates to the virtual machine’s activity.
215915927 operations, 5098022 (Those are virtual machine operations, and lookups and records
lookups, 241118 record, 94958150 in tables and the number of packets inspected.)
extract
Cookies: 1972405 total, 411870 FireWall-1 uses an abstract data type, call cookie, to represent
alloc, 411870 free, 30001 dup, packets. This statistic relates to the code that handle those
4344704 get, 120861 put, 2038056 cookies and is used only for heuristic tuning of our code.
len
Fragments: 142389 fragments, 0 FireWall-1 performs ’virtual re-assembly’ which means that it
expired, 24012 packets gathers all the fragments of a packet before processing that
packet. This statistics information tells you that the kernel
module has processed 142389 fragments and assembled them
to 24012 packets while nonfragments were expired (fragments
expire when their packet fails to be reassembled in a 20 second
time frame or when, due to memory exhaustion, they cannot be
kept in memory anymore).
Encryption: 39948 encryption, This information relates to the amount of encrypted/decrypted

38797 decryption, 22348 short, 0 packets done by the kernel. The ’short’ element refers to the
failures number of packets which where not encrypted because they
had no data in them (they had only headers and the fwz scheme
does not encrypt the headers).
Translation: 245/1023021 forw, The information that relates to address translation. 245 of the
222/829627 bckw, 467 tcpudp, 0 1023021 packets, going on the 'forward' direction (forward –
icmp, 36-31 alloc. outgoing, backward - incoming), while 222 of the 829627
packets, going on the 'backward' direction, where translated.
467 of the translations were of TCP/UDP packets while no
ICMP packet had to be translated. 36 TCP/UDP port numbers
were dynamically allocated while 31 were deallocated.

434 Utilities
FP Forwarding When FireWall-1 controls the status of IP Forwarding, then FireWall-1 changes the
status as follows:
• When FireWall-1 is stopped (fwstop), IP Forwarding is disabled
• When FireWall-1 is started (fwstart), IP Forwarding is enabled
This ensures that there is never a time (after FireWall-1 has been started for the first
time) that the host is forwarding without the FireWall-1 FireWall Module being loaded
with a Security Policy.
It is recommended that IP Forwarding be disabled in the kernel. In this way, IP

Forwarding will be never be enabled unless FireWall-1 is working, no matter which of
the above options you have chosen.
Syntax
fw ctl ip_forwarding always
Enabling and SunOs 4

Disabling IP To disable IP Forwarding, type (as root):
Forwarding echo "ip_forwarding/W 0" | adb -w /vmunix /dev/kmem
You may wish to do this in /etc/rc.single, just before the sync command, as follows:
loadkeys -e
# Disable ip forwarding
echo "ip_forwarding/W 0" | adb -w /vmunix /dev/kmem
#
sync
exit 0
) < /dev/null > /dev/null 2>&1
To enable IP Forwarding, type (as root):

echo "ip_forwarding/W 1" | adb -kw /vmunix /dev/mem
Solaris 2.x (source routed packets)

To turn off IP Forwarding and source routed packets, edit /etc/rc2.d/S69inet and
change:
ndd -set /dev/ip ip_forwarding 1
to:
ndd -set /dev/ip ip_forwarding 0
ndd -set /dev/ip ip_forward_src_routed 0
HP–UX 9
To disable IP Forwarding, type (as root):
echo "ipforwarding/W 0" | adb -w /hp-ux /dev/kmem
You may wish to do this at the end of /etc/brc, as follows:

.echo "ipforwarding/W 0" | adb -w /hp-ux /dev/kmem

exit 0

echo "ipforwarding/W 1" | adb -w /hp-ux /dev/kmem
HP–UX 10
On HP-UX 10, the same commands (as for the HP-UX 9) can be put early in the rc2.d
directory, provided that /usr is mounted locally. In this case, you could put these
statements in /sbin/init.d/noipforward: The files in the rc2.d directory are executed
one after the other, in alphabetical sequence of their names.
#!/sbin/sh
PATH=/sbin:/usr/sbin:/usr/bin
export PATH
case "$1" in
start_msg)
echo "Turn IP-Forwarding OFF"
;;
stop_msg)
echo "(Not Turning IP-Forwarding on)"
;;
’start’)
if [ -x /usr/bin/adb ]; then
echo "ipforwarding/W 0" | adb -w /stand/vmunix
/dev/kmem
fi
;;
esac
exit 0
Make sure /sbin/init.d/noipforward is executable and link it to /sbin/rc2.d/

S001noipforward.
If /usr is not mounted locally, then put the above statements in a file that is executed
after /usr is mounted.

echo "ipforwarding/W 1" | adb -w /stand/vmunix /dev/mem
Windows NT Server
1. When you install FireWall-1, check Control IP Forwarding in the IP Forwarding
screen. If you have already installed FireWall-1, reconfigure FireWall-1 using the
FireWall-1 Configuration application. When you do so, the different configuration
options will be displayed as different tabs in the Configuration screen.
2. Enable the IP Enable Routing option in the Advanced TCP/IP Configuration
screen.

436 Utilities
3. This screen is accessible from the TCP/IP Configuration screen in the Networks
applet in the Control Panel.
4. Reboot the computer.
fw gen fw gen generates an Inspection Script (*.pf) file out of a Rule Base (*.W) file. The
command takes a Rule Base file as an argument and the Inspection Script is printed to
the standard output. Rule Base (*.W) files are created by the Graphical User Interface,
but you may edit them and use this command to generate Inspection Scripts (though
this is not recommended).
Syntax
fw gen <RuleBase_filename>
Example
fw gen $FWDIR/conf/default.W
fw gen $FWDIR/conf/corporate.W | more
fw gen $FWDIR/conf/corporate.W > /tmp/corporate.pf
fw kill fw kill sends a signal to FireWall-1 daemons fwd, fwm, snmpd, and any content
security servers running. This component is security irrelevant.
Syntax
fw kill [-t sig_no] proc-name
Parameter
[-t sig_no] proc-name — if the file $FWDIR/log/<proc-name>.pid exists, send

sig_no to the pid given in the file; if no signal is specified, signal 15 (SIGTERM)
is sent.
The FireWall-1 daemons and Security Servers write their pids to files in the log
directory during Start up. These files are named $FWDIR/log/ <daemon_name>.pid.
For example, the file containing the pid of the FireWall-1 snmp daemon is $FWDIR/
log/snmpd.pid.
Example
fw kill snmpd
sends signal 15 to the FireWall-1 snmp daemon.
fw kill -t 1 snmpd

sends signal 1 to the FireWall-1 snmp daemon.
fwc fwc is the FireWall-1 language compiler. It compiles an Inspection Script (*.pf) file
but does not install it. Use this command to see if your Inspection Scripts can be
compiled without actually installing them on FireWall Modules.
fwc takes an Inspection Script (*.pf) file as an argument and produces several files:
Inspection Code (*.fc) file, FireWall Module tables (*.ft) file, log format (*.lg) file
and *.set,*.db and *.objects files. These files are produced in the directory $FWDIR/
tmp.
fwm fwm is the FireWall-1 Management Server in the Client-Server implementation of the
Management Module. It is used to communicate with the GUI and to add, update and
remove administrators.
fwm must be running on the Management Server if you want to use the GUI client on
one of the client machines.
In stage A, this component is security irrelevant. In stage B, it is security relevant.
Syntax
fwm [-a name [-w{w|u|r|m}] [-s password] [-q]| -r name | -
p | -g]
Parameters
-a name — add or update an administrator.
-w — set access level as follows:
w — Read/Write
u — User Edit
r — Read Only
m — Monitor Only
-s password — set the administrator’s password.
-q — when adding an administrator, don’t prompt for the administrator’s
password (useful for batch updates).
-r name — delete an administrator.
-p — print a list of administrators.
-g — convert the old *.W files to one unified rulebases.fws that is used by fwm.

438 Utilities
To add an administrator, type:

fwm -a
You are prompted to type the user’s name and password. You are asked to confirm the
password by typing it a second time.
To delete an administrator, type:

fwm -r
You are prompted to type the user’s name.
fwell fwell manages Access Lists for Wellfleet routers. This component is security
irrelevant unless routers controlled have an E3 certification.
Syntax
fwell load rulebase-file [-s] [-u] [interface-
name@]router-name
[targets]
fwell unload [-s] [-u] [interface-name@]router-name
targets
fwell stat targets
Parameters
load — loads the Access List to the router.
unload — unloads the Access List.
-s — generate summary output.
stat — show statistics.
-u — specifies list of interfaces.
For example, the command: fwell stat well produces output similar to that
shown in Table 16.
Table 16:
Circuit IF FILTERDATE
E21 - -
S21 192.114.50.33 d423Mar95

10:34:13
S22 - -

When loading a Rule Base to a router, the router’s interfaces are first
unloaded. If the -u parameter is specified, then the virtual router’s
interfaces are unloaded. If the -u parameter is not specified, then the “real”
router’s interfaces are unloaded.
Individual Interface Rather than loading (or unloading) the Security Policy (Access Lists) to (or from) all
Loading for Bay the interfaces of a Bay Router, it is possible to specify individual interfaces.
Routers (Wellfleet)
Example
Suppose a Wellfleet router well has three interfaces: E21, S21 and S22; the
user might wish to define (manually, in objects.C) two “virtual” routers, well1
and well2, as follows:
(well1:ipaddr well:if-1E21)
(well2:ipaddr well:if-0S21:if-2S22)
The list of interfaces to be loaded or unloaded is specified in the command

line. For example, the command:
fwell load p.W E21@well1
performs the following actions:

1. Unloads E21, S21, S22 (all the interfaces of the “real” router well – this is
because the -u parameter was not specified)
2. Loads E21 (all the interfaces of the virtual router well1)
In practice, specifying E21 in the command line had no effect. All the interfaces were
loaded but well1 has only one interface.
p.W is the name of the Rule Base file.
The command:
fwell load -u p.W well2

• Unloads S21 and S22 (all well2 interfaces; this is because the –u parameter was
specified)
• Loads S21 and S22 (all well2 interfaces)
The command:
fwell load -u p.W S21@well2

440 Utilities

• Unloads S21 (the only interface specified in the command line)
• Loads S21 (the only interface specified in the command line)
fw tab fw tab displays the content of Inspection Tables on the target hosts in various formats.
This component is security irrelevant.
Syntax
fw tab [-all | -conf confile] [-short] [-max num] [-u]
[-table name] targets
Default format displays for each host: host name and a list of all tables with their
elements
Parameters
-all — display all tables.
-conf confile — read parameters from confile.
-short — use short format: host name, table name, table ID, and its number of
elements.
-max num — for each table, display only its first num number of elements (default is
16).
-u — do not limit the number of displayed entries.
-table table_name — display only table_name table.

Example
fw tab
fw tab -t hostlist1 gateway1
fwxlconf fwxlconf is the FireWall-1 Address Translation configuration utility.
snmp_trap snmp_trap sends an SNMP trap to the specified host. The message may appear in the
command line, or as one line in the program input (stdin).

• host – the name of the host that should receive the trap
• message – the message sent to host.
Usage: snmp_trap [-v var] [-g generic_trap]
[-s specific_trap] host [message]
-v var: an optional object id to bind with the message
-g generic_trap: One of the values:
0 coldStart
1 warmStart
2 linkDown
3 linkUp
4 authenticationFailure
5 egpNeighborLoss
6 enterpriseSpecific (default value)
-s specific_trap: a unique number specifying
the trap type; valid only if generic trap
value is enterpriseSpecific (default value is 0)
snmp_trap is the default command in SNMP Trap Alert Command in the Logging and
Alerting tab of the Properties Setup screen (Windows GUI) and in the Control
Properties/Logging and Altering screen (OpenLook GUI). You can use the -v flag to
send the value of one of the FireWall-1 MIB variables.
In stage A, only the snmp_trap part of the alert component is security enforcing (for
SNMP traps). In stage B, the entire basic component will be security enforcing.
status_alert status_alert generates an alert. status_alert is used in the Command field of the Status
View Actions screen and in the Action on Transition field in the Options screen.
User Database: These components access and modify the user’s database and include the utilities fw
Importing and dbexport and fw dbimport. Similar functionality is available in the management
Exporting daemon. In stage A, this basic component is security irrelevant. In stage B, it will be
security relevant.
Importing
To import users into the FireWall-1 User Database from an external source, you must
create an ASCII (text) file with the required information and import the file into
FireWall-1 using the fw dbimport utility.

442 Utilities
Syntax
fw dbimport [-m] [-s] [-v] [-r] [-k errors] [-f file] [-d
delim]
Parameters
-m — indicates that if an existing user is encountered in the import file, the user’s
default values will be replaced by the values in the template (the default template or
the one given in the attribute list for that user in the import file), and the original
values will be ignored; if -m is not specified, then an existing user’s original values
will be not be modified.
-s — suppress the warning messages issued when an existing user’s values are
changed by values in the import file.
-v — is verbose mode.
-r — dbimport will delete all existing users in the database.
-k nerrors — continue processing until nerror errors are encountered. The line count
in the error messages starts from one including the attributes line and counting empty
or commented out lines.
-f file — specifies the name of the import file. The default import file is $FWDIR/
conf/user_def_file.
-d — specifies a delimiter different from the default value (;).
To ensure that there is no dependency on the previous database values, use the -r flag
together with the -m flag.
The import file must conform to the following syntax:

1. The first line in the file is an attribute list.
The attribute list can be any partial set of the following attribute set, as long as
name is included:
{name; groups; destinations; sources; auth_method; fromhour;
tohour; expiration_date; color; days; internal_password;
SKEY_seed; SKEY_passwd; SKEY_gateway; template; comments; userc}__
2. The attributes must be separated by a delimiter character.
The default delimiter is the ; character. However, you can use a different character
by specifying the -d option in the command line.
3. The rest of the file contains lines specifying the values of the attributes per user.
The values are separated by the same delimiter character used for the attribute list.
An empty value for an attribute means use the default value.

4. For attributes that contain a list of values (for example, days), enclose the values
in curly braces, {}.
Values in a list must be separated by commas. If there is only one value in a list,
the braces may be omitted.
A + or - character appended to a value list means add to delete the values in the
list from the current default user values.
Otherwise, the default action is to replace the existing values.
5. Legal values for the days attribute are: MON, TUE, WED, THU, FRI, SAT, SUN.
6. Legal values for the authentication method are:
Undefined, S/Key, SecurID, Solaris Password, FireWall-1 Password, RADIUS,
Defender.
7. Time format is hh:mm.
8. Date format is dd-mmm-yy, where mmm is one of Jan, Feb, Mar, Apr, May, Jun,
Jul, Aug, Sep, Oct, Nov, Dec.
9. If the S/Key authentication method is used, all the other attributes regarding this
method must be provided.
10. If the FireWall-1 password authentication method is used, a valid FireWall-1
password should be given as well.
11. The password should be encrypted with the C language encrypt function.
12. Values regarding authentication methods other than the one specified are ignored.
13. The userc field specifies the details of the user’s SecuRemote connections, and
has three parameters, as follows:

444 Utilities
Table 17: userc Parameters
Parameter Values
key encryption FWZ1, DES,

method CLEAR, Any
data encryption FWZ1, DES,

method CLEAR, Any
integrity MD5,[blank] =
method no data integ-
rity
“Any” means the best method available for the connection. This depends on the
encryption methods available to both sides of the connection.
Example
If userc is {FWZ1,FWZ1,MD5}:
Key encryption method is FWZ1.
Data encryption method is FWZ1.
Data integrity method is MD5.
If userc is {DES,CLEAR,}
Key encryption method is FWZ1.
No data encryption.
No data integrity.
If userc is {Any,Any,}:
Use “best” key encryption method.
Use “best” data encryption method.
No data integrity. A line beginning with the ! character is considered a
comment.
After preparing the import file, execute fw dbimport to import the users into the
FireWall-1 User Database.
Exporting
You can export your User Database to an ASCII file using fw dbexport.
The generated file has the same syntax as the import file for fw.
Syntax
fw dbexport [-f file] [-u username] [-d delim]

Parameters
-f file — specifies the name of the output file. The default output file is $FWDIR/
conf/user_def_file.
-u username — specifies that only one user (username) be exported.
-d — specifies a delimiter different from the default value (;).

446 Utilities

Appendix D: Check Point
Products License Features
f o r Ve r s i o n 4 . 0
Evaluation Products
Product_Name Description Features Features_Mgmt

CPFW-EVAL-1-3DES FireWall-1Evaluation pfmx connect vpnstrong controlx oseu motif
Package with 3DES ram1 srunlimit embedded vpnstrong
encryption srunlimit
CPFW-EVAL-1-DES FireWall-1Evaluation pfmx connect vpndes controlx oseu motif

Package with DES ram1 srunlimit embedded vpndes
encryption srunlimit
CPFW-EVAL-1-FWZ1 FireWall-1Evaluation pfmx connect vpn ram1 controlx oseu motif

Package with FWZ1 srunlimit embedded vpn srunlimit
Encryption
CPFW-EVAL-1-40BIT FireWall-1 Evaluation pfmx connect skip isakmp controlx oseu motif
Package with 40 Bit ram1 srunlimit embedded skip isakmp
Encryption srunlimit
CPFW-EVAL-1 FireWall-1 Evaluation pfm activemod control oseu embedded
Package Non-VPN motif
CPOS-EVAL-1 Evaluation Copy for OSM rcc

(Open Security Manager)
447
448 Single Gateway Products
Single Gateway Products

CPFW-FIG-25-V40 Firewall Internet Gateway/ stdlight25
25
CPFW-FIG-50-V40 Firewall Internet Gateway/ stdlight50

50
CPFW-FIG-100-V40 Firewall Internet Gateway/ stdmed100

100
CPFW-FIG-250-V40 Firewall Internet Gateway/ stdmed250

250
Enterprise Products

CPFW-EPC-U-V40 Enterprise Center pfm control
CPFW-NSC-U-V40 Network Security Center pfm control routers
Inspection Module

CPFW-IM-1-V40 FireWall-1 Inspection pfi1 enc1
Module

Appendix D: Check Point Products License Features for Version 4.0 449
FireWall Modules

CPFW-FM-25-V40 Firewall Module/25 pfm25
CPFW-FM-50-V40 Firewall Module/50 pfm50
CPFW-FM-100-V40 Firewall Module/100 xlate auth content highav

medium100
CPFW-FM-250-V40 Firewall Module/250 xlate auth content highav

medium250
CPFW-FM-U-V40 Firewall Module/Unlimited pfm
Add On Modules

CPFW-AM-250-V10 Account Management on am1
25-250 LDAP servers
CPFW-AM-U-V10 Account Management ram1

onUnlimited LDAP servers
CPFW-CC-U-V40 Connect Control Module connect
CPFW-ENC-25- 3DES Encryption Module for vpnstrong enc25 vpnstrong ca

3DES-V40 25 Nodes
CPFW-ENC-25-DES- DES Encryption Module for vpndes enc25 vpndes ca
V40 25 Nodes
CPFW-ENC-25- FWZ1 Encryption Module vpn enc25 vpn ca

FWZ1-V40 for 25 Nodes
CPFW-ENC-25-40bit- 40BIT Encryption Module for skip isakmp enc25 skip isakmp ca
V40 25 Nodes
3DES-V40 50 Nodes
CPFW-ENC-50-DES- DES Encryption Module for vpndes enc50 vpndes ca

V40 25 Nodes

450 Single Gateway Products

CPFW-ENC-50-40bit- 40BIT Encryption Module for skip isakmp enc50 skip isakmp ca
V40 50 Nodes

3DES-V40 100 Nodes
CPFW-ENC-100- DES Encryption Module for vpndes enc100 vpndes ca
DES-V40 100 Nodes

CPFW-ENC-100- 40BIT Encryption Module for skip isakmp enc100 skip isakmp ca
40bit-V40 100 Nodes

3DES-V40 250 Nodes
CPFW-ENC-250- DES Encryption Module for vpndes enc250 vpndes ca

DES-V40 250 Nodes

CPFW-ENC-250- 40BIT Encryption Module for skip isakmp enc 250 skip isakmp ca
40bit-V40 250 Nodes
CPFW-ENC-U-3DES- 3DES Encryption Module for vpnstrong encul vpndes ca

V40 Unlimited Nodes
CPFW-ENC-U-DES- DES Encryption Module for vpndes encul vpndes ca

V40 Unlimited Nodes
CPFW-ENC-U- FWZ1 Encryption Module vpn encul vpn ca

FWZ1-V40 for Unlimited Nodes
CPFW-ENC-U-40bit- 40BIT Encryption Module for skip isakmp encul skip isakmp ca
V40 Unlimited Nodes

Management Consoles

CPFW-ESC-U-V40 Enterprise Security Console control
Open Security Extension/Open Security Manager

CPFW-OSE-1 Security Console module for ose1
management of one 3rd part
Secuity Enforcement Device
CPFW-OSE-10 Security Console module for ose10

management of 10 3rd part
Secuity Enforcement
Device.
CPFW-OSE-U Security Console module for oseu
management of an unlimited
number of 3rd part Secuity
Enforcement Device.
CPOS-OSM-1 NT based security console osm1

for management of one
third-party security
enforcement point
CPOS-OSM-10 NT based security console osm10

for management of up to 10
third-party security
enforcement points
CPOS-OSM-U NT based security console rcc
for management of up to an
unlimited number of third-
party security enforcement
points

452 FireWall-1 Basic Features
FireWall-1 Basic Features
Name Use License for:

“am1” Account Management (LDAP)
“auth” Authentication
“ca” Encryption Management (Certificate

Authority)
“cmd” Command-line Interface
“connect” Connect Control Module (Load

Balancing) ‘activemod’ is an alias
“des” DES Encryption
“embedded” License to Manage an Unlimited

Number of Embedded Firewalls, with
an unlimited number of nodes
behind them
“encryption” FWZ1 Encryption (or other
encryption methods, in addition to
their particular license)
“filter” Generating an INSPECT script (.pf
file) from a .W file, for v2.x licenses,
‘fwgen’ is an alias
“fm” Packet Filtering, for v2.x licenses,
‘mod’ and ‘module’ are aliases
“fwc” Compiling INSPECT scripts (.pf files)
to Filtering Code (.fc file), for v2.x
licenses, ‘compil’ and ‘compiler’ are
aliases
“fwlv” Activating the OpenLook logviewer
“fwz” FWZ
“highav” High Availability
“isakmp” ISKMP/Oakley (IKE)
“light1” Only the FireWall machine itself can

be protected - No IP Forwarding
“light25” Up to 25 Internal Hosts behind the
FireWall


“light50” Up to 50 Internal Hosts behind the
FireWall
“manualipsec” Manual IPSec
“medium100” Up to 100 Internal Hosts behind the

FireWall

FireWall

FireWall
“motif” Controlling a Motif GUI
“msp” Signals that this is a MSP Product,

and not a normal FireWall-1
“ram1” Account Management (LDAP) from
a Remote Machine
“remote” Controlling Remote Modules
“remote1” Controlling 1 Remote Module
“remote2” Controlling 2 Remote Modules
“remote4” Controlling 4 Remote Modules
“router##” Controlling up to ## Routers (## is a

number between 1 an 15)
“routers” Controlling an Unlimited Number of
Routers (‘routers’ may also be called
‘oseu’)
“skip” SKIP Encryption
“srlarge” Up to 250 SecuRemote Clients
“srlight” Up to 50 SecuRemote Clients
“srmedium” Up to 100 SecuRemote Clients
“srsuper” Up to 500 SecuRemote Clients
“srulight” Up to 25 SecuRemote Clients
“srunlimit” Unlimited Number of SecuRemote

Clients
“strong” Strong Encryption (with Larger Key)


“ui” The OpenLook GUI (except for the
Log Viewer)
“unlimit” An Unlimited number of Internal

Hosts
“xlate” Address Translation
FireWall-1 Combined Features
Name Combination:
“control” “lcontrol” + “remote”
“controlx” “control” + “ca”
“lcontrol” “rcontrol” + “ui”
“rcontrol” “fwc” + “cmd” + “fwlv” +

“filter”
“rcc” “control” + “routers”
“enc1” “encryption” + “light1”
“enc100” “encryption” + “medium100”

“encul” “encryption” + “unlimit”
“pfi” “fm” + “xlate” + “highav” +

“unlimit”
“pfi1” “fm” + “xlate” + “highav” +

“light1”
“light25”

“light50”

Name Combination:
“pfm” “pfi” + “content” + “auth”
“pfm25” “pfi25” + “auth” + “content”

“pfm50” “pfi50” + “auth” + “content”
“pfmx” “pfm” + “encryption”
“stdlight1” “pfi1” + “auth” + “content” +

“lcontrol”
“stdlight25” “lcontrol” + “pfm25”
“stdlight50” “lcontrol” + “pfm50”
“stdmed100” “medium100” + “fm” +

“xlate” + “auth” + “content” +
“highav”
“stdmed 250” “medium250” + “fm” +
“xlate” + “auth” + “content” +
“highav”
“vpn” “fwz” + “skip” + “isakmp”
“vpndes” “vpn” + “manualipsec” +

“des”
“vpnstrong” “vpndes” + “strong”


Glossary
A access list — a list of policies to be enforced on routers. Access lists contain policies
in the order in which they are to be enforced.
access-control rights — provide multi-level access control to security engineers and

systems administrators.
Account Management Client — an independent module used to integrate an LDAP

server with FireWall-1 user authentication.
address-resolution protocol (ARP) — a TCP/IP protocol used to convert an IP

address into a physical address.
alertf — used to monitor the logging activity of a rule and issue a specific alert when
a condition is met.
asymmetric encryption — uses one key to encrypt a message and another to decrypt
the message.
B bouncing the firewall — the process of stopping and restarting the firewalled
computer. This causes the Firewall Module to reread the local masters file and allow
the Management Console to remotely install security policies.
C certificate authority (CA) — a trusted third party from whom a public key can be
obtained reliably, even via the Internet. The CA certifies a public key by generating a
certificate (digital signature). The digital signature acts as proof of the sender’s
identity. A digital signature is created using a public encryption-key scheme.
certificate (digital signature) — a digital signature (created by a certificate authority)

that acts as proof of a sender’s identity. A digital signature is created using a public
encryption-key scheme.
client encryption — SecuRemote technology that allows remote network users to

access their internal networks securely.
Connect Control Module — the FireWall-1 module containing the load-balancing

algorithms. Connect Control provides a redirection mechanism, ensuring that all
traffic (from the same connection) is directed to the same server.
457
458
D data encryption standard (DES and Triple DES) — a symmetric-key encryption

method that uses a 40-bit key and is illegal to export out of the US or Canada. DES
allows interoperability with ISAKMP- and SKIP-compliant firewalls, and provides
one standard for encryption.
Denial-of-Service attack (DoS) — a type of attack on a network that is designed to

bring the network to its knees by flooding it with useless traffic.
distinguished name (DN) — unique name for a FireWall-1 object that is made by
associating the sequence of DNs from the lowest level of a hierarchal structure up to
the root.
E Encapsulation — a form of FireWall-1 encryption (used with SecuRemote).

Encapsulation allows SecuRemote users to connect to hosts inside an encryption
domain.
encryption — the process that ensures data is secured when coming from or going to a
firewalled computer.
encryption key — software that decrypts encrypted data.
encryption module — the FireWall-1 module that provides DES encryption (for
SKIP and IPSec) and FWZ1 encryption.
enterprise management — a line of FireWall-1 products that manage any number of

firewall and inspection modules in a firewalled network.
F Firewall Module — the FireWall-1 component that implements security policies, log
events and communicates with management modules. The Firewall Module provides
inspection-module capabilities, user authentication, multiple-firewall synchronization
and content security.
FWZ — a proprietary-key management scheme that uses FWZ-1 (a worldwide

exportable encryption algorithm) and DES (North America only).
G GET — an FTP command that instructs a server to transfer a specified file to a client.
H HTTP redirect — FireWall-1’s mechanism for directing HTTP requests to a single

HTTP logical server.

Glossary 459
I in-place encryption — an encryption method that encrypts new IPSEC and IP

headers, which allows for greater performance than that provided by the following
encryption algorithms: manual IPSEC, SKIP and ISAKMP.
inspection module — the FireWall-1 component that provides access control, client
and session authentication, network-address translation, and auditing.
inspection script — a high-level machine language that provides the FireWall-1

inspection module with its rule base.
IP Security (IPSec) — a set of protocols that support secure exchange of packets at

the IP layer. For IPsec to work, the sending and receiving devices must share a public
key.
ISAKMP (Internet Security Association and Key Management Protocol) — the

encryption standard of the Internet Engineering Task Force (IETF), the main
standards organization for the Internet. The ISAKMP protocol provides a
consistent framework for transferring key and authentication data, independent of
encryption and authentication mechanisms.
L Lightweight Directory Access Protocol (LDAP) — a protocol that allows Internet

clients to access and manage databases of users over a TCP/IP connection. LDAP is
supported by Netscape and included in Windows NT version 5.X.
load balancing — the FireWall-1 algorithm that allows several servers in one network
to share and distribute the load among themselves, all while being protected by one
firewalled computer.
load-balancing algorithm — a component of FireWall-1 load balancing, load-

balancing algorithms determine which physical servers will fulfill communication
requests. The FireWall-1 load-balancing algorithms are server load, round trip, round
robin, random and domain.
load-balancing daemon (LHTTPD) — a component of FireWall-1 load balancing,

LHTTPD directs client packets to a server and notifies the client that all remaining
connections must be directed to the IP address of the selected server. Once a client has
established a connection and the load-balancing daemon has determined that the
incoming packet must be load balanced, the remainder of the client’s communication
is conducted without the load-balancing daemon’s intervention.
Load measuring — the FireWall-1 load-balancing component that is installed on

HTTP physical servers that are part of a logical-server group. Load measuring allows
FireWall-1 to direct communication requests to server with the lightest traffic.

460
load-measuring agent — a component of FireWall-1 load balancing, the load-

measuring agent is an application that allows the load-balancing daemon to query a
server’s load.
Log Viewer — a FireWall-1 GUI, the Log Viewer displays the login-and-alert fields
specified in the Log and Alert screen of a security policy’s properties.
logical server — a group of machines that provide the same services and are treated as
a group, among whose members a workload is distributed.
M Management Console — a FireWall-1 GUI client that provides for the management
of either a single security enforcement point or multiple distributed security
enforcement points.
management module — provides centralized, GUI-based security management

control and monitoring of firewall modules residing on local or distributed computers.
management server — manages the FireWall-1 database, the rule base, network
objects, servers, users, and more.
Manual IPSec — an encryption and authentication scheme that uses fixed security
keys that are exchanged manually.
masking rules — a process by which security engineers can make viewing a rule base
easier by hiding rules they do not want to see.
O Oakley — an Internet encryption protocol that enables two authenticated parties to

agree on secure and secret keying material. The Oakley protocol supports
compatibility with the ISAKMP protocol for encryption.
Open Platform for Secure Enterprise Connectivity (OPSEC) — a collection of

services that enable the FireWall-1 product line to be integrated with other
applications and services.
P persistent server mode — a component of FireWall-1 load balancing, persistent

server mode allows sessions to retain their load-balancing methods until the sessions
have ended.
public-key infrastructure (PKI) — a system of digital certificates, certificate

authorities, and other registration authorities that verify and authenticate external-
network transactions.
public-key encryption — an encryption scheme that uses two keys: one private and
one public. These keys are created using the Diffie-Hellman key scheme.

Glossary 461
R Registration Authority (RA) — approves the issuance of certificates (by certificate

authorities) and directory services where certificate information is stored.
Reliable datagram protocol (RDP) — a protocol used by FireWall-1 to agree on

encryption parameters.
remote management — an internal-network setup allowing remote management of

Firewall Modules; remote management is made up of FireWall-1’s Management
Console, the management module and the Firewall Module.
router access list — a list of policies to be enforced on the routers. The access list
contains the policies in the order in which they are to be enforced.
router-security management — provides security management for router-access

control lists across one or more routers.
S SecuRemote — a separate Check Point product and is based on a technology called

client encryption, which allows remote network users to access their internal
networks securely.
SecuRemote Client — the SecuRemote software installed on a client that

communicates with a firewalled computer.
SecuRemote kernel module — the core of SecuRemote, the SecuRemote kernel

module performs encryption functions.
security-policy file (SPF) — the FireWall-1 file (default.w) containing all security-
policy parameters; the SPF resides in the c:\winnt\fw\conf directory.
shared secret key — a secret decryption format needed to decrypt data .
sites — used with SecuRemote, sites are firewalled computers.
SKIP (Simple Key Management for Internet Protocol) — a key-management

protocol that defines the way encryption and authentication keys can be shared
securely between two parties.
SYNDefender — a proprietary FireWall-1 application that protects against denial-of-

service attacks from external networks.
SYN flooding attack — a type of attack on a network that is designed to bring the
network to its knees by flooding it with useless traffic.

462
T template — part of FireWall-1’s Account Management Client, a template is a

definition of users; changes made to a template are applied to all users who continue
to inherit at least some of their properties from the template.
tunneling-mode — an encryption method that works by encapsulating a network

protocol within packets carried by a second network. Tunneling-mode encryption
does this by embedding its own network protocol within a packet’s TCP/IP headers.
U user-defined tracking — the process by which the option of an alert or log is

established.
V virtual private network (VPN) — a private network overlaid on a public IP network

infrastructure (such as the Internet). Encryption in a VPN provides secured
connections between points where encrypted data travels along the Internet.
X X.500 — used with FireWall-1’s LDAP component, X.500 is an ISO and Internet
standard that defines how global directories should be structured.

Checkpoint - Advanced Firewall-1 Management CCSE Student User Guide

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Checkpoint - Advanced Firewall-1 Management CCSE Student User Guide

Transféré par

Droits d'auteur :

Formats disponibles

Advanced FireWall-1

All other products or services mentioned herein are trademarks or registered

Check Point Software Technology Ltd.

International Headquarters: U.S. Headquarters: Dallas Courseware Development:

E-mail: info@checkpoint.com HTTP://www.checkpoint.com

Please direct any comments concerning Check Point courseware to

Rev. B Document # CPTS-DOC-C1012

Introduction to Advanced FireWall-1 Management (CCSE) 1

CCSE Course Description .................................................................................... 1

Rev. B Document # CPTS-DOC-C1012

FireWall-1 Architecture ....................................................................................... 15

Document # CPTS-DOC-C1012 Rev. B

Rev. B Document # CPTS-DOC-C1012

Document # CPTS-DOC-C1012 Rev. B

Configuring SYNDefender ......................................................................................................... 85

Rev. B Document # CPTS-DOC-C1012

Lab 4: Anti-Virus Checking for Incoming E-Mail ............................................... 122

Unit III — Chapter 1:

Introduction ....................................................................................................... 141

Document # CPTS-DOC-C1012 Rev. B

Creating the Digital Signature .................................................................................................. 156

Unit III — Chapter 2:

Introduction ....................................................................................................... 167

Rev. B Document # CPTS-DOC-C1012

Review .............................................................................................................. 233

Unit III — Chapter 3:

Introduction ....................................................................................................... 235

Document # CPTS-DOC-C1012 Rev. B

Summary .................................................................................................................................. 260

Introduction ....................................................................................................... 263

Introduction ....................................................................................................... 285

Rev. B Document # CPTS-DOC-C1012

Multiple LDAP Servers ............................................................................................................. 288

Document # CPTS-DOC-C1012 Rev. B

Introduction ....................................................................................................... 325

Rev. B Document # CPTS-DOC-C1012

Introduction ....................................................................................................... 361

Introduction ....................................................................................................... 393

Document # CPTS-DOC-C1012 Rev. B

Troubleshooting Load Balancing and HTTP Logical Servers .................................................. 394

HP-UX Installation .................................................................................................................... 409

Solaris Notes ............................................................................................................................ 413

Solaris/NT Syntax Differences ................................................................................................. 415

Rev. B Document # CPTS-DOC-C1012

fwstop ....................................................................................................................................... 417

Document # CPTS-DOC-C1012 Rev. B

Evaluation Products........................................................................................... 447

Rev. B Document # CPTS-DOC-C1012

Document # CPTS-DOC-C1012 Rev. B

Chapter 1: The Firewall Challenge

Chapter 2: FireWall-1 Architecture Overview

Chapter 3: Product Overview

Rev. B Document CPTS-DOC-C1012

CCSE Course Description

Welcome to the Advanced FireWall-1 Management Check Point Certified Security

Course Objectives • Understand the FireWall-1 product as an enterprise-management solution

CCSE Course Layout I-1

• Working knowledge of firewall technologies

CCSE and CCSI courses will no longer provide certification to students

Document # CPTS-DOC-C1012 Rev. B

Course Map Intro

Chapter 2: FireWall-1 Architecture

Chapter 3: Product Overview

Chapter 2: User Defined Tracking