[3408] in WWW Security List Archive
Re: Where to locate external webserver ?
daemon@ATHENA.MIT.EDU (Mark Seiden)
Wed Oct 30 01:44:54 1996
From: mis@seiden.com (Mark Seiden)
In-Reply-To: <199610291423.OAA22980@menglad.ecmwf.int> from Philippe Parmentier at "Oct 29, 96 02:23:25 pm"
To: mol@ecmwf.int (Philippe Parmentier)
Date: Tue, 29 Oct 1996 20:19:32 -0800 (PST)
Cc: bruggema@btmaa.bel.alcatel.be, www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
consider the typical case of an ssl-talking web server, running on a
bastion host, receiving an order containing a credit card from a
client out there somewhere, and wanting to insert it in an rdbms
on the inside, which usually is protected only by a login and
password. (i'll use sybase rdbms lingo, but it really doesn't
matter for the example.)
writing a queue file and having it fetched by an inside machine polling
for work is not a great solution for several reasons:
- the file is sitting in the clear for some period of time, the
polling interval.
- polling is delay-prone and inefficient, compared with interrupt
driven or msg-based systems.
- the bastion host still needs to authenticate the fetching machine,
somehow (but presumably it already allows the firewall to connect for
the usual operational reasons).
- you still need a special-purpose daemon to run on the inside machine.
the main advantage is that the firewall probably already has a policy
of permiting inside machines to talk outside, and the web server already
allows the firewall to do that.
the alternatives i've used are:
1. use the gauntlet sybase proxy. this does some authentication of
sybase requests. i haven't audited it.
2. use a plugboard (or netcat, for that matter) restricted so only the
web server's ip addresses can talk to the inside rdbms server port.
naturally the router must be configured to prevent ip address spoofing
of the bastion host's address from the outside. the web server cgi
(or middleware layer) must somewhere contain an rdbms login and
password, and this login should be restricted to executing only the
specific stored procedures to insert an order in the database. if you
can make your network path between web server and firewall and
firewall and order entry machine sniffproof, you can talk in the
clear.
3. use a plugboard but use ssh to talk over it. this gives you
encrypted, compressed, cryptographically authenticated file copies,
using scp to copy the file. there's no exposure on the firewall, which
seems no cleartext. (if you're clever, you may be able to get by with
no accessible tmpfile version of the order.) so no cleartext except
briefly on the web server and on the destination machine.
4. just plugboard port 443 through the firewall, and run a secure
server on the inside which only does order processing. big advantage:
no plaintext outside the firewall and no buffering or polling needed.
risk: anyone who can break into the secure server (say, through
weak cgi) may be able to do stuff elsewhere inside.)
what are the exposures in these schemes?
- in 1..3 anyone who can break into the web server can pretend to be
the web server and fabricate orders, and if there is one, they may be
able to harvest the clear copies of the orders.
- they can also launch a brute force or denial of service attack on
the rdbms via the plugboard.
- with the the ssh private key of the web server but only in
combination with an ip spoofing attack, they can do this from another
host on the lan.
(all of these seem like pretty difficult attacks to me.)
my personal favorite is currently 3, since it is largely immune to
sniffing attacks regardless of network technology, even on the part
of insiders. (only the endpoint hosts are vulnerable due to their
need for cleartext.)
(implicit advertisement: my consulting practice involves finding the
right solution to specific problems using piece parts such as these...)
> In a previous mail , VERBRUGGEN MARC GZ3 03/450.33.49 wrote :
> > 2) Suppose that I want to update the information from data in a database on a
> > machine that is on the inside of the firewall : how do I fix that in a safe way
> > ? A CGI based solution, using some kind of database connect will probably not
> > wrk because the firewall will not allow it.
> >
>
> If writing on your databse in real time is not critical, the safest way
> would be do write temporarly on a local database or file on your server, and
> then have every so often a job on the machine inside your fire wall fetch
> the necessary data from the web server. That way, you will even be able to
> check on these data before actually do something with them (like test size
> to avoid overflow, type etc).
>
>
> --
>
> Philippe Parmentier E-mail : P.Parmentier@ecmwf.int
> Snail : ECMWF, Shinfield Park, Reading, Berkshire RG2 9AX, U.K.
>
--
mark seiden, mis@seiden.com, 1-(415) 592 8559 (voice)
