It's official, Nokia's is out of the security business

   I hate to say I told you so, but I did. Over two months ago I told you that the Checkpoint and Nokia relationship was coming to an end. Well that day have finally arrived. Reuters reported today that Nokia has finally found a suitor for their Nokia IP Series appliances. They have already stopped development on all new products. That's right, no more IPSO updates, at least for a while. The deal, which is expected to be finalized in a week or two, may cause up to 700 employees to dust off their resumes.

  Nokia's IP series firewalls and VPNs provided simple security services however most of their popularity revolved around their long time relationship with Checkpoint. Nokia provided the perfect hardware platform for Checkpoint's software based firewalls. It seemed like a match made in heaven until Checkpoint started working on their own UTM appliances and established a partnership with Crossbeam. The failed Sourcefire deal set Checkpoint back a few years but UTM-1 and Power-1 appear to be a success in today's "One Security Product To Rule The World" society. Their UTM product line does much more than the Nokia IP series ever did including 0 day malware, anti-virus, content filtering, and anti-spam. Nokia knew their fate and just hoped to escape on two feet.

  The details of the sale have not been released, however the security division was purchased by a "financial investor", which is corporate speak for "someone who will sit on it for a while and resell it to someone else".

Websense tackles Web 2.0 security

    On September 18^th, just before the stock market took a nose dive, Websense CEO Gene Hodges rang the opening bell as a symbolic introduction of their newest security appliance. In addition, Websense launched a new strategic marketing campaign.

   The Websense Web Security Gateway, the only Web 2.0 content classification suite, hit the virtual shelves with a lot of buzz.  According to Darkreading “Based on the latest release of the company’s flagship Web security platform, Websense Web Security Version 7, the Web Security Gateway allows businesses to embrace and use Web 2.0 technologies to accelerate their business goals – without having to worry about malicious or inappropriate content.”

   The new content engine will focus on dynamic content like blogs, instant messaging, and peer-to-peer sites. Over the past 3 years Web 2.0 has been a gift and a curse. To business managers, Web 2.0 means a near real-time business presence on the web. It means a virtual presence on Secondlife, free advertising on Myspace,  RSS feeds that inform existing and potential customers on new products, and a plethora of blogs and wiki’s that keep their product or service on the lips of cyberspace.

   To IT Security managers, Web 2.0 can lead to sleepless nights trying to figure out how to protect intellectual property, block unscrupulous sites that literally change by the hour, and prevent malicious malware embedded in dynamic content from reaching the company’s interior.

   Websense has attempted to address these concerns with the Web Security Gateway. According to their site “With the Websense ThreatSeeker Network, Websense continuously scans the Internet—more than 600 million Web sites every week—to find new malware before it strikes. By finding a threat at the source, Websense can block it everywhere—from email to Web mail, from static URLs to dynamic Web 2.0 sites. Then Websense Web Security provides multi-layered defense to thwart botnet attacks, block phishing messages and access to infected URLs, and botnet "phone home" communication.”

“Websense Web Security Gateway allows organizations to secure Web traffic effectively while still enabling the latest Web-based tools and applications. Through a multi-vector traffic-scanning engine, the Websense Web Security Gateway analyzes Web traffic in real-time—instantly categorizing new sites and dynamic content and proactively discovering security risks and blocking dangerous malware.”

