ACLs vs. full firewalls

Mailman List Mirror (Read Only)
1

Hi all,
  One of the duties of my current place of employ is reorganizing the
network. We have a few Catalyst 6500 series L3 switches, but currently
do all packet filtering (and some routing) using a software based
firewall. Don't ask me, I didn't design it :slight_smile:

  Current security requirements are only based on TCP and non-stateful
UDP src/dst net/port filtering, and so my suggestion was to use ACLs
applied on the routed interface of each VLAN. There was some talk of
using another software based firewall or a Cisco FWSM card to filter
traffic at the border, mostly for management concerns. We expect full 1
gig traffic levels today, and 10 gig traffic levels in the future.

  I view ACLs as being a cheap, easy to administrate solution that
scales with upgrades to new interface line speeds, where a full stateful
firewall isn't necessary. However, I wanted to get other opinions of
what packet filtering solutions people use in the border and in the
core, and why.

  What's out there, and why do you guys use it? How do you feel about
the scalability, performance, security, and manageability of your
solution? What kind of traffic levels do you put through it?

2

Current security requirements are only based on TCP and non-stateful
UDP src/dst net/port filtering, and so my suggestion was to use ACLs
applied on the routed interface of each VLAN. There was some talk of
using another software based firewall or a Cisco FWSM card to filter
traffic at the border, mostly for management concerns. We expect full 1
gig traffic levels today, and 10 gig traffic levels in the future.

The FWSM can handle 1 Gb/s but not 10. The connection between the FWSM and the backplane is a 6x1 Gig Etherchannel, and the published max throughput is about 5.5 Gb/s, but I've never stressed one to more than about 35% of that in a production environment.

The only Cisco firewalls that I'm awre of today that are rated to 10 Gb/s or more are the ASA 5580-20 and 5580-40, but how suitable they'd be for you depends very much on our design goals, including how complex your firewall rules and service policies will be. You might also be able to shoe-horn an ASR into this role. Other considerations include functional support for IPv6, long term support strategy/development roadmap, whether you need to support VPN traffic directly on your firewall, etc... Cisco seems to be moving away from IPSEC for remote access VPNs and pushing people toward SSL.

There are some other interesting offerings from Juniper/Netscreen, Palo Alto, and others, unless you're specifically married to Cisco gear.

I view ACLs as being a cheap, easy to administrate solution that
scales with upgrades to new interface line speeds, where a full stateful
firewall isn't necessary. However, I wanted to get other opinions of
what packet filtering solutions people use in the border and in the
core, and why.

ACLs can be used as part of a 'defense in depth' strategy, though if you need stateful filtering, their utility might be somewhat limited. If there is traff that you know you don't care about, you can block it with an ACL and save the resources on your firewall. Just remember that those same ACLs can complicate your troubleshooting efforts when something does break.

jms

3

Michael,

Do you have logging or audit requirements to your filters?
We use ACLs almost everywhere for non-stateful filtering, but
there are a few locations (e.g. HIPPA) that require an
audit trail which is perhaps better accomplished by a firewall.

Eric :slight_smile:

4

Hi all,
  One of the duties of my current place of employ is reorganizing the
network. We have a few Catalyst 6500 series L3 switches, but currently
do all packet filtering (and some routing) using a software based
firewall. Don't ask me, I didn't design it :slight_smile:

  Current security requirements are only based on TCP and non-stateful
UDP src/dst net/port filtering, and so my suggestion was to use ACLs
applied on the routed interface of each VLAN. There was some talk of
using another software based firewall or a Cisco FWSM card to filter
traffic at the border, mostly for management concerns. We expect full 1
gig traffic levels today, and 10 gig traffic levels in the future.

  I view ACLs as being a cheap, easy to administrate solution that
scales with upgrades to new interface line speeds, where a full stateful
firewall isn't necessary. However, I wanted to get other opinions of
what packet filtering solutions people use in the border and in the
core, and why.

ACLs are a cheap solution; ease of administration depends on your
scale in terms of number of entries. Keep in mind that depending
on your hardware platform, using ACLs can run into unexpected
limitations. If you're considering doing this on the 6500 platform,
read up on TCAM limitations and L4Op/LOU operator limits:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp43433

It can be a very rude awakening when you add one more seemingly
innocuous ilne to your ACL, and discover the entire thing has suddenly
gone into software switched mode.

With that caveat aside, there are many large sites that do make
use of ACLs as part of their security repetoire. It's definitely
something to consider, just be aware of your hardware platform's
limitations before diving in headfirst.

Matt

5

Hi all,
  One of the duties of my current place of employ is reorganizing the
network. We have a few Catalyst 6500 series L3 switches, but currently
do all packet filtering (and some routing) using a software based
firewall. Don't ask me, I didn't design it :slight_smile:

  Current security requirements are only based on TCP and non-stateful
