[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 364
  • Last Modified:

Configure Cisco 506e Firewall

How do I configure the cisco 506e firewall On a new server?
0
HighSecured
Asked:
HighSecured
  • 6
  • 5
1 Solution
 
lrmooreCommented:
Can you be more specific on what you need to do? Is this a new 506? Or do you have a new server for which you need to "puch holes" in the firewall for email or www traffic?

0
 
lrmooreCommented:
Hello? Do you still need help?
0
 
HighSecuredAuthor Commented:
Eeep, sorry, we've been extremely busy for the last several days.

So yes, we have a Cisco PIX firewall, version 6.2(2) w/ two interfaces, with current interface configuration below:

nameif ethernet0 outside security0
nameif ethernet1 inside security100
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol ils 389
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060
fixup protocol skinny 2000
names
pager lines 24
logging on
logging console alerts
interface ethernet0 10full
interface ethernet1 10full
mtu outside 1500
mtu inside 1500
ip address outside 64.116.184.210 255.255.255.240
ip address inside 192.168.1.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm history enable
ip audit info action alarm
ip audit attack action alarm
pdm history enable
arp timeout 14400
route outside 0.0.0.0 0.0.0.0 64.116.184.209 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 si
p 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
no sysopt route dnat
telnet 200.90.134.0 255.255.255.0 outside
telnet 192.168.1.0 255.255.255.0 inside
telnet timeout 5
ssh timeout 5
terminal width 80

Naturally, security-compromising data such as password checksums information have been omitted.

Our situation is this:

  We purchased this firewall from recommendations from these forums to host two (with the ability of more) dedicated servers behind it.  Both servers have been allocated seperate, public IP addresses 64.116.184.210 and *.211, with a gateway of *.209 and subnet 255.255.255.240.  My questions are:

1. What commands/configuration do we send to the command line interface in order to effectively route both boxes' packets through the firewall?  Ideally, each box would be able to keep its actual IP-- *.210, *.211 (as opposed to an internal one).  The intial configuration should be completely open, allowing all on all, but barring, of course, fragment, icmp, and other common attacks.

2.  Additionally, we would like to know how, in the future, one might be able to restrict incoming/outgoing packets to given TCP/UDP ports from a given range of IP addresses.  For example, if we only wanted 123.45.67.89 to access TCP port 1234 on machine *.211, how would we go about doing this; conversely, if we wanted to null-route incoming connections from 123.45.67.89 to effectively block communication on TCP1234, but allow communication for everyone else, how would this be done?
0
A Cyber Security RX to Protect Your Organization

Join us on December 13th for a webinar to learn how medical providers can defend against malware with a cyber security "Rx" that supports a healthy technology adoption plan for every healthcare organization.

 
lrmooreCommented:
>Ideally, each box would be able to keep its actual IP-- *.210, *.211 (as opposed to an internal one)
That's not possible with your configuration. If you had a different subnet on the outside interface, then it would be possible, but since you don't, then your only option is to use private IP's on the servers and create static NAT for each.

>64.116.184.210 and *.211
This is another problem if .210 must be assigned to the interface. That only leaves you with .211 to use for a server, with 1-1 NAT, but I've shown you a workaround below...

Basic commands to get you communicating to start:
For example purposes:
Server1 = 192.168.1.100
Server2 = 192.168.1.200

/-- create global PAT for outbound xlates (any host inside)
  global (outside) 1 interface
/--create nat rule, same #1 to match the global
  nat (inside) 1 192.168.1.0 255.255.255.0
/-- create 1-to-1 static nat server private IP - public IP  
  static (inside,outside) 64.116.184.210 192.168.1.100 netmask 255.255.255.255
/-- create access-list to permit all traffic to that particular host
  access-list outside_in permit ip any  host 64.116.184.210
/--apply the access-list to the outside interface  
  access-group outside_in in interface outside

/--Basic IDS rules, attack prevention:
ip audit name attack1 attack action alarm reset
ip audit name info1 info action alarm
ip audit interface outside info1
ip audit interface outside attack1
ip audit info action alarm
ip audit attack action reset

For future reference, you can create static Port translations, then apply access-list permisssions (work around to use the interface IP for some services):
   static (inside,outside) tcp 64.116.184.211 smtp 192.168.1.200 smtp netmask 255.255.255.255
   static (inside,outside) tcp 64.116.184.211 http 192.168.1.200 http netmask 255.255.255.255
   static (inside,outside) tcp 64.116.184.211 https 192.168.1.200 https netmask 255.255.255.255

/--access-list permits only those ports that you want/need open if not specified, it is blocked always
   access-list outside_in permit tcp any host 64.116.184.211 eq smtp
   access-list outside_in permit tcp any host 64.116.184.211 eq http
   access-list outside_in permit tcp any host 64.116.184.211 eq https
/-- always re-apply the acl to the interface any time you make changes
   access-group outside_in in interface outside





0
 
HighSecuredAuthor Commented:
> >Ideally, each box would be able to keep its actual IP-- *.210, *.211 (as opposed to an internal one)
>That's not possible with your configuration. If you had a different subnet on the outside interface, then it would be possible, but since you don't, then your only option is to use private IP's on the servers and create static NAT for each.

Hmm, so if we had options, for example, to both change the subnet and get another router, what could be done for each?  That is, if we could change the subnet, what would be ideal; or, if we could get another router to be able to avoid the internal-ip issue, what would be ideal?

>This is another problem if .210 must be assigned to the interface. That only leaves you with .211 to use for a server, with 1-1 NAT, but I've shown you a workaround below...

So, are you saying we can only use one IP for both servers underneath the firewall?  Why couldn't the .210 also be used?

The main problem is, that when clients start hosting their own dedicated servers underneath the firewall, explicit routes would need to be created for certain, nonstandard services, I am assuming--  particularly on inbound connections.

Sorry for all the confusion, but our provider requires us to put *all* of our servers behind a hardware firewall, so I'm trying to set up the absolute minimum to begin with (without sacrificing functionality) in order the appease the gods of the datacenter.
0
 
lrmooreCommented:
In order for the servers to keep their public IP's, no router is necessary, but you need a separate subnet from the ISP that is routed to your PIX. It must be a different subnet than your outside interface IP. Example:
    ip address outside 64.116.184.210 /28
IP NAT pool of addresses: 64.116.184.224 /28 <== ISP routes this subnet to the outside IP address
 No, they cannot just let you use more IP's in the same subnet as your interface.

Now, you can use:

     ip address outside 64.116.184.210 255.255.255.240
     ip address inside 64.116.184.225 255.255.255.240

Server1 = 64.116.184.226
Server2 = 64.116.184.227
Server3 = 64.116.184.228
<etc>
    static (inside,outside) 64.116.184.224 64.116.184.224 netmask 255.255.255.240
    access-list outside_in permit ip any 64.116.184.224 255.255.255.240
    access-group outside_in in interface outside

>So, are you saying we can only use one IP for both servers underneath the firewall?  Why couldn't the .210 also be used?
Not saying that at all. Since **.210 is assigned to the actual interface of the PIX, then you can't do a 1-1 nat to an inside host, but you can use port redirection to redict specific ports to multiple inside hosts if you want, as I demonstrated above.

>The main problem is, that when clients start hosting their own dedicated servers underneath the firewall, explicit routes would need to be created for certain, nonstandard services, I am assuming--  particularly on inbound connections.
No. As long as your ISP routes a whole subnet to you, then no other routes anywhere need to be created. That works whether you have a full block of IP's available to you at the interface and then you create static NAT mapping, or whether you use full public IP's on the servers. All the routing is done at the ISP. To illustrate:

  Given your outside IP 64.116.184.210 netmask 255.255.255.240
  Given your default route: 64.116.184.209
If the ISP allows you to use the whole /28 block, then you can use .211 - .222 with static NAT maps to private IP's on the servers.
   static (inside,outside) 64.116.184.211 192.168.1.211 netmask 255.255.255.255
   static (inside,outside) 64.116.184.212 192.168.1.212 netmask 255.255.255.255
   <etc>
Given that configuration, your clients would access their servers by the public IP that you have natted to their respective server.. There is virtually no functional difference between using static NAT to a Private IP, or using a public IP on the servers themselvs. You have a wide range of flexibility by using private IP's on the inside of the PIX to start with..
0
 
HighSecuredAuthor Commented:
/* Quote
No. As long as your ISP routes a whole subnet to you, then no other routes anywhere need to be created. That works whether you have a full block of IP's available to you at the interface and then you create static NAT mapping, or whether you use full public IP's on the servers. All the routing is done at the ISP. To illustrate:

  Given your outside IP 64.116.184.210 netmask 255.255.255.240
  Given your default route: 64.116.184.209
If the ISP allows you to use the whole /28 block, then you can use .211 - .222 with static NAT maps to private IP's on the servers.
   static (inside,outside) 64.116.184.211 192.168.1.211 netmask 255.255.255.255
   static (inside,outside) 64.116.184.212 192.168.1.212 netmask 255.255.255.255
   <etc>
Given that configuration, your clients would access their servers by the public IP that you have natted to their respective server.. There is virtually no functional difference between using static NAT to a Private IP, or using a public IP on the servers themselvs. You have a wide range of flexibility by using private IP's on the inside of the PIX to start with..
*/

Right, we've got the 13-1 ip addresses that the ISP has given us; so, you're saying that we just use .210 as the router, and allocate .211+ to the actual other boxes?  Then, do we configure the boxes to listen for that IP or the 192.168.1.211,.212,etc, or do we just let it listen to the actual IP bound to it?

Therefore, in order to configure the firewall to be able to do as you said (eg, customers can access the boxes using the IP they desire), we do
   static (inside,outside) 64.116.184.211 192.168.1.211 netmask 255.255.255.255
   static (inside,outside) 64.116.184.212 192.168.1.212 netmask 255.255.255.255

In *addition* to which other commands?  It seems that there have been several situations mentioned, so I'm just trying to clarify before adding in conflicting stuff.

And do we need our ISP to do anything in addition? (as you said "ISP routes this subnet to the outside IP address
 No, they cannot just let you use more IP's in the same subnet as your interface.").  Or, is that just in the case of doing something different?
0
 
lrmooreCommented:
> you're saying that we just use .210 as the router, and allocate .211+ to the actual other boxes?  
Correct. Just as I demonstrate here:

  static (inside,outside) 64.116.184.211 192.168.1.211 netmask 255.255.255.255
  static (inside,outside) 64.116.184.212 192.168.1.212 netmask 255.255.255.255
  static (inside,outside) 64.116.184.213 192.168.1.213 netmask 255.255.255.255
  static (inside,outside) 64.116.184.214 192.168.1.214 netmask 255.255.255.255
<etc>

NOTE: your private IP does not have to be the same last octet, your Private IP's can be anything you want. I personally think it makes things easier for our meager human brains to comprehend and keep some correlation between the public and private. x.211=y.211 is easier than x.211=y.84 - if you know what I mean..

>Then, do we configure the boxes to listen for that IP or the 192.168.1.211,.212,etc, or do we just let it listen to the actual IP bound to it?
the boxes listen to the actual IP assigned to it... most servers will listen to "all assigned IP addresses"

>And do we need our ISP to do anything in addition?
Your ISP needs to do nothing else at this point.
0
 
HighSecuredAuthor Commented:
Okay, so finally to confirm, everything that we need to do to get up and running is:

// Sets the firewall's IP address as 64.116.184.210, subnet *.240.
  ip address outside 64.116.184.210 255.255.255.240

// Routes pub.211 --> priv.211, and similarly for *.212, *.213.
  static (inside,outside) 64.116.184.211 192.168.1.211 netmask 255.255.255.255
  static (inside,outside) 64.116.184.212 192.168.1.212 netmask 255.255.255.255
  static (inside,outside) 64.116.184.213 192.168.1.213 netmask 255.255.255.255
 (and so forth for each extra box)

  ip audit name attack1 attack action alarm reset
  ip audit name info1 info action alarm
  ip audit interface outside info1
  ip audit interface outside attack1
  ip audit info action alarm
  ip audit attack action reset


Allow ports in for only .211 on stmp, http+s, ssh, and 1234 (arbitrary port)
   access-list outside_in permit tcp any host 64.116.184.211 eq smtp
   access-list outside_in permit tcp any host 64.116.184.211 eq http
   access-list outside_in permit tcp any host 64.116.184.211 eq https
   access-list outside_in permit tcp any host 64.116.184.211 eq ssh
   access-list outside_in permit tcp any host 64.116.184.211 eq 1234

// Permit anything to push through to 212, for example.
   access-list outside_in permit ip any  host 64.116.184.212

   access-group outside_in in interface outside


And then bind 192.168.1.(box) on each given box.

Did I miss/screw up/ misunderstand anything?
0
 
lrmooreCommented:
That's about all there is to it, except for the default route:

   route outside 0.0.0.0 0.0.0.0 64.116.184.209 1

0
 
HighSecuredAuthor Commented:
Awesome... thanks a billion.  It seems to be working as of now =)

You're a god, as always :P

Cheers :)
0

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 6
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now