PhoneBoy’s Security Theater

Back when I worked for the Nokia TAC support Check Point Security Gateways, I actually ran a Nokia appliance as the headend for my network. One could call it "keeping my skills sharp for my daily work." For a variety of reasons, I discontinued this practice and instead opted for more traditional home routers that I could install DD-WRT on.

When I started working for Check Point, I alternated between either running a DD-WRT router or using a UTM-1 EDGE appliance. When Check Point announced the SG80 (and later the 1100 series appliance), I moved to using those. 

And while I probably could continue to use the 1100 series appliance for some time, I finally got my hands on a 2200 Appliance and decided that it should be the headend to my home Internet connection. I wanted to be able to use all the latest Check Point features and get my hands a bit dirtier than I have in a while. What better way to do that than with my family, which is very good at generating lots of real-world, Internet-bound traffic :)

DHCP and DNS Server on the Gateway

Every gateway I've used in the last several years had a DHCP server. In most cases, it also included a DNS server. Gaia does have a built-in DHCP server, and should you use it, should make sure to configure your rulebase to permit the traffic correctly as described in sk98839.

That said, it's not currently possible to make the Gaia DHCP server authoritative for a given subnet without manually hacking the dhcpd.conf file (see sk92436 and sk101525). I did this, which worked.

I still wanted a local DNS server too where I could define local DNS entries for items on my subnet. I could have easily used dnsmasq on one of the many DD-WRT routers I still have on my network as WiFi access points, but I wanted it on the Security Gateway, just like I had it on my 1100, UTM-1 EDGE, and others. I poked around a bit on my Gaia R77.20 installation and discovered that it too had dnsmasq.

I want to be clear: dnsmasq is not formally supported on Gaia. That said, it appears to work quite nicely. The configuration file /etc/dnsmasq.conf is not managed through Gaia and, as far as I know, it should survive upgrades and the like and not be affected by anything you do in Gaia, except maybe enable the DHCP server in Gaia, which obviously do you don't want to do if you're going to use dnsmasq for this.

The dnsmasq in Gaia appears to take most of the common configuration options, so I set about configuring it as described in the dnsmasq documentation. Starting it up is pretty simple: a service dnsmasq start from Expert mode gets it going.

But, of course, that only works until the next reboot. Now I could have hacked /etc/rc.local or something like that, but I know how to make Gaia's configuration system actually start this process for me, monitor it, and restart it if it dies.  

[Expert@animal:0]# dbset process:dnsmasq t
[Expert@animal:0]# dbset process:dnsmasq:path /usr/sbin
[Expert@animal:0]# dbset process:dnsmasq:runlevel 3
[Expert@animal:0]# dbset :save

I guess all those years of supporting IPSO paid off :) If you want to turn off dnsmasq in the future, issue the following commands from Expert mode:

[Expert@animal:0]# dbset process:dnsmasq
[Expert@animal:0]# dbset :save

One other thing you might want to do if you're running a local DNS server is have your Security Gateway actually use it. The problem is: dhclient (which obtains settings from a DHCP server) actually overwrites the configuration in Gaia for the DNS domain and the DNS servers to use. You should be able to prevent this by changing the /etc/dhclient.conf configuration file not to use this information.

Specifically, it means changing this line:

request ntp-servers, subnet-mask, host-name, routers, domain-name-servers, domain-name;

to this:

request ntp-servers, subnet-mask, host-name, routers;

DHCP and the Default Route on the Internet Interface

When I put the 2200 in my network, I noticed that Gaia was not accepting the default route from Comcast's DHCP server. To get my home network oeprational, I manually set the default route to my Internet-facing interface, which seemed to work for a time.

One persistent issue I was having, that I initially was unable to figure out, was that it would take some time in order for sites to load. I wasn't quite sure why, but it was only happening occasionally and not something I could easily track down. I ignored it for a couple of weeks, but last night the problem really came to a head.

I thought Comcast was having a problem. I even went so far as to call Comcast and they said there was some signal problem on their end. The problem still persisted. The only thing "different" was that we had visitors who brought a laptop with him and was playing League of Legends with my son.

I tried a number of things, and couldn't figure out what was going on. I did start seeing some peculiar traffic on my external interface, and decided on a fluke to check my arp table. Rather than the 20-30 entries I'm used to seeing, I was seeing over 700 entries. For IPs on the Internet. That didn't look right. And sure enough, I was seeing arp whois requests for Internet IPs coming from my gateway.

