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

[Michael B. Trausch]

On Fri, 2011-02-11 at 18:54 -0500, Ron Frazier wrote:
> I don't think we need to continue to escalate an argument in public.  
> You're reading a lot into my messages that doesn't exist.  I have
> never intentionally insulted anyone in this group, and if I
> unintentionally insulted someone, I'm sorry.  I do not have a holier
> than thou attitude, and don't feel that way at all.  The compliment I
> paid you was legitimate and sincere, even though we disagree on some
> things.  Now, you're using the F word.  I really don't know why.
> Whatever I did to make you so mad, I'm sorry.

I'll apologize for my word choice.  I could have omitted the word.

I will, however, cite examples where I have perceived (admittedly,
possibly where none exists, but tone, context and word choice certainly
impact my own impression) attitude.

From message <4D5428A3.4010803 at c3energy.com>:
> 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.

In reply to <1297352879.6390.161.camel at canyon.wittsend.com>:
> > 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.

Mike W. pointed out both how and why the information that Gibson
distributes is (not always, but many times) plain wrong.  Your reply
states that security is somehow achieved differently in the consumer
situation vs. the business situation.  I submit that it is not: networks
do not operate differently based on the context of their surroundings.
They have no way to tell that they're a home network vs. a small
business network vs. a large or huge business network.

It's been pointed out multiple times that Gibson often does not speak
within the framework of existing standards.  Now, if Gibson made every
reasonably human effort to be accurate *and* get the "average user" to
understand him, and did not perpetuate inaccurate information, I would
have no problem whatsoever with him---and I would have no problem
whatsoever with citing him.  I absolutely loathe (s)he who makes my jobs
more difficult---and one of the jobs of having to manage networks for
others is to combat the misconceptions that people gain when they listen
to people who give bad advice.

Honestly, I don't think Mike W. was being harsh at all.  I think he was
being polite.  Very polite.

As David T. observed (also, IMHO, very politely):
> 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.

And he went on to post a list of examples substantiating his
observation.  One of the examples was this:
> 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.)

You replied with this:
> Now, you guys are telling me, that if the bot randomly scans my public
> IP address, 76.97.???.???, and if my ports are stealthed and I don't 
> send ANY response, and if I don't respond to ICMP pings and such, that
> the bot is still going to know I'm there?  Come on!  I'm not buying
> that for 5 seconds unless someone explains exactly how that will
> occur.

Quote: "[you are] not buying that for 5 seconds unless someone explains
how that will occur".  By that point in the thread, it had _already_
been explained, and in the very message that you replied to with that
nugget, a reference was given to RFC 1122, which explains the "why" to
that in sufficient detail (and it only expects that you refer to the
RFCs that define the protocols that RFC 1122 discusses in order to
understand it).  Yes, a bit of reading and research would be required to
process all of that.  And I mentioned somewhere in this thread that I'd
expect that to take anywhere from one to a several days, depending on
how much and how quickly you're able to digest it.

Given that David T. was kind enough to not only point out the example
and provide a reference to the RFC that defines this standards-compliant
behavior, this seemingly incredulous reply was uncalled for.  Your word
choice clearly denotes exclamation and disbelief.

All of the information was handed to you on a platter---and I'm not
saying that's a bad thing.  That's what we do here.  We help each other
by providing information and discourse on it, on a wide range of topics
that is loosely centered around Linux stuff (and "on-topic" is
thankfully not painfully restricted to Linux-only; obviously this thread
is on networking and in a more-or-less operating system independent
context).

Now, to be fair, my frustration doesn't exist solely because of this
thread.  For example, in the thread "HELP, need to setup wireless …",
which is more-or-less where this whole thing started, I stated this:

> You'll need to use your wireless router as just a switch in order to
> avoid double-NAT.  If you disable its DHCP, and ensure that it's got
> an IP address on the right subnet, all you have to do is plug the
> Atnex equipment into one of the normal ports on your wireless router.

