Tuesday, September 29, 2015

Stateful Inspection, who invented it, really?

In my first Check Point video nugget one of the questions is about inventors of Stateful Inspection.

I thought it was a simple one. Surprisingly, I have received some unexpected answers. Most of them were about Nir Zuk being the actual inventor. That made me thinking, what if I myself was mistaken, and the guy actually did that? So I have started researching this.

Here are some results.

I was actually right. Patent rights to Stateful Inspection belong to Check Point and Gil Shwed, according to US patent 5,606,668. The patent application was filed in 1993.

So, what about Nir then?

Well, here it is quite interesting. Nir Zuk does not hesitate crediting himself for developing Stateful Inspection.

Here is the quote from Palo Alto web site: "Nir was... a principal engineer at Check Point Software Technologies, and was one of the developers of stateful inspection technology."

It is very accurate, isn't it? "One of the developers..." Of course he was, he worked with Check Point from 1994 till 1999. He could not possible invent it, considering half a year gap between filing the patent application and his start in Check Point.

Should not confuse us much, right? It must be something else.

In Nir's interview to IT World in April 2010 when talking about his Check Point years he says:  "We invented a technology called stateful inspection, on which all network security technology today is based." This is a bigger statement, but again, if by "we" he means "we, Check Point", there is probably nothing wrong there.

The article itself is peculiar. There he also claims he single-handedly developed Floodgate product in 1999 and then was practically pushed out of the company by Israeli developers for doing so. I will not comment on that, as we are discussing Stateful Inspection topic only.

There is one more article from 2008 published by InformationWeek. The title is very promising: "Who invented the firewall".

Believe it or not, the very first sentence credits Nir Zuk. It says: "Nir Zuk says he developed the technology used in all firewalls today." The article is brilliant, it its own way.

The author, Kelly J. Higgins is apparently not fluent with FW technical terms. I would not blame her much, although her attempt to crack the case does not deserve full marks, in my humble opinion. She quotes one of the experts in the article though, saying: "Zuk was the father of the stateful firewall product at Check Point…"

Funny, Check Point is only mentioned in the article if if referenced to Nir Zuk. Here is another example: "Meanwhile, Zuk, who helped build Check Point's firewall technology, isn't shy about taking credit for the first commercial firewall."

If I would read this without any background, it would be clear to me: Nir does it all. He is the father, developer, inventor and, finally, helper. All praise Nir.

Well, the whole story is a very good example of bold PR (If you have ever seen Palo Alto marketing presentation, you know what I am referring to) and inaccurate journalism.

Nir Zuk was one of the developers, all right. The rest is just noise on the channel.

If you have spotted anything inaccurate this, please let me know. It might be possible (although unlikely) I am still missing some parts of this puzzle.  





Sunday, September 27, 2015

Firewall Basics: Part two - the nugget is live

Hi again.

I have just uploaded the second nugget from the Firewall Basics series. Check it out.


The trivia question in this one is a bit trickier. I will be waiting your answers till 11.10.2015.

I have received a lot of requests and suggesting for future series. It will take me some time to address most of them. Thanks a lot for your support, interest and understanding.

I have also received some negative marks on youtube. That is okay, my work is not perfect. But it would help if you could specify what particularly you did not like. This kind of feedback will help me to do a better job the next time.

Thanks and see you soon.

Sunday, September 20, 2015

The very first nugget is published

Hi all, I have just uploaded the first nugget: "FW basics: Part one" to my youtube channel.



In FW basics series we are talking about fw principles and fundamental concepts: fw kernel placement, stateful inspection, kernel tables, enforcement principles, components of Check Point security systems.

Once the foundation is set, we will talk about troubleshooting in particular. It does not seem to be feasible to replace in class troubleshooting course by these video fragments, but my goal is to provide clear and simple explanation of the things that would help one to understand Check Point environment better. With such understanding troubleshooting becomes easier and less stressful.

I hope you like the video. Please send me your answers for trivia before the next nugget is published.

Thanks for your comments and support.

Thursday, September 17, 2015

Introducing Check Point video nuggets

Hi all!

I have decided to start a new project on Youtube: Check Point Video Nuggets.

