dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
1599
share rss forum feed


exocet_cm
Free at last, free at last
Premium
join:2003-03-23
New Orleans, LA
kudos:3

Best way to lock down public-accessible servers

I'm testing some public-accessible servers in my lab that are behind my gateway/firewall.

These multiple servers running 2008 R2 Web run public-facing applications (secure FTP, secure HTTP portal, etc) and connect through DCOM and other means to back-end application servers running 2008 R2 Enterprise.

Although these web servers are in the same subnet as the app servers, have the same domain firewall policies as the app servers, their only "protection" from the outside is the gateway.

Now that I'm done testing the Web-to-App connections and the programs are running smoothly, what would be the best method, if any, to lock these servers down? Put them in a new subnet?
--
"All newspaper editorial writers ever do is come down from the hills after the battle is over and shoot the wounded." - Bruce Anderson
"I have often regretted my speech, never my silence." - Xenocrates
Check out my blog: »www.johndball.com



Jahntassa
What, I can have feathers
Premium
join:2006-04-14
Conway, SC
kudos:4

1 recommendation

I usually put anything that's 'public facing' on a 'DMZ' network, which is separate from any internal LANs. If that public system needs to talk to something on the LAN, I either do a pull from the LAN side, or lock down that public system so it can only access specifically what I need it to access.

Beyond that, firewall on each, only specific ports on the WAN firewall / router allowed to them, and Anti-Virus with reporting turned on.


JoelC707
Premium
join:2002-07-09
Lanett, AL
kudos:5

1 recommendation

reply to exocet_cm

My suggestion is a DMZ network as well. You'd end up with two firewalls. One at the border with the DMZ network behind it and in the DMZ network is your second firewall that feeds the LAN network. You'd run either public IPs on the DMZ servers or 1:1 static NAT, don't run general NAT here, run NAT on the LAN side so you aren't double NATing.

This arrangement gives you two firewalls an outside hacker must penetrate to get to LAN resources and provides a true firewall between the LAN and public servers (allow specific ports though only as needed for them to communicate with their respective back-end servers).


HarryH3
Premium
join:2005-02-21
kudos:2
Reviews:
·Suddenlink
reply to exocet_cm

Here's a pdf of how it would be done using a Watchguard device: »www.watchguard.com/help/configur···-US).pdf The idea is similar regardless of which firewall you have.



exocet_cm
Free at last, free at last
Premium
join:2003-03-23
New Orleans, LA
kudos:3
reply to JoelC707

Everything is virtual, BTW except for the gateway/firewall which is a physical box.

On the gateway, I have two external IPs. One for everything, the second IP is mapped 1:1 to all external accessible servers. All traffic incoming/outgoing goes through that IP address for those servers.

I guess that is the first step in segregating traffic for these servers. The second would be internally separating the subnet, referenced in the Watchguard link, to something my main server subnet doesn't use and using domain windows firewall (already in place) to configure access to those devices. Windows Firewall would block all ports from that subnet and I would poke holes in the DENY ALL rule to allow certain traffic.
--
"All newspaper editorial writers ever do is come down from the hills after the battle is over and shoot the wounded." - Bruce Anderson
"I have often regretted my speech, never my silence." - Xenocrates
Check out my blog: »www.johndball.com

JoelC707
Premium
join:2002-07-09
Lanett, AL
kudos:5

Through the use of VLANs and/or subnetting, you could use multiple inside interfaces on the single firewall to gain a DMZ subnet setup. It won't be completely a true DMZ subnet because it shares the same firewall but it'll be close. Your diagram would be about right for that kind of setup.



tubbynet
reminds me of the danse russe
Premium,MVM
join:2008-01-16
Chandler, AZ
kudos:1
reply to exocet_cm

said by exocet_cm:

Now that I'm done testing the Web-to-App connections and the programs are running smoothly, what would be the best method, if any, to lock these servers down? Put them in a new subnet?

(i say all of this speaking from working in large datacenters -- so take it with a grain of salt and apply what you think is needed).

