Auditing a Nokia IP 330 Check Point Firewall

Global Information Assurance Certification Paper
Copyright SANS Institute
Author Retains Full Rights
This paper is taken from the GIAC directory of certified professionals. Reposting is not permited without express written permission.
Interested in learning more?
Check out the list of upcoming events offering
"Auditing & Monitoring Networks, Perimeters & Systems (Audit 507)"
at http://www.giac.org/registration/gsna
ts.
fu
ll r
igh
Auditing a Nokia IP 330 Check Point Firewall-1 NG FP3
AnAudi
t
or
’
sPer
spect
i
ve
rr
eta
i
ns
SANS GSNA
Practical Assignment Version 2.1
January 27, 2004
04
,A
ut
ho
Curtis L. Hefflin, Jr.
©
SA
NS
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
1
Author retains full rights.
©
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
Table of Contents
Abstract ............................................................................................................ 3
1 Assignment 1 - Research in Audit, Measurement Practice, and Control....... 4
1.1
Introduction ............................................................................................ 4
1.2
Identify the system to be audited ........................................................... 4
1.3
Evaluate the risk to the system .............................................................. 6
1.3.1
Threat Sources ............................................................................... 6
1.3.2
General Risks to the System .......................................................... 8
1.4
What is the current state of practice, if any? ........................................ 11
1.4.1
General Resources ....................................................................... 11
1.4.2
Books............................................................................................ 11
1.4.3
Web Sites ..................................................................................... 12
2 Assignment 2 –Create An Audit Checklist................................................... 14
2.1
Policies, Procedures and Guidelines ................................................... 15
2.2
Identification & Authentication.............................................................. 16
2.3
Physical and Environmental................................................................. 18
2.4
Security Design and Configuration....................................................... 20
2.5
Continuity............................................................................................. 31
2.6
Audit Trail, Monitoring, Analysis and Reporting ................................... 33
3 Assignment 3 –Audit Evidence................................................................... 37
3.1
Audit..................................................................................................... 37
3.2
Residual Risks ..................................................................................... 85
3.3
System Auditability............................................................................... 86
4 Assignment 4 –Audit Report or Risk Assessment ...................................... 87
4.1
Executive summary.............................................................................. 87
4.2
Audit =findings
.......................................................................................
87
Key
fingerprint
AF19 FA27
2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
4.2.1
Policies, Procedures, and Guidelines ........................................... 87
4.2.2
Physical and Environmental.......................................................... 88
4.2.3
Security Design and Configuration ............................................... 88
4.2.4
Continuity...................................................................................... 90
4.3
Audit recommendations ....................................................................... 90
4.4
Costs.................................................................................................... 93
4.5
Compensating Controls ....................................................................... 94
Appendix A—References ................................................................................... 95
Appendix B—Physical and Environmental Security ........................................... 97
Appendix C—Management and IT Questionnaire .............................................. 98
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
2
Author retains full rights.
04
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
Abstract
This document partially fulfills of the requirements for the GIAC Systems and
Network Auditor (GSNA) certification. It is based on an audit of a Nokia
CheckPoint Firewall that provides network security protection for a small
consulting organization. The technical aspects of this audit were performed
during October and November of 2003.
©
SA
NS
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
3
Author retains full rights.
1 Assignment 1 - Research in Audit, Measurement Practice, and
Control
eta
i
ns
fu
ll r
igh
ts.
1.1 Introduction
Thi
saudi
ti
sper
f
or
medonasmal
lor
gani
zat
i
on’
spr
i
mar
yI
Pnet
wor
kf
i
r
ewal
l
.The
audit target is a Nokia IP 330 running CheckPoint Firewall-1/VPN-1 NG Feature
Pack 3 software. The firewall acts as the security gateway separating the
i
nt
er
nalnet
wor
k
,DMZ,‘
wi
l
dcar
d’net
wor
k
,andt
heI
nt
er
net
.Thewi
l
dcar
dnet
wor
k
is comprised of wireless and wired workstations externally positioned between
the Nokia Checkpoint Firewall and the border router. The firewall is also the VPN
terminator for remote user access. Remote user client workstations use
Checkpoint VPN-1 SecuRemote/SecureClient NG for secure connectivity to the
firm’
si
nt
er
nalnet
wor
kf
oracc
esst
of
i
l
e,dev
el
opment
,andt
ests
er
ver
s.
ut
ho
rr
1.2 Identify the system to be audited
This audit is on a Nokia IP 330 Firewall running IPSO 3.6 FCS6 operating
system, a BSD unix variant. The firewall software is CheckPoint Firewall-1 NG
Feature Pack 3. The following table provides additional firewall configuration
details.
©
SA
NS
In
sti
tu
te
20
04
,A
Nokia IP330
Model
IP330
Memory
64 MB
Key
fingerprint = AF19IPSO
FA273.6
2F94
998D FDB5 DE3D F8B5 06E4 A169 4E46
SW Release
FCS6
SW Version
Releng 1061 01.21.2003-230310
Interface Configuration
eth-s2p1
Unused
eth-s2p2
Unused
eth-s3p1
x.x.a.1
Internal interface—Internal
systems provide DNS, print,
and file services to internal
users. This is also the
encryption domain for
remote users to access
development and test
servers.
eth-s4p1
x.x.b.1
DMZ interface—Systems on
this net are natted to outside
for public and remote user
access.
eth-s5p1
x.x.c.21
Outside Interface—
Connected via hub to border
router. The wildcard network
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
4
Author retains full rights.
ts.
is on the x.x.c.x segment.
CheckPoint Firewall Software
- Check Point VPN-1/FireWall-1 NG Feature Pack 3 (Build 53225)
- Check Point SVN Foundation NG Feature Pack 3 (Build 53267)
- VPN-1 SecuRemote/SecureClient NG Feature Pack 3 (Build 53328)
04
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
The firewall acts as the security gateway separating the internal network, DMZ,
wildcard network, and the Internet. The firewall is also the VPN terminator for
remote users. Each network segment is connected via Linksys EtherFast 10/100
Workgroup Hubs. The following is an overview of the logical design.
©
SA
NS
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Organization Network Overview
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
5
Author retains full rights.
1.3
Evaluate the risk to the system
ts.
An evaluation of risks begins with the identification of threats and potential
outcomes. Threats are conditions, circumstances, and events with the potential
to cause harm to a system or the information it contains. The security control
objectives detailed below considers the variety of threats to which the Nokia
Checkpoint Firewall and the information assets it protects will be subject.
fu
ll r
igh
1.3.1 Threat Sources
eta
i
ns
There are a variety of potential threat sources with the capability and in some
cases intent to exploit system and design vulnerabilities as they relate to the
Nokia Checkpoint Firewall and the assets it protects. Threats can be borne by
humans, the system itself, the physical environment, and by nature. Human
threats can be either deliberate or accidental. The following list represents threat
source groupings [1] for the Nokia Checkpoint Firewall.
ut
ho
rr
 Individuals using network access –The threats in this category are
network-basedt
hr
eat
st
oanor
gani
zat
i
on’
scr
i
t
i
calasset
s.Theyr
equi
r
e
direct action by a person and can be deliberate or accidental in nature.
Potential outcomes include:
NS
In
sti
tu
te
20
04
,A
o Unauthorized system access
o Inserting malicious code
o Unauthorized access to system o Passive wiretapping
functions
o Active wiretapping
Key fingerprint
= AF19 FA27
2F94 998D
DE3D
F8B5 06E4 A169 4E46
o Unauthorized
disclosure
of FDB5 o
IP spoofing
data
o Traffic analysis
o Unauthorized modification or
o Disruption of network
destruction of data
communications
o Disruption of system
operations
o Misuse of system resources
©
SA
 Individuals using physical access –The threats in this category are
physical threat
st
oanor
gani
z
at
i
on’
scr
i
t
i
c
alass
et
s.Theyr
equi
r
edi
r
ect
action by a person and can be deliberate or accidental in nature. Potential
outcomes include:
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
6
Author retains full rights.
o Unauthorized initiation of network
connection
o Unauthorized facility access
o Destruction of facility
components
o Disruption of system operations
ts.
Hardware destruction
Hardware theft
Use of unauthorized hardware
Active wiretapping
Passive wiretapping
Unauthorized system access
Accidental hardware damage
fu
ll r
igh
o
o
o
o
o
o
o
 System problems –The threats in this category are problems with an
or
gani
z
at
i
on’
si
nf
or
mat
i
ont
ec
hnol
ogysy
s
t
ems
.Exampl
esi
ncl
ude:
rr
eta
i
ns
o Accidental data damage
o Accidental hardware damage
o External network
communications failure
o Internal network component
failure
o System component failure
,A
ut
o
o
o
o
Misconfigurations
Hardware defects
Software defects
Unavailability of related
systems
Viruses, worms, malicious code
Design flaws
Improper configuration
Operator error
ho
o
o
o
o
sti
tu
Training programs
Security policy
Configuration management
Backup and recovery
o
o
o
o
Patch management
Configuration guidelines
Change control
Firewall policy
NS
In
o
o
o
o
te
20
04
 Administration/Management problems –The threats in this category are
problems with the administration of information security and assurance
Key fingerprint
AF19 FA27 2F94
998D FDB5Examples
DE3D F8B5
06E4 A169
4E46
policies,=procedures,
and guidelines.
include
the lack
of, or
poor:
©
SA
 Other problems –The threats in this category are problems or situations
that are outside the control of an organization. This category of threats
i
ncl
udesnat
ur
aldi
s
as
t
er
st
hatcanaf
f
ectanor
gani
z
at
i
on’
si
nf
or
mat
i
on
technology systems as well as interdependency risks. Interdependency
risks include the unavailability of critical infrastructures
(telecommunications, electricity, etc.). Other types of threats outside the
control of an organization can also be included here. Examples of these
threats include:
o System component failure
o Network communications
o Electromagnetic Interference
o Lightning
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
7
Author retains full rights.
o Severe Storm
o Water Damage
ts.
failure
o Power disturbance/outage
o Fire
fu
ll r
igh
1.3.2 General Risks to the System
The following table represents the risks to the Nokia Checkpoint Firewall
including the Nokia hardware, IPSO operating system, Checkpoint Firewall NG
software, and firewall properties and rulebase configuration
Treat
Adverse Outcomes (risks)
ho
Vulnerability
rr
eta
i
ns
Each of the vulnerabilities listed below would be considered severe if they were
fully exploited. The threat/likelihood could be considered low to high depending
on the technical and procedural controls that are implemented to mitigate the
identified vulnerabilities.
The primary threat
Inadequate physical security controls
sources for this
could lead to the following potentially
vulnerability are
adverse outcomes.
individuals with physical  Unauthorized user interacts with
access to the office
a valid users computer system.
Key fingerprint = AF19 FA27
2F94hosting
998D FDB5
06E4 A169 4E46
space
the DE3D F8B5
 Unauthorized
user simply turns
or
gani
zat
i
on’
sc
omput
er
off a computer or networking
and network systems. In
device by hitting the off switch or
most cases this includes
pulling the power cable.
organization employees,  Unauthorized access to system
maintenance and
consoles can enable the user to
cleaning personnel.
interrupt the boot process to get
access to the root prompt.
 An attacker can boot the system
from a modified boot disk
 Physical access also enables
password guessing since
password lockout feature are not
typically enforced at the console.
 Unauthorized users can gain
access to backup media and
printouts of data/information.
 An unauthorized user can capture
network traffic by accessing hubs
and network cables.
©
SA
NS
In
sti
tu
te
20
04
,A
ut
Inadequate
physical security
controls to the
Nokia Checkpoint
Firewall.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
8
Author retains full rights.
The primary threat
Inadequate network access controls
source for this
to the Nokia IPSO operating system
vulnerability is
and checkpoint application could
individuals using
lead to unauthorized operating
network access
system and application configuration
including organization
changes. This can in turn lead to
staff with authorized and additional adverse outcomes,
unauthorized network
including:
access and outsiders
 Disruption of network
with unauthorized
communications
access.
 Disruption of system operations
 Unauthorized disclosure of data
 Unauthorized
modification/destruction of data
Misconfiguration of The primary threat
Considering the critical role the
Checkpoint firewall source for this
firewall plays in the security of the
properties and
vulnerability includes
or
gani
zat
i
on’
snet
wor
kacc
ess
i
bl
e
rulebase.
individuals with network assets, poorly configured firewall
and physical access to
properties and rules can lead to
the Nokia Checkpoint
numerous adverse outcomes.
Firewall. In most cases
 Disruption of network
these individuals are
communications
organization employees  Disruption of system operations
or contract network
 Unauthorized disclosure of data
engineers authorized to  Unauthorized modification or
Key fingerprint = AF19 FA27
2F94 998D
FDB5and
DE3D F8B5destruction
06E4 A169of4E46
access,
configure
data
managet
hef
i
r
ewal
l
’
s
 Unauthorized system access
properties and rulebase.  Misuse of system resources
The likelihood that
 Unauthorized initiation of network
firewall
connection
misconfigurations will
occur depend a great
deal on the training and
experience of the
network engineer as well
as the policies,
procedures, and
guidelines this person
must comply with.
©
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
Inadequate network
access controls to
the Nokia IPSO
operating system
and checkpoint
application
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
9
Author retains full rights.
The primary threat
The Nokia IPSO operating system is
source for this
essentially a highly configurable
vulnerability includes
router that supports a wide range of
individuals with network internet protocols, LAN and WAN
and physical access to
technologies, and remote
the Nokia device. In
management capabilities.
most cases these
Misconfiguration of this device can
individuals are
lead to numerous issues including:
organization employees  Disruption of network
or contract engineers
communications
authorized to access,
 Disruption of system operations
configure and manage
 Unauthorized initiation of network
the IPSO operating
connection
system properties. The
 Unauthorized system access
likelihood IPSO
operating system
misconfigurations will
occur depends a great
deal on the training and
experience of the
engineer as well as the
policies, procedures,
and guidelines this
person must comply
with.
KeyInadequate
fingerprint =policies
AF19 FA27
998Dthreat
FDB5 DE3D F8B5
4E46 policies,
The2F94
primary
Solid,06E4
wellA169
developed,
procedures and
source here is the
procedures, and guidelines will
guidelines
or
gani
zat
i
on’
s
diminish the likelihood of adverse
management and IT
outcomes of inadequate policies
staff. Management must procedures and guidelines including:
direct the development
 Ad hoc firewall policy changes
of and enforce
that have not gone through
compliance to
change control procedures
information assurance
 Rulebase implementations
and policies,
counter to security policy
procedures, and
 Inadequate backup and recovery
guidelines.
procedures can lead to the loss
or destruction of vital system
information.
 Lack of configuration guidelines
can lead to inconsistent system
configurations.
©
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
Misconfiguration of
Nokia IPSO
operating system
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
10
Author retains full rights.
Single point of failure in a device that
plays a critical security and access
role poses the risk of interruption of
access to important information,
software, applications, and services.
ts.
The primary threat
source for this
vulnerability includes
hardware and software
defects that could cause
system crashes and
hardware failures.
fu
ll r
igh
Inadequate
hardware
redundancy
ns
1.4 What is the current state of practice, if any?
Auditing perimeter networks appears to be a robust activity with numerous
resources available to the auditor. The resources range from general information
system auditing to specific Checkpoint Firewall-1 auditing guidelines. The
following sections include general resources, books, and websites.
te
tu
Related
Requirements
Audit Method
I
D
T
Comments
O
TCSEC, 3.1.2.1;
3.2.2.1; 3.3.2.1
TCSEC, 3.1.2.1;
3.2.2.1; 3.3.2.1
DoDD 5200.28,
Encl. 3, A.1
TCSEC
2.2.2.2
©
SA
AUD.2
The TCB shall protect
authentication data so that it
cannot be accessed by any
unauthorized user.
The TCB shall be able to
enforce individual
accountability by providing the
capability to uniquely identify
each individual ADP
The audit trail shall be of
sufficient detail to reconstruct
events in determining the cause
or magnitude of compromise
should a security violation or
malfunction occur.
sti
I&A.4
Source Document
In
I&A.3
Requirement Description
NS
Req.
Number
20
04
,A
ut
ho
rr
eta
i
1.4.1 General Resources
Federal and Department of Defense (DoD) agencies provide ample resources in
this area due to Federal and DoD Certification and Accreditation requirements.
Processes such as NIACAP (National Information Assurance Certification and
Accreditation Process) and DITSCAP (DoD Information Technology Security
Certification and Accreditation Process) provide security testing and evaluation
guidelines for information systems that will operate on Federal and DoD
networks. The guidelines are specific and provide solid auditable control and
procedural objectives. The following table is excerpted from a DoD information
security Requirements Traceability Matrix (RTM). It shows several DoD
Key
fingerprint
= AF19
FA27 2F94
998D FDB5 DE3D F8B5 06E4 A169 4E46
information
system
security
requirements.
(I)nterview, (D)ocument Review, (T)esting Techinque, and (O)bservation
1.4.2 Books
Inside Network Perimeter Security by Stephen Northcutt, Lenny Zelter, et al., is a
comprehensive information security book that covers defending network
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
11
Author retains full rights.
ts.
perimeters. It goes in to detail on the integration of various perimeter security
devices including routers, firewalls, VPNs, and Intrusion Detection Systems (IDS)
and how the devices are best positioned in perimeter security designs. Inside
Network Perimeter Security also presents a discussion on assessment
techniques. The Internal Assessment section provides several firewall control
objectives along with the tools and procedures for testing.
rr
eta
i
ns
fu
ll r
igh
Hacking Exposed provides a detailed view of how hackers, crackers and other
unauthorized users view information technologies, both network- and host-based,
and the tools and techniques that are used to exploit security vulnerabilities.
There is also detailed discussion on how security engineers can mitigated the
r
i
s
ksdi
s
cus
sed.Theaut
hor
smak
et
hepoi
ntt
hat“
mos
tf
i
r
ewal
l
sar
eof
t
en
misconfigured, unmai
nt
ai
ned,andunmoni
t
or
ed”
,t
husexpos
i
ngt
hepr
ot
ect
ed
network to unauthorized access. There are detailed discussions on how to
identify and exploit firewall vulnerabilities and misconfigurations using tools such
as nmap, netcat, firewalk and hping. The authors also describe
countermeasures that security engineers can employ to defend against the
various attack techniques presented.
04
,A
ut
ho
Managing Information Security Risks, The OCTAVE Approach provides
methodologies for self-directed security evaluations that was developed at the
CERT Coordination Center. It is designed to help an organization identify and
rank key information assets; weigh threats to those assets; and analyze
vulnerabilities involving technology and practices.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
tu
te
20
1.4.3 Web Sites
The following short list represents key information security web resources that
provide audit guidance.
NS
In
sti
 http://iase.disa.mil/
Information Assurance Support Environment (IASE)—IASE is a
Department of Defense sponsored clearinghouse for information
assurance information.
©
SA
 http://csrc.ncsl.nist.gov/ and http://csrc.ncsl.nist.gov/pcig/cig.html
