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

[Geoffrey Myers]

Does anyone else have a MHW email folder devoted to Michael?  Great 
stuff Michael, keep it coming.

Michael H. Warfield wrote:
> 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
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo


-- 
Until later, Geoffrey

"I predict future happiness for America if they can prevent
the government from wasting the labors of the people under
the pretense of taking care of them."
- Thomas Jefferson