Last message on previous page:
Archived from groups: comp.security.firewalls (More info?)

Micheal Robert Zium wrote:

> Purl Gurl wrote:
> >Jens Hoffmann wrote:

(snipped)

> >> Port 0 and ICMP are not the same. really.

> >Yes. There is much debate on this topic. One
> >of my links provided, discusses this issue.

> You are very intelligent.

Yes, I am. Why I am intelligent is when I moved from being
a penniless ignorant rural Oklahoma farm girl, I made a
decision, at a young age, to dedicate myself to becoming
well educated and financially secure. I have attended
college, non-stop, since 1980. I have worked for decades
to become well educated. Have you?

Clearly you missed my link references to articles which
discuss this port zero / ICMP controversy and confusion.
You really should pay more attention, rather than investing
so much thought and effort into how to best harass me.


> I'll bet you even really know there is no such thing
> as an ICMP port 0.

I am still researching this. There is much controversy over
this. I have learned, from friendly people here, there is
a lot of confusion created by referring to an ICMP type
number as a port number. That makes sense.

Nonetheless, I do have in my well calloused hands, a report
from a security firm indicating ICMP responses from port 0
at our server. I am not sure what to make of this.

Internet research today yielded some articles indicating
ethernet to ethernet routing employs ICMP in a manner
which does not comply with what I have learned here.
This I discussed at length. Perhaps you did not fully
understand the implications of my article.

You will note in one of my articles today, I have been
performing a lot of hardware tests and noting results.
I do have a reputation for digging deep into any given
topic, to learn as much as possible. This is a direct
reflection of my strong desire to learn.

This desire is evidenced by my finding two Apache
bugs over the past year, very serious bugs still being
discussed on this very day. Rather odd, an entire
development community never found what I found.

I not yet prepared to commit to this rule ICMP cannot
originate from port zero. Currently, my research is
split fifty-fifty on this. It would be foolish of
me to commit on this, in lieu of knowing for certain.

Do you expend time and effort into research and learning,
or do you spend most of your time looking for me?

What do you think about my idea of you boys starting a
new newsgroup named after me? I fashion this to be a
great idea. This would afford you boys a place to meet,
gossip and such, during those times I "vanish" to
guest lecture at my university.

Give this some thought. Lots of fun for you, my groupies!


Purl Gurl

Archived from groups: comp.security.firewalls (More info?)

"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
news:40AD705F.E07EBC3B@purlgurl.net...
> Purl Gurl wrote:
>
> > Vogulus wrote:
>
> (snipped)
>
> > Relax boy, you are about to blow a fifty amp fuse.
>
>
> "A search of google and google groups proves that you
> love dispute. You love name-calling. You post ridiculous
> misinformation, when it is corrected, or anyone tries to
> help you; you do nothing but insult them. You are "infamous,"
> (Your own word) for being a troll, and a jerk."
>
>
> I understand now.

No, you don't understand and that's the problem.

When someone asks a question, I answer it, then they proceed to insult me.

I'm going to search google groups... and google, and find out what kind of
troll I am dealing with.

Now it's very clear what kind.

Later,
Vogulus Eversor

Archived from groups: comp.security.firewalls (More info?)

"Stalks" <sorry@dont.want.spam.tv> wrote in message
news:68arc.15787505$Id.2615148@news.easynews.com...

<snipped>

