Showing posts with label checkpoint. Show all posts
Showing posts with label checkpoint. Show all posts

Wednesday, 13 April 2011

Evaluation Assurance Levels - EAL

EAL stands for evaluation assurance level and is a certificate of security for IT products measured against a set of common security criteria. The main source of information on EAL levels is the common criteria portal where you can find details of approved products and information on the criteria used for the EAL certifications.

Who uses it?


Your average network bod may not come across EAL very often. It tends to crop up in areas that are regulated by government bodies such as CESG who will often require EAL4 certified products for certain secure environments. However you don't just buy EAL4 kit and be government approved, it fits into a much larger security framework such as ISO27k dealing with everything from who gets into the building to how you manage changes to IT systems.

How does a product get EAL certified?


It is assessed against a set of common criteria by an approved agency. The developer of the system produces a security target (ST) document containing a list of features to be assessed.The ST is based on the criteria here. The process is long and expensive, according to wikipedia vendors were spending $1 - $2.5million to gain EAL4 certification in the 1990s.


What do you get when EAL certified?


Certified products are listed on the common criteria portal along with the rating granted, the ST it was assessed against and the assessment report. e.g. here (PDF) is the ST for the Cisco ASA as a firewall and here (PDF) is the assessment report. Interesting to note that the EAL4 VPN certificate was issued separately, so an ASA acting as both firewall and VPN endpoint is not a valid EAL4 solution, strictly speaking you would need two in series performing each task.

So what does it mean in to a network engineer?


Probably not a lot, it's a policy requirement for many places but the assessment is only against the device, not against the specific implementation of it. You could deploy an EAL4 firewall with a policy of "permit any any" and it's still an EAL4 device! At that point the other security mechanisms should have stopped you from putting it on the network.

If you are involved in hardware selection for a regulated organization then you may need to use EAL4 devices in certain situations.

What is required to meet the various levels?


The EAL process is broken down to cover the following aspects of a system:
Development, documentation, life-cycle support, security target evaluation, testing, vulnerability assessment.

Each EAL level goes into slightly more detail, for example the "development" area at EAL1 requires a basic functional specification to be provided by the developer. EAL2 requires that same functional specification but expanded to include details of security inforcement. It also requires a security architecture description and a basic design. The specifics of those items are detailed here.

How long does it take to get EAL4?


It seems to vary from a very long time to aeons, certainly it's measured in years rather than months. A look on the NIAP CCEVS evaluation and evaluated list for firewalls shows a few examples:
Checkpoint R65 HFA01 on IPSO recorded as submitted Oct 2005 although R65 was released in 2007 so the process was started early during development. It passed March 2009. So that's 4 years to get certified and the product went EOL in March 2011, 2 years later.
Cisco ASA 8.3 as a VPN submitted November 2009 still not passed, predicted June 2011.
Palo Alto submitted various devices in December 2009 and still running.

What exactly is certified?


The certification is issued against a specific software release and hardware platform.

A specific version of the software you say? As in....minor version??


That is how the cert is written. The Cisco ASA obtained EAL4 for firewall purposes on version 7.0(6) of it's OS which was released in August 2006. Cisco have been patching and updating that for 5 years! The ASA is now up to release 8.4, which has been submitted again to CCEVS (scheme run by NIST and NSA) for evaluation.

In reality there will be a security assessor on the ground who will review the solution and hopefully be sensible about using a modern patched version of the OS and judge it acceptable to meet an EAL4 requirement, even if it's not strictly what's on the EAL4 certificate.

I don't know anyone who would tell you with a straight face that using a 5 year old OS on a firewall is going to increase your security!

What about high end firewalls?


There is a bit of a gap, if you need an EAL4 firewall with 10gig throughput then you're out of luck as the only one that's passed assessment is Checkpoint Power-1 on the 5075/9075, however that went end of life last month (March 2011). The closest is the Cisco 5580 which has been submitted for EAL4, due November 2011 and is arguably similar enough to the 5540 to be acceptable, however it's recently announced as being binned in preference of the 5585 so after August 2011 you can't buy one any more!