Virtual Firewalls pt2: Juniper Vsys

   In part 2 of our Virtual Firewalls review I will take a look at Juniper’s Vsys. In part 1 I presented an overview or Virtual Firewalls and explained their benefits in today’s cost conscious, virtualization heavy, green planet touting society. I also took a look at Checkpoint’s VSX, both from an appliance perspective (Crossbeam) and software. For those of you who have not read part 1 I encourage you to check it out here.

   Juniper’s Virtual System (VSYS) can be defined as a logical firewall, or group of logical firewalls contain in a single physical firewall. As with Checkpoint’s VSX, VSYS provides service providers and Network Operations Centers the ability to manage all of their customer’s firewalls in one appliance. Common components like administrative access, global policies, and virtual routers, can be shared across Virtual Systems while each Vsys contains its own address book entries,  user lists, VPNs, policies, NATs, and services. Vsys is not as segmented as VSX with regards to Virtual Firewall configurations. Virtually all components can be designated as either shared or exclusive to each Vsys. Though extremely robust, this can add a greater learning curve with regards to initial configuration and troubleshooting.  When components are shared, they become available to other Virtual Systems and/or the root vsys.  Exclusive components are only available to the Virtual System in which it was created.

   Each Vsys contains 3 primary components, vitrual routers, zones, and network interfaces. Virtual routers are created automatically when a Vsys is created. The Virtual routers is named <vsys_name>-vr and provides the routing logic for the Vsys. Other shared virtual routers are also created and accessible to all virtual systems. When a Vsys is created, 3 default zones are also created called Trust-<vsys-name>, Untrust-Tun-<vsys-name>, and Global-<vsys>.  The network interfaces created are both shared and non-shared. The shared interface is attached to the Untrust Zone and is accessible across all Virtual Systems. This interface can be either a physical interface or a VLAN tagged subinterface. The non-shared interface is attached to the Trust Zone and can also be a physical interface or a VLAN tagged subinterface.

   Traffic from the Untrust Zone is classified by the root Vsys to determine the best Virtual System to handle the traffic. As indicated when the “get route ip <Ip address>" command is ran from the root Vsys, there may be multiple matches for each network but the more specific route will always be chosen. Traffic classification defines which IP’s are bound to which zones. This allows the root vsys to decide which vsys to send traffic to. There are 2 methods of traffic classification. One if for traffic destined for a virtual interface (vpn’s, mips, dips). The root vsys keeps a list of virtual interfaces so it knows were to send traffic destined for a virtual interface automatically. The second method is for traffic passing through a vysy. In order for the root vsys to know where to send the traffic either VLAN tagging or IP-based classifications must be used. When defining the traffic, overlapping ranges cannot be used since shared zones are utilized.

For a simple How-To guide for setting up a Vsys on a Juniper Firewall please refer to the guide located in our forums.

 Vsys licensing starts at 10 Virtual Systems and can be customized for virtually any number of systems from 25, 100, 250, and more.

   Professional support for Virtual Systems is a lot easier than it is with Checkpoint, which currently runs on several different appliance vendors.  Juniper’s knowledge base is pretty extensive, which is a good thing because your going to need it. I’ve found that troubleshooting a Vsys can be cumbersome and involves a lot of trial and error.

For more information on Juniper's Vsys, check out there white papers online.

Introducing McAfee's Artemis

   Continuing the latest trend of cloud based security, mentioned several times on Netleets, from vendors like Trend Micro, F-Secure, Zscaler, and Checkpoint, McAfee throws their name in the hat with Artemis. Like Trend Micro’s Smart Protection Network, Artemis, part of McAfee’s Total Protection Service, hashes and classifies suspicious URL’s and files. As e-mail’s pass the scanner, a hash is taken and compared against the database of hashes for malicious content. Prior to this, local white and black lists are checked, which eliminates some of the need to receive remote approval for data.

   According to their home page, “malware reported in 2008 already exceeds the amount reported in 2006 and 2007 combined. The unprecedented growth in malware has made it difficult not only for consumers and enterprises, but also for security vendors trying to keep up using the traditional “signature” based defense mechanism.”

   Though not intended to replace client based anti-virus scanners, it does have it’s advantages. When malware is released in the wild, it’s usually flooded out to the web in hopes of infecting unsuspecting users. In order for a virus scanner or malware client to detect a piece of malware, it has to know about it. When it is discovered, a signature is created and released to the public. On average, this takes about 2 days. Scanners are configured to look for new updates at a certain interval. For most, that interval is once a day during non-business hours. The time elapsed between a malware release to patching can be as long as 36 hours. According to McAfee, the process of identifying, patching, and deploying can be as long as 72 hours. That’s plenty enough time for malware to wreck havoc on a network, causing a slow down in throughput, leaking sensitive information, and possibly even damaging essential data and applications. Cloud based scanning takes a “virtual” 0-day approach by checking for known malware in real time.

   According to David Marcus, security research and communications manager at McAfee, “The idea is to cut zero-day threats, threats where there is no known fix or cure, down to 1 minute threats that are recognized as soon as they show up”. He went on to say, "It's almost the equivalent of being a first responder. It allows us to say we don't know what it is, but we've identified something suspicious going on, let's take it into the cloud, compare to larger black list, and make a fix. It lets us close a huge protection gap between when it's found, when it's analyzed, when it has protection written against it and when its sent out, which is usually the next day after it's found".

   As with other cloud based services, most of the load is removed from the local client and shifted to a remote group of servers on the internet. A DNS lookup is performed, where the closest server is identified. The hash taken locally is then sent to this remote server where a comparison is made against the local hash database. An approve/deny message is sent back to the client. This open up another can of worms when deciding if this product is right for you. Is the method of hashing, sending remotely, and waiting for a response really faster than local processing? What happens when the remote server is unreachable or performance is slow? Is all traffic dropped or allowed in the event of a failure? Is previously approved traffic cached like similar services by Checkpoint?  If so, can multiple clients on an enterprise network share cached hashes?

   McAfee’s site contends that identification of the malware takes less than a second once the hash, of fingerprint, is received. Though that is really hard to believe, even if that is possible, that does not account for the time it takes to hash send and receive the approval. It is also important to note that Artemis only work for malware and not PUP’s (potentially unwanted programs). In addition, Artemis has only been tested on Windows platforms.

   An independent test performed in Feburary by AV Comparatives,  showed that virus and worm detections went up about 1 with Artemis and backdoor bot detection increased by 4% compared to the traditional McAfee VirusScan Engine. However AV Comparatives also reported an extremely high number of false positives reported, causing over 500 good packets to be blocked.

   McAfee intends on expanding Artemis to the McAfee VirusScan Enterprise and other consumer products later this month but are happy with the success it has seen thus far.