I am going to take some bits and pieces out of my custom courses: 
  • Troubleshooting, 
  • Optimisation and 
  • Best Practices, 
and to convert them into short videos explaining different aspects of firewalling with Check Point.

The crude video below is the start.


If you are interested in something particular, if you have any suggestion or want to support the project, please contact me here or via email (in the video).

Thank you for watching. Stay tuned.
















Monday, August 24, 2015

High End Check Point appliances, digging further

In my previous post I have asked you about origin of Check Point 61K and 41K chassis. Before continuing this discussion please let me explain why I am digging into this.

The main reason is that Check Point does not provide enough information about the hardware specs of the appliances. Customers apparently should be happy just with security power indicator. Basically Check Point tells us: trust our sizing tool, we will present you with the right box for your throughput and particular combination of your security features.

This does not work 100%, there are always issues with border customer cases, wrongly assessed requirements and missed functionality.

Treating appliances as black boxes does not help to built the trust. How do we know if the box is powerful as announced? With high-end boxes there are even more bottleneck that with regular appliances. Thus more questions.

The second reason is about my personal preferences. As an engineer I like taking things apart to see what is inside. Design and capabilities: these are the points I want to be sure about.

If you seem this too much, it is okay, you can stop reading here and get back to your own toys. If you are with me, I want to share some of the findings.

------- read below this line if you are still interested -------

In the comments of the previous post someone has put a link to ASIS, a company with less than 200 employees, according to its LinkedIn profile. The company has two addresses in Israel and USA. US address apparently belongs to a small sales office.

According to my anonymous reader,  this company is producing the chassis for Check Point. Indeed, their Perform 140 and Perform 60 chassis look very similar to 61K and 41K, without SSM and SGM blades.


Now, what about the blades?

I did not find anything that would look like SGM or SSM on Asis web site.

So far I am assuming Check Point is using Advantech MIC-5333 or MIC-5332 ATCA modules as SGM blades.



Unfortunately, I did not found the Switch modules (SSM) on Advantech site. Advantech only lists a single Switch Module for ATCA, ATCA-9112, which looks a bit different than the switch blades used on 61K or 41K.

Strangely, on marketing photos of Advantech ATCAs that I have already cited in the previous post, switch modules look exactly as Check Point ones, except for the colour, although it is listed as ATCA-9112. Could be that these marketing photos were done with older modification of the blade. So far I continue searching for the definitive proof.

If you have any further information to share, please do so. On my side, I will keep you posted about news for the matter.




Thursday, August 20, 2015

Who is making Check Point High End chassis?

The full name of Check Point includes Software Technologies in the title. It hints that Check Point does not produce its own appliances. And who does for that matter?

One question is bothering me for years now: who is making Check Point 61K and 41K chassis? I have never got a straight answer on it from CP itself, not even a hint.

But just for sake of argument, take a look onto Advantech Advanced TCA boxes:



Do they look almost like 61000 and 41000 from Check Point to you?

Granted, it is not 100% match. The smaller chassis even have 41K composition up side down. Could it be that Advantech is producing custom HW for Check Point? Or could it be that Check Point uses just some of the components such as frames and fan blocks, but the blades are done somewhere else?

I wish I know the answer to this.

What do you think? What do you know?

Friday, August 7, 2015

Renaming global objects cause CMA migration to fail

I have recently discovered rather unfortunate situation with Multi-Domain Security Management servers. If you have ever renamed any of the global objects in the global policies, you cannot migrate CMAs anymore.

This sounds strange, but it is the fact. With R77.x cma_migrate script will fail on the target machine if at least one of the global objects was ever renamed.

Check Point has a rather vague SK article about it, and the only proposed solution is to request a hotfix. Mind this article is only referring to R77.10 version, although the issue is present on R77.20 and potentially on R77.30.

It seems cma_migrate is running re-upgrade verifications and fails if gdb_rename table is not empty.

I can only guess if it was done intentionally or not, but there is a history of other issues with renaming global objects on MDSM.

For example, with R75.40 it was impossible to rename a global object, unless a particular system variable was changed (SK82380). One more know issue was about upgrading R76 MDS to R77.10 
(SK98793).

Considering all above, the only recommendation is: do not rename global objects to avoid any of the described issues.