>
> Although, ICMP never actually makes a connection does it?`

in case of a echo request and echo reply (when you ping outside),
yes the reply is RELATED to the outgoing request

> similar to UDP
> in the way it sends and forgets? I dont know, perhaps the ESTABLISHED
> state rule isnt needed

yes it is, when you send a UDP packet to a closed port, normal behavior
is to receive an ICMP Type 3 Code 3 (Port unreachable). This packet is
RELATED and indiquates your applications that the port is closed,
so apps do not have to have hang until a timeout value is expired to
tell you that it doesnt work.

>, but I remember reading somewhere about it.

this article is excellent :
http://iptables-tutorial.frozentux [...] ONNECTIONS

> Nevertheless, that and the RELATED rule allow ICMP incoming to
> connections that already have a previous connection.
>
> All outgoing ICMP is allowed. Would I be missing out on anything
> critical with this particular set of firewall rules?

not really, but Casey's rules are excellent, there are some ICMP
codes that arent really needed


>
> --
> May the ping be with you ....

and so the pong

Have a nice day

Maxime Ducharme
Programmeur / Spécialiste en sécurité réseau


>
> Registered Linux user number: 355729

Archived from groups: comp.security.firewalls (More info?)

Maxime Ducharme wrote:

> Stalks wrote:

(snipped)

> when you send a UDP packet to a closed port, normal behavior
> is to receive an ICMP Type 3 Code 3 (Port unreachable).

What response is effected when a port is stealthed?

Is it possible to send a query to a stealthed port
which effects an ICMP response, when this should not
take place?


Purl Gurl

Archived from groups: comp.security.firewalls (More info?)

Purl Gurl wrote:
> Maxime Ducharme wrote:
>
>
>>Stalks wrote:
>
>
> (snipped)
>
>
>>when you send a UDP packet to a closed port, normal behavior
>>is to receive an ICMP Type 3 Code 3 (Port unreachable).
>
>
> What response is effected when a port is stealthed?
>
> Is it possible to send a query to a stealthed port
> which effects an ICMP response, when this should not
> take place?
>
>
> Purl Gurl

My understanding was a closed port is stealthed *because* it doesnt return an ICMP response.
Therefore not letting on that there is a computer available.

--
May the ping be with you ....

Registered Linux user number: 355729

Archived from groups: comp.security.firewalls (More info?)

Hi Purl

"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
news:40AE0B5D.F54ED4CA@purlgurl.net...
>
> (snipped)
>
> > when you send a UDP packet to a closed port, normal behavior
> > is to receive an ICMP Type 3 Code 3 (Port unreachable).
>
> What response is effected when a port is stealthed?

a "stealthed" port means the client sends a UDP packet to
a closed port, and the server does not send an ICMP
error message back (in iptables, it is DROPing packets).


>
> Is it possible to send a query to a stealthed port
> which effects an ICMP response, when this should not
> take place?

nope, see above reply
stealth = no response

>
>
> Purl Gurl

Have a nice day

Maxime Ducharme Programmeur / Spécialiste en sécurité réseau
mducharme@cybergeneration.com

Archived from groups: comp.security.firewalls (More info?)

Stalks wrote:

> Purl Gurl wrote:
> > Maxime Ducharme wrote:
> >>Stalks wrote:

(snipped)


> >>when you send a UDP packet to a closed port, normal behavior
> >>is to receive an ICMP Type 3 Code 3 (Port unreachable).

> > What response is effected when a port is stealthed?

> > Is it possible to send a query to a stealthed port
> > which effects an ICMP response, when this should not
> > take place?

> My understanding was a closed port is stealthed *because*
> it doesnt return an ICMP response. Therefore not letting on
> that there is a computer available.

This is my understanding as well, and appears to be a
generally accepted notion.

All of our ports are stealthed except for those with
specific services available. I check this via various
internet sites, several times a month, to be sure our
stealthed ports are just such.

I am still stuck on this port 0 ICMP response thing.

Your article has caused me to consider port 0 is such
an "unusual" port, testing facilities may simply report
it stealthed without actually testing. If port 0 is
simply closed, not stealthed, this would elicit an
ICMP response which might be reported as an ICMP
response from port 0 although inaccurate wording.

Our security survey reports three ICMP type responses
from port 0 and I would like to dismiss this as being
an error in wording within this report. Clearly this
is not a wording error using type number as a port
number because the ICMP responses were not "0" type.

In a nutshell, various tests show port 0 as stealthed.
This security report indicates ICMP responses for port 0.

This will bug me until I discover what is really happening,
error in wording, a hack which does elicit ICMP from port 0,
a report of stealthed when actually simply closed, open
port 0 being reported as stealthed. So clueless on this.

Bothers me to know there "might" be a security concern
and I cannot garner enough information to verify there
is a security concern, or there is not a security concern.

This is why I am so concerned and so obsessive about this.

On May 15 my logs show ten hits on port 0, which is a
direct result of our security survey. On May 20 there
is one hit from GRC Shields Up. Those are expected.
Logs indicate zero outbound traffic. No concerns.

Use of nmap displays no hits on port 0 which indicates
to me nmap does not behave as documented. I used many
different arguments for nmap, but no record of nmap
having hit port 0 as it should. For now, it appears
nmap reports testing port 0 when it actually does not.
Use of nmap does show for port 80 in my logs. It does
not show on port 0 logs. Something is not right with
nmap, perhaps buggy or flawed.

Exasperating this, there is no way to log ICMP transactions
so I cannot verify if those ten security survey hits did,
in fact, elicit ICMP responses by hacking port 0 so much.
Logs verify hack attempts on port 0 as reported with no
outbound traffic, save for their ICMP reported responses.

Lot of problems presented by port zero, and zero solutions.

Thanks for your input, Stalks.

Purl Gurl

Archived from groups: comp.security.firewalls (More info?)

Maxime Ducharme wrote:

> Purl Gurl wrote:

(snipped)

> > > when you send a UDP packet to a closed port, normal behavior
> > > is to receive an ICMP Type 3 Code 3 (Port unreachable).

> > What response is effected when a port is stealthed?

> a "stealthed" port means the client sends a UDP packet to
> a closed port, and the server does not send an ICMP
> error message back (in iptables, it is DROPing packets).

> > Is it possible to send a query to a stealthed port
> > which effects an ICMP response, when this should not
> > take place?

> nope, see above reply
> stealth = no response

This is precisely my understanding as well, Maxime.

Now I am questioning if this is "always" true. There
is mounting evidence which contradicts this, but there
are so many variables involved, I am having extreme
difficulties proving or dismissing.

I have an article response to Stalks, time stamped
just before this one. Greater details are afforded.
You might find my testing of nmap and results to
be of personal interest to you.

Purl Gurl

Archived from groups: comp.security.firewalls (More info?)

"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
news:40AE182D.DF340FFA@purlgurl.net...

> (snipped)
>

>
> Now I am questioning if this is "always" true. There
> is mounting evidence which contradicts this, but there
> are so many variables involved, I am having extreme
> difficulties proving or dismissing.

this is not as hard as you are saying

"stealth" is a word used on many sites and in many
programs, and means "no response"

isnt it clear ?

there is no other possibilities, as long as you are
talking about UDP and TCP ports

ICMP is not involved in "stealth" concept


>
> I have an article response to Stalks, time stamped
> just before this one. Greater details are afforded.
> You might find my testing of nmap and results to
> be of personal interest to you.

nope, thx

>
> Purl Gurl

Maxime

Archived from groups: comp.security.firewalls (More info?)

"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
news:40AE1702.5BDB249C@purlgurl.net...

(snipped)

> I am still stuck on this port 0 ICMP response thing.

Again, there is not port in ICMP packlets.

Here is a picture of an ICMP packet :

http://www.onlamp.com/pub/a/bsd/20 [...] asics.html

I suggest that you read again before posting.

Have a nice day

Maxime

Archived from groups: comp.security.firewalls (More info?)

On Fri, 21 May 2004 07:49:38 -0700, Purl Gurl spoketh
>
>I am still stuck on this port 0 ICMP response thing.
>

There is no port zero.

Since most programs dealing with reporting traffic uses source and
destination IP addresses and ports, port 0 is often put in when
reporting ICMP messages. That doesn't mean that there was ever traffic
on port 0, just that the zero is put there rather than a blank.


Lars M. Hansen
http://www.hansenonline.net
(replace 'badnews' with 'news' in e-mail address)

Archived from groups: comp.security.firewalls (More info?)

Thx Lars

thats also what i'm thinking, Purl see this "port 0" somewhere
in his devices/software output.

This is only a way of naming "blank"

Maxime Ducharme
Programmeur / Spécialiste en sécurité réseau

"Lars M. Hansen" <badnews@hansenonline.net> wrote in message
news:ifksa0ld11jehn78gmrr44893p0i0agqak@4ax.com...
> On Fri, 21 May 2004 07:49:38 -0700, Purl Gurl spoketh
> >
> >I am still stuck on this port 0 ICMP response thing.
> >
>
> There is no port zero.
>
> Since most programs dealing with reporting traffic uses source and
> destination IP addresses and ports, port 0 is often put in when
> reporting ICMP messages. That doesn't mean that there was ever traffic
> on port 0, just that the zero is put there rather than a blank.
>
>
> Lars M. Hansen
> http://www.hansenonline.net
> (replace 'badnews' with 'news' in e-mail address)

Archived from groups: comp.security.firewalls (More info?)

Purl Gurl wrote:

>Micheal Robert Zium wrote:
>
>> You are very intelligent.
>
>Yes, I am.

<snip boring diatribe>

Hmmm...looks like I gave you way too much credit.

>> I'll bet you even really know there is no such thing
>> as an ICMP port 0.
>
>I am still researching this. There is much controversy over
>this.

Only in ignorant or stupid people's minds. Which one are you?
Nevermind, it's a rhetorical question, it's quite obvious.

Archived from groups: comp.security.firewalls (More info?)

"Casey" <casey@nosuch.net> wrote in message
news:MPG.1b16e5f15b8ecfb198972c@news.west.earthlink.net...
> In article <10ant8ug3454eb8@news.supernews.com>, illemann@surfbest.net
says...
> > Can I survive if I block all ICMP requests?
> > Win2K Pro SP.4 single user
> >
> >
> >
> Hi Allen,
> For about a year I was in a quandry about how set firewall rules for ICMP.
> I read everything I could find; read newsgroup posts regarding ICMP.
> My conclusion: There seems to be no consenses of how ICMP should be
> treated.
> These rules have worked very well for me:
> 1. Allow ICMP 0,3,8,11 incoming
> 2. Allow ICMP 3,8 Outgoing
> 3. Allow ICMP 0,8 incoming and outgoing to my ISP only.
> (I understand your ISP may ping you to see if you are still
> connected. You would want to respond so you will not be
> disconnected)
> 4.Block ICMP all other types incoming and outgoing.
>
> Port numbers range from 1 to 65535.
> ICMP types range from 0 to at least 18 (and probably higher
> but obsolete).
> Casey

Casey, I asked my ISP about ICMP 0,8 to/from my ISP only
and this was their response:
"Unfortunately there is no way I could give you the range of
networks or IPs that the ping would come from. It can change
depending on the access number you dial into, and also with
time as our backbone networks change their equipment. The
pings themselves would typically come from our backbone
providers such as Qwest, UUnet, etc, as they own the physical
hardware."
Does that sound reasonable?

Alan

Archived from groups: comp.security.firewalls (More info?)

In article <10aut4v7g2vbn3a@news.supernews.com>, illemann@surfbest.net says...
>
> "Casey" <casey@nosuch.net> wrote in message
> news:MPG.1b16e5f15b8ecfb198972c@news.west.earthlink.net...
> > In article <10ant8ug3454eb8@news.supernews.com>, illemann@surfbest.net
> says...
> > > Can I survive if I block all ICMP requests?
> > > Win2K Pro SP.4 single user
> > >
> > >
> > >
> > Hi Allen,
> > For about a year I was in a quandry about how set firewall rules for ICMP.
> > I read everything I could find; read newsgroup posts regarding ICMP.
> > My conclusion: There seems to be no consenses of how ICMP should be
> > treated.
> > These rules have worked very well for me:
> > 1. Allow ICMP 0,3,8,11 incoming
> > 2. Allow ICMP 3,8 Outgoing