Posts Tagged ‘Firewall’

Choose the Next-Generation Enterprise Network Firewalls

Sunday, April 10th, 2011

Network firewall has been one indispensable layer of defense to external attacks and regulatory requirement for many companies. With many competitive vendors on the market, next-generation firewalls have been a buzz word in a red-hot war for the market. But what does exactly the next-generation firewall mean for the customers? And are you choosing the future winner who will survive the war and not having to migrate to another vendor in the future?

Checkpoint may be the first one to officially use “NG” as the product name, the used NGX (Next-Generation Extension) for recent product line. After popular firewall platform Netscreen was acquired by Juniper as a strategy of integrating Netscreen firewall engine into JUNOS routing platform, Nir Zuk founded PaloAlto to start another line of firewall product with the similar architecture of Netscreen firewall engine, and has been intensively marketing PaloAlto as the next-generation firewalls.

To win the war on the next-generation firewall campaign, Nir had a very interesting debate with Mike Rothman recently. Nir defined the next-generation firewall as the application-aware network firewall, which can recognize the application specific traffic and ability of the deep application layer (layer-7) inspection for policy control and anti-virus purpose, while Mike challenged the some aspects of it on the hardware capacity and configuration issue.

No matter what the next-generation of firewalls the vendors are selling for, it will be very important for the customers to do comparative testing and have hands-on experience on the following key areas for the long-term firewall deployment.

1. Firewall policy implementation and maintenance requirement

The most resource intensive effort for enterprise firewalls support is the policy implementation and rule life-cycle maintenance due to the pure number of firewall rules and changing nature of the network environment. Firewall rules should be easy to define and understand with central management capability. Checkpoint management suite and client GUI so far is still the best GUI on the market so far, unfortunately CLI users will be disappointed that Checkpoint does not support command line loading of policy rules, which I sometimes feel is so much inconvenient for rule processing.

2. Consider migration requirement and cost for the legacy firewalls

As firewall technologies evolve, it is un-common for companies to move from one firewall platform to another. One thing does need to check is that firewall software should support sufficient features for the rules migration if you have legacy firewalls. For example, if Netscreen supports nested subgroup, but another platform has not yet supported this feature, it may be better off waiting until the same feature is available in another platform. You cannot image what nuisance this kind of not-so-obvious limitation can cause to the firewall policy rule conversion and maintenance, more importantly, it causes the confusion for the original rule business owners and technical staff supporting original rules.

3. Choose zone-based firewalls verse non-zone-based firewalls

Some firewalls like Checkpoint are not zone-based firewalls because firewall rule does not require interface to be assigned to a security zone for rule construction. On the other hand, Juniper and PaloAlto are based on the similar firewall engine architecture design that requires zone to be defined as one dimension in the firewall rules. This extra dimension may cause the difference that you never expect in a dynamic routing environment. For example, checkpoint rules only concern about the source, destination, and port triplet, routing for the related IPs are not checked unless anti-spoofing is turned on. For Juniper and PaloAlto, traffic for the related IPs has to come from the specified interface zones. If for any reason routing changes the direction, the rules will no longer work, which is different behavior from Checkpoint, so it is important to evaluate company routing environment for deploying zone-based firewalls.

4. Firewall deployment effort and system upgrade

Checkpoint appears requires more steps and effort in deploying and support its current firewall product line (I cannot speak about its newest products), while Juniper and Netscreen is more streamlined in term of deployment and software upgrade.

5. Firewall vendor future development strategy and sustainability

Make sure which direction firewall vendors are going for their firewall product, you do not want to deploy something that will be end-of-service or end-of-life and have to migrate to another product or vendor. Also need to be aware of technical support arrangement and typical software upgrade release cycle.

Because all layers of traffic data (including application layer) can be inspected by the firewall, it is always feasible to integrate defense mechanism such as anti-virus, anti-malware, routing ACL, web defense, application vulnerability detection, and even IDS/IPS in the firewall appliance. Many vendors have tried one-way or other, noticeably Checkpoint’s SmartDenfense and Web Intelligence, Juniper’s intention to collapse routing with firewall, and PaloAlto’s feature of single-pass detection of virus and application-aware policy control. The question is not whether they can do it, but how well they will do it for the added defense features as a firewall platform. That is apparently related to the vendor’s vision of the next-generation of Internet threats from evolving technologies such as web 2.0, mobile computing, cloud computing, and their capability of software implementation on a scalable hardware.