Arping for every IP you access on the Internet is not terribly efficient. Comcast was, understandably, not responding to these ARP requests quickly, though they eventually did. Furthermore, due to the transient nature of ARP entries, they were timing out every minute or so, which meant that as long as I was actively passing traffic, connections to websites worked great. When I stopped and reconnected? It would take forever to connect.

Which brings me back to the original problem I had: getting Gaia to take a default route from a DHCP server. Turns out, there's an option in Gaia called "kernel routes" that you need to enable to make this work, and enabling it is pretty straightforward. If I had search SecureKnowledge earlier, I probably could have saved myself learning (and documenting) this lesson. It is documented in sk95869.

Now the Internet at home is working great once  No delays in loading websites at all. At least ones caused by configuration errors on my part :)

Dynamic IP Gateway Security Policy

One of the challenges of using a Dynamic IP Gateway is that you don't know what the external IP is of your security gateway. Not knowing it could make it difficult to, say, make "port forwarding" rules or rules that relate to allowing traffic to the Security Gateway itself.

Turns out this is not an issue. When you check a gateway object as Dynamic IP as shown below, two Dynamic Objects come into play: LocalMachine (which always resolves to your gateway's external IP address) and LocalMachine_All_Interfaces which resolves to all of the IP addresses associated with your gateway. These dynamic objects are simply placeholder objects that get their actual definition updated on the local gateway. For these two objects in particular, this happens periodically without any action on the administrator's part.

Dynamic Objects have a couple of important limitations. Rules using Dynamic Objects must be installed on a specific installation target, i.e. you cannot simply leave the Install On field for the rule the default Policy Targets. Not doing so will cause a policy compilation error. The second issue is that rules with Dynamic Objects disable SecureXL termplates at that rule. This isn't a huge deal as I'm coming nowhere near the capacity of my 2200, and most of my traffic is hitting rules with acceleration, but it is a consideration you must make when constructing your rulebase. 

Another important limitation: Identity Awareness is not supported on Security Gateways that have a Dynamic IP. I do not believe this is an issue on the 600/1100 appliances, but it is for the 2200 and up. 

Final Thoughts

It's been a while since I posted something technical on my own blog about using Check Point. My role is such that I'm not always involved in the technical side of things like I was back when I wasn't quite Internet famous :)

In any case, it may be something I'll do again in the future. I'm sure that pieces of this article will also show up in SecureKnowledge--the supported parts of the above at least.

And, of course, these are my own thoughts and experiences. Corrections and feedback are welcome.

Ok, this is a completely shameless plug for my employer. But it's really big. And really small at the same time. And my take on it, which wasn't cleared with the marketing folks, and thus my, albeit biased, opinion.

The Check Point 600 Appliance, which was announced today at Interop, represents Check Point's refreshed entry into the SMB Security space. It provides the same security functionality you'd find in Check Point's larger appliances in something that fits into an SMB--both in terms of form factor and price. This includes Check Point's award-winning IPS, App Control, URL Filtering, Anti-Virus, Anti-Spam, VPN, oh and don't forget the firewall :)

If you're familiar with the SG80, which Check Point launched a couple years back, the new 600 Appliance looks a bit like that, though the internals are slightly different from the SG80. There are standard USB ports, Express Card and SD-card slots in the 600 as well as optional WiFi and ADSL ports. It also includes a revamped Web Interface that incorporates functionality from the UTM-1 EDGE and Safe@ appliances allowing full management of the security policy across all Software Blades.

Under the hood? It's nearly the same code that runs in the larger Check Point appliances--Check Point R75.20 running Embedded Gaia, to be exact. When you SSH or serial console into the appliance, you are presented with clish, which functions similar to how it does on one of the larger appliances. You can also drop into Expert mode for more advanced debugging, which again, works very similar to how its done on the larger gateways. 

The main differences between the 600 and the Check Point 1100 Appliance, which was announced a few weeks ago are:

• Lower price: List price of a 600 is roughly $200 cheaper than the comparable 1100 model.
• Chassis color: Bright orange, like the old Safe@ boxes.
• Central Management: While the 1100 can be centrally managed with standard R75.46 or R76 management (standalone or Provider-1), the 600 can only be centrally managed by Check Point Cloud-Managed Security service.

In any case, I am truly excited about this as finally, SMBs can finally get the same Enterprise-grade security that the Fortune 100 relies on for a fraction of the cost--starting at $399.

Check Point's SMB Portal has information about the new appliances as well as how to acquire them.

When I was in Israel at the end of 2012, I was talking with the folks putting the finishing touches on the Check Point 2013 Security Report. Of course, since then, the report has been formally released and you can now read it for yourself. Here's a video preview of what you'll find in it:

Some of the data gathered for this report was related to the 3D Security Reports Check Point generated for customers during 2012 where we took a Security Gateway and either ran it in-line (in bridge mode) or plugged it into a mirror port on a customer's switch. It's worth pointing out that, in many cases, a competitive security solution was already in place and the Check Point Security Gateways were seeing stuff the other solutions were missing.

Other data for this report also came from SensorNet, ThreatCloud, and results from our Endpoint Security Best Practices Report, which is a great way to find out if your Windows PC is configured according to our Best Practices.

The most surprising statistics?

• 63% of the organizations surveyed had at least one malicious bot in their network. 
• 43% of the organizations surveyed had traffic to/from an anonymizer service.

Of course, if you're knee deep in the security space, 0% of this is news to you.

In a previous post, I asked if we could trust no one in Information Security. The reality is that, at some point, we have to trust. We have to trust that we have the right policy in place. We have to trust our people to do the right thing. We have to trust our tools will do their job.

Of course, we should not blindly trust. We need to evaluate that our tools are doing their job, keeping the bad stuff out and enforcing the policy you've specified. We need to trust that our people are doing the right thing. Your tools are both enforcing the policy and educating the users about what the policy is, right? And, of course, you need to evaluate the policy to ensure it is both effective and in-line with business objectives.

If Information Security professionals spend all their time doubting everything, not only will they drive themselves crazy, but the real threats will get by.

Along these lines, The marketing folks at Check Point put together a video discussing trust and its very important role in Information Security.

The implementation details will vary depending on the attack target and the request type, but the basic concept of a denial of service is to overwhelm a target with a seemingly legitimate series of requests so that real requests are ignored and not processed. If the attack is launched from multiple points on the network, it is referred to as a distributed denial of service attack (a.k.a. DDoS).

I remember when I first started hearing about denial of service issues more than 10 years ago. I even played with a few tools to generate them on my own--in my own network, of course. Back then, defenses for this sort of thing simply didn't exist. Aiming a tool at a helpless server protected by an even more helpless firewall was a great way to wreak havoc.

In general, there are two ways to create a Denial of Service condition:

• Cause the relevant service to crash. This is actually pretty difficult to do in a simple fashion given the resiliency of most public-facing services, though for lesser-used services, it can happen.
• Resource exhaustion, where some resource needed to provide the service (bandwidth, buffers, etc) is depleted in a way that causes the service to not respond to legitimate requests.

Over the years, every part of the service stack has gotten more resilient against the most basic form of these attacks. For example, a simple SYN flood won't take down most web servers these days as web servers are smart enough not to allocate resources to a connection until the three-way handshake completes. That said, if you can get a few million of your closest friends to run Low Orbit Ion Cannon at a server, or visit a particular webpage, you can still take down a target.

To give you a real-world example of this, I'll talk briefly about a recent denial of service someone brought to Check Point's attention via a Pastebin posting. The attack, ironically, was not all that different from the first SYN floods I played with more than a decade ago.

According to the report on Pastebin, the security researcher was able to essentially cause a Check Point Security Gateway to stop processing packets by sending ~120k packets per second. That's easy to generate inside a VMware environment, or even on an isolated network segment. Over an Internet link? Depends on the size of the pipe.

Regardless of how realistic that particular incoming packet rate may be in a given environment, what happens when the gateway sees that much traffic? In many cases, it simply runs out of memory, causing traffic to be dropped. It also runs out of processor capacity to forward said traffic.

Since the only way to truly stop a denial of service attack is to disconnect from the Internet, your best hope is that the various components are optimally configured to operate in potential denial of service conditions. Check Point's official response to this issue mentions four specific configuration changes that can be made to their security gateways:

1. Implementing the IPS protection "SYN Attack" feature in SYN cookie mode, which will reduce the memory footprint caused by these bogus connection attempts.
2. A hotfix for SPLAT/GAiA systems that, along other things, optimizes how the SYN+ACK packets that come back from the server are processed (IPSO does not require this).
3. Where applicable, use multiqueue to increase the number of processors that can handle traffic on a given interface.
4. Increasing the receive buffers on the interface.

If you're a (potential) Check Point customer, you've likely heard of our 3D Security Analysis Report. The idea is to take real traffic from your network off a span port, and run it through our Security Gateway to see what is going on in your network. While it is a sales tool, it's certainly an important one as it will instantly demonstrate the value of Check Point's solutions based on your own traffic.

Both for fun and to test an upcoming version of our Security Gateway software, I decided to run a 3D Security report against my own network. I took an existing Check Point appliance, loaded up with code, and plugged it into a Mirror Port on my switch. I let it it run for a day or so to collect traffic. In an active business network, you can let it run for as little as an hour or two and see results.

You can see what a full 3D Security report looks like by downloading a sample. I won't share my report, but I will share bits and pieces of it so you can get a sense for the kinds of things it will show you. Specifically, I used IPS, App Control, and URL Filtering as part of my report, though it is possible to include DLP and (soon) Antibot.

There were a couple of surprises here. I thought I had removed Dropbox and Hamachi from all my computers. Apparently not. This will need to get corrected. LogMeIn is in use in my network, so I'm not worried about that. The eMule thing will have to be investigated since I'm pretty sure I'm not running that in my network (my kids aren't either).

