PhoneBoy’s Security Theater

Intrusion Prevention Systems are designed to detect possible attacks that are occurring over the network and act upon them in some way. They are not unlike firewalls, but they tend to approach the problem a bit differently. Whereas your typical network firewall is a "deny by default" system (i.e. deny all traffic except those which pass certain criteria), an IPS tends to be an "allow all by default" system (i.e. allow all traffic except those things that look dangerous). Also, firewalls tend to be routers to serve as a network choke point, whereas the IPS is a "bump in the wire" looking at all traffic passing through. It is usually deployed in-line with the firewall, either on an ingress or egress point.

Joel Esler, one of the professional services guys for Sourcefire, who sell IPS solutions (Nokia, my employer, is a Sourcefire partner), wrote an interesting blog post decrying the typical practice of deploying the IPS outside the Internet-facing firewall. His basic message: if your Internet-facing firewall is properly configured and your important machines are properly ensconced behind it, you don't need an IPS on the outside of your firewall. The IPS should be placed inside the firewall.

While I agree that IPS is needed inside the external firewall, I think IPS has a useful place outside the firewall as well. It is not always feasible to put everything behind a firewall. For example, it may not be possible/feasible to subnet your external network so you can put stuff behind a firewall. You might be using a service that does not play nice with a firewall. Or any number of other technical or political reasons.

Even if you can manage to get everything behind a stateful inspection firewall, what's looking after the firewall? Sure, a properly configured firewall will deflect anything the Internet is likely to throw at it, but even a properly configured firewall might be susceptible to a security vulnerability.

To throw another viewpoint into the mix, perhaps the place to integrate IPS functionality is right in the firewall itself. Check Point was clearly starting down this road with SmartDefense in the NG AI release of VPN-1. Now in the R70 release of Check Point's Security Gateway product, we have the IPS software blade, which is a full-blown IPS.

The bottom line is that if you're going to use an IPS, you need it everywhere bad stuff could happen--inside or just outside your security parameter. Or on the firewall itself ;)

One of the things that is making this transition to Check Point Software easier is the community of people that support, use, and sell what used to be called Firewall-1, but now goes by a few different names and offers many more functions than just firewalling and VPNs. It's a community I have never really left, having spent the last decade in Nokia's Security Appliance Business, but it's one I was less visible in over the past several years.

Despite being less visible in recent years, I have still been contributing, albeit indirectly. I have been maintaining Nokia's knowledge base, which of course contains many articles that relate to Check Point. I haven't written many Check Point-related articles in recent years, but I do work to make sure that the articles other folks in support write are readable. I also help our team out in various, sundry capacities, with the goal being to get customer issues resolved quickly.

In the course of this work, and my presence on many a social network, I run across the occasional person who thanks me for the contribution I made to the betterment of the Check Point community many years ago. As I re-engage in the community, the accolades have noticeably increased.

Meanwhile, Kellman Meghu, a SE manager for Check Point Software in Canada, recently gave a troubleshooting presentation for CPX 2009 in Las Vegas (CPX, or Check Point Experience, is their annual trade show). In the presentation, he apparently decided to use a picture of me to represent when things got hairy and you needed expert advice from support.

Kellman tweeted the following yesterday:

Used a picture of @PhoneBoy in his presentation. The crowd cheered; no one has forgotten the help he has provided to CP users.

To say I was touched and humbled is an understatement.

So what now? Hard to make any grand plans under the circumstances, but I'm keeping busy. I'm still running the FireWall-1 Gurus mailing list and participating on the CPUG Forums, helping out where I can. It's not much, but until the deal between Nokia and Check Point closes, it's difficult to do much else.

As I write this, I am still a Nokia employee. Yesterday's announcement did not change that, at least until the deal closes sometime in the next three months. Meanwhile, here are a few of the more interesting pieces that appeared online regarding the announcement.

• Check Point to buy Nokia security appliance business (from Reuters)
• Check Point to buy Nokia security appliance business (from Globes [online])
• Check Point Sees Better Product Through Nokia Acquisition (from eWeek Channel Insider)
• Check Point to acquire Nokia's security appliance business (from ThreatChaos)
• Check Point acts on my advice (from Network World)

Andrew Hay and Warren Verbanec, two of my former co-workers, along with Peter Giannoulis and Keli Hay have come together to make the Nokia Firewall, VPN, and IPSO Configuration Guide. These folks have put together a comprehensive tome covering all of Nokia's network security solutions, though the primary focus is on Nokia IPSO and Check Point VPN-1. I also played a small role in this book by writing the foreward for it, as well as helping both Andrew and Warren with various things over the years.

Of course, since the time this book was finished, but before it was printed and bound, and available on amazom.com and other places, Nokia announced it was selling off the Security Appliance business. Even if the boxes have a different name on them, which must happen eventually as result of new ownership, they'll still be the same high-quality systems you've come to know and love from Nokia.

Every once in a while, the part of Nokia I work for announces new stuff. Today, it's a new piece of gear: the Nokia IP1280. Excuse the marketing speak, but I occasionally like to promote the things my part of Nokia is doing. :)

For some reason, I found the phrase "dealt deep layer enterprise security threats another blow" found in the press release announcing the Nokia IP1280 funny. I suppose it does that, since this 2U, quad-core Intel CPU powerhose can handle 24 ports, up to 14 Gbps of throughput with optional ADP modules, hot-swappable components, and a starting price of $39,995 USD. Yes, the IP1280 runs Check Point VPN-1, as most of the Nokia Appliances do.