It is never easy to evaluate and choose truly next-generation enterprise firewall due to the constant evolving technology, threat environment, and unique company requirement. However with comparative testing of multiple vendor products for the required functionalities, and matches vendor products future development strategy with company’s future plan, it will reduce the risk of choosing a product that will be a loser of the war of next-generation firewalls, and improve ROI on the firewall deployment and maintenance.

Tags: , , , ,
Posted in Firewall | No Comments »

Checkpoint SPLAT firewall routing software limitations

Saturday, January 15th, 2011

Checkpoint is a well-known vendor for enterprise firewall, one of the popular firewall platforms is its SecurePlatform firewall appliance. Last I was told was that this Linux based firewall appliance will be the only platform that Checkpoint will support, and Solaris based firewalls will be discontinued. If it is indeed the case, I’d hope Checkpoint strengthen its SecurePlatform development, as I know at least two routing software limitation will handicap its deployment, and what concerns me is that these limitations appears not documented anywhere, and customers mostly can only discover them when devices are being deployed.

SecurePlatform firewall appliances have routing software built-in, which is called Advanced Routing Suite software. It is based on open source gated software and customized by Checkpoint. Generally I have a pleasant experience with this routing software. However I discovered that there are following two limitations that surprised me.

First is that this Advanced Routing Suite can only supports up to 25 BGP peers. That is the total peers you can have for all the peering Autonomous Systems (AS). Beyond that BGP configuration loading will lead to an error message, and only 25 BGP peering can be loaded, you have to check which peers get loaded. The limitation appears hard-coded in the software. This limitation may be not that critical for most of the enterprise environment, but you can bet there are some environments that this won’t fly.

The solution to overcome 25 BGP peer limitation is to put some peers into peer-group, however that is where the second software limitation kicks in. The SecurePlatform routing peer-group does not support configuration for “soft-reconfiguration inbound”, which is so important in dynamic routing environment with BGP. The software does not even alert anything when this configuration is applied, it simply silently drops it. You do not even notice it gets dropped unless you verify the loaded routing configuration. I tried to confirm that this setting is the default, but it proved that it is not. Checkpoint has admitted that a REF needs to be opened to address this.

Overall I think SecurePlatform has quite some good features as an enterprise firewall appliance, however if these two limitations are not addressed, it will need to be carefully validated and tested when deploying for the very large BGP routing infrastructure.




Tags: , , , ,
Posted in Firewall | 2 Comments »

How to troubleshoot connection issue on a Checkpoint firewall?

Saturday, November 13th, 2010

Firewall has been widely deployed by companies to protected perimeter with business partner and Internet, including VPN. Firewall denies all connections unless explicitly allowed by the business for the best security.

It’s not unusual that business connection is not working after firewall rules are implemented on the firewall, which causes financial loss and frustration to the business, up to the point that some people even question the benefits of the firewall.

With business transaction being interrupted, it is important to be able to troubleshoot the connection issue methodically and systematically to ensure the timely resolution of the issue. The outcome of the troubleshooting is either proving firewall is not guilty as charged, or acknowledge guilty and rectify the issue accordingly.

This post will be focusing on troubleshooting with Checkpoint platform based on my years’ hands on experience. Troubleshooting with other firewall platform will follow in other posts, but concepts should be the same.

Below are the steps that I typically use to troubleshoot connectivity issue on Checkpoint platform:

1. Collect devices info for the impacted business hosts

First and the most important, it’s critical to get the complete list of IPs for the impacted business hosts. This typically can be provided by business, however there are following caveats to watch out:

  • Hosts may be multi-homed and have multiple interfaces, so what business gives may be just one IP of several interfaces, and that IP may not be the one registered in firewall rules, so ensure to get all interface IPs for the host.
  • Checkpoint host object is object-oriented, meaning that each host object has one IP explicitly registered and visible, but there may be other IPs registered in topology property of the host object, and those IPs are not easily visible unless you click on “topology” tab for the host object. When search the rules, ensure to search for the all the business host interface IPs.
  • Sometimes business can only provide IPs that they think are in the scope, but due to the unique network or application design, it could be that other related device IPs that are having issue, this typically the cases when connections are proxied or NAT is involved. It is helpful to have business provide the information about how the connections are setup to direct the troubleshooting in the right direction.

2. Verify the routing path for the business connection

After business side IP information is collected, next step is to find out if firewall has probability of being guilty, i.e., to find out if firewall is in the routing path of the connection, and if there is firewall in path, find out what firewall to investigate (note that companies typically have many firewalls and complex routing).

