This is a discussion on Re: [fw-wiz] Web Services and Firewall/Network Architecture - Firewalls ; Thanks Dan! -----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Dan Lynch Sent: Monday, March 24, 2008 2:48 PM To: Firewall Wizards Security Mailing List Subject: Re: [fw-wiz] Web Services and Firewall/Network Architecture Richard, The best info I've found is ...
[mailto:email@example.com] On Behalf Of Dan
Sent: Monday, March 24, 2008 2:48 PM
To: Firewall Wizards Security Mailing List
Subject: Re: [fw-wiz] Web Services and Firewall/Network Architecture
The best info I've found is in Cisco's book "Network Security
Architectures", and SANS' "Inside Network Perimeter Security".
The basic rule is: never allow high risk connections to high value
networks. IOW, internet sources shouldn't touch my internal servers. If
a web server needs to be publicly accessed, it goes into a DMZ network
(maybe more accurately termed a "screened subnet") off a firewall. That
server is thoroughly hardened, and does not make connections into the
internal network. If there's a database backend to the web server, that
DB server goes into yet another DMZ. Firewall rules strictly control
connections between DMZs and the private nets. Local OS firewalls and
IPSec policies control connections within the DMZs.
On a single firewall with four interfaces, it might look like this:
Internet ---> |
|--Web server DMZ
|--Db server DMZ
You can do similar with multiple firewalls.
DMZ servers are initially configured on a test net, an image of the
final config is taken and saved in escrow, then the server is deployed
into the wild-wild-DMZ. Patches and updates to these servers are handled
manually and carefully logged. (Your sys admins will hate you, but it
beats letting them connect through the firewall to an internal patch
server.) Occasionally the server is pulled from production, and the
escrowed image applied. Then the logged patches are re-applied, arriving
at a new final, production install. A new image is taken, and the
machine re-released into the DMZ.
There are times when it's necessary to allow a public web server to
connect to internal machines. Outlook Web Access comes to mind, in which
the web server "must" be a domain member server. In that case, the web
server is fronted by an application-layer proxy firewall.
The books give multiple examples, discuss web services software
architecture in detail, and address VPN remote access, authentication,
mail and DNS services too.
Dan Lynch, CISSP
Information Technology Analyst
County of Placer
> -----Original Message-----
> From: firstname.lastname@example.org
> [mailto:email@example.com] On
> Behalf Of Ginski, Richard J
> Sent: Thursday, March 20, 2008 11:29 AM
> To: firstname.lastname@example.org
> Subject: [fw-wiz] Web Services and Firewall/Network Architecture
> Hi All,
> There's talk in our org to directly interface one of our
> back-end servers to provide web services for external
> entities via the Internet. On the surface, this is a risky
> option for me. Although firewall "protected", I don't want a
> "protected device" directly interacting with web service
> "consumers" from the Internet. It sounds like a bad idea to me.
> I have been searching around looking for sample diagrams
> (etc) on environments that support Web Services. I am trying
> to determine where stuff goes in this environment and how a
> firewall/DMZ fit into the picture. Can anyone point me to
> where info would be available for this? I've checked the
> archives for the past year and checked at OASIS, W3C, OWASP,
> and XML.com, with no luck. The "web services sites" focus on
> coding practices, coding architecture, and coding frameworks.
> Although very important, it's not the info I am looking for.
> We are trying to determine how web services fit in our
> environment using best practices in network design and
> network security to support web services.
> Any help would be greatly appreciated. TIA!
firewall-wizards mailing list
firewall-wizards mailing list