National Institute of Standards & Technology (NIST) Computer Security
Resource Clearinghouse—This NIST site provides numerous information
assurance and security checklists and implementation guides referred to
as STIGs (Security Technical Implementation Guides)
 http://www.cert.org/octave/
Computer Emergency Response Team (CERT) developed The OCTAVE
(Operationally Critical Threat, Asset, and Vulnerability Evaluation) method
the defines a phased approach to a comprehensive, systematic, contextdriven information security risk evaluation.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
12
Author retains full rights.
 http://www.infosyssec.org
Information Systems Security Resource is a comprehensive security
information resource portal that provides links to relevant audit resources
including threat risk assessments and guides
fu
ll r
igh
ts.
 http://www.sans.org
The SANS (SysAdmin, Audit, Network, Security) Institute is a cooperative
research and education organization. It enables security professionals,
auditors, system administrators, and network administrators to share the
lessons they are learning and find solutions to the challenges they face.
The site provides numerous auditing resources via articles and research
papers.
04
,A
ut
ho
rr
eta
i
ns
 http://www.securityfocus.com
Security Focus is a comprehensive security portal providing wide and indepth information in all areas of information assurance and security.
©
SA
NS
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
13
Author retains full rights.
2 Assignment 2 –Create An Audit Checklist
fu
ll r
igh
ts.
The following tables address the technical and procedural control objectives in
auditing the Nokia Checkpoint Firewall. As previously discussed, the device sits
behind a border router and filters network traffic to and from the Internet,
‘
wi
l
dc
ar
d’LAN,i
nt
er
nalLAN,DMZ,andSecuRemot
econnec
t
i
ons.
In identifying the risks for each of the control objectives detailed below, the
following terms were used.
eta
i
ns
Vulnerability— a weakness in an information system, system security practices
and procedures, administrative controls, internal controls, implementation, or
physical layout that could be exploited by a threat to gain unauthorized access to
information or disrupt processing. [1]
,A
ut
ho
rr
Threat—an indication of a potential undesirable event. A threat refers to a
situation in which a individual (threat source) could do something undesirable (an
attacker initiating a denial-of-ser
vi
ceat
t
ackagai
nstanor
gani
z
at
i
on’
semai
l
server) or a natural occurrence (threat source) could cause an undesirable
out
come(
af
i
r
edamagi
nganor
gani
zat
i
on’
si
nf
or
mat
i
ont
echnol
ogy hardware). [1]
04
Likelihood—an estimate on the likelihood a threat source could or would exploit
vulnerability.
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
sti
tu
te
Risk—a function of the likelihood of a given threat-source exercising a particular
potential vulnerability and the resulting impact of that adverse event on the
organization. [6,14]
NS
In
The control objectives are broken down into seven information assurance and
security categories.
©
SA
Information Assurance and Security Categories
Policies, Procedures, and Guidelines
Identification & Authentication
Physical and Environmental
Security Design and Configuration
Continuity
Encryption
Audit Trail, Monitoring, Analysis and Reporting
Abbreviation
PPG
IAU
PEN
SDC
CON
ENC
ATR
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
14
Author retains full rights.
2.1
Policies, Procedures and Guidelines
Check 1 of 21
Information Security Policies, Procedures, and Guidelines.
1, 3, 10, 20, experience (Note: the numbers correspond to
the references in Appendix A)
Ensure that policies, procedures, and guidelines are
established for all aspects of information assurance as it
relates to the Nokia CheckPoint Firewall. Areas of concern
include Security Policy; Configuration Management; Backup
and Recovery; Patch Management; Configuration Guides;
Change Control; and Firewall Policy.
ts.
PPG-1
Description
Reference
ns
fu
ll r
igh
Control Objective
Vulnerability
Incomplete policies, procedures, and guidelines leaves the
Nokia Checkpoint Firewall system vulnerable to ad hoc
system configuration and firewall policy changes potentially
rendering the system and the assets it protects in a less
secure posture.
ut
ho
rr
eta
i
Risk
20
04
,A
Threat Source
The most likely threat source is an organization employee
making configuration changes to the Nokia IPSO operating
Key fingerprint = AF19system
FA27 2F94
FDB5 DE3D
F8B5 06E4
A169 4E46
and 998D
the Checkpoint
firewall
application.
©
SA
NS
In
sti
tu
te
Likelihood
It is probable that incomplete policies, procedures, and
guidelines exist in a small newly formed organization. In this
environment it is highly likely the threat source could
expose the vulnerability.
Compliance
Potential Outcome
The network protection provided by the Nokia Checkpoint
Firewall can be undermined without clearly documented
policies, procedures, and guidelines. Ad hoc firewall policy
changes that have not gone through change control
procedures can lead to misconfigurations that expose
information to unauthorized disclosure, modification, loss,
and/or destruction. Lax or non-existent backup and
recovery policies and procedures can lead to prolonged
interruption of service, and the loss or destruction of vital
system information.
Compliance to this control objective is met if the
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
15
Author retains full rights.
Test #
Compliant
Yes
No
ns
Security Policy
Configuration
Management
Backup and Recovery
Patch Management
Configuration Guides
Change Control
Firewall Policy
I-Interview D-Documentation
rr
PPG-1.3
PPG-1.4
PPG-1.5
PPG-1.6
PPG-1.7
How
Reviewed
I
D
eta
i
PPG-1.1
PPG-1.2
Control Objective to
Test
fu
ll r
igh
Testing
ts.
organization has documented policies, procedures, and
guidelines.
Interview key staff and review the documented policies,
procedures, and guidelines as detailed in the following
table.
The interview process and review of documentation is
somewhat subjective. Although a checklist is used, the
auditor must review and determine the completeness of the
documentation.
04
,A
ut
ho
Analysis
20
Key
= AF19
2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
2.2 fingerprint
Identification
& FA27
Authentication
Check 2 of 21
Individual identifier and password access
5, 8, 16, Experience
Ensure that Nokia IPSO operating system access, Checkpoint
application access for management, and SecuRemote access to
internal network resources is gained through the presentation of an
individual identifier and password.
Vulnerability
Lack of accountability due to shared accounts is the primary
vulnerability for this control objective.
NS
In
sti
tu
te
IAU-1
Description
Reference
Control Objective
©
SA
Risk
Threat Source
Threats to this vulnerability include authorized users who have
been granted user accounts and unauthorized users attempting to
access systems via shared or compromised user accounts.
Likelihood
The likelihood this vulnerability would be exploited is low
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
16
Author retains full rights.
ts.
considering that is common practice that all users receive unique
logon credentials. However, this is a small and relatively new
organization and may not have mature access control polices and
procedures in place. They may not necessarily recognize or
consider the risks of using shared accounts or having inadequate
audit trails.
ns
fu
ll r
igh
Potential Outcome
Inconclusive audit trail of user access to the Nokia Checkpoint
Firewall or the assets it protects. If threat sources were to
intentionally or accidentally disclose, modify, or destroy protected
information, tracking down the responsible individual would be
difficult.
Compliance to this control objective is met if there are unique
accounts and passwords for all authorized users accessing the
systems.
Testing
To test for unique accounts
1. Obtain a list of authorized users from management staff. The
users will include system administrators and SecuRemote
users.
2. Match unique account ID with the individual on the
authorized users list.
3. Note any exceptions.
4. Document all accounts and state role. There will likely be
Key fingerprint = AF19 FA27 2F94
998D
FDB5 DE3D
F8B5
06E4 A169
4E46 These should
system
accounts
used for
internal
processes.
be documented as well.
Analysis
Objective
©
Risk
SA
sti
Check 3 of 21
Password Complexity
5, 8, 16, Experience
Ensure that passwords are, at a minimum, an 8-12 character mix of
case sensitive upper case letters, lower case letters, numbers, and
special characters (e.g., 7Turt1e$).
Vulnerability
Weak passwords are relatively easy to compromise given the
numerous unix and widows-based tools available to exploit this
vulnerability.
Poorly configured technical control mechanisms that do not require
strong passwords, lockout features, or reuse limits all put the
system in a vulnerable position.
In
NS
IAU-2
Description
Reference
Control Objective
tu
te
20
04
,A
ut
ho
rr
eta
i
Compliance
Threat Source
Threats to this vulnerability include authorized users who have
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
17
Author retains full rights.
been granted user accounts and unauthorized users attempting to
exploit weak user access mechanisms. These individuals may use
physical and network access to exploit the vulnerabilities.
fu
ll r
igh
ts.
Likelihood
Given the current state of technical controls available in most
security related applications, it is unlikely that a given threat source
could exploit weak password vulnerabilities. However, the actual
likelihood depends on how well the procedural and technical
controls are implemented.
ho
rr
eta
i
ns
Potential Outcome
Potential outcomes include the disclosure of corporate information
from low valued assets to custom created applications and scripts.
Modification of custom application and scripts. Modification of
security configurations enabling continued unauthorized access
Destruction of custom created applications and scripts would
disrupt active projects. Service interruption would prevent remote
access to internal systems and development network access
Compliance to this control objective is met if the Nokia IPSO
operating system, Checkpoint firewall management interface, and
SecuRemote logon only accepts passwords that have an 8-12
character mix of case sensitive upper case letters, lower case
letters, numbers, and special characters (e.g., 7Turt1e$)
Key
fingerprint = AF19The
FA27
2F94 998D
FDB5 DE3D
F8B5 06E4
4E46
Testing
following
procedures
are required
to A169
test compliance:
1. Create an account within each application and provide noncompliant passwords. (Use very basic password such as
golf, boating, and jazz)
2. Note whether the passwords are accepted.
3. If accepted, log out of the system/application and log back in
using the newly created account.
4. Note the success or failure of the logon activity.
This procedure is completed and documented for the Nokia IPSO
operating system, Checkpoint firewall management interface, and
SecuRemote user authentication.
Objective
©
Analysis
SA
NS
In
sti
tu
te
20
04
,A
ut
Compliance
2.3
Physical and Environmental
PEN-1
Description
Reference
Control Objective
Check 4 of 21
Physical Access
2, 16, experience
Ensure that only authorized individuals with need-to-know or need-
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
18
Author retains full rights.
to-access requirements are granted physical access to the Nokia
Checkpoint firewall.
Vulnerability
Physical access to the Nokia Checkpoint Firewall by unauthorized
personnel can undermine the effectiveness of security and access
it is in place to provide.
ts.
Risk
fu
ll r
igh
Threat Source
Threat sources include organization employees, visitors, and nonemployed support and maintenance staff.
eta
i
ns
Likelihood
The likelihood of unauthorized physical access in a small office
environment is high unless certain mitigating measures are in
place.
04
,A
ut
ho
rr
Potential Outcome
Physical access can allow unauthorized users to modify system
control settings enabling additional access control violations.
Physical access can allow the user to gain console access to the
system. There is also a potential for service interruption by
deliberate or accidental power shut off or removal of network
commutations devices or cables. Physical access can potentially
result in the loss of the physical device by theft or destruction.
20
Key
fingerprint = AF19Compliance
FA27 2F94 998D
DE3D
F8B5 06E4
A169
4E46 access
Compliance
to thisFDB5
control
objective
is met
if physical
te
controls are in place to control access to the Nokia Checkpoint
Firewall.
Conduct site survey using the physical and environmental security
checklist (Appendix B) to ensure that the Nokia Checkpoint Firewall
is housed in a locked computer room and held within locked
cabinets. Check whether power and network cables are openly
exposed.
Objective
In
sti
tu
Testing
SA
NS
Analysis
©
PEN-2
Description
Reference
Control Objective
Risk
Check 5 of 21
Power supply
experience
Ensure the Nokia Checkpoint Firewall is plugged in to an
operational uninterruptible power supply (UPS) device.
Vulnerability
Small office environments may have unreliable power supplies and
unpredictable voltage fluctuations. They typically do not have
backup power sources such as generators.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
19
Author retains full rights.
Threat Source
Threats to this vulnerability are typically non-human in nature. They
may include physical and environmental factors such as building
supplied power failures and fluctuations, and natural factors such
as lightening, severe storms, and flooding.
fu
ll r
igh
ts.
Likelihood
The likelihood of a power outage is considered low, however
power/voltage fluctuations may occur more frequently.
In
Security Design and Configuration
NS
2.4
sti
tu
te
20
04
,A
ut
ho
rr
eta
i
ns
Potential Outcome
Thepr
i
mar
yout
c
omesi
ncl
udedamageordest
r
uct
i
onoft
heNok
i
a’
s
internal components including: power supply modules,
motherboards, memory modules, and hard drives. This can easily
result in data and system configuration loss and interruption of
access to protected assets and services.
Compliance
Compliance to this control objective is met if the Nokia is plugged
into an uninterruptible power supply (UPS) with the following
features:
 Automatic Voltage Regulation (AVR)
 Building wiring fault indicator
 Replace battery indicator
 Hot swap batteries
 Battery management capabilities
 Overload Indicator
Key fingerprint = AF19 FA27
998D
FDB5LEDs
DE3D F8B5 06E4 A169 4E46
 2F94
Status
Indicator
 Wide input voltage range
Testing
Conduct site survey using the physical and environmental security
checklist (Appendix B) to ensure that the Nokia firewall is plugged
in to a UPS device with the minimum features described above.
Analysis
Objective
©
SA
SDC-1
Description
Reference
Control Objective
Risk
Check 6 of 21
Firewall and Network architecture documentation
9, 10, experience
Ensure firewall and network architecture is clearly documented and
diagramed.
Vulnerability
Poorly documented and diagramed firewall and network
architecture does not accurately communicate actual
implementation.
Threat Source
Authorized system administrators implementing configuration
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
20
Author retains full rights.
changes based on poorly documented and diagrammed
architecture.
ts.
Likelihood
In a small, rapidly developing organization it is likely the actual
implementation is a head of the documentation.
fu
ll r
igh
Potential Outcome
The primary outcome is firewall rulebase misconfigurations which
could lead to disruption of service and unauthorized access.
Compliance to this control objective is met if the documented
firewall and network architecture matches the results of network
discovery scanning activities.
Testing should be carried out using the following procedures:
1. Obtain and review firewall and network documentation and
diagrams.
2. Use nmap to ping scan each network segment protected by
the Nokia Checkpoint Firewall.
3. Compare the results of the scan to the firewall and network
documentation.
4. Note any exceptions.
ns
Compliance
Objective
04
Analysis
,A
ut
ho
rr
eta
i
Testing
20
Key
fingerprint = AF19Check
FA27 2F94
998D FDB5 DE3D F8B5 06E4 A169 4E46
SDC-2
7 of 21
Firewall business requirements
Experience
Ensure firewall architecture supports business requirements and
security policy.
Vulnerability
The primary vulnerability is an inappropriate amount of access is
given to users, administrators, and remote access users due to
poor communication between management and security engineers.
tu
te
Description
Reference
Control Objective
©
SA
NS
In
sti
Risk
Threat Source
Authorized and unauthorized individuals using network resources
are the primary threat sources for the vulnerabilities.
Likelihood
The likelihood of this vulnerability being exploited is directly related
to how well the business requirements are communicated to the
individuals responsible for implementing the Nokia Checkpoint
Fi
r
ewal
l
’
sover
al
lc
onf
i
gur
at
i
onandr
ul
ebase.
Potential Outcome
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
21
Author retains full rights.
Disclosure of confidential information such as custom application
code, proposal drafts, service contracts, etc. This could also led to
accidental destruction of valuable information or intellectual
property.
Compliance to this control objective is somewhat subjective to
determine and is based in part on discussions with both the
managementst
af
fwhohavedevel
opedt
heor
gani
zat
i
on’
sbusi
ness
model and the network engineers who implement technical security
controls to protect critical assets and information. The auditor must
ascertain what assets are most valuable to the organization and
what level of access in to and out of each network security zone is
required for business purposes.
Use the following procedures to determine compliance.
1. Interview key management staff using the security
requirements questionnaire (Appendix C).
2. Interview network/system engineering staff using the security
requirements questionnaire (Appendix C)
3. Review firewall policies/rules to determine if implemented
network security meets management expectations and
requirements.
Subjective
fu
ll r
igh
ts.
Compliance
ho
rr
eta
i
ns
Testing
,A
ut
Analysis
©
SA
NS
In
sti
tu
te
20
04
SDC-3
Check 8 of 21
Description
Nokia IPSO operating system security
Key
fingerprint
=
AF19
FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Reference
Experience
Control Objective
Ensure Nokia IPSO operating system is secure and that
unnecessary services are disabled.
Risk
Vulnerability
Although the Nokia is installed with the pre-harden IPSO operating
sy
s
t
ems,i
t
’
soutoft
heboxconf
i
gur
at
ion will likely have
unnecessary and insecure network services enabled. Unnecessary
services and a default configuration may provide access for
unauthorized users.
Threat Source
Authorized and unauthorized individuals with network access. This
would include inexperienced network engineers who disable the
f
i
r
ewal
lappl
i
c
at
i
ony
etkeept
heNoki
a’
si
nt
er
f
ac
esat
t
achedand
active on the production network.
Likelihood
It is likely that the various threat sources noted above could exploit
an IPSO operating system service.
Potential Outcome
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
22
Author retains full rights.
An unauthorized user could gain access to the Nokia IPSO
operating system by way of its open and unprotected network
services. As a result the unauthorized user could disrupt network
services or use the platform to attack other segments of the
network.
Compliance to this control objective is met if all unnecessary
application ports are disabled and that secure applications (SSH
and HTTPS) are used for remote management.
Testing
The nmap and Nessus utilities for network scanning and security
auditing are used to test this control objective.
1. Review system configuration
2. Research possible vulnerabilities and attacks against the
Nokia IPSO operating system using the following internet
resources:
 CERT CC: http://www.cert.org/nav/index_red.html
 Bugtraq: http://www.securityfocus.com/bid
3. Use nmap to scan the Nokia IPSO operating system (be
sure the checkpoint firewall is disabled for this activity.)
4. Use Nessus to scan the Nokia IPSO operating system (be
sure the checkpoint firewall is disabled for this activity.)
5. Document the findings and map each open udp and tcp port
to its service/application. (e.g. 23/tcp-telnet, 80/tcp-http, etc.)
Some ports may require additional research to map its
corresponding service or application.
Key
fingerprint = AF19Objective.
FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Analysis
20
04
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
Compliance
Check 9 of 21
Firewall Application Security
Experience
Ensure firewall application is secure. Unnecessary services are
disabled.
Vulnerability
The default configuration of Checkpoint Firewall-1 may have
unnecessary network services enabled. Unnecessary services and
a default configuration may provide access points for unauthorized
users.
In
sti
tu
te
SDC-4
Description
Reference
Control Objective
©
SA
NS
Risk
Threat Source
Authorized and unauthorized individuals with network access. Inexperienced system administrators who have not thoroughly tested
the firewall prior to production implementation.
Likelihood
There is a medium likelihood that unauthorized users via network
access will compromise the firewall application given its default
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
23
Author retains full rights.
configuration.
ts.
Potential Outcome
An unauthorized user could gain access to the firewall application
and alter its configuration. This can in turn be used to disrupt
services and access to information resources.
Compliance to this control objective is met if all unnecessary
application ports are disabled. Additionally, the implemented
firewall policy/rulebase must adequately restrict access to the
firewall application.
The nmap and Nessus utilities for network scanning and security
auditing are used to test this control objective.
1. Review the firewall policy/rulebase to determine whether
access to the firewall application is adequately restricted to
authorized hosts and users.
2. Review the $FWDIR/conf/gui-clients file
3. Run the cpconfig command to verify firewall administrators
and their level of permissions.
4. Research possible vulnerabilities and attacks against the
Checkpoint Firewall application using the following internet
resources:
 CERT CC: http://www.cert.org/nav/index_red.html
 Bugtraq: http://www.securityfocus.com/bid
