Just a few questions:
If You connect to the internet with a public IP address and then ping
another public IP adress containg a stealthed machine. What response
should You get?
If You connect to the internet with a public IP adress and then ping
another public IP adress containing no machine at all (plug pulled, so
to speak). What response should You get?
/B. Nice
In article <7bgu82lm79qg58lp1f6294vg67fh612oqg@4ax.com>,
B. Nice
>Just a few questions:
>If You connect to the internet with a public IP address and then ping
>another public IP adress containg a stealthed machine. What response
>should You get?
If you could provide a technical definition of 'stealthed' then
we might be able to answer the question. Different people mean different
things by it, and the answer will be different depending on the
definition.
>If You connect to the internet with a public IP adress and then ping
>another public IP adress containing no machine at all (plug pulled, so
>to speak). What response should You get?
- no response if something along the way is filtering the icmp
or icmp responses
- no response if you are using a PAT (Port Address Translation)
device to provide your "public IP address" and your PAT device cannot
figure out how to get the icmp response back to the original host
(icmp does not have "ports", so getting the response back is
problematic)
- no response if the last router (or firewall) in the chain has been set
to not return icmp responses for unavailable devices [this is
fairly common]
- If nothing filters, all addresses get mapped well enough, and
the terminal device is configured to return status, then you
would get an ICMP UNREACHABLE (ICMP type 3). The ICMP subtype
would be 0 (Network Unreachable), or 1 (Host Unreachable), or
possibly even 2 (Protocol Unreachable). But you could even get
other subtypes, such as Destination Network Unknown,
or Destination Network Administratively Prohibitted.
The response ICMP subtype would, however, *NOT* be 3 (Port Unreachable) for
an ICMP ECHO packet, even though that's one of the very common
subtypes when TCP or UDP are the protocol.
On Tue, 13 Jun 2006 23:28:54 GMT, roberson@hushmail.com (Walter
Roberson) wrote:
>In article <7bgu82lm79qg58lp1f6294vg67fh612oqg@4ax.com>,
>B. Nice
>
>>Just a few questions:
>
>>If You connect to the internet with a public IP address and then ping
>>another public IP adress containg a stealthed machine. What response
>>should You get?
>
>If you could provide a technical definition of 'stealthed' then
>we might be able to answer the question. Different people mean different
>things by it, and the answer will be different depending on the
>definition.
I was referring to "stealthed" in the meaning: not responding to ICMP
requests.
In that case the answer to my question must obviously be: no response.
>>If You connect to the internet with a public IP adress and then ping
>>another public IP adress containing no machine at all (plug pulled, so
>>to speak). What response should You get?
>
>- no response if something along the way is filtering the icmp
>or icmp responses
>
>- no response if you are using a PAT (Port Address Translation)
>device to provide your "public IP address" and your PAT device cannot
>figure out how to get the icmp response back to the original host
>(icmp does not have "ports", so getting the response back is
>problematic)
>
>- no response if the last router (or firewall) in the chain has been set
>to not return icmp responses for unavailable devices [this is
>fairly common]
>
>- If nothing filters, all addresses get mapped well enough, and
>the terminal device is configured to return status, then you
>would get an ICMP UNREACHABLE (ICMP type 3). The ICMP subtype
>would be 0 (Network Unreachable), or 1 (Host Unreachable), or
>possibly even 2 (Protocol Unreachable). But you could even get
>other subtypes, such as Destination Network Unknown,
>or Destination Network Administratively Prohibitted.
>The response ICMP subtype would, however, *NOT* be 3 (Port Unreachable) for
>an ICMP ECHO packet, even though that's one of the very common
>subtypes when TCP or UDP are the protocol.
Thank You for a good explanation.
Know I understand why I get different results.
Walter Roberson wrote:
> - no response if the last router (or firewall) in the chain has been set
> to not return icmp responses for unavailable devices [this is
> fairly common]
Better said: This is fairly uncommon except at some very lousy big ISPs
(like AOL) and creates various types of problems.
B. Nice
> If You connect to the internet with a public IP address and then ping
> another public IP adress containg a stealthed machine. What response
> should You get?
No response.
> If You connect to the internet with a public IP adress and then ping
> another public IP adress containing no machine at all (plug pulled, so
> to speak). What response should You get?
ICMP host unreachable.
Yours,
VB.
--
"If you want to play with a piece of windows software that makes you
click all over the place, there's always minesweeper."
Kyle Stedman about "Personal Firewalls" in c.s.f
In article <4f9m48F1i2v68U2@news.dfncis.de>,
Sebastian Gottschalk
>Walter Roberson wrote:
>> - no response if the last router (or firewall) in the chain has been set
>> to not return icmp responses for unavailable devices [this is
>> fairly common]
>Better said: This is fairly uncommon except at some very lousy big ISPs
>(like AOL) and creates various types of problems.
No, it is quite common. For example, the Cisco PIX acts this way
by default, and it is quite uncommon for people to specifically
configure otherwise. In four years of helping people with their
PIX configurations, I don't think I've seen more than one person
with the appropriate command in their configuration.
In article
B. Nice
>On Tue, 13 Jun 2006 23:28:54 GMT, roberson@hushmail.com (Walter
>Roberson) wrote:
>>If you could provide a technical definition of 'stealthed' then
>>we might be able to answer the question. Different people mean different
>>things by it, and the answer will be different depending on the
>>definition.
>I was referring to "stealthed" in the meaning: not responding to ICMP
>requests.
>In that case the answer to my question must obviously be: no response.
Note, though, that some common ping programs use TCP or UDP instead
of ICMP. My answer is nearly the same for those, except I would remove
the note about ICMP Unreachable (3) Subtype 3 (Port Unreachable)
not being possible, and would add it into the list of possibles.
But if you define "stealthed" in terms of ICMP, and your ping works
in terms of TCP or UDP, then you might get a response of some sort...
On 14 Jun 2006 12:42:32 +0200, Volker Birk
>B. Nice
>> If You connect to the internet with a public IP address and then ping
>> another public IP adress containg a stealthed machine. What response
>> should You get?
>
>No response.
>
>> If You connect to the internet with a public IP adress and then ping
>> another public IP adress containing no machine at all (plug pulled, so
>> to speak). What response should You get?
>
>ICMP host unreachable.
>
>Yours,
>VB.
That was also what I expected, but when I tested it between two
machines connected to two different ISP's I got two different
responses to the unplugged scenario. And the only reason I can think
of is that ICMP packets are filtered somewhere in between.
/B. Nice
In article <4f9m48F1i2v68U2@news.dfncis.de>,
Sebastian Gottschalk
>Walter Roberson wrote:
>> - no response if the last router (or firewall) in the chain has been set
>> to not return icmp responses for unavailable devices [this is
>> fairly common]
>Better said: This is fairly uncommon except at some very lousy big ISPs
>(like AOL) and creates various types of problems.
It's opposite creates "various types of problems" as well.
There are no security features in icmp, and in particular there
is no authentication that an ICMP ECHO packet comes from the IP
that it claims to come from. If a terminal firewall or router
responds to ICMP ECHO requests directed to non-existant systems with
ICMP UNREACHABLE packets (of whatever subtype), then that firewall
or router makes a nifty contribution to DDoS (Distributed Denial
of Service) attacks.
Furthermore, it takes resources on the security gateway to
ARP for the destination, hold that status until a timeout, and then
create an ICMP UNREACHABLE packet. If the security gateway has a
heavy load -- normal traffic or just a lot of random probes or a DoS
or DDoS attack -- then responding can be an unaffordable drain on
resources.
For these reasons, -many- security gateways are set to NOT respond
to ICMP ECHO, and NOT respond to TCP or UDP packets that do not
match the local security policy. It is most definitely not
just "some very lousy big ISPs" that do this.
Walter Roberson wrote:
> There are no security features in icmp, and in particular there
> is no authentication that an ICMP ECHO packet comes from the IP
> that it claims to come from. If a terminal firewall or router
> responds to ICMP ECHO requests directed to non-existant systems with
> ICMP UNREACHABLE packets (of whatever subtype), then that firewall
> or router makes a nifty contribution to DDoS (Distributed Denial
> of Service) attacks.
Why? How?
> Furthermore, it takes resources on the security gateway to
> ARP for the destination, hold that status until a timeout, and then
> create an ICMP UNREACHABLE packet. If the security gateway has a
> heavy load -- normal traffic or just a lot of random probes or a DoS
> or DDoS attack -- then responding can be an unaffordable drain on
> resources.
That's why rate limits are good for!
> For these reasons, -many- security gateways are set to NOT respond
> to ICMP ECHO, and NOT respond to TCP or UDP packets that do not
> match the local security policy.
Fine, but routers at your ISP are not primarily security gateways.
In article <4falvnF1hduldU4@news.dfncis.de>,
Sebastian Gottschalk
>Walter Roberson wrote:
>> There are no security features in icmp, and in particular there
>> is no authentication that an ICMP ECHO packet comes from the IP
>> that it claims to come from. If a terminal firewall or router
>> responds to ICMP ECHO requests directed to non-existant systems with
>> ICMP UNREACHABLE packets (of whatever subtype), then that firewall
>> or router makes a nifty contribution to DDoS (Distributed Denial
>> of Service) attacks.
>Why? How?
Have your "owned" systems spoof icmp echo packets, addressed to
security gateways that respond with ICMP Unreachables, with the source
address set to the system one wants to DDoS. The resulting Unreachable
will not go to the system that sent out the ICMP, but instead
to the system whose IP address appeared in the ICMP. The attack
then becomes practically untraceable, and if a large group of
such intermediate security gateways are used, the attack cannot
reasonably be filtered based upon IP.
>> Furthermore, it takes resources on the security gateway to
>> ARP for the destination, hold that status until a timeout, and then
>> create an ICMP UNREACHABLE packet. If the security gateway has a
>> heavy load -- normal traffic or just a lot of random probes or a DoS
>> or DDoS attack -- then responding can be an unaffordable drain on
>> resources.
>That's why rate limits are good for!
And what does one do when the rate limit is hit?
If the gateway responds with ICMP UNREACHABLE, perhaps with a subtype
about administrative policy denial, then resources are still required
for that (keep in mind that upload bandwidth might be considerably
lower or proportionately more expensive than download bandwidth.)
If the gateway just drops the ICMP ECHO packet without reply, then the
security gateway has joined the ranks of the "only a few lousy big
ISPs" (or whatever the exact wording was), as not producing
-any- ICMP UNREACHABLE HOSTUNREACHABLE is merely the same thing
as rate limiting such respones to zero.
>> For these reasons, -many- security gateways are set to NOT respond
>> to ICMP ECHO, and NOT respond to TCP or UDP packets that do not
>> match the local security policy.
>Fine, but routers at your ISP are not primarily security gateways.
I don't see the relevance of that last remark to anything that
I had said? I made no statement about the propriety of ISPs
filtering ICMP on behalf of their customers or on behalf of the
ISPs' infrastructure: my remark was merely that failing to produce
ICMP Unreachables was common at security gateways, to which someone
counter-claimed that it was not common, in response to which I
explained why it -is- common on security gateways.
Walter Roberson wrote:
> Have your "owned" systems spoof icmp echo packets, addressed to
> security gateways that respond with ICMP Unreachables, with the source
> address set to the system one wants to DDoS. The resulting Unreachable
> will not go to the system that sent out the ICMP, but instead
> to the system whose IP address appeared in the ICMP. The attack
> then becomes practically untraceable, and if a large group of
> such intermediate security gateways are used, the attack cannot
> reasonably be filtered based upon IP.
This is true for almost any spoofed attack and doesn't require any
redirects. The real matter should only be about how big the
amplification in traffic is, and certainly ICMP should be your least worry.
>>> Furthermore, it takes resources on the security gateway to
>>> ARP for the destination, hold that status until a timeout, and then
>>> create an ICMP UNREACHABLE packet. If the security gateway has a
>>> heavy load -- normal traffic or just a lot of random probes or a DoS
>>> or DDoS attack -- then responding can be an unaffordable drain on
>>> resources.
>
>> That's why rate limits are good for!
>
> And what does one do when the rate limit is hit?
Slowing down or stop responding.
> If the gateway just drops the ICMP ECHO packet without reply, then the
> security gateway has joined the ranks of the "only a few lousy big
> ISPs" (or whatever the exact wording was), as not producing
> -any- ICMP UNREACHABLE HOSTUNREACHABLE is merely the same thing
> as rate limiting such respones to zero.
A constant flow of ICMP Echo Requests are not a part of normal
operation. With rate limits, such systems go back to normal mode.
> my remark was merely that failing to produce
> ICMP Unreachables was common at security gateways,
and routers. Better reread what you wrote.
In article <4fb3f0F1i8eijU1@news.dfncis.de>,
Sebastian Gottschalk
>Walter Roberson wrote:
>> my remark was merely that failing to produce
>> ICMP Unreachables was common at security gateways,
>and routers. Better reread what you wrote.
The phrase I used was "terminal firewalls and routers"; the
adjective "terminal" applies to "routers" as well as "firewalls".
"security gateway" is a generic term that includes any kind of device
that provides security controls (including, e.g., deliberately not
providing ICMP Unreachable), whether they be marketed as
"router" or "firewall" or something else.
So, whatever you were reading in about intermediate routers at
ISPs was not present in my posting.
[Note: In English, if you have a sentance fragment of the form
ADJECTIVE NOUN1 CONJUNCTION NOUN2 then the adjective
"distributes across" the conjunction and applies to both nouns.
In cases where the distribution is not intended, a comma is put before
the conjunction or else the whole is rewritten as
NOUN2 CONJUNCTION ADJECTIVE NOUN1
Examples:
rotten apples or oranges (rotten applies to both)
rotten apples, or oranges (rotten applies only to apples)
oranges or rotten apples (clearer form of the above)
]
In article <7vUjg.25840$IK3.7508@pd7tw1no>,
roberson@hushmail.com (Walter Roberson) wrote:
> In article
> B. Nice
> >On Tue, 13 Jun 2006 23:28:54 GMT, roberson@hushmail.com (Walter
> >Roberson) wrote:
>
> >>If you could provide a technical definition of 'stealthed' then
> >>we might be able to answer the question. Different people mean different
> >>things by it, and the answer will be different depending on the
> >>definition.
>
> >I was referring to "stealthed" in the meaning: not responding to ICMP
> >requests.
>
> >In that case the answer to my question must obviously be: no response.
>
> Note, though, that some common ping programs use TCP or UDP instead
> of ICMP.
Which "common ping programs" are these?
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***