UDP src/dst net/port filtering, and so my suggestion was to use ACLs
applied on the routed interface of each VLAN. There was some talk of
using another software based firewall or a Cisco FWSM card to filter
traffic at the border, mostly for management concerns. We expect full 1
gig traffic levels today, and 10 gig traffic levels in the future.

  I view ACLs as being a cheap, easy to administrate solution that
scales with upgrades to new interface line speeds, where a full stateful
firewall isn't necessary. However, I wanted to get other opinions of
what packet filtering solutions people use in the border and in the
core, and why.

It seems there is a trend towards moving host protection on to the
hosts themselves, onto or closer to the resource or entity being
protected. It's basically following the cliche, "If you want something
to be done properly, you need to do it yourself."

http://www.opengroup.org/jericho/ - they call it "de-perimeterization"

I first came across the idea in this article:

http://www.cs.columbia.edu/~smb/papers/distfw.html

If you move to the host-based firewalling model, plain packet
filtering ACLs at the perimeter would be quite an adequate form of a
first level of defence, while also avoiding the performance overhead
of (or resources required to perform) stateful tracking of large
amounts of traffic.

Regards,
Mark.

6

Beware off using ACL filtering on 6500s with many vlans (100+) and long
acls (hundred+ lines)...

You'll soon find out more than you ever wanted to know about TCAM,
different TCAM types used in various sup's and what the limitations
imposed by TCAM on processing ACLs in hardware...

Sam Crooks

7

While there are no specific audit requirements, overall traffic auditing
(not just for dropped packets) is definitely something I'm considering.
One way of gathering this data without using a firewall would seem to be
netflow; I don't think netflow specifically calls out (or even shows?)
traffic blocked by ACLs though, which could be a point for consideration.

Eric Gauthier wrote:

8

It seems there is a trend towards moving host protection on to the
hosts themselves, onto or closer to the resource or entity being
protected. It's basically following the cliche, "If you want something
to be done properly, you need to do it yourself."

And IPv6 tends to push security back onto hosts, too.

If you move to the host-based firewalling model, plain packet
filtering ACLs at the perimeter would be quite an adequate form of a
first level of defence, while also avoiding the performance overhead
of (or resources required to perform) stateful tracking of large
amounts of traffic.

And a combination of the two - if you *are* performing more complex
checks deeper inside the network, packet filtering can reduce the load
that actually reaches those inner check points.

I'd be interested to hear why people use firewalls. I've never felt the
need, myself - am I living in a fool's paradise?

Regards, K.

9

End hosts are not always trustworthy.

If a host is compromised, should it be able to send anything and everything out to the public network?
If a host is a desktop PC controlled by an end user, should it be able to send and receive anything it wants?

IMO, host based filtering and ACLs (either firewalls or router ACLs or whatever) in the network should both be used. They fulfil different needs.

10

A packet filter looks at the "top surface" of the packet, and processes
the packet accordingly - based on things like the protocol, the source
address, the destination address, the TCP flags and so on.

A firewall, on the other hand, makes decisions based on knowledge about
the data being carried.

I.e., firewall != packet filter; my question related to firewalls.

Regards, K.

11

A packet filter is often part of a firewall, though it's usually not a
complete solution. However, I'd disagree with your blanket assertion.
A better way to phrase it is that a firewall at a given level cannot
protect against attacks at a different level. Packet filters don't
block SMTP weirdness or filter Evilscript from web pages; web proxies
don't guard against, say, ACK scans. It's like it says on the tube of
toothpaste: a packet filter (or for that matter, a firewall) is an
effective security device if used as part of a program of good network
hygiene and regular professional care.

    --Steve Bellovin, http://www.cs.columbia.edu/~smb

12

Stateless ACLs in hardware at the edge are important both for infrastructure self-protection (i.e., iACLs) and for policy enforcement of the type you indicate. As others on this thread have pointed out, do understand your platform characteristics and craft your ACLs accordingly.

Stateful - i.e., context-aware bidirectional - filtering via a firewall makes sense in situations in which a) the nodes 'behind' the firewall aren't typically operating as servers and/or b) the bidirectional communications patterns which should be observed are well-known, and in which the participation of hosts is under the control/influence of the network operator. For example, in front of a corporate LAN, or between the tiers of a multi-tiered application, one can craft quite specific stateful inspection rules which can be used to explicitly allow and disallow certain types of traffic.

For front-end, publicly-accessible conventional servers, stateful inspection may not add as much value, as basically every connection which comes into those servers is unsolicited (i.e., no existing stateful communications context against which to measure pass/fail decisions); this is where high-speed stateless ACLs, coupled with host OS/app/service hardening play a key role. It's very important to avoid the instantiation of unnecessary state in front of public-facing assets, as DDoS attacks are essentially attacks against capacity and against state.

One should also look into implementing DDoS mitigation techniques such as S/RTBH, in conjunction with the chosen policy-enforcement regime.

13

