<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Ron,<br>
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 <b>my</b> clue elevator wasn't arriving on all
floors. <br>
<br>
Wolf<br>
<br>
PS Are you coming out to the ITT Linux fest on 2/19?<br>
<br>
<br>
On 02/10/2011 01:04 PM, Ron Frazier wrote:
<blockquote cite="mid:4D5428A3.4010803@c3energy.com" type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, 2011-02-10 at 08:47 -0500, Ron Frazier wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Before getting into usage, here is some data on CLOSED vs STEALTH ports
from Steve's website at <a class="moz-txt-link-freetext" href="https://www.grc.com/su/portstatusinfo.htm">https://www.grc.com/su/portstatusinfo.htm</a> .
</pre>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">quote on -->
</pre>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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).
</pre>
<blockquote type="cite">
<pre wrap="">...
"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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Now that is good advice under any circumstance.
</pre>
<blockquote type="cite">
<pre wrap=""><-- end quote
</pre>
</blockquote>
<pre wrap=""><-- snip -->
Mike
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>