This typically can be done using “traceroute” tool from the source host. Actual “traceroute” command differs depending on the OS system. In Unix, it is “traceroute”, in windows, it is “tracert”. There are following caveats to watch out for the traceroute:

  • Traceroute needs to be allowed by the firewalls and routers in path. If host not traceable, or being blocked by in-path firewalls and routers, traceroute output will display “request timed out” messages. In such cases, if there is no related network topology diagram available, one has to jump to the last hop to continue to traceroute until all hops are mapped out.
  • There may be firewall behind firewall for some connections, so ensure to find out how many firewalls are involved in the issue.

Once firewalls in routing path are identified, traceroute should be attempted from firewall to business hosts to ensure there is no asymmetric routing going on, as firewall may drop the connection due to the SmartDefense setting.

3. Verify business host and application is up and reachable

When people complain about firewall issue, it is sometimes in fact the host or application is not up, or not reachable due to routing issue. Checking that host and application is up may save quite some time working on the firewall. If ping and traceroute is allowed outbound, ping and traceroute the host will help speed up identifying the root cause.

4. Check the drop logs to see if traffic is denied

If host and application is up, and routing appears working, also the firewalls are confirmed to be the routing path, next is to focus on the firewall rule. Check the firewall logs are typically the most effective way to find out where the problem is. As checkpoint could store firewall logs locally, or forward to SmartTracker, or any other remote hosts, it is critical to know where the firewall rule logs are stored. Checking the logging property for the firewall object will identify where the logs SHOULD be. Note that sometimes the logs are stored locally due to the connection issue to the remote log server, even though it is set to forward to the remote log server. If logs are not seen on the server where it should be, check the logging connections on the firewall, checkpoint is using tcp port 257 for the logging, so check if the connection for this port is established on the firewall.

The most luck scenario would be that the connection is logged, and it will indicate either the connections are dropped or allowed. If connections are allowed as indicated by the logs, it can be safely say that problem likely lies outside of firewall, otherwise, the drop log should provide the necessary info to add the correct rules for the connection. For example, business may have provided the wrong IP, or wrong service ports, or additional IP and ports are needed in the rules.

If you are under the gun to find out whether the firewall is guilty or not now, as the last resort, temporarily add an allow-all rule to the firewall at the top of firewall rules, and ask business to test. If business still complains, you know that problem is somewhere else (warning: remove allow-all rule quick after the test).

5. Additional troubleshooting tools

So far above procedure should have resolved typically firewall connection issues, however in some cases, the problem may need to dig into how the firewall daemon is behaving on the firewall. These will have to resort to debug tools such as tcpdump to check the traffic packets. Checkpoint also provides utility called “fw monitor” tool and many debug options. Since these tools deserve their own length of explanation, I will cover them in different posts.




Tags: , , ,
Posted in Checkpoint, Firewall | 7 Comments »

What makes the best firewall system?

Sunday, January 3rd, 2010

Enterprise firewall has always been an integral component of enterprise security.   Choosing a good firewall system not only means the best security but also the significant difference in the operation cost and financial impact.

So, if you need to choose, deploy, and support firewalls for your company, or design firewall system, what makes the best firewall system?

I recommend evaluating following ten critical criteria:

  1. Capacity and performance must be sufficient for the enterprise requirement.
  2. System should be scalable.
  3. System security can segregate different roles for operational access.
  4. Ease of viewing and configuring the firewall rules.
  5. System has sufficient alerting and monitoring mechanism critical components.
  6. There is sufficient auditing logging management for the changes made to the rules and system.
  7. Good debugging capability when firewall has issues, both for the system issue or firewall rules issue.
  8. Good backup and restore mechanism.
  9. Centralized management of the firewalls and firewall rules.
  10. Capability to export firewall system info and rules with customizable fields.

One desired feature for a good firewall system is the capability to suggest optimization of the firewall rules when new rules are added.  Firewall rule maintenance is becoming a significant issue as more and more rules are added over the time, optimization of firewall rules as each rule is added will improve the firewall performance and reduce rule maintenance cost.

It is worth mention that there are a wide range of firewall series offered by leading enterprise firewall vendors such as Check Point Software Technologies, Juniper Networks, SonicWALL, Secure Computing (McAfee).  From operational perspective, it is advisable to check out the desired series against the above list, and select the one that is the best for the supporting team’s capacity.   Getting the feedback from the people who had hands-on experience on the product will be especially helpful.

Any expert comment is welcome.




Tags: ,
Posted in Firewall | 164 Comments »