For Defense in depth I would use multi-tiered approach.

Stateless ACL at Border for bound checks
Stateful FW for Checking sessions
Outbound ACLs on Innerchoke points
Application Intelligence and DDOS mitigation by IPS between Border and
Firewall
Endpoint Security using Enterprise Anti-Virus agents/NAC Agents

Regards

Ubaidali Abdul Razack
+65.65436404 (Office)
+65.65436278 (Fax)

Roland Dobbins <rdobbins@cisco.com>
04/08/2009 08:28 AM

To
NANOG list <nanog@nanog.org>
cc

Subject
Re: ACLs vs. full firewalls

However, I wanted to get other opinions of what packet filtering
solutions people use in the border and in the
core, and why.

Stateless ACLs in hardware at the edge are important both for
infrastructure self-protection (i.e., iACLs) and for policy
enforcement of the type you indicate. As others on this thread have
pointed out, do understand your platform characteristics and craft
your ACLs accordingly.

Stateful - i.e., context-aware bidirectional - filtering via a
firewall makes sense in situations in which a) the nodes 'behind' the
firewall aren't typically operating as servers and/or b) the
bidirectional communications patterns which should be observed are
well-known, and in which the participation of hosts is under the
control/influence of the network operator. For example, in front of a
corporate LAN, or between the tiers of a multi-tiered application, one
can craft quite specific stateful inspection rules which can be used
to explicitly allow and disallow certain types of traffic.

For front-end, publicly-accessible conventional servers, stateful
inspection may not add as much value, as basically every connection
which comes into those servers is unsolicited (i.e., no existing
stateful communications context against which to measure pass/fail
decisions); this is where high-speed stateless ACLs, coupled with host
OS/app/service hardening play a key role. It's very important to
avoid the instantiation of unnecessary state in front of public-facing
assets, as DDoS attacks are essentially attacks against capacity and
against state.

One should also look into implementing DDoS mitigation techniques such
as S/RTBH, in conjunction with the chosen policy-enforcement regime.

14

MS is doing something very Jerico'ish with "DirectAccess" ... very loosely,
"Automagic IPsec + IPv6 (via Teredo when needed) + AD-based auth"
(MS's previous step was SDI (Server Domain Isolation))

/TJ

From: Mark Smith
[mailto:nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org]
Sent: Tuesday, April 07, 2009 5:34 PM
To: Michael Helmeste
Cc: nanog@nanog.org
Subject: Re: ACLs vs. full firewalls

Hi all,
  One of the duties of my current place of employ is reorganizing the
network. We have a few Catalyst 6500 series L3 switches, but currently
do all packet filtering (and some routing) using a software based
firewall. Don't ask me, I didn't design it :slight_smile:

  Current security requirements are only based on TCP and non-stateful
UDP src/dst net/port filtering, and so my suggestion was to use ACLs
applied on the routed interface of each VLAN. There was some talk of
using another software based firewall or a Cisco FWSM card to filter
traffic at the border, mostly for management concerns. We expect full
1 gig traffic levels today, and 10 gig traffic levels in the future.

  I view ACLs as being a cheap, easy to administrate solution that
scales with upgrades to new interface line speeds, where a full
stateful firewall isn't necessary. However, I wanted to get other
opinions of what packet filtering solutions people use in the border
and in the core, and why.

It seems there is a trend towards moving host protection on to the hosts
themselves, onto or closer to the resource or entity being protected. It's
basically following the cliche, "If you want something to be done properly,

you

need to do it yourself."

http://www.opengroup.org/jericho/ - they call it "de-perimeterization"

I first came across the idea in this article:

http://www.cs.columbia.edu/~smb/papers/distfw.html

If you move to the host-based firewalling model, plain packet filtering

ACLs at

15

> It seems there is a trend towards moving host protection on to the
> hosts themselves, onto or closer to the resource or entity being
> protected. It's basically following the cliche, "If you want something
> to be done properly, you need to do it yourself."

And IPv6 tends to push security back onto hosts, too.

> If you move to the host-based firewalling model, plain packet
> filtering ACLs at the perimeter would be quite an adequate form of a
> first level of defence, while also avoiding the performance overhead
> of (or resources required to perform) stateful tracking of large
> amounts of traffic.

And a combination of the two - if you *are* performing more complex
checks deeper inside the network, packet filtering can reduce the load
that actually reaches those inner check points.

Which would address my concern of just passing along the [D]DOS to the
host. Mitigating attacks at the border and letting the hosts allow
what they specifically need is a good model.

I'd be interested to hear why people use firewalls. I've never felt the
need, myself - am I living in a fool's paradise?

By your email I'll assume you've never had to deal with HIPPA[1] or
SOx[2]. That aside I see a value in using a stateful FW that does
packet inspection to validate the type of traffic over a certain port
should really be there.

-r

[1] http://en.wikipedia.org/wiki/HIPPA
[2] http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act