Category: security

We’re always quick to criticize ... and usually quiet when we should praise. I’d like to fix one of my omissions: a few days ago I was trying to figure out whether Nexus 7000 supports IPv6 access lists (one of the presentations I was looking at while researching the details for my upcoming Data Center webinar implied there might be a problem) and was pleasantly surprised by the breadth of packet filters offered on this platform. Let’s start with a diagram.

Extremely valid comment made by Pavel Skovajsa in response to my “Rest in peace, my WAF friend” post beautifully illustrates the compartmentalized state some IT organizations face; before going there, let’s start with the basic questions.

Do we need WAF ... as a function, not as a box or a specific product? It’s the same question as “do we need virus scanners” or “do we need firewalls” in a different disguise. In an ideal world where all the developers would be security-conscious and there would be no bugs, the answer is “NO”. As we all know, we’re in a different dimension and getting further away from the heavens every time someone utters “just good enough” phrase or any other such bingo-winning slogan.

It’s popular to bash IT vendors’ lack of security awareness (Microsoft comes to mind immediately), but they’re still far ahead of a typical web application developer. At least they get huge exposure, which forces them to implement security frameworks.

A few years ago, Cisco bought a company that made application-level firewalls, first an XML-focused product (XML Gateway) that was also able to verify your XML data, later a Web Application Firewall (WAF), which was effectively the XML product with half of the brains ripped out.

I was really looking forward to these products. Layer-3 firewalls cannot protect web sites against application-layer problems like SQL injections or cross-site scripting, so we definitely need something on the application layer and the WAF (and XML Gateway) ran as virtual appliance in VMware, making them ideal for my lab environment. I quickly lost interest after the first cursory contact with the XML Gateway as you could only manage both products with a web-based GUI (and I definitely don’t want to publish blog posts full of screenshots).

It looks like the signed DNS root zone might finally get deployed on July 15th and Geoff Huston celebrates the fact with a lengthy article on DNSSEC. Just in case you’re not aware what DNSSEC is all about, he’s providing this nifty summary:

A succinct summary of the problem that DNSSEC is intended to address is that DNSSEC is intended to protect DNS clients from believing forged DNS data.

Read the rest of the article on his blog.

DNSSEC deployment could cause some firewalls to hiccup. You might have to change your ASA configuration; zone-based firewall on IOS supposedly works just fine.

When Cisco started preaching about Borderless Networks a few months ago, we all knew the term Borderless Networks was a new fuzzily-defined paradigm revolving around the facts that:

• People want to use their smartphones (and other mobile devices) to access the corporate data from anywhere at any time.
• Employees have started to use third-party cloud services with unproven security or reliability without coordination with corporate IT or Security.

However, when Cisco Press launched the Securing the Borderless Network book (with the subtitle Security for the Web 2.0 World), I was hoping to get some insight into what Cisco really means with the Borderless Networks paradigm. I was also expecting some hard technical facts and solutions for the problems pestering all of us.

One of the scenarios I’m discussing in the DMVPN webinar is redundant DMVPN network with two ISPs. It’s not a particularly complex setup, unless the ISPs decide to deploy anti-spoofing filters (more precisely: unicast RPF checks) in which case it becomes crucially important which outbound interface you use for your DMVPN tunnel.

Anyhow, I was trying to make the whole thing work in a lab and it was repeatedly failing, so I decided to log uRPF violations. According to the documentation, it’s a piece of cake:

Yesterday I finally found time to listen to the DDoS chewing podcast on Packet Pushers. While I know quite a bit about the technical solutions, their focus on the big picture and Service Provider offerings was a truly refreshing one (after all, if you’re under attack, it’s best if your upstream SP filters the junk).

They also mentioned a few interesting application-related issues that will definitely help me streamline my web sites (for example: once your load goes above a certain threshold, start serving cached data instead of retrieving it live from the database) and discussed an interesting case study where a networking engineer (Greg, if I’m not mistaken) managed to persuade the programmers to optimize the application, thus saving the company a lot of money in the long run.

