NOW: Web Site security principles WAS Re: was BabyCam WAS hacking

["Mark Harrison" <Mark.Harrison@xxxxxxx>]

> Out of interest how do these people manage to hack
> system on a private ip range as the router is
> peforming NAT ?

Hacking for Dummies, by Mark Harrison ;-)

Let me preface this by saying that I write from the perspective of
defending large corporate sites who not only get the "script
puppy"
attacks, but also directed attacks aimed at compromising us
specifically. You may be interested to know that we no longer bother
logging "intrusion attempt detection" on our bigger sites, since
we
typically get several thousand hack attempts per hour. We therefore only
log the ones that show some level of sophistication.

The three basic principles of web site protection are "defence in
depth", "only let through what you need" and "keep it
patched".

A typical site looks as follows:

(Internet) - Firewall A - Load Balancer - Web servers - Firewall B -
Application Servers - Firewall C - Database Servers - Firewall D -
Corporate mainframes

For a start, and for reasons of resilience rather than of security,
every piece identified as a server or a firewall, starting with the
connection to the Internet, and up to and including Firewall C tends to
be a cluster of boxes rather than a single one.

You assume that any given piece of your security may be compromised
(because new vulnerabilities are discovered all the time.)

Let's imagine, say, that a hacker wants to do something nasty to your
site. Assuming that the site is well set up, , in order to do anything
other than access an HTTP server running on "Web servers", he
needs to
do one of two things:

1: Take advantage of a problem in the HTTP server to make it do
something odd
2: Compromise firewall A and persuade it to let you access a
non-standard port

To prevent 1:, you make sure you apply all the security patches to your
HTTP server.
To prevent 2:, you make sure you apply all the security patches to your
Firewall server AND harden the operating system on your web server to
remove things like Telnet access (literally by removing the telnet
executables from the O/S - you leave in, say SSH for authenticated
remote access, and console access for "emergency" local access.)

The "2" case also answers the question "how does it route to
a 10.
address" - you have to assume that once you compromise a firewall, you
can persuade it to do stuff like that.

Now, and this is important, Only the Web Servers can issue requests
(through CGIs, Servlets or whatever) to the Application Servers. No
Browser ever connects to anything other than a webhead.

Doing these things foxes 99.9% of attacks. Unfortunately, these attacks
are from people without that much ingenuity. Hence, you also have to
assume that there are people out there who will simultaneously become
aware of a new vulnerability in both your Firewall _and_ your web
server's O/S. If this happens, you just assume that they trash your web
heads, so the site becomes unusable.

However, you then have a plan to stop them doing anything REALLY nasty
(like - wander through to your database server and steal all your
customers' information, let alone wander into your corporate mainframe!)

The plan here is to use Firewall B. Firewall B sits behind the web
servers tier and moderates their communication to the Application
Servers. Firewall B is, in the best practice model, a completely
different TYPE of firewall to Firewall A - that way the hacker can't
exploit the same vulnerability twice! Ie - if Firewall A is a (pair of)
Nokia machine(s) running Checkpoint Firewall-1, then Firewall B will be
a pair of Cisco PIXes.

In addition, you don't store any data in your application servers - they
just run the business logic, but write the state information either back
into your database server or forward into a cookie on your client's PC.
In practice these days, the only information you write forward is a
cookie that identifies the session ID for the transaction currently in
progress unless the customer has agreed to have a persistent cookie for
authenticating them "next time" to your personalisation logic.

If things get REALLY bad, your hacker compromises: Firewall A, Web
Server, Firewall B, Application Server - you then have Firewall C -
ideally another type yet again, to protect your data.

The two monkeys:

If your security requirements are lower, then you might make Firewall A
and Firewall B the same. If so, you tend to (for cost reasons) implement
the web servers and application servers tiers as Demilitarised Zones off
the same firewall.

If you're at home, and you have a firewall, you probably don't bother
hardening the O/S of your internal PCs anyway. (Except for maybe turning
off Microsoft file sharing.)



Phew... glad I got that out :-)