The security market moves quickly compared to the EAL assessments and it proves tricky.

The top end Cisco firewall platform is the 5585, not even showing as submitted for EAL evaluation yet.
Checkpoint has R71 under assessment now, predicted result in November 2011.
Palo Alto has various items aiming for November 2011, but their flagship model the PA-5000 is not listed as under assessment, it only recently hit market in the UK so EAL certification may not have been discussed yet.
Juniper have EAL4 for their ScreenOS platform the SSG, which goes EOL in 2013. They have EAL3 for Junos 9.3 on the SRX platform, the current version is 10.4. There doesn't appear to be any indication that the SRX security platforms have been submitted for EAL4 certification, although it would be surprising if that were the case as governments would be ditching Juniper en-masse before 2013.

So until November 2011 there are no EAL4 10gig firewalls. You'll have to build a farm of 1gig ones instead!

What alternative schemes are there?


FIPS-140 from NIST.
CAPS, the CESG Approved Product Scheme.

Is it worth me buying EAL4 products?


If you have to ask then probably not. If your business is regulated and the agencies setting those policies define EAL4 as a requirement then you have no choice.

For companies with the option I would say it's a helpful indicator but I would certainly use other aspects above the EAL status when selecting a device:

  • Performance.

  • Price.

  • Published security tests and exploits.

  • Staff familiarity.

  • Internal testing.



An EAL4 certificate does indicate that the product was developed following good practices and has a well defined and documented architecture. These are clearly good things in terms of stability and security. However not having EAL4 doesn't necessarily mean the product hasn't followed a good development process and isn't secure, it just means the manufacturer hasn't paid for it to be assessed.

Read more...

Monday, 19 October 2009

Checkpoint Traffic Sniffing

There are a couple of handy commands for sniffing traffic on Checkpoint.

Tcpdump and fw monitor.


The following runs a tcpdump capture on IPSO, snagging the entire packet to a file:
tcpdump -s1700 -w output.cap -ni <interface> host <IP-addr>

Without the -s1700 it'll just grab the first part of each packet and not the full contents. If you're running it on a newer platform (e.g. SPLAT) then you can probably use -s0 instead, it's to specify the size of the packets that are recorded.

The problem with tcpdump is that running it on a device designed to filter traffic means you may not be seeing exactly what you expect. So it's probably better to use "fw monitor", the Checkpoint tool that lets you specify exactly where in the stack you are sniffing packets from.

The official guide is here.

Not much more to say about it except to give a simple example for reference:
fw monitor -e 'accept src=<src-ip> or dst=<dst-ip>;'

Just remember to terminate each line with a semi-colon.

Read more...

Wednesday, 9 September 2009

Minimal Downtime Checkpoint Upgrade

This is an old process I worked out for an R55->R65 upgrade on a Nokia VRRP cluster to provide minimal downtime. In lab tests this worked with under a second of lost packets. In reality I wouldn't bet on a busy cluster being upgraded without losing traffic under any circumstances!

My preferred method is to wipe everything completely and re-build from config backups rather than try to do software upgrades.


Step 0 is to make sure you have printed copies of all documents (incase you kill the internet), copies of both old and new IPSO, Checkpoint, HFAs any CDs you need and all passwords.


First steps are to upgrade the Server, a newer version server can manage old enforcement modules.

1 - Run upgrade_export on the Smart Center Server (SCS) and save the file remotely.
2 - If you have a backup SCS then run cpstop on it, keep it for backout!
3 - Run cpclean on the SCS to remove all Checkpoint software. Run the CD install.
4 - Use upgrade_import to load the config exported in step 2.
5 - Sort out the licenses (test this thoroughly in advance or allow hours/days/weeks for this step)
6 - Check the server is talking to the enforcement modules correctly.
7 - Backup server can be updated at any point from here on, personally I'd leave it until much later to be sure we don't need to roll back to it.

