[fw-wiz] ***SPAM*** Re: IPv6 support in firewalls

Patrick, you make some valid points.

- yes, it's true that social engineering and leaks will undermine
attempts to keep internal topology details private. If someone's willing to leak this sort of confidential information I suspect they will reveal other details that put you at risk whether you are using private or public space.

- Yes, double NAT'ing is not a pretty thing.

- My crystal ball only says that if I'm building inter-organizational tunnels to connect parties outside my operational control directly to assets on my internal network I probably have much worse security problems to fret about than IP addresses. I'm not a fan of site-to-site VPNs and "you authenticated using IKE so welcome to my subnet" implementations but that takes us down another nasty rathole. IMO there are alternatives to admitting hosts as IP addressable peers to your network. However if this is the poison you choose to drink, you're right that having unique IP addresses makes it easier to swallow.

- I'm happy to hear a large scale IPv6 success story.

- I wish I could feel as confident about IPv6. Nearly 14 years have lapsed and I confess that my perspective is jaded. I think it may be another 5 before we see measurable IPv6 penetration and at least a decade beyond of 4-to-6 and 6-to-4 tunneling (and NAT).

We will have a 20 year old protocol with little innovation and only unique addresses to show for our efforts. NAT may have been a cheap hack. Time will tell whether IPv6 is regarded as the right thing or an expensive hack. So I'll set a cask of beer aside and we'll revisit the subject again in 2012.



Patrick M. Hausen wrote:
Hi!

On Mon, Aug 27, 2007 at 01:24:54PM -0400, Dave Piscitello wrote:

First you should not rely on NAT as a security measure, anyway,
because it isn't.
I advocate using every measure possible to provide security. IP masquerading helps thwart information gathering. I would never suggest using NAT as the only security measure. By IP masquerading, I avoid having a RIR identify the address blocks I use internally, as they would if I were to use public space. Explain why you feel this is wrong?

I don't feel this is wrong, I think good security practice
should be to make it unnecessary by design. The security
of a cipher should not depend on the secrecy of the algorithm.

The security of a network should not depend on the secrecy of
the structure, because sooner or later secrets will be no longer.

A bit of social engineering, a fired insider, ... holds for
ciphers and for networks, IMHO. And I mean *should* as in
RFC language, not as in common English ;-)

Third, this is the _only_ way to get rid of the "net 10 considered
harmful" nightmare
It's only a nightmare for people who do not exercise discipline
in assigning addresses.

OK, so please hand me a list of the RFC 1918 networks of all
third parties that I will need to connect to in the next ten
years. Your crystal ball seems to be working a lot better than
mine ;-)) No insult intended, honestly, but I don't buy the
"discipline" argument. Different enterprises need to connect
as business dictates, possibly tomorrow. And double NATing
and proxying makes things worse, not better.

As I said, SAP is already using addresses from their RIPE assigned
allocation for their strictly internal VPN connections to customers.
That would be "Oracle" for you American guys ;-) Biggest German
software company ...

I could just as easily err with public addresses and assign the same block of addresses to multiple sites.

Yes you can. But then it's your fault. And if the successor of
the successor for your former position gets it wrong, then either
you or the first successor did not document properly.

But the addresses of arbitraty peers are strictly outside of
my control ...

Uniqe addresses for every single device. You can still hide
them behind a proxy if you feel like it. That's the additional
benefit. You can decide which hosts to expose and which ones
to hide. With at least a /48 assigned to every end user, there's
plenty of maneuver room.

Compare that to an IPv4 /29 for your uplink and all of a sudden a
7th department wants a server with port 80 exposed to the
Internet.

IMHO theses are the combined reasons to start over and
kill NAT forever.
Won't happen in my lifetime, nor my childrens' lifetime.

Time will tell ;-) I won't bet more than, say, a cask of
beer on my position, but I strongly feel like it was
The Right Thing [tm] and NAT was a cheap hack that has
been far too successful.

Kind regards,
Patrick M. Hausen
Leiter Netzwerke und Sicherheit
begin:vcard
fn:David Piscitello
n:Piscitello;David
adr;dom:;;3 Myrtle Bank Lane;Hilton Head;SC;29926
email;internet:dave@xxxxxxxxxxx
x-mozilla-html:FALSE
url:http://hhi.corecom.com/weblogindex.htm
version:2.1
end:vcard

_______________________________________________
firewall-wizards mailing list
firewall-wizards@xxxxxxxxxxxxxxxxxxxxx
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

Relevant Pages

  • Re: Cable Vs. DSL
    ... Well, its likely that he is using a Linksys or D-link NAT enabled router, ... >>is what the clients are seen to have from the internet. ... >security measure, it's merely a way to broaden the available address ...
    (Security-Basics)
  • Re: How exposed am I?
    ... > addition to NAT? ... For a small business solution, you may want to look at a WatchGuard FW ... I don't think you can take security on the Internet lightly in today's ...
    (comp.security.firewalls)
  • Re: Performance improvement for NAT in IPFIREWALL
    ... NAT is not a security feature. ... provides no better security than the packet-filtering firewall would alone. ... any network topology, which connects to the Internet, IMHO. ...
    (freebsd-net)
  • Re: How do I share files (securely) using wifi modem/router?
    ... the internet" when file and printer sharing are enabled. ... vaguely refer to something you call "ways to get through NAT". ... a little bit of security is often far worse than no ... see Section 9.0 (Security Considerations) of RFC 2663 ...
    (alt.internet.wireless)
  • [NT] Vulnerability in Microsoft Data Access Components Allows Code Execution (MS07-009)
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... Get your security news from a reliable source. ... this vulnerability by preventing Active Scripting and ActiveX controls ... mode sets the security level for the Internet zone to High. ...
    (Securiteam)