You replied to _that_ with:
> I don't see what the problem is.  I go though two routers all the
> time, both doing NAT, to get to my internet connection.  The following
> should work fine with LAN cables between the parts.  Paul is welcome
> to call me personally if he needs help.

Which, in its context, reads as if I was somehow unwilling or unable to
provide Paul with help, based on my statement that double (or more)
NAT'ing is not a good thing.  It also includes the somewhat petty "well
it works for me so it should work here and there too" type of attitude.
One that I'm sure that we're all too familiar with; very popular in bug
and issue tracking systems.  From there, we have (me again):

> Double-NAT (a NAT within a NAT) unduly reduces performance and creates
> an artificial barrier that need not exist.  It can also unnecessarily
> complicates the network and brings about more points of failure.

And then (you again):
> I didn't intend any offense, so I hope none was taken.  The method I
> proposed seemed like the quickest way to get Paul up and running in
> what appeared to be a home office situation.

Here, the implication that somehow "home office situation" is relevant.
To be fair, we hadn't reached the discussion on how that is irrelevant,
but anyway, that post came after Mike W. took the time to kindly explain
various situations where this can be a problem.  Elsewhere in the thread
I, too, highlighted points where it's a problem.  Now, I realize that
what is perfectly clear to me (that a switch is better than a NAT when
given the choice) maybe perhaps seemed (or still seems?) trivial or
unimportant to you.  I must state that I vehemently disagree --- the
need for simple, robust, correct setups trumps everything else (in my
opinion).  Call me a perfectionist, or perhaps even an obsessive
perfectionist.  But shrugging off such an important point to me seems
like simple dismissal.  I find that to be not necessarily insulting, but
certainly displeasing---particularly when I've taken the time to explain
something.

Later in the thread you say (this time to Mike W.):
> Both you and Michael T. make some good points about potential
> problems, and this strategy might not apply to more complex commercial
> networks.  I'm in a home office situation.

Again, as if this is somehow relevant.

I later said:
> There is no situation that I can think of where a double NAT is
> appropriate.  It breaks many expectations in the design of a single
> network, both at the human and at the application layers.  (Let's say
> that the "human layer" is the missing 8th layer of the OSI model.)  Or
> perhaps to state it better: I would consider it a design of last
> resort, except for the fact that I cannot fathom a situation so awful
> as to require one.
[snip]
> The first time I actually saw a double-NAT setup was probably my most
> confusing.  And I came off looking like an idiot the first time I saw
> it.  At first, I could not explain the problems on the network that I
> was in charge of fixing.  They didn't make any sense.  It had never
> occurred to me to actually check into whether or not there was a NAT
> running on this network; it was a single physical network, in one
> building, in a single administrative domain.  It took me hours to
> figure out that the behavior was likely because of a NAT, and it only
> took me hours to figure out because the thought never even entered my
> mind in the first place.  I mean, who would put a NAT on the inside of
> a network that is fully controlled by a single entity?

To which you replied thus:
> I am not a networking guru, but here are some thoughts.  See comments
> in line.
[snip]
> The program [Crossloop] has to negotiate a connection with a central
> outside server first.  Then the two PC's are bound together to talk
> directly to each other, as I understand it.  Also, you should be able
> to access a centralized backup just like I do with my printer, by the
> IP address.  The NAT routers don't care.  However, broadcast and ICMP
> packets may not make it across the NAT boundry.
[snip]
> Ahh ... now we know why you have a personal bias and grudge against
> NAT routers!  8-)