Cisco Firewalls Dosable AGAIN....pt.2

   As many of you are aware, a couple months ago I informed you about Cisco security devices that were susceptible to DOS attacks. For a refresher, check out that article here. In short, Cisco PIX and ASA's could be DOSed by TCP ACKS, specially crafted TLS packets, Instant Messenger Inspection, Vulnerability Scans, and Control-plane ACL's. If that was not enough to convince you to immediately download a patch, Cisco has added several other vulnerabilities that could cause a Denial of Service to those same previously vulnerable systems. So if you ignored Cisco's advise, they would like you to know that your firewalls are now also vulnerable to SIP processing vulnerabilities, as well as DOS attacks involving SSL, Clientless, and IPSec Client VPN.

   Affected products include the following:

Erroneous SIP Processing Vulnerabilities

Cisco PIX and Cisco ASA devices configured for SIP inspection are vulnerable to multiple processing errors that may result in denial of service attacks. Cisco PIX and ASA software versions prior to 7.0(7)16, 7.1(2)71, 7.2(4)7, 8.0(3)20, and 8.1(1)8 are vulnerable to these SIP processing errors.

IPSec Client Authentication Processing Vulnerability

Cisco PIX and Cisco ASA devices that terminate remote access VPN connections are vulnerable to a denial of service attack if the device is running software versions prior to 7.2(4)2, 8.0(3)14, and 8.1(1)4. Cisco PIX and Cisco ASA devices that run software versions 7.0 and 7.1 are not affected by this vulnerability.

SSL VPN Memory Leak Vulnerability

Cisco ASA devices that terminate clientless remote access VPN connections are vulnerable to a denial of service attack affecting the SSL processing software if the device is running a software version prior to 7.2(4)2, 8.0(3)14, or 8.1(1)4. Cisco ASA devices that run software versions 7.0 and 7.1 are not affected by this vulnerability.

URI Processing Error Vulnerability in SSL VPNs

Cisco ASA devices that terminate clientless remote access VPN connections are vulnerable to a denial of service attack in the HTTP server if the device is running software versions prior to 8.0(3)15, and 8.1(1)5. Cisco ASA devices that run software versions 7.0, 7.1, or 7.2 are not affected by this vulnerability.

Potential Information Disclosure in Clientless VPNs

Cisco ASA devices that terminate clientless remote access VPN connections are vulnerable to potential information disclosure if the device is running affected 8.0 or 8.1 software versions. Cisco ASA devices running software versions 7.0, 7.1, or 7.2 are not affected by this vulnerability. Cisco ASA devices the run software versions prior to 8.0(3)15 and 8.1(1)4, or after 8.0(3)16 and 8.1(1)5 are also not affected by this vulnerability.