fu
ll r
igh
Compliance
04
,A
ut
ho
rr
eta
i
ns
Testing
20
Key fingerprint = AF19The
FA27
2F94 998Dfirewall
FDB5 application
DE3D F8B5 must
06E4 be
A169
4E46 for the
checkpoint
enabled
te
following scans
©
SA
NS
In
sti
tu
5. Use nmap to scan the Nokia Checkpoint Firewall from an
untrusted host.
6. Use Nessus to scan the Nokia Checkpoint Firewall from an
untrusted host.
7. Use nmap to scan the Nokia Checkpoint Firewall from a
trusted host. (This step will indicate ports, protocols, and
services available to management clients.)
8. Use Nessus to scan the Nokia Checkpoint Firewall from a
trusted host.
9. Document the findings and map each open udp and tcp port
to its service/application. (e.g. 23/tcp-telnet, 80/tcp-http, etc.)
Objective
Analysis
SDC-5, ENC-1
Description
Reference
Control Objective
Check 10 of 21
2, 8, 9, Remote management activity security
Experience
Ensure that Remote management activity to the Nokia IPSO
operating system and the firewall application are secured and
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
24
Author retains full rights.
encrypted.
Vulnerability
Nokia ipso operating system permits remote management via telnet
and http.
Risk
fu
ll r
igh
ts.
Threat Source
Authorized and unauthorized users with network analysis tools to
capture account information in data transmissions.
Likelihood
The likelihood in this case depends on the configuration of the
IPSO operating system remote management services.
rr
eta
i
ns
Potential Outcome
An unauthorized user could capture clear text account information
and use it to gain access to the Nokia operating system and alter
IPSO and firewall configurations.
Compliance is based on a review of the remote management
configuration settings for the Nokia IPSO operating system and
Checkpoint Firewall application. And, an analysis of captured
remote management traffic. All data, including usernames and
passwords, transferred between the systems must be encrypted.
Testing
The following procedures should be used to check for compliance
for this control objective:
Key fingerprint = AF19 FA27
998D
DE3D remote
F8B5 06E4
A169 4E46configuration
1. 2F94
Review
andFDB5
document
management
settings for the IPSO operating system.
2. Review and document firewall management settings in the
firewall application.
3. Use the ethereal network traffic analyzer to capture remote
management network traffic directed at the ipso operating
system and the firewall application.
4. Review network captures for any clear text transmissions.
Analysis
Objective
NS
In
sti
tu
te
20
04
,A
ut
ho
Compliance
©
SA
SDC-6
Description
Reference
Control Objective
Risk
Check 11 of 21
Firewall rulebase
9, 10, 12, experience
Ensure that the firewall rulebase is logically constructed and
annot
at
edandadher
est
ot
heor
gani
z
at
i
on’
ssec
ur
i
t
yandf
i
r
ewal
l
policies.
Vulnerability
A poorly constructed and annotated rulebase may have rules
inconsistent with the organization’
ssec
ur
i
t
yandf
i
r
ewal
lpol
i
c
i
es
.
Threat Source
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
25
Author retains full rights.
Authorized individuals (security engineers) with network access to
the Nokia Checkpoint Firewall. Security engineers can implement
poorly constructed rulesets. Unauthorized individuals with network
access are considered threat sources as they may gain access to
protected systems as a result of misconfigured rules.
fu
ll r
igh
ts.
Likelihood
This is likely to occur when firewall rules are implemented in an ad
hoc fashion, during emergencies, or without the guidance of firewall
policies and change control procedures.
rr
eta
i
ns
Potential Outcome
An unauthorized user can cause a disruption of service, or access
key information that could be destroyed, modified, or disclosed. An
authorized user may have an inappropriate level of access for the
tasks they are required to perform. This may lead to deliberate or
accidental destruction, modification, or disclosure of key
information.
Compliance is based on a thorough review of the firewall
configuration and rulebase. The firewall rulebase must be logically
const
r
uc
t
edandannot
at
edandadher
est
ot
heor
gani
z
at
i
on’
s
security and firewall policies.
Testing
Exami
net
heor
gani
z
at
i
on’
sf
i
r
ewal
landsecur
i
t
ypol
i
c
i
es
.Rev
i
ew
the rulebase for logical construction and proper annotations. Key
Key fingerprint = AF19configuration
FA27 2F94 998D
FDB5 DE3D
F8B5 06E4 A169 4E46
indicators
include:
 Network communications not explicitly permitted into a
protected network is denied access.
 Accepted services should be indicated, except on drop rules
where any (all) services are dropped. Otherwise the services
permitted should be detailed.
 Each rule should be commented indicating the purpose of
t
her
ul
e,dat
el
astmodi
f
i
ed,admi
ni
s
t
r
at
or
’
sname
 Tracking should log each rule, or where appropriate an alert
should be issued in addition to the log record.
 Review global policies
 Check that implied rules are logged
 Ensure that global policies are consistent with firewall
policy and ruleset.
Analysis
There are both subjective and objective elements to testing
compliance for this control objective. It is subjective in that there are
numerous ways to securely implement a firewall policy. However,
there are numerous elements that are objectively verified, including
logging, rule comments, and the principle that all traffic not explicitly
accepted is denied.
©
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
Compliance
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
26
Author retains full rights.
SDC-7
Description
Reference
Control Objective
Check 12 of 21
Internal network security
9, 10, 12, experience
Ensure that access to and from the internal network is appropriately
secured.
Vulnerability
Thesy
st
emswi
t
hi
nanor
gani
z
at
i
on’
si
nt
er
nalnet
wor
kt
y
pi
cally
contain the most valuable information assets. A poorly implemented
firewall may expose those assets to unauthorized access.
fu
ll r
igh
ts.
Risk
ns
Threat Source
The primary threat sources are unauthorized users who may exploit
firewall misconfiguration vulnerabilities. SecuRemote users also
pose a threat as they are given access to internal resources.
rr
eta
i
Likelihood
It is likely that unauthorized users could exploit a firewall
misconfiguration.
04
,A
ut
ho
Potential Outcome
Potential outcomes include information disclosure, unauthorized
access, data/information loss and modification. Authorized users
who connect via SecuRemote could gain access to systems not
intended for their use.
20
Key
fingerprint = AF19Compliance
FA27 2F94 998D
DE3D
F8B5 06E4
A169
4E46
Compliance
to thisFDB5
control
objective
is met
if the
firewall rulebase
tu
te
indicates that internal network access is not permitted from external
networks (Internet, DMZ, and wildcard networks). A review of the
remote access configuration indicates that SecuRemote users are
permitted to access only specific and necessary systems.
The following test procedures will test for compliance:
1. Review firewall rulebase
2. Review SecuRemote access configuration by reviewing the
firewall rulebase and remote access properties.
3. Review the user properties of each SecuRemote user.
Check that the location tab indicates specific destination
systems.
4. Use the network security tools nmap and firewalk to attempt
to enumerate internal network resources from the DMZ,
Internet, and wildcard networks.
5. Create a new SecuRemote user, access the internal network
and use the superscan4 scanner to attempt to enumerate
internal systems.
Objective
©
SA
NS
In
sti
Testing
Analysis
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
27
Author retains full rights.
SDC-8
Description
Reference
Control Objective
Check 13 of 21
DMZ network security
9, 10, 12, experience
Ensure that access to and from the DMZ network is appropriately
secured.
Vulnerability
Systems on the DMZ are typical accessible from the Internet and
from all organization networks. There is the risk that an
unauthorized user who has compromised a DMZ system could
initiate another attack from that machine to a host within or outside
t
heor
gani
z
at
i
on’
snet
wor
k
.Ther
ef
or
e,i
nt
er
nalandex
t
er
nal
networks are vulnerable if the firewall system permits DMZ systems
to initiate connections to other network segments.
ns
fu
ll r
igh
ts.
Risk
rr
eta
i
Threat Source
The primary threat sources are unauthorized users who may exploit
firewall misconfiguration vulnerabilities.
ho
Likelihood
Highly likely unless mitigated at properly configured firewall.
04
,A
ut
Potential Outcome
If the chain of events occurred as described above, potential
outcomes include information disclosure, unauthorized access,
data/information loss and modification.
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Compliance to this control objective is met if the firewall rulebase
indicates that access to DMZ systems is permitted and
appropriately logged. The review must also show that any DMZ
system initiated traffic is blocked from entering the internal and
wildcard networks. Also, any DMZ system initiated traffic destined
for the Internet is restricted, logged, and monitored.
The following test procedures will test for compliance:
1. Review firewall rule base
2. Use the network security tools nmap and firewalk to attempt
to enumerate internal network resources from the DMZ.
3. Use the ethereal network traffic analyzer on the internal
network to capture any data originating from the DMZ.
In
sti
tu
te
Compliance
©
SA
NS
Testing
Analysis
Objective
SDC-9
Description
Reference
Control Objective
Check 14 of 21
Wildcard (wired and wireless segment) network security
9, 10, 12, experience
Ensure that access to and from the wildcard network is
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
28
Author retains full rights.
appropriately secured.
Vulnerability
In this small office environment WLAN if not properly configured
can exposes the entire network to unauthorized access.
Reviewing the configuration of the wireless network is out of
scope, however securing network traffic to and from the internal
network and DMZ is secured at the firewall.
ts.
Risk
ns
fu
ll r
igh
Threat Source
Unauthorized and authorized individuals with wired and wireless
access who are connected to the wildcard network. An additional
threat source is system problems associated with the WLAN
configuration.
rr
eta
i
Likelihood
If the wireless LAN is poorly secured, then it is likely that an
unaut
hor
i
zedus
ercoul
dac
cesst
heor
gani
zat
i
on’
sr
esour
cesf
r
om
that point.
,A
ut
ho
Potential Outcome
Potential outcomes include information disclosure, unauthorized
access, data/information loss and modification.
Compliance to this control objective is met if the firewall rulebase
indicates that wildcard network traffic is not permitted into the
Key fingerprint = AF19internal
FA27 2F94
998D Internet
FDB5 DE3D
F8B5 network
06E4 A169
4E46 is
network.
and DMZ
access
appropriately restricted and logged. An exception to the control
objective is granted if the wildcard network system uses
SecuRemote encryption to access internal network systems.
Testing
The following test procedures will test for compliance:
1. Review firewall rule base
2. Use the network security tools nmap and firewalk to
attempt to enumerate internal resources.
3. Use the ethereal network traffic analyzer on the internal
network to capture any data originating from the wildcard
network.
Analysis
Objective
SA
NS
In
sti
tu
te
20
04
Compliance
©
SDC-10
Description
Reference
Control Objective
Risk
Check 15 of 21
SecuRemote Security
9, 10, 12, experience
Ensure that SecuRemote access is appropriately configured to
protect internal network resources.
Vulnerability
SecuRemote enables remote users to access internal systems. If
not properly configured and appropriately restricted, remote users
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
29
Author retains full rights.
will have complete network access to all internal systems.
ts.
Threat Source
The primary threat sources are authorized users who have been
given remote access to internal systems. There is an additional
treat from unauthorized users who compromise the SecuRemote
client workstation
fu
ll r
igh
Likelihood
The likelihood depends in large part on the SecuRemote/remote
access configuration.
rr
eta
i
ns
Potential Outcome
If the SecuRemote/remote access parameters are poorly
configured, an authorized or unauthorized SecuRemote user can
enumerate the internal network. Potential outcomes include the
modification, destruction, or disclosure of valuable information
assets.
Compliance to this control objective is met if the SecuRemote
configuration indicates that remote access global properties, VPN
manager properties, and SecuRemote user properties are
appropriately configured.
Testing
The following test procedures will test for compliance:
1. Review the remote access VPN basic and advanced
Key fingerprint = AF19 FA27properties.
2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
2. Review the user properties of each SecuRemote user.
Check that the location tab indicates specific destination
systems.
3. Review firewall rulebase to ensure that the remote access
rule is logged and commented.
4. Create a new SecuRemote user and attempt to access
internal resources.
5. Use the SuperScan network security tool to attempt to
enumerate internal network resources from the
SecuRemote client.
6. Use the ethereal network analyzer to confirm that data in
transit between the SecuRemote client and the Nokia
Checkpoint Fireall is encrypted.
Analysis
Objective
©
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
Compliance
SDC-11
Description
Reference
Control Objective
Check 16 of 21
IP Spoofing
8, 9,13, 15, experience
Ensur
et
hatt
heChec
kpoi
ntFi
r
ewal
l
’
sdef
enseandant
i
-spoofing
capabilities are appropriately configured to defend against
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
30
Author retains full rights.
network-based attacks such as IP spoofing, Denial of Service,
and TCP/IP implementation related attacks.
Vulnerability
IP Spoofing can facilitate successful network based attacks.
Risk
ts.
Threat Source
Unauthorized users using deliberate network attack methods.
fu
ll r
igh
Likelihood
Likelihood greatly depends of on whether anti-spoofing and attack
defense capabilities are properly configured in the firewall.
eta
i
ns
Potential Outcome
Potential harm includes service interruption and system
application damage.
This control objective is considered compliant if the Checkpoint IP
spoofing and SmartDefense capabilities are appropriately
configured and engaged.
Testing
The following test procedures will test for compliance:
1. Review firewall properties for appropriate IP address
spoofing and logging configuration settings.
2. Review SmartDefense settings to ensure the
appropriate checks are enabled and network-based
attack activity is logged.
Key fingerprint = AF19 FA27 2F94
998D
FDB5
DE3D F8B5
06E4 A169internal
4E46 resources.
3. Use
nmap
to attempt
to enumerate
4. Use Nessus buffer overflow tools to verify
SmartDefense setup.
Analysis
Objective
Continuity
©
SA
NS
CON-1
Description
Reference
Control Objective
In
2.5
sti
tu
te
20
04
,A
ut
ho
rr
Compliance
Risk
Check 17 of 21
System and Configuration Backups
Experience
Ensure that the Nokia IPSO operating system image, Checkpoint
application, and firewall rulebase is regularly backed up and
stored off device.
Vulnerability
The Nokia Checkpoint Firewall, like all computer/network devices
have mechanical parts that can wear out over time. Hardware and
application failures can render a system inoperable and
unrecoverable in a timely fashion if their software and
configurations are not properly backed-up.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
31
Author retains full rights.
Threat Source
The primary threat sources are operational factors including
system component failures (e.g. hard drive, power supply),
network component failures (e.g. network interface cards, VPN
accelerators), and software crashes.
fu
ll r
igh
ts.
Likelihood
Likelihood for this vulnerability to be exposed is considered
medium since hardware and software failures do not frequently
occur.
ho
rr
eta
i
ns
Potential Outcome
Dependi
ngont
heowner
’
ss
er
vi
cecont
r
actNok
i
ahar
dwar
ecan
be replaced between 1 and 5 business days. However, without a
proper back up of the IPSO image and firewall application
configuration, actual downtime could last an additional 24 to 48
hours as the system configuration is brought back to an
operational production state This can cost considerable financial
resources and lost productivity.
This control objective is considered compliant if the system
administrator can provide backups of the Nokia IPSO operating
system image, Checkpoint application, and firewall rulebase.
Backup and restore procedures should be documented and
provided.
Key
fingerprint = AF19The
FA27
2F94 998D
DE3D F8B5
06E4
4E46
Testing
following
testFDB5
procedures
will test
for A169
compliance:
1. Review backup and recovery policies and procedures.
2. Review the backed-up files and data.
3. If operationally feasible perform a full backup and recovery
on the Nokia Checkpoint Firewall using the provided backup and recovery procedures.
4. Fully test functionality of the Nokia Firewall application
 Review the firewall rulebase and policy configuration
 Initiate traffic from all segments
 Connect remotely using SecuRemote client.
 Review firewall logs.
©
Analysis
SA
NS
In
sti
tu
te
20
04
,A
ut
Compliance
CON-2
Description
Reference
Control Objective
Risk
Objective
Check 18 of 21
Firewall Redundancy
Experience
Ensure that the Nokia CheckPoint Firewall is not a single point of
failure.
Vulnerability
The Nokia Checkpoint Firewall, like all computer/network devices
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
32
Author retains full rights.
have mechanical parts that can wear out over time. Hardware and
application failures can render a system unusable and
unrecoverable in a timely fashion. As a single point of failure, this
could cause significant network availability issues.
fu
ll r
igh
ts.
Threat Source
The primary threat sources are operational factors including
system component failures (e.g. hard drive, power supply),
network component failures (e.g. network interface cards, VPN
accelerators), software crashes, and environmental factors that
may accelerate or cause hardware failures.
eta
i
ns
Likelihood
Likelihood for exposing this vulnerability is considered medium
since hardware and software failures do not frequently occur.
04
,A
ut
ho
rr
Potential Outcome
Dependi
ngont
heowner
’
ss
er
vi
cecont
r
actNok
i
ahar
dwar
ecan
be replaced between 1 and 5 business days. With out hardware
redundancy in the form of a dual firewall implementation, actual
downtime could last as much as 7 business days. Five days for
replacement system to arrive on site. An additional 24-48 hours
as the system configuration is brought back to an operational
production state, costing considerable financial resources and lost
productivity.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
This control objective is compliant if there is a fully functional
secondary firewall operating in standby mode.
The following test procedures will test for compliance:
1. Review Nokia Firewall redundancy configuration.
2. Test failover capabilities by disrupting network connectivity
and power to each system.
3. Monitor application and network connectivity to internal
network, wildcard network, DMZ, and the Internet systems.
Objective
te
20
Compliance
NS
In
sti
tu
Testing
Audit Trail, Monitoring, Analysis and Reporting
©
2.6
SA
Analysis
ATR-1
Description
Reference
Control Objective
Check 19 of 21
User access logging
9, 13, 16, experience
Ensure that user access (Nokia operating system, firewall
application, and SecuRemote) attempts are logged and
maintained with appropriate level of detail to ensure
accountability.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
33
Author retains full rights.
Risk
Vulnerability
There is little to no user accountability or audit trial with out
appropriate user access logging.
fu
ll r
igh
ts.
Threat Source
There are numerous threat sources for this vulnerability including
authorized users deliberately or accidentally modifying system
configurations and unauthorized users attempting to access
system resources.
ns
Likelihood
Most security related devices and applications log user access,
however, these features are highly configurable leaving room for
administrator error.
ho
rr
eta
i
Potential Outcome
Several adverse outcomes exist including the inability to enforce
accountability policies and the inability to trace system changes
back to the responsible individuals.
This control objective is compliant if the checkpoint firewall access
logs indicate user access. The Nokia IPSO operating system
must also log all user access attempts.
Testing
For the Checkpoint Firewall Application use the SmartTracker
interface tool to
Key fingerprint = AF19 FA27
998D
FDB5 DE3D
F8B5
06E4user
A169access.
4E46
1. 2F94
Review
firewall-1
logs for
remote
2. Review audit trail logs for system administrator activity.
te
20
04
,A
ut
Compliance
©
SA
NS
In
sti
tu
For the Nokia IPSO operating system either from the Nokia IPSO
operating system command line or the Nokia Network Voyager
web interface tool:
Review all system logs including:
 System Message Log
 Web Server Access Log
 Web Server Error Log
 User Login/Logout Activity
 Management Activity Log
