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.
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.
On 04/22/2014 01:15 PM, Matthew Huff wrote:
I wouldn't manage a corporate network without a centrally managed firewall (stateful; or not).
Matthew, No one is saying that. What Roland is saying, and the position that I agree with, is that putting a firewall in front of a system _that is intended to be ON the Internet, serving external users_, is a bad idea. I think it's a given that you'd want to protect your internal systems with a firewall (except for the aforementioned IPv6 illuminati, of whom I am not one). Doug
As long as the various stateful firewalls and IDS systems offer hostile action detection and blocking capabilities that raw webservers lack, there are certainly counterarguments to the "port filter only" approach being advocated here. Focusing only on DDOS prevention from one narrow range of attack vectors targeting the firewalls themselves is narrowminded. The security threat envelope is pretty wide. Vulnerabilities of similar nature exist on the webservers themselves, and on load balancer devices you will likely need anyways. Any number of enterprises have chosen that if a DDOS or other advanced attack is going to be successful, to let that be successful in bringing down a firewall on the external shell of the security envelope rather than having penetrated to the servers level. Smart design can also handle transparently failing over should such a vendor-specific attack succeed. The idea that anyone doing real, big complex networks would or has to accept any SPOF is ludicrous. The question is, how important is avoiding SPOFs, and how committed you are. If the answer is "absolutely must, and we have enough budget to do so" then it's entirely doable. On Tue, Apr 22, 2014 at 1:28 PM, Doug Barton <dougb@dougbarton.us> wrote:
On 04/22/2014 01:15 PM, Matthew Huff wrote:
I wouldn't manage a corporate network without a centrally managed firewall (stateful; or not).
Matthew,
No one is saying that. What Roland is saying, and the position that I agree with, is that putting a firewall in front of a system _that is intended to be ON the Internet, serving external users_, is a bad idea.
I think it's a given that you'd want to protect your internal systems with a firewall (except for the aforementioned IPv6 illuminati, of whom I am not one).
Doug
-- -george william herbert george.herbert@gmail.com
On 04/22/2014 01:49 PM, George Herbert wrote:
As long as the various stateful firewalls and IDS systems offer hostile action detection and blocking capabilities that raw webservers lack, there are certainly counterarguments to the "port filter only" approach being advocated here.
Right, but now you're talking about something other than just a firewall.
Focusing only on DDOS prevention from one narrow range of attack vectors targeting the firewalls themselves is narrowminded. The security threat envelope is pretty wide. Vulnerabilities of similar nature exist on the webservers themselves, and on load balancer devices you will likely need anyways.
Again, sure, but removing a needless firewall from the equation is one less thing to worry about.
Any number of enterprises have chosen that if a DDOS or other advanced attack is going to be successful, to let that be successful in bringing down a firewall on the external shell of the security envelope rather than having penetrated to the servers level.
And if they are making that choice proactively who am I to argue? I disagree, but their network, their rules. What usually happens though is that enterprises believe that the firewall will protect them, without understanding that it can actually create a SPOF instead.
Smart design can also handle transparently failing over should such a vendor-specific attack succeed. The idea that anyone doing real, big complex networks would or has to accept any SPOF is ludicrous. The question is, how important is avoiding SPOFs, and how committed you are. If the answer is "absolutely must, and we have enough budget to do so" then it's entirely doable.
Of course. Doug
On 22 Apr 2014, at 22:49, George Herbert <george.herbert@gmail.com> wrote:
Any number of enterprises have chosen that if a DDOS or other advanced attack is going to be successful, to let that be successful in bringing down a firewall on the external shell of the security envelope rather than having penetrated to the servers level.
And I don’t think there’s problem with that approach. The problem starts, when those anonymous enterprises “silently" expect, that: a) firewall will somehow magically defend the network, scrub the “bad” traffic and let good traffic pass (“that’s why we’ve paid for state of the art firewall, right?!”) b) firewall will fail gracefully, taking down all services, and doing real hole in the transport and not jabbing some packets there and there, maybe malformed, maybe parts of different connections crammed in wrong headers… until reboot; and the reboot may not be also totally transparent, as links will go up, down, init, and so on c) insert your own horror-story here …and using those assumptions to advocate for stateful firewall everywhere. If you’re aware of that assumptions, and you’re aware of the constraints we’re facing with actually developing working edge defence for the network, you’ll be anyway advocating creation of a funnel - with stateless first lines od defense, taking care of all the trash that can come from the internet, and rate-limiting the traffic that seems to be legitimate if above certain thresholds. And at that point - stateful firewall may not be needed anymore, because service itself can scale better. Nowadays, enterprise networks are picking up best practices from SPs, where scale does matter and networks are built to actually have that characteristics. Anycast DNS is often found in enterprise networks, as well as other anycasted services (usually in “shared IP” model) - mail, web, AAA and other services. The same goes for actually protecting the internet edge. How often your network is being DDoSed? Be it 300kpps or 5Mpps, how will your stateful firewall at the edge of it deal with it? And by the way, when we’re speaking about internet visible services - how many stateful firewalls defend www.google.com? Or www.amazon.com? Or OpenDNS servers? Or 8.8.8.8/8.8.4.4? I bet none. But would love to hear from people maintaining them. -- "There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromirski@jabber.org about." John von Neumann | http://lukasz.bromirski.net
participants (5)
-
Christopher Morrow -
Doug Barton -
George Herbert -
Lukasz Bromirski -
Matthew Huff