In case you're not sure what these apps are, the report provides you with a nice description of all the apps:

Meanwhile, another thing the 3D report tells you is how much bandwidth the various apps are using:

I've used quite a bit of bandwidth over the last 24 hours or so! A third of it is SSL traffic, so I can't see inside it all (though I could if I deployed my gateway inline and added my CA certificate to my family PCs). Note not all of this is Internet-bound traffic, but still 2 GB in 24 hours is quite a lot, especially when you consider Comcast's 250GB cap!

The report provides a breakdown as well (note this is a partial list):

Finally, while there wasn't much going on from an IPS point of view, the blade did detect a couple of anomalies, which are provided along with the relevant remediation:

While the customer response to these reports has been generally positive, they are also end up being quite an eye-opener as you see things you never knew were going on. Even I am surprised at what I'm seeing in my own home network! Imagine what you'll find in your network.

By now I'm sure you've seen, heard, or read Check Point's official announcements made at NASDAQ this morning. This is by no means a regurgitation of the official press releases, but it is my own personal take on what was announced. If you want to see the announcement for yourself, check out the recording!

(Just to be clear, I work for Check Point and these are my own thoughts.)

Check Point R75.20

This release (press release, download) brings a number of new features. One of the most anticipated ones is the ability to inspect outgoing SSL traffic. Not just for Application Control, where it is most needed given the proliferation of sites requiring SSL, but in all the various software blades we support. And its included as part of the relevant software blades license (i.e. it's not a separate charge).

SSL inspection is done by essentially doing a "man in the middle" on the traffic. The gateway dynamically generates a certificate for the destination website, which is presented to the client when they connect. This allows the Security Gateway to see the traffic "in the clear" and make the relevant security decisions. The connection is encrypted as it leaves the gateway with SSL. Since SSL inspection is more intensive than inspecting HTTP traffic, and potentially creates potential regulatory issues by its use, you will have granular controls as to when this feature is invoked.

Another new feature in R75.20 is a completely revamped URL Filtering blade. While Check Point is still selling this as a separate product, it is actually integrated with Application Control. Applications and URL Filtering categories are given equal billing in the now combined Application Control and URL Filtering rulebase. You can do user-level URL filtering (with Identity Awareness) and can take advantage of our UserCheck technology to inform users of the policies. We can also handle HTTPS websites and custom categories. The categories themselves have also been substantially updated.

Unlike with previous versions of URL Filtering, where the entire URL filtering database was stored locally on the Security Gateway, the new engine makes use of the cloud. Commonly accessed URLs and their categories are stored in a local cache on the gateway. Over 99% of your web traffic should be met by the local cache on your gateway. When someone accesses a URL not in the local cache, the URL Filtering database in the cloud is consulted, with the result being stored in the local cache for future use.

The Data Loss Prevention (DLP) blade also gets a substantial update in R75.20. HTTP performance is substantially improved in this release and you also gain the ability to examine HTTPS traffic as well. A large number of additional "out of the box" datatypes are now included. We also integrate with an internal Microsoft Exchange server so DLP can be performed on internal email as well as email leaving the organization.

SecurityPower

A common complaint I've heard from Check Point customers over the years is that the performance numbers we quote for our appliances don't reflect what performance you'll get in the real world with real world traffic patterns. This is because performance numbers have been historically quoted for a single firewall rule (any any any accept) with the most optimal traffic pattern (1500 byte UDP packets). To be fair, this has been the standard industry practice for some time now. Every vendor of network equipment performs tests like this.

Unfortunately, this isn't a good indicator of how an appliance will perform under real world conditions. With that in mind, Check Point has developed a new testing methodology for its appliances using a real rulebase (100 rules) with real-world traffic patterns (both based on industry standards and actual patterns seen at Check Point customer installations). This rulebase and traffic pattern exercises all of the various features and functionalities available in our Security Gateway. Based on those tests, Check Point has rated each appliance with a SecurityPower Unit rating (SPU).

One could call the SPU an arbitrary metric. What it gives you is a relatively simple way to compare appliances and the relative security load they can handle. More importantly, an SPU can be generated for a given set of requirements (required blades, throughput, number of connections, and so on). You can then compare that against the available appliances to ensure you choose the right security appliance for the right security task.

Check Point has developed a tool that does exactly this. It will be available shortly. Personally, I think this is a big deal.

New Appliances

Two new appliances are being launched today for the data center: the 21400 (press release, product page) and the 61000 (press release, product page). These appliances are aimed squarely at the data center, where tens or even hundreds of megabits gigabits per second of throughput are needed!

The 21400 is a powerful 2U platform that features massive port density (up to 37 1000-base-T ports, 36 1000-base-F SFP ports, or 12 10GBase-F SFP+ ports), 50 GB of firewall throughput, 21GB of IPS throughput, hot-swappable redundant power supplies and disk drives, and an optional Lights-out Management card. Everything you'd expect from a carrier-grade chassis. The appliance runs both R71 and R75 with SecurePlatform.

The 61000 series, on the other hand, is a monster appliance! It's a 14U (DC) or 15U (AC) bladed chassis that, when fully loaded, will support 200GB of firewall throughput today and, with future hardware and software enhancements, will support over 1TB of throughput in the future! Aside from all of the various connectivity and redundancy options, the appliance acts as a single platform that, when new hardware blades are added, automatically configures itself to distribute the load between the blades! The platform currently runs a 64bit version of SecurePlatform based on R75.

Both appliances, which are referred to as Data Center Appliances, are available now on the Check Point pricelist.

From ZoneAlarm’s Newest Security Solution: SocialGuard:

SocialGuard, ZoneAlarm’s newest security solution, promises a groundbreaking new method of monitoring and preventing safety breaches on Facebook the most popular social networking site by a mile, with over 500 million users without “friending” your child and intruding on his/her social space. SocialGuard sends real-time alerts to parents via email–or the SocialGuard interface–whenever suspicious activity is detected on your child’s profile; parents can customize security settings and keywords to trigger such messages if the child is exposed to illicit or inappropriate content. SocialGuard monitors children’s Facebook accounts for threats including cyberbullying, age fraud ensures children are not befriended by adults outside of their network; friend requests, hacked accounts, and link safety flags dangerous/offensive links contained in messages.

The product, available now, can be purchased here.

Check Point, my employer, is behind this. I've used the betas of this product and they do precisely what they say without being a huge burden on you or your computer. The price: $1.99 a month or $19.99 a year, makes this a no-brainer if you have kids using Facebook!

See what Check Point's Head of Consumer Business has to say about SocialGuard.

From Reality Check - Features - Malware - Computer Business Review:

"The industry needs to change a little bit," [Check Point Software Technologies CEO Gil Shwed] says. "Our software blade architecture is the right direction but it's not enough. I think the real change is actually understanding that security is not a bunch of technologies that people need to deploy but understanding that it needs to be treated like a business process. It starts with the well-defined policy of what a company wants to achieve and what is allowed or not allowed, continues with educating - or not educating but involving the users - and the enforcement side is only the last part of it.

"Most of our customers have a lot of check lists but not one clear policy. Everybody is trying to keep the users aside from that, but if users are not aware of their expected behaviour they become the weakest link in security. Then it goes to enforcement, which needs to apply these principles. We've just launched 3D Security that has three elements - policy, people and enforcement - and I think that would be a major change in people's mindset when they think about security.

While Check Point certainly has some great security technology--I should know, I work there--if it's not applied according to a process and policy with defined business goals, the result will be less than satisfying. I've seen it again and again in my work over the years.

On the two Check Point user community sites CPUG and CPshared, I made a couple of interesting observations today:

• CPshared already had more active threads today than CPUG. This includes all the public boards, which I verified by loading up both sites in Google Chrome's "Incognito Mode" to ensure I wasn't logged in.
• The number of Check Point employees already participating on CPshared is far more than I've ever noticed on CPUG in the past two years.

Keep in mind that the CPUG forums have been around since August 2005. CPshared was only "officially" announced last week--it had been privately tested for about 4 weeks before that.

Again, these are just observations. They may be completely meaningless. You can come to your own conclusions here.