RE: Re: Anti-Defacement Products...

[fernando_montenegro () hp com]

Hi everyone!

ATTENTION: This message is not supposed to be marketing drivel. Though I will 
talk about a specific product, I hope the technical description will merit 
posting to the list.

Using a multilevel OS as a Web server, as Paul described, is something that we 
have had some success with at HP. One of our better known products, Virtual 
Vault, is architected almost exactly like Paul described. The product is based 
on a modified version of HP-UX, so running it is not totally unlike 
administering a normal UNIX box.

The way that the Virtual Vault (VV) is set up is to have 4 separate containers, 
enforced by MAC rules (not changeable from a running process, once "root" is 
disabled and no extra privileges are given to user accounts):
- System, holds almost all files in the system plus the running instances of 
most operating system applications.
- Outside, containing ONLY the webserver running instance and the webserver's 
access log.
- Inside, holds the running instances for some administrative daemons and the 
customer application, as well some temporary files/directories.
- SystemHigh, with the audit daemon's running instance and ancilliary files.

BTW, normal Discretionary Access Controls (DAC, our familiar owner-group-world 
permission mechanism) still applies, so access is checked against DAC and MAC 
both.

Should the OUTSIDE compartment be compromised (through a failure in the Web 
server), the only files subject to change are the HTTP access logs. Usually, 
the HTML/GIF/JPG/... content will be housed in the SYSTEM compartment, 
therefore safe from modification by the outside.

The customer application runs in the INSIDE compartment. While a compromise 
there is worse, it is still limited by the MAC rules.

Checking MD5 signature on files can be done on-the-fly for CGI scripts (though 
it will hurt performance) or regularly through cron.

On the downside, it takes some planning to come up with the proper policies and 
procedures for integrating content, running audits, ... but it is certainly 
within reach of any knowledgeable UNIX shop.

Hope this helps. 

Cheers,
Fernando
--
Fernando da Silveira Montenegro     Hewlett-Packard Brasil
HP Consulting - IT Security         Al. Rio Negro, 750 - Alphaville
mailto:fernando_montenegro () hp com   Barueri, SP - Brazil 06454-000
voice: +55-11-7297-4351             #include <disclaimer.h>


> -----Original Message-----
> From: mcnabb () argus-systems com [mailto:mcnabb () argus-systems com]
> Sent: Tuesday, March 28, 2000 5:10 PM
> To: Kyle.Starkey () msdw com
> Cc: mcnabb () argus-systems com; firewall-wizards () nfr net
> Subject: Re: [fw-wiz] Re: Anti-Defacement Products...
>
>
> Starkey, Kyle wrote:
> > I was thinking about defacement the other day and how to 
> help automate a
> > response to this type of activity.  I understand that host 
> based security
> > and network based security is the key, but what about 
> response.  I am
> > looking for a product that could be used to make sure the page being
> > displayed was the real page.  Thoughts of encyting the 
> page/code to get a
> > hash and storing it somewhere inside the enterprise, 
> periodically the
> > webserver re-calcing the hash on the page stored locally 
> and running a check
> > against a the stored copy secured in box on the inside.  I 
> would also
> > envision the automatic posting of the original source back 
> to the webserver
> > and alerts bieng generated to the security officer if the 
> two hashes did not
> > match.  Does anyone know of any product that does something 
> similar?  I was
> > hoping not to have to build this from scratch, but perhaps 
> it will be my
> > little project.  Any thoughts about this project or 
> software that might
> > already do this for me would be greatly appreciated...
>
>
>
> 1. Use a TOS to create 3 virtual machines: one for the webserver process,
> one for the webpages, and one for administration.  Make the webpages VM
> read-only from the webserver VM.
>
> 2. Move all admin utilities into the admin VM.
>
> 3. Put the internet network interface in the webserver VM, and put the
> internal LAN network interface into the admin VM.  If you want, you can
> pick certain hosts or subnets on the internal LAN to be in the admin VM
> and send all other internal hosts to the webserver VM.
>
> 4. Use the packet filtering part of the TOS to prevent the webserver,
> or anything that is coming from the Internet from ever contacting the
> admin VM and from ever modifying the webpages VM.  Note: this will hold
> true no matter what machine instructions are executed in the VM, so you
> can open up other services (like ftp or telnet) if you want.  Or, you
> could put these other services in their own VMs.
>
> 5. Use the integrity mechanism of the TOS to verify checksums and security
> attributes of the webpage files.  This can be run automatically at any
> interval you need.  If you want to be really paranoid, set up another VM
> for logging and auditing and run everything from that.  Make the other
> VMs visible to the logging VM, but not the other way around.  Use the
> packet filtering on the TOS to limit access to the logging VM to a single
> host somewhere, preferably protected via a VPN and on the internal LAN.
>
> 6. If this is a host with a single network interface, use virtual IFs
> to set up the system so that each VM has its own virtual network IF and
> give each service and VM its own IP address on the box.