I should have clarified that better. I wouldn't manage a corporate network without a centrally managed firewall (stateful; or not). Depending on host security alone, especially Windows desktops, isn't something I would care to be a part of. Some IPv6 pundits have pushed the idea of re-establishing the norm of end-to-end connectivity without regard to anything other than host security. This may be fine for educational, residential, and/or public networks, but IMHO a really bad idea for corporate networks. Compliance and auditing are only a few of the issues. BTW, There are a number of reasons for coroporate use of source and destination NATing that have nothing to do with the type of security that has been discussed. For example: 1) We have a business partner that requires all access to their data come from a small IP range (1-4 addresses). We have a distributed batch system that downloads/processes nightly data. We had to implement NAT so that all of our machines appear to come from those 4 address. I made it known how easy it was to defeat their access security, and how inane it was. I spoke directly to their VP of IT, and it didn't matter. If we wanted their data, we had to comply. Since no other company provides that data, we had to use NAT. Elegant design always loses to practical concerns. 2) We use source and destination nat via our extranet provider (BT-Radianz) over private lines. NAT is done for a number of reasons including traffic engineering and network information hiding. Most of the partners on the other side of the extranet have very tight ACLs. If we were to need to change our source IP, it would take a miracle to get it changed on their side short of 3-4 weeks. That's the world some people live in. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 -----Original Message----- From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] On Behalf Of Christopher Morrow Sent: Tuesday, April 22, 2014 3:46 PM To: Matthew Huff Cc: Brian Johnson; nanog@nanog.org Subject: Re: Requirements for IPv6 Firewalls On Tue, Apr 22, 2014 at 3:41 PM, Matthew Huff <Matthew.Huff@ox.com> wrote:
I think some of the disconnect is the difference between a provider network and a corporate one.
For example, www.foo.com if it is highly visible and has a high traffic rate would have load balancers and line rate routers, but no statefull firewalls.
Corporate foo.com, on the other hand, where end-users, and internal servers reside, almost certainly has a statefull firewall.
doesn't this come down to design of the whole system though? or rather, I bet roland would point out that this comes down to the design of the whole system... and tradeoffs folk decide to make/break. watching a corporate mail server complex melt down because some 'well intentioned admin' put a stateful firewall (with a single rule; "permit smtp"!) in front of the mail servers ... Having to explain to them (and losing because 'policy') that 'permit tcp any any eq 25' was more effective and better for their systems health was quite painful. eventually the CIO didn't listen and he works elsewhere.
Personally, if I were told to use only host based security on a corporate network and no central administrated firewall, I'd be shopping my resume.
why? sure there's a place for things like firewalls, but there's also a fine place for just 'drop packets with filters and don't maintain state'. it really comes down to the design goals of the whole system. -chris
---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039
-----Original Message----- From: Christopher Morrow [mailto:morrowc.lists@gmail.com] Sent: Tuesday, April 22, 2014 3:18 PM To: Brian Johnson Cc: nanog@nanog.org Subject: Re: Requirements for IPv6 Firewalls
On Tue, Apr 22, 2014 at 2:55 PM, Brian Johnson <bjohnson@drtel.com> wrote:
Eric,
If you read what he posted and really believe that is what he is saying, you need to re-think your career decision. It is obvious that he is not saying that.
Roland's saying basically: 1) if you deploy something on 'the internet' you should secure that something 2) the securing of that 'thing' should NOT be be placing a stateful device between your users and the 'thing'.
In a simple case of: "Put a web server on the internet"
Roland's advice breaks down to: 1) deploy server 2) put acl on upstream router like: permit tcp any any eq 80 deny ip any any 3) profit
The router + acl will process line-rate traffic without care.
-chris
I hate it when threads breakdown to this type of tripe and ridiculous restatement of untruths.
- Brian
-----Original Message----- From: Eric Wieling [mailto:EWieling@nyigc.com] Sent: Tuesday, April 22, 2014 1:16 PM To: Dobbins, Roland; nanog@nanog.org Subject: RE: Requirements for IPv6 Firewalls
It seems to me you are saying we should get rid of firewalls and rely on applications network security.
This is so utterly idiotic I must be misunderstanding something. There are a few things we can count on in life, death, taxes, and application developers leaving giant security holes in their applications.
-----Original Message----- From: Dobbins, Roland [mailto:rdobbins@arbor.net] Sent: Saturday, April 19, 2014 12:10 AM To: nanog@nanog.org Subject: Re: Requirements for IPv6 Firewalls
You can 'call' it all you like - but people who actually want to keep their servers up and running don't put stateful firewalls in front of them, because it's very easy to knock them over due to state exhaustion. In fact, it's far easier to knock them over than to knock over properly-tuned naked hosts.
Also, you might want to search the NANOG email archive on this topic. There's lots of previous discussion, which boils down to the fact that serious organizations running serious applications/services don't put stateful firewalls (or 'IPS', or NATs, et. al.) in front of their servers.
The only way to secure hosts/applications/service against compromise is via those hosts/applications/services themselves. Inserting stateful middleboxes doesn't actually accomplish anything to enhance confidentiality and integrity, actually increases the attack surface due to middlebox exploits (read the numerous security notices for various commercial and open-source stateful firewalls for compromise exploits), and has a negative impact on availability.