Such complicated schemes are not neccesery in this case.
It's more easier to combine the SQL and http/ftp server in one machine.
Seting up firewall carefully is enough. Combining it with appropriate tcp
wrappers and making sure that the other servers are patched carefully makes
it a tough work to be exploited.
Here's my suggestion (using linux ipfwadm):
ipfwadm -Fp deny
ipfwadm -Fa accept -S 0/0 -D webserver 20 -P tcp
ipfwadm -Fa accept -S 0/0 -D webserver 21 -P tcp
ipfwadm -Fa accept -S 0/0 -D webserver 80 -P tcp
ipfwadm -Fa accept -S internal_network/mask -D webserver sqlport -P tcp
ipfwadm -Fa accept -S internal_network/mask -D webserver sqlport -P udp
Eventualy you may assigned your internal network private addresses and masquerade it.
Try to log all denied
packets for webserver and internal network. It's a good idea to limit the services
that you provide to the world
from your firewall server.
Because sql servers are traditionally insecure, you could put a custom wrapper, or
even develop a daemon,
that will handle the updates between the sql server and internal network and tell the
sql server not open a socket.
There is enough software for making an interface between SQL servers and WEB (PHP is a
good choice).
Good luck.
On Wed, 24 Feb 1999, David Taylor wrote:
> Date: Wed, 24 Feb 1999 09:21:38 -0600
> From: David Taylor <[EMAIL PROTECTED]>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: Bypassing Firewall
>
> I need help supporting my position as outlined below.
>
> Our current set-up is rather typical:
>
> external__________firewall____________internal
> |
> |
> webserver
>
> We will be adding an SQL DB server to enhance e-commerce functionality
> (inventory levels, order status etc...) The database server will receive
> updates from an internal source (current guesses are anywhere from every 5 -
> 30 minute intervals) My suggestions to management are:
>
> external__________firewall____________internal
> |
> |
> switch
> / \
> / \
> webserver SQL DB server
>
> or:
>
>
> external_________firewall__________internal
> / \
> / \
> / \
> webserver SQL DBserver
>
> with an appropriate tunnel carved-out to facilitate the internal -> DMZ
> updates.
>
> Management has proposed the following scenario:
>
> external_________firewall__________internal
> | /
> | /
> | /
> webserver___SQLDBserver
>
> with the segment between the webserver and the SQL server being a different
> net.
>
> They feel that the update traffic will bog down the firewall (not a chance
> it hasn't even begun to break a sweat) and that since the traffic coming to
> the webserver has already passed through the firewall that it is "safe"
> (i.e. sanitized) additionally that since both the webserver and the database
> server will be acting as gateways that now one would know about them.
>
> To me this idea seems just plain "bad!"
>
> I've pitched the obvious "security through obscurity" regarding the
> gateways. I've also tried to explain that due to the nature of http and SSL
> one is able to tunnel other protocols/applications within them. I'm now
> being pressed for "specific examples" of why their idea is insecure. Or,
> better yet, specific examples of how it could be exploited. Better yet
> would be real-world situations that could be sited to support my position.
>
> Sorry for rambling on.
> Thanks in advance for any help.
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
----------------------------
Vesselin Mladenov
NetBG Communications Ltd.
phone: +359-2-974-4260
+359-2-974-4261
----------------------------
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
