Building network automation solutions

9 module online course

Start now!

Category: web

Netflix summary

Many thanks to those of you that responded with Netflix details (special thanks to Volcker for sending me the packet capture). Immediately after someone mentioned firewalls, I knew what the most sensible answer should be: to get across almost anything, use HTTP. No surprise, Netflix chose to use it. However, they’ve managed to deploy streaming video over TCP, which is not a trivial task. So, how did they do it?

read more see 2 comments

IOS HTTP vulnerability

The Cisco Subnet RSS feed I’m receiving from Network World contained interesting information a few days ago: Cisco has reissued the HTTP security advisory from 2005. The 2005 bug was “trivial”: they forgot to quote the “<” character in the output HTML stream as “&lt;” and you could thus insert HTML code into the router’s output by sending pings to the router and inspecting the buffers with show buffers assigned dump (I found the original proof-of-concept exploit on the Wayback Machine). However, I’ve checked the behavior on 12.4(15)T1 and all dangerous characters (“<” and quotes) were properly quoted. So, I’m left with two explanations.

read more see 1 comments

Local Content Filtering in Cisco IOS

Cisco IOS release 12.4(20)T introduced (web) content filtering. The feature is aimed primarily at the ISR routers which can connect to an external service hosted by Trend Micro, turning the mundane administrative task of blacklisting web sites into a subscription service.

You can use the same features without the Trend Micro service whenever you need a quick fix (for example, blocking a few web sites). The Local content filtering is also available on other platforms, not just on ISRs. Not surprisingly, the online IOS documentation on the local part of this feature is a bit sketchy, but you’ll find all the details you need to configure this feature in the Local Content Filtering article.

Read the full article in the CT3 wiki

.
see 2 comments

HTTP PUT is broken in IOS release 12.4(15)T

Isaac was trying to implement the HTTP PUT solution I’ve described in the IP Corner article Using a Web Server to Manage Your Router Configurations. He couldn’t get IIS or Apache to work and finally discovered that he was facing an IOS problem. When he’s upgraded the routers to IOS release 12.4(20)T or 12.4(22)T, the copy running-config http://host/path command worked as expected.

Isaac, thanks for the feedback!

add comment

Hyperlinked RFCs

If you're too young to remember the days of IBM mainframes, punched cards and 132-column printouts, you could get a feeling for what we had to cope with by looking at the original RFC texts. Even the latest RFCs are published in text-only fixed-font format with no extra formatting, making it a nightmare to quote a section of the RFC in a post or an article (not to mention the very real danger of falling asleep just by looking at an RFC).

A variety of third-party web sites have tried to fill the gap by providing RFCs in hyperlinked or PDF format. I've tried a few of them and usually got turned away by inconsistent or broken links.

Finally, IETF recognized that we live in the third millenium and started offering IETF documents (including RFCs) with HTML markup. To get hyperlinked versions of the RFCs, go to IETF tools web site and enter RFC number or use Google to search the IETF repository.
see 1 comments

You fix some, you break some ...

When Cisco fixed the tclsh bug in IOS release 12.4, they managed to break another nice feature: you can no longer execute tcl scripts within HTTP server on Cisco IOS. Previously you could use tcl scripts to generate customized outputs or reports that could be viewed through a web browser or even generate parts of HTML code that could be included in web pages served from the router. It's all gone in 12.4(15)T1 ...
add comment

Unicode IPS vulnerability: more details

Cisco has released security response acknowledging that the IPS software does not properly handle a rarely used Unicode encoding. Reading the security notice you might be left wondering what's going on. Here's the whole story.

Within an URI (web address), the ASCII characters can be encoded in one of three ways:
  • Unless they are reserved, they can be included in the URI directly (for example, you can always use the letter a in an URI).
  • You can always escape a character using its hexadecimal value. Letter a can thus be written as %61.
  • Unicode character set includes full-width form of ASCII characters, where letter a can be encoded as a two-byte value 0xFF61 (or %ff%61 in an URI)
The IPS software (standalone or integrated in Cisco IOS) does not recognize the sequence %ff%61 as letter a. It's thus possible to evade some IPS triggers by replacing ASCII characters with their full-width Unicode encoding.

The vulnerability by itself does not open new attack routes, unless you use the IPS as the only means of protection of a vulnerable system (which is a bad practice anyway).
add comment

Cisco IOS web server with no enable password

IOS has (yet another) nice "underdocumented" feature - if you don't have an enable password/secret configured on your router, you can access IOS HTTP(S) server (assuming it's enabled with the ip http server command) without any authentication whatsoever. Of course you'd never do that in a production environment, but it's nice to know you can always configure the router from a web browser if needed (see also the discussion on default passwords with Cisco SDM).
add comment

Cisco IOS violates RFC 2616 (HTTP/1.1)

Update 2012-08-27: Stefan de Kooter reported the bug had been fixed in IOS release 15.1(4)M.

I simply had to check with the RFC; by setting the Host: field of HTTP request to an IP address (instead of a host name), Cisco IOS violates section 14.23 of RFC 2616, which says:

The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource ... The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL.
add comment

IOS HTTP client sets Host: field to IP address

Update 2012-08-27: Stefan de Kooter reported the bug had been fixed in IOS release 15.1(4)M.

If you run multiple web sites on a single physical server, it's highly likely that you rely on the ability of HTTP/1.1 clients to specify the Host: field in the HTTP request to indicate which web site they're trying to access.

Cisco IOS always inserts the web server's IP address (not the hostname) in the Host: field of the HTTP request, regardless of whether you enter IP address or hostname in the URL part of an IOS command that supports HTTP (for example, copy or more command) ... and regardless of whether the hostname is locally configured with the ip host command or resolved by an external DNS server specified in the ip name-server command.

End result: Cisco IOS-based routers (tested up to release 12.4(11)T) can access only the default web site on a web server hosting multiple web sites.

add comment

Home page for Cisco IOS web server

Another un(der)documented fact: when you access the router's home page (assuming HTTP or HTTPS server has been enabled), the router displays:
  1. The home.html file if it exists in any filesystem;
  2. The home.shtml file if it exists in any filesystem;
  3. a default page with links to exec, SDM, QDM and TAC support

Note: even though you can access home.html file on flash: device directly, that web page cannot reference any other file in flash: as a relative link unless you specify flash: as the default path for the HTTP requests with the ip http path flash: command.

see 2 comments

Cisco IOS Web Server

These tips will help you get the most out of the Cisco IOS embedded web server:

These ones explain how to use IOS HTTP server and client to manage your router configuration and execute commands on the router:

add comment
Sidebar