As someone who works for the group that supports the Nokia Appliances, I would certainly appreciate it if when your company buys one of these platforms, you'd avail yourself of Nokia's First Call, Final Resolution support. At least that's what the marketing types have been calling it for many moons now.

When I was at the car dealer yesterday giving my car some service love, I hung out at the dealership while the repair was taking place. My dealer is pretty good--they give you a coupon (or two) for a free latte while you wait for your car to be serviced. They offer WiFi throughout their waiting area. They also have a "lounge" where you can either use one of the computers they have or use your own.

Despite the dealer having WiFi, I didn't use it. Why? Their system requires reauthenticating every two hours, which gets old when I know I am going to be there for at least twice that long. Instead, I decided to use my Sprint EVDO dongle.

Unfortunately, I spent a long time fighting with the Sprint Connection Manager software (version 1.10.0023.0) instead of working. When I tried to use it to connect, then started up my VPN to connect to the office, my EVDO connection would unceremoniously disconnect. I don't remember my Verizon card ever doing this.

I eventually figured out how to get this combination working. The hint is in the graphic here. Sprint's software--and presumably Verizon's software--are simply front ends for the standard Windows dial-up networking. Sprint's software also has this NDIS mode in it--make sure it's set to RAS before you do this trick.

In Check Point Secure Client (which us old-timers still call SecuRemote), I told it to use a Dial-up connection, which shows up in the Connection window. In my case, I ticked the Use Dial-up option and used the connection called CDMA. There was another one called 3G Connection that I didn't try. After this, Secure Client properly brought up the EVDO connection and started my VPN. The connection didn't drop once and worked reliably for the rest of the time I was at the dealer.

I left the Sprint Connection Manager software running, but I don't believe it was necessary. It continued to show me signal strength and the like, but I did not see any details about how much data I was sending and receiving. That's ok, just as long as my EVDO worked.

In my past life, I did a heck of a lot with Check Point FireWall-1, now called VPN-1 Power or something. I don't do much with it now except for use their VPN client to access work, but I do spend some of my day job reviewing stuff other people write about it.

One of the things I have to do in order to use my work computer on my home network is to actually allow my work computer to access a couple of things at home: namely my Mac sitting right next to it and my network printer. Unfortunately, the combination of the VPN configuration and the firewall software loaded on the laptop make this a challenge, but not difficult.

One of the things the VPN does is add all these routes to the routing table that essentially override the local routes. Now I can see why an enterprise might want to do that, but if you want to access local resources, then it creates a challenge.

What I was doing to correct this issue was doing all this by hand: looking at the routing table, removing the offending routes, and adding a few others. In smaller environments, the routes are going to always be to the same default IP. The problem with the implementation I am working with is the nexthop for these routes has a habit of being different each time I connect. I needed to look at the routing table manually before doing the surgery on it. The end result was that I could access the machines I needed.

Today, I got the bug to automate all this, so I decided to write a Windows Batch file to accomplish all this. Apparently, this was harder than I thought, but I wrote a batch file that:

• Looked at the routing table for a route I know the VPN will set. Fortunately Windows allows you to print only a specific route.
• Parse out all the junk that gets printed in addition to the information I wanted. This parsing turned out to be the most difficult, particularly in getting the information out of a FOR loop.
• Set routes, which is relatively easy once you have the information.

And FTW, I decided to also add in automatically logging into SecureClient. One batch script logs me in and mucks with the routing table. To find that information, I had to refer to a tome I wrote nearly four years ago. Yes, I know it was published in 2004, but I did a lot of the writing for it in 2002/2003. Damn publisher lead times. Anyway, I looked in a more recent Check Point book (on NGX) that I had lying around and it didn't even cover SecureClient on the command line. It's not the first time I found something in my own book that hasn't made it into other, more recent books, either.

Anyway, I am happy to say it's all working just fine. I do miss being able to use my SecureClient GUI (enabling CLI mode disables all that stuff), but I like how much easier the entire logging on experience is now. For those who are interested, I am posting my batch job after the break. If you're interested, click on thru and read my handy work.

@REM kill Echo
@echo off
setlocal EnableDelayedExpansion
set SCC="C:Program FilesCheckPointSecuRemotebinscc"
%SCC% setmode cli
rem %SCC% disconnect
%SCC% up username %1%
%SCC% connect "VPN Profile"
%SCC% status
%SCC% ep
@REM Trying to pull out VPN route and mess with routing table
@REM
@REM Did we find the netmask line?
set hitnetmask=0
@REM Let's pull out a route I know will be there:
@for /f "tokens=3" %%i in ('route print 192.168.0.0') do (
@REM After we found the netmask, the next thing we get is the route we want
@REM and make sure we get out of dodge
if !hitnetmask! EQU 1 (
call :set_nexthop %%i
GOTO :found_route
)
@REM The next line after the "netmask" line is the one we want.
if "%%i" == "Netmask" (call :set_hitnetmask)
)
:set_hitnetmask
set hitnetmask=1
GOTO :eof
:set_nexthop
set nexthop=%1
GOTO :EOF
:found_route
echo Nexthop is %nexthop%, deleting/setting the routes appropriately
echo on
route delete 192.168.0.0 mask 255.255.255.0 %nexthop%
route delete 192.168.0.2 %nexthop%
route delete 192.168.2.253 %nexthop%
route add 192.168.2.253 192.168.0.254
@endlocal