Maybe I let my button be pressed, but my discussion of NAT is built
around neither personal bias nor a grudge.  I have disliked NAT since
long before then.  I've disliked nearly every thing that has been put in
place to try to draw out IPv4's existence and delay the IPv6 transition.
Many years ago when I setup my very first network that required NAT, I
learned about the multitude of problems that there were with it.  I
learned how to work around (most of) them, and at the time, there were
not ALGs for everything, so you had to do things like use passive FTP
(or otherwise you'd have FTP sessions hang forever) and so forth.
Nowadays, the transparent ALGs that are supported by the Linux kernel
make things more bearable, but you still lack true end-to-end
communication.  True end-to-end communication is very important,
ironically, in order to be able to maintain security in certain
situations.

I did not take me long to see that NAT was a bad thing from the
perspective of IT professionals for another important reason:  Many
people at that time were talking about NAT appliances like they were the
second coming of Christ, that they would save everything and everyone
from doom and gloom if only you accepted them into your networks.  The
misconceptions perpetuated over the following approx. 14 years have
changed little, though now with the high-profile problems that Microsoft
has had with systems even behind stateful firewalls and NAT applicances,
_some_ of those people who vehemently campaigned for NAT everywhere due
to security reasons have seen just how incorrect they were.  Such people
often never bother to seek out the standards and read them.  Most of
them are talking out of their bums because they heard some trusted
person tell them that "NAT is good and here's why" and trumped it up to
"it slices, it dices, it purées, and it cleans the kitchen, too!".

The very same types of people who spent years and years sounding loud
trumpets for NATs have, however, mostly stuck to their guns.  A number
of those people (and new people) have moved into the free software world
for one of an unknown number of reasons.  And now, some of them have
moved on to other things.  For example, Mono.  We now have a group of
people who do the same thing with it---a large group of people---who
take what someone says and treat it as gospel truth, all without so much
as taking a few minutes to hunt to see if the assertions that they've
been given are even valid.  If someone said it on a stream, or a blog,
or anything that has appeared on slashdot or similar, it must be right,
right?

These are the type of people that Eric Hoffer wrote about in his book
"The True Believer".  His book was more on the concepts of things that
people see as fundamental; freedom, religion, political views,
philosophy.  But people apply it to everything.  And "true believers"
really irk the snot out of me.  People who will accept information
handed to them without looking to sources often never seek out the full
picture and, if given the chance, will disseminate what they have
"learned".  This does not come without negative consequence.  And yes,
it makes me hot when this happens.  It's something that I have to
contend with on an everyday basis in my work.

I've drawn analogies at points in these threads to cars.  Computers,
like cars, are machines that serve a purpose.  And, like cars, they have
to be fed and cared for.  And also like cars, if they are improperly
managed, they can cease performing well.  Unlike cars, computers can
talk to each other and relay data and useful information and also
complete crap to each other.  Unlike cars, where most of the behavior of
the car is pretty much designed and implemented at the factory, with
modification of such behavior requiring a great deal of knowledge, care,
time, and patience, computers are much more flexible.  Install software,
and you've modified what your computer's capabilities are.

Years ago, when the Web was just starting to become popular, it was
clear that people were not going to learn how to secure their systems
without education.  Unfortunately, no massive effort to provide adequate
and accurate education ever really caught on.  Double unfortunately,
people don't often seek out information with which to educate
themselves.  One example of the result of this is that the average user
does not truly know how to prevent getting icky stuff in their computer.
It used to be pretty simple to tell people how to stay safe: just don't
take floppy disks from other people.

But now we have CDs, flash drives, almost universally we have network
connections, hypermedia, network streams, ever-increasingly programmable
file formats (case in point: PDF --- an online PAPER FORMAT ---
supporting JavaScript, for crying out loud), users who think they know
what they want and dictate requirements to programmers who tell them
"that's really not a good idea," but they insist and havoc is wrought,
programmers who aren't always careful in the code that they write (desk
checking? who does that anymore), and the list goes on and on and on.
It's almost impossible to tell people how to use their computers and
networks securely without teaching them _something_ about how all of it
works, just like it's not possible to tell someone how to repair many
problems on a car without first explaining the hows and the whys behind
the procedure.

That is to say that "knowing the procedure" for doing something is to
know nearly nothing at all.  Procedures, established best practices, and
all that stuff---they're all dynamic.  The things that we should be
doing today may not be the things that we should be doing tomorrow.
Another wonderful case in point is the whole thing with IPv4 and IPv6.
Best practices in IPv4 are in many cases not best practices in IPv6.
New best practices become possible because the drastic differences
between the two, and there are many things which are required of IPv6
that were only ever optional in IPv4.  More choice, more security
mechanisms, more space, and the fact that scanning a whole network can
(depending on a number of factors) take almost as long as attempting to
brute force a moderate to long encryption key, make it worlds better.

