Checkpoint Firewall-1 Upgrade NG-R55 to NGX-R65

August 30, 2008 / / 6 comments

This will undoubtedly be a fun and tedious challenge. No support and only Google to work with.

The upgrade will consist of upgrading from a clone PC with 3 NIC cards running Secure Platform NG R55 to Secure Platform NGX R65running on a Dell PowerEdge 1950 with 2 x 146Gb 15K rpm drives and 4 NIC cards.

A lot of research went into the actual migration and during this research I found an excellent summary on backups, snapshots and upgrade exports.

[Oversimplified Executive Summary]
  • -A upgrade_export contains just Check Point configuration
  • -A backup is an upgrade_export plus SPLAT OS configuration
  • -A snapshot is a backup plus binary files, both Check Point and SPLAT OS
  • -As a general rule of thumb, if your restoring on the same hardware a snapshot would be the easiest to use since it contains the most info and an upgrade_export would be the worst, since you’d have to manually restore the most stuff.
[upgrade_export]
  • -It doesn’t backup any OS (i.e. SPLAT) settings, it only backup up CheckPoint settings
  • -It will let you export on one OS and then import on a different OS (i.e. go from Windows to SPLAT)
  • -You can upgrade_import on different hardware (i.e. go from IBM to HP)
  • -You can restore an export from an older version to a newer version of CheckPoint. A SPLAT backup/restore requires that you have the exact same versions. Note that when upgrading from an older to newer version, you must use the newer version’s upgrade_export utility to create the export file.
  • -It restores the product list as well. The SPLAT restore command won’t restore the Check Point settings if you don’t have the exact same products (and product versions) installed.
[backup]
  • -A SPLAT backup will back up both the SPLAT OS settings as well as the CheckPoint settings
  • -Basically it’s an upgrade_export with OS settings added in
  • -Restoring a backup file requires the exact same software installation. I.e. you can’t restore a backup from R55 on to R60 (the HFA level must match as well). The installed product list must match as well. Note that you can still restore the OS settings even if your installed Check Point product list doesn’t match.
  • -The SPLAT OS settings are hardware specific. If you restore the system settings you must restore on the same hardware. However, if you only restore the Check Point settings you can restore on different hardware. Restoring just the Check Point settings is essentially the same thing as doing an “upgrade_import” of an exported file.
[snapshot]
  • -A snapshot is even better than a backup since it contains binary files. I.e. you can revert from R60 to R55 with a snapshot. The downside to this is that a snapshot file is much larger than an upgrade_export or backup file.
  • -A snapshot can also roll you forward for minor software changes. For example if I revert from R60 HFA05 to HFA01 I can later revert back to R60 HFA05 from R60 HFA01
  • -A snapshot cannot revert to a newer major release of Check Point. I.e. you can’t revert from R55 to R60.
  • -If you’re reinstalling SPLAT on the same hardware you don’t have to install any HFA’s or change any configuration. Simply reverting to your saved snapshot file will restore all configurations and HFAs. The only stipulation is that the major software version must match. I.e. a R60 snapshot file will only work on a R60 install (regardless of HFA level).
  • -You can only revert on the same hardware, since the snapshot file contains hardware specific SPLAT settings.
[An exception to the rules]
  • -If you’re feeling lucky I’ve noticed that you can actually restore a backup file or snapshot file on different hardware as long as you:
  • -Delete “/etc/sysconfig/hwconf” (this is automatically re-created during the reboot)
  • -In the case of a snapshot file also delete “/etc/modules.conf”
                -Backups don't contain this file
                -modules.conf controls which drivers are loaded
                -This is be automatically re-created during the reboot
  • -Remove the “hwaddr” lines from /etc/sysconfig/netconf.C
  • -Reboot
  • -You must remove the hwaddr lines since the firewall will use the MAC addresses stored in the snapshot/backup file, not your network card’s physical MAC addresses. You can verify which MAC addresses you’re using with these commands:
        ifconfig |grep HWaddr
                -This shows which MACs you're currently using
        grep hwaddr /etc/sysconfig/hwconf
                -This should contains your NICs' physical MAC addresses.
           If in doubt, delete this file, reboot and this file will be
           automatically created on startup.
        grep hwaddr /etc/sysconfig/netconf.C
                -This shows which MACs your server is configured to use.
           If there are no "hwaddr" lines, then your NIC's physical MACs
        will be used.  If there are no "hwaddr" lines you can create them
        by running "cpnetconf store".
  • -To remove the hwaddr lines in “/etc/sysconfig/netconf.C” run these commands:
        cd /etc/sysconfig
        cpstop
        mv netconf.C netconf.C.old
        grep -v hwaddr netconf.C.old >netconf.C
        rm /etc/sysconfig/hwconf
        reboot

