Category: firewall

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).

A while ago I’ve bitterly complained about the FTP protocol design. I have decades-long grudge with FTP. If you’re old enough to remember configuring firewalls before stateful inspection or reflexive access lists became available, you probably know what I’m talking about; if not, here’s the story.

When enterprises started using the Internet 15+ years ago, most desktop FTP clients did not support passive mode (although it was part of the FTP standard). When configuring “firewalls” (one or two routers with long access lists), you had to allow all inbound TCP session to ports higher than 1024 just to support FTP data sessions. No problem ... unless you were using Sun workstations or NetBIOS over TCP (both of them use dynamic server ports above 1024), in which case those services were totally exposed to the Internet.

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.

Imagine you have a large retail network: your remote offices use ISDN to dial into the central site and upload/download whatever periodic reports they have. Having a core router connected to an ISDN PRI interface is the perfect solution:

A few years later, ISDN is becoming too slow for your increased traffic needs and you want to replace it with DSL or VPN-over-Internet solution. Your Service Provider offers you PPPoE forwarding with L2TP. This is a perfect solution as it allows you to minimize the changes:

Unveiling of the Cisco IOS release 15.1(1)T was the extreme opposite of the CRS-3 and Catalyst 3750-X splashes; the next release of one of the foundations of Cisco’s core business deserved a modest two-paragraph mention in the What's New in Cisco Product Documentation page.

If you’re a voice guru, you’ll probably enjoy the list of 20+ voice-related new features, including the all-important Enhanced Music on Hold. For the rest of us, here’s what I found particularly interesting:

Anyone dealing with FTP and firewalls has to ask himself “what were those guys smokingthinking?” As we all know, FTP is seriously broken interestingly-designed:

• Command and data streams use separate sessions.
• Layer-3 addresses and layer-4 port numbers are carried in layer-7 messages.
• FTP server opens a reverse session to a dynamic port assigned by the FTP client.

Once upon a time, there was a very good reason for this weird behavior. As Marcus Ranum explained in his Internet nails talk @ TEDx (the title is based on the For Want of a Nail rhyme), the original FTP program had to use two sessions because the sessions in the original (pre-TCP) Arpanet network were unidirectional. When TCP was introduced and two sessions were no longer needed (or, at least, they could be opened in the same direction), the programmer responsible for the FTP code was simply too lazy to fix it.

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:

A quick question for you: in two years since my Deploying Zone-based Firewalls digital short cut (marketese for downloadable PDF) was published, we’ve sold around 200 copies of it. Obviously we’re doing something wrong and I’d appreciate your opinion: is it the topic (are you using ZB firewall on Cisco IOS?), the format (would you prefer paper copy?), the platform (Cisco IOS as a firewall), pricing ($14.99 for 112 pages) or something else?

The zone-based firewall uses security policy-maps to specify how the flows between zones should be handled based on their traffic classes. The obvious actions that you can use in the security policy are pass, drop and inspect, but there’s also the police action and one of the readers sent me an interesting question: “why would you need the police action in the security policy if you already have QoS policing”.

If you have been visited by a friendly Cisco sales engineer recently, you might have already heard about the ACE Web Application Firewall (WAF). If you’re curious enough to start investigating on your own, you might have stumbled across the WAF product description on Cisco’s Web site, which tells you … nothing.

Let’s start with an easy question: if I already have a firewall, why would I need another box with “fire” and “wall” in its name? The short answer is “Because Web programmers rarely know how to write secure Web applications.”

read more see 10 comments

I was delighted when I got access to Cisco's ACE XML Gateway/Web Application Firewall (WAF) box. This box is the perfect intersection of three fields I'm really interested in: networking, security and web programming, so I'll work with it quite a lot in the future and post interesting tips and tricks about its usage.

As this blog is currently focused exclusive on Cisco IOS, I'm wondering how to cover these new products. I won't create another blog; it simply doesn't make sense to build another blog from the ground up, but there are a few other options. Please help me select the best one by voting in the poll.

read more see 2 comments

The Thinking problem management! blog had an interesting article on The Leaky VLANs myth, quoting a test report from SANS Institute that documents how you can inject frames into other VLANs even if you're not connected to a trunk port. The report is eight years old (so one would hope this issue has been fixed in the meantime), but there's another question you should ask yourself is: what happens when you lose the configuration of the switch (and I've seen devices losing configuration after a power glitch). If you're using a router to perform L3 switching, no harm is done; a router with empty configuration forwards no packets. But if you're using a low-end switch, you're in deep trouble; by default, a switch forwards packets between all ports ... and if you use static IP addresses on all subnets, you won't even notice they're connected. If you want to be very safe, you're better off having a different set of switches for the inside and the outside zones of your firewall.