Seeing that there are many questions regarding
"where should I place my web server in relation
to my router/firewall/proxy" etc, I'd like
to type up a small list to head off at least
some of the questions:
This is heavily geared towards NT, seeing that
it's the operating system of choice for new people,
and they're the ones that probably have the most
to gain from reading this.
Generic rules:
1. Hide as much information as possible
(in this context, as few publicly accessible IPs
as possible)
2. Work by first restricting everything and
then opening up what needs to be opened up,
not the other way around. (This is old news
but cannot be repeated too often)
3. If an outside user can initiate commands on
a machine, ANY commands!!!, it is to be labeled
"unsafe" and placed in a DMZ so as to protect
internal hosts.
4. If a feature is new, it has more bugs than
an old feature. (Is "old feature" oxymoronic btw?)
5. When your setup is finished. AT LEAST do a port
scan from the outside!!!
http://www.winfiles.com/apps/nt/net-info.html
You too are human, and being one, you are
bound to make mistakes.
The third point is the really interesting one
given the questions we see.
For instance, your web server should be protected
by a stateful inspection firewall or screening
router with _very_ mean settings when it comes
to fragmented packets.
Protecting a web server by passing queries through
a proxy server means little or no security but rather
degraded performance - never mind doing that (this
assumes that you installed that firewall I talked
about. If you didn't, the proxy IS a good idea :-))
If you have the ability to disguise your web server's
address through means of static adress translation,
do so. See rule #1.
If your web server needs to access a database, see
rule #3 - if someone can initiate commands on a machine,
it belongs in the DMZ. This goes for standalone SQL
servers as well as MS Access databases. Your DMZ machines
should NOT be allowed to initiate connections to
internal network machines, under ANY circumstances.
Programmers write server software. Programmers are human.
Humans make mistakes.
Machines in the DMZ should never contain information
about the internal network. (Rule #1). This means
that they cannot have trust-like relationships to
machines in the internal network since this involves knowledge.
It also (of course) means that they cannot be part
of the same domain, using a for instance a seldom-updated
BDC in the DMZ.
If you need to access files on DMZ machines, I recommend
FTP or SSH - see rule #4.
But, if you ***absolutely need*** file system access via
NetBIOS to the machines in the DMZ, I recommend that
you dynamically address translate (NAT-hide) your
NetBIOS calls from the inside to the machines
in the DMZ (Yes folks, this actually works! It's
NetLogon to domain controllers that doesn't
work, plain sessions do!).
You'll have to type the user name and password
to access the share of course. (You didn't think
that you could assign the same user names and
passwords in the DMZ that you do in the internal
network, did you?)
If your webfuhrers are technically challenged,
you might want to consider mapping the web server's
hard drive in their logon scripts like so:
net w: use \\webserver\sharename /user:joe mypassword
(But I'd advice against it :-)
Of course, you'd need a mapping from "webserver" to its
real IP address through LMHOSTS or perhaps WINS?
(My advice is to use LMHOSTS, even though it may
increase admin burdens)
Greg Bastian asked how to give the web server access
to an MS Access database. The database file is
updated by users on the internal network?
There is no really good answer to this question if
you need shared data. If you'd like to invest
a lot more $$$ in your solution you could look into
Corba and their object model - there are reportedly
proxies specially written for this transport, I
haven't needed to do that yet (yay!).
If you only need to sync your data a few times a day,
and changes are only moved from the inside out, you
might look into the possibility of uploading it
via FTP. This would require an FTP service on the
web server, which should not be reachable from the
outside -- if intruders can modify your database,
they could have it run arbitrary commands every time
your perform a query on it.
Other solutions is to use SSH and SCP to copy the data.
This is the most secure solution I can think of other than
moving it by means of floppies or singing telegrams.
Uhm.. I'm not going to kill my own livelyhood by giving
away too much for free in one large lump, so I think I'm
going to cut it short here! :-)
Anyways, it all boils down to:
Look at rules 1 2 and 3. Investigate how they apply
to every step of your solution.
If something breaks these rules, change your solution.
Later
/Mike
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
