4 posts tagged “network”

Well, I received the Netscreen/Juniper SSG eval unit last week and I'd give it a mixed response so far. To recap, the goals for this project are as follows:

1. Provide intelligent inbound NAT for a new group of servers that need some connectivity inside the enterprise but must face out to the Internet to provide services for partners and customers
2. Consolidate outbound NAT/firewall functionality for Campus LAN and WLANs which are currently on separate, standalone Linux boxes running iptables. Along with this, provide increased visibility into traffic flows so abusive protocols (especially BitTorrent) can be controlled.
3. Consolidate 20 or so site-to-site VPNs which are currently on two separate End-of-Lifed concentrators.
4. Replace our ethernet egress router/traffic shaper which is also end-of-lifed, but has an excellent Class-Based Queuing setup that allows fine-grained control over how link bandwidth is allocated and shared.
   

 Here are my original requirements and how the SSG is measuring up so far:

• must block bittorrent and other polymorphic P2P protocols
  
• D-   Only the "IDP" products (either a standalone box or the $20000+ ISG series) support full tcp stream inspection; the normal Deep Inspection functionality requires a priori knowledge of what ports a particular service will be using, which sort of defeats the purpose.
  
• must have a decent traffic shaping setup, CBQ would be nice (Alack, Xedia, we hardly knew ye)
• C  There's sort of a basic CBQ but it's not hierarchical; traffic allotments are tied to a given policy and sadly there doesn't seem to be a way to do the thing I most want: prevent any one LAN IP address from hogging all the bandwidth. You can also do DSCP marking and/or priority queuing based on code points but I don't think that's really going to help much.
  
• must have decent site-to-site VPN interoperability (ideally with support for far-side roaming addresses)
• A The VPN stuff is fine for lan-to-lan, but this has been a strong point for Netscreen since the 2.x days. They have made some improvements in the remote access VPNs too but I don't expect to toss the Cisco/Altiga VPN3ks any time soon.
  
• should have good SNMP-ability and preferably netflow type session data exports
  