Analysis
When reviewing user access log data ensure that the following
auditable information for each access attempt is recorded
 Date and time
 User ID
 Source and destination address
 Success/failure of event
Objective
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
34
Author retains full rights.
Check 20 of 21
Nokia/Checkpoint network logging
9, 13, 16, experience
Ensure that network traffic filtered at the firewall is logged and
maintained with the appropriate level of detail to assure firewall
rulebase performs as expected; alerts are appropriately triggered;
and that auditable information for each event is recorded.
Vulnerability
There is little to no accountability or audit trial evidence without an
appropriate level of network traffic filtering and firewall logging.
fu
ll r
igh
ts.
ATR-2
Description
Reference
Control Objective
Risk
ho
rr
eta
i
ns
Threat Source
There are numerous threat sources for this vulnerability including
authorized users deliberately or accidentally modifying system
configurations and unauthorized users attempting to access
system resources. A threat also exists from compromised DMZ
systems initiating unauthorized communications to the Internet
andt
heor
gani
zat
i
on’
si
nt
er
nalandwi
l
dcar
dnet
wor
ks.
te
20
04
,A
ut
Likelihood
Most network security devices and applications have the
capability to log network traffic traversing its network interfaces,
however, these features are highly configurable leaving room for
Key fingerprint = AF19error.
FA27 The
2F94likelihood
998D FDB5
DE3D F8B5
06E4
A169 4E46
depends
on the
experience
and training of
t
heor
gani
z
at
i
on’
ss
ec
ur
i
t
yadmi
ni
st
r
at
or
sandengi
neer
s
.
©
SA
Testing
NS
Compliance
In
sti
tu
Potential Outcome
Several adverse outcomes exist including the inability to track
unusual network activity and provide information to support
computer forensic analysis requirements.
Analysis
This control objective is compliant if the logs contain the
appropriate level of detail for audit trail purposes.
The following test procedures will test for compliance:
1. Create network traffic to the Nokia IPSO operating system.
2. Create network traffic to protected systems on the DMZ,
wildcard, and internal networks.
3. Create SecuRemote traffic to the checkpoint firewall and
internal systems.
4. Review CheckPoint Firewall logs.
5. Review Nokia system and application logs.
6. correlate the firewall logs to the test network traffic.
Objective
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
35
Author retains full rights.
Check 21 of 21
Log alerts
13, experience
Ensure that log event alerting features are enabled and
functioning properly for the Nokia IPSO operating system and the
Checkpoint Firewall application.
Vulnerability
Firewall and security personnel are not aware of serious system
and security events.
ts.
ATR-3
Description
Reference
Control Objective
fu
ll r
igh
Risk
eta
i
ns
Threat Source
All network users inside and outside of the organization
attempting to probe and otherwise discover network and system
vulnerabilities. System failures and performance warnings are
also a threat to system operation if unnoticed.
ut
ho
rr
Likelihood
Networks and systems are constantly scanned. It is very likely
that at some point a unauthorized user will make a concerted
effort to probe the network for exploitable vulnerabilities
te
20
04
,A
Potential Outcome
Repeated attempts at network probing may eventually reveal
exploitable vulnerabilities, which may in turn lead to disruption of
Key fingerprint = AF19service
FA27 2F94
FDB5 DE3D F8B5
06E4 A169
4E46
or to998D
the modification,
destruction,
or disclosure
of
valuable information assets.
This control objective is compliant if Nokia IPSO operating system
and Checkpoint firewall log event alerting features are configured,
enabled, and perform as expected.
The following test procedures will test for compliance:
1. Review Nokia IPSO operating system logging and alerting
configuration.
2. Review firewall logging and alerting configuration.
3. Test alerting capability with network probe attempts from
all interfaces of the firewall.
4. Send a test alert from the Nokia IPSO operating system.
Objective
sti
tu
Compliance
SA
NS
In
Testing
©
Analysis
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
36
Author retains full rights.
3 Assignment 3 –Audit Evidence
The following tools were used during the technical audit activities:
Nessus
2.0.7
Plugins 2.0.8.a
4.0
5.0
SuperScan
Firewalk
Source
www.insecure.org
Port scanning
Access control list
testing
Network analyzer, sniffer
Converts binary data to
Base64 encoding and
vice versa
www.foundstone.com
www.packetfactory.ne
t
www.ethereal.com
http://www.rtner.de/sof
tware/base64.html
www.nessus.org
Audit
,A
ut
3.1
ho
rr
eta
i
ns
Ethereal
0.9.11
Base64.exe N/A
Purpose
Port scanning, OS
detection
Vulnerability scanning
ts.
Version
2.54BETA31
fu
ll r
igh
Tool
Nmap
04
PPG-1
20
Description:
Security
Policies,
Key
fingerprintInformation
= AF19 FA27
2F94 998D
FDB5Procedures,
DE3D F8B5 and
06E4Guidelines.
A169 4E46
NS
In
Test #
sti
tu
te
Results:
Management and system administration staff were interviewed regarding the
following policies, procedures and guidelines and asked to supply supporting
documentation for review.
SA
PPG-1.1
PPG-1.2
©
PPG-1.3
PPG-1.4
PPG-1.5
PPG-1.6
PPG-1.7
Control Objective to
Test
Security Policy
Configuration
Management
Backup and Recovery
Patch Management
Configuration Guides
Change Control
Firewall Policy
How
Reviewed
I
D
x
x
x
x
x
x
x
Compliant
Yes
x
No
x
x
x
x
x
x
x
I-Interview D-Documentation
Assessment:
>>The organization is not compliant with this control objective.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
37
Author retains full rights.
fu
ll r
igh
ts.
The organization does not have formally documented policies, procedures or
guidelines. They are aware of the importance of such items but have not
formalized or thoroughly documented the processes. For example, there is a
gathering of configuration guides obtained from the Nokia and Checkpoint
Knowledge Base web sites. However, the guidelines do not specifically reflect
the implemented configuration on the audited system. Patches and updates are
appl
i
ed “
as needed”
, howev
er
,t
her
ei
s no f
or
malpr
oc
es
sf
or obt
ai
ni
ng
vulnerability alerts, testing fixes, and implementation. Network diagrams do
appear to be up to date, as this is currently a relatively simple network from a
logical and physical perspective.
ns
PEN-1
eta
i
Description: Physical Access to the Nokia Firewall System
20
04
,A
ut
ho
rr
Results:
An inspection of the office space including the space housing the firewall and
other networking devices was conducted. An actual attempt to subvert physical
security was not necessary because the firewall and other networking and
computing systems are located in an open office space location. All systems are
located on an open-air computer rack within an ordinary office room. Access is
relatively unrestricted during normal business hours. A receptionist directs the
visitor to the appropriate office space. After normal business hours office building
cleaning crews have access to office spaces to empty trash and clean floors.
Key
fingerprint
= AF19
FA27used
2F94 during
998D FDB5
DE3D F8B5
06E4
A169 4E46
Appendix
B lists
questions
the Physical
access
discussion.
SA
NS
In
sti
tu
te
Assessment:
>>The organization is not compliant with this control objective.
Physical security of the firewall does not exist beyond that provided by a locked
office door. The space is accessible by all staff and visitors during normal
business hours. The office is locked during off hours; however, cleaning and
building maintenance personnel have keys to all offices enabling access during
those times.
©
PEN-2
Description: Power supply
Results:
The physical area containing the firewall was inspected for UPS device
installation. It was noted that the Nokia Checkpoint Firewall was plugged into a
UPS device that provides the required level of functionality as described below:
 Automatic Voltage Regulation (AVR)
 Building wiring fault indicator
 Replace battery indicator
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
38
Author retains full rights.




Hot swap batteries
Battery management capabilities
Overload Indicator
Status Indicator LEDs
rr
eta
i
ns
fu
ll r
igh
ts.
Additionally the site was surveyed for other environmental control technologies
and equipment. The following was noted:
-Surge protection power strips
-One fire extinguisher
However, the space did not provide,
-Raised flooring
-Localized cooling system other than that provided by the building for a human
work environment.
-Humidity monitor
I
twas al
s
o not
ed t
hr
ough di
scussi
ons wi
t
ht
he or
gani
zat
i
on’
s managert
hat
building supplied cooling and heating is curtailed 6:00PM to 6:00AM Monday
through Thursday and from 6:00pm Friday to 6:00am Monday.
ho
Appendix B lists questions used during the environmental controls discussion.
te
20
04
,A
ut
Assessment:
>> The organization has a UPS device to protect the Nokia Checkpoint Firewall
from voltage spikes and sudden loss of power, and is therefore compliant with
the control objective. However, other environmental controls are not adequately
implemented to protect against environmental factors that could potentially harm
computer
systems
or FA27
mitigate
risksF8B5
such06E4
as A169
fires, 4E46
flooding, and
Key
fingerprint
= AF19
2F94environmental
998D FDB5 DE3D
temperature and humidity fluctuations.
tu
SDC-1
sti
Description: Firewall and Network architecture documentation
SA
NS
In
Results:
The results are based on the testing procedures defined in the SDC-1 checklist
item.
Network diagrams were submitted and reviewed.
©
Results of the discovery scanning activity are below:
[root@localhost root]# nmap -sP x.x.b.1-254
Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Host (x.x.b.1) appears to be up.
Host (x.x.b.99) appears to be up.
Host (x.x.b.102) appears to be up.
Host (x.x.b.104) appears to be up.
Host (x.x.b.105) appears to be up.
Host (x.x.b.106) appears to be up.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
39
Author retains full rights.
Nmap run completed -- 254 IP addresses (6 hosts up) scanned in 5 seconds
fu
ll r
igh
Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Host (x.x.a.1) appears to be up.
Host (x.x.a.32) appears to be up.
Host (x.x.a.33) appears to be up.
Host (x.x.a.34) appears to be up.
Host (x.x.a.35) appears to be up.
Host (x.x.a.99) appears to be up.
Host (x.x.a.101) appears to be up.
ts.
[root@localhost root]# nmap -sP x.x.a.1-254
Nmap run completed -- 254 IP addresses (7 hosts up) scanned in 6 seconds
ns
[root@localhost root]# nmap -sP x.x.c.1-254
ut
ho
rr
eta
i
Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Host (x.x.c.1) appears to be up.
Host (x.x.c.2) appears to be up.
Host (x.x.c.3) appears to be up.
Host (x.x.c.5) appears to be up.
Host (x.x.c.6) appears to be up.
Host (x.x.c.9) appears to be up.
Host (x.x.c.21) appears to be up.
Host (x.x.c.111) appears to be up.
,A
Nmap run completed -- 254 IP addresses (8 hosts up) scanned in 15 seconds
20
04
Thesuppl
i
ednet
wor
kdi
agr
am suppor
t
st
hedi
scover
yscanont
heor
gani
zat
i
on’
s
IP network.
Key
fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
tu
te
Assessment:
>>The organization is compliant with the control objective.
sti
SDC-3
In
Description: Nokia IPSO operating system security
SA
NS
Results:
The results are based on the testing procedures defined in the SDC-3 checklist
item.
©
Vulnerability Advisory Search
Vulnerability
Name
CERT®
Advisory CA2004-01
Short Description
Multiple H.323 Message Vulnerabilities
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
Source
Applicable
to Audit
System
http://www.cert.org/
advisories/CA2004-01.html
NO
40
Author retains full rights.
®
Multiple vulnerabilities in implementations of the
Session Initiation Protocol (SIP)
http://www.cert.org/
nav/index_red.html
NO
Multiple Vulnerabilities in Many Implementations
of the Simple Network Management Protocol
(SNMP)
Nokia IPSO Voyager HTTPDAccessLog.TCL
Remote Script injection Vulnerability
http://www.cert.org/
nav/index_red.html
NO
http://www.securityf
ocus.com/bid/9020/
info/
Yes
Bugtraq ID
8928
Nokia IPSO Unspecified Denial of Service
Vulnerability
http://www.securityf
ocus.com/bid/8928/
info/
NO
Bugtraq ID
4089
Multiple Vendor SNMP Request Handling
Vulnerabilities
http://www.securityf
ocus.com/bid/4089
NO
Bugtraq ID
Nokia IPSO Voyager ReadFile.TCL Remote File
Reading Vulnerability
http://www.securityf
ocus.com/bid/7426
NO
fu
ll r
igh
ns
eta
i
ho
Nmap port scanning results are below:
rr
7426
ts.
CERT
Advisory CA2003-06
CERT®
Advisory CA2002-03
Bugtraq ID
9020
ut
root@localhost root]# nmap -v -sU -sT -O -p 1-65535 x.x.c.21
©
SA
NS
In
sti
tu
te
20
04
,A
Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Host (x.x.c.21) appears to be up ... good.
Initiating Connect() Scan against (x.x.c.21)
Adding open port 18208/tcp
Adding
open port
18196/tcp
Key
fingerprint
= AF19
FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Adding open port 18191/tcp
Adding open port 80/tcp
Adding open port 23/tcp
The Connect() Scan took 41 seconds to scan 65535 ports.
Initiating UDP Scan against (x.x.c.21)
The UDP Scan took 326 seconds to scan 65535 ports.
Adding open port 514/udp
Adding open port 1024/udp
Adding open port 161/udp
For OSScan assuming that port 23 is open and port 1 is closed and neither are
firewalled
Interesting ports on (x.x.c.21):
(The 131062 ports scanned but not shown below are in state: closed)
Port
State
Service
23/tcp
open
telnet
80/tcp
open
http
161/udp
open
snmp
514/udp
open
syslog
1024/udp
open
unknown
18191/tcp open
unknown
18196/tcp open
unknown
18208/tcp open
unknown
Remote operating system guess: NOKIA IPSO 3.2 Running Checkpoint Firewall-1
Uptime 0.127 days (since Sat Nov 8 05:02:58 2003)
TCP Sequence Prediction: Class=random positive increments
Difficulty=36098 (Worthy challenge)
IPID Sequence Generation: Incremental
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
41
Author retains full rights.
Nmap run completed -- 1 IP address (1 host up) scanned in 368 seconds
[root@localhost root]#
Nessus vulnerability scanning results are below:
ts.
Nessus Scan Report
------------------
-
Number
Number
Number
Number
of
of
of
of
fu
ll r
igh
SUMMARY
hosts which were alive during the test: 1
security holes found: 5
security warnings found: 9
security notes found: 7
ns
TESTED HOSTS
eta
i
x.x.c.21 (Security holes found)
DETAILS
F8B5 06E4 A169 4E46
te
20
04
,A
ut
ho
rr
+ x.x.c.21:
. List of open ports:
o telnet (23/tcp) (Security warnings found)
o http (80/tcp) (Security hole found)
o snmp (161/udp)
o syslog (514/udp)
o unknown (1024/udp)
o unknown (18191/tcp)
o unknown (18196/tcp)
o unknown (18208/tcp)
o general/tcp
(Security
warnings
Key fingerprint
= AF19
FA27 2F94
998Dfound)
FDB5 DE3D
o general/udp (Security notes found)
o general/icmp (Security warnings found)
tu
. Warning found on port telnet (23/tcp)
In
sti
The Telnet service is running.
This service is dangerous in the sense that it is not ciphered - that is,
everyone can sniff the data that passes between the telnet client and the
telnet server. This includes logins and passwords.
NS
You should disable this service and use OpenSSH instead. (www.openssh.com)
SA
Solution: Comment out the 'telnet' line in /etc/inetd.conf.
©
Risk factor : Low
CVE: CAN-1999-0619
. Information found on port telnet (23/tcp)
A telnet server seems to be running on this port
. Information found on port telnet (23/tcp)
Remote telnet banner:
. Vulnerability found on port http (80/tcp) :
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
42
Author retains full rights.
The remote host is using a version of mod_ssl which is older than 2.8.10.
This version is vulnerable to an off by one buffer overflow which may allow
a user with write access to .htaccess files to execute arbitrary code on
the system with permissions of the web server.
Solution: Upgrade to version 2.8.10 or newer
Risk factor: High
CVE: CVE-2002-0653
BID: 5084
. Vulnerability found on port http (80/tcp):
ts.
Note that several Linux distributions (such as RedHat)
patched the old version of this module. Therefore, this
might be a false positive. Please check with your vendor
to determine if you really are vulnerable to this flaw
fu
ll r
igh
***
***
***
***
ns
The remote host appears to be running a version of Apache which is older
than 1.3.28
eta
i
There are several flaws in this version, which may allow an attacker to
disable the remote server remotely. You should upgrade to 1.3.28 or newer.
ho
rr
*** Note that Nessus solely relied on the version number
*** of the remote server to issue this warning. This might
*** be a false positive
04
,A
ut
Solution: Upgrade to version 1.3.28
See also: http://www.apache.org/dist/httpd/Announcement.html
Risk factor: High
CVE: CAN-2003-0460
BID: 8226
20
. Vulnerability
foundFA27
on port
(80/tcp):
Key
fingerprint = AF19
2F94http
998D
FDB5 DE3D F8B5 06E4 A169 4E46
te
The remote host is using a version of mod_ssl which is older than 2.8.7.
In
sti
Some vendors patched older versions of mod_ssl, so this
might be a false positive. Check with your vendor to determine
if you have a version of mod_ssl that is patched for this
vulnerability
NS
***
***
***
***
tu
This version is vulnerable to a buffer overflow which, albeit difficult to
exploit, may allow an attacker to obtain a shell on this host.
©
SA
Solution: Upgrade to version 2.8.7 or newer
Risk factor: High
CVE: CVE-2002-0082
BID: 4189
. Vulnerability found on port http (80/tcp):
The remote web server seems to be vulnerable to the Cross Site Scripting
vulnerability. The vulnerability is caused by the result returned to the
user when a non-existing file is requested (e.g. the result contains the
JavaScript provided in the request).
The vulnerability would allow an attacker to make the server present the
user with the attacker's JavaScript/HTML code. Since the content is
presented by the server, the user will give it the trust level of the
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
43
Author retains full rights.
server (for example, the trust level of banks, shopping centers, etc. would
usually be high).
Risk factor: Medium
Solution: Upgrade to the latest version of WebSphere
. Vulnerability found on port http (80/tcp):
fu
ll r
igh
The remote host has the CGI 'hpnst.exe' installed.
ts.
BID: 2401
Older versions of this CGI (pre 5.55) are vulnerable to a denial of service
attack where the user can make the CGI request itself.
ns
Solution: upgrade to version 5.55
Risk factor: High
CVE: CAN-2003-0169
eta
i
. Warning found on port http (80/tcp)
The remote Checkpoint Firewall is open to Web administration.
ho
rr
An attacker use it to launch a brute force password attack against the
firewall, and eventually take control of it.
ut
Solution: Disable remote Web administration or filter packets going to this
port
,A
Risk factor : Medium
04
. Warning found on port http (80/tcp)
The remote=host
using
a version
of OpenSSL
which 06E4
is older
Key fingerprint
AF19isFA27
2F94
998D FDB5
DE3D F8B5
A169than
4E460.9.6j
or
20
0.9.7b
tu
te
This version is vulnerable to a timing based attack which may allow an
attacker to guess the content of fixed data blocks and may eventually be
able to guess the value of the private RSA key of the server.
In
sti
An attacker may use this implementation flaw to sniff the data going to
this host and decrypt some parts of it, as well as impersonate your server
and perform man in the middle attacks.
NS
*** Nessus solely relied on the banner of the remote host
*** to issue this warning
©
SA
See also: http://www.openssl.org/news/secadv_20030219.txt
http://lasecwww.epfl.ch/memo_ssl.shtml
http://eprint.iacr.org/2003/052/
Solution: Upgrade to version 0.9.6j (0.9.7b) or newer
Risk factor: Medium
CVE: CAN-2003-0078, CAN-2003-0131
BID: 6884, 7148
. Warning found on port http (80/tcp)
Your webserver supports the TRACE and/or TRACK methods. It has been shown
that servers supporting this method are subject to cross-site-scripting
attacks, dubbed XST for 'Cross-Site-Tracing', when used in conjunction with
various weaknesses in browsers.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
44
Author retains full rights.
An attacker may use this flaw to trick your legitimate web users to give
him their credentials.
Solution: Disable these methods.
fu
ll r
igh
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
ts.
If you are using Apache, add the following lines for each virtual host in
your configuration file:
If you are using Microsoft IIS, use the URLScan tool to deny HTTP TRACE
requests or to permit only the methods needed to meet site requirements and
policy.
ns
See http://www.whitehatsec.com/press_releases/WH-PR-20030120.pdf
http://archives.neohapsis.com/archives/vulnwatch/2003-q1/0035.html
eta
i
Risk factor: Medium
rr
. Warning found on port http (80/tcp)
ho
The remote host appears to be running a version of Apache which is older
than 1.3.27
,A
ut
There are several flaws in this version, you should upgrade to 1.3.27 or
newer.
04
*** Note that Nessus solely relied on the version number
*** of the remote server to issue this warning. This might
*** be a false positive
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
tu
te
20
Solution: Upgrade to version 1.3.27
See also: http://www.apache.org/dist/httpd/Announcement.html
Risk factor: Medium
CVE: CAN-2002-0839, CAN-2002-0840, CAN-2002-0843
BID: 5847, 5884, 5995, 5996
sti
. Warning found on port http (80/tcp)
In
The remote host is using a version of mod_ssl which is older than 2.8.10.
Note that several Linux distributions (such as RedHat)
patched the old version of this module. Therefore, this
might be a false positive. Please check with your vendor
to determine if you really are vulnerable to this flaw
©
***
***
***
***
SA
NS
This version is vulnerable to a flaw which may allow an attacker to
successfully perform a cross site scripting attack under some
circumstances.
Solution: Upgrade to version 2.8.10 or newer
Risk factor: Low
CVE: CAN-2002-1157
BID: 6029
. Information found on port http (80/tcp)
A web server is running on this port
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
45
Author retains full rights.
. Information found on port http (80/tcp)
The remote web server type is:
Apache/1.3.6 (Unix) mod_auth_pam/1.0a mod_ssl/2.3.11 OpenSSL/0.9.5a
Solution: You can set the directive 'ServerTokens Prod' to limit the
information emanating from the server in its response headers.
ts.
. Warning found on port general/tcp
fu
ll r
igh
The remote host does not discard TCP SYN packets which have the FIN flag
set.
Depending on the kind of firewall you are using, an attacker may use this
flaw to bypass its rules.
rr
. Information found on port general/tcp
eta
i
Solution: Contact your vendor for a patch
Risk factor: Medium
BID: 7487
ns
See also: http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html
http://www.kb.cert.org/vuls/id/464113
ut
ho
Nmap found that this host is running NOKIA IPSO 3.2 Running Checkpoint
Firewall-1
,A
. Information found on port general/tcp
Remote OS guess: Nokia IPSO 3.2-3.5 Running Checkpoint Firewall-1 or NG FP2
04
CVE: CAN-1999-0454
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
20
. Information found on port general/udp
tu
te
For your information, here is the traceroute to x.x.c.21:
x.x.c.21
sti
. Warning found on port general/icmp
In
The remote host answers to an ICMP timestamp request. This allows an
attacker to know the date which is set on your machine.
NS
This may help him to defeat all your time based authentication protocols.
SA
Solution: filter out the ICMP timestamp requests (13), and the outgoing
ICMP timestamp replies (14).
©
Risk factor: Low
CVE: CAN-1999-0524
. Warning found on port general/icmp
The remote host answered to an ICMP_MASKREQ query and sent us its netmask
(255.255.255.0)
An attacker can use this information to understand how your network is set
up and how the routing is done. This may help him to bypass your filters.
Solution: reconfigure the remote host so that it does not answer to those
requests. Set up filters that deny ICMP packets of type 17.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
46
Author retains full rights.
Risk factor: Low
CVE: CAN-1999-0524
-----------------------------------------------------This file was generated by the Nessus Security Scanner
Service
telnet
http
Purpose/Function
Remote administration
Remote administration, Nokia Network Voyager
interface
snmp
Simple network management protocol. Not used in
the current environment.
syslog
System logging server. Not used in the current
environment.
Reserved
Unknown purpose or function
CPD
Check Point Daemon Protocol
- Download of rulebase from MM to FWM
- Fetching rulebase from FWM to MM when starting
Undefined
Undefined Checkpoint service port
FW1_CPRID Check Point Remote Installation Protocol
- Protocol used from MM to FWM when installing
Secure Updates.
161/udp
eta
i
ns
514/udp
fu
ll r
igh
Port
23/tcp
80/tcp
ts.
Port to service mapping:
ho
rr
1024/udp
18191/tcp
,A
ut
18196/tcp
18208/tcp
te
20
04
Note: Port number service and purpose/function were based on information obtained from the
following sites:
Keyfingerprint
= AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
http://www.iana.org/assignments/port-numbers
 http://www.fw-1.de/aerasec/ng/ports-ng.html