> I intend to continue the thread long enough to complete some
> discussions I'm in with other people and answer questions they've
> asked me and discuss some test results from my router.  Other than
> that, I'm going to let it drop.

To be completely honest, it need not even be dropped completely.  But a
word of advice: I'd drop it long enough to gain a better understanding.
I'd say read Wikipedia, but it's even possible to come across incorrect
information there.  Sometimes it's intentional vandalism, sometimes it's
an innocuous edit that someone made that they thought would clarify
something but instead it makes it worse.  That is one downside of having
a fully-publicly editable wiki.  It often gets corrected very quickly,
though I have found on more than a few occasions that I'd be reading an
article and come across something that I had to do a bit of extra
digging and research to fix because the article was wrong for whatever
reason.

Hell, even that doesn't bother me, unless the person comes back and
reverts my edit to their previous state without citing any reason why,
and then it often gets real ugly.  I will not drop the issue for any
reason on WP; it means too much to me to let it be polluted with
inaccurate or misleading information.

> I have one more question for you.  You may choose to answer it, or
> not.  It's up to you.

I have no problem answering questions.  None at all.

> Do you, or don't you, agree with the first 8 pieces of advice I said
> I'd give to friends and family in the prior post from 4:51 PM
> regarding the use of consumer routers, with the EXCEPTION of number 7,
> which was about UPNP, which is situation dependent?

Both yes and no.  And I'll attempt to explain why.

> 1) Get a router and put it between your PC and the cable modem.

If there is only a single PC that will ever use the Internet connection,
I don't see a problem with a direct connection between the computer and
the Internet access medium.  If the PC will not be on a network (other
than the Internet), then the PC won't be running services for a Windows
network (since most ISPs filter out Windows networking ports, that is
effectively what happens), and if the PC is not going to have any other
services enabled which are exposed to IP, then there isn't a problem at
all.  No ports listening means no ports of entry to the system.  Since
it's only one computer, NAT is not needed.  Since it's only one
computer, a firewall isn't needed since services won't be running.  No
matter whether we're talking about a residential "average Joe" or a
single computer in an Internet-connected business, the assumption here
is that it's going to be a workstation of some sort, and thus it is not
going to be running any sort of extra network services.

The only reason to have a NAT appliance, a switch, a router, or any
other sort of device between the computer and the Internet access medium
is to facilitate network functionality.

Now, if you're going to be running network services, but not using the
system as a workstation, then again, you need not have a NAT appliance.
Just install, configure, and start the services that you need.
Configure them securely at the operating system and application levels,
and all is good.  Since the only ports of entry are those that you just
configured, you again have nothing to worry about---and provably so.

