Cisco website www.cisco.com 403 forbidden?

Is it just me that they don't like?

Nah, they hate me too. :slight_smile:

Behalf Of Jay Hennigan
Sent: March 15, 2004 3:19 PM

Is it just me that they don't like?

Apparently they don't like me either. On top of that, they're running
Apache 1.0--not so good.

Todd

me too

Arnold

Jay Hennigan wrote:

Is it just me that they don't like?

I've seen one or two other reports.

Seems like a good opportunity for a round of Wild Speculation.

Nope, they got me too.

I can access it from Canada, but it seems that the first page is missing
some info which are typically there.

Priyantha
Wightman Internet

Anyone going to open a TAC case ?

** Reply to message from "Todd Mitchell - lists" <lists@ciphin.com> on
Mon, 15 Mar 2004 15:23:14 -0500

> Behalf Of Jay Hennigan
> Sent: March 15, 2004 3:19 PM
>
> Is it just me that they don't like?

Apparently they don't like me either. On top of that, they're running
Apache 1.0--not so good.

Todd

--

As of 12:40 Pacific whatever time, it's working for me. Metadata says
the updated the page March 12th.

Behalf Of Jay Hennigan
Sent: March 15, 2004 3:19 PM

Is it just me that they don't like?

All fixed now, but load times are hella slow:

phoenix:~# curl -I cisco.com
HTTP/1.1 200 OK
Server: Apache/1.0 (Unix)
Set-Cookie: CP_GUTC=209.123.169.252.240801079383253714; path=/; expires=Fri,
09-Mar-29 20:40:53 GMT; domain=.cisco.com
Connection: close
Content-Type: text/html

Todd

"Cisco is under spam attack"
"Cisco has closed their website because Vendor J made fun of it"
"Cisco just lost all of their data! Call DataSafe!"
"An intern unplugged the website"
"Cisco decided to use SPEWS to control access to their website"

Probably a million other people just discovered it was back up as well.

I know alot of users that will just sit there, hitting refresh over and
over again until the site finally comes up, instead of just going to do
something else and coming back later.

Then, when it finally comes back up, you have a million users who are
hitting refresh over and over again because the site is slow, creating
even more load, and you get the picture. :slight_smile:

no issues here..loads quickly.

Todd Mitchell - lists wrote:

Good god, is there really so little interesting shit on the Internet that
we are reduced to 20 post long threads me too-ing a 30 minute outage of a
website which is now fixed?

The god damn packet kiddies were more interesting than this crap. Enough
already!

Its obviously the Monsters on Maple street. *

* http://www.tvtome.com/TwilightZone/season1.html#ep22

Oh no! Wait, we are the ... Arrrrhhhgggg!!!

         ---Mike

Can anyone point me at any papers that talk about security issues raised by
private networks passing dns requests for RFC 1918 private address space out
to their ISP's dns servers?

I'm aware of the issues involved with an ISP passing the requests on to the
root servers but was looking specifically for security type issues relating
to a private network passing the requests out to their ISP's dns servers.

Geo.

Hint: Every such DNS request that escapes will either time out or get an
error. The admin is unwilling or unable to fix the resulting breakage.
The fact that it isn't being fixed should tell you a lot about the site....

Geo. wrote:

Can anyone point me at any papers that talk about security issues raised by
private networks passing dns requests for RFC 1918 private address space out
to their ISP's dns servers?

I've never seen the whole paper on the topic. Leaking the fact that
you use 10.10.10.0/24 or whatever internally is not a big deal. It's
security by obscurity of the very weak kind. Anyone with half of a clue
will drop traffic with a source or destination address of their internal
RFC1918 networks at the border, (and even if one uses registered
addresses internally, you would be dropping traffic with a souce address
of the internal network from entering at the border). That's the "real"
security.

I'm aware of the issues involved with an ISP passing the requests on to the
root servers but was looking specifically for security type issues relating
to a private network passing the requests out to their ISP's dns servers.

These requests will not go to the root servers any more than any other
reverse lookups ISP's DNS,

   $ dig -x 10 ns
   ; <<>> DiG 8.3 <<>> -x ns
   ;; res options: init recurs defnam dnsrch
   ;; got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
   ;; QUERY SECTION:
   ;; 10.in-addr.arpa, type = NS, class = IN

   ;; ANSWER SECTION:
   10.in-addr.arpa. 1W IN NS blackhole-1.iana.org.
   10.in-addr.arpa. 1W IN NS blackhole-2.iana.org.

   ;; ADDITIONAL SECTION:
   blackhole-1.iana.org. 16m43s IN A 192.175.48.6
   blackhole-2.iana.org. 16m43s IN A 192.175.48.42

   ;; Total query time: 53 msec
   ;; FROM: sec-tools.corp.globalstar.com to SERVER: default -- 207.88.152.10
   ;; WHEN: Tue Mar 16 09:53:44 2004

The IN-ADDR.ARPA delegations for RFC1918 space are just like any
other block. You'll just end up hitting IANA's blackhole servers,
and not all that much, the cache times are one week.

Of course, the obvious "fix" is to run your own internal DNS which
is authorative for your RFC1918 addresses.

The IN-ADDR.ARPA delegations for RFC1918 space are just like any
other block. You'll just end up hitting IANA's blackhole servers,
and not all that much, the cache times are one week.

Also, those blackhole servers are anycast, so they might even be answered relatively locally. See <http://www.as112.net/>.

Of course, the obvious "fix" is to run your own internal DNS which
is authorative for your RFC1918 addresses.

Joe

RFC1918