tu
Assessment:
In
sti
>>The organization is not compliant with this control objective.
©
SA
NS
Vulnerability advisory web search revealed that the installed version of Nokia
IPSO operating system is vulnerable to a web based attack via the Nokia
network voyager web interface tool. The full text of the vulnerability description is
below:
Nokia IPSO is a security operating system for Nokia and
partner security applications. Nokia IPSO could allow a
remote attacker to view files on the system. A remote
attacker with access to the Web-based Voyager
management interface could send a specially-crafted URL
request to the readfile.tcl script to view files on the system
for which the attacker has read permissions.
Nmap scanning revealed that telnet, http, snmp, syslog and several Checkpoint
Firewall NG ports are open.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
47
Author retains full rights.
Nessus security scanning revealed that several open application ports were
vulnerable to specific attack methods including cross-site-scripting, timing based
attacks, brute force password attacks, and password capture.
fu
ll r
igh
ts.
The Nokia IPSO operating system is vulnerable to several types of networkbased attacks when the firewall software is disabled. This could be the case
during system maintenance and troubleshooting activities. IP forwarding is
disabled when the firewall application is disabled, however, IP forwarding can be
re-enabled at the Nokia operating system command line, exposing internal
systems to attack.
ns
SDC-4
eta
i
Description: Firewall application security
ho
rr
Results:
The results are based on the testing procedures defined in the SDC-4 checklist
item.
,A
ut
The $FWDIR/conf/gui-client file contained the appropriate client IP address
information.
04
The $FWDIR/conf/fwmusers file indicates one firewall administrator account.
Key
= AF19 FA27represent
2F94 998Dthe
FDB5
DE3D F8B5
06E4 A169
4E46 and
The fingerprint
following screenshots
implemented
firewall
properties
te
20
rules protecting the Nokia Checkpoint Firewall.
©
SA
NS
In
sti
tu
Below is the Global Properties configuration interface.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
48
Author retains full rights.
ts.
fu
ll r
igh
ns
eta
i
rr
ho
ut
,A
04
Below is the firewall rule permitting access to the firewall module for remote
management purposes.
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
®
Short Description
Source
Applicable
to Audit
System
SA
Vulnerability
Name
NS
Vulnerability Database search results:
Check Point RDP Bypass Vulnerability
http://www.cert.org/
advisories/CA2001-17.html
NO
Check Point Firewall-1 SecuRemote Internal
Interface Address Information Leakage
Vulnerability
http://www.securi
tyfocus.com/bid/8
524
NO
Bugtraq ID
7161
Check Point FW-1 Syslog Daemon Unfiltered
Escape Sequence Vulnerability
http://www.securityf
ocus.com/bid/7161
YES
©
CERT
Advisory CA2001-17
Bugtraq ID
8524
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
49
Author retains full rights.
ts.
Bugtraq ID
Check Point VPN-1/Firewall-1 Remote Syslog
http://www.securityf YES
7159
Data Resource Consumption Vulnerability
ocus.com/bid/7159
Bugtraq ID
Multiple Vendor HTTP CONNECT TCP Tunnel
http://www.securityf NO
4131
Vulnerability
ocus.com/bid/4131
Bugtraq ID
Check Point VPN-1 IKE Aggressive Mode Forcing http://www.securityf NO
5920
Vulnerability
ocus.com/bid/5920
Additional Checkpoint Firewall vulnerabilities dating back to 6/1/99 were noted and found not applicable to
the Checkpoint Firewall operating in this environment.
Port
80
Protocol Service
TCP
HTTP
Telnet
23
TCP
Purpose/Use
Used to remotely access the
Nokia Network Voyager webbased IPSO operating
system configuration tool.
Used to remotely manage
and configure the IPSO
operating system
Used for communication
between Management
Clients (SmartDashboard
GUI) and the CheckPoint
Management Module.
eta
i
ns
Application
Internet Explorer
fu
ll r
igh
In normal interactions with the Nokia Checkpoint Firewall from a trusted
management client host, the following ports, protocols, and services are utilized
(as indicated by ethereal network sniffer captures).
ut
CPMI
04
,A
CheckPoint
18190 TCP
Management Clients
(SmartDashboard)
ho
rr
Telnet
Note:fingerprint
Port number= service
and purpose/function
wereDE3D
based on
information
obtained
from the
Key
AF19 FA27
2F94 998D FDB5
F8B5
06E4 A169
4E46
tu
te
20
following sites:
 http://www.iana.org/assignments/port-numbers
 http://www.fw-1.de/aerasec/ng/ports-ng.html
sti
Nmap scan results from an untrusted host are below:
In
[root@localhost root]# nmap -v -P0 -sU -sS -O -p 1-65535 x.x.c.21
©
SA
NS
Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Host (x.x.c.21) appears to be up ... good.
Initiating SYN Stealth Scan against (x.x.c.21)
Adding open port 264/tcp
Adding open port 18264/tcp
The SYN Stealth Scan took 8835 seconds to scan 65535 ports.
Initiating UDP Scan against (x.x.c.21)
The UDP Scan took 4063 seconds to scan 65535 ports.
Adding open port 1252/udp
Adding open port 52276/udp
Adding open port 57011/udp
Adding open port 33588/udp
Adding open port 41014/udp
*
*
*
Adding open port 56807/udp
Adding open port 44040/udp
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
50
Author retains full rights.
eta
i
ns
fu
ll r
igh
ts.
Adding open port 44943/udp
Adding open port 50966/udp
Adding open port 55120/udp
Adding open port 13013/udp
Adding open port 16789/udp
Adding open port 63775/udp
Adding open port 41400/udp
Adding open port 28535/udp
Adding open port 36355/udp
(no udp responses received -- assuming all ports filtered)
For OSScan assuming that port 264 is open and port 500 is closed and neither
are firewalled
For OSScan assuming that port 264 is open and port 500 is closed and neither
are firewalled
For OSScan assuming that port 264 is open and port 500 is closed and neither
are firewalled
Interesting ports on (x.x.c.21):
(The 131066 ports scanned but not shown below are in state: filtered)
Port
State
Service
264/tcp
open
bgmp
500/tcp
closed
isakmp
18262/tcp closed
unknown
18264/tcp open
unknown
tu
te
20
04
,A
ut
ho
rr
No exact OS matches for host (If you know what OS is running on it, see
http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=2.54BETA31%P=i386-redhat-linux-gnu%D=11/8%Time=3FAD4148%O=264%C=500)
TSeq(Class=RI%gcd=1%SI=9E42%IPID=I%TS=2HZ)
TSeq(Class=RI%gcd=1%SI=D164%IPID=I%TS=2HZ)
TSeq(Class=RI%gcd=1%SI=9EC1%IPID=I%TS=2HZ)
T1(Resp=Y%DF=N%W=4000%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=N)
T3(Resp=N)
T4(Resp=N)
Key
fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=N)
T7(Resp=N)
PU(Resp=N)
NS
In
sti
Uptime 0.385 days (since Sat Nov 8 05:02:55 2003)
TCP Sequence Prediction: Class=random positive increments
Difficulty=40641 (Worthy challenge)
IPID Sequence Generation: Incremental
SA
Nmap run completed -- 1 IP address (1 host up) scanned in 12919 seconds
[root@localhost root]#
©
Firewall Log screenshot during nmap scanning from untrusted host:
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
51
Author retains full rights.
ts.
fu
ll r
igh
ns
eta
i
rr
ho
ut
,A
Nessus vulnerability scanning results from an untrusted host are below.
04
Nessus Scan Report
20
-----------------Key
fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
SUMMARY
hosts which were alive during the test : 1
security holes found: 1
security warnings found: 0
security notes found: 4
te
of
of
of
of
tu
Number
Number
Number
Number
sti
-
In
TESTED HOSTS
NS
x.x.c.21 (Security holes found)
SA
DETAILS
©
+ x.x.c.21 :
. List of open ports:
o unknown (18264/tcp) (Security hole found)
o rap (256/udp)
o isakmp (500/udp)
o unknown (18262/udp)
o unknown (18264/udp)
o general/tcp (Security notes found)
o general/udp (Security notes found)
. Vulnerability found on port unknown (18264/tcp) :
The remote host appears to be vulnerable to the Apache Web Server Chunk
Handling Vulnerability.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
52
Author retains full rights.
If Safe Checks are enabled, this may be a false positive since it is based
on the version of Apache. Although unpatched Apache versions 1.2.2 and
above, 1.3 through 1.3.24 and 2.0 through 2.0.36, the remote server may be
running a patched version of Apache
. Information found on port unknown (18264/tcp)
A web server is running on this port
. Information found on port unknown (18264/tcp)
ns
The remote web server type is:
fu
ll r
igh
ts.
Solution: Upgrade to version 1.3.26 or 2.0.39 or newer See also:
http://httpd.apache.org/info/security_bulletin_20020617.txt
http://httpd.apache.org/info/security_bulletin_20020620.txt
Risk factor: High
CVE: CVE-2002-0392
BID: 5033
eta
i
Check Point SVN foundation/NG FP2
ho
. Information found on port general/tcp
rr
Solution: We recommend that you configure (if possible) your web server to
return a bogus Server header in order to not leak information.
ut
Remote OS guess: Nokia IPSO 3.6 running CheckPoint FW-1 NG FP2
,A
CVE: CAN-1999-0454
04
. Information found on port general/udp
For your information,
theFDB5
traceroute
x.x.c.21
:
Key fingerprint
= AF19 FA27 here
2F94 is
998D
DE3D to
F8B5
06E4 A169
4E46
20
x.x.c.21
tu
te
-----------------------------------------------------This file was generated by the Nessus Security Scanner
©
SA
NS
In
sti
Firewall log screenshot during Nessus vulnerability scanning:
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
53
Author retains full rights.
ts.
fu
ll r
igh
ns
eta
i
rr
ho
ut
,A
04
Port to service mapping for untrusted host:
Port fingerprint
Service
Key
= AF19 FA27 2F94 Purpose/Function
998D FDB5 DE3D F8B5 06E4 A169 4E46
500/tcp
isakmp
Check Point VPN-1 SecuRemote Topology Requests
- Topology Download for SR (build 4100 and higher)
and SCl
ISAKMP, Internet Security Association and Key
Management Protocol, defines procedures and packet
formats to establish, negotiate, modify and delete
Security Associations.
http://www.networksorcery.com/enp/protocol/isakmp.htm
20
FW1_topo
NS
In
sti
tu
te
264/tcp
Check Point Extrnet public key advertisement
- Protocol for exchange of public keys when configuring
Extranet
18264/tcp FW1_ica_services Check Point Internal CA Fetch CRL and User
Registration Services
- Protocol for Certificate Revocation Lists and registering
users when using the Policy Server
- needed when e.g. FWM is starting
©
SA
18262/tcp CP_Exnet_PK
Note: Port number service and purpose/function were based on information obtained from the
following sites:
 http://www.iana.org/assignments/port-numbers
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
54
Author retains full rights.
 http://www.fw-1.de/aerasec/ng/ports-ng.html
