Thanks very much for your reply; it has helped a lot in thinking of
(more) things to do.

On Fri, 25 Mar 2005 17:23:34 -0500, Steven M. Bellovin
<smb@cs.columbia.edu> wrote:

> Ideally, you'd use two machines; put apache on one and the db on the
> second.  Ideally, both machines have two NICs:
> 
> Internet --- apache --- db --- back end

I remembered that you would probably want DNS and possibly a mail
server in a setup like this. In that case I would think of something
like:

Internet
--> apache --> backend
--> dns and secondary mail
--> mail and secondary dns

Backend
--> db
--> syslogd

(ie. 3 internet and 2 locally accessible machines)

Is there anything not-advisable with the above? It's probably better
to get backup dns/mx on a different net segment in case a router goes
down in the datacentre or something; but then the site would go down
anyway so all that would do from a client's perspective is resolve but
fail to connect as opposed to failing to resolve in the first place
which, for me, is worse (cannot resolve domain.com is more
"frightening" than "timeout").

Port knocking sounds very interesting for administering remotely.

> Have very strict ipfilters on both machines.  Don't speak anything as
> powerful as sql over that link; instead, it should be a very
> narrowly-defined application-specific language.

If the only connection from the db to the webserver is local, and
physical security is not a concern then wouldn't sql suffice?

Also, if the attacker gained access to your web server they could
access the database through your web api regardless of the db api
surely.

- if your scripts (web api) do it, then someone who has access to
those scripts can also do it, as long as the database connect
information is in your scripts

The only way to have no database connect information stored on your
webserver (and hence removing the possibility of your hacker
connecting to the db server) is if you add/remove users manually, and
get the users to specify their passwords to the database directly
through your web api.

If you did this then there remains one last possibility - hacker
manages to access your db server and has access to your db files. I
assume this is paranoia on a very high level, but theoretically how
could you encrypt your db files while enabling your db api to access
them?

Are there other ways of doing this? Of course, if you're running an
IDS chances are you'd find out before they got this far, but the
possibility remains.

Amadeus