The _moment_ that you start talking about more than one computer,
though, a number of assumptions change:

 * A multi-node network that someone runs is typically going to
   grow "organically"; e.g., when people decide that something else
   needs to be there, it comes into the picture somehow.  Rarely
   do home networks ever get rearchitected by their owners.  This
   has the tendency to reduce the potential for security on the
   network because of a variety of factors, and a stateful firewall
   should be put in place to protect systems on the network from
   unintended access.

   Note that I am *absolutely* not saying that a stateful firewall
   is appropriate for any and every network.  As with _any_ tool, it
   has a very specific purpose.  I don't use stateful firewalling on
   all networks.  I don't advocate that it be applied universally nor
   blindly.  On many networks that I see with stateful firewalling,
   there are no network services exposed and thus the stateful
   firewall is doing nothing but increasing latency---sometimes
   significantly, depending on the class and vintage of the stateful
   firewall itself.

   On the majority of networks where a stateful firewall is present
   _and_ where it is necessary, it's overapplied.  This doesn't do
   any significant harm, it's just annoying.  These are the types
   of networks where someone is officially in charge of it that
   (we hope) knows what they're doing.  What it says to me is that
   whoever implemented the network really just does what they're
   told to do and doesn't really think about it.  Really and truly,
   only the lower half (and even more correctly, really only the
   well-known ports) need to be covered by a stateful firewall.

   A firewall is primarily good at keeping things contained within
   a network, not blocking things from entering the network.  There
   are exceptions, but for the most part, they all have trivially
   easy workarounds, and the proper place to employ security is on
   the client and server systems present on the network.

   A sane default configuration for a stateful firewall will protect
   services on the inside of the network that have a relatively
   decent chance of accidentally being enabled with an improper
   configuration.  On a simple home network, a stateful firewall
   should be used on all the well known ports (with some exceptions
   for services that enhance security, such as the ports that are
   used for IPsec negotiation, or the SSH port).  Of course, having
   the SSH port open means that people should be using strong
   passphrases or (ideally) keys.  I prefer teaching people how to
   use keys when they need to use SSH, because that is simpler
   for them to understand.  Most people understand the idea of
   keeping a physical token safe.  And then the password requirement
   isn't so strong, either; the user can use a single really long
   passphrase (say, a full sentence) as opposed to multiple moderate
   length passwords or phrases on multiple systems.

 * Networks with multiple nodes are more likely to have things like
   networked printers, which by default will accept connections from
   anywhere under the sun.  So, add to the list of well-known ports
   (technically defined as ports zero through 1023) the list of
   commonly known print server ports.  The most commonly used one
   of those is port 9100, and the others fall in the well-known port
   range as far as I can recall at the moment (and without looking
   it up).

 * Networks with multiple nodes are also more likely to have multiple
   users, and with multiple users there is the notion that not every
   user is fully aware of every other user's actions.  This of course
   means that it is much more important to properly secure all of the
   computer systems that are on the network.  But nobody ever does.
   Even with massively large corporations, the number of computers
   which can be logged into with some sort of default password, or
   that have passwordless access to the BIOS, is staggering.  It is
   my impression (gained through experience) that most networks are
   poorly managed, not just home networks.  Another point for
   network security being distributed throughout the entire network.

 * Most importantly, networks with multiple nodes *must* have some
   sort of device between the network and the Internet access medium,
   whether that be a NAT (due to lack of address space), a real IP
   router, or a combination of IP router and firewall.

> Either by wizard or by manually checking, check and / or change:

Again, I disagree.

If you are the average consumer and you do not know what you are doing,
use the setup wizard.  Do not modify any other settings that are you are
not familiar with.  If you have concerns about the security of your
network, call someone who knows the whole, big picture, and tell them
what it is you are hoping to achieve.

Then again, you could _not_ call someone else.  You could stop and read
the standards for the various layers of networking that you intend to
use.  You could do relatively little research, for that matter.  Most of
it is reading and rereading; study.  The way networks work academically
speaking is really and truly how they work in practice.  If you turn up
few results on Google and aren't finding any useful authoritative
references from something like Wikipedia and you do not find anything
relevant at the IETF, then ask someone (or a group of someone's, like
this group) to help get you pointed in the right direction in terms of
study material.

Following checklists and procedures is fine and dandy, as long as you
understand them.  I believe this statement to be universal: it does not
matter what field you are in, or what field you are from and only
visiting.  An understanding of the what and the how is all you need for
following directions from a checklist.  An understanding of the _why_ is
what brings you to a point where you are "proficient" in what you are
doing, and able to understand e.g., why the items on the checklist are
ordered the way they are and how each instruction or item on the
checklist has an impact.  It also helps you to internalize the
checklist, of course, so that you gain the whole big picture in that
insanely /giant/ storage medium---not in terms of physical size, but
data storage---inside your head.

Once you understand and can describe precisely how and why a change is
applicable to a network, _then_ start playing with the other options.
By default, commodity NAT appliances have a default configuration that
is balanced between permissive and restrictive.  That balance is what
you want, 99% of the time, on a home network.