generally -- you look at two fold isolation. the first -- being mentioned by Jahntassa See Profile in creating a public dmz for all external facing servers and services. bear in mind -- that the normal connotation for this is either (a) external users coming from the interwebs, or untrusted external uses (b2b-type stuffs). this dmz is isolated from the "trusted" network by way of a firewall.

from there -- within both the dmz and internal "app" environments -- the idea of vlan'ing and security filtering is applied per vlan. there are two schools of thought, one in which each "app cluster" (web, app, and database) are in their own vlan, and another in which all web servers are in one vlan, apps in another, and db's in another. in this way, each web server can have specific access-policy applied on which app server it can hit, with no direct access to the db server, etc. this may be overkill -- but in large environments -- the "three-tier app" is a conceptual model that generally follows this process.

q.
--
"...if I in my north room dance naked, grotesquely before my mirror waving my shirt round my head and singing softly to myself..."

HELLFIRE
Premium
join:2009-11-25
kudos:18
reply to exocet_cm

2nd what's been said so far.

To help you visualize, here's a DMZ / 3leg firewall setup. Basically you wouldn't want the web / SFTP / HTTPS box(es) to be used as jump off points
to attack your other inside hosts.

As for cramer's 3tier setup, here's two other pictures for your reference.

For further isolation at layer 2, I'd look into private VLANs for your hosts

Other standard "best practices" / "no duhs!" as well :
- persistent logging set up -- syslogs, access logs, etc.
- regular patching of OS, software, apps, etc.
- IDS / IPS -- YMMV
- antivirus and any other relevant anti-X
- least priviledge permissions set up on each host(s)
- regular review / audit of the environment, firewall rules and logs, etc.

My 00000010bits.

Regards



Drex
Beer...The other white meat.
Premium
join:2000-02-24
Not There
kudos:1
Reviews:
·AT&T U-Verse
reply to tubbynet

said by tubbynet:

there are two schools of thought, one in which each "app cluster" (web, app, and database) are in their own vlan, and another in which all web servers are in one vlan, apps in another, and db's in another. in this way, each web server can have specific access-policy applied on which app server it can hit, with no direct access to the db server, etc. this may be overkill -- but in large environments -- the "three-tier app" is a conceptual model that generally follows this process.

Three tier is how I've seen it implemented. Separate web from app from DB via firewall and ONLY allow those ports/protocols between each "layer". I can tell you it's how the DoD does it. In fact they go a step further with a single gateway/proxy with a white list as well. Want you web app to be publicly accessible? Better get it on the white list.
--
I'm actually not funny, I'm just really mean and people think I'm joking.


tubbynet
reminds me of the danse russe
Premium,MVM
join:2008-01-16
Chandler, AZ
kudos:1

said by Drex:

Three tier is how I've seen it implemented.

this is true in my experience as well. however -- i have seen some customers make each "app" pod into its own /29 or so. web, app, and db resides in this pod and is self-contained using firewall rules. this allows a lot of freedom and flexibility in migration from a virtual perspective (i.e. vmware vmotion, etc).

both are accepted practice, it just depends on the security and business continuity goals that are to be achieved.

q.
--
"...if I in my north room dance naked, grotesquely before my mirror waving my shirt round my head and singing softly to myself..."


exocet_cm
Free at last, free at last
Premium
join:2003-03-23
New Orleans, LA
kudos:3
reply to exocet_cm

Well it took a minute but I got it all moved over to a separate subnet. I have the settings in place to put them on their own VLAN but I have to upgrade the software in my gateway to the next version which supports VLAN tagging on multiple pseudo-interfaces.

In the mean time, they are all in a separate subnets with Windows Firewall set to block all incoming and all outgoing except the services that are needed to communicate with the DCs and the WAN.
On the other end, the internal networks are blocking everything from the DMZ servers except the connections between the DMZ servers and the application servers. Outside of the scope of the application servers nothing can communicate with anything in the DMZ.
--
"All newspaper editorial writers ever do is come down from the hills after the battle is over and shoot the wounded." - Bruce Anderson
"I have often regretted my speech, never my silence." - Xenocrates
Check out my blog: »www.johndball.com