- SCS now updated -

8 - Run the IPSO backups on all enforcement modules (firewalls).
9 - Turn off "Firewall Monitoring" in the VRRP options on all firewalls.
10 - Set the cluster version to be R65 in Smart Dashboard.
11 - Reboot a backup firewall and run the IPSO install from the boot manager, also install the R65 wrapper.
* This may not work with anonymous FTP, best to set a username/pass on FTP server *
12 - When the box is rebuilt, log in via SSH, edit the file $FWDIR/lib/webgui_client.def and add the IP address of the PC you want to use to access Voyager initially.
13 - Run comp_init_policy -g to regenerate the initial firewall policy with the new client definition.
14 - Reboot the box.
15 - Install any HFAs, check whether the client.def file needs editing again each time (HFA may overwrite it).
16 - Log into the system on voyager, load the IPSO backup file from earlier. Turn off VRRP monitor firewall.
* Check the package and IPSO image configuration, this may have reverted back to the old versions, you may need to re-install Checkpoint packages to get these settings back to sensible values *
17 - Push policy from Smart Dashboard, it should install to the updated firewall only.

* OUTAGE COMING UP!! *
You can use cphaprob state to see whether you have a cluster working but it's unlikely due to the version differences

18 - Force VRRP to fail over, either by editing the priority values or by disabling/disconnecting a monitored interface on the master unit.

Make sure you edit the priorities anyway on the upgraded unit so it remains the master when you restore the IPSO config later onto the next unit.

Don't just turn the priority down on the (old) master as the IPSO restore will reset them and you may end up with a VRRP master that has no firewall software loaded and just acts as a router!

19 - Run any traffic tests you have, decide whether the new version is working properly and whether you want to go past the point of no return! You can still fail back to the old version at this stage.

20 - Run steps 11-17 on the remaining firewall.

21 - Push policy to the entire cluster, verify all units accept it. Check that the cluster is talking with "cphaprob state"
22 - Set VRRP values back to the original state, re-enable "monitor firewall".

23 - Test out the new firewalls. Include

Hopefully it's all worked and you're now on the new versions.

Read more...

Useful Checkpoint Commands

Some useful Checkpoint commands for reference:

fw unloadlocal - Unload the local policy.
fw stat - Show the policy version that is currently installed.
fw log - Show the log file.
fw ver - Show the installed Checkpoint version.
fw lslogs - List all log files available.
fw logswitch - Force a log cycle.


cp_conf sic state - Show SIC (secure internal comms) status.
cp_conf ha enable/disable - Enable/Disable HA (not sure what difference is to cphastop/cphastart)
cp_conf lic get - Show installed licenses - same as "cplic print"

cpstat - Show module status
cpstat -f routing os - Show routing table.
cpstat -f ifconfig os - Show interface configurations.
cpstat -f accelerator vpn - Show VPN hardware status.

cpwd_admin - Checkpoint process command.
cpwd_admin list - Show running processes.

vpn debug - Turns on VPN debugging, logs to $FWDIR/log/vpnd.elg
vpn debug ikeon - Turns on debugging to $FWDIR/log/IKE.elg (needs IKEView application to read)

vpn tu - VPN Tunnel Utility

vpn ver - Shows VPN version installed (same as fw ver in any NG/NGX).

iclid - Basic shell to provide IOS like commands.


Clustering / HA commands (These also work for VRRP HA)