fu
ll r
igh
The following nmap scan is from a trusted host to the firewall:
ts.
The following test results were obtained by running the same nmap and nessus
scans from a trusted host. In this environment the trusted host is the internal
firewall management client workstation. For this test a host object was created
for the scanning host.
[root@localhost root]# nmap -v -P0 -sU -sS -O -p 1-65535 x.x.a.1
©
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
eta
i
ns
Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Host (x.x.a.1) appears to be up ... good.
Initiating SYN Stealth Scan against (x.x.a.1)
Adding open port 80/tcp
Adding open port 262/tcp
Adding open port 18208/tcp
Adding open port 18191/tcp
Adding open port 18209/tcp
Adding open port 18264/tcp
Adding open port 264/tcp
Adding open port 18184/tcp
Adding open port 256/tcp
Adding open port 23/tcp
Adding open port 18183/tcp
Adding open port 1032/tcp
Adding open port 259/tcp
Adding open port 1034/tcp
Adding open port 18187/tcp
Adding open port 1033/tcp
Adding open port 257/tcp
Adding
open port
1035/tcp
Key
fingerprint
= AF19
FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Adding open port 18190/tcp
Adding open port 18192/tcp
Adding open port 18210/tcp
Adding open port 1031/tcp
Adding open port 18221/tcp
Adding open port 18196/tcp
Adding open port 1036/tcp
Adding open port 900/tcp
The SYN Stealth Scan took 104 seconds to scan 65535 ports.
Initiating UDP Scan against (x.x.a.1)
The UDP Scan took 325 seconds to scan 65535 ports.
Adding open port 161/udp
Adding open port 53/udp
Adding open port 514/udp
Adding open port 18234/udp
Adding open port 18233/udp
Adding open port 1701/udp
Adding open port 1024/udp
Adding open port 2746/udp
Adding open port 259/udp
Adding open port 500/udp
Adding open port 68/udp
For OSScan assuming that port 23 is open and port 1 is closed and neither are
firewalled
For OSScan assuming that port 23 is open and port 1 is closed and neither are
firewalled
For OSScan assuming that port 23 is open and port 1 is closed and neither are
firewalled
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
55
Author retains full rights.
sti
tu
te
20
04
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
Interesting ports on (x.x.a.1):
(The 131032 ports scanned but not shown below are in state: closed)
Port
State
Service
23/tcp
open
telnet
53/udp
open
domain
68/udp
open
dhcpclient
80/tcp
open
http
161/udp
open
snmp
256/tcp
open
rap
257/tcp
open
set
259/tcp
open
esro-gen
259/udp
open
firewall1-rdp
262/tcp
open
arcisdms
264/tcp
open
bgmp
500/udp
open
isakmp
514/udp
open
syslog
900/tcp
open
unknown
1024/udp
open
unknown
1031/tcp
open
iad2
1032/tcp
open
iad3
1033/tcp
open
netinfo
1034/tcp
open
unknown
1035/tcp
open
unknown
1036/tcp
open
unknown
1701/udp
open
unknown
1720/tcp
filtered
unknown
2746/udp
open
unknown
18183/tcp open
unknown
18184/tcp open
unknown
18187/tcp open
unknown
18190/tcp open
unknown
18191/tcp open
unknown
18192/tcp open
unknown
18196/tcp open
unknown
18208/tcp
open= AF19 FA27
unknown
Key
fingerprint
2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
18209/tcp open
unknown
18210/tcp open
unknown
18221/tcp open
unknown
18233/udp open
unknown
18234/udp open
unknown
18264/tcp open
unknown
©
SA
NS
In
No exact OS matches for host (If you know what OS is running on it, see
http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=2.54BETA31%P=i386-redhat-linux-gnu%D=1/4%Time=3FF82ADA%O=23%C=1)
TSeq(Class=RI%gcd=1%SI=AFB8%IPID=I%TS=2HZ)
TSeq(Class=RI%gcd=1%SI=6B2B%IPID=I%TS=2HZ)
TSeq(Class=RI%gcd=1%SI=B1C6%IPID=I%TS=2HZ)
T1(Resp=Y%DF=N%W=4000%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=N)
T3(Resp=N)
T4(Resp=N)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=N)
T7(Resp=N)
PU(Resp=Y%DF=N%TOS=E0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=0%ULEN=134%DAT=E)
Uptime 0.109 days (since Sun Jan 4 07:24:58 2004)
TCP Sequence Prediction: Class=random positive increments
Difficulty=45510 (Worthy challenge)
IPID Sequence Generation: Incremental
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
56
Author retains full rights.
Nmap run completed -- 1 IP address (1 host up) scanned in 446 seconds
[root@localhost root]#
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
Firewall Log screenshot during nmap scanning:
04
Nessus vulnerability scanning results from a trusted host are below.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
te
20
Nessus Scan Report
------------------
of
of
of
of
hosts which were alive during the test: 1
security holes found: 6
security warnings found: 7
security notes found: 10
sti
Number
Number
Number
Number
In
-
tu
SUMMARY
NS
TESTED HOSTS
DETAILS
SA
x.x.a.1 (Security holes found)
©
+ x.x.a.1 :
. List of open ports:
o telnet (23/tcp) (Security notes found)
o http (80/tcp) (Security hole found)
o rap (256/tcp)
o set (257/tcp)
o esro-gen (259/tcp)
o arcisdms (262/tcp) (Security notes found)
o bgmp (264/tcp)
o unknown (900/tcp)
o iad2 (1031/tcp)
o iad3 (1032/tcp)
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
57
Author retains full rights.
ts.
fu
ll r
igh
ns
ut
ho
rr
eta
i
netinfo (1033/tcp)
unknown (1034/tcp)
unknown (1035/tcp)
unknown (1036/tcp)
unknown (18183/tcp)
unknown (18184/tcp)
unknown (18187/tcp)
unknown (18190/tcp)
unknown (18191/tcp)
unknown (18192/tcp)
unknown (18196/tcp)
unknown (18208/tcp)
unknown (18209/tcp) (Security notes found)
unknown (18210/tcp)
unknown (18221/tcp)
unknown (18264/tcp) (Security hole found)
domain (53/udp)
bootpc (68/udp)
snmp (161/udp)
firewall1-rdp (259/udp)
isakmp (500/udp)
syslog (514/udp)
unknown (1024/udp)
l2tp (1701/udp)
unknown (2746/udp)
unknown (18233/udp)
unknown (18234/udp)
general/tcp (Security notes found)
general/udp (Security notes found)
general/icmp (Security warnings found)
,A
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
04
. Information found on port telnet (23/tcp)
20
telnet server
be running
on this
port
Key Afingerprint
= AF19seems
FA27to2F94
998D FDB5
DE3D
F8B5 06E4 A169 4E46
sti
tu
Remote telnet banner:
te
. Information found on port telnet (23/tcp)
In
. Vulnerability found on port http (80/tcp):
NS
The remote host is using a version of mod_ssl which is older than 2.8.10.
©
SA
This version is vulnerable to an off by one buffer overflow which may allow
a user with write access to .htaccess files to execute arbitrary code on the
system with permissions of the web server.
***
***
***
***
Note that several Linux distributions (such as RedHat)
patched the old version of this module. Therefore, this
might be a false positive. Please check with your vendor
to determine if you really are vulnerable to this flaw
Solution: Upgrade to version 2.8.10 or newer
Risk factor: High
CVE: CVE-2002-0653
BID: 5084
. Vulnerability found on port http (80/tcp) :
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
58
Author retains full rights.
The remote host appears to be running a version of Apache which is older
than 1.3.28
There are several flaws in this version, which may allow an attacker to
disable the remote server remotely.
ts.
You should upgrade to 1.3.28 or newer.
fu
ll r
igh
*** Note that Nessus solely relied on the version number
*** of the remote server to issue this warning. This might
*** be a false positive
eta
i
. Vulnerability found on port http (80/tcp) :
ns
Solution : Upgrade to version 1.3.28
See also : http://www.apache.org/dist/httpd/Announcement.html
Risk factor : High
CVE : CAN-2003-0460
BID : 8226
rr
The remote host is using a version of mod_ssl which is older than 2.8.7.
,A
Some vendors patched older versions of mod_ssl, so this
might be a false positive. Check with your vendor to determine
if you have a version of mod_ssl that is patched for this
vulnerability
04
***
***
***
***
ut
ho
This version is vulnerable to a buffer overflow which, albeit difficult to
exploit, may allow an attacker to obtain a shell on this host.
version
or newer
KeySolution:
fingerprintUpgrade
= AF19 to
FA27
2F94 2.8.7
998D FDB5
DE3D F8B5 06E4 A169 4E46
te
20
Risk factor: High
CVE: CVE-2002-0082
BID: 4189
sti
tu
. Vulnerability found on port http (80/tcp):
©
SA
NS
In
The remote web server seems to be vulnerable to the Cross Site Scripting
vulnerability. The vulnerability is caused by the result returned to the
user when a non-existing file is requested (e.g. the result contains the
JavaScript provided in the request).
The vulnerability would allow an attacker to make the server present the
user with the attacker's JavaScript/HTML code. Since the content is
presented by the server, the user will give it the trust level of the server
(for example, the trust level of banks, shopping centers, etc. would usually
be high).
Risk factor: Medium
Solution: Upgrade to the latest version of WebSphere
BID: 2401
. Vulnerability found on port http (80/tcp) :
The remote host has the CGI 'hpnst.exe' installed.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
59
Author retains full rights.
Older versions of this CGI (pre 5.55) are vulnerableto a denial of service
attack where the user can make the CGI request itself.
Solution: upgrade to version 5.55
Risk factor: High
CVE: CAN-2003-0169
. Warning found on port http (80/tcp)
ts.
The remote Checkpoint Firewall is open to Web administration.
fu
ll r
igh
An attacker use it to launch a brute force password attackagainst the
firewall, and eventually take control of it.
Solution : Disable remote Web administration or filter packets going tothis
port
Risk factor : Medium
ns
. Warning found on port http (80/tcp)
eta
i
The remote host is using a version of OpenSSL which is older than 0.9.6j or
0.9.7b
ho
rr
This version is vulnerable to a timing based attack which may allow an
attacker to guess the content of fixed data blocks and may eventually be
able to guess the value of the private RSA key of the server.
,A
ut
An attacker may use this implementation flaw to sniff the data going to this
host and decrypt some parts of it, as well as impersonate your server and
perform man in the middle attacks.
04
*** Nessus solely relied on the banner of the remote host
*** to issue this warning
also: http://www.openssl.org/news/secadv_20030219.txt
KeySee
fingerprint
= AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
te
20
http://lasecwww.epfl.ch/memo_ssl.shtml
http://eprint.iacr.org/2003/052/
sti
tu
Solution: Upgrade to version 0.9.6j (0.9.7b) or newer
Risk factor: Medium
CVE: CAN-2003-0078, CAN-2003-0131
BID: 6884, 7148
In
. Warning found on port http (80/tcp)
SA
NS
Your webserver supports the TRACE and/or TRACK methods. It has been shown
that servers supporting this method are subject to cross-site-scripting
attacks, dubbed XST for 'Cross-Site-Tracing', when used in conjunction with
various weaknesses in browsers.
©
An attacker may use this flaw to trick your legitimate web users to give him
their credentials.
Solution: Disable these methods.
If you are using Apache, add the following lines for each virtual host in
your configuration file :
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
60
Author retains full rights.
If you are using Microsoft IIS, use the URLScan tool to deny HTTP TRACE
requests or to permit only the methods needed to meet site requirements and
policy.
See http://www.whitehatsec.com/press_releases/WH-PR-20030120.pdf
http://archives.neohapsis.com/archives/vulnwatch/2003-q1/0035.html
ts.
Risk factor: Medium
fu
ll r
igh
. Warning found on port http (80/tcp)
The remote host appears to be running a version of Apache which is older
than 1.3.27
There are several flaws in this version, you should upgrade to 1.3.27 or
newer.
eta
i
ns
*** Note that Nessus solely relied on the version number
*** of the remote server to issue this warning. This might
*** be a false positive
ut
. Warning found on port http (80/tcp)
ho
rr
Solution: Upgrade to version 1.3.27
See also: http://www.apache.org/dist/httpd/Announcement.html
Risk factor: Medium
CVE: CAN-2002-0839, CAN-2002-0840, CAN-2002-0843
BID: 5847, 5884, 5995, 5996
,A
The remote host is using a version of mod_ssl which is
older than 2.8.10.
04
This version is vulnerable to a flaw which may allow an attacker to
te
Note that several Linux distributions (such as RedHat)
patched the old version of this module. Therefore, this
might be a false positive. Please check with your vendor
to determine if you really are vulnerable to this flaw
tu
***
***
***
***
20
perform
a cross
attack
Keysuccessfully
fingerprint = AF19
FA27
2F94 site
998Dscripting
FDB5 DE3D
F8B5under
06E4some
A169circumstances.
4E46
In
sti
Solution: Upgrade to version 2.8.10 or newer
Risk factor: Low
CVE: CAN-2002-1157
BID: 6029
NS
. Information found on port http (80/tcp)
SA
A web server is running on this port
©
. Information found on port http (80/tcp)
The remote web server type is :
Apache/1.3.6 (Unix) mod_auth_pam/1.0a mod_ssl/2.3.11 OpenSSL/0.9.5a
Solution : You can set the directive 'ServerTokens Prod' to limit the
information emanating from the server in its response headers.
. Information found on port arcisdms (262/tcp)
The service closed the connection after 2 seconds without sending any data
It might be protected by some TCP wrapper
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
61
Author retains full rights.
. Information found on port unknown (18209/tcp)
The service closed the connection after 0 seconds without sending any data
It might be protected by some TCP wrapper
fu
ll r
igh
The remote host appears to be vulnerable to the Apache
Web Server Chunk Handling Vulnerability.
ts.
. Vulnerability found on port unknown (18264/tcp) :
If Safe Checks are enabled, this may be a false positivesince it is based on
the version of Apache. Although unpatched Apache versions 1.2.2 and above,
1.3 through 1.3.24 and 2.0 through 2.0.36, the remote server may be running
a patched version of Apache
eta
i
ns
Solution: Upgrade to version 1.3.26 or 2.0.39 or newer
See also: http://httpd.apache.org/info/security_bulletin_20020617.txt
http://httpd.apache.org/info/security_bulletin_20020620.txt
rr
Risk factor: High
CVE: CVE-2002-0392
BID: 5033
ho
. Information found on port unknown (18264/tcp)
ut
A web server is running on this port
,A
. Information found on port unknown (18264/tcp)
04
The remote web server type is :
20
Point=SVN
foundation/NG
FP2 FDB5 DE3D F8B5 06E4 A169 4E46
KeyCheck
fingerprint
AF19
FA27 2F94 998D
tu
te
Solution : We recommend that you configure (if possible) your web server to
return a bogus Server header in order to not leak information.
sti
. Information found on port general/tcp
In
Remote OS guess : Nokia IPSO 3.6 running CheckPoint FW-1 NG FP2
CVE : CAN-1999-0454
NS
. Information found on port general/udp
©
SA
For your information, here is the traceroute to x.x.a.1 :
x.x.a.1
. Warning found on port general/icmp
The remote host answers to an ICMP timestamp request. This allows an
attacker to know the date which is set on your machine.
This may help him to defeat all your time based authentication protocols.
Solution: filter out the ICMP timestamp requests (13), and the outgoing
ICMP timestamp replies (14).
Risk factor: Low
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
62
Author retains full rights.
CVE: CAN-1999-0524
. Warning found on port general/icmp
The remote host answered to an ICMP_MASKREQ query and sent us its netmask
(255.255.255.0)
ts.
An attacker can use this information to understand how your network is set
up and how the routing is done. This may help him to bypass your filters.
fu
ll r
igh
Solution: reconfigure the remote host so that it does not answer to those
requests.
Set up filters that deny ICMP packets of type 17.
Risk factor: Low
CVE: CAN-1999-0524
eta
i
ns
-----------------------------------------------------This file was generated by the Nessus Security Scanner
04
,A
ut
ho
rr
Firewall log screenshot during Nessus vulnerability scanning:
SA
NS
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
©
Nokia IPSO console activity during Nessus trusted host scanning:
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
63
Author retains full rights.
ts.
fu
ll r
igh
ns
eta
i
rr
ho
ut
,A
04
NS
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Service
telnet
domain
dhcpclient
http
snmp
FW1
Purpose/Function
Remote administration
Domain Name Service
Bootstrap Protocol Client
World Wide Web HTTP
Simple Network Management Protocol
Check Point VPN-1 & FireWall-1 Service
- Get topology information from MM to FWM
©
Port
23/tcp
53/udp
68/udp
80/tcp
161/udp
256/tcp
SA
Port to service mapping for trusted host:
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
64
Author retains full rights.
©
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
- Full synchronization for HA configuration
257/tcp
FW1_log
Check Point VPN-1 & FireWall-1 Logs
- Protocol used for delivering logs from FWM to MM
259/tcp
FW1_clntauth
Check Point VPN-1 & FireWall-1 Client Authentication
FW1_clntauth_teln (Telnet)
et
- Protocol for performing Client-Authentication at FWM
using telnet
259/udp
firewall1-rdp
Check Point VPN-1 FWZ Key Negotiations - Reliable
Datagram Protocol
- Protocol used for FWZ VPN (supported up to NG FP1
only)
- Protocol used by SR/SCl for checking the availability of
the FWM/PS
262/tcp
arcisdms
arcisdms
264/tcp
FW1_topo
Check Point VPN-1 SecuRemote Topology Requests
- Topology Download for SR (build 4100 and higher) and
SCl
500/udp
isakmp
ISAKMP, Internet Security Association and Key
Management Protocol, defines procedures and packet
formats to establish, negotiate, modify and delete
Security Associations.
http://www.networksorcery.com/enp/protocol/isakmp.htm
514/udp
syslog
Syslog
900/tcp
FW1_clntauth
Check Point VPN-1 & FireWall-1 Client Authentication
FW1_clntauth_http
Key fingerprint = AF19 FA27 2F94(HTTP)
998D FDB5 DE3D F8B5 06E4 A169 4E46
- Protocol for performing Client-Authentication at FWM
using HTTP
1024/udp
Reserved
Unknown Purpose
1031/tcp
iad2
BBN IAD
1032/tcp
iad3
BBN IAD
1033/tcp
netinfo-local
Local netinfo port
1034/tcp
activesync
ActiveSync Notifications
1035/tcp
mxxrlogin
MX-XR RPC
1036/tcp
nsstp
Nebula Secure Segment Transfer Protocol
1701/udp
l2f, l2tp
l2f
1720/tcp
h323hostcall
h323hostcall
2746/udp
VPN1_IPSEC_enc Check Point VPN-1 SecuRemote IPSEC Transport
apsulation
Encapsulation Protocol
- Default-Protocol used for UDP encapsulation
18183/tcp
FW1_sam
Check Point OPSEC Suspicious Activity Monitor API
- Protocol e.g. for Block Intruder between MM and FWM
18184/tcp
FW1_lea
Check Point OPSEC Log Export API
- Protocol for exporting logs from MM
18187/tcp
FW1_ela
Check Point OPSEC Event Logging API
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
65
Author retains full rights.
In
sti
tu
te
20
04
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
- Protocol for applications logging to the Firewall log at
MM
18190/tcp
CPMI
Check Point Management Interface
- Protocol for communication between GUI and MM
18191/tcp
CPD
Check Point Daemon Protocol
- Download of rulebase from MM to FWM
- Fetching rulebase from FWM to MM when starting
18192/tcp
CPD_amon
Check Point Internal Application Monitoring
- Protocol for e.g. getting System Status from MM to
FWM
18196/tcp
Unknown
Unknown
18208/tcp
FW1_CPRID
Check Point Remote Installation Protocol
- Protocol used from MM to FWM when installing Secure
Updates.
18209/tcp
- not defined Protocol used in SIC for communication between FWM
and ICA (status, issue, revoke)
18210/tcp
FW1_ica_pull
Check Point Internal CA Pull Certificate Service
- Protocol used by SIC for e.g. FWM pulling CA's from
MM
18221/tcp
CP_redundant
Check Point Redundant Management Protocol
- Protocol used for synchronizing primary and secondary
MM
18233/udp FW1_scv_keep_ali Check Point SecureClient Verification KeepAlive Protocol
ve
- Protocol for verifying SecureClient
18234/udp
tunnel_test
Point DE3D
tunnelF8B5
testing
application
Key fingerprint
= AF19 FA27 2F94Check
998D FDB5
06E4
A169 4E46
- Protocol for testing applications through a VPN, used by
SR/SCl
18264/tcp
FW1_ica_services Check Point Internal CA Fetch CRL and User
Registration Services
- Protocol for Certificate Revocation Lists and registering
users when using the Policy Server
- needed when e.g. FWM is starting
©
SA
NS
Note: Port number service and purpose/function were based on information obtained from the
following sites:
 http://www.iana.org/assignments/port-numbers
 http://www.fw-1.de/aerasec/ng/ports-ng.html
