[ale] How to test your public internet connection for open ports

[Michael H. Warfield]

Addressing certain point...

On Sat, 2011-02-12 at 12:28 -0500, Ron Frazier wrote: 
> Hi Michael W.,

<-- snip -->

> Probably true.  However, there's not a lot we can do about it since 
> marketers, and not engineers control the way the products are 
> presented.  We're going to have to reeducate consumers, and maybe 
> management and marketers too, about how IPv6 works.

Ah...  But this is where SG comes it.  He's contributing to the FUD with
inaccurate imprecise statements.  He's the source of a lot of
frustration in that regard.  We have to overcome the preconceived
misconceptions which he's sown, unfortunately.
> > As a security professional I'll go so far as to say you are more secure
> > on IPv6 with no firewall at all, than you are on IPv4 with a firewall or
> > NAT.  Why?  Because IPv6 is 4 billion times more difficult to
> > comprehensively brute force scan a single subnet than it is to scan the
> > IPv4 internet from end to end.  Note:  I'm being VERY precise in that
> > terminology.  Yes, IPv6 can be scanned, especially when people treat it
> > like IPv4 and assign sequential addresses, but you have to use
> > "intelligent" scans and heuristics to choose your targets, you can not
> > simply start at one end of even a single subnet and scan to the other
> > end.  Now put THAT behind a firewall, or have the addresses changing
> > periodically (privacy enhanced addresses) and try scanning for that.
> > Combine that with the deliberate sparse nature of v6 allocations.  IPv4
> > is like shooting fish in a barrel.  You hit a broadband or DSL subnet,
> > you can barely turn around and take a breath without hitting an
> > opportune target.  Now, replace each of those single IPv4 addresses with
> > an IPv6 /64 subnet.  Now you have only 1 change in 18 billion billion of
> > guessing a host address (times the number of machines).  The opportunity
> > to score drops real low and your attack yield is low because the
> > defenders attackable footprint is so much tinier.

> I understand what you're saying.  You may be right.  You're into the 
> realm of statistics and probabilities, which is not my specialty.  I'm 
> intrigued by IPv6, and I like to keep up with new technology, and I'd 
> like to try it.  As you all have discussed, I could get it now by 
> tunneling.  Comcast has recently rolled out native dual stack IPv6 in 
> Colorado for testing.  But, it's not available here yet.  I want to try 
> it, but I am very leery of the security.  I would still want a 
> firewall.  I don't know if those have been created and debugged yet.  
> Also, I don't know if the IPv6 stacks in Windows and Linux randomize the 
> IP addresses chosen for the hosts, or maybe DHCP does that, or maybe 
> nobody does that.  I certainly wouldn't want to reduce my security by 
> opening up a direct IPv6 pathway into my network.  I actually disabled 
> the IPv6 networking components in Windows because I had reason to think 
> they were destabilizing my IPv4 network.

Here are the points I want to respond to.

I actually did not get involved in IPv6 until we had decent firewalls.
I've been involved with IPv6 for over a decade.  Yeah, that's right.
The firewalls have been available for well over 10 years and are at
total parity with IPv6.  The Linux v6 firewall logic is as rock solid as
the v4 logic.  In fact, I believe they (now) share the same state table
engine and central logic.  After all, it's just a different protocol.
The handlers remain the same.  It's all in how you write your rules.

The security you get from NAT can be summed up in 3 iptables rules
(which I posted in another message), this time with a few comments.

# Add rules to accept services here and apply special handling here
# or anywhere before the final reject.

# Accept everything on the internal interface to forward to external
-A FORWARD -i {internal interface} -j ACCEPT

# Master state toggle...  Allows all established connections back in
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Add logging rules for connection attempts here if desired

# Reject everything else - Administratively prohibited.
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

That's it!  That's the totality of the security you get from NAT.  And
the same rules work perfectly fine with either iptables or ip6tables.
Total parity.  You do have two separate tables, one for IPv4 and one for
IPv6, so be sure to included both.

Now, for random addresses...  That's up to you.  There are several
addressing schemes on IPv6.

Stateless Autoconf EUI-64:
IPv6 address is derived from the MAC address and the router advertised
prefix.  The lower 64 bits never change and are based on the interface
MAC address through a well known algorithm (see my presentation).  EUI
remains constant when moving between subnets or other networkds.