Even if DDoS protection might not be relevant to your current job position and although a lot of their discussion was spinning around SP offerings and application-level solutions, I would strongly recommend that you listen to the podcast. After all, it never hurts to glance around your sandbox and consider other perspectives (and I definitely enjoyed the view).

John shared a great idea in his comment to my “FTP: a trip down the memory lane” post: when using some FTP servers you can specify the range of passive ports, allowing you to tighten your router ACL (otherwise you’d have to allow inbound connections to all TCP ports above 1024).

If you’re using wu-ftpd, the port range is specified with the passive ports configuration directive in the ftpaccess configuration file. ProFTPD uses PassivePorts configuration directive and recommends using IANA-specified ephemeral port range. Pure-FTPd takes a more cryptic approach: the port range is specified in the –p command-line option.

Arnold sent me an excellent question yesterday; he bought my Deploying Zone-Based Firewalls book, but found no sample configurations using IPSec VPN. I was able to find a few sample configurations on CCO, but none of them included the self zone. The truly interesting bit of the puzzle is the traffic being received or sent by the router (everything else is self-explanatory if you’ve read my book), so those configurations are not of great help.

Realizing that this is a bigger can of worms than I’ve expected, I immediately fixed the slides in my Choose the Optimal VPN Service webinar, which now includes the security models for GRE, VTI and DMVPN-based VPN services.

The "You can't secure the cloud" article published by Hoff on Rational Survivability discusses whether you can make the cloud solutions as secure as enterprise (walled garden) ones. Here's a great summary:

Yes, it’s true. It’s absolutely possible to engineer solutions across most cloud services today that meet or exceed the security provided within the walled gardens of your enterprise today.

The realities of that statement come crashing down, however, when people confuse possibility with the capability to execute whilst not disrupting the business and not requiring wholesale re-architecture of applications, security, privacy, operations, compliance, economics, organization, culture and governance.

The rest of the article is also well worth reading.

Every now and then an incident reminds us how vulnerable BGP is. Very few of these incidents are intentional (the Pakistan vs. YouTube is a rare exception) and few of them are propagated far enough to matter on a global scale (bugs in BGP implementations are scarier). Most of these incidents could be prevented with either Secure BGP or Secure Origin BGP but it looks like they will not be implemented any time soon.

Daniel Miessler described an interesting application of the Workstation-as-a-Service (now you know what WAAS stands for ;) cloud service (formerly known as virtual desktop): enterprise network will have to protect their workstations against browser-based attacks and the best approach is to virtualize the browsers and isolate them in a sandbox behind a firewall.

Virtualization, virtual desktops and other security-related cloud services are described in my Next-generation IP Services workshop.

Someone sent me an interesting question a while ago: “is it possible to detect DOS flooding with an EEM applet?” Of course it is (assuming the DOS attack results in very high load on the Internet-facing interface) and the best option is the EEM interface event detector.

The interface event detector is more user-friendly than the SNMP event detector. You can specify interface name and parameter name in the interface event detector; with SNMP event detector you have to specify SNMP object identifier (OID). The interface event detector stores the interface name, measured parameter name and its value in three convenient environment variables that you can use to generate syslog messages or alert the operators via e-mail.

I’d like to thank all the readers that took time and responded to my question about the failure of my Deploying Zone-Based Firewalls book. The sad short conclusion is: while everyone would love to have an electronic copy of the book, the technology and the mindsets are simply not ready yet. Here are the details:

Last week I described the “beauty” I’d discovered through the NetworkWorld site: a solution that supposedly rejects DoS frames in 6 nanoseconds. Without having more details, I’ve tried hard to be objective and justify that you cannot get that performance in a best-case scenario (at least without having really expensive hardware and optimized architecture). In the meantime, one of the readers provided the name of the author of this discovery and I was able to find the original publication that was published in the Proceedings of the 2007 spring simulation multiconference by Society for Computer Simulation International.