As usual, To be continued......

Virtual Firewalls pt1: Checkpoint VSX

  Due to recent forum requests, I have decided to write an analysis of Virtual Systems for firewalls. Over the next few weeks I will take a look at various firewalls that operate as Virtual Systems. This will include, but not limited to Juniper Netscreens running Vsys, Cisco FWSM with Security Contexts, and Checkpoint firewalls running VSX.

Why Virtual Firewalls?

   With recent advances in architecture and storage capacities, virtualization is at its peek. Servers, routers, and even workstations are being virtualized in an effort to consolidate and share resources. Sizes of data centers are shrinking to the point where many companies find it beneficial to lease a couple of racks from a Network Operations Center (NOS) than spend money to build out a dedicated data center.

   But traditionally firewalls are placed at a company’s perimeter and layering is usually achieved by mixing vendors. So how would firewall virtualization benefit? The answer lies in multi-customer environments like ISPs, NOCs,  Managed Security Service Providers (MSS) and college campuses. Virtual firewalls work great in these environments because ISPs can now bundle security services in their management packages as a customizable option. College campuses can segment traffic for students and administrators on one gateway. In the past, a global firewall policy was applied to all (or most) customers, One throat to choke. One firewall to rule them all. The master key to all doors. I hope you see where I’m going with this by now. ISPs are buying one beefy system and segmenting resources, policies, and interfaces (or VLANS) to individual customers at a tremendous cost savings over stand alone appliances. This saves on rack space, power utilization, maintenance, and TCO.

   The first virtual firewall we are going to take a look at is possibly the most robust. Crossbeams Systems’ X series appliance is designed for super redundancy. Dual back plains and power along with redundant management, interfaces, and applications. Speaking of applications, they run on APM cards (Application Process Module) that contains a VAP (Virtual Application Processor) which consists of an OS, system software, and applications that can run concurrently. Multiple APMs can be added to a VAP group for load balancing.  All of this is controlled by the CPM, which manages and stores all global configurations. And last but not least, the NPM assigns traffic flows to the VAP. This makes a Crossbeam X series the perfect candidate for a Virtual System. Checkpoint’s own Power-1 appliance boosts comparable throughput statistics as the X series but does not have the redundancy necessary to support large implementations like ISPs.

   Each Virtual Firewall, known as VSX, acts as a separate Firewall. The gateway decides which virtual instance will handle the packet based on VLAN tagged interfaces (bridged mode) or routing. Interfaces can be dedicated or shared, including the Management interface. As you will learn in future articles, this is very different from many of the other virtual systems that actually makes each virtual firewall look like a stand alone entity.

   Each Virtual System maintains its own state tables, security policies, VPNs, logging, and configuration settings. Virtual Routers are used to route traffic between Virtual Systems and traffic to or from shared resources (DMZ) or interfaces. A Virtual Switch is also configured to establish connectivity between Virtual Systems. It contains its own ARP table.

   Warp Links are used to establish a point to point connection between a Virtual Switch/Router and a Virtual System. Each side of a link in a Virtual System has a wrpj# interface.

   Unlike some other Virtual Systems, VSX also supports overlapping IP Addresses since each Virtual System maintains its own arp and route table.  

   VSX licenses are purchased in 10, 25, 50, 100, or 250 unit blocks and can be pretty pricey compared to other Virtual Systems.

   Setup is fairly painless. There is a VSX wizard that will walk you though the setup. Cluster options are also available via the Wizard, which eases the hassle of designing an HA environment.Troubleshooting is done typical Checkpoint style. Smartview tracker combined with a series of “fw” commands can give you all the info you need.

   With regards to support, Checkpoint has released several hot fixes to address known VSX issues involving VPNs, asynchronous routing,  and disappearing routing tables. That can either be good or bad news, depending on how you look at it. Their KB is pretty extensive with regards to Checkpoint specific (software) issues. Like all Checkpoint products, their KB does not contain much information regarding platform specific issues like Proxy Arps on Crossbeams (known issue) or failover on Nokia’s.

More Product information::

Websense separates themselves with recent acquisitions