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

[Michael H. Warfield]

On Fri, 2011-02-11 at 03:21 -0500, Ron Frazier wrote: 
> Hi Michael T,
> 
> See my reply to David, which covers most of this.  Other replies in 
> line.  I've snipped out the parts I want.
> 
> On 02/11/2011 02:13 AM, Michael B. Trausch wrote:
> 
> 
> >
> > The average consumer doesn't configure _anything_ manually.  At least,
> > not in my own personal experience.  Hell, they don't even set passwords,
> > or if they do, they're taped to the keyboard or the monitor.  Hardly
> > shining beacons of security, humans.
> >
> >    
> 
> You're right.  But the context of our discussion was those average or 
> above average consumers who listen to Mr. Gibson's podcast, so they're 
> already in tune to the need for security.
> 
> >
> > The default configuration of any NAT appliance is going to be absolutely
> > all that the average consumer requires.  By default, all consumer
> > devices that I am aware of do not forward incoming connections on any
> > port to any system on the LAN side of the device, thereby raising the
> > bar sufficiently high enough that your typical script kiddie isn't going
> > to bother with it.  IOW, unsolicited connections aren't allowed.
> >
> >    

> That's partly incorrect.  The default settings generally do silently 
> drop, or stealth, unsolicited packets, which is exactly what Steve is 
> recommending.  However, there are usually other defaults which must be 
> checked and sometimes changed.

Excuse me?  I have experience with a variety of wireless routers and DSL
modems and all.  Can you quote some specific models.  I've worked with
Linksys, Netgear, Motorola, D-Link, and a number of others.  Their
default is NOT to drop packets.  Their default is to return ICMP errors.
If you try to connect to a port on one of those routers, it's going to
return an ICMP UNREACH and then some subcode that tells you more.  I
haven't run into a single router that, out of the box, drops packets by
default.  There may be some.  But you will have to be specific.

Simple test.  Forget SG and his toys for the moment.  You know the
public address of your router.  From outside that router telnet to it on
some bogus port like this:

telnet {router ip} 12345

See what happens.  If it hangs for 30-60 seconds, then you are right,
the router dropped the packet.  If it immediately comes back to you and
reports "connection refused" then you are wrong.  It sent back an ICMP
error message saying nothing was there.  Try it.


> The best we can hope for from the afore mentioned consumers is to have a 
> passing knowledge of security, and they probably won't have the money to 
> pay us for it.


> Sincerely,

> Ron

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

Regards,
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/20110211/e142c8a2/attachment-0001.bin