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

David Tomaschik david at systemoverlord.com
Thu Feb 10 20:51:47 EST 2011


On 02/10/2011 01:04 PM, Ron Frazier wrote:
> 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
> 
<!-- SNIP -->

So, apparently GMail's web interface ate my earlier post.  It's a shame.

Note: This is not directed towards Ron or anyone else on the list, and I
hope it is not taken personally.  I'm also not going to call Steve
Gibson a hack, even if he might be called that by other audiences.  I'm
not interested in Steve Gibson, just the (poor) advice he gives.

Yes, we need someone who can break down security issues into terms that
are useful for the average consumer.  That being said, it should be
someone who accurately describes security issues, countermeasures, and
implications.  Steve Gibson has, in my eyes, failed that on several
occasions.

1.) The description of "stealthed" vs. "closed" ports, and the security
implications of the two.  His description of a stealthed port as a "good
thing" and a closed port as a "bad" thing is ridiculous.  If the port is
closed, the most information an attacker will glean from that is that
there is a host on that IP address.  He'll get that from the lack of a
ICMP Host Unreachable response anyway.  (See MHW's post about that.)

2.) Misleading descriptions of the implications of open ports.  If you
run GRC's "Shields Up" with 443 open, you'll receive this message: "The
presence of this secure web port in your system implies that this system
is establishing secure connections with web browsers. The number one
reason for doing this is the transmission of credit card information.
This implies that the successful intruder could access the web server's
credit card database and score bigtime. This is a VERY bad port to have
open unless you are actually conducting secure web commerce!"  There are
a number of other uses of HTTPS, and implied in this message is that
being compromised by HTTPS makes it easier for the attacker to gain
access to the database than any other compromise, leading to users
thinking that other open ports are "less important".

3.) Advocating blocking ICMP echo request (ping) packets.  Again, from
"Shields Up": "Ping Reply: RECEIVED (FAILED) — Your system REPLIED to
our Ping (ICMP Echo) requests, making it visible on the Internet. Most
personal firewalls can be configured to block, drop, and ignore such
ping requests in order to better hide systems from hackers. This is
highly recommended since "Ping" is among the oldest and most common
methods used to locate systems prior to further exploitation."  RFC 1122
[1] specifically requires that hosts on the Internet respond to ICMP
echo requests with an ICMP echo reply.  Misguided users might end up
blocking all ICMP packets (I have seen at least one consumer router with
an option to block all ICMP), resulting in the breaking of path MTU
discovery, ICMP redirection (which admittedly has its own issues), and
the loss of Host/Network unreachable messages.  (In addition to the
dozens of other messages carried by ICMP.)  This might also make the
user unable to send outbound pings, or receive their replies.  (Again,
dropping ICMP = bad.)  Even Steve himself admits[2] that this breaks the
way things are designed to work.

4.) Steve suggests connecting unprotected hosts directly to the
Internet.  On the "Shields Up" results page, he has a section labeled
"Detecting Ports Blocked by Your ISP" where he states "If your system is
operating behind a residential "NAT" router, the router will be acting
as a natural and excellent hardware firewall. But that's not what you
want for the moment. You can temporarily remove your NAT router and
connect an unprotected computer directly to your cable modem or DSL
line. Or, if you are comfortable reconfiguring your NAT router, you may
be able to point the router's "DMZ" at one of your computers which has
been instructed to "trust" our probe IP of [4.79.142.206]. If, after
doing so, most of the service ports change to either open or closed, you
have succeeded and any remaining stealth are being blocked by your ISP."
 In 2004, the Internet Storm Center estimated that an unpatched Windows
system would only last 20 minutes online before being compromised.[3]
Suggesting that ANY "unprotected" system be connected to the Internet
for any amount of time is terrible advice, especially from someone who
calls himself a security expert.

5.) Default options on "Shields Up" scan either a handful of common
service ports or the lowest 1056 TCP ports.  A successful result there
is significantly misleading to the end user by implying that their
system is secure.  There is a lot of software, particularly Peer-to-Peer
software, that uses ports over 1056.  For example, the default
"/etc/services" (listing "Well Known" ports) on Ubuntu contains 165 TCP
services with ports over 1056.  Many of these applications (P2P again)
may use UPnP to open ports on your firewall, so if you haven't done
EVERYTHING Steve Gibson advocates and have left UPnP enabled, you could
have applications exposed to the Internet and never know.

6.) His "File Sharing" test only checks port 139.  Port 445 is also used
for the SMB protocol, and has had a number of quite successful exploits.[4]

7.) Steve has advocated[5] pointing the DMZ feature on a router to an
unused IP address so that unsolicited inbound packets are dropped.
Sounds great, right?  It probably is, unless you're a user who points to
something that happens to be unused right now, but the next time you
reboot your computer, you might just get that IP address.  (Sure, if you
pay close attention, you can put it outside your router's DHCP range,
but hey, we're talking about "Average consumer", right?)

8.) Steve continues to refer to NAT as security.[5] (And numerous other
places.)

I'm not saying Steve hasn't contributed to the field of consumer
security, and I'm not saying that every bit of advice he gives is crap.
 But, really, the way security is done needs to be reformed.  It needs
to be a collaborative effort, and we need to make users understand.
Steve has said things that misleads users into believing that they are
secure when they may, in fact, still have vulnerabilities.  I don't
think he emphasizes user education enough, and I don't believe he has
paid adequate attention to drive-by downloads, bundled malware, and user
privacy issues.  Most compromises of home computers are NOT caused by
services on the host.  Most of the compromises occur because users a)
download things they shouldn't, b) don't patch, c) use peer-to-peer (see
a.), and d) don't know better.  Being stealthed doesn't fix a single one
of those.


[1] http://www.faqs.org/rfcs/rfc1122.html
[2] http://www.grc.com/sn/sn-146.txt
[3]
http://www.techrepublic.com/article/study-unpatched-pcs-compromised-in-20-minutes/5314563
[4] http://www.linklogger.com/TCP445Scan3.htm
[5] http://www.grc.com/sn/sn-064.txt

--
David Tomaschik, RHCE, LPIC-1
System Administrator/Open Source Advocate
OpenPGP: 0x5DEA789B
http://systemoverlord.com
david at systemoverlord.com


More information about the Ale mailing list