With the inbound filtering configure it is time for filtering the DMZ’s. The focus of the 4th part of the series will be configuring the ACL’s for the customer DMZ.
The perimeter architecture consists of two DMZ’s. The first DMZ is called “Service” DMZ, the second is called “customer”. The customer DMZ consists of systems used by Widgets to interact with Widgets customers, these systems include the web site, online shopping and online support database.
When configuring network access its’ important to ensure exposing only required ports. Because there are requirements for two DMZ’s we must create two ACL’s. To create the customer DMZ ACL we must identify we systems, their IP addresses and the required ports for the customer DMZ.
Listed below are the requirements for the customer DMZ:
Widgets Website – 5.2.3.80 (192.168.1.80) [tcp/80]
Widgets Extranet Website – 5.2.3.143 (192.168.1.143) [tcp/80 & tcp/443]
Widgets Online Database – 5.2.3.44 (192.168.1.44) [tcp/80 & tcp/443]
Widgets 3rd Party Online Database Support Applications – 5.2.3.250 (192.168.1.250) [tcp/12345, tcp/23456, & tcp/34567]
With requirements defined its time to create the access-list. Since this is the ACL for the customer DMZ the ACL name will be customer_access_in. Because traffic will be responding to the request we must ensure that we permit traffic from our DMZ host back to the original request. Here is how the ACL will be configured:
access-list customer_access_in permit tcp any 192.168.1.80 eq 80
access-list customer_access_in permit tcp 192.168.1.80 eq 80 any
access-list customer_access_in permit tcp any 192.168.1.143 eq 80
access-list customer_access_in permit tcp 192.168.1.143 eq 80 any
access-list customer_access_in permit tcp any 192.168.1.143 eq 443
access-list customer_access_in permit tcp 192.168.1.143 eq 443 any
access-list customer_access_in permit tcp any 192.168.1.44 eq 80
access-list customer_access_in permit tcp 192.168.1.44 eq 80 any
access-list customer_access_in permit tcp any 192.168.1.44 eq 443
access-list customer_access_in permit tcp 192.168.1.44 eq 443 any
access-list customer_access_in permit tcp any 192.168.1.44 eq 12345
access-list customer_access_in permit tcp 192.168.1.44 eq 12345 any
access-list customer_access_in permit tcp any 192.168.1.44 eq 23456
access-list customer_access_in permit tcp 192.168.1.44 eq 23456 any
access-list customer_access_in permit tcp any 192.168.1.44 eq 34567
access-list customer_access_in permit tcp 192.168.1.44 eq 34567 any
access-list customer_access_in deny ip any any
With the customer DMZ ACL built it must be applied. Cisco ASA firewall ACL’s are not applied to an interface so to bind the customer ACL we type the following commands:
asa(config)#access-group customer_access_in in interface dmz1
The customer DMZ is should not be accessible from the Internet! The next article will focus on the service DMZ.
Until next time.........
Showing posts with label filtering. Show all posts
Showing posts with label filtering. Show all posts
Monday, June 28, 2010
Thursday, June 10, 2010
Internet Network Filtering Part 3
After configuring filtering on the border router, it is time to perform filtering on the firewall. I believe in one rule for inbound Internet traffic to the firewall, only allow what is REQUIRED for the organizations business to function. For the purpose of this article the following services are required for the organization to function:
Widgets Website - 5.2.3.80 [tcp/80]
Widgets Extarnet Site - 5.2.3.143 [tcp/80 & tcp/443]
Widgets Online Database - 5.2.3.44[tcp/80 & tcp/443]
Widgets Email Server - 5.1.2.25 [tcp/25]
Widgets DNS - 5.1.2.53 [udp/53]
Widgets DNS - 5.1.2.54 [udp/53]
Widgets VPN - 5.1.2.123 [udp/500 & udp/4500]
Widgets SSL VPN - 5.1.2.43 [tcp/80 & tcp/443]
Widgets 3rd party Online Database Support - 5.2.3.250 [tcp/12345, tcp/23456 & tcp/34567]
Widgets perimeter network is protected with a Cisco ASA firewall. The firewall has an outside interface(outside), customer DMZ interface (DMZ1), service DMZ interface (DMZ2), and an inside interface(inside).
Because ASA's uses the concept of security levels each interface must be assigned one. For more information understanding the ASA security level concept please visit the Cisco website.
The IP address of servers in the DMZ use the RFC 1918 192.168.1.0/24 and 192.168.2.0/24 addresses. The use of these address require address translation to be performed. For more information on understanding and configuration a Cisco ASA for address translation please visit the Cisco website.
To configure access list for the required service we must use this command syntax:
access-list NAME action protocol source destination service
For detailed information for ASA access-list configuration please visit the Cisco website.
When configuring an ACL unless there is a legitimate business case I always take a default deny stance. When ordering an ACL I prefer to place entries that will hit more often at the top of the ACL.
Using the requirements listed above we will create an ACL named outside_access_in.
access-list outside_access_in permit udp any 5.1.2.53 eq 53
access-list outside_access_in permit udp any 5.1.2.54 eq 53
access-list outside_access_in permit tcp any 5.2.3.80 eq 80
access-list outside_access_in permit tcp any 5.2.3.44 eq 443
access-list outside_access_in permit tcp any 5.2.3.44 eq 80
access-list outside_access_in permit tcp any 5.2.3.143 eq 443
access-list outside_access_in permit tcp any 5.2.3.143 eq 80
access-list outside_access_in permit tcp any 5.1.2.25 eq 25
access-list outside_access_in permit udp any 5.1.2.123 eq 500
access-list outside_access_in permit udp any 5.1.2.123 eq 4500
access-list outside_access_in permit tcp any 5.1.2.43 eq 80
access-list outside_access_in permit tcp any 5.1.2.43 eq 443
access-list outside_access_in permit tcp any 5.2.3.250 eq 12345
access-list outside_access_in permit tcp any 5.2.3.250 eq 23456
access-list outside_access_in permit tcp any 5.2.3.250 eq 34567
access-list oustide_access_in deny ip any any
If a syslog server with sufficient disk space is available I prefer to log every Access Control Entry (ACE). After logging all my ACE's if there additional space on the syslog server I will add this last entry:
access-list outside_access_in deny ip any any log
When logging every hit on the ACL you will have a great understanding of your network. However this type of logging can be very storage expensive. If storage space becomes an issue, I always keep logging on my permits.
With the ACL built it must be applied to the outside interface of the ASA firewall. Unlike Cisco IOS it is not applied in the interface configuration. To bind the ACL to the outside interface we must enter in the following commands:
asa(config)#access-group outside_access_in in interface outside
With the ACL's and NAT setup (check out the Cisco website for more information) you must next permit traffic to the physical servers in the DMZ. The next article in this series will describe creating the ACL in the DMZ.
Widgets Website - 5.2.3.80 [tcp/80]
Widgets Extarnet Site - 5.2.3.143 [tcp/80 & tcp/443]
Widgets Online Database - 5.2.3.44[tcp/80 & tcp/443]
Widgets Email Server - 5.1.2.25 [tcp/25]
Widgets DNS - 5.1.2.53 [udp/53]
Widgets DNS - 5.1.2.54 [udp/53]
Widgets VPN - 5.1.2.123 [udp/500 & udp/4500]
Widgets SSL VPN - 5.1.2.43 [tcp/80 & tcp/443]
Widgets 3rd party Online Database Support - 5.2.3.250 [tcp/12345, tcp/23456 & tcp/34567]
Widgets perimeter network is protected with a Cisco ASA firewall. The firewall has an outside interface(outside), customer DMZ interface (DMZ1), service DMZ interface (DMZ2), and an inside interface(inside).
Because ASA's uses the concept of security levels each interface must be assigned one. For more information understanding the ASA security level concept please visit the Cisco website.
The IP address of servers in the DMZ use the RFC 1918 192.168.1.0/24 and 192.168.2.0/24 addresses. The use of these address require address translation to be performed. For more information on understanding and configuration a Cisco ASA for address translation please visit the Cisco website.
To configure access list for the required service we must use this command syntax:
access-list NAME action protocol source destination service
For detailed information for ASA access-list configuration please visit the Cisco website.
When configuring an ACL unless there is a legitimate business case I always take a default deny stance. When ordering an ACL I prefer to place entries that will hit more often at the top of the ACL.
Using the requirements listed above we will create an ACL named outside_access_in.
access-list outside_access_in permit udp any 5.1.2.53 eq 53
access-list outside_access_in permit udp any 5.1.2.54 eq 53
access-list outside_access_in permit tcp any 5.2.3.80 eq 80
access-list outside_access_in permit tcp any 5.2.3.44 eq 443
access-list outside_access_in permit tcp any 5.2.3.44 eq 80
access-list outside_access_in permit tcp any 5.2.3.143 eq 443
access-list outside_access_in permit tcp any 5.2.3.143 eq 80
access-list outside_access_in permit tcp any 5.1.2.25 eq 25
access-list outside_access_in permit udp any 5.1.2.123 eq 500
access-list outside_access_in permit udp any 5.1.2.123 eq 4500
access-list outside_access_in permit tcp any 5.1.2.43 eq 80
access-list outside_access_in permit tcp any 5.1.2.43 eq 443
access-list outside_access_in permit tcp any 5.2.3.250 eq 12345
access-list outside_access_in permit tcp any 5.2.3.250 eq 23456
access-list outside_access_in permit tcp any 5.2.3.250 eq 34567
access-list oustide_access_in deny ip any any
If a syslog server with sufficient disk space is available I prefer to log every Access Control Entry (ACE). After logging all my ACE's if there additional space on the syslog server I will add this last entry:
access-list outside_access_in deny ip any any log
When logging every hit on the ACL you will have a great understanding of your network. However this type of logging can be very storage expensive. If storage space becomes an issue, I always keep logging on my permits.
With the ACL built it must be applied to the outside interface of the ASA firewall. Unlike Cisco IOS it is not applied in the interface configuration. To bind the ACL to the outside interface we must enter in the following commands:
asa(config)#access-group outside_access_in in interface outside
With the ACL's and NAT setup (check out the Cisco website for more information) you must next permit traffic to the physical servers in the DMZ. The next article in this series will describe creating the ACL in the DMZ.
Monday, March 29, 2010
Internet Network Filtering Part 2
The first part of this series covered ingress filtering on your organizations Internet router. The goal of ingress filtering was to filter illegitimate traffic hitting your firewall. The next part of this series will cover egress filtering on the Internet router.
Egress filtering is filtering traffic leaving an organizations network. For a more in-depth explanation of egress filtering please read the paper I authored titled Performing Egress Filtering.
To review the organization Internet architecture consists of the following equipment.
One Cisco IOS router
Serial (s0/0) Interface connecting a T-1 to the Internet
Ethernet (e0/0) Interface connecting to firewall outside interface
One Cisco ASA firewall
The first step implementing egress filtering is to determine all Internet connections into your organizations network. Create a list with each location and all address ranges in that location. In some organizations their Internet connection may consist of multiple address ranges and/or ISPs.
For these articles the IP address range assigned by our fake ISP is 5.1.2.0/24 and 5.2.3.0/24. These ranges are currently not allocated and are for demonstration purposes only.
As with the ingress filter, extended ACL’s are used for the egress filters. To create the ACL type these commands in:
Inetrt01(config)#access-list 101 permit ip 5.1.2.0 0.0.0.255 any
Inetrt01(config)#access-list 101 permit ip 5.2.3.0 0.0.0.255 any
Inetrt01(config)#access-list 101 permit ip any 5.1.2.0 0.0.0.255
Inetrt01(config)#access-list 101 permit ip any 5.2.3.0 0.0.0.255
Inetrt01(config)#access-list 101 deny ip any any log
The first two permit access control entries (ACE) allow traffic sourced from our public address space to access the Internet through the Internet router. The next two permitted ACE’s allow traffic on the Internet to access resources in the IP ranges of 5.1.2.0/24 and 5.2.3.0/24. The final ACE is used to identify systems using source address other than the ones assigned to our organization. Any system that hits on the deny ACE must be investigated. The two likely causes of the hits could be mis-configured or infected with malware.
To maintain direction consistency, easier management, and better system performance the ACL will be applied inbound on the Ethernet interface. Use the following commands to apply the ACL to e0/0
Inetrtr01(config)#interface e0/0
Inetrtr01(config-if)#ip access-group 101 in
Two test must be performed to ensure the egress filtering is working correctly. First make a connection to a website such as www.google.com. Review the ACL and hits should appear on your source range and traffic bound for your source range. Next make a connection to www.google.com, this time send traffic with a spoofed IP address of 1.1.1.1. Review the ACL and hits should appear on the deny statement. If you see other hits on this ACE you should investigate these hits.
Congratulations you have now successfully implemented egress filtering on your edge router. Next time I will start on filtering on the firewall.
Egress filtering is filtering traffic leaving an organizations network. For a more in-depth explanation of egress filtering please read the paper I authored titled Performing Egress Filtering.
To review the organization Internet architecture consists of the following equipment.
One Cisco IOS router
Serial (s0/0) Interface connecting a T-1 to the Internet
Ethernet (e0/0) Interface connecting to firewall outside interface
One Cisco ASA firewall
The first step implementing egress filtering is to determine all Internet connections into your organizations network. Create a list with each location and all address ranges in that location. In some organizations their Internet connection may consist of multiple address ranges and/or ISPs.
For these articles the IP address range assigned by our fake ISP is 5.1.2.0/24 and 5.2.3.0/24. These ranges are currently not allocated and are for demonstration purposes only.
As with the ingress filter, extended ACL’s are used for the egress filters. To create the ACL type these commands in:
Inetrt01(config)#access-list 101 permit ip 5.1.2.0 0.0.0.255 any
Inetrt01(config)#access-list 101 permit ip 5.2.3.0 0.0.0.255 any
Inetrt01(config)#access-list 101 permit ip any 5.1.2.0 0.0.0.255
Inetrt01(config)#access-list 101 permit ip any 5.2.3.0 0.0.0.255
Inetrt01(config)#access-list 101 deny ip any any log
The first two permit access control entries (ACE) allow traffic sourced from our public address space to access the Internet through the Internet router. The next two permitted ACE’s allow traffic on the Internet to access resources in the IP ranges of 5.1.2.0/24 and 5.2.3.0/24. The final ACE is used to identify systems using source address other than the ones assigned to our organization. Any system that hits on the deny ACE must be investigated. The two likely causes of the hits could be mis-configured or infected with malware.
To maintain direction consistency, easier management, and better system performance the ACL will be applied inbound on the Ethernet interface. Use the following commands to apply the ACL to e0/0
Inetrtr01(config)#interface e0/0
Inetrtr01(config-if)#ip access-group 101 in
Two test must be performed to ensure the egress filtering is working correctly. First make a connection to a website such as www.google.com. Review the ACL and hits should appear on your source range and traffic bound for your source range. Next make a connection to www.google.com, this time send traffic with a spoofed IP address of 1.1.1.1. Review the ACL and hits should appear on the deny statement. If you see other hits on this ACE you should investigate these hits.
Congratulations you have now successfully implemented egress filtering on your edge router. Next time I will start on filtering on the firewall.
Sunday, February 21, 2010
Internet Network Filtering part 1
The architecture for connecting organizations to the Internet typically comes in two flavors. The first architecture consist of a single device, usually a router but sometimes a firewall. The second architecture consist of multiple devices, typically a router and a firewall. No matter what architecture is chosen it is important the proper filtering is implemented. This is the first in a series discussing the implementation of proper filtering for an organizations Internet connection.
For this series of post the organization Internet architecture consist of the following equipment.
One Cisco IOS router
Serial (s0/0) Interface connecting a T-1 to the Internet
Ethernet (e0/0) Interface connecting to firewall outside interface
One Cisco ASA firewall
For a review of network ingress filtering review RFC 2827.
To properly implement ingress filtering begin by determining addresses currently allocated by IANA. To review the current address spaces allocated review the IANA website by following this link:
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
Review the list and note every prefix whose status is either unallocated or reserve. The unallocated status is for prefix's that IANA has not issued. The reserved status is for prefixes reserved for various reasons such as being used in RFC 1918 private address, multicast networks, research networks, etc. These prefixes have no legitimate reason for being routed on the Internet, and if seen entering the organization should be dropped.
With the list of prefix's to be dropped the next step is to build the access control list (ACL). Before building the ACL it is important to understand which traffic direction the list will be applied to.
Since the filtering decision is based only on address space simple IP ACL will be used. To create the ACL type these commands in:
inetrtr01(config)#access-list 10 deny 5.0.0.0 255.0.0.0
inetrtr01(config)#access-list 10 deny 10.0.0.0 255.0.0.0
inetrtr01(config)#access-list 10 deny 14.0.0.0 255.0.0.0
.
input omitted
.
inetrtr01(config)##access-list 10 deny 253.0.0.0 255.0.0.0
inetrtr01(config)#access-list 10 deny 254.0.0.0 255.0.0.0
inetrtr01(config)#access-list 10 deny 255.0.0.0 255.0.0.0
inetrtr01(config)#access-list 10 permit any any
The permit statement allows all traffic from valid prefix's to access the organization resources.
With the ACL built use the following commands to apply the ACL to the s0/0 interface
inetrtr01(config)#interface s0/0
inetrtr01(config-if)#ip access-group 10 in
Now test the ACL by sending traffic to the organization with spoofed source address of 10.0.0.1. After sending this traffic check the ACL and there should be hits on the line for 10.0.0.0/8 network. Once you are happy with the ACL save the configuration.
Congratulations you have now successfully implemented ingress filtering. Now all spoofed traffic from illegal sources will be dropped by the Internet router. Dropping this illegitimate traffic at the router reduces the workload on the firewall.
Next week I will cover egress filtering on the Internet router to ensure no spoofed traffic is leaving the organization.
For this series of post the organization Internet architecture consist of the following equipment.
One Cisco IOS router
Serial (s0/0) Interface connecting a T-1 to the Internet
Ethernet (e0/0) Interface connecting to firewall outside interface
One Cisco ASA firewall
For a review of network ingress filtering review RFC 2827.
To properly implement ingress filtering begin by determining addresses currently allocated by IANA. To review the current address spaces allocated review the IANA website by following this link:
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
Review the list and note every prefix whose status is either unallocated or reserve. The unallocated status is for prefix's that IANA has not issued. The reserved status is for prefixes reserved for various reasons such as being used in RFC 1918 private address, multicast networks, research networks, etc. These prefixes have no legitimate reason for being routed on the Internet, and if seen entering the organization should be dropped.
With the list of prefix's to be dropped the next step is to build the access control list (ACL). Before building the ACL it is important to understand which traffic direction the list will be applied to.
Since the filtering decision is based only on address space simple IP ACL will be used. To create the ACL type these commands in:
inetrtr01(config)#access-list 10 deny 5.0.0.0 255.0.0.0
inetrtr01(config)#access-list 10 deny 10.0.0.0 255.0.0.0
inetrtr01(config)#access-list 10 deny 14.0.0.0 255.0.0.0
.
input omitted
.
inetrtr01(config)##access-list 10 deny 253.0.0.0 255.0.0.0
inetrtr01(config)#access-list 10 deny 254.0.0.0 255.0.0.0
inetrtr01(config)#access-list 10 deny 255.0.0.0 255.0.0.0
inetrtr01(config)#access-list 10 permit any any
The permit statement allows all traffic from valid prefix's to access the organization resources.
With the ACL built use the following commands to apply the ACL to the s0/0 interface
inetrtr01(config)#interface s0/0
inetrtr01(config-if)#ip access-group 10 in
Now test the ACL by sending traffic to the organization with spoofed source address of 10.0.0.1. After sending this traffic check the ACL and there should be hits on the line for 10.0.0.0/8 network. Once you are happy with the ACL save the configuration.
Congratulations you have now successfully implemented ingress filtering. Now all spoofed traffic from illegal sources will be dropped by the Internet router. Dropping this illegitimate traffic at the router reduces the workload on the firewall.
Next week I will cover egress filtering on the Internet router to ensure no spoofed traffic is leaving the organization.
Subscribe to:
Posts (Atom)