Stateless Autoconf Privacy Enhanced addresses:
EUI is assigned at random at boot and may even change with time (time
variant) but doesn't have to (time invariant).  EUI is combined with the
router advertised prefix for a global address.

Stateful Autoconf dhcp6 allocated addresses:
Addresses handed out from a pool from a dhcp server just like IPv4.

Static addresses:
Addresses manually assigned just like IPv6 (DON'T DO IT).

Cryptographic addresses:
EUI is assigned by cryptographic formula.  Uncommon.  Special case.

Rotating addresses:
Any scripted (supervisory) process can add addresses to an interface and
have them work.  Add to DNS using nsupdate.  Rotates security services
through random addresses periodically and addressable through DNS
reference.

Windows defaults to privacy enhanced addresses time-invariant.

Linux defaults to EUI-64.

Not sure what OS/X does.

Any of them can be used in any of the above modes very easily.  You're
choice.

> > Point on the curve.  Years ago a particularly nasty worm called the
> > Whitty worm cut loose on the net.  Its growth was explosive.  Within
> > minutes it overwhelmed routers and networks.  Within a half an hour it
> > had infected well over 12,000 hosts around the world.  It took days to
> > clean up.  I participated in a lot of that.  Because of the unique
> > nature of that worm, I was able to track it in my darknet net-telescope
> > as did CAIDA, a much larger (/8) net telescope.  It was a single packet
> > spoofed UDP based worm that was spoofed "from" a particular port making
> > is rather easy to track and easy to tell when it managed to "sneak"
> > behind a NAT router (I started seeing other ports and multiple ports
> > from teh same address - simple).  It wasn't part of a virus or trojan
> > package, so it only propagated by network traffic alone and it wasn't
> > something you tripped on browsing a web site.  A classical self
> > propagating worm.
> >
> >  From the time I saw the first Whitty worm packets in the aperture of my
> > net-telescope to the time I saw the first indications that it had wormed
> > it's way past a NAT and infected a NAT based network was under 1 minute.
> > We never did determine how it was that it managed to make it past NAT
> > devices, which should have been acting like firewalls, but it did and by
> > the end of the day there were hundreds of NAT based networks that were
> > infected.  I can't say if it snuck past stateful firewalls or not, since
> > I couldn't discriminate that, but I strongly suspect that it would have
> > as well.  Whitty would have never gotten off the ground on an IPv6
> > network.
   
> Those routers may have had a bug in the firmware.  Steve periodically 
> points out various consumer routers that are behaving badly and which 
> need a firmware upgrade or which have a flaw and no patch is available.

Maybe they did and maybe they didn't.  Point is, they were not designed
to provide security in the first place.  The fact that they did provide
some security, for some admittedly extremely common configurations, is
totally beside the point.  NAT is not required to provide security.
There are legitimate configurations of NAT which provide no security.
They could have been misconfigured from a security standpoint but
working perfectly correctly from a NAT stand point.  Is that a bug?  I'm
not sure.

Years ago, there was one NAT device that propagated broadcasts across
the NAT.  If you hit the local subnet address of the public subnet it
was on with a directed broadcast, it obligingly broadcast that to the
devices behind the NAT on that local broadcast address of that private
address space!  It literally NATed the local broadcasts (both ways I
might add).  It was designed that way.  Personally (and this is purely
conjecture on my part) I think it was designed that way to facilitate MS
Windows because Netbios NMB packets broadcast name registration traffic.
This would facilitate making Netbios work in broadcast mode across NAT
devices.  I can see that.  I can believe they honestly believed that
they were doing the "right thing".  It was designed to do NAT and was
not designed to do security.  The vendor tried to argue that it was a
feature and it met the spirit and the letter of the RFCs.  They later
removed that feature (under duress).  Was it a bug?  They said no.  They
probably STILL say no.  That could never happen with IPv6 (no broadcasts
at all and the multicasts are scoped).  I would bet good money that the
one of the few reasons we haven't seen more of that is that most of
these NAT routers are based on Linux (OpenWRT if nothing else) and Linux
never implemented it that way.  That was a proprietary implementation
and that was their interpretation of the standard.  Could it happen
again.  Possible.  Very possible.  Vendors don't learn.

> Sincerely,

> Ron

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110212/2fb1075f/attachment.bin