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 :) 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?
On Tue, 7 Apr 2009, Michael Helmeste wrote:
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
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 :) On Tue, Apr 07, 2009 at 01:05:31PM -0700, Michael Helmeste wrote:
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 :)
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?
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:
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 :) [...]
On 4/7/09, Michael Helmeste <mhelmest@uvic.ca> wrote:
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 :)
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_paper09... 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
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?
On Tue, 07 Apr 2009 13:05:31 -0700 Michael Helmeste <mhelmest@uvic.ca> wrote:
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 :)
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.
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?
On Wed, 2009-04-08 at 07:04 +0930, Mark Smith wrote:
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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
On 8/04/2009, at 10:32 AM, Karl Auer wrote:
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?
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. -- Nathan Ward
On Wed, 2009-04-08 at 10:46 +1200, Nathan Ward wrote:
I'd be interested to hear why people use firewalls.
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?
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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
On Wed, 08 Apr 2009 09:20:34 +1000 Karl Auer <kauer@biplane.com.au> wrote:
On Wed, 2009-04-08 at 10:46 +1200, Nathan Ward wrote:
I'd be interested to hear why people use firewalls.
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?
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.
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
On Wed, Apr 08, 2009 at 08:32:02AM +1000, Karl Auer wrote:
On Wed, 2009-04-08 at 07:04 +0930, Mark Smith wrote:
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
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
-----Original Message----- 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
On Tue, 07 Apr 2009 13:05:31 -0700 Michael Helmeste <mhelmest@uvic.ca> wrote:
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 :)
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.
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?
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 -----Original Message----- From: Michael Helmeste [mailto:mhelmest@uvic.ca] Sent: Tuesday, April 07, 2009 3:06 PM To: nanog@nanog.org Subject: 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 :) 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?
On Apr 8, 2009, at 4:05 AM, Michael Helmeste wrote:
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. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // +852.9133.2844 mobile Our dreams are still big; it's just the future that got small. -- Jason Scott
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 On Apr 8, 2009, at 4:05 AM, Michael Helmeste wrote:
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. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // +852.9133.2844 mobile Our dreams are still big; it's just the future that got small. -- Jason Scott Please consider the environment before printing this e-mail. _______________________ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is being sent by 3Com for the sole use of the intended recipient(s) and may contain confidential, proprietary and/or privileged information. Any unauthorized review, use, disclosure and/or distribution by any recipient is prohibited. If you are not the intended recipient, please delete and/or destroy all copies of this message regardless of form and any included attachments and notify 3Com immediately by contacting the sender via reply e-mail or forwarding to 3Com at postmaster@3com.com.
participants (13)
-
Crooks, Sam -
Eric Gauthier -
Justin M. Streiner -
Karl Auer -
Mark Smith -
Matthew Petach -
Michael Helmeste -
Nathan Ward -
Ravi Pina -
Roland Dobbins -
Steven M. Bellovin -
TJ -
ubaidali_abdul_razack＠3com.com