RE: Removing ping/icmp from a network

["Adewale, Akin (IT Services - Infosec Team)" <Akin.Adewale () capita co uk>]

The 10.XXX range is reserved, so that is an Internal Microsoft IP for
one of their devices. 

Usually, for security against Spoofing, it is better to make sure this
can not be seen outside your network.

Akin Adewale


-----Original Message-----
From: listbounce () securityfocus com [mailto:listbounce () securityfocus com]
On Behalf Of Razi Shaban
Sent: 27 March 2008 23:49
To: Michael Painter
Cc: security-basics () securityfocus com
Subject: Re: Removing ping/icmp from a network

IP Whois Information for 10.22.0.26

OrgName:    Internet Assigned Numbers Authority
OrgID:      IANA
Address:    4676 Admiralty Way, Suite 330
City:       Marina del Rey
StateProv:  CA
PostalCode: 90292-6695
Country:    US

NetRange:   10.0.0.0 - 10.255.255.255
CIDR:       10.0.0.0/8
NetName:    RESERVED-10
NetHandle:  NET-10-0-0-0-1
Parent:
NetType:    IANA Special Use
NameServer: BLACKHOLE-1.IANA.ORG
NameServer: BLACKHOLE-2.IANA.ORG
Comment:    This block is reserved for special purposes.
Comment:    Please see RFC 1918 for additional information:
Comment:    http://www.arin.net/reference/rfc/rfc1918.txt
RegDate:
Updated:    2007-11-27

Clean, I guess.

--
Razi


On 3/27/08, Michael Painter <tvhawaii () shaka com> wrote:
> Tracing route to microsoft.com [207.46.197.32]
>  over a maximum of 30 hops:
>   1     8 ms     8 ms     9 ms  flexnet-adsl-customers [206.126.0.5]
>   2     8 ms     8 ms     8 ms  shhh.our.upstream [66.135.224.201]
>   3     8 ms     8 ms     7 ms  216.236.111.17
>   4    10 ms     9 ms     8 ms  hnl-edge-01.inet.qwest.net
[67.129.94.1]
>   5    61 ms    62 ms    62 ms  bur-edge-03.inet.qwest.net
[205.171.13.169]
>   6    61 ms    62 ms    62 ms  bur-core-02.inet.qwest.net
[205.171.13.89]
>   7    82 ms    85 ms    84 ms  sea-core-01.inet.qwest.net
[67.14.1.186]
>   8    84 ms    83 ms   101 ms  sea-edge-03.inet.qwest.net
[205.171.26.38]
>   9    83 ms    83 ms    81 ms  63.237.224.30
>   10    91 ms    85 ms    83 ms  ge-1-3-0-57.wst-64cb-1b.ntwk.msn.net
[207.46.36.249]
>   11    83 ms    81 ms    81 ms  ge-0-0-0-0.wst-64cb-1a.ntwk.msn.net
[207.46.34.45]
>   12    83 ms    82 ms    81 ms  ge-7-1-0-0.cpk-64c-1b.ntwk.msn.net
[207.46.35.41]
>   13    81 ms    84 ms    84 ms  ten3-4.cpk-76c-1a.ntwk.msn.net
[207.46.34.38]
>   14    87 ms    85 ms    82 ms  10.22.0.26
>   15     *        *        *     Request timed out.
>   16     *        ^C
>
>  Hmm...10.22.0.26?
>
>
>
>      ----- Original Message -----
>  From: "Jason" <securitux () gmail com>
>  To: "Mark Owen" <mr.markowen () gmail com>
>  Cc: "Ansgar -59cobalt- Wiechers" <bugtraq () planetcobalt net>;
<security-basics () securityfocus com>
>  Sent: Thursday, March 27, 2008 8:52 AM
>  Subject: Re: Removing ping/icmp from a network
>
>
>  > ICMP is allowed throughout most Internet routers, if you can trace
all
>  > the way to the hop before the firewall, then you have narrowed down
>  > where the issue is.
>  >
>  > From there, what about network analysis and application monitoring
>  > tools? What about tcpdump, ethereal, etc? Can that not be used that
to
>  > check network and server latency / response times on a standard web
>  > request?
>  >
>  > We have a customer in Australia who's ISP blocks all ICMP to and
from
>  > their CPE routers. We seem to get along just fine. Web site is down
or
>  > is slow and the router before the CPE is responding, dump the
packets,
>  > look at the timestamps and see what's going on. IP packet traces
spit
>  > back latency just fine with or without ICMP. Problem inside the
CPE?
>  > Use remote management tools over a VPN to troubleshoot further (if
you
>  > manage the server of course).
>  >
>  > Reputation is not going to change based on whether ICMP is allowed
or
>  > not... if the web site is down its down, clients aren't going to
care
>  > if they can ping it or not if they can't access their data through
SSL
>  > or whichever protocol either way. "Well I can't do my job, but this
is
>  > a stable server because I can ping it".
>  >
>  > Plus, if you absolutely must have ICMP to troubleshoot from the
>  > Internet, firewall rules can be used to narrow the source and
>  > destination as someone else in this thread suggested. I may have
given
>  > too much of a blanket statement when saying no ICMP from the
Internet
>  > at all, I should have said no open ICMP. Controlled ICMP through a
>  > firewall with proper rules should be good.
>  >
>  > I don't consider MS's site unreliable just because I, or anyone on
the
>  > Internet for that matter, can't ping it.
>  >
>  > -J
>  >
>  > On Thu, Mar 27, 2008 at 1:09 PM, Mark Owen <mr.markowen () gmail com>
wrote:
>  >> On Thu, Mar 27, 2008 at 12:25 PM, Jason <securitux () gmail com>
wrote:
>  >>  *snip*
>  >>  >  The idea is to limit your Internet footprint to make it as
difficult
>  >>  >  as possible for an attacker. There is no need for a web server
to
>  >>  >  respond to ping from the Internet for example.
>  >>
>  >>  It is very critical that your web server responds to ICMP on the
>  >>  Internet.  If you go out of the way and ignore essential
protocols for
>  >>  IP over a public network, you're just going to create a headache
for
>  >>  all of us.
>  >>
>  >>  Without ICMP, it is very difficult for us to determine where a
problem
>  >>  exists when our clients complain about slow load times or
>  >>  inaccessibility to your website.  No ICMP means no basic trace
>  >>  routing, no basic latency checks, and no basic error reporting.
So
>  >>  even if the problem is somewhere in our infrastructure that
limits or
>  >>  prevents access to your site, you're going to get the blame and
bad
>  >>  reputation of an unstable server.  If it doesn't respond to ping,
and
>  >>  can't be traced, its not our fault that our client can't access
your
>  >>  site, it's yours.
>  >>
>  >>  --
>  >>  Mark Owen
>  >>

This email has been scanned for all viruses by the MessageLabs SkyScan
service.

This email and any files transmitted with it are confidential, and may be subject to legal privilege, and are intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error or think you may have done so, you may not peruse, use, disseminate, 
distribute or copy this message. Please notify the sender immediately and delete the original e-mail from your system.