38
1 Auditing Checkpoint Auditing Checkpoint Firewalls Firewalls CSI Annual Conference 1999 Session J7 Ben Rothke, CISSP Network Security Engineer eB Networks, Inc. Iselin, New Jersey [email protected]

Auditing Check Point Firewalls

Embed Size (px)

DESCRIPTION

One of the first presentations I gave. CSI 1999- Auditing Check Point Firewalls

Citation preview

Page 1: Auditing Check Point Firewalls

1

Auditing Checkpoint Auditing Checkpoint FirewallsFirewalls

CSI Annual Conference 1999 Session J7

Ben Rothke, CISSP

Network Security Engineer

eB Networks, Inc.

Iselin, New Jersey

[email protected]

Page 2: Auditing Check Point Firewalls

2

About me...

• Who I am• Who eB Networks is• Your handout, this presentation WYSINEWYG

– e-mail me for the current version

Page 3: Auditing Check Point Firewalls

3

AgendaThis session is about:• Ensuring your Firewall-1 is properly configured• Performing an audit & analysis of a Checkpoint firewall

This session is not about:• Comprehensive investigation of every available

Firewall-1 configuration and option• General firewall architectures & configurations• Firewall certification

– ICSA– West Coast Labs– CCSA/CCSE

Page 4: Auditing Check Point Firewalls

4

What is a Firewall?

• Protection from all known hacker attacks

• AllAll traffic from inside to outside and vice-versa must pass through the firewall

• Only authorizedauthorized traffic, as defined by the local security policy, will be allowed in

• The firewall itselfitself is immune to penetration

Page 5: Auditing Check Point Firewalls

5

What is a firewall audit?

• Websters defines audit as a methodical examination & review

• A point in time attestation of the firewall structure• How do you perform this methodical examination &

review?– Stay tuned!

• On the other hand, a firewall audit is not:– A guaranty that the firewall operating system or underlying

network operating system is secure– A guaranty that the firewall or network operating system is

configured correctly

Page 6: Auditing Check Point Firewalls

6

GAAP & GASSP• Generally Accepted Accounting Principles (GAAP)

– Widely accepted set of rules, conventions, standards & procedures for reporting financial information, as established by the Financial Accounting Standards Board in 1973. The mission of FASB is to establish and improve standards of financial accounting and reporting for the guidance and education of the public, including issuers, auditors and users of financial information.

• Generally Accepted System Security Principles (GASSP)– In development by the International Information Security

Foundation– Research and complete the Authoritative Foundation– Develop and approve the framework for the GASSP – Map the Authoritative Foundation of related authoritative works – GASSP homepage: http://web.mit.edu/security/www/gassp1.html

Page 7: Auditing Check Point Firewalls

7

GASSP

• The lack of a GASSP means that there is no authoritative reference on which to maintain a protected infrastructure. If there was a GASSP, then there would be a way to enforce a level of compliance, and provide a vehicle for the authoritative approval of reasonably founded exceptions or departures from GASSP

Page 8: Auditing Check Point Firewalls

8

Steps to auditing a firewall

• Review corporate firewall policy• Review network infrastructure• Run hosts & network assessment scans• Review Firewall-1 configuration• Review Firewall-1 rulebase• Put it all together in a report• Redo as necessary

Page 9: Auditing Check Point Firewalls

9

Infrastructure & architecture

• It is necessary to look at the infrastructure since a firewall does not exist in a vacuum, rather it should operate in the context of defense in depth

• Internet access requirements• Understand the business justifications for Internet access• Validate inbound & outbound services that are allowed• Review design (i.e. dual-homed, multi-homed, proxy)• Analyze connectivity to internal/external networks• Interview firewall & network administrators

– Information on operating procedures– supporting documents– installation procedures– maintenance procedures

Page 10: Auditing Check Point Firewalls

10

Policy

Policy is a critical element of the effective and successful operation of a firewall. A firewall can’t be effective unless it is deployed it in the context of working policies that govern its use and administration.

Marcus Ranum defines a firewall as “the implementation of your Internet security policy. If you haven’t got a security policy, you haven’t got a firewall. Instead, you’ve got a thing that’s sort of doing something, but you don’t know what it’s trying to do because no one has told you what it should do”.

Page 11: Auditing Check Point Firewalls

11

Policy

– Is there a published firewall policy for your organization? – What policies have top management reviewed and approved

that are relevant to the firewall infrastructure? This may include:

• Internet usage policy • Business Partners, contractors, temporary staff, etc. • Confidentiality policy• E-mail policy• Emergency Response policy• Responsibilities for controlling the organizations Information

Security

– Are there procedures to change the firewall policies? If so, what is the process?

– How are these policies communicated throughout the organization?

Page 12: Auditing Check Point Firewalls

12

Firewall Management

• Who owns the firewalls - is this defined• Who is responsible for implementing the stated policies for

each of the firewalls• Who is responsible for day to day management of the

firewall• Who monitors the firewall for compliance with stated policies• How are security related incidents reported to the

appropriate Information Security staff• Are CERT, CIAC, vendor specific and similar advisories for

