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

[Wolf Halton]

Ron,
Michael W is a real expert on these things, isn't he.  Probably a good 
percentage of the list was saying to themselves, "Wow, that Gibson site 
is helpful. "  Michael took it in a whole new direction.  Than 
interchange is why I like the Ale list so much.  Makes me want to get a 
cisco pix and really dig into the options.  Here I am using a d-link 
wireless and it gives you very few options easily - no console port and 
no command line.  This is another case where it turns out *my* clue 
elevator wasn't arriving on all floors.

Wolf

PS Are you coming out to the ITT Linux fest on 2/19?


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
>
> 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
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20110211/e9b4694e/attachment-0001.html