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 (at) shaka (dot) com [email concealed]> 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 (at) gmail (dot) com [email concealed]>
> To: "Mark Owen" <mr.markowen (at) gmail (dot) com [email concealed]>
> Cc: "Ansgar -59cobalt- Wiechers" <bugtraq (at) planetcobalt (dot) net [email concealed]>; <security-basics (at) securityfocus (dot) com [email concealed]>
> 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 (at) gmail (dot) com [email concealed]> wrote:
> >> On Thu, Mar 27, 2008 at 12:25 PM, Jason <securitux (at) gmail (dot) com [email concealed]> 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
> >>
>

[ reply ]