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

[Michael H. Warfield]

On Thu, 2011-02-10 at 08:47 -0500, Ron Frazier wrote: 
> This is a PS to my prior reply post about configuring the router, with 
> the subject of Shout Outs for good Wirless-N Router for Home.  I decided 
> to give this a new subject.
> 
> Once your system is set up to connect to the internet, you want to make 
> sure neither your modem, nor your router is exposing open ports to the 
> world that you don't intend.  Following is an easy to use and very 
> popular port scanner that you can run from Steve Gibson's website.  It's 
> harmless, but will scan the most commonly used ports on your public 
> address to see if any are open.  If they are, you get a red light on 
> your screen for each open port number.  If they're closed, but still 
> responding and saying "I'm not here" so to speak, you get a blue light.  
> If they are stealthed, meaning giving no response at all to the port 
> scanner, you get a green light.  From a point of view of optimum 
> security, you want all stealth, or green lights.  There are any number 
> of Linux utilities that you can use for this purpose as well, like 
> ZenMap.  However, if you do too many port scans from your home IP, your 
> ISP may think you're a cracker.  Also, port scanning your own public IP 
> from inside your home LAN may not work.  This utility is easy to use, 
> comes from a third party, and is outside your LAN.  Note, this will test 
> the outermost device (closest to the internet) on your public IP.  If 
> your modem is responding to any querys, which it shouldn't unless 
> someone needs remote administration capabilities, which are a security 
> risk, that will show up in the results.  Otherwise, you will be testing 
> your router.

> Before getting into usage, here is some data on CLOSED vs STEALTH ports 
> from Steve's website at https://www.grc.com/su/portstatusinfo.htm .

> quote on -->

> A "Stealth" port is one that completely ignores and simply "drops" any 
> incoming packets without telling the sender whether the port is "Open" 
> or "Closed" for business. When all of your system's ports are stealth 
> (and assuming that your personal firewall security system doesn't make 
> the mistake of "counter-probing" the prober), your system will be 
> completely opaque and invisible to the random scans which continually 
> sweep through the Internet.

See now.  This is one of those perfect examples I use where I say Steve
Gibson's clue elevator just does not hit all the floors.  He writes a
good column for people who are not in the security business but
sometimes he really just missing the mark.  Sometimes his lack of
understanding of underlying protocols is surprising.  I recall some
incident years ago on the kernel mailing list where some anti-DDoS
proposal of his reached the list proclaiming "The end of DDoS!"  It
really only affected SYN flood DDoSs even if it could have worked and it
wouldn't even have worked for that.  He just really didn't understand
how the protocols and stacks worked and hadn't really considered all the
aspects.  And it certainly wasn't the end of all DDoS as he so proudly
proclaimed.  But it got him press and coverage, so I guess it served him
well.

So...  What's the difference between "dropping" a packet (what he's
calls stealth and what nmap calls filtered) and rejecting a packet
(default is PKT_FILTERED or administratively denied).  I would argue,
absolutely none of any real significance.  You can still differentiate
ports which are "closed" (you get either an UNREACH PORT_UNREACH or you
get a TCP RESET) from those that are "open" (to you) and you can still
differentiate the IP address as active from adjoining addresses which
are not (returns ICMP UNREACH HOST_UNREACH).

One difference is that it CAN now be abused in DDoS attacks if you are
dropping all packets.  If someone uses it as a spoofing source for SYN
floods, it can be abused because it doesn't return resets, which would
break the SYN flood.  Doh!  It could also be used in other "spoofing"
attacks where a returned reset or reject would spoil all the fun.

"Stealth" isn't stealth because "not there" is not "stealth".  It stands
out against a backdrop of "HOST_UNREACH" errors like a sore thumb.  True
the attacker has to time that connection out, assuming he's even waiting
for the return packets from the SYN's.

OTOH, if you reject a packet with ICMP UNREACH HOST_UNREACH an attacker
MIGHT play on through and ignore you because you look like the host
isn't even there.  Of course, he may not even be looking at error
returns and he may not be even waiting for returns and may be just
running flat out asynchronous, at which time, really, none of this
matters.  If you are doing this on a firewall, maybe you want to return
ICMP UNREACH NET_UNREACH for the whole network range and let your
stateful firewall open the ports for clients.

