Security Professional's Nightmare

Reportedly, NSA could install backdoors to Juniper devices. Oh my, oh my...

Spiegel reporter really has his fun, quoting:

"When it comes to modern firewalls for corporate computer networks, the world's second largest network equipment manufacturer doesn't skimp on praising its own work. According to Juniper Networks' online PR copy, the company's products are "ideal" for protecting large companies and computing centers from unwanted access from outside. They claim the performance of the company's special computers is "unmatched" and their firewalls are the "best-in-class." Despite these assurances, though, there is one attacker none of these products can fend off -- the United States' National Security Agency."

Do we want CPUGcon?

With Check Point User Group (CPUG), we are used to have not only a valuable place to exchange ideas and experience but also an annual event in Europe, the famous CPUG conference.

Starting from year 2008, CPUGcon was hosted in Chur, Switzerland and then in Munich, Germany. For many years it was, arguably, the most interesting technical event around Check Point security. Unfortunately, the interest to this conference seems to fade.

Year to year, we have less participants. This year in Munich we have reached all times low with only 50 attendees.

I am wondering what's going on. Is it the general interest to Check Point that is in decline? Is it something about administrative and organisational issues around the conference that drive people out? Is it something else?

Do we even want this conference to live on? Do we need it? And if yes, what can be done to get more people and more discussions there?

Three reasons why Check Point DDOS Protector is NOT a Check Point solution

Last year Check Point has added a number of so-called DDOS Protector appliances to its portfolio.

It is not a secret that this solution is in fact OEM of Radware DefensePro appliances, rebranded as Check Point.

There is no fun in stating obvious. It is not only about colours. Check Point's and Radware's security philosophies are essentially different. Here are three reason why I cannot consider box painted blue from the first picture to be a Check Point solution:

1. Security Architecture

In its firewalls Check Point performs inspection before forwarding the traffic. FW kernel is placed in between NICs and IP stack, so in general, traffic cannot be forwarded before a security decision to accept it is being reached*. 

In DefensePro/DDOS Protector solution network module and analysis module are separated. Traffic flows through the box while being analysed. Traffic is only interrupted once analysis module detects an attack. Detection is not immediate, and before anything, connectivity is maintained. 

2. Central management

In Check Point world management is a distinct entity. Although it can coexist with a firewall module in so-called standalone configuration, it is still a separate product. Working with management requires GUI tools. This set: GUI, management and enforcement point is called "three tier infrastructure". This separation helps building flexible centrally managed security systems.

With Radware DDOS solution, management is an integral part of the product in whole. It always is on the box, and to work with it, one uses WebUI instead of a standalone application. With such approach single box deployment is simple and straight forward while having a distributed centrally managed security system might be a challenge.

3. Integration

The only integration DDOS Protector has with Check Point is about logs. One cannot run it as part of centrally managed security system. DDOS Protector lacks built-in mechanism to share its own decision with the rest of the infrastructure and to reuse security decisions made by other parts of Check Point security system. Generally speaking, it has exactly the same level of integration as any other third party OPSEC product.

--------

*Strictly speaking, that is not exactly true for some specific cases of streaming-based inspection. Some IPS features require analysis of application stream and cannot be performed on per packet basis. The difference with Radware here is that packets are still going through FW kernel while being streamed, and thus are subject for FW inline stateful inspection anyway. FW needs not accept the flow through its security rulebase before any further in-depth inspection is performed.

Misleading certificate re-creation error

A customer of mine has to renew VPN certificate signed by VeriSign because it is about to expire.  The normal procedure would be to delete the existing one and to re-create is. The only issue with this is that it takes VeriSign a couple of days to process the request.

He has decided to create a new certificate with the same CA and to add it. Obviously, this does not work. The error is "certificate with the same DN already exists". The customer did not give up. He was trying and trying to use a different DN. The error was exactly the same.

In fact, it is the message which is not correct. According to SK61087, quoting:  

module can have only one certificate signed by a particular CA. Thus, when the new certificate is issued, you will be asked whether to replace any existing certificate signed by the same CA.

In this particular scenario certificate creation fails because there is already another certificate in place from the same CA. GUI error reports an issue which is completely different.

The only way is to delete the existing VeriSign certificate and to re-create it again. If there is a significant delays in the process, do not push policy on that FW till the renewal is fully done.