Instructions:
  1. Make a backup, a snapshot of your original firewall. Its not fun having to restore a firewall from scratch without a backup.
  2. Make a note of the DNS servers, IP addresses and associated ethernet NICs (ie. eth0, eth1, eth2, etc.), make a note of products installed.
  3. Secure an Eval license from a Checkpoint vendor.
  4. Install the new version of Checkpoint on the new hardware.
  5. cd to $FWDIR/bin/upgrade_tools and run “./upgrade_export /path/with_enough_space/cpexport_R55.tgz” on the production firewall.
  6. Download the upgrade_checker from Checkpoint depending on your upgarde path. In my case its R65_upgrade_checker.linux22.tgz
  7. Extract the checker and run the R65 version of the upgrade_export binary. “./upgrade_export /path/with_enough_space/cpexport_R65.tgz”
  8. Import both exports into your new firewall.  1st the R55 export and then the R65 export. Run “./upgrade_import cpexport_R55.tgz” and then “./upgrade_import cpexport_R65.tgz”.
  9. Be sure to upgrade your license. You will need internet connectivity and an active support agreement with Checpoint. The file that you need to run is in the NGX CD and its called <OS>/license_upgrade. Run “./license_upgrade simulate” and then “./license_upgrade upgrade”. You can check the status by isung the status flag.

[ad]

Category: Technology / Tags: ,

Screencast on Cracking WEP

June 21, 2005 / / No comments

Just like webcasting, podcasting and other type of castings….. screencasting is also starting to pick up as a way to share the knowledge!!!!! Here’s one on cracking WEP. WEP is a security protocol for wireless devices. More on Wikipedia… (an online FREE encyclopedia growing strong).

Category: Security / Tags: ,

What is the problem with SIP & NAT

May 18, 2005 / / No comments

Getting SIP to work across a NAT or several of them from point to point can be very painful…. a sniffer and logs will help you greatly, if you can understand what is going on……

A SIP call involves both SIP signaling and RTP audio streams with the RTCP control streams as a hang-around.

MORE…

Let’s look at it from above:

SIP CLIENT SIP SERVER
(phone) (phone)

———————> SIP
SIP < ———————
———————> RTP
RTP < ———————
———————> RTCP
RTCP < ———————

This means that we have six different UDP streams for one call. Each one have a sender’s address (IP) and a sender’s port (UDP) and a recipient’s address and port. In most cases, the RTP ports are dynamically assigned, to enable multiple calls at a time. If you place a firewall in between the phone, you can imagine that there’s a lot of ports to open and close for a call.ave one way audio? Why? If both client and server are located on the same network, which was the assumption of the SIP architects, this is rather elegant. It gets messy if they are on two different networks with a NAT (Network Address Translator) device between them. Let me explain.
SIP PHONE (A)————NAT————–SIP PHONE (B)
Local network INTERNET

Now, the SIP phone A tries to call SIP phone B. The NAT device lets the SIP message go out to SIP phone B, and “remembers” that A is talking UDP to B.
When B answers the call, the NAT device looks the address up in memory, figuring out that B was contacted by A and sends the packet to A. In the SIP answer from B, B told a that “I listen for your audio on this RTP port”. In the original message from A to B, A told B that “I listen for incoming audio on this IP and this port”.

Here’s where the problematic area begins.

Phone A is able to send audio to phone B. But the message from A to B included a non-existing IP address (Internal RFC1918 IP address) so there’s no way B can send audio to A. This is the reason for a lot of messages on the list saying
-“I only get audio in one direction in my SIP call”.
There’s no way B can send audio to A. Period. We need to change the behaviour of A and B to get calling out to work.
Solution: The Asterisk NAT fix
Imagine that Phone B is your Asterisk server. In the Asterisk SIP channel, there’s a peer setting called “nat=yes”. This changes the behaviur of phone B, i.e. Asterisk.

When phone A sends an invitation to a call, it includes the IP address and port where it listens for audio from phone B, your Asterisk server. If “nat=yes” is set, Asterisk says “fine, dude” and totally ignores this data. Instead, it checks the IP address the message was sent from, i.e. your NAT device. This IP address is used instead of the local private address (RFC1918) and audio is sent to that address instead. With most NAT devices, the audio is then forwarded to the client and we have two way audio.

Conclusion: If Asterisk is on a public address (on the Internet) and your phone is behind a NAT (from the server’s point of view), setting nat=yes fixes your audio problem.
The phone can call Asterisk, but I get no incoming calls?
The NAT device is like an old relative, it has got a very short memory. So after a while, the relationship between phone A and phone B is totally forgotten. Beacuse of this, when phone B wants to place a call to phone A, the NAT device looks at the IP sender’s address and can’t relate it to any device on the inside. It drops the packet and forgets all about it ever having been sent there in the first place.

This is how NAT devices work. If communication starts from the inside, going out, answers are handed back to the inside. If someone on the outside wants to communicate to someone on the inside, that will not work.

Solution: Keep the gates open – NAT-keep-alives
A SIP phone usually registers with a SIP proxy. This message comes from the inside of the NAT to the server on the outside. Now, there’s an open connection in the NAT device. As soon as there’s no more packets on that connection, the NAT device cancels the connection and forgets all about it. The trick is to keep the packets flowing, forcing the NAT device to keep the connection open.

Some phones send NAT “keep-alive” packets by themselves. X-lite and Sipura have this feature. If the phone can’t do it, configure Asterisk to do it. Setting “qualify=yes” in the [peer] section for this device, Asterisk starts sending packets to the device, keeping the NAT connection open. You will also be able to see some timing for packets between Asterisk and the phone when you do “sip show peers” at the CLI.