Something maybe built round this set of iptables rules:

... [static open-port rules here]
-A FORWARD -i {internal interface} -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-net-unreachable

Season with options and interfaces to taste.  Stick your static rules
and trusted (inside) interface rules above them.  Anything inside is
protected by the state table (BTW - this is all it takes to match the
silly so called "NAT" security).  This also works in IPv6 land with
ip6tables, no NAT required.

If the port is "Open" (I hate the terms "Open" and "Closed".  They're so
imprecise and misused) to some addresses and "Closed" to others
(filtered or dropped) does it really make more sense to drop a packet
than reject it with a "HOST UNREACH"?  Why?  For that matter, most
attacker tools don't care about the minor codes.  The thing was
unreachable.  Just rejecting the packet does just fine and it doesn't
make you a DDoS SYN NULL sync.

All that being said...  The difference between dropping packets and
rejecting packets is so minor as to be not worth the time to argue over.
Some people will argue that it's "common sense" but, to me, common sense
is the "future application of past experience" and my past experience
tells me otherwise.  Others are free to disagree.

I have several examples in my experience of actual malicious activity
out on the net which abused sites that dropped all packets by default.

The most amusing was a piece of malware that was driving us all nuts for
ages.  It was spoofing all communications right down the spoofing its
MAC addresses on the local wire, so you had to literally go switch to
switch and port to port to find the wire of the machine that was
infected with this bloody thing.  One site I know finally managed to
track one down and capture it.  It was infecting a Linux system.  They
seized the hard drive but, unfortunately, they were not trained in doing
a forensic analysis and failed to make a backup before spinning the
drive up in a lab.  They watched this process listen on a sniffer port
for a certain beacon packet it was expecting from the outside world,
which it didn't receive.  After a few seconds of this, it pinged an
address (which later proved to be an address which was dropping all
packets) and received an UNREACH NET_UNREACH error and then immediately
totally wiped itself off the machine, because it determined it was in a
lab.  That thing contained a "negative response dead-man's-switch" (dms)
and overwrote itself destructively, completely, and irrecoverably if it
ever got an error from the dms test.  Few months later, it disappeared
off the net and we never saw it again.  Who ever controlled it was
finished with their little experiment.

Another example was a simple case of spoofing trying to abuse and ftp
site and make it look like it came from another.  Only real live active
case of full tcp spoofing I've ever really seen where the attacker was
on the wire close to the target and could sniff the return packets.  The
spoofed site got the blame for the attack (which is where I came in).

> ...
> 
> "Closed" is the best you can hope for without a stealth firewall or NAT 
> router in place. At least the port is not "Open" for business and 
> accepting connections from the probes which are continually sweeping the 
> Internet searching for exploitable systems.

Again.  This is stupid at best.  Open ports are open.  For "closed"
ports, if you drop packets or reject them either way, it's the same
thing in the end.

> Anyone scanning past your IP address will detect your PC, but "closed" 
> ports will quickly refuse connection attempts. Since it's much faster 
> for a scanner to re-scan a machine that's known to exist, the presence 
> of your machine might be logged for further scrutiny at a later time --- 
> for example, when a new operating system vulnerability is discovered and 
> before the potential for exploitation has been repaired.

In the age of massive parallel scans, this is a load of crap.  Nobody,
and I mean nobody, sends a single connection attempt and waits.  If they
do "wide" scans (scan all ports on a single host and move on) at all any
more (very rare now days) they send thousands of SYNs asynchronously and
reap what comes back asynchronously.  No impact.  Some limited narrow
scans (scanning for a single service across multiple hosts and nets)
might be slowed but even then it's all going to be largely asynchronous.
I see far far more narrow scans than wide scans any more.

> For this reason it is important for you to stay current with updates 
> from your operating system vendor since new potential vulnerabilities 
> are discovered frequently.

Now that is good advice under any circumstance.

> <-- end quote

<-- snip -->

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/20110210/694afa8c/attachment.bin