the existence of new vulnerabilities monitored• Are there written procedures that specify how to react to

different events, including containment and reporting procedures

Page 13: Auditing Check Point Firewalls

13

Firewall Security Management

– Accounts on the firewall. Explain their purpose.– Are remote access sessions encrypted via as SSH or similar– How many people have the administration account

passwords? How are these controlled? – Logs

• Enabled, reviewed, archived?

– Backup and recovery procedures established for the firewall configuration, policies and relevant data

– IDS in use?– Adequate backup power supplies– Firewall components located in areas where access is

restricted only to authorized personnel

Page 14: Auditing Check Point Firewalls

14

Configuration

• Ensure FW is appropriately configured• Determine latest patch installation• Y2K• Review system settings• It goes without saying that the FW is physically

secured.• Dangerous system components (e.g., compilers,

debuggers) have been removed • Only necessary accounts are active • Only necessary services and applications are run • No direct modem connection

Page 15: Auditing Check Point Firewalls

15

Physical Security

• NT, Unix, NetWare, all require a secure infrastructure• Local console must be secure• Management console should not be open to the

external network• The firewall configuration should be fully protected

and tamper proof (except from an authorized management station)

• Full authentication is required for the administrator for local administration

• Full authentication and an encrypted link is required for remote administration

Page 16: Auditing Check Point Firewalls

16

Change Control• Review change control procedures documents• Review test plans• Test procedures documentation• Review procedures for updating fixes• Procedures documentation• Review management approval process• Process should ensure that changes to the following

components are documented:– Any upgrades or patches require notification and scheduling of

down-time– electronic copies of all changes– hard copy form filled out for any changes

Page 17: Auditing Check Point Firewalls

17

Backup and Contingency

• Maintain a golden copy of Firewall-1, including patches

• Review backup procedures and documentation• Review backup schedule • Determine if procedures are in place to recover the

firewall system should a disruption of service occur • Review contingency plan• Contingency plan documentation

Page 18: Auditing Check Point Firewalls

18

Miscellaneous issues

• Time synchronization• File system integrity

– Tripwire

• If running on NT, NTFS should be used

Page 19: Auditing Check Point Firewalls

19

Network objects

• Logical entities that are grouped together as part of the security policy. A group of web servers could be a simple network object that a rule is applied to. – Every network object has a set of attributes, such as network

address, subnet mask, etc. Examples of entities that can be part of a network object are:

• networks and sub-networks• servers• firewalls• routers• switches• hosts and gateway• Internet domains• groups of the above

Page 20: Auditing Check Point Firewalls

20

Security issues with network objects

• Objects can contain and reference anywhere from a single device, to entire networks containing thousands of devices which can create a significant obstacle when attempting to evaluate the security configuration & security level of a Checkpoint firewall.

• Network objects are timesaving from an administrative perspective. From a security perspective, any built-in trust that is associated with the object is automatically created for every entity within that object. This web of trust makes a comprehensive Firewall-1 review more difficult.

Page 21: Auditing Check Point Firewalls

21

Services/protocols/users

• Too many services can hinder the efficacy of the firewall– Each service should be authorized. If not, disable it.– NT, check Control Panel => Services– Unix - etc/services

• Similarly, unnecessary protocols open needless communication links– NT, check Control Panel => Network => Protocols– Unix - etc/protocols

• Users– Firewall should a minimal amount of user accounts– NT, check User Manager– Solaris, check /etc/passwd

Page 22: Auditing Check Point Firewalls

22

The rulebase

• A rule base is a file stored on the firewall that contains an ordered set of rules that defines a distinct security policy for each particular firewall. Access to the rule base file is restricted to those that are either physically at the firewall or a member of the GUI clients list specified in the configuration settings.

• A rule describes a communication in terms of its source, destination and service. The rule also specifies whether the communication should be accepted or rejected and whether a log entry is created.

Page 23: Auditing Check Point Firewalls

23

First fit vs. Best Fit

• Firewall-1 is a first-fit inspection engine.

• If you have 50 rules, and the incoming packet matches rule #4, the inspection engine stops immediately (since rules are examined sequentially for each packet) and does not go through the rest of the rule base.

• Each rule must be reviewed in total, verify that the source, destination, service and action is appropriate

Page 24: Auditing Check Point Firewalls

24

Rule 0Rule 0 includes items implicitly protected, including:• Anti-Spoofing - Set on the interface tab of the FW. • Authentication Failures: This is set in the Authentication tab of the

rulebase properties. If this is set to log or alert, any failed authentication attempts will show as a rule 0 log.

• SYNDefender warnings may get logged as rule 0. The Display Warning Messages checkbox in the SYNDefender tab of the rulebase properties is where this can be disabled.

• Successful SecuRemote authentication’s can also appear as a rule 0 accept. This is controlled by the Enable Decryption on Accept checkbox in the Security Policy tab of the Rulebase Properties.

• Anything dropped by the IP Options checking will log as rule 0. The logging is controlled by the IP Options Drop Track section of the Log and Alert tab of the Rulebase Properties.

From http://www.phoneboy.com/fw1/