Now, when Asterisk wants to place a call to the phone, the NAT welcomes the packets and forwards them happily to your phone.

Conclusion: If Asterisk is on a public IP address and your phone is on the inside of a NAT device, we need to keep the NAT connection open by frequently sending dummy packets between the devices. This will keep the connection open for incoming calls.

What can STUN do for me?
STUN, Simple Traversal of UDP over NAT devices, is a *discovery* protocol. With STUN, the phone on the inside of the NAT device can send discovery packets to a STUN server, trying to figure out how the NAT device works. NAT devices can work in many ways, and there are evil ones that will not let phone calls go through, regardless of what you do. STUN-enabled phones will discover those.

STUN tells the phone, among other things, what IP address the NAT device is using on the outside. When the phone then signals to the SIP proxy/server, it sends the proper IP address, not the private IP address used on the inside. With a proper implementation, you don’t need nat=yes for STUN- enabled phones. The data sent to Asterisk will be correct.

And UPNP, will that help?
UPNP, Universal Plug’n’play, is another solution. It’s a protocol that the phone can use to communicate with the NAT device, allocating ports and getting a proper configuration. With UPNP enabled phones and NAT devices, your Asterisk server doesn’t need nat=yes.
Asterisk on the INSIDE of a NAT device
If you have Asterisk on the INSIDE of a NAT device, trying to communicate with a SIP proxy (like Free World Dialup) on the outside or having phones on the outside, you’re in another ball game.

Check the sip.conf.sample in the Asterisk configs directory for the externalip and localnet settings, that tells Asterisk what the outside IP address is. And yes, we could use a STUN client in Asterisk so that Asterisk could figure out what to do. Any coders? You’re wanted. If you have phones on the outside, port forwarding is your best friend. As you can imagine, this is not an easy task. Check the wiki for help.
Outbound SIP proxy – what is that?
An outbound SIP proxy is a SIP proxy in the same sense as you can configure a web proxy on the edge of your LAN, handling all web traffic between your LAN and the outside world. An outbound SIP proxy would take care of all SIP messages between your LAN and the outside world, the Internet. This proxy could also handle conversion of IP addresses, and assist the firewall in opening and closing RTP/RTCP ports to let the call go through.

The Intertex IX66 works like this, and there are ways to configure the SIP Express Router to be part of the Firewall DMZ, handling the SIP messaging and working with an RTP proxy to handle the audio.

Currently, there’s no support in Asterisk for an outbound SIP proxy. I am working on it, but need some help. Check chan_sip2 in the bug tracker.

Summary: NAT – It’s a big mess, and it ain’t easy
SIP and NAT is not an easy topic, since there are so many different NAT devices out there. It’s getting easier with SIP devices detecting type of NAT with STUN, delivering correct and useful data to the SIP proxy.

There’s also a lot of topics I haven’t covered in this short essay, like handling the media path (canreinvite=no for devices on the inside of a NAT), RTP proxies and Session Border Controllers. We’ll come back to that later, possibly when we document all of this in the Asterisk handbook.

Read more:

Voip-info.org: NAT and VOIP
Voip-info.org: Asterisk, SIP and NAT
Voip-info.org: Asterisk NAT=yes documentation (sip.conf)

What’s the difference between SIP and IAX2?
While SIP is a protocol that is being developed, but not yet standardized, in the IETF, IAX2 is more of a proprietary development that is created for Asterisk to Asterisk communication. Nowadays, there are many soft phones created using the IAX2 protocol as well as ATA devices, like Digium’s IAXY.

IAX2 uses one port for signalling and audio. If the “client” is on the inside of a NAT device, it registers and then keeps the connection open with keep-alives. This way, calls can be placed in both directions.

IAX2 doesn’t use dynamically allocated ports for audio like SIP, thus making it much easier to traverse NAT devices and to configure Firewalls to support IP telephony.

Category: Technology / Tags: , , , ,

The Need for PKI (Business Issues)

August 10, 2002 / / No comments

In today’s fast-paced and expanding world of internet commerce and communications there has developed a necessity for increased security.

This has created the need for digital signatures and encryption of documents. Implementation of PKI will allow for the verification and authentication of people and documents, as well as providing avenues for secure communications over networks.

This dramatically reduces the threats of fraud and attacks against first line security defenses such as reusable passwords. With the increasing proliferation of password protected applications and the dissemination of passwords among the user community, utilization of the PKI dramatically decreases the vulnerability of computer systems to attacks and attempts at “hacking”.

The prospect of a successful attack, in an effort to thwart security measures that are currently in place is significantly reduced in a managed PKI environment To remain a leader in IT development and competitive in the marketplace, we must embrace state-of the-art-practices and technology.

E-commerce requires confidentiality of sensitive information and authentication of authorized users. A managed Public Key Infrastructure (PKI) will deliver these capabilities along with flexibility to fit with existing policies and practices.

[ad]

Category: Security / Tags: ,
« Older Entries   Recent Entries »
Wordpress Theme by ThemeZee