[ipv6hackers] Is there a telecom company which adpated IPv6 network on LTE?

[Johannes Weber]

Hi everybody,

a few month ago I wrote an article about the misunderstandings concerning NAT
security. It can be found here:
http://blog.webernetz.net/2013/05/21/why-nat-has-nothing-to-do-with-security/

Regards,

Johannes


> Enno Rey <erey at ernw.de> hat am 19. August 2013 um 15:23 geschrieben:
>
>
> Hi,
>
> >
> > As I mentioned already, I have yet to find a security officer (except the
> > ones that rely mostly on pre-canned security assumptions such as "in my
> > GIAC training book at page 15 it's written NAT is not a security measure")
> > that doesn't like NAT.
>
> I know quite a few (who don't like NAT)...
> and I know environments where using NAT at certain intersection points is
> strictly forbidden.
> For a simple reason: without NAT there's usually some isolation property
> between RFC 1918 space and the Internet. enabling NAT breaks that exact
> isolation and hence _enables_ communication paths (and not every sec officer
> is happy about _enabled_ communication, with regard to assets to be
> protected).
> Just ask one of them about her happiness when it comes to periodically
> auditing the $SOME_HUNDRED_ADDITIONAL_NAT_RULES on the tab (on
> $ORG_STATEFUL_FW) next to the $SOME_THOUSAND_FILTERING_RULES.
>
> thinking that NAT prevents communication (by "hiding" something) is a gross
> misunderstanding. Actually NAT _enables_ communication. that's its very
> purpose, see RFC 1631.
>
> best
>
> Enno
>
>
>
>
>
>
> >
> > About logging, I have yet to see carrier grade of GI firewalls that logs
> > *every* connection coming in an out, but I see every day firewalls that log
> > every NAT translation. However I understand that this may depend on the
> > technology and the personal experience.
> >
> > I try to avoid making blanked statements based only on my own experience,
> > generally, therefore I feel less certain about the logging part of the
> > discussion - I concede that.
> >
> >
> >
> > > Stateful inspection provides security. To the extent that NAT requires
> > > stateful
> > > inspection, you get Stateful inspection (and it's related security) for
> > > free by
> > > implementing NAT.
> > >
> >
> > Going again out of the commonplace, stateful inspection does not
> > necessarily provide any more security that NAT. The answer is, as usual,
> > "it depends". "Inspecting" a packet does not mean in itself you are
> > actually *doing* anything with that - are you logging or verifying or even
> > denying packets that do not match connection tables? have you enabled
> > source spoofing on your firewall? protocol checks? In my experience often
> > these policies are disabled or just logged - for lots of reasons we may
> > want to discuss off line, as I feel they are off topic here - and often NAT
> > is instead more effective, as at least connection table checking is
> > *necessary* within NAT - it wouldn't work otherwise, plain and simple.
> >
> > Therefore I would go so far to say that if you are "only" inspecting
> > without any policy, then NAT is actually more helpful that stateful checks
> > - at least it is doing something: verifying connection tables and hiding a
> > source network.
> >
> >
> >
> > > However, if your NAT is a stateless 1:1 mapping, then you get no security,
> > > so
> > > clearly NAT is not the part that provides the security.
> > >
> >
> > If it is 1:1 mapping, it is still hiding the source network. Again, it will
> > not refrain determined hackers to undercover my infrastructure but
> > certainly will make them lose more time.
> >
> > I would like to remember that we are anyway talking about a specific case,
> > that is, customers' ISP networks in a mobile environment. We were not
> > making a generic point on NAT. In this scenario, NAT is indeed a mechanism
> > which in itself can protect customers' from overbilling or battery draining
> > attacks, therefore it is a cheap-and-dirty, security-by-obscurity method,
> > but it is effective enough in most cases. I am sure if you want to get
> > perfect protection you'll need something more that that, but in everyday's
> > life you have to make tough budget decisions.
> >
> >
> >
> > > As to logging of the traffic, again, NAT requires a single choke-point to
> > > work.
> > > It is the single chokepoint that provides the easy logging of all traffic,
> > > not the
> > > NAT itself.
> > >
> >
> > I see you are "conceding" me the point that an architecture that includes
> > NAT makes logging easy.
> >
> > I am satisfied with that :-)
> >
> >
> > Kind regards
> > --
> > Marco Ermini
> > root at human # mount -t life -o ro /dev/dna /genetic/research
> > http://www.linkedin.com/in/marcoermini
> > "Jesus saves... but Buddha makes incremental back-ups!"
> > _______________________________________________
> > Ipv6hackers mailing list
> > Ipv6hackers at lists.si6networks.com
> > http://lists.si6networks.com/listinfo/ipv6hackers
>
> --
> Enno Rey
>
> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
> Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 174 3082474
>
> Handelsregister Mannheim: HRB 337135
> Geschaeftsfuehrer: Enno Rey
>
> Troopers 2013 Videos online:
> http://www.youtube.com/user/TROOPERScon?feature=watch
>
> =======================================================
> Blog: www.insinuator.net || Conference: www.troopers.de
> =======================================================
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
> http://lists.si6networks.com/listinfo/ipv6hackers
>