Page 25: Auditing Check Point Firewalls

25

Stealth rule/Cleanup rule

The stealth rule ensures that that nobody can directly connect or communicate to the firewall, other than

administrators that are GUI authorized.Remember to use Drop, not Reject

Page 26: Auditing Check Point Firewalls

26

Examples of poor rules

Page 27: Auditing Check Point Firewalls

27

Implied pseudo rules

Page 28: Auditing Check Point Firewalls

28

Misc. issues• GUI clients

– Verify, and limit amount

• Administrators– Verify permission level (Read Only, Read/Write)

• SYNDefender– None/Gateway/Relay

• IP Forwarding– Disabled

• ICMP– Disable. If ICMP (Properties => Security Policy) is enabled,

your network can be externally port scanned. If ICMP is needed, create a rule that limits what source addresses can connect to them.

Page 29: Auditing Check Point Firewalls

29

INSPECT• INSPECT is a high-level programming language for FW-1.

By using INSPECT, programmers can create FW-1 specific applications and/or calls to the FW-1 O/S.

• Security applications written in INSPECT are compiled into executable code which is downloaded to the access devices and security gateways. The INSPECT VM on the access devices and security gateways then executes these applications enforcing the rules defined via the rulebase.

• INSPECT is designed for security. Therefore it doesn’t allow loops, functions don’t support recursion, no explicit memory allocation is permitted; in addition to other features.

Page 30: Auditing Check Point Firewalls

30

INSPECT• You will likely never need to review any INSPECT code.

The .def files, which are used to generate INSPECT code may infrequently need to be modified to allow certain services through the firewall, to change some default behaviors, or to make changes to some services.

• Inspection script - ASCII file (*.pf) which is generated from a Security Policy (*.w file)

• Inspection code - *.fc file compiled from the inspection script

• FW Module - Runs on the host that executes the inspection code

Page 31: Auditing Check Point Firewalls

31

Resources• www.phoneboy.com

– Excellent FW-1 resource with tons of technical information

• www.enteract.com/~lspitz/pubs.html– White papers on FW-1 & security from Lance Spitzner

• www.securepoint.com – Maintains numerous FW-1 discussion threads

• www.checkpoint.com/~joe – FW-1 reference page

• www.securityportal.com– Firewall products & security news

• safer.siamrelay.com– Multivendor security information

Page 32: Auditing Check Point Firewalls

32

More resources

• Marcus Ranum: Publications, Rants, Presentations & Code– www.clark.net/pub/mjr/pubs/index.shtml– Relevant to this talk, read On the Topic of Firewall Testing

• Internet Firewalls Frequently Asked Questions– www.interhack.net/pubs/fwfaq/

• Auditing Your Firewall Setup – www.enteract.com/~lspitz/audit.html

• Bugtraq vulnerability database– www.securityfocus.com

Page 33: Auditing Check Point Firewalls

33

Tools

• ISS– Internet Scanner– System Scanner

• NAI– CyberCop Scanner

• Nmap– www.insecure.org/nmap

• SecureIT– Firewall HealthCHECK

• Saint– www.wwdsi.com/saint

• WebTrends for Firewalls– www.webtrends.com/products/

firewall

Caveat: Your firewall can graduate magna cum laude from these tools & still be insecure

Page 34: Auditing Check Point Firewalls

34

Books

• Brent Chapman & Elizabeth Zwicky Building Internet Firewalls, O’Reilly & Assoc., 1995. ISBN 1-56592-124-0

• William Cheswick & Steve Bellovin Firewalls and Internet Security Addison Wesley, 1994. ISBN 0-201-63357-4

• Simson Garfinkel & Gene Spafford Practical Unix & Internet Security, O’Reilly & Assoc., 1996 ISBN 1-56592-148-8

• Marcus Goncalves Checkpoint Firewall-1 Administration Guide, McGraw-Hill 1999, ISBN: 0-07134229-X

Page 35: Auditing Check Point Firewalls

35

Mailing lists

• CERT – cert-advisory-request@ cert.org

• CIAC– [email protected]

• Firewall-1 mailing list– [email protected]

• Firewalls mailing List – [email protected]

• Firewall Wizards List– [email protected]

• Newsgroups– comp.security.firewalls– news.checkpoint.com

• COAST– coast-

[email protected]

• Bugtraq– [email protected]

• NTBugtraq– [email protected]

• ISS X-Force Advisories– [email protected]

Page 36: Auditing Check Point Firewalls

36

Conclusion

A firewall is only as good as it’s implementation. In today’s dynamic world of Internet access, it’s easy to make mistakes during the implementation process. By auditing your firewall setup, you can ensure that the firewall is enforcing what you expect it to, in a secure manner.

Source: Lance Spritzer

Page 37: Auditing Check Point Firewalls

37

Any questions? Any questions? comments? jokes?

Please fill out your evaluation sheets

Page 38: Auditing Check Point Firewalls

38

Thank You!!

Ben Rothke, CISSP, CCO

Network Security Engineer

eB Networks, Inc.

[email protected]

www.ebnetworks.com

Iselin, New Jersey USA