[ipv6hackers] Is there a telecom company which adpated IPv6 network on LTE?
Enno Rey
erey at ernw.de
Mon Aug 19 15:23:37 CEST 2013
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
=======================================================
More information about the Ipv6hackers
mailing list