• B- I really should have said 'managability' rather than strict SNMP - there have been a few things the web interface croaked on (some types of service definitions can't be grouped with others, generating a cryptic error) but the syslog exports are good and the CLI is good. No netflow/sflow though.

Not exactly a stellar report card. The IDP stuff seems particularly weak, leading to a reformulation of the old bumper sticker: "The more I learn about these vendor boxes, the more I like Snort".  There are indeed Bleedingsnort rules for BT and other P2P programs and snort by definition can do port-independent signatures. Combined with Flexresponse it would be possible to RST enough of the bittorrent connections to make using it from work functionally useless, even if it's not "firewalled" per se. 

However, running a pure linux solution like Trustix Enterprise Firewall or a hacked-up CentOS has its own set of problems -- mainly that it doesn't help with the consolidation goals at all, and when the LARTC HOWTO is the best set of documentation in existence for the implementation you're using...you've got a problem.

More exploration is on tap for the rest of the week. If we can meet three of the four goals with the SSG, it'll be worth the sticker price. Next up: inbound NAT...

Still trying to get a Juniper SSG to evaluate, and I thought this might be of some interest. I guess they wanted to make sure I actually had some reason for asking for a demo unit -- and not just idle curiousity and a desire to get free network kit -- so one of my contacts asked what the test plan was. I had several things in mind but hadn't codified them on paper yet, so this was actually a worthwhile exercise. Here's the result, and if you, Dear Reader, can think of any other products that can meet these requirements, I'd dearly love to hear about 'em...

1. Firewall capability
   a. bittorrent / p2p blocking
   b. stateful inspection engine configurability - can i block specific
   application-layer packet content?
   c. 'zone' separation - is there bleed-through of broadcast/layer2/
   non-ip traffic? Do arp tables overflow w/ dsniff?
   d. DNAT (port forward) implementation correctness and throughput

2. VPN capability
   a. interoperability with Netscreen 5XP for both fixed-ip and
   dynamic-ip remote endpoint
   b. interoperability with cisco PIX / IOS for third party VPN
   c. policy rule apply after tunnel decode for limited-access tunnels
   d. tunnel re-establishment on rekey/ike delete/desync'ed timers

3. Traffic management
   a. CBQ-style features - per-class bandwidth guarantee+borrow
   b. Behavior during congestion - queue tail-drop vs RED?
   c. managability/statistical feedback on class overlimits / throttles
   / borrow attempts / drops

4. Managability
   a. SNMP export of relevant stats, esp VPN status and traffic
   management stats
   b. CLI-ability of all commands (do some operations force you to use
   the web interface?)
   c. Do any unresolved caveats in recent OS releases apply to us?

Here's the DMZ dilemma. As Rich Bejtlich aptly points out in the closing chapter of Extrusion Detection, there's a growing trend toward a consolidated DMZ architecture that eliminates the traditional "air gap" between the egress router and the campus network, a trend which ought not to be accepted without some serious thought.  I've been grappling with this recently at work, and I believe there are some valid reasons for this trend but that, indeed, it's not nearly the shoo-in the vendors claim.

Fig.1 - Dmz-traditional

First, the box labelled 'egress' in Fig.1 was traditionally an access router which required specialized hardware to terminate a WAN interface and usually included some bare-bones packet filters that blocked bogons and spoofs, whereas the 'firewall' box would have CPU horsepower to do more sophisticated NAT and access control operations but only support ethernet interfaces. But these days, more and more Internet access comes in the form of an Ethernet handoff (either at a colocation facility or MAN) plus traditional firewall functionality has been rolled up into "access" devices (like a Cisco 2800 running the IP-PLUS/FW/IDS feature set). So the gap between these two roles is closing.

Second, it can be advantageous to consolidate functionality onto fewer individual boxes -- imagine that, in addition to the one-legged bastion host in Fig.1, there are also a pair of VPN concentrators each with a leg on the DMZ and one inside the Enterprise LAN for remote access. Plus maybe a second firewall providing internet access for a campus wireless LAN. Plus a proliferation of bastion hosts for "extranet" type services, upon some of which business requirements might demand applications of questionable good programming practice... Suddenly, the appeal of a collapsed DMZ as in Fig.2 becomes understandable -- at least it allows an administrator to (as Robert Heinlein said) "put all your eggs in one basket -- then watch that basket!"

Fig.2 - Dmz-collapsed

The caveats, however, are not insubstantial. First and foremost, an exploit or failure on the firewall itself, and in particular anything which compromises the integrity of the "zones" (which implement traffic-forwarding policy between the different segments) is absolutely fatal to the model. The DMZ Network in Fig.2 is logically partitioned but physically connected to the same piece of hardware as the Enterprise LAN resources, so a lot depends on how that hardware implements the separation. Do SNMP requests from one zone reveal details about another? Are there completely separate bridge tables and spanning tree advertisements? Compromise of a bastion host brings an attacker closer to the internal resources in a collapsed architecture than in an air-gap setup.

Another consideration is that of complexity. Adding redundancy to protect against common failures is assuredly a good thing, but there comes a point along the curve of diminishing returns where the redundancy itself  is the cause of downtime, due to the added burden of complexity it imposes on the system. With VPN tunnels, traffic shaping, enterprise firewall,  and extranet access all gated through a paired set of devices, the pairing mechanism had better be clean, unobtrusive, and well-tested. Shooting the other node in the head and then turning the revolver on oneself due to a corner case in the protocol timeout had better never happen on a mission-critical service. Never. (I'm looking at you, Veritas Cluster Server.)

So where does that leave us? As I said, a great deal depends on the implementation, which can really only be sounded out through real-world experience. I think a reasonable strategy might be to start small and incrementally consolidate features, and to remember that just because a box can run all your VPN tunnels, load balance your web servers, and authenticate your wireless users, doesn't necessarily mean it should. I'm trying to get an eval unit of Juniper/Netscreen's SSG 500 boxes, and I"m still looking for other suitable products that might fit the bill.  My requirements, in addition to the concerns I already listed:

• must block bittorrent and other polymorphic P2P protocols (this was the instigation for my search)
  
• must have a decent traffic shaping setup, CBQ would be nice (Alack, Xedia, we hardly knew ye)
• must have decent site-to-site VPN interoperability (ideally with support for far-side roaming addresses)
• should have good SNMP-ability and preferably netflow type session data exports (no thanks, Netscreen Global Pro)