RE: Re: Anti-Defacement Products...

["Jonathan Squire" <jsquirelists () crosswinds net>]

Another product that may be of intrest in protecting your web sites from defacement
is whale communications eGap. (http://www.whalecommunications.com/)

The transaction shuttle product would be able to protect your sensitive content
from being modfied on the web server by network based attacks.

The eGap is a hardware device that physically disconnects your external server
from the inside network, it does not pass Network protocols at all, rather it
just passes the transaction data (the url) through to an inside box that servers
the request. If the external boxes is compromised, the sensitive material (your
web pages) are not exposed to modification, as the external machine does not
contain the content.

The egap transaction shuttle also has the ability to inspect the content of
the urls to make sure only valid data is passed to/from the internal server.



> 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.