Here is an only tangentially related anecdote.

Shortly before we left for Ohio over Christmas, we had a series of
problems with power and network outages in the area we live in.  Both
events were significant enough that repair crews from the respective
companies had to come out.  I like talking to repair crews, because I
like to chat with them and get a feel for what they're doing and why I'm
impacted.  I _love_ learning.  Anyway, the electric crews had one guy
doing the work, with the rest of the work crew standing far, far away;
contrasted with the cable company, where all of the members of the team
were working.

There was a major difference, aside from the amount of voltage running
through the electric company's "hubs" (for lack of a better term) vs the
cable company's.  The guys on the cable repair crew knew the ins and
outs of everything that was in their boxes.  The people on the electric
repair team, however, did not.  They were afraid of the box, and
apparently unfamiliar with their own procedures; the guy doing the work
had to constantly ask for what he was supposed to do next, asking if it
was safe to touch thing /x/, and so on.

Needless to say, the cable crews were much more confident and efficient.

So, all that said: users not aware of what they're doing should leave
all of the configurations outside of the setup wizard alone.

> 2) WPA/WPA2 wireless encryption on with long random password - 20+ digits. 
> (WEP will not do.  It is badly broken and can be cracked in a 
> matter of minutes.  There have been examples of WPA with shorter 
> passwords being cracked as well.)

WPA-2 with TKIP is known insecure.  Any WEP variant, as you mention, is
also known to be insecure.  WPA-2 with CCMP, OTOH, is known to be secure
(as far as I can tell, still).

Every device I've purchased in the last year has, as part of its
configuration wizard, offered the option to turn off wireless or set it
to WPA2 security.  WEP has also been available on them all, but all the
ones I can recall at the moment discouraged it with red letters and a
bold font---you know, the type of thing that scares end-users.  I would
call that quite satisfactory.

The only advice that I give is that it be a passphrase, not a password.
I tell people to think of an English sentence that they could remember
as a password, and that they can remember without it being easy to guess
by someone else.  It doesn't have to be syntactically or semantically
valid, either; it just has to be something that you can remember and
ideally have caps, lowercase, punctuation, and maybe even numbers.  For
example:

  Jewel Wars eat all 2 of Python's eggs!

Such a phrase can be made to be easy to remember and is secure (enough)
against brute-force attack.  Remember that another crucial thing to keep
in mind is that you only need enough security to merit what you're
trying to protect.  And remember also that the length of a password
isn't the only thing that dictates how strong it is.  The passphrase
above is reasonably strong, but the amount of entropy that it contains
is very low.  IOW, if the attacker knows that you're totally contained
within the visible ASCII spectrum, that is 94 possibilities per
character.  It's still a lot of combinations, and that is really strong
comparatively speaking; assuming a KDF (key derivation function) that
doesn't somehow make the password incredibly weak (e.g., by doing
something like pass.upper()[:8] assuming the passphrase is stored in a
variable named "pass" as a string in Python), it should be plenty strong
enough.

It is possible to calculate exactly how strong it is in terms of
entropy, but this is long enough and I don't recall at the moment what
the calculations are, anyway.  Someone who is exceptionally adept at
compression would likely be able to provide an answer nearly off the top
of their head.

> 3) Default password change
> (Yes, it's only available from the LAN.  If a virus gets loose in 
> the network, it may try to access the router's configuration and change 
> it through the setup screen, using the default password.  Not to mention 
> children and other people that might be accessing the LAN.)

Retention of a default password is almost universally always a bad
thing.  Either the default password is well-known, easily derived using
a simple formula, or, provided a vendor that actually provides
apparently random passwords, stored in the vendor's database somewhere.

Of course, it is important to remember that changing a device's default
password is only going to protect the device from the point of view of
the LAN, and only if there isn't another "master" password, a well-known
key or certificate, or some way to remotely trigger an NVRAM/flash reset
over the network.

> 4) NAT on
> (Not security specific but needed for IPv4 setups with multiple 
> computers.  Probably already on.  Check anyway.)

