Re: Access to backend systems

["Stephen P. Berry" <spb () meshuggeneh net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Ellis Luk writes:

> But nowadays, in the name of eComm, more and more business requires
> their web applications to be able to connect to the back-end systems
> (usually databases), so that they can present real-time production data
> to their customers, (or even worse, allow their customers to enter data
> to the backend systems for processing.

        [deletia]

> I guess my questions are:
> 1) have you encounter similar situation before?
> 2) how would you use your resource (firewall and/or other servers) to 
> protect it ?

Assuming no other requirements:

        -Put the front end web(or whatever)server in a service network
         behind a dedicated interface of a firewall
        -Dual home the front end server
        -Connect the (single-homed) database to the second interface
         of the front-end server
        -Install ipf (or something similar) on both machines
        -Configure ipf on both machines to only allow whatever is
         required for the database functionality

In this sort of situation, the things you're going to have to worry
about in any topology are things like:

        -Security of the front end server code (i.e., freedom from
         remotely-exploitable bugs)
        -Ability of the front end server to do sane access control
        -Ability of the front end server to handle arbitrary input
         sanely

        -Security of the database code
        -Ability of the database to do sane access control
        -Ability of the database to handle arbitrary input

If you can rely on the first three, then the second three are not
as much of an issue.  In any case, all of the items I list above
are part of the standard littany of the problems associated with accepting
inbound traffic.  If you're relying on accepting inbound data, you're
going to have to come to terms with those problems.

In other words, those are design limitations inherent in the problem
you're trying to solve.  I'm not going to attempt to address those
issues, and I reckon they're beyond the scope of what you're asking.

In addition to these fundamental design limitations, you can introduce
an whole new set of implementation problems depending on how you
build your system.  The simple topology I describe above is an attempt
to minimise your security liabilities by not introducing new
problems which are implementation (rather than design) specific.
Put another way, it's an attempt to be no worse than the best case,
mod your selection of database, front end server, authentication widgetry,
u.s.w.


My guess is that you've got some database access requirements you
haven't described.  Even given that, setting up something like:

        -Sshd(8) on the front-end server (or another dual-homed machine
         beside it) configured to require RSA/DSA keys
        -All lusers on this machine have an ~/.ssh/authorized_keys file
         with a "command="
        -The specified command forces an ssh to the database machine

...is probably still preferable to putting the database machine 
on a general-population network (i.e., corporate LAN).  Always
try to avoid establishing transitive trust relationships with
machines accepting inbound traffic.  Always consider containment
of a compromise when specing or building a service network.

One of the most important aspects of operational security is understanding
and controlling failure modes.  If you are actually concerned about
security you must be willing to subjugate the needs of functionality
to the needs of security.  In most cases you will discover that there
are more ways to establish a given functional goal within an accepted
security framework than there are to establish meaningful security
goals within a rigid functional framework.






- -Steve

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE574WaG3kIaxeRZl8RAk5tAJ96sFVDzHG9KiXgbudpDTClMsdhnACgoaiz
Wa17SLsPaOwhq8hde70nMlc=
=9qNJ
-----END PGP SIGNATURE-----

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards