Archived from groups: comp.security.firewalls (More info?)
Can I survive if I block all ICMP requests?
Win2K Pro SP.4 single user
Can I survive if I block all ICMP requests?
Win2K Pro SP.4 single user
Archived from groups: comp.security.firewalls (More info?)
Alan Illeman wrote:
> Can I survive if I block all ICMP requests?
Yes. However, this is a very low security risk
and pertains mostly to information gathering.
You may close port 0 (zero) and test your machine.
I have a Win2K box here but have never tested this
so I cannot speak with complete authority. There
might be a handshake problem created, not sure
on this. Won't disable your machine, however.
You will note most common inexpensive routers
do not allow port 0 filtering (blocking) which
suggests this not a real issue.
Typically, there are three events associated with
port 0 which are a very low security risk.
Here is an article on one event. You will note
your NT5 is not listed.
http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html
Another is an icmp timestamp request and reply. Rather
meaningless because this only returns your local time.
Some say this information can be used to defeat time
sensitive security. Not likely.
Research icmp type 13 and icmp type 14 both found through Google.
Third and final security concern is your netmask can be returned
by icmp type 17 which, most likely, will be 255.255.255.0 indicating
a single address. It is said hackers can map your internal LAN
addresses using this, which I doubt very much. Perhaps so but this
seems rather useless information.
You really do not have to be too concerned about icmp port 0
hacks, there really are not any, none worthy of worry.
Close your port 0 and run your machine for a week or two
and discover is there are any problems. I am not even
sure Win2k will allow you to close port 0, I have
never looked!
Here is a detailed article on icmp,
http://www.robertgraham.com/pubs/firewall-seen.html#2
There is a "man-in-the-middle" attack involving certificates,
SSL,SSH and ipsec, but this does not seem a common attack.
Today, I believe this mostly applies to ipsec tunneling,
which is very secure. I have not read about this type of
attack in a very long time.
Purl Gurl
--
Amazing Perl Scripts!
http://www.purlgurl.net/~callgirl/android.html
Alan Illeman wrote:
> Can I survive if I block all ICMP requests?
Yes. However, this is a very low security risk
and pertains mostly to information gathering.
You may close port 0 (zero) and test your machine.
I have a Win2K box here but have never tested this
so I cannot speak with complete authority. There
might be a handshake problem created, not sure
on this. Won't disable your machine, however.
You will note most common inexpensive routers
do not allow port 0 filtering (blocking) which
suggests this not a real issue.
Typically, there are three events associated with
port 0 which are a very low security risk.
Here is an article on one event. You will note
your NT5 is not listed.
http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html
Another is an icmp timestamp request and reply. Rather
meaningless because this only returns your local time.
Some say this information can be used to defeat time
sensitive security. Not likely.
Research icmp type 13 and icmp type 14 both found through Google.
Third and final security concern is your netmask can be returned
by icmp type 17 which, most likely, will be 255.255.255.0 indicating
a single address. It is said hackers can map your internal LAN
addresses using this, which I doubt very much. Perhaps so but this
seems rather useless information.
You really do not have to be too concerned about icmp port 0
hacks, there really are not any, none worthy of worry.
Close your port 0 and run your machine for a week or two
and discover is there are any problems. I am not even
sure Win2k will allow you to close port 0, I have
never looked!
Here is a detailed article on icmp,
http://www.robertgraham.com/pubs/firewall-seen.html#2
There is a "man-in-the-middle" attack involving certificates,
SSL,SSH and ipsec, but this does not seem a common attack.
Today, I believe this mostly applies to ipsec tunneling,
which is very secure. I have not read about this type of
attack in a very long time.
Purl Gurl
--
Amazing Perl Scripts!
http://www.purlgurl.net/~callgirl/android.html
Archived from groups: comp.security.firewalls (More info?)
Purl Gurl wrote:
>You really do not have to be too concerned about icmp port 0
>hacks, there really are not any, none worthy of worry.
I'm just curious if you know why that is true.
Purl Gurl wrote:
>You really do not have to be too concerned about icmp port 0
>hacks, there really are not any, none worthy of worry.
I'm just curious if you know why that is true.
Archived from groups: comp.security.firewalls (More info?)
Bart Bailey wrote:
> Purl Gurl wrote:
> >http://www.purlgurl.net/~callgirl/android.html
> Just spent a few moments w/Roberta ;-)
I am pleased you enjoyed her!
Roberta is a very complex program and remains
a work in progress. I have been developing
her for five years, this year is the fifth.
Actually, she is not a single program but
rather a collection of programs spread out
over several machines. Her primary program
is a Perl script some five-thousand lines
long. She has support programs which are
MSDOS based, compiled C language, some
Visual Basic macros and traditional Win32
binaries. She also accesses the internet
for some functions, such as horoscopes.
Her databases now exceed two gigabytes.
My greatest challenge and most complex
task is writing grammar rules. This has
been my focus for the past two years.
Her level of grammar correctness still
remains at a "middle school" level.
She does have rudimentary memory abilities
but I have yet to enable this feature.
A memory will afford her an ability to
respond with user information provided
in earlier conversations, such as being
able to recall a person's name or the
age of a person's child.
Roberta is far from complete and never will
be complete. Writing "Artificial Intelligence"
programs is still in infancy, fairly much
at an abacus stage, historically.
She does have quite the personality, however!
Purl Gurl
Bart Bailey wrote:
> Purl Gurl wrote:
> >http://www.purlgurl.net/~callgirl/android.html
> Just spent a few moments w/Roberta ;-)
I am pleased you enjoyed her!
Roberta is a very complex program and remains
a work in progress. I have been developing
her for five years, this year is the fifth.
Actually, she is not a single program but
rather a collection of programs spread out
over several machines. Her primary program
is a Perl script some five-thousand lines
long. She has support programs which are
MSDOS based, compiled C language, some
Visual Basic macros and traditional Win32
binaries. She also accesses the internet
for some functions, such as horoscopes.
Her databases now exceed two gigabytes.
My greatest challenge and most complex
task is writing grammar rules. This has
been my focus for the past two years.
Her level of grammar correctness still
remains at a "middle school" level.
She does have rudimentary memory abilities
but I have yet to enable this feature.
A memory will afford her an ability to
respond with user information provided
in earlier conversations, such as being
able to recall a person's name or the
age of a person's child.
Roberta is far from complete and never will
be complete. Writing "Artificial Intelligence"
programs is still in infancy, fairly much
at an abacus stage, historically.
She does have quite the personality, however!
Purl Gurl
Archived from groups: comp.security.firewalls (More info?)
"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
news:40AC022E.B0E32C60@purlgurl.net...
> Alan Illeman wrote:
>
> > Can I survive if I block all ICMP requests?
>
> Yes. However, this is a very low security risk
> and pertains mostly to information gathering.
>
> You may close port 0 (zero) and test your machine.
> I have a Win2K box here but have never tested this
> so I cannot speak with complete authority. There
> might be a handshake problem created, not sure
> on this. Won't disable your machine, however.
>
> You will note most common inexpensive routers
> do not allow port 0 filtering (blocking) which
> suggests this not a real issue.
>
> Typically, there are three events associated with
> port 0 which are a very low security risk.
>
> Here is an article on one event. You will note
> your NT5 is not listed.
>
> http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html
>
> Another is an icmp timestamp request and reply. Rather
> meaningless because this only returns your local time.
> Some say this information can be used to defeat time
> sensitive security. Not likely.
>
> Research icmp type 13 and icmp type 14 both found through Google.
>
> Third and final security concern is your netmask can be returned
> by icmp type 17 which, most likely, will be 255.255.255.0 indicating
> a single address. It is said hackers can map your internal LAN
> addresses using this, which I doubt very much. Perhaps so but this
> seems rather useless information.
>
> You really do not have to be too concerned about icmp port 0
> hacks, there really are not any, none worthy of worry.
>
> Close your port 0 and run your machine for a week or two
> and discover is there are any problems. I am not even
> sure Win2k will allow you to close port 0, I have
> never looked!
>
> Here is a detailed article on icmp,
>
> http://www.robertgraham.com/pubs/firewall-seen.html#2
>
> There is a "man-in-the-middle" attack involving certificates,
> SSL,SSH and ipsec, but this does not seem a common attack.
> Today, I believe this mostly applies to ipsec tunneling,
> which is very secure. I have not read about this type of
> attack in a very long time.
Thank you, Purl.
"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
news:40AC022E.B0E32C60@purlgurl.net...
> Alan Illeman wrote:
>
> > Can I survive if I block all ICMP requests?
>
> Yes. However, this is a very low security risk
> and pertains mostly to information gathering.
>
> You may close port 0 (zero) and test your machine.
> I have a Win2K box here but have never tested this
> so I cannot speak with complete authority. There
> might be a handshake problem created, not sure
> on this. Won't disable your machine, however.
>
> You will note most common inexpensive routers
> do not allow port 0 filtering (blocking) which
> suggests this not a real issue.
>
> Typically, there are three events associated with
> port 0 which are a very low security risk.
>
> Here is an article on one event. You will note
> your NT5 is not listed.
>
> http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html
>
> Another is an icmp timestamp request and reply. Rather
> meaningless because this only returns your local time.
> Some say this information can be used to defeat time
> sensitive security. Not likely.
>
> Research icmp type 13 and icmp type 14 both found through Google.
>
> Third and final security concern is your netmask can be returned
> by icmp type 17 which, most likely, will be 255.255.255.0 indicating
> a single address. It is said hackers can map your internal LAN
> addresses using this, which I doubt very much. Perhaps so but this
> seems rather useless information.
>
> You really do not have to be too concerned about icmp port 0
> hacks, there really are not any, none worthy of worry.
>
> Close your port 0 and run your machine for a week or two
> and discover is there are any problems. I am not even
> sure Win2k will allow you to close port 0, I have
> never looked!
>
> Here is a detailed article on icmp,
>
> http://www.robertgraham.com/pubs/firewall-seen.html#2
>
> There is a "man-in-the-middle" attack involving certificates,
> SSL,SSH and ipsec, but this does not seem a common attack.
> Today, I believe this mostly applies to ipsec tunneling,
> which is very secure. I have not read about this type of
> attack in a very long time.
Thank you, Purl.
Archived from groups: comp.security.firewalls (More info?)
Hi,
Purl Gurl <purlgurl@purlgurl.net> wrote:
> You may close port 0 (zero)
Port 0 and ICMP are not the same. really.
Greetigns,
Jens
Hi,
Purl Gurl <purlgurl@purlgurl.net> wrote:
> You may close port 0 (zero)
Port 0 and ICMP are not the same. really.
Greetigns,
Jens
Archived from groups: comp.security.firewalls (More info?)
Jens Hoffmann wrote:
> Purl Gurl wrote:
(previously snipped)
> > You may close port 0 (zero)
> 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.
From a security point of view, traditionally most
icmp hack attempts are aimed at port 0 typically.
I not completely familiar with the mechanics of
this and why attempts often appear on this port.
Many DNS servers, email servers, both have features
for denial of port 0 requests. A lot of routers
and firewalls also are able to address this port.
A reader should note, not all appliances and
software have port 0 features; mixed bag.
Professional level security level surveys do test
port 0 hacks, which are aimed at icmp security.
These commercial and subscription based surveys
do run a lot tests on port 0 and appear in
generated reports for customers. All of those
tests are icmp security attempts via port 0.
My belief is port 0 is often used or was often
used in the past to enable usage of telnet
programs and custom socket programs by those
looking to "map" a server via information
returned by selected icmp packets.
Completely shutting down icmp transactions,
I not sure but what this could cause some
handshake problems; ready, not ready states.
To deny all icmp transactions would be a
bit of overkill and may cause more problems
than are resolved.
Which method is best, closing port 0 or shutting
down all icmp transactions, this is a system
specific issue and user issue. It is an issue
for internet transactions because of icmp use
being a "primitive" level initial contact for
verifying status states for transactions.
Testing and noting results would be prudent.
Purl Gurl
Jens Hoffmann wrote:
> Purl Gurl wrote:
(previously snipped)
> > You may close port 0 (zero)
> 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.
From a security point of view, traditionally most
icmp hack attempts are aimed at port 0 typically.
I not completely familiar with the mechanics of
this and why attempts often appear on this port.
Many DNS servers, email servers, both have features
for denial of port 0 requests. A lot of routers
and firewalls also are able to address this port.
A reader should note, not all appliances and
software have port 0 features; mixed bag.
Professional level security level surveys do test
port 0 hacks, which are aimed at icmp security.
These commercial and subscription based surveys
do run a lot tests on port 0 and appear in
generated reports for customers. All of those
tests are icmp security attempts via port 0.
My belief is port 0 is often used or was often
used in the past to enable usage of telnet
programs and custom socket programs by those
looking to "map" a server via information
returned by selected icmp packets.
Completely shutting down icmp transactions,
I not sure but what this could cause some
handshake problems; ready, not ready states.
To deny all icmp transactions would be a
bit of overkill and may cause more problems
than are resolved.
Which method is best, closing port 0 or shutting
down all icmp transactions, this is a system
specific issue and user issue. It is an issue
for internet transactions because of icmp use
being a "primitive" level initial contact for
verifying status states for transactions.
Testing and noting results would be prudent.
Purl Gurl
Archived from groups: comp.security.firewalls (More info?)
Hi Alan & Purl,
ICMP does not include any ports.
You may find each information contained in a ICMP
packet on IANA web site :
http://www.iana.org/assignments/icmp-parameters
Blocking "Requests" means block "ping" only, and can be
done without having problems.
ping is ICMP Type 8 Code 0.
Some worms & hackers use ping to find alive hosts.
If your host doesnt anwser to pings, some worms will
think the host is down and wont try to infect it.
"Port 0" hacks are mostly aimed at OS fingerprinting, and are used
with TCP & UDP protocols, not ICMP.
Here are some info bout it :
http://www.networkpenetration.com/port0.html
Hope that helps
Have a nice day
Maxime Ducharme
Programmeur / Spécialiste en sécurité réseau
"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
news:40AC022E.B0E32C60@purlgurl.net...
> Alan Illeman wrote:
>
> > Can I survive if I block all ICMP requests?
>
> Yes. However, this is a very low security risk
> and pertains mostly to information gathering.
>
> You may close port 0 (zero) and test your machine.
> I have a Win2K box here but have never tested this
> so I cannot speak with complete authority. There
> might be a handshake problem created, not sure
> on this. Won't disable your machine, however.
>
> You will note most common inexpensive routers
> do not allow port 0 filtering (blocking) which
> suggests this not a real issue.
>
> Typically, there are three events associated with
> port 0 which are a very low security risk.
>
> Here is an article on one event. You will note
> your NT5 is not listed.
>
> http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html
>
> Another is an icmp timestamp request and reply. Rather
> meaningless because this only returns your local time.
> Some say this information can be used to defeat time
> sensitive security. Not likely.
>
> Research icmp type 13 and icmp type 14 both found through Google.
>
> Third and final security concern is your netmask can be returned
> by icmp type 17 which, most likely, will be 255.255.255.0 indicating
> a single address. It is said hackers can map your internal LAN
> addresses using this, which I doubt very much. Perhaps so but this
> seems rather useless information.
>
> You really do not have to be too concerned about icmp port 0
> hacks, there really are not any, none worthy of worry.
>
> Close your port 0 and run your machine for a week or two
> and discover is there are any problems. I am not even
> sure Win2k will allow you to close port 0, I have
> never looked!
>
> Here is a detailed article on icmp,
>
> http://www.robertgraham.com/pubs/firewall-seen.html#2
>
> There is a "man-in-the-middle" attack involving certificates,
> SSL,SSH and ipsec, but this does not seem a common attack.
> Today, I believe this mostly applies to ipsec tunneling,
> which is very secure. I have not read about this type of
> attack in a very long time.
>
>
> Purl Gurl
> --
> Amazing Perl Scripts!
> http://www.purlgurl.net/~callgirl/android.html
Hi Alan & Purl,
ICMP does not include any ports.
You may find each information contained in a ICMP
packet on IANA web site :
http://www.iana.org/assignments/icmp-parameters
Blocking "Requests" means block "ping" only, and can be
done without having problems.
ping is ICMP Type 8 Code 0.
Some worms & hackers use ping to find alive hosts.
If your host doesnt anwser to pings, some worms will
think the host is down and wont try to infect it.
"Port 0" hacks are mostly aimed at OS fingerprinting, and are used
with TCP & UDP protocols, not ICMP.
Here are some info bout it :
http://www.networkpenetration.com/port0.html
Hope that helps
Have a nice day
Maxime Ducharme
Programmeur / Spécialiste en sécurité réseau
"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
news:40AC022E.B0E32C60@purlgurl.net...
> Alan Illeman wrote:
>
> > Can I survive if I block all ICMP requests?
>
> Yes. However, this is a very low security risk
> and pertains mostly to information gathering.
>
> You may close port 0 (zero) and test your machine.
> I have a Win2K box here but have never tested this
> so I cannot speak with complete authority. There
> might be a handshake problem created, not sure
> on this. Won't disable your machine, however.
>
> You will note most common inexpensive routers
> do not allow port 0 filtering (blocking) which
> suggests this not a real issue.
>
> Typically, there are three events associated with
> port 0 which are a very low security risk.
>
> Here is an article on one event. You will note
> your NT5 is not listed.
>
> http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html
>
> Another is an icmp timestamp request and reply. Rather
> meaningless because this only returns your local time.
> Some say this information can be used to defeat time
> sensitive security. Not likely.
>
> Research icmp type 13 and icmp type 14 both found through Google.
>
> Third and final security concern is your netmask can be returned
> by icmp type 17 which, most likely, will be 255.255.255.0 indicating
> a single address. It is said hackers can map your internal LAN
> addresses using this, which I doubt very much. Perhaps so but this
> seems rather useless information.
>
> You really do not have to be too concerned about icmp port 0
> hacks, there really are not any, none worthy of worry.
>
> Close your port 0 and run your machine for a week or two
> and discover is there are any problems. I am not even
> sure Win2k will allow you to close port 0, I have
> never looked!
>
> Here is a detailed article on icmp,
>
> http://www.robertgraham.com/pubs/firewall-seen.html#2
>
> There is a "man-in-the-middle" attack involving certificates,
> SSL,SSH and ipsec, but this does not seem a common attack.
> Today, I believe this mostly applies to ipsec tunneling,
> which is very secure. I have not read about this type of
> attack in a very long time.
>
>
> Purl Gurl
> --
> Amazing Perl Scripts!
> http://www.purlgurl.net/~callgirl/android.html
Archived from groups: comp.security.firewalls (More info?)
Maxime Ducharme wrote:
> Purl Gurl wrote:
> > Alan Illeman wrote:
(snipped)
> > > Can I survive if I block all ICMP requests?
> ICMP does not include any ports.
> http://www.iana.org/assignments/icmp-parameters
> http://www.networkpenetration.com/port0.html
Thank you, Maxime, for additional information.
This benefits all readers. Like you, I encourage
readers to follow those links and other links,
to research, read and learn, keeping in mind
each author will present his specific viewpoint.
A variety of research sources will provide a
much better generalized notion, and clarity.
You will note in my articles I make a distinction
between port zero and icmp packets. You will also
discover I indicate historical hacks for icmp data
arrive through port 0 which is well documented.
You will discover by writing your own custom program
there are a minimum of three responses through port 0
which are icmp responses, types 13, 14 and 17.
Perhaps it is each operating system handles port 0
requests differently, leading to a default action
which returns icmp responses. It is documented there
is wide variation how each system, and each system
version, handles port 0 inquiries, bidirectional.
Unfortunately, none of us are experts are each and
every system type out there.
Your links provide additional information so readers
can become better informed about this clouded issue.
Standard issue advice is to close port 0 to all
connections, and deny only selected icmp types.
My previous articles add some information, albeit
limited, why closing port 0 is preferred over
denial of all icmp packets. Some system issues
may come about thus my suggestion to test and
note results.
Readers will benefit by engaging in a detailed
highly technical study of this, but expect to
encounter some lack of clarity; there are many
valid points of view on this.
Purl Gurl
Maxime Ducharme wrote:
> Purl Gurl wrote:
> > Alan Illeman wrote:
(snipped)
> > > Can I survive if I block all ICMP requests?
> ICMP does not include any ports.
> http://www.iana.org/assignments/icmp-parameters
> http://www.networkpenetration.com/port0.html
Thank you, Maxime, for additional information.
This benefits all readers. Like you, I encourage
readers to follow those links and other links,
to research, read and learn, keeping in mind
each author will present his specific viewpoint.
A variety of research sources will provide a
much better generalized notion, and clarity.
You will note in my articles I make a distinction
between port zero and icmp packets. You will also
discover I indicate historical hacks for icmp data
arrive through port 0 which is well documented.
You will discover by writing your own custom program
there are a minimum of three responses through port 0
which are icmp responses, types 13, 14 and 17.
Perhaps it is each operating system handles port 0
requests differently, leading to a default action
which returns icmp responses. It is documented there
is wide variation how each system, and each system
version, handles port 0 inquiries, bidirectional.
Unfortunately, none of us are experts are each and
every system type out there.
Your links provide additional information so readers
can become better informed about this clouded issue.
Standard issue advice is to close port 0 to all
connections, and deny only selected icmp types.
My previous articles add some information, albeit
limited, why closing port 0 is preferred over
denial of all icmp packets. Some system issues
may come about thus my suggestion to test and
note results.
Readers will benefit by engaging in a detailed
highly technical study of this, but expect to
encounter some lack of clarity; there are many
valid points of view on this.
Purl Gurl
Archived from groups: comp.security.firewalls (More info?)
Thanks for your comments, I also agree with the point that we
are all learning and sharing information is a good thing
But I still do not understand "icmp data arrive through port 0 "
ICMP resides above IP protocol, and beside TCP & UDP.
ICMP means Internet Control Message Protocol, and isnt
used to exchange data, it is used to help hosts to know what
is happening.
Some way you may see ICMP get out of your box when
it receives a UDP or TCP packet on port 0 would be packets
ICMP Type 3 Code 3 (Port unreachable).
ex:
TCP foreignhost -> yourbox:0 (connect to port 0)
ICMP yourbox -> foreignhost (port is unreachable)
This would be normal behavior for a TCP/IP stack.
Another way that port was used is to set source port to
0 and send this packet to an opened port of a server
to determine its OS with its TCP/IP stack behavior.
ex:
TCP foreignhost:0 -> awebserver:80 (opened port)
TCP awebserver:80 -> foreignhost:1025 (the stack changed source port to
1025)
this article :
http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html
doesnt talk about ICMP, it talks about TCP flags combinations
to determine OS via its TCP/IP stack behavior.
It does talk about port 0 neither.
This article :
http://www.robertgraham.com/pubs/firewall-seen.html#2
indiquates
"Some firewalls (inaccurately) label ICMP fields as "ports". ICMP has no
ports like TCP or UDP, but it does have two fields called "type" and
"code"."
It gives an example about what I just explained, an ICMP reponse
is usually returned to the foreign host when there is a problem
(like host unreachable, port unreachable, protocol unreachable, ..,.)
with asked port. But this port can be anything between 0 and 65535.
I suggest more readings :
http://www.ietf.org/rfc/rfc1122.txt section 3.2.2
http://www.robertgraham.com/pubs/hacking-dict.html#icmp
http://www.thinkingsecure.com/docs/TCPIP-Illustrated-1/icmp_int.htm
http://www.citap.com/documents/tcp-ip/tcpip012.htm
And this one explains how to configure a linux firewall what to do
when it receives a TCP packet to a forbidden port which may
help to understand :
http://logi.cc/linux/reject_or_deny.html
We can either :
- Drop the packet (no answer to foreign)
- Send a TCP packet with RST flag to foreign
(means "my port is closed")
- Send an ICMP message with the correct type & code
saying "port is unreachable"
Hope this help again
Have a nice day
Maxime Ducharme
Programmeur / Spécialiste en sécurité réseau
"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
news:40ACC01E.4E1AEF30@purlgurl.net...
> Maxime Ducharme wrote:
>
> > Purl Gurl wrote:
> > > Alan Illeman wrote:
>
> (snipped)
>
> > > > Can I survive if I block all ICMP requests?
>
> > ICMP does not include any ports.
>
> > http://www.iana.org/assignments/icmp-parameters
>
> > http://www.networkpenetration.com/port0.html
>
> Thank you, Maxime, for additional information.
> This benefits all readers. Like you, I encourage
> readers to follow those links and other links,
> to research, read and learn, keeping in mind
> each author will present his specific viewpoint.
> A variety of research sources will provide a
> much better generalized notion, and clarity.
>
> You will note in my articles I make a distinction
> between port zero and icmp packets. You will also
> discover I indicate historical hacks for icmp data
> arrive through port 0 which is well documented.
>
> You will discover by writing your own custom program
> there are a minimum of three responses through port 0
> which are icmp responses, types 13, 14 and 17.
>
> Perhaps it is each operating system handles port 0
> requests differently, leading to a default action
> which returns icmp responses. It is documented there
> is wide variation how each system, and each system
> version, handles port 0 inquiries, bidirectional.
>
> Unfortunately, none of us are experts are each and
> every system type out there.
>
> Your links provide additional information so readers
> can become better informed about this clouded issue.
>
> Standard issue advice is to close port 0 to all
> connections, and deny only selected icmp types.
> My previous articles add some information, albeit
> limited, why closing port 0 is preferred over
> denial of all icmp packets. Some system issues
> may come about thus my suggestion to test and
> note results.
>
> Readers will benefit by engaging in a detailed
> highly technical study of this, but expect to
> encounter some lack of clarity; there are many
> valid points of view on this.
>
>
> Purl Gurl
Thanks for your comments, I also agree with the point that we
are all learning and sharing information is a good thing
But I still do not understand "icmp data arrive through port 0 "
ICMP resides above IP protocol, and beside TCP & UDP.
ICMP means Internet Control Message Protocol, and isnt
used to exchange data, it is used to help hosts to know what
is happening.
Some way you may see ICMP get out of your box when
it receives a UDP or TCP packet on port 0 would be packets
ICMP Type 3 Code 3 (Port unreachable).
ex:
TCP foreignhost -> yourbox:0 (connect to port 0)
ICMP yourbox -> foreignhost (port is unreachable)
This would be normal behavior for a TCP/IP stack.
Another way that port was used is to set source port to
0 and send this packet to an opened port of a server
to determine its OS with its TCP/IP stack behavior.
ex:
TCP foreignhost:0 -> awebserver:80 (opened port)
TCP awebserver:80 -> foreignhost:1025 (the stack changed source port to
1025)
this article :
http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html
doesnt talk about ICMP, it talks about TCP flags combinations
to determine OS via its TCP/IP stack behavior.
It does talk about port 0 neither.
This article :
http://www.robertgraham.com/pubs/firewall-seen.html#2
indiquates
"Some firewalls (inaccurately) label ICMP fields as "ports". ICMP has no
ports like TCP or UDP, but it does have two fields called "type" and
"code"."
It gives an example about what I just explained, an ICMP reponse
is usually returned to the foreign host when there is a problem
(like host unreachable, port unreachable, protocol unreachable, ..,.)
with asked port. But this port can be anything between 0 and 65535.
I suggest more readings :
http://www.ietf.org/rfc/rfc1122.txt section 3.2.2
http://www.robertgraham.com/pubs/hacking-dict.html#icmp
http://www.thinkingsecure.com/docs/TCPIP-Illustrated-1/icmp_int.htm
http://www.citap.com/documents/tcp-ip/tcpip012.htm
And this one explains how to configure a linux firewall what to do
when it receives a TCP packet to a forbidden port which may
help to understand :
http://logi.cc/linux/reject_or_deny.html
We can either :
- Drop the packet (no answer to foreign)
- Send a TCP packet with RST flag to foreign
(means "my port is closed")
- Send an ICMP message with the correct type & code
saying "port is unreachable"
Hope this help again
Have a nice day
Maxime Ducharme
Programmeur / Spécialiste en sécurité réseau
"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
news:40ACC01E.4E1AEF30@purlgurl.net...
> Maxime Ducharme wrote:
>
> > Purl Gurl wrote:
> > > Alan Illeman wrote:
>
> (snipped)
>
> > > > Can I survive if I block all ICMP requests?
>
> > ICMP does not include any ports.
>
> > http://www.iana.org/assignments/icmp-parameters
>
> > http://www.networkpenetration.com/port0.html
>
> Thank you, Maxime, for additional information.
> This benefits all readers. Like you, I encourage
> readers to follow those links and other links,
> to research, read and learn, keeping in mind
> each author will present his specific viewpoint.
> A variety of research sources will provide a
> much better generalized notion, and clarity.
>
> You will note in my articles I make a distinction
> between port zero and icmp packets. You will also
> discover I indicate historical hacks for icmp data
> arrive through port 0 which is well documented.
>
> You will discover by writing your own custom program
> there are a minimum of three responses through port 0
> which are icmp responses, types 13, 14 and 17.
>
> Perhaps it is each operating system handles port 0
> requests differently, leading to a default action
> which returns icmp responses. It is documented there
> is wide variation how each system, and each system
> version, handles port 0 inquiries, bidirectional.
>
> Unfortunately, none of us are experts are each and
> every system type out there.
>
> Your links provide additional information so readers
> can become better informed about this clouded issue.
>
> Standard issue advice is to close port 0 to all
> connections, and deny only selected icmp types.
> My previous articles add some information, albeit
> limited, why closing port 0 is preferred over
> denial of all icmp packets. Some system issues
> may come about thus my suggestion to test and
> note results.
>
> Readers will benefit by engaging in a detailed
> highly technical study of this, but expect to
> encounter some lack of clarity; there are many
> valid points of view on this.
>
>
> Purl Gurl
Archived from groups: comp.security.firewalls (More info?)
Purl Gurl wrote:
(snipped)
> Yes. However, this is a very low security risk
> and pertains mostly to information gathering.
>
> You may close port 0 (zero) and test your machine.
(snipped)
>
> Purl Gurl
Ah, the wonderful ICMP packet, be careful with it, for the power of the
Ping is something only the most hardy can deal with consciously.
My personal opinion is that the majority of firewalls log packets with
ports in mind to deal with UDP and TCP packets, but when an ICMP packet
is logged the port field is simply filled with a "0x0" instead of
[null]. Perhaps this is where all the confusion lies?
Its impossible to listen on port 0, or at least I found with winxp and
debian both replaced my port 0 listening attempt with a random available
port.
After some searching on the subject it mostly leads to this info.
Although Purl was correct to say that port 0 is a security risk, albeit
a low one, as malformed packets can be explicitly targetted for port 0
and depending on the operating system/firewall they are directed at a
different response is given, and you can use this response to give an
educated guess as to what the OS/Firewall is.
My experience on this subject is low, I'm just adding my 0.02 euro
One thing i noticed about this group is its very headstrung to tell
people they are wrong or show that they are smart. In technology, there
is always the possibility that some things aren't so cut and dry.
I ask that members of this group try to communicate with a little more
respect to each other since we are all professionals and there are some
pretty intelligent people here. I hope I wasn't disrespectful to anyone.
Regards,
Steve.
--
May the ping be with you ....
Registered Linux user number: 355729
Purl Gurl wrote:
(snipped)
> Yes. However, this is a very low security risk
> and pertains mostly to information gathering.
>
> You may close port 0 (zero) and test your machine.
(snipped)
>
> Purl Gurl
Ah, the wonderful ICMP packet, be careful with it, for the power of the
Ping is something only the most hardy can deal with consciously.
My personal opinion is that the majority of firewalls log packets with
ports in mind to deal with UDP and TCP packets, but when an ICMP packet
is logged the port field is simply filled with a "0x0" instead of
[null]. Perhaps this is where all the confusion lies?
Its impossible to listen on port 0, or at least I found with winxp and
debian both replaced my port 0 listening attempt with a random available
port.
After some searching on the subject it mostly leads to this info.
Although Purl was correct to say that port 0 is a security risk, albeit
a low one, as malformed packets can be explicitly targetted for port 0
and depending on the operating system/firewall they are directed at a
different response is given, and you can use this response to give an
educated guess as to what the OS/Firewall is.
My experience on this subject is low, I'm just adding my 0.02 euro
One thing i noticed about this group is its very headstrung to tell
people they are wrong or show that they are smart. In technology, there
is always the possibility that some things aren't so cut and dry.
I ask that members of this group try to communicate with a little more
respect to each other since we are all professionals and there are some
pretty intelligent people here. I hope I wasn't disrespectful to anyone.
Regards,
Steve.
--
May the ping be with you ....
Registered Linux user number: 355729
Archived from groups: comp.security.firewalls (More info?)
Stalks wrote:
> Purl Gurl wrote:
(snipped)
> > Yes. However, this is a very low security risk
> > and pertains mostly to information gathering.
> > You may close port 0 (zero) and test your machine.
> Ah, the wonderful ICMP packet, be careful with it, for the power of the
> Ping is something only the most hardy can deal with consciously.
Yes, great care needs to be taken with icmp packets, thus my
suggestion to test and note results; there may be problems.
No pings allowed here, though, so stop that!
> After some searching on the subject it mostly leads to this info.
> Although Purl was correct to say that port 0 is a security risk, albeit
> a low one, as malformed packets can be explicitly targetted for port 0
> and depending on the operating system/firewall they are directed at a
> different response is given, and you can use this response to give an
> educated guess as to what the OS/Firewall is.
Precisely. There are lots of rules, lots of defintions, but this does
not ensure those rules and definitions will be followed. Microsoft
is well known for inventing their own protocol definitions.
I suspect part of the problem on this is we, all of us, run such
complicated systems, WAN, modem, router, LAN, firewall, networking
and who knows how many different system types hooked together, we
can no longer rely on rules and definitions. Any one component can
have a mind of its own, much like a woman, as men slowly learn.
It is not my habit to guarantee any specific action will result
in specific results. We just don't know. On this topic, I would
rather suggest closing port 0, when allowed, then mess around
with icmp packet filtering and note what happens.
You may label me a rule breaker and may label all things internet
related, rule breakers as well.
I tend to cringe when people start citing definitions, rules,
http protocol, RFC "must do this" rules. Most of those rules
are rarely followed.
There is suspicion in mind now, Microsoft might be breaking
some rules on port 0, but I cannot convict them, just yet.
We have a lot of equipment sitting in front of our MS servers.
Our system does respond to Port 0 and does send ICMP packets.
> My experience on this subject is low, I'm just adding my 0.02 euro
Not only do you Europeans drive on the wrong side of the road,
you also carry funny looking coins in your pockets.
May the EURO be with you.
Purl Gurl
Stalks wrote:
> Purl Gurl wrote:
(snipped)
> > Yes. However, this is a very low security risk
> > and pertains mostly to information gathering.
> > You may close port 0 (zero) and test your machine.
> Ah, the wonderful ICMP packet, be careful with it, for the power of the
> Ping is something only the most hardy can deal with consciously.
Yes, great care needs to be taken with icmp packets, thus my
suggestion to test and note results; there may be problems.
No pings allowed here, though, so stop that!
> After some searching on the subject it mostly leads to this info.
> Although Purl was correct to say that port 0 is a security risk, albeit
> a low one, as malformed packets can be explicitly targetted for port 0
> and depending on the operating system/firewall they are directed at a
> different response is given, and you can use this response to give an
> educated guess as to what the OS/Firewall is.
Precisely. There are lots of rules, lots of defintions, but this does
not ensure those rules and definitions will be followed. Microsoft
is well known for inventing their own protocol definitions.
I suspect part of the problem on this is we, all of us, run such
complicated systems, WAN, modem, router, LAN, firewall, networking
and who knows how many different system types hooked together, we
can no longer rely on rules and definitions. Any one component can
have a mind of its own, much like a woman, as men slowly learn.
It is not my habit to guarantee any specific action will result
in specific results. We just don't know. On this topic, I would
rather suggest closing port 0, when allowed, then mess around
with icmp packet filtering and note what happens.
You may label me a rule breaker and may label all things internet
related, rule breakers as well.
I tend to cringe when people start citing definitions, rules,
http protocol, RFC "must do this" rules. Most of those rules
are rarely followed.
There is suspicion in mind now, Microsoft might be breaking
some rules on port 0, but I cannot convict them, just yet.
We have a lot of equipment sitting in front of our MS servers.
Our system does respond to Port 0 and does send ICMP packets.
> My experience on this subject is low, I'm just adding my 0.02 euro
Not only do you Europeans drive on the wrong side of the road,
you also carry funny looking coins in your pockets.
May the EURO be with you.
Purl Gurl
Archived from groups: comp.security.firewalls (More info?)
Hi,
Purl Gurl <purlgurl@purlgurl.net> wrote:
>> Port 0 and ICMP are not the same. really.
> From a security point of view, traditionally most
> icmp hack attempts are aimed at port 0 typically.
Once again: ICMP has no ports. Tehre are types. You have ports with
TCP and UDP, not with ICMP.
> I not completely familiar with the mechanics of
> this and why attempts often appear on this port.
You are not familiar with the TCP/IP protocol family.
Read Tanenbaum, Stevens, Cheswick.
> My belief is port 0 is often used or was often
> used in the past to enable usage of telnet
> programs and custom socket programs by those
> looking to "map" a server via information
> returned by selected icmp packets.
What are you talking about?
> Completely shutting down icmp transactions,
> I not sure but what this could cause some
> handshake problems; ready, not ready states.
Read Stevens. Read Cheswick.
> To deny all icmp transactions would be a
> bit of overkill and may cause more problems
> than are resolved.
Definitely.
> Which method is best, closing port 0 or shutting
> down all icmp transactions, this is a system
> specific issue and user issue.
Closing port 0 will do nothing related to icmp.
> for internet transactions because of icmp use
> being a "primitive" level initial contact for
> verifying status states for transactions.
You really don't know, what ICMP is, don't you?
Greetings,
Jens
Hi,
Purl Gurl <purlgurl@purlgurl.net> wrote:
>> Port 0 and ICMP are not the same. really.
> From a security point of view, traditionally most
> icmp hack attempts are aimed at port 0 typically.
Once again: ICMP has no ports. Tehre are types. You have ports with
TCP and UDP, not with ICMP.
> I not completely familiar with the mechanics of
> this and why attempts often appear on this port.
You are not familiar with the TCP/IP protocol family.
Read Tanenbaum, Stevens, Cheswick.
> My belief is port 0 is often used or was often
> used in the past to enable usage of telnet
> programs and custom socket programs by those
> looking to "map" a server via information
> returned by selected icmp packets.
What are you talking about?
> Completely shutting down icmp transactions,
> I not sure but what this could cause some
> handshake problems; ready, not ready states.
Read Stevens. Read Cheswick.
> To deny all icmp transactions would be a
> bit of overkill and may cause more problems
> than are resolved.
Definitely.
> Which method is best, closing port 0 or shutting
> down all icmp transactions, this is a system
> specific issue and user issue.
Closing port 0 will do nothing related to icmp.
> for internet transactions because of icmp use
> being a "primitive" level initial contact for
> verifying status states for transactions.
You really don't know, what ICMP is, don't you?
Greetings,
Jens
Archived from groups: comp.security.firewalls (More info?)
Jens Hoffmann wrote:
> Purl Gurl wrote:
(snipped)
Directing personal insults at me will not
prompt me to engage you in dialog. Quite
the opposite, I will ignore you.
I will encourage you to employ common courtesy
in your articles. Doing so will better foster
meaningful dialog.
Purl Gurl
Jens Hoffmann wrote:
> Purl Gurl wrote:
(snipped)
Directing personal insults at me will not
prompt me to engage you in dialog. Quite
the opposite, I will ignore you.
I will encourage you to employ common courtesy
in your articles. Doing so will better foster
meaningful dialog.
Purl Gurl
Archived from groups: comp.security.firewalls (More info?)
Purl Gurl wrote:
(lots snipped)
>
> Our system does respond to Port 0 and does send ICMP packets.
>
> Purl Gurl
What is your system? and do all ICMP rules apply to port 0 on this system?
--
May the ping be with you ....
Registered Linux user number: 355729
Purl Gurl wrote:
(lots snipped)
>
> Our system does respond to Port 0 and does send ICMP packets.
>
> Purl Gurl
What is your system? and do all ICMP rules apply to port 0 on this system?
--
May the ping be with you ....
Registered Linux user number: 355729
Archived from groups: comp.security.firewalls (More info?)
Stalks wrote:
> Purl Gurl wrote:
(lots snipped)
> > Our system does respond to Port 0 and does send ICMP packets.
> What is your system? and do all ICMP rules apply to port 0 on this system?
Stalks, after reading so many articles on this, here and
on the internet, I do not have a clue. Everything "assumed"
has been tossed out my window, along with the wash and baby.
Actually I was more tempted to toss my girl out a window
when she became a teenager, but she is past that although
I remain a teenager, and she is now the mother.
Stalks, just briefly, we are fed a T1 broadband connection,
an Orion modem, Linksys programmable router, three machines
on our LAN, each a highly modified WIN32 system (Not NT)
with Apache, a dns server and and an email server. Apache
is on one machine. DNS and Email on another, supporting
programs for my cgi applications, mostly databases, on
the final machine.
This week, I will be plugging in a Netscreen appliance and
linking it to SNORT. This will sit between our modem
and our router. That should really add some surprises!
Seems a fairly typical system. I am leaning towards the
Linksys router responding to port 0 requests. However,
a timestamp ICMP did make it through to our hack testing.
This suggests at least one of our machines responding
to a port 0 probe with an ICMP packet. Might be our
router stripped the port 0 reference allowing an ICMP
request to be a multicast non-port specific request.
However, one of our servers, either DNS or email, has
a port 0 security feature, don't remember which. I will
take a look later, although I think it is the DNS server.
On Linksys responding, I believe this is the origin of
the ICMP packet for a netmask. This makes sense because
our router is netmasked for a single ip address on
the T1 WAN system. Our internal LAN netmasking is
multiple addresses, and this did not show in probes.
To add confusion, each machine is netmasked for
a single ip address (255.255.255.0) which may
also be the port 0 ICMP reponse.
Hack probes for port 0 did yield ICMP packets.
Your guess is good as any, Stalks. I have been rendered
literally clueless on this.
> May the ping be with you ....
I told you to stop that!
Purl Gurl
Stalks wrote:
> Purl Gurl wrote:
(lots snipped)
> > Our system does respond to Port 0 and does send ICMP packets.
> What is your system? and do all ICMP rules apply to port 0 on this system?
Stalks, after reading so many articles on this, here and
on the internet, I do not have a clue. Everything "assumed"
has been tossed out my window, along with the wash and baby.
Actually I was more tempted to toss my girl out a window
when she became a teenager, but she is past that although
I remain a teenager, and she is now the mother.
Stalks, just briefly, we are fed a T1 broadband connection,
an Orion modem, Linksys programmable router, three machines
on our LAN, each a highly modified WIN32 system (Not NT)
with Apache, a dns server and and an email server. Apache
is on one machine. DNS and Email on another, supporting
programs for my cgi applications, mostly databases, on
the final machine.
This week, I will be plugging in a Netscreen appliance and
linking it to SNORT. This will sit between our modem
and our router. That should really add some surprises!
Seems a fairly typical system. I am leaning towards the
Linksys router responding to port 0 requests. However,
a timestamp ICMP did make it through to our hack testing.
This suggests at least one of our machines responding
to a port 0 probe with an ICMP packet. Might be our
router stripped the port 0 reference allowing an ICMP
request to be a multicast non-port specific request.
However, one of our servers, either DNS or email, has
a port 0 security feature, don't remember which. I will
take a look later, although I think it is the DNS server.
On Linksys responding, I believe this is the origin of
the ICMP packet for a netmask. This makes sense because
our router is netmasked for a single ip address on
the T1 WAN system. Our internal LAN netmasking is
multiple addresses, and this did not show in probes.
To add confusion, each machine is netmasked for
a single ip address (255.255.255.0) which may
also be the port 0 ICMP reponse.
Hack probes for port 0 did yield ICMP packets.
Your guess is good as any, Stalks. I have been rendered
literally clueless on this.
> May the ping be with you ....
I told you to stop that!
Purl Gurl
Archived from groups: comp.security.firewalls (More info?)
Purl Gurl wrote:
> Stalks wrote:
> > Purl Gurl wrote:
(lots snipped)
> > > Our system does respond to Port 0 and does send ICMP packets.
> > What is your system? and do all ICMP rules apply to port 0 on this system?
> an Orion modem
Just keyed in on that. I am going to backup a bit
and propose another concept.
Our WAN system, external to us, is an extremely large
system covering thousands of square miles. It is a
netmask type system using Cisco routers for nodes.
Additionally, actual physical routing to a specific
machine, out of millions, is done by MAC address
of a modem.
It is very possible our external port 0 probes were
actually receiving ICMP reponses from any of thousands
of CISCO routers or any of hundreds of mainframes
along the way.
Could very well have been a gateway response!
There is no way, not a reasonable way, to track down
this port 0 ICMP response with so many external devices
in the system. This could be originating from Europe
where people drive on the wrong side of the road and
carry funny looking coins in their pockets.
* frowns *
Totally befuddled now. The PING is not with me.
Purl Gurl
Purl Gurl wrote:
> Stalks wrote:
> > Purl Gurl wrote:
(lots snipped)
> > > Our system does respond to Port 0 and does send ICMP packets.
> > What is your system? and do all ICMP rules apply to port 0 on this system?
> an Orion modem
Just keyed in on that. I am going to backup a bit
and propose another concept.
Our WAN system, external to us, is an extremely large
system covering thousands of square miles. It is a
netmask type system using Cisco routers for nodes.
Additionally, actual physical routing to a specific
machine, out of millions, is done by MAC address
of a modem.
It is very possible our external port 0 probes were
actually receiving ICMP reponses from any of thousands
of CISCO routers or any of hundreds of mainframes
along the way.
Could very well have been a gateway response!
There is no way, not a reasonable way, to track down
this port 0 ICMP response with so many external devices
in the system. This could be originating from Europe
where people drive on the wrong side of the road and
carry funny looking coins in their pockets.
* frowns *
Totally befuddled now. The PING is not with me.
Purl Gurl
Archived from groups: comp.security.firewalls (More info?)
"Purl Gurl" <purlgurl@purlgurl.net> wrote in message ...
(snipped)
>
> Our system does respond to Port 0 and does send ICMP packets.
>
Just for fun I tested it on our XP systems, on a Linksys router
& on a CATALYST switch, they all answer with a TCP
RST packet :
mducharme@max ~
$ nmap -sS -P0 -p0 --packet_trace 10.1.1.2
WARNING: Scanning "port 0" is supported, but unusual.
Starting nmap 3.48 ( http://www.insecure.org/nmap ) at 2004-05-20 12:00
Eastern Daylight Time
SENT (4.6770s) TCP 10.1.1.1:59338 > 10.1.1.2:0 S ttl=43 id=64558 iplen=40
seq=1438141545 win=4096
RCVD (4.6870s) TCP 10.1.1.2:0 > 10.1.1.1:59338 RA ttl=64 id=15498 iplen=40
seq=0 win=0 ack=0
Interesting ports on 10.1.1.2:
PORT STATE SERVICE
0/tcp closed unknown
Nmap run completed -- 1 IP address (1 host up) scanned in 4.737 seconds
Only our linux servers which have a DROP configuration in iptables do not
answer.
Bye
Maxime Ducharme
Programmeur / Spécialiste en sécurité réseau
"Purl Gurl" <purlgurl@purlgurl.net> wrote in message ...
(snipped)
>
> Our system does respond to Port 0 and does send ICMP packets.
>
Just for fun I tested it on our XP systems, on a Linksys router
& on a CATALYST switch, they all answer with a TCP
RST packet :
mducharme@max ~
$ nmap -sS -P0 -p0 --packet_trace 10.1.1.2
WARNING: Scanning "port 0" is supported, but unusual.
Starting nmap 3.48 ( http://www.insecure.org/nmap ) at 2004-05-20 12:00
Eastern Daylight Time
SENT (4.6770s) TCP 10.1.1.1:59338 > 10.1.1.2:0 S ttl=43 id=64558 iplen=40
seq=1438141545 win=4096
RCVD (4.6870s) TCP 10.1.1.2:0 > 10.1.1.1:59338 RA ttl=64 id=15498 iplen=40
seq=0 win=0 ack=0
Interesting ports on 10.1.1.2:
PORT STATE SERVICE
0/tcp closed unknown
Nmap run completed -- 1 IP address (1 host up) scanned in 4.737 seconds
Only our linux servers which have a DROP configuration in iptables do not
answer.
Bye
Maxime Ducharme
Programmeur / Spécialiste en sécurité réseau
Archived from groups: comp.security.firewalls (More info?)
Maxime Ducharme wrote:
> Purl Gurl wrote:
(snipped)
> > Our system does respond to Port 0 and does send ICMP packets.
> Just for fun I tested it on our XP systems, on a Linksys router
> & on a CATALYST switch, they all answer with a TCP
> RST packet :
> WARNING: Scanning "port 0" is supported, but unusual.
Unusual indeed! Maxime, have you tried external probes
to determine what responses are garnered?
Our probes originated from a server on the outside, not
even on our geographic WAN system.
Do you think there may be differences in response
between internal probes, such as you did, and
external probes?
First rule of good Scientific Method is to standardize
all controls. Inherently, this is not possible with
internet usage!
Purl Gurl
Maxime Ducharme wrote:
> Purl Gurl wrote:
(snipped)
> > Our system does respond to Port 0 and does send ICMP packets.
> Just for fun I tested it on our XP systems, on a Linksys router
> & on a CATALYST switch, they all answer with a TCP
> RST packet :
> WARNING: Scanning "port 0" is supported, but unusual.
Unusual indeed! Maxime, have you tried external probes
to determine what responses are garnered?
Our probes originated from a server on the outside, not
even on our geographic WAN system.
Do you think there may be differences in response
between internal probes, such as you did, and
external probes?
First rule of good Scientific Method is to standardize
all controls. Inherently, this is not possible with
internet usage!
Purl Gurl
Archived from groups: comp.security.firewalls (More info?)
Purl Gurl wrote:
> Maxime Ducharme wrote:
> > Purl Gurl wrote:
(snipped)
> > > Our system does respond to Port 0 and does send ICMP packets.
> > Just for fun I tested it on our XP systems, on a Linksys router
> > & on a CATALYST switch, they all answer with a TCP
> > RST packet :
> > WARNING: Scanning "port 0" is supported, but unusual.
> Do you think there may be differences in response
> between internal probes, such as you did, and
> external probes?
Another difference is our external probes were
deliberately crafted "hack" probes, not system
functions. This is another variable to consider.
Our extensive external testing employed very well
crafted hacks designed to fool our system in as
many ways as possible. Nearly five-thousand tests
in total. Stepping outside the expected, breaking
the rules, not obeying definitions, otherwords
deliberately black hat hacking, might be the
true source of difference here.
Purl Gurl
Purl Gurl wrote:
> Maxime Ducharme wrote:
> > Purl Gurl wrote:
(snipped)
> > > Our system does respond to Port 0 and does send ICMP packets.
> > Just for fun I tested it on our XP systems, on a Linksys router
> > & on a CATALYST switch, they all answer with a TCP
> > RST packet :
> > WARNING: Scanning "port 0" is supported, but unusual.
> Do you think there may be differences in response
> between internal probes, such as you did, and
> external probes?
Another difference is our external probes were
deliberately crafted "hack" probes, not system
functions. This is another variable to consider.
Our extensive external testing employed very well
crafted hacks designed to fool our system in as
many ways as possible. Nearly five-thousand tests
in total. Stepping outside the expected, breaking
the rules, not obeying definitions, otherwords
deliberately black hat hacking, might be the
true source of difference here.
Purl Gurl
Archived from groups: comp.security.firewalls (More info?)
Hi,
Purl Gurl <purlgurl@purlgurl.net> wrote:
> A variety of research sources will provide a
> much better generalized notion, and clarity.
With engineering it's a lot simpler:
Read the definitions.
> You will note in my articles I make a distinction
> between port zero and icmp packets.
That was not apparent.
> You will also
> discover I indicate historical hacks for icmp data
> arrive through port 0 which is well documented.
No icmp data will ever arrive through port 0.
> Unfortunately, none of us are experts are each and
> every system type out there.
Yepp. you seem to be a good programmer, but you are not
a network specialist.
> Readers will benefit by engaging in a detailed
> highly technical study of this, but expect to
> encounter some lack of clarity; there are many
> valid points of view on this.
Ehm. No. There aren't. There are, however, a lot of
people selling snake oil.
I once again suggest, that you read the definition
of the terms you are using.
If you don't trust my choice of authors, try some
source code for IP-stacks.
Greetings,
Jens
Hi,
Purl Gurl <purlgurl@purlgurl.net> wrote:
> A variety of research sources will provide a
> much better generalized notion, and clarity.
With engineering it's a lot simpler:
Read the definitions.
> You will note in my articles I make a distinction
> between port zero and icmp packets.
That was not apparent.
> You will also
> discover I indicate historical hacks for icmp data
> arrive through port 0 which is well documented.
No icmp data will ever arrive through port 0.
> Unfortunately, none of us are experts are each and
> every system type out there.
Yepp. you seem to be a good programmer, but you are not
a network specialist.
> Readers will benefit by engaging in a detailed
> highly technical study of this, but expect to
> encounter some lack of clarity; there are many
> valid points of view on this.
Ehm. No. There aren't. There are, however, a lot of
people selling snake oil.
I once again suggest, that you read the definition
of the terms you are using.
If you don't trust my choice of authors, try some
source code for IP-stacks.
Greetings,
Jens
Archived from groups: comp.security.firewalls (More info?)
Jens Hoffmann wrote:
> Purl Gurl wrote:
(snipped)
> > A variety of research sources will provide a
> > much better generalized notion, and clarity.
> With engineering it's a lot simpler:
Which is way many engineered buildings, bridges
and other structures, collapse.
Setting rules and definitions is beneficial.
However, I would invite you to compare RFC
http protocols to Microsoft Internet Explorer.
Once you have learned MSIE does not follow
any http protocols, then have a look at various
operating systems. You will learn rules are
dismissed, outright ignored, most often by
Microsoft who maintains their own rules.
I clearly state this in my previous articles.
We can make a rule you will stop at all stop signs.
Here in California, we do not stop, despite the law.
You have suggested reading definitions. I will suggest you
read my articles for comprehension. Your responses lead a
reader to believe I wrote something, which I did not. Your
responses also indicate you do not understand my writings
or are deliberately ignoring what I wrote.
Personally, I am annoyed by nit-pickers. Any can do this
and usually they are wrong and remain nit infested.
Nothing is standardized related to the internet and it
is my advice readers should seek out a lot of information
to become informed, rather than rely on stated rules,
which are rarely followed.
Be sure hackers do not follow the rules and exploits
come through in the most surprising ways.
Purl Gurl
Here are some results from a professional security survey.
All of these comments are associated with port 0 hacks and
in their documentation, port 0 is specifically listed.
These are three results out of nearly five-thousand tests
for security vulnerabilities.
ICMP PORT 0
The remote host answered to an ICMP_MASKREQ query and sent us
its netmask (255.255.255.0). An attacker can use this information
to understand how your network is set up and how the routing is done.
This may help him bypass your filters.
Solution: Reconfigure the remote host so that it does not answer
to those requests. Set up filters that deny ICMP packets of type 17.
Risk Factor: Low CVE:CAN-1999-0524
ICMP PORT 0
The remote host answers to an ICMP timestamp request. This allows
an attacker to know the date which is set on your machine. This may
help him to defeat all your time based authentication protocols.
Solution: Filter out the ICMP timestamp requests (13), and the
outgoing ICMP timestamp replies (14).
Risk Factor: Low CVE:CAN-1999-0524
TCP PORT 0
The remote host does not discard TCP SYN packets which have the
FIN flag set. Depending on the kind of firewall you are using,
an attacker may use this flaw to bypass its rules. See also:
http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html
http://www.kb.cert.org/vuls/id/464113
Solution: Contact your vendor for a patch.
Risk Factor: Low BID:7487
Jens Hoffmann wrote:
> Purl Gurl wrote:
(snipped)
> > A variety of research sources will provide a
> > much better generalized notion, and clarity.
> With engineering it's a lot simpler:
Which is way many engineered buildings, bridges
and other structures, collapse.
Setting rules and definitions is beneficial.
However, I would invite you to compare RFC
http protocols to Microsoft Internet Explorer.
Once you have learned MSIE does not follow
any http protocols, then have a look at various
operating systems. You will learn rules are
dismissed, outright ignored, most often by
Microsoft who maintains their own rules.
I clearly state this in my previous articles.
We can make a rule you will stop at all stop signs.
Here in California, we do not stop, despite the law.
You have suggested reading definitions. I will suggest you
read my articles for comprehension. Your responses lead a
reader to believe I wrote something, which I did not. Your
responses also indicate you do not understand my writings
or are deliberately ignoring what I wrote.
Personally, I am annoyed by nit-pickers. Any can do this
and usually they are wrong and remain nit infested.
Nothing is standardized related to the internet and it
is my advice readers should seek out a lot of information
to become informed, rather than rely on stated rules,
which are rarely followed.
Be sure hackers do not follow the rules and exploits
come through in the most surprising ways.
Purl Gurl
Here are some results from a professional security survey.
All of these comments are associated with port 0 hacks and
in their documentation, port 0 is specifically listed.
These are three results out of nearly five-thousand tests
for security vulnerabilities.
ICMP PORT 0
The remote host answered to an ICMP_MASKREQ query and sent us
its netmask (255.255.255.0). An attacker can use this information
to understand how your network is set up and how the routing is done.
This may help him bypass your filters.
Solution: Reconfigure the remote host so that it does not answer
to those requests. Set up filters that deny ICMP packets of type 17.
Risk Factor: Low CVE:CAN-1999-0524
ICMP PORT 0
The remote host answers to an ICMP timestamp request. This allows
an attacker to know the date which is set on your machine. This may
help him to defeat all your time based authentication protocols.
Solution: Filter out the ICMP timestamp requests (13), and the
outgoing ICMP timestamp replies (14).
Risk Factor: Low CVE:CAN-1999-0524
TCP PORT 0
The remote host does not discard TCP SYN packets which have the
FIN flag set. Depending on the kind of firewall you are using,
an attacker may use this flaw to bypass its rules. See also:
http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html
http://www.kb.cert.org/vuls/id/464113
Solution: Contact your vendor for a patch.
Risk Factor: Low BID:7487
Archived from groups: comp.security.firewalls (More info?)
"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
(snipped)
>
> Do you think there may be differences in response
> between internal probes, such as you did, and
> external probes?
>
depends on devices configuration
the devices i tested were both on internal & external
Have a nice day
Maxime
"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
(snipped)
>
> Do you think there may be differences in response
> between internal probes, such as you did, and
> external probes?
>
depends on devices configuration
the devices i tested were both on internal & external
Have a nice day
Maxime
Archived from groups: comp.security.firewalls (More info?)
Hi,
Maxime Ducharme <mducharme@cybergeneration.com> wrote:
> Hope this help again
Excellent, nitpicking and perfectly correct.
Greetings,
Jens
Hi,
Maxime Ducharme <mducharme@cybergeneration.com> wrote:
> Hope this help again
Excellent, nitpicking and perfectly correct.
Greetings,
Jens
Archived from groups: comp.security.firewalls (More info?)
"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
(snipped)
>
> Another difference is our external probes were
> deliberately crafted "hack" probes, not system
> functions. This is another variable to consider.
>
> Our extensive external testing employed very well
> crafted hacks designed to fool our system in as
> many ways as possible. Nearly five-thousand tests
> in total. Stepping outside the expected, breaking
> the rules, not obeying definitions, otherwords
> deliberately black hat hacking, might be the
> true source of difference here.
>
>
> Purl Gurl
this is cool but not very precise
can you explain us some "special" techniques used ?
later
Maxime
"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
(snipped)
>
> Another difference is our external probes were
> deliberately crafted "hack" probes, not system
> functions. This is another variable to consider.
>
> Our extensive external testing employed very well
> crafted hacks designed to fool our system in as
> many ways as possible. Nearly five-thousand tests
> in total. Stepping outside the expected, breaking
> the rules, not obeying definitions, otherwords
> deliberately black hat hacking, might be the
> true source of difference here.
>
>
> Purl Gurl
this is cool but not very precise
can you explain us some "special" techniques used ?
later
Maxime
TRENDING THREADS
-
News Windows 11 will reportedly display a watermark if your PC does not support AI requirements- Started by Admin
- Replies: 22
-
-
Discussion What's your favourite video game you've been playing?- Started by amdfangirl
- Replies: 3K
-
Facebook
Twitter
Instagram