No need to check.  I haven't seen a device in several years that comes
without that enabled out of the box.  The use of NAT is so universal
that it's assumed that every home and small business network contains a
NAT between the network and the upstream network (Internet connection).
Of course, as has been mentioned in many other threads, this will
change.

> 5) Firewall on
>       (Yes, it's probably on already.  Check anyway.)

No need to check; default settings in all routers I've used in the last
several years assume a 1:m NAT configuration and have the barebones
stateful firewall to go with it.  Also recall that the stateful firewall
in a configured-by-default network provides next to no benefit, since no
services are started that are exposed.

To make a distinction from something I said earlier: networks run a lot
of services, to be sure.  There has been a lot of work in the past
several years in the realm of "zero configuration networking", the
notion that you can plug devices such as printers into the network and
they will automatically be accessible.  They'll try DHCP to get an
address, and then they'll use APIPA if that fails.  They will advertise
their name on the local network using a multicast protocol, as well.

Such services are not exposed to the Internet, because they are limited
in scope.  No COTS NAT appliance that I am aware of (that is, of entry
level devices) are capable of multicast routing, so all such traffic
will stop at the edge of the network.  No firewalling is therefore
necessary to contain it.

> 6) Remote WAN side admin off
>       (Yes, it's probably already off. Check anyway.)

Again, default sane settings turn that off.  Users have no need to
check.  It is something *I* would check when I look into a network, but
only because I go in assuming absolutely nothing.

> 7) UPNP off
>       (Yes, that breaks some automated setups of games and things.  But 
> in terms of security, it's a risk.  If a virus gets loos in the network, 
> many of them will specifically try to exploit UPNP to open holes in the 
> firewall.  Not only that, sometimes, you never know it's been done.  A 
> security conscious user would be better off to manually open the ports 
> he needs for his game.  The friends and family members I advise are not 
> gamers.)

uPnP can only be security risk if the devices that use it are also
considered to be security risks.  uPnP is not strictly speaking
necessary.  Almost all things that are possible with uPnP can be worked
around.  In fact, everything I can think of that uPnP is used for is
able to be worked around by using proxies, application layer gateways,
or some form of tunneling (probably over UDP).  There is therefore
little to no benefit to turning off uPnP.

And if you get one of the little bugs that uses uPnP on a workstation
computer, you can bet your hide that it has a fallback that easily
sidesteps it.  If it cannot configure uPnP, it'll probably just attempt
to make outbound TCP connections.

> 8) SSID change to something besides Linksys, etc.
>       (Not security specific.  Helps you connect to your router rather 
> than your neighbor's when picking from a list.  Helps your neighbor 
> connect to his.  I've seen more of this in the past, less now.)

This is usually prompted for in the configuration wizard, as well.
Therefore, no need to go out of the way to change it.  The only wireless
networks that I have seen that are using "default" names are the systems
that AT&T is installing these days, which are named after some scheme
that they use (presumably to keep track of equipment).  Users are
allowed and able to change the names of the wifi networks of these
devices, but the initial name is derived from information associated
with the device, the account, a random number, or some combination of
the three (depending on vintage and technician).  Such device do not
have a configuration wizard at all, and are relatively hard to use.  I
don't recommend any end user poke around in them.

> That's all I need to know.  And, regardless of your reply, I won't
> reply again, if that's what you want. 

All I ask is that you spend some time learning about the things that are
being secured.  Definitely read about IPv4, TCP, UDP, and if desired
IPv6.  Spend some time (not a whole hell of a lot) on studying the OSI
model, enough that you think in terms of the layers.  It will make it so
much easier to come to an understanding about the often seemingly
counterintuitive aspects of implementing security, because you won't
just have half the story: you'll be able to construct a model in your
head that represents the impact that the security has on the mechanisms
it protects, and then it all makes sense so much more quickly.

I'd rather answer more questions that build from what you read in
standards documents than try to explain the standards themselves without
you having read them.  I do hope that makes sense.

	--- Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110211/54d70cd2/attachment-0001.bin