Assessment:
>>The organization is not compliant with this control objective.
Vulnerability advisory web search revealed that the installed version of
Checkpoint Firewall NG FP3 is currently vulnerable to two application exploits.
Checkpoint Hotfixes are available for this issue. Additionally, it is noted that
misconfigurations of the firewall application could expose the Nokia Checkpoint
Firewall or the network systems and applications it protects to vulnerabilities.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
66
Author retains full rights.
Nmap scanning from a non trusted host revealed that several open Checkpoint
Firewall NG ports and ISAKMP. All of the open ports are required for various
firewall operational activities or SecuRemote connections.
fu
ll r
igh
ts.
Nessus security scanning from a non-trusted host confirmed the nmap findings.
Several false findings are noted. In particular, Nessus identified 18264 as an
apache web server. The tcp port actually represents FW1_ica_services, which is
used for Check Point Internal CA Fetch CRL and User Registration Services.
Risks to the Nokia Checkpoint Firewall are minimal from non-trusted hosts. The
firewall adequately blocks all unauthorized connection attempts.
eta
i
ns
However, under the current configuration, and in particular firewall rule 2,
numerous vulnerabilities to the firewall exist from trusted hosts.
ho
rr
The firewall rule and global policies permitting remote administration are not
adequately configured to protect the system.
,A
ut
SDC-5, ENC-1
Description: Remote management activity security
20
04
Results:
The results are based on the testing procedures defined in the SDC-5, ENC-1
Key
fingerprint
checklist
item. = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
©
SA
NS
In
sti
tu
te
The following Nokia Network Voyager screenshots provide information regarding
the remote management configuration settings for the IPSO operating system.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
67
Author retains full rights.
ts.
fu
ll r
igh
ns
eta
i
rr
ho
ut
,A
04
©
SA
NS
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
68
Author retains full rights.
ts.
fu
ll r
igh
ns
eta
i
rr
ho
04
,A
ut
The following Checkpoint firewall management configuration screenshots provide
information regarding the remote management configuration settings for the
Checkpoint Firewall application.
©
SA
NS
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
69
Author retains full rights.
ts.
fu
ll r
igh
ns
eta
i
rr
ho
ut
,A
04
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
In
sti
The following screenshots represent network transmission captures of remote
management activity to the Nokia checkpoint firewall .
©
SA
NS
The first capture is from the management station to Nokia checkpoint firewall
using the Nokia Network Voyager web interface to configure the IPSO operating
system:
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
70
Author retains full rights.
ts.
fu
ll r
igh
ns
eta
i
rr
ho
ut
,A
04
The following capture is from the management station to Nokia checkpoint
©
SA
NS
In
sti
tu
te
20
Key
fingerprint
= AF19
2F94the
998D
FDB5
DE3D F8B5
06E4 A169 4E46
firewall
using telnet
to FA27
configure
IPSO
operating
system:
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
71
Author retains full rights.
04
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
The following capture is again from the management station to Nokia checkpoint
firewall using the Checkpoint NG SmartDashboard client firewall management
and configuration tool.
20
Key
fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Assessment:
te
>>The organization is not compliant with this control objective.
SA
NS
In
sti
tu
As indicated by the Nokia configuration screenshots and confirmed by the
network traffic captures, IPSO operating system remote management is
accomplished via clear text http and telnet services. The base64 encoded login
account and password is captured during the web-based Nokia Network Voyager
log in. The encoded account and password can be de-coded using the
base64.exe utility. The telnet captures reveal the login account and password as
well.
©
The checkpoint Global Properties settings permit firewall-1/vpn-1 control
connections. Firewall-1/VPN-1 captured connection control transmissions were
encrypted.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
72
Author retains full rights.
SDC-8
Description: DMZ network security
ts.
Results:
The results are based on the testing procedures defined in the SDC-8 checklist
item.
fu
ll r
igh
The following rule allows networks access to DMZ systems from all networks
04
,A
ut
ho
rr
eta
i
ns
Test scenario
Given that unrestricted access is permitted to the DMZ, a test was developed to
simulat
eacompr
omi
sedDMZsy
st
em’
sat
t
emptt
oenumer
at
ei
nt
er
nalnet
wor
k
systems.
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
NS
In
Firewalk and nmap were used to test security. The ethereal network analyzer
was used on the internal network to capture any data originating from the DMZ
network.
SA
Firewalk results:
©
[root@localhost root]# firewalk -n -pUDP -s 53 -d 53 x.x.a.1 x.x.a.101
Firewalk 5.0 [gateway ACL scanner]
Firewalk state initialization completed successfully.
UDP-based scan.
Ramping phase source port: 53, destination port: 53
Hotfoot through x.x.a.1 using x.x.a.101 as a metric.
Ramping Phase:
1 (TTL 1): *no response*
2 (TTL 2): *no response*
3 (TTL 3): *no response*
*
*
*
21 (TTL 21): *no response*
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
73
Author retains full rights.
22 (TTL 22): *no response*
23 (TTL 23): *no response*
24 (TTL 24): *no response*
25 (TTL 25): *no response*
Scan aborted: hopcount exceeded.
ts.
25
0
29
0
0
0
0
fu
ll r
igh
Total packets sent:
Total packet errors:
Total packets caught
Total packets caught of interest
Total ports scanned
Total ports open:
Total ports unknown:
[root@localhost root]#
Nmap results:
ns
root@localhost root]# nmap -v -P0 -sU -sS -O x.x.a.101
©
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
eta
i
Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Host (x.x.a.101) appears to be up ... good.
Initiating SYN Stealth Scan against (x.x.a.101)
The SYN Stealth Scan took 1679 seconds to scan 1554 ports.
Initiating UDP Scan against (x.x.a.101)
The UDP Scan took 1755 seconds to scan 1459 ports.
Adding open port 1670/udp
Adding open port 499/udp
Adding open port 1404/udp
Adding open port 167/udp
Adding open port 491/udp
Adding open port 374/udp
*
*
*
Key
fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Adding open port 396/udp
Adding open port 541/udp
Adding open port 95/udp
Adding open port 413/udp
Adding open port 1652/udp
Adding open port 655/udp
(no udp responses received -- assuming all ports filtered)
Warning: OS detection will be MUCH less reliable because we did not find at
least 1 open and 1 closed TCP port
All 3013 scanned ports on (x.x.a.101) are: filtered
Too many fingerprints match this host for me to give an accurate OS guess
TCP/IP fingerprint:
SInfo(V=2.54BETA31%P=i386-redhat-linux-gnu%D=11/9%Time=3FAE4FE5%O=-1%C=-1)
T5(Resp=N)
T6(Resp=N)
T7(Resp=N)
PU(Resp=N)
Nmap run completed -- 1 IP address (1 host up) scanned in 3655 seconds
[root@localhost root]#
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
74
Author retains full rights.
Ethereal network captures did not pick up any traffic originating from the DMZ
network.
04
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
The checkpoint firewall logs indicate that all firewalk and nmap traffic was
blocked at the DMZ interface (x.x.b.1). The firewall log showed that the firewalk
traffic originating from the DMZ was identified as an attack and was blocked by
the SmartDefense feature of the Checkpoint firewall.
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
tu
te
Assessment:
>>The organization is not compliant with this control objective.
©
SDC-10
SA
NS
In
sti
Although the traffic from the DMZ to the internal network was blocked at the
firewall, the rule permitting access from the Internet is too permissive. As a result,
this configuration will expose DMZ systems to numerous network based
vulnerabilities and attacks.
Description: SecuRemote Access and Configuration
Results
The results are based on the testing procedures defined in the SDC-10 checklist
item.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
75
Author retains full rights.
04
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
The following Checkpoint remote access screenshots provide information
regarding the VPN-1 SecuRemote configuration settings.
©
SA
NS
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
76
Author retains full rights.
ts.
fu
ll r
igh
ns
eta
i
rr
ho
ut
,A
04
©
SA
NS
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
77
Author retains full rights.
ts.
fu
ll r
igh
ns
eta
i
rr
ho
ut
,A
04
©
SA
NS
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
78
Author retains full rights.
The following rule permits remote access users to authenticate at the firewall and
initiate communication to internal systems
04
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
The following screenshot is a portion of the encrypted traffic originating from the
remote client to the firewall.
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
©
SA
NS
In
sti
SuperScan was used on the remote system to enumerate internal systems
operating on the x.x.a.1-254 network segment. The following screenshot shows a
portion of the SuperScan results.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
79
Author retains full rights.
ts.
fu
ll r
igh
ns
eta
i
rr
ho
ut
,A
04
©
SA
NS
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
80
Author retains full rights.
04
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
The following screenshot shows the SecuRemote traffic permitted into the
internal network.
20
Key
fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Assessment:
tu
te
>>The organization is not compliant with this control objective.
©
SA
NS
In
sti
Remote access is not appropriately configured on the firewall. Although, only
authorized users can gain access to internal systems, the configuration of
individual users is too permissive; any destination within the encryption zone is
permitted. In this configuration the encryption zone include all systems operating
on the x.x.a.x internal network segment. Once the user authenticates at the
firewall he or she will have complete network access to all internal systems. The
SuperScan4 results run from the SecuRemote client system confirms the access
available to remote users. The firewall log indicates the remote users access is
permitted to all internal systems.
The ethereal network captures indicate that all data in transit is encrypted.
However, the initial SecuRemote to Checkpoint Firewall communication revealed
the organizations domain name.
CON-1
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
81
Author retains full rights.
Description System and Configuration Backups
The results are based on the testing procedures defined in the CON-1 checklist
item.
04
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
Results
The following screenshot represents the backup and restore configuration for the
Nokia Checkpoint Firewall.
NS
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
©
SA
The following file was shown and represents the Checkpoint firewall backup file.
This file, along with other checkpoint firewall backups created at various dates,
was noted on the Nokia system in the /var/backup directory.
bahama1_nokia_fw_20031227.tgz
Assessment:
>>The organization is partially compliant with this control objective. The
Checkpoint Firewall application is adequately backed-up using the Backup and
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
82
Author retains full rights.
Restore Configuration feature of the Nokia IPSO operating system. The file is
saved on the system in the /var/backup directory and off-system on CD.
The organization does not use the full feature set available for full and automated
backups of the Nokia IPSO operating system and Checkpoint firewall application.
fu
ll r
igh
There were no documented backup and recovery procedures.
ts.
At time of review, we were not permitted to restore the system with the available
backup file.
ns
ATR-3
eta
i
Description: Log alert functionality
rr
Results:
ho
The results are based on the testing procedures defined in the ATR-3 checklist
item.
04
,A
ut
The following screenshots represent the Nokia IPSO operating system logging
and alerting configuration.
©
SA
NS
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
83
Author retains full rights.
ts.
fu
ll r
igh
ns
eta
i
rr
ho
ut
,A
04
©
SA
NS
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
84
Author retains full rights.
ts.
fu
ll r
igh
ns
eta
i
rr
ho
ut
,A
04
The alert features of the Checkpoint Firewall are not enabled as indicated by the
20
Key
= AF19
trackfingerprint
attribute for
eachFA27
rule. 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
te
The Log and Alert properties of the firewall are in the default configuration.
tu
>>The organization is not compliant with this control objective.
SA
NS
In
sti
The alerting features of the Nokia Checkpoint Firewall are not configured.
©
3.2 Residual Risks
A great deal of residual risk to the organization remains. In each of the
information assurance and security areas of concern there exists room for
improvement. The lack of documented policies, procedures and guidelines is the
mostappar
entr
i
s
kt
ot
heor
gani
z
at
i
on.Gi
vent
heor
gani
z
at
i
on’
sbus
i
nes
smodel
and how information technology resources are used, improvements here will go a
long way in assuring the confidentiality, integrity, availability and accountability of
protected systems and resources. Clearly defined security, access control, and
firewall policies will contribute greatly to securing the environment. The physical
environment is well suited for the business needs of the organization. The office
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
85
Author retains full rights.
eta
i
ns
fu
ll r
igh
ts.
space is conducive to business related efforts; however, the space provides little
physical and environmentalsecur
i
t
yf
ort
heor
gani
zat
i
on’
snet
wor
k
i
ngand
comput
i
ngdevi
ces.I
nani
dealsi
t
uat
i
on,t
heor
gani
zat
i
on’
si
nf
or
mat
i
on
technology assets would be hosted in an environmentally controlled and
physically secured computer/data center space. However, there is no justifiable
busi
nessc
asef
ors
uc
hacost
l
ysol
ut
i
onatt
hi
ss
t
agei
nt
heor
gani
z
at
i
on’
s
development.
The choice of firewall platform is well suited to meet their business needs. The
Nokia IP 330 running Checkpoint Firewall-1/VPN-1 NG provides the appropriate
level of port capacity, security features and scalability to meet their requirements.
However, a high degree of residual risks to their information assets remains due
the overall configuration of both the Nokia IPSO operating system and
Checkpoint firewall application.
In most cases the audited control objects were not met. However, in each case
there are economically feasible solutions to reduce security risks to an
acceptable level.
©
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
3.3 System Auditability
The Nokia CheckPoint Firewall-1/VPN-1 NG FP3 system is very auditable. Both
systems, the Nokia IPSO operating system and Checkpoint firewall, have rich
feature sets in this regard. The distributed nature of the security architecture
posed several issues.
 The SecuRemote clients are not auditable. Giving internal network access to
remote users can introduce risks not easily controlled. Who has access to the
Keyu
fingerprint
=st
AF19
FA27
2F94
998D
FDB5
DE3D
F8B5
06E4
A169
4E46
s
er
’
swor
k
at
i
on?
Wha
tacce
ssco
nt
r
olme
as
u
r
esar
ei
mp
l
emen
t
edont
he
workstation? How well is the system defended against computer viruses and
worms? All of these issues can have an impact on the security of the
or
gani
z
at
i
on’
spr
ot
ec
t
edi
nf
or
mat
i
onas
set
swhent
hatr
emot
euserconnect
s.
 Shared user accounts are used for both Nokia IPSO operating system and
the firewall manager. As a result, it is fairly difficult to determine who
accesses these systems with a reasonable level of certainty.
 The Windows 2000 workstation operating system that supports the
Checkpoint firewall configuration client software (Checkpoint Smart Clients)
had default security configurations. Minimal security logging is implemented.
 The lack of documentation made it difficult to objectively audit policies,
procedures, and guidelines.
 Nokia IPSO operating system and Checkpoint firewall alerting features were
not configured and enabled. I could not run tests to trigger an alert for the
audit.
 It was not possible to test firewall redundancy. The firewall is a single point of
failure. I could not run tests or otherwise audit dual firewall failover
capabilities.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
86
Author retains full rights.
4 Assignment 4 –Audit Report or Risk Assessment
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
4.1 Executive summary
The Nokia CheckPoint Firewall-1/VPN-1 NG audit covered several key
information assurance (IA) and security areas of concern, including:
 Policies, Procedures, and Guidelines
 Identification & Authentication
 Physical and Environmental
 Security Design and Configuration
 Continuity
 Encryption
 Audit Trail, Monitoring, Analysis and Reporting
Given the expediency with which this network, and specifically the Nokia Firewall,
was stood up, the overall configuration mini
mal
l
ypr
ot
ect
st
heor
gani
zat
i
on’
s
networking, computing, and information assets from immediate compromise. In
each of the IA areas of concern noted above technical and procedural controls
can be implemented to mitigate security risks to the organization. The sections
below summarize the audit findings, recommend technical and procedural
mitigations, and estimated cost of remediation.
04
,A
4.2 Audit findings
The following exceptions to prudent security practices are noted along with any
related risks to the organization and its information assets.
20
Key
AF19 FA27 2F94
FDB5 DE3D F8B5 06E4 A169 4E46
4.2.1fingerprint
Policies,=Procedures,
and 998D
Guidelines
©
SA
NS
In
sti
tu
te
 Information Security Policies, Procedures, and Guidelines (PPG-1).
Audit Procedure: Interviewed key staff, complete PPG checklist,
reviewed available documentation.
Findings: The organization has not formally documented any
information assurance and security policies, procedures, and guideline.
Staff is aware of the importance of such items and has taken steps to
begin formalizing their documentation.
Risk: All matters related to information assurance/security are without
a solid foundation when formal policies, procedures and guidelines are
not documented. This information guides all aspects of security
including:
o Managing and cataloging system configurations. Stable and consistent
system configurations lower administration costs and support security
patch and software update processes.
o Setting system backup requirements and establishing system recovery
procedures. No backup, no recovery. System hardware and software
failures are inevitable, having a system backup and a documented and
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
87
Author retains full rights.
practice recovery strategy will reduce the risk of prolong system
unavailability.
o Establishing security patch and software update installation processes
reduced the risk of exploited system vulnerabilities.
fu
ll r
igh
ts.
o Developing system configuration guides
o Security policy, Firewall Policy
o Change control policy will eliminate ad hoc firewall rule changes and
create audit trails for administrator accountability. Proposed changes are
reviewed and approved prior to implementation.
te
20
04
,A
ut
ho
rr
eta
i
ns
4.2.2 Physical and Environmental
 Physical Access (PEN-1).
Audit Procedure: Inspected the facility and office space of the
organization including the space housing the Nokia Firewall.
Interviewed key staff using the physical and environmental security
checklist in Appendix B as a guide to the discussion.
Findings: Physical access to the Nokia Firewall and other networking
and computing devices is a not adequately secured. The systems are
in an office space more suited for staff. Technical and physical control
mechanisms are not implemented to control physical access to
networking and computing systems.
Risk: The office space housing the firewall and various other
networking and computing devices does not support physical and
environmental security best practices. Although the number of
Key fingerprint
= AF19 and
FA27computing
2F94 998Ddevices
FDB5 DE3D
A169 4E46
networking
in useF8B5
does06E4
not warrant
data center
like facilities, the open nature of the office environment poses
significant risk of loss due to theft or unauthorized access.
©
SA
NS
In
sti
tu
 Uninterruptible Power Supply (PEN-2).
