cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
395
Views
0
Helpful
5
Replies

ASA and introducing DMZ

ephillips12
Level 1
Level 1

I have recently inherited a network with around 80 hosts containing mostly web, mail, and database servers. After auditing their ASA 5510, I found a major security issue I want to fix with as little service interruption as possible. The problem is that the ASA is only configured with 2 interfaces:

Outside = 123.123.123.0/29

Inside = 234.234.234.0/24

Both subnets are public address blocks, and the 234.234.234.0/24 subnet is currently assigned to the hosts.

To fix this I would like to introduce at least one DMZ interface to separate the web and mail servers from the database servers. My proposed setup would be:

DMZ = 10.10.10.0/24

Then I would NAT the public IP to DMZ interface to prevent having to change DNS for the sites that the web servers run.

My question is how can I introduce this DMZ with as little server interruption as possible? Could I take one host at a time and change the IP of that host to a 10.10.10.X IP, then issue a NAT command something like this?:

static (dmz,outside) 234.234.234.X 10.10.10.X netmask 255.255.255.255 dns

Keep in mind that the 234.234.234.0/24 subnet is still assigned to the inside interface and there will still be other hosts that are live within that subnet. Will the static (dmz, outside) 234.234.234.X override and route to the DMZ instead of the inside?

Of course in the end, I will have a new subnet on the inside, something like 10.0.0.0/24 and the only interface with a publicly routed subnet will be the outside.

I'm open for any ideas, thanks for your time.

5 Replies 5

scheikhnajib
Level 1
Level 1

Mate,

Not sure if this will work, I know that the PIX will NAT and then router which means when you have a request from the outside towards a host on your DMZ, the PIX will translate the destination address and then forward the packet to the destination host. The fact that you have your inside interface addressed with the same range is a bit confusing and I don't think that I can give you an accurate answer.

My recommendation is: Save the hassle, write a proper plan and do a big bang migration ... it saves you time and it will be cleaner and more efficient.

Even if your approach worked, how are you going to deal with server-2-server traffic where hosts on the DMZ will need to talk to hosts on the inside while your migrating? You will need to consider more elements and you will expose yourself to more risk.

That's my personal opinion.

Cheers,

S.

scheikhnajib,

Thanks for your reply. I was hoping to avoid this but I'm not sure I can. Only problem is changing 80+ servers all at once is no small task.

Thanks for your help.

phillips,

The method that you are suggesting should work.

if you have a static translation of a host in the dmz with the public address belonging to the inside..it does not matter because the firewall will be loooking for a route to the 10.x.x.x IP and not the 234.x.x.x ip...right?

My feeling says it should work, chnage the IP of one server at a time to bring it to the dmz after creating the static translation.the access list is already there I guess applied to the outside interface.

However you might also want to consider communication between your webserver/app servers and the DB servers because once you create the dmz and move servers there, webservers and app servers will now have to traverse the firewall to reach the DB servers...in contrast to the current scenario where all servers are in one zone "INSIDE"

Naseem

Naseem,

Thank you very much for your input.

I'm going to test this next week during our maintenance window. I will let you know what the results are.

Naseem,

Just wanted to update you as I tried this during our maintenance window last night. This worked!!!

I did have some issues talking back to the 234.234.234.0/24 from the DMZ, but that's expected. Only quirk I found was in the ASDM. I added the DMZ interface in the ASDM, but setup the static NAT rule via the command line tool in the ASDM. After I verified that it worked, I removed the static NAT rule from the ASA via the ASDM. The ASDM tried to get smart and screwed up my outside_acl. It basically replaced everything with 234.234.234.X with the DMZ's subnet of 10.10.10.X. I'm not sure why it did it but it of course broke all external access in. I had to quickly fix it but it wasn't a major issue.

I guess the ASDM was confused because of the NAT to the DMZ and that the inside had the same subnet bound to it.

Anyways, this did work and I guess I will not be able to use the ASDM (or will need to be very careful) until it's all migrated over. Thanks for your help on this.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: