We covered a lot of topics in this show, mainly hating on firewalls and the lack of security process in most corporate companies.
I was listening to one of your shows from July and heard you discuss Checkpoint Vs. other firewalls. I’ve been lucky (or unlucky, depending upon how you look at it) to touch multiple types of commercial and open source firewalls. I work for an EDU in the US and we started with Checkpoint on Solaris in approximately 1999 and I managed that infrastructure for about six years. I ended up with it after moving from our Unix team to the Networking team. I had implemented TCPWrappers and IPFilter on all our Unix hosts when we didn’t really have firewalls and as the only woman in the group, the guys gave me the stuff that wasn’t considered “real” networking equipment: DNS, load-balancing and firewalls. About two years ago, I made the recommendation to rip the entire infrastructure out after a rather painful failed attempt to get PIM routing working between two of our data centers and two Checkpoint/Nokia clusters.
But removing Checkpoint from an enterprise is like trying to rid your bathroom of mildew. I could tell you horror stories about calling CheckPoint because I needed help quickly and being able to hear the support person flip through the manual to look up the answer, having bug issues escalated to R&D in Israel, which means a four-month wait (Checkpoint’s version of /dev/null), or how the product allowed a previous admin to make incredible misconfiguration errors which I spent countless hours fixing. By the way, I completely concur with the assessment regarding ASAs being horrible as well. They’re confusing, have a badly written interface and are almost unusable. The bright spot for me is also Juniper. With the Netscreen firewalls, I’ve found them to be so stable and easy, I’m almost embarrassed to get a paycheck for managing them. What’s really funny is that Netscreen was started by Nir Zuk, who was one of the original Checkpoint people. Now he’s out shilling his new firewall company, Palo Alto, which is an application-layer firewall. Let me know if you ever need some firewall horror stories, because I have plenty.
Firewalls and security devices:
What the hell is wrong with firewalls today? They don’t seem to protect us from anything except the most primitively incompetent script kiddies, while overcomplicating our networks and creating choke points. Has anyone really seen any firewall that operates at anything near the line speed advertised? And when firewall vendors advertise how many concurrent connections in the connection table they can hold or how many packets per second they can process, is that a “real world” scenario or do they rig the tests in order to maximize the numbers?
FW: For security in 1999
How do already overworked security or network engineers test devices without access to expensive network simulation devices or traffic generators? Then you turn on the application inspection functionality and performance goes out the window. Is the talk about NextGen firewalls all a lot of hype? How are the major players doing: Cisco, Juniper, Palo Alto, Checkpoint, and Fortinet? Are any of them really offering anything different or is it just more of the same snake oil? Maybe it’s time for a paradigm shift with security. What can “cloud security” companies like Zscaler offer that’s different? Is it time for a change from adding more DLP, Proxies, AV, IDS/IPS, SIEMs and all the other appliances we’re buying? What about information sharing projects like DNS-OARC, REN-ISAC, Team CYMRU? Are those valuable? And don’t even get me started on the horrible failure of NAC and endpoint security. Are you really going to tell a VP that he can’t have his iPad, iPhone or Android tablet on the network?
Agreement among the team that NetScreen firewalls are awesome and the SRX firewalls will be nice when they are finished – in five years or so.
Some of the domain names on that list suggest that the attackers had (or wanted to appear to have) contempt for the United States. Among the domains used in the attack (extra spacing is intentional in the links below, which should be considered hostile):
A partial list of the domains used in the attack on RSA
- www usgoodluck .com
- obama .servehttp .com
- prc .dynamiclink .ddns .us
Okay, the RSA situation just got EVEN funnier, if possible. Looks like EMC bought NetWitness.
The word from some blogposts is that RSA was running NetWitness on their network. NetWitness isn’t an IDS, but more of a forensic analysis after-attack tool. However, RSA probably had the standard IDS/IPS tools on their network and it points to a real problem with these devices: too much noise (alerts, both false positives and false negatives) to actually be useful. Their network security devices missed the attack, but who’s really surprised here. I’ve found most of the stuff on the market to be a lot of sound and fury signifying nothing. So what does this acquisition really mean in the marketplace?
Tom: It looks like more than half my Twitter feed was affected by the Epsilon Mass Mailer data breach. Target, Marriott, Saks, Hilton, JPMorgan, Citibank, Best Buy, Walgreens, ad infinitum. When companies like this have their hooks into so many different companies and are responsible for the storage of so much information about customer bases, what kinds of remediation are available when they ruin your good name by getting breached? People are going to want heads for this screw up, and I don’t think there’s enough of Epsilon to go around. Add in the fact that most “experts” are calling for a huge rise in the kind of attacks that targeted RSA and you’re going to have a storm of social engineering out there.
Mrs. Y: This is the “tip of the iceberg”. Last Black Hat was really focused on SAP and ERP hacking. The hackers are getting much smarter and have taken it up a notch. They’ve realized where the valuable information is located and they’re willing to spend the money and effort to learn these really esoteric and byzantine enterprise applications used for housing data warehouse, human resources and financial data. The real problem here is that we need to look at security in a new way. We have to start building it in, not bolting it on afterwards after we do some policy-mandated security assessments and penetration tests. Security is the concern of everyone in the enterprise,
Here’s some more info regarding the Epsilon compromise
Anyone else worried about SLAAC attacks and other security issues as they deploy IPV6 on their networks? Has anyone implemented raguard or some of the other recommendations made by Joe Klein, the IPV6 security guy?
Date: Wed, 6 Apr 2011 14:23:41 -0400 From: Joe Klein email@example.com Subject: Re: [Dailydave] SLAAC Attack - 0day Windows Network Interception Configuration Vulnerability To: Sebastian Krahmer firstname.lastname@example.org Cc: email@example.com Message-ID: Content-Type: text/plain; charset=windows-1252
Sorry Adam, the whole ?ND MITM? issue is old news, has been discussed at IETF meeting, mailing lists and published in multiple RFC's. I have also been teaching, demoing this and other IPv6 attack technique for at least seven years, as has Marc Heuse (Marc - Nice job on the IPv6 THC Tools and your presentations!).
What you might find interesting is the reason Microsoft doesn?t include SEND in their current products. It seems after the engineers from Microsoft and Ericsson finished writing the IETF document, they also wrote and filed a patent on the process. So Microsoft has concerns implementing SEND, due to legal concerns with Ericsson. I have been privately requesting Microsoft to address this issue since 2005 and publicly requested a status from the MSRC at their Q&A session during Black Hat Vegas 2009. The status so far is — there is no status. Anyone form Microsoft want to provide a status?
On mitigating this problem, you have multiple choices:
- Disable IPv6 on all devices.
This is the best option if you do not have security products which support IPv6 ? really support IPv6! That level of support should include parity with the current IPv4 product, support for all active RFC?s, device discovery and vulnerabilities. I presented a list of those high level items during HOPE/Toorcon/Sector 2010, if you anyone is interested.
So over the last 5 years, I have interviewed hundreds of vendors claiming to support IPv6, many of them monitor this list. I have a ?Trust but verify?, so I tested many of these products, and the result is they all FAILED. I presented on my finding back in 2005 but have been updating this list yearly. I have considered publishing my findings, but legal consul recommended against it. This year might be different, stay tuned ? maybe Black Hat or Defcon.
If you do have products which support IPv6, or your vendor has convinced you of it, then leave IPv6 enabled. The cost of disabling, then enabling the protocol on a large network can be very expensive. Also, don?t be that guy that removes the IPv6 binaries as a method to protect your networks. It seems if you remove the binaries from many operating systems, it will require a complete reload of the operating system and applications.
- If you don?t currently support IPv6 in your environment, block layer 2 protocol number 86DD.
- If by chance you have IPv6 enabled or support IPv6, enable RA guard. Note, that many switches either don?t support RA Guard and will requiring a switch replacement, while others require a software upgrade.
- Again if you don?t currently support IPv6, you can also block and log protocol 41 on routers. This will not solve the problem, but will at least provide an indication an attack is accruing. Look for the router advertising packets.
- There are a bunch of other methods, but sadly don?t have time to enumerate all them here.
- Implement SEND.
This in theory is easy, but in practice can take a lot of work. It will require all hosts and routers to support IPv6 SEND/CGA. It will also require implementing a certificate authority.
On the router/switch side, Cisco and Juniper have implemented SEND in their devices. Outside of these two vendors, your only option are for FreeBSD or LINUX system:
- Use the DoCoMo Labs USA OpenSource implementation of RFC 3971, 3972, and 3779 for SEcure Neighbor Discovery (SEND). The code and documentation can be downloaded at: http://www.aestheticscientist.com/082406/lab_opensource.html
- Use IPv6-SEND-CGA (http://code.google.com/p/ipv6-send-cga/) For the client side, consider Easy-SEND (at http://sourceforge.net/projects/easy-send) or IPv6-SEND-CGA (http://code.google.com/p/ipv6-send-cga/), for Linux.
Adam, one good outcome of your teams posting this vulnerability is, the security and IT community are discussing potential risks involving in poor deployment of IPv6 networks.
Hosts / Guests
Special thanks to Mrs Y – “The Network Princess” for joining us this week.
and last, and the very least.
Subscribe in iTunes and RSS
Media Player and MP3 Download