Audit Procedure: Inspected the physical area containing the Nokia
Checkpoint Firewall and interviewed staff using the physical and
environmental security checklist in Appendix B.
Findings: The UPS implementation does meet the PEN-2 control
objective, however, as previously noted the space housing the Nokia
Checkpoint firewall was designed and is more suited for office
personnel. Environmental control and monitoring technologies are not
available. Most notable are water sprinkler system heads above the
computing devices.
Risk: In an office environment, it is appropriate and likely a
requirement to have water sprinkler systems. However, if triggered,
these sprinkler systems will damage computing equipment.
4.2.3 Security Design and Configuration
 Nokia IPSO operating system security (SDC-3).
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
88
Author retains full rights.
eta
i
ns
fu
ll r
igh
ts.
Audit Procedure: The Nokia IPSO system configuration was
reviewed. The CheckPoint firewall application was disabled to permit
unfiltered network security scans of the Nokia IPSO operating system.
Scans were completed using the nmap and Nessus security scanners.
Findings: The Nokia is running IPSO 3.6 FCS6, Jan. 2003 release.
The scan results indicate that the Nokia IPSO operating system is
vulnerable to several types of network-based attacks when the firewall
software is disabled. The IPSO operating system application
vulnerabilities have been addressed in later releases of the operating
system. The system is also implemented with a remote management
configuration permitting clear-text telnet and http access.
Risk: The primary risk here is unauthorized access when the firewall
software is disabled. The firewall application maybe disabled for
maintenance or troubleshooting purposes on the Nokia. There is also
the ability to enable IP forwarding, effectively turning the firewall into an
IP router.
tu
te
20
04
,A
ut
ho
rr
 Firewall application security (SDC-4).
Audit Procedure: The checkpoint firewall application is in semidistributed architecture. The Checkpoint enforcement and
management modules are both on the Nokia platform. However,
firewall management is handled remotely via a desktop computer
system running Windows 2000 workstation operating system.
Reviewing the Win2K workstation was not in the scope of this audit.
However, there is a trust relationship between the firewall and
manage
men
tc
l
i
en
tby998D
wayo
ft
hef
i
r
ewal
l
’
scon
f
i
gur
a
t
i
on,p
ol
i
c
i
esand
Key fingerprint
= AF19
FA27
2F94
FDB5
DE3D
F8B5
06E4
A169
4E46
rulebase. It was determined that the best approach in auditing the
f
i
r
ewal
l
’
sappl
i
cat
i
ons
ec
ur
i
t
ywast
oscant
hesy
s
t
em f
r
om anunt
r
ust
ed
host and a trusted host.
©
SA
NS
In
sti
Findings: The scan results indicate that the Nokia Checkpoint Firewall
is adequately protected from untrusted hosts. When scanned with
nmap traffic is dropped. Nessus based scans and attacks were either
dr
oppedorsuc
cessf
ul
l
ybl
oc
kedbyCheckpoi
nt
’
sSmar
t
Def
enset
ool
.
However, scans and attacks from the trusted host were permitted
through. The nmap scan run against the firewall from the trusted host
indicated that in addition to the checkpoint firewall-1 NG specific open
application ports, telnet, HTTP, DNS, DHCP client, SNMP, and syslog
services are running. Nessus also revealed application specific
vulnerabilities.
Risk: A trust relationship exists between the Nokia Checkpoint Firewall
and the management client. The security configuration of the Win2K
workstation operating system on the management client as well as its
physical security may severely weaken the security posture of the
entire Firewall system. Again, without the benefit of policies,
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
89
Author retains full rights.
procedures and guidelines to direct security configurations and access
controls the system is open to numerous vulnerabilities.
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
 Remote management activity security (SDC-5).
Audit Procedure: Reviewed the Nokia IPSO management
configuration settings. Reviewed the Checkpoint Firewall NG
Management configuration settings. Used a network analyzer to
capture network traffic between the firewall management client and the
Nokia Firewall.
Findings: A review of the Nokia remote management configuration
settings indicate that telnet and http is enabled for remote IPSO
operating system management. Network data transmission captures of
telnet and http logon traffic revealed administrator account userid and
password.
The checkpoint Global Properties settings permit firewall-1/vpn-1
control connections. Firewall-1/VPN-1 captured connection control
transmissions were encrypted.
Risk: Remote management connections to the Nokia IPSO operating
system are clear text and vulnerable to capture. Remote management
of the Checkpoint firewall application is encrypted. Note that the same
account password is used for IPSO and firewall application
management.
©
SA
NS
In
sti
tu
te
20
04
4.2.4 Continuity
 System and Configuration Backups (CON-1).
Key fingerprint
= AF19
FA27 2F94
998Dbackup
FDB5 DE3D
F8B5 06E4
A169and
4E46
Audit
Procedure:
Review
and recovery
policies
procedures. Review Nokia IPSO configuration to determine backup
implementation. Review the backed-up files and data. Perform a full
backup and recovery on the Nokia Checkpoint Firewall using the
provided back-up and recovery procedures.
Findings: Automated backups are not configured on the Nokia firewall.
Firewall manager backups are not implemented.
Risk: Dependi
ngont
heowner
’
sser
vi
cecont
r
actNoki
ahar
dwar
ecan
be replaced between 1 and 5 business days, however with out a
proper back-up of the IPSO image and configuration actual downtime
could last an additional 24 to 48 hours as the system configuration is
brought back to an operational production state, costing considerable
financial resources and lost productivity.
4.3 Audit recommendations
As a result of the audit findings and risks noted above the following
recommendations are presented.
1. IT staff andt
heor
gani
zat
i
on’
smanagementneedst
odocumentpol
i
ci
es,
procedures, and guidelines. The following areas should be addressed.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
90
Author retains full rights.
fu
ll r
igh
ts.
Keep in mind that these are dynamic documents that will mature and
evolve as the organization develops.
 Security Policy
 Configuration Management Process
 Backup and Recovery Procedures
 Patch Management Process
 Configuration Guidelines
 Change Control Process
 Firewall Policy
All documentation should be version controlled and intranet web
accessible.
©
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
eta
i
ns
2. The organization needs to invest in two water resistant, ventilated,
lockable computer racks. The racks should be positioned away from
sprinkler heads. Although the office is not environmentally controlled
for temperature and humidity, conditions are within acceptable levels
for the eight networking and computing systems in use. It is also
recommended to request that cleaning staff perform their tasks during
normal business hours.
3. Secure the Nokia IPSO operating system
a. Upgrade the IPSO operating system to IPSO 3.7.1 Build004. This
version fixes several vulnerabilities including: IP cluster DoS; script
injection; OpenSSH; and OpenSSL vulnerabilities.
b. Disable all clear-text protocols used to access the Nokia IPSO
operating system.
c. Enable
HTTPS
(SSL)DE3D
for remote
purposes.
Key fingerprint
= AF19SSH
FA27and
2F94
998D FDB5
F8B5 management
06E4 A169 4E46
d. Create individual accounts for each administrator.
e. Disable snmp
f. Configure automated backups of the IPSO image and checkpoint
firewall application.
4. Secure access to the firewall application
a. Upgrade the firewall software to the latest version that includes
CheckPoint Application Intelligence feature. NG with Application
Intelligence (R55).
b. Restrict management access to the firewall. (See 5.a and 5.b
below.)
c. Create individual accounts for each administrator
d. Use widely available best practices to secure and otherwise
lockdown the firewall management client workstation.
e. Provide a means to physically secure the firewall management
client workstation (e.g. secure in a lockable cabinet or provide cable
locks as a theft deterrent.)
5. Implement a more granular rulebase
a. Restrict access to the Nokia Checkpoint Firewall to include only the
firewall management client workstation. The rule should only permit
SSH, HTTPS, CPMI (18190/tcp), and CPRID (18208/tcp).
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
91
Author retains full rights.
ns
fu
ll r
igh
ts.
b. Uncheck the following Firewall-1 Implied Rules:
i. Accept VPN-1 & Firewall-1 control connections
ii. Accept CPRID connections (SmartUpdate)
iii. Acceptdy
nami
caddr
es
sModul
es
’DHCPt
r
af
f
i
c
c. Deny access to the firewall manager from all other networks and
workstations.
d. For the internal network, add individual workstations to the rule
permitting DMZ, wildcard, and Internet access. Remove the internal
network object.
e. I
mpl
ementc
l
i
entoruseraut
hent
i
cat
i
onf
r
om ‘
wi
l
dcar
d’net
wor
kt
hat
contains both wired and wireless client workstations.
f. Redefine the DMZ network. (See 6 below)
g. Subscribet
oChec
kpoi
nt
’
sSmar
t
Def
ense.I
mpl
emental
lpol
i
c
i
est
o
defend against network-based application attacks.
©
SA
NS
In
sti
tu
te
20
04
,A
ut
ho
rr
eta
i
6. Based on discussions with the management and IT staff, the DMZ as it
is currently used does not require Internet accessibility. The
or
gani
z
at
i
on’
s website is static and only provides basic corporate and
contact information.
a. Move the public web server content to a web hosting service that
provides security, secure email, and 24/7 technical support.
b. Deny public Internet access to the redefined DMZ.
c. Include the redefined DMZ in the SecuRemote encryption zone for
remote access.
d. If testing/validation for ongoing business purposes requires Internet
should
be FDB5
permitted
toF8B5
only known
hosts
and
Key fingerprintaccessibility,
= AF19 FA27it2F94
998D
DE3D
06E4 A169
4E46
restricted to applicable ports and protocols.
7. Implement more granular access to SecuRemote users. Restrict the
remote users to specific systems and services.
8. Enabl
eal
er
t
i
ngt
ot
r
i
ggerwhenr
emot
euser
saccesst
heor
gani
z
at
i
on’
s
resources. Monitor logs.
9. Install host-based firewalls on critical system servers to provide an
addition layer of defense.
10. Implement backup and recovery strategies on critical systems. Utilize
the available features in the Nokia IPSO operating system.
11. Eliminate the Nokia as a single point of failure by implementing dual
firewall in failover configuration.
12. System Failure warning alerts should be configured on the Nokia.
Upgrade the support contract to improve hardware replacement
timelines.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
92
Author retains full rights.
Costs
Time
120 hours
► 40 hours--Security
Consultant to
support internal
policy development
effort.
► 80 hours combined
for IT staff and
Management
8 hours
► IT staff relocates
network and server
equipment to racks
► Tests all systems
for correct
functionality
3 days off-site training
$2500—Equipment
ho
rr
(26U Universal Server Rack Mount Cabinet
19 Inch Network Equipmnet Enclosure 36"
Deep)
Cost
$4000—Consultant
Fees
$50—Hard copy
documentation
eta
i
Secure Server Rack
ns
fu
ll r
igh
Recommendation
Develop and Document information
assurance policies, procedures, and
guidelines
ts.
4.4
$2000—Course costs
and travel (courses are
available locally)
CheckPoint SmartDefense Service
4 hours
$1,000—CheckPoint
Key fingerprint = AF19 FA27 2F94 998D FDB5
DE3D
F8B5
06E4
A169
4E46
► Configuration and
subscription
fee
testing
,A
te
20
04
(VPN-1/Firewall-1 Management II –NG)
ut
Checkpoint Firewall-1 Training
8 hours
► Installation,
configuration, and
testing
$400—Software
Firewall redundancy
► Hardware
- Nokia IP 330
- Dual port interface card
► Software
- Checkpoint Express 50 user
license (includes firewall1/vpn-1, SecuRemote,
SmartDefense)
24 Hours
► Installation,
configuration, and
testing
$2500—IP 330 Base
System
$1000—Dual-port
Ethernet card
$3500—Software
©
SA
NS
In
sti
tu
Norton Internet Security
Includes:
► No
r
t
onAnt
i
Vi
r
us™
Professional
► No
r
t
on™ Per
sonalFi
r
ewal
l
:
► No
r
t
on™ Ant
i
Spam
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
93
Author retains full rights.
Backup software
(Retrospect Small Business Server v6.5)
$260—Software
$0
ts.
Implement Nokia and Firewall
configuration and rulebase
recommendations
8 hours
► Installation,
configuration, and
testing
32 hours
► Configuration and
testing
Approx. $10.00/month.
ns
fu
ll r
igh
Web Hosting Service for
16 hours
Informational website and email.
► Setup,
The following provides a web site
Configuration and
hosting directory.
testing
http://www.webhostinginspector.com
Compensating Controls
04
4.5
,A
ut
ho
rr
eta
i
Undocumented costs include
Network downtime—In most cases network downtime is required. In each case the tasks
can be completed during non-business hours.
40-Hour workweek—IT staff working 16 hours during non-business hours may not be
available during normal business hour to maintain a 40-hour work week.
Management Hours—Management hours are more costly. Hours not billed to their clients
directly impacts revenue.
20
Key
AF19 FA27
2F94
998D
FDB5
F8B5 06E4
A169 4E46 and
The fingerprint
goal in any= security
effort
is to
apply
the DE3D
best available
technologies
©
SA
NS
In
sti
tu
te
pr
act
i
cesi
nl
i
newi
t
ht
heval
ueoft
heor
gani
zat
i
on’
si
nf
or
mat
i
onass
et
sand
business model. Although there are significant security improvements needed in
this organization, attempting to achieve absolute security is impractical and cost
prohibitive. In light of this, several compensating controls exist.
1. Harden all windows-based systems and apply the latest security patches.
2. Utilize TCP/IP filtering capabilities on all windows-based system where
appropriate.
3. Currently there is no compelling requirement for public access to the DMZ.
Allow access to only authenticated SecuRemote users. Revisit the issue
as the organization develops.
4. Periodical assess the network using open-source security tools such as
nmap and Nessus.
5. IT staff should regularly review security focused web sites.
6. Management should budget for security related training.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
94
Author retains full rights.
Appendix A—References
ts.
1. Alberts, C., Dorofee, A. Managing Information Security Risks: The
OCTAVE Approach. New York, NY: Addison-Wesley. (2002)
fu
ll r
igh
2. Anonymous. Maximum Security, 3rd Edition. Indianapolis, IN: SAMS.
(2001).
3. Atkins, D., Buis, P., et al. Internet Security Professional Reference.
Indianapolis, IN: New Riders. (1996).
eta
i
ns
4. CACI International Inc.“
Comput
erSecur
i
t
yThr
eat
s”URL:
http://www.caci.com/business/ia/threats.html (September, 2003).
rr
5. Garfinkel, S., Spafford, G. Practical UNIX & Internet Security, 2nd Edition.
Sebas
t
opol
,CA:O’
Rei
l
l
y
.(
1996)
.
,A
ut
ho
6. Has
h,J.S.“
RI
SKMANAGEMENTGUI
DANCEFORI
NFORMATI
ON
TECHNOLOGYSYSTEMS”URL:
http://csrc.nist.gov/publications/nistbul/itl02-2002.txt (February, 2002)
04
7. Information Assurance Support Environment, URL: http://iase.disa.mil
(September, 2003).
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
tu
te
8. McClure, S., Scambray, J., Kurtz, G. Hacking Exposed Network Security
Secrets & Solutions. New York, NY: Osborne/McGraw Hill. (2001).
In
sti
9. Northcutt, S., Zeltser, L., Winters, S., Kent Fredrick, K., Ritchey, R. W.
Inside Network Perimeter Security. New York, NY: New Riders. (2003).
NS
10. Schetina, E., Green, K., Carlson, J. Internet Site Security. New York, NY:
Addison-Wesley. (2002).
SA
11. Spi
t
z
ner
,L.“
Audi
t
i
ngYourFi
r
ewal
lSet
up”URL:
http://www.spitzner.net/audit.html (December, 2000).
©
12. Spi
t
z
ner
,L.“
Bui
l
di
ngYourFi
r
ewal
lRul
ebase”URL:
http://www.spitzner.net/rules.html (December, 1999).
13. Spi
t
z
ner
,L.“
I
nt
r
us
i
onDet
ect
i
onf
orFW-1: How to Know When You Are
Bei
ngPr
obed”URL:http://www.spitzner.net/intrusion.html (December,
2001).
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
95
Author retains full rights.
ts.
14. St
onebur
ner
,G.
,Goguen,A.
,andFer
i
nga,A.“
Ri
skManagementGui
de
for Information Technology Systems Recommendations of the National
Institute of Standards and Technology Special Publication 800-30”URL:
http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf (October
2001).
fu
ll r
igh
15. Tanase,M.“
IP Spoof
i
ng:AnI
nt
r
oduct
i
on”URL:
http://www.securityfocus.com/infocus/1674 (March, 2003).
04
,A
ut
ho
rr
eta
i
ns
16. Titpon, H.F., Krause, M. Information Security Management Handbook, 4th
Editition. Boca Raton, FL: Auerbach. (2000).
©
SA
NS
In
sti
tu
te
20
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
96
Author retains full rights.
Appendix B—Physical and Environmental Security
ut
fu
ll r
igh
ho
rr
eta
i
Is access to the building restricted (key, code,
electronic card)?
Is there a process for issuing keys, codes, and/or
cards that requires proper authorization and
background checks?
Are access logs kept for the computer room?
Are access logs regularly reviewed?
Is the computer room isolated or combined with
other workspaces?
What hours do people have access to the computer
room?
Are security and networking devices secured with in
the computer room?
Is the floor elevated?
Are network cables accessible?
Comment
ts.
Compliant
YES
NO
ns
Physical Security Checklist
,A
Environmental Protections Checklist
Compliant
YES
NO
Comment
©
SA
NS
In
sti
tu
te
20
04
Are smoke detectors present?
Is a firewall
suppression
system
present?
Key
fingerprint
= AF19 FA27
2F94
998D FDB5 DE3D F8B5 06E4 A169 4E46
Are there fire extinguishers in the room?
Are there manual fire alarms?
Are UPS (uninterruptible power supply) devises
installed?
Are emergency power-off switches present inside
and outside the computer room?
Is the temperature of the room set to manufacturer
standards?
Is ventilation to the room adequate?
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
97
Author retains full rights.
Appendix C—Management and IT Questionnaire
What is the purpose/mission of the organization?
2.
Describe how the network is used in general?
3.
How do independent consultants use the network?
4.
How is the Internet used?
5.
How is the internal network used?
6.
How is the DMZ used?
7.
What is the primary purpose of the wildcard network?
04
,A
ut
ho
rr
eta
i
ns
fu
ll r
igh
ts.
1.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Whatar
et
hecompany
’
smos
tval
uabl
easset
s?
9.
How is the information maintained?
10.
What role does information security play in the success of the
organization?
©
SA
NS
In
sti
tu
te
20
8.
Curtis Hefflin
Nokia IP 330 Check Point Firewall-1 NG
AnAudi
t
or
’
sPer
spect
i
ve
© SANS Institute 2004,
As part of GIAC practical repository.
98
Author retains full rights.
Last Updated: March 30th, 2018
Upcoming Training
SANS 2018
Orlando, FL
Apr 03, 2018 - Apr 10, 2018
Live Event
SANS London April 2018
Apr 16, 2018 - Apr 21, 2018
Live Event
SANSFIRE 2018
London, United
Kingdom
Washington, DC
Jul 14, 2018 - Jul 21, 2018
Live Event
SANS Baltimore Fall 2018
Baltimore, MD
Sep 10, 2018 - Sep 15, 2018
Live Event
SANS OnDemand
Online
Anytime
Self Paced
SANS SelfStudy
Books & MP3s Only
Anytime
Self Paced
Download PDF
Similar pages