cphaprob state - Show clustering status (this should list all firewalls in the cluster or something isn't working).
cphastart / cphastop - Start/Stop the High Availability/Clustering.
cphaconf - HA configuration from command line.
cphaconf set_ccp broadcast/multicast - Set the Cluster Control Protocol to use broadcast or multicast

Read more...

Monday, 24 August 2009

Checkpoint Software Blade Architecture

I received an email this morning from Checkpoint advertising their new software blade architecture.

Checkpoint already provide a hardware virtualization platform in the VSX-1, so could this be a blade-center version? No, the blades here are not actual blades in the sense that the rest of the industry uses the term, they are infact software modules.

So what is it?
It's a "new" architecture to Checkpoint systems that allows you to choose which software modules you want installed on your gateway/smart center servers.

So whats the difference between this and R65's cpconfig software install section?
It has templates (and possibly a GUI).

Is there anything new here?
Kind of, if you dig a bit deeper there are some interesting bits to R70, but they're nothing to do with blades or this software blade architecture.

The Checkpoint blade architecture seems mainly to be a new model for licensing, it'd be nice to avoid the confusion of the past. The old licenses seem so simple in theory, but in practice quickly become painful, especially when you have upgraded a complex system through several releases (and who runs Checkpoint on anything other than a complex system). I'll be watching with interest!

I do wish they'd called it something else though, blade is a fairly well known term and using it in this context is likely to cause confusion.

So what is new?
R70 replaces smart defence with IPS, URL filtering, anti-spam and anti-virus modules. These are software only modules, not like the Cisco ASA IDS/IPS units, and they run on the same hardware. It'll be interesting to see how well these perform in the wild as I don't currently have any data on them.


Nokia/IPSO support in R70
It may (or may not) be news to some but R70 now is being released for Nokia/IPSO platforms. I'm a bit suprised that Checkpoint are still supporting the Nokia boxes now that they have their own line of hardware running SPLAT.

Nokia is no longer a supported platform for Sourcefire and I can't see Checkpoint supporting them indefinitely. Both SPLAT and IPSO are Unix-based systems but SPLAT is a Linux kernel and IPSO is FreeBSD based so they won't be using identical code and it must be expensive for Checkpoint to develop and maintain both lines.

Nothing has been announced that I'm aware of but it would seem like a good idea to start thinking about migrating away from the Nokia boxes if you use them currently.

Read more...

Monday, 8 June 2009

Checkpoint to Cisco VPNs #2

This is part 2 of the article started here. I'll be creating traditional mode VPN rules, because they are less abstracted than VPN communities and a bit easier to understand (in my opinion). There are some complications*.

To follow a similar methodology to that used on the Cisco router, the steps are as follows:
  1. Define the ISAKMP (phase 1) policy.
  2. Define the IPsec (phase 2) policy.
  3. Create the firewall rule specifying traffic to pass over the VPN.
  4. Define the encryption domains.

Checkpoint doesn't really have a concept of applying the crypto map to an interface as with Cisco. The Cisco concept of a crypto map is close to the encryption domains on Checkpoint.


1. Define the ISAKMP (phase 1) policy.

In Checkpoint the ISAKMP configuration is applied to an "interoperable device" object created for the Cisco VPN gateway. Edit your interoperable device and select "traditional mode configuration" on the "VPN" page to open the ISAKMP properties as shown here:

You configure encryption and integrity, specify to use a pre-shared secret (although you won't be able to enter one just yet) and in the "Advanced" options you can specify DH and lifetimes.

Be careful as the Cisco and Checkpoint default lifetimes do not match.

In practice, ISAKMP can negotiate new keys when the old ones are due to expire but best to make them match anyway to keep things tidy.



2. Define the IPsec (phase 2) policy.
3. Create the firewall rule specifying traffic to pass over the VPN.

IPSec policy is defined under the actual firewall rule which also specifies the interesting traffic. Create a rule allowing the VPN traffic through the firewall (using pre-NAT addresses) and set the action to be "Encrypt"*. Double click on "Encrypt" and you can edit the IPSec settings for the connection.

In this case we're using 3DES/MD5, DH group 2 and specifying which interoperable device the VPN is talking to.

The traffic being allowed is between 10.0.0.0/24 (local) and 172.16.0.0/24 (remote) in either direction and Any protocol.




4. Define the encryption domains.

The encryption domains on Checkpoint are defined as properties of the gateway objects. Edit the interoperable device and open the "Toplogy" page, you can either manually set the topology or use another object to represent the encryption domain.

Here I am using the Remote_172.16.0.0_24 network object to define the Cisco end of the VPN encryption domain.

If you do destination NAT then the encryption domain is the post-NAT address as opposed to the firewall rules which must contain the pre-NAT address.




So that's the remote encryption domain defined, the local encryption domain is specified in the Checkpoint gateway object in the same way. The best way to do this is with a group, so that you can easily add further subnets in future if needed.



There is just one thing missing from the above, the shared key. This is actually defined on your local Checkpoint object rather than the remote peer's object. The reason I put this last is that the peer name won't show up until you've configured the interoperable device properties.

Edit your own Checkpoint enforcement module and open the VPN "Traditional mode configuration", then use the "Edit Secrets" button and you should see an entry for each of your VPN peers that have the "Pre-Shared Secret" box ticked.

Simply select the peer and enter the secret, "cisco" in this case.








Now having said all of the above, I will also say that making these systems interact nicely is a tricky business and you may find that it doesn't work even if you've followed these instructions to the letter.

Part 3 of this series of articles will include some troubleshooting methods to try and help fix any problems.











* Note: Checkpoint firewall policies are either in traditional VPN mode or simplified VPN mode which uses communities rather than the rules shown above.

If you don't have the "Encrypt" option in the Action column or if you have a "VPN" column then you're using a simplified VPN policy and cannot create traditional mode VPNs. Unfortunately you cannot convert a policy from simplified mode to traditional so your options are either to create a new policy from scratch, specifying "traditional" when you create it, or to use VPN communities instead.

Read more...

Sunday, 24 May 2009

Checkpoint to Cisco VPNs #1

Article #1 - Intro & Cisco Setup.

To show some of the finer points of Checkpoint VPNs I'll rig up a test lab with a site-to-site VPN linking a Cisco IOS router and a Checkpoint R65 splat box.

This article is not intended to be a general VPN introduction, rather the specifics of Checkpoint/Cisco interaction.


The network will look like this:




The local end is using 10.0.0.0/24, the Smart Center sits in this subnet.

The VPN traffic is shown by the red arrow. I'm using a transit network, VLAN 150 - 192.168.0.0/24 but this will probably be the internet in most cases.

The first VPN is going to be very simple, no NAT involved anywhere.








Cisco IOS Setup

In this case we need a static route configured on the IOS router to ensure traffic for the remote LAN goes out of the correct interface:
ip route 10.0.0.0 255.255.255.0 192.168.0.2
In reality you may not need this as for internet-based site-to-site VPNs the routers default route often does the job.

Now the five steps to create a VPN, handy bit of ISCW revision!
  1. Define the ISAKMP (phase 1) policy.
  2. Define the IPsec (phase 2) policy.
  3. Create the crypto ACL specifying interesting traffic.
  4. Make the crypto map to bind it all together.
  5. Apply the crypto map to an interface.

1 - ISAKMP policy

crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 2
crypto isakmp key cisco address 192.168.0.1

2 - IPsec policy
crypto ipsec transform-set TESTSET esp-aes 256 esp-sha-hmac

3 - Crypto ACL
Define here what traffic should be encrypted.
ip access-list extended VPN_INTERESTING_TRAFFIC
permit ip 172.16.0.0 0.0.0.255 10.0.0.0 0.0.0.255 log

4 - Crypto Map.

 crypto map VPN_MAP 10 ipsec-isakmp
set peer 192.168.0.1
set transform-set TESTSET
set pfs group2
match address VPN_INTERESTING_TRAFFIC


5 - Apply to an interface

Cisco_Router(config)#interface fastethernet 0/0
Cisco_Router(config-if)#crypto map VPN_MAP
*Mar 1 00:25:33.187: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON


If you see the "ISAKMP is ON" message then it's looking good. If you get errors then check whether your hardware and software is supported, as an example some of the 8xx series routers cannot do AES encryption and I don't think IPsec is supported on any of the standard IOS images.

Part 2 goes over configuration of the Checkpoint end.

Read more...