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

[Ron Frazier]

Michael W.,

I appreciate the post, but, I think you're being excessively harsh on 
Mr. Gibson.  You've got to understand that his whole focus in just about 
everything he does (that I'm aware of) in the field of security is the 
AVERAGE everyday CONSUMER, or moderately technical consumer.  His 
audience is the consumer.  He writes for the consumer.  Not for 
engineers, such as you or me, and not for networking gurus.  His sole 
focus is to help those consumers secure their computers within the 
bounds of their knowledge and their equipment.  Almost everything you 
said doesn't apply to a consumer environment, but does apply to an 
enterprise environment.  My message post was in reply to another which 
asked advice on how to buy a router, even though I changed the subject 
line.  Well, the next thing you need to do after you buy a router is 
properly configure it, which is why I made two followup posts.

The average consumer is going to go to Fry's or Best Buy or a similar 
place and buy an off the shelf router for $ 50 - $ 100.  The odds are, 
he won't be running DD-WRT on it.  He'll take it home and install it 
according to the instructions.  Then, he'll either run their setup 
wizard, which I don't recommend, or he'll manually configure it, which I 
do recommend.  The main question on his mind other than getting it 
working, will be - is the firewall in this thing going to protect me as 
much as possible from unsolicited internet attacks?  In this context, 
it's entirely appropriate to use simplified terminology to get the point 
across.

An "open" port will allow a "stranger" to access your computer in some 
way that you didn't request, possibly to attack it.  A "closed" or 
"stealthed" port will not.  The theory of stealthing a computer is the 
same as the theory of stealthing a bomber.  You don't want to reflect 
anything back.  If Joe Cracker points his bot at my ISP's network and 
randomly does a port scan of my IP address, his bot won't see me AT 
ALL.  He will get no replies, no rejects, no nothing.  There is no way 
that cannot be the safest of the open, closed, stealthed alternatives.  
What's he going to attack?  There's nothing there that's visible.  Even 
if his scan returned all closed ports, it's entirely true that he can 
log my IP address to rescan later, perhaps each time major OS patches 
come out, or major security events happen.  If all the ports were 
stealthed, and there was no reply to the probes, he has no reason to 
take note of this address at all.

In the context of the average consumer, I think the red, blue, green 
light concept is a great way to illustrate to the user exactly where any 
potential weaknesses are.

Furthermore, the average consumer has neither the knowledge, nor the 
capability, to control how packets are rejected.

The consumer can buy a router which stealths the ports (most do), or one 
which does not.  I say buy one that does.  Once purchased, the router's 
control panel will allow him to turn on and off the NAT (although this 
may affect the firewall), turn on and off the firewall, turn on and off 
the ping response, turn on and off UPNP, turn on an off remote 
administration, and turn on and off the wireless encryption.  That's 
about all.  So, even if the consumer had the knowledge to know about how 
packets might be rejected, he cannot change the function of the router.  
Most consumers, however, will be doing good just to do the manual 
configuration.

The average consumer will not be concerned over DDOS attacks.

The prior 2 posts I made on this topic, and Steve's website, are 
designed to help an average consumer or moderately technical consumer 
configure an average router for maximum safety from unsolicited attacks 
in the quickest amount of time with the least possible technical 
knowledge.  I think they accomplish that.  While there are many 
extremely technical Linux users here, not everyone on the list is a 
Linux or iptables expert.  Those less technical people will benefit from 
the information.

If I can figure out how to make Ubuntu totally stealth this PC, I'm  
going to do that.  I don't want the ports closed, no matter what form 
that takes.  I want them silent.  In the mean time, I'll be sitting 
behind my stealth firewall.  I'll try to address some of your more 
technical points later, if I think I have anything intelligent to say.  
However, much of it is above my level of expertise.

I totally understand that the rules and requirements and best practices 
are different in the enterprise.

PS - I cannot comment on an event on another list at another time that I 
didn't witness.

Sincerely,

Ron

On 02/10/2011 10:47 AM, Michael H. Warfield wrote:
> 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
>    
>    

-- 

(PS - If you email me and don't get a quick response, you might want to
call on the phone.  I get about 300 emails per day from alternate energy
mailing lists and such.  I don't always see new messages very quickly.)

Ron Frazier

770-205-9422 (O)   Leave a message.
linuxdude AT c3energy.com