So many times the security of the network devices, or the access into the network is laid out in such a way that should one of those devices fail, the network is down.  In this case, no one even attacked you and you are in a spot where you must route around the failed security device, and with concern for uptime, you may do it in a manner that is far less secure than if you had never had the device in the first place.  Why?  Usually because you are trying to patch the hole quickly, and inadvertently leave a security hole, which, if you had never owned the device, you would have thought through and secured this method of connection.  These holes commonly show up as missing lines in the ACLs due to IP schema changes, or a routing issue that is now bypassing more of your security than you intended.

The solutions are numerous, but when developing a solution there are always the four “P”s that must work together.

Performance – How well will the solution work should there be a failure and how fast can it be implemented and how much will the reduced  performance cost in terms of business.

Probability – How likely is it that there will be a failure of this device given its own internal redundancy

Price – Do I need to explain this one?

So the obvious answer, is that if price weren’t a factor, buy two of everything have two circuits from two providers, bring in power from two power grids, have two cores switches, each with two fibers to redundant distribution layer, to redundant access layer to servers with redundant NICs and vmware to move all of the servers to another diversley geo-located site should this site get destroyed.

More likely you should look at ways to, within a budget, mitigate the consequences of a failure.  Let’s say you have an Inline web filter that is going up to a pair of Cisco ASAs.  Well, your inline web filter is a single point of failure sitting in front of a redundant solution.  So what do you do if you can’t afford another webfilter and need to know that should it fail you can still maintain business.

First – make sure you keep your warranty up on the web filter and have fast replacement.  This doesn’t cost nearly what a second webfilter would, and reduces your performance risk from an outage time perspective.

Second – Design with this in mind.  See if you can use your webfilter a different way.  Maybe as WCCP where should it go down, you can fail open. If you must stay inline, assume it will fail closed (even if it advertises itself differently).  Then plan disaster recovery around that.  In this case you may have two VLANs involved.  One for the inside of the web filter and one for the outside.  The inside VLAN is a routed VLAN on your layer 3 switch.  You are routing to your ASAs directly.  To do this you connect the inside of your web filter to the inside VLAN, and the outside interface to a non routeable VLAN on the layer 3 switch.  You will then connect your ASAs’ inside interfaces to that same outside VLAN.  This forces the traffic through the webfilter and is a very common setup for this scenario.  Should the webfilter go down, you change the VLAN on the ASAs to the inside vlan, and you have internet access again.  You have lost the web filter obviously, but hopefully your performance impact isn’t that great until the replacement unit can arrive.

By doing this you can also ensure that the inside vlan, is secured in a manner that your company policy is congruent with should a failure occur.

Security – More than just ACLs is a post from: Geeknick

Related posts:

1. Should I use Supernets and Secondary Address in my network ? Many network administrators are using secondary addressing and supernets as...

Related posts brought to you by Yet Another Related Posts Plugin.

The two main object groups I use are network and service.

The network object group is where you put subnets and hosts, while the service object group is for protocols and ports.

As a best practice I use specific groups on most installs, they are:

INSIDE_NETWORKS
VPN_NETWORKS
HTTP_SERVERS
HTTPS_SERVERS
SMTP_SERVERS

HTTP_SERVERS, HTTPS_SERVERS and SMTP_SERVERS all would contain their specific hosts.  Using these for access-control you may have a configuration that looks like the following:

object-group network HTTP_SERVERS
  network-object host 1.1.1.1
  network-object host 1.1.1.2

access-list OUTSIDE_IN_ACL permit tcp any object HTTP_SERVERS eq www

This would allow anyone port 80 access to servers with an external address of 1.1.1.1 or 1.1.1.2.

Should I need to add additional web servers in the future, I just create the NAT and add the host to the object group.

If this were written out individually it would look like (you can see this in a “show access-list”):

access-list OUTSIDE_IN_ACL permit tcp any host 1.1.1.1 eq www
access-list OUTSIDE_IN_ACL permit tcp any host 1.1.1.2 eq www

I would follow suite using HTTPS_SERVERS for port tcp 443 and SMTP_SERVERS for tcp port 25 and would have access-list entries for each type.

Should a server need to be in all three, such as an Outlook Web Access server running on a single node exchange environment, you would add this server to each of the three object groups.
Some people react with “why not create an object group with all three ports in it and have one line that allows all the ports?”

My feeling is how often are these three ports mixed?  There are instances where every server that is HTTP is HTTPS as well, and then it may make sense to make a network object group called WEB_SERVERS for all of the hosts and a service for the ports allowed to these servers.  Such a configuration would look like the below:

object-group network WEB_SERVERS
  network-object host 1.1.1.1
  network-object host 1.1.1.2
object-group service WEB_SERVER_POTS
  service-object tcp eq 80
  service-object tcp eq 443

access-list OUTSIDE_IN_ACL permit object WEB_SERVER_PORTS any object WEB_SERVERS

if this were to be broken out it would look like

access-list OUTSIDE_IN_ACL permit tcp any host 1.1.1.1 eq 443
access-list OUTSIDE_IN_ACL permit tcp any host 1.1.1.1 eq 80
access-list OUTSIDE_IN_ACL permit tcp any host 1.1.1.2 eq 443
access-list OUTSIDE_IN_ACL permit tcp any host 1.1.1.2 eq 80

This is great as long as all of your web servers are always both http and https, but if you have some that are https only, then using the broken out model with HTTP_SERVERS and HTTPS_SERVERS is the most secure method.

So how do you use this for ease of NAT and Encryption?  Here is a common scenario:

I have insider users at 10.15.10.0/24 and 10.17.10.0/24 and vpn users attached to my ASA with a range of 10.25.10.0/24 and 10.27.10.0/24.  These wireless users can be either dial-in or lan to lan tunnels, in this case lets use dial-in and discuss LAN to LAN and multiple sites later.  Either way when the internal users want to communicate with them I don’t want their traffic to be NATed, but when the internal users communicate to the internet, I need to NAT them so it will correctly route.  On top of this my dial-in users will use their local internet (split-tunneling) as opposed to tunneling all their internet traffic to the ASA.

In this case I would use my object groups INSIDE_NETWORKS and VPN_NETWORKS extensively to server multiple functions.

So lets talk about the INSIDE_NETWORKS first.  I want to list all of my internal networks here, in this case

Object-group network INSIDE_NETWORKS
network-object 10.15.10.0 255.255.255.0
network-object 10.17.10.0 255.255.255.0

For my VPN networks, same thing using the VPN_NETWORKS group

object-group network VPN_NETWORKS
network-object 10.25.10.0 255.255.255.0
network-object 10.27.10.0 255.255.255.0

Now I have a foundation I can build on.  From here I have many purposes to fill.  Lets start with NAT to the internet.

First thing is to create an access-list that defines the traffic to be NATed.

access-list INSIDE_NAT permit ip object INSIDE_NETWORKS any

Then we need to setup our NAT

nat (inside) 1 access-list INSIDE_NAT
global (outside) 1 interface

In this I allowing only my internal networks to NAT to the outside interface global IP when I go to the internet.  This helps with spoofing addresses, because if I am not NATting it it should not be routable on the internet.  Of course reverse route verify is also a great tool for this.

Next lets look out using these for my split-tunneling on the VPN.  Again the first thing is to create access-list, this will look the same as my NAT access-list, but I will create another just for management purposes.

access-list VPN_SPLIT_TUNNEL permit ip object-group INSIDE_NETWORKS any

I would then use this in my group-policy to split tunnel.

group-policy DEMO internal
group-policy DEMO attributes
  vpn-idle-timeout none
  vpn-tunnel-protocol IPSec
  split-tunnel-policy tunnelspecified
  split-tunnel-network-list value VPN_SPLIT_TUNNEL

Now as I add new objects to the INSIDE_NETWORKS group, they are automatically entered into my split tunnel as well as my NAT (first example).

So that brings us to VPN no nat.  In this case I want to have my real IP addresses show up to my dial-in users, in order to do this I have to bypass the NAT when going only to my VPN users and not when going to the internet.  Again, I start with an access-list.

access-list NO_NAT permit ip object-group INSIDE_NETWORKS object-group VPN_NETWORKS

Then I configure my NAT

nat (inside) 0 access-list NO_NAT

Again, as I add networks to my INSIDE_NETWORKS or new pools and networks to my VPN_NETWORKS the NO_NAT access-list is automatically updated.  I don’t have to update this in multiple places in order for it to take effect in many parts of the ASA configuration.

So now let’s make it a bit more complicated.  I have multiple sites running on an MPLS with Site to Site VPNs and remote access vpns as well.  This is handled with object groups, but with a bit more refinement.

Lets say I have Miami, Alpharetta and Las Vegas locations on an MPLS with the internet all coming from the Alpharetta ASA.  I also have 2 remote sites, New York and Chicago over site to site VPNs terminating on the ASA.  The networks are below.

MPLS Sites:
Miami – 10.64.0.0/16 and 10.65.0.0/16
Alpharetta – 10.32.0.0/16 and 10.33.0.0/16
Las Vegas – 10.96.0.0/16 and 10.97.0.0/16

Remote Sites
New York – 10.128.0.0/16 and 10.129.0.0/16
Chicago – 10.160.0.0/16 and 10.161.0.0/16

My VPN users are at 10.192.1.0/24 and 10.192.2.0/24

In this case I would create the following object groups to manage all of this.
object-group network ALPHARETTA_NETWORKS
network-object 10.32.0.0 255.255.0.0
network-object 10.33.0.0 255.255.0.0
object-group network MIAMI_NETWORKS
network-object 10.64.0.0 255.255.0.0
network-object 10.65.0.0 255.255.0.0
object-group network LAS_VEGAS_NETWORKS
network-object 10.96.0.0 255.255.0.0
network-object 10.97.0.0 255.255.0.0
object-group network NEW_YORK_NETWORKS
network-object 10.128.0.0 255.255.0.0
network-object 10.129.0.0 255.255.0.0
object-group network CHICAGO_NETWORKS
network-object 10.160.0.0 255.255.0.0
network-object 10.161.0.0 255.255.0.0
object-group network REMOTE_VPN_USRES
network-object 10.192.1.0 255.255.255.0
network-object 10.192.2.0 255.255.255.0

You can then nest object groups within each other to come back to your two major network categories from above, VPN_NETWORKS and INSIDE_NETWORKS.

object-group network VPN_NETWORKS
group-object REMOTE_VPN_USERS
group-object CHICAGO_NETWORKS
group-object NEW_YORK_NETWORKS
object-group network INSIDE_NETWORKS
group-object ALPARETTA_NETWORKS
group-object MIAMI_NETWORKS
group-object LAS_VEGAS_NEWORKS

With this setup I can now be very granular on access control as well as VPN tunnel setup.  From an access control standpoint I can control per site the access to a DMZ off the ASA or specific sites using access-lists and the specific object group for that site.  For instance, I can put an access-list on the inside that allows only Miami networks to 10.1.1.1 on the DMZ

access-list INSIDE_IN_ACL permit ip object-group MIAMI_NETWORKS host 10.1.1.1

I can utilize the INSIDE_NETWORKS like I did before for NAT and split tunneling and the VPN_NETWORKS group for no nat along with the INSIDE_NETWORKS again.

For my crypto maps for my site to site VPNs I need to create access-lists for the match commands that determine the specific interesting traffic.  Lets say I want to create an access list for my crypto MAP to New York.  It is one line.

access-list NEW_YORK_CRYPTO permit ip object-group INSIDE_NETWORKS object-group NEW_YORK_NETWORKS

At each remote site I would have similar object groups and access-lists, but switch around a little.  So the New York site, the object-group INSIDE_NETWORKS would only contain the NEW_YORK_NETWORKS object group and the VPN_NETWORKS would contain ALPHARETTA_NETWORKS, MIAMI_NETWORKS and LAS_VEGAS_NETWORKS.

Utilizing Cisco Security Manager and having everything named the same, you can now make single changes to object groups and have your NAT, Crypto MAPs, No NATs and remote users vpn split tunnels updated all at the same time.  If you are doing it by hand, the same script can be applied to all of your remote sites should you add a network in on location, thus reducing total cost of ownership and increasing productivity.

Troubleshooting is also much easier as your access-lists are smaller and if you are using well named object-groups, they are easy to follow.  If you use the command “show run access-list” you only see typed lines of the access-list, so all of the lines that are broken out because of the object group are not seen, making it easier to read your configuration.

An ASA using these best practices is easy to use and far more secure.

Author: Alex Jerrold, Cisco CCIE Security

Posted at Geeknick

Utilizing Object Groups on the ASA is a post from: Geeknick

Related posts:

1. Dropping Traffic in IOS Everyone is familiar with access-lists as a way to drop...

Related posts brought to you by Yet Another Related Posts Plugin.

Network based sensors require that all traffic pass through the appliance. This solution ensures that all traffic is passed through the inspection engine as it enters and leaves the network core. This is an effective way to ensure all traffic gets inspected but the downside to this type of solution is that the appliance must operate at data center speeds of 1Gbps or greater. Often this leads to the appliance potentially becoming a bottleneck. As sensor throughput speed increases, so does the associated cost.
Host based IPS solutions are software that is typically installed on the host that detects unauthorized or unwanted activity. These solutions typically inspect the host machine to determine the use and needs of that machine and then allow policy to be written for the specific machine. Often host based IPS solutions provide additional functionality such as web application firewall, file system integrity and other features.
Below are links to some popular solutions to this growing need.
Cisco IDSM-2
http://www.cisco.com/en/US/prod/collateral/modules/ps2706/ps5058/product_data_sheet0900aecd804b91d7.html
Cisco 4200 series IPS sensors
http://www.cisco.com/en/US/prod/collateral/vpndevc/ps5729/ps5713/ps4077/ps9157/product_data_sheet09186a008014873c_ps4077_Products_Data_Sheet.html
Cisco Security Agent
http://www.cisco.com/en/US/prod/collateral/vpndevc/ps5707/ps5057/data_sheet_c78-458616.html
Trend Micro Deep Security

http://us.trendmicro.com/us/solutions/enterprise/security-solutions/virtualization/deep-security/

Author: Mike Lundy

Posted at Geeknick

Intrusion Prevention for the Core is a post from: Geeknick

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Access lists tend to slow a router down.  The packet has to be matched to an access-list and depending on how well you have your access-list ordered and how long it is, it may be many lines of trying to match before the packet is dropped.  This eats up processor cycles, and by default you have a default deny any, meaning that if you have a 1000 line access-list that ends in an implicit deny, and you have a lot of packets that have to go all the way through, you eat up lots of processor doing this.

Option 1:  Rewrite your access-lists – Setup your access-lists in an order you think they will be most likely matched and denied.  For instance, lets say you have three servers a web server at an IP address of 1.1.1.1 which you want to allow both port 80 and 443 to it, a mail server at 1.1.1.2, to which you allow tcp 25, and an sftp server at 1.1.1.3 that needs port 22 opened up.

If they are built in this order and your access-list grows organically your access-list may look like the following.

ip access-list extended OUTSIDE_IN_ACL
permit tcp any host 1.1.1.1 eq 80
permit tcp any host 1.1.1.1 eq 443
permit tcp any host 1.1.1.2 eq 25
permit tcp any host 1.1.1.3 eq 22

This will work, but there are ways to optimize it.  If your mail server is going to get the bulk of the traffic, followed by your web server and then your sftp server you would want to reconsider the order of the list.  In this example, in order for the packet destined for the mail server on port 25 to get through, your router has to cycle through lines 1 and 2 of your access-list before being allowed through, slowing things down each step of the way.

Also, what if someone is trying to see if you have other websites in your company that are publicly available.  While this access-list would block it, the packet would go through 4 lines of access-list before finally being dropped by the implicit deny any any.  Your new access-list may look like the following.

ip access-list extended OUTSIDE_IN_ACL
permit tcp any host 1.1.1.2 eq 25
deny tcp any any eq 25
permit tcp any host 1.1.1.1 eq 80
deny tcp any any eq 80
permit tcp any host 1.1.1.1 eq 443
deny tcp any any eq 443
permit tcp any host 1.1.1.3 eq 22
deny tcp any any eq 22

It is a bit harder to write and maintain, but will increase performance on your router.

Option 2:  Route to null – This option drops traffic at line speed.  Lets say you want to drop all traffic that goes to a certain ip address for security reasons, for example 2.2.2.2.  Simply add a route

ip route 2.2.2.2 255.255.255.255 null0

This sends all traffic destined for 2.2.2.2 straight down a black hole.  The problem with this, is there is not a counter on how many packets were dropped.

Option 3: Route-Map – This option allows you to match traffic based on a list of criteria and then send it to the null interface.  This is very nice when you want to match based on an header tag, next hop address or packet length or a combination of all of them.  Simply write your route-map and set the next hop to null0.  In this example, if you wanted to tag a packet on your network as it enters, and then make sure that it doesn’t leave your network you could do the following.

to tag the packet based on source address of 3.3.3.3.

!!!!on inbound router!!!!

ip access-list standard SOURCE_ACL
permit host 3.3.3.3

route-map TAG5 permit 10
match ip address SOURCE_ACL
set tag 5

inter fa0/0

ip policy route-map TAG5

!!!on outbound router!!!!

route-map DROP5 permit 10
match tag 5
set interface Null0

inter fa0/0

ip policy route-map DROP5

The problem with this is that does take up processor cylces as well as it is run before the route table.  So it will add some overhead, but gives you the ability to mark your packets on the way in, but no drop them unless they try to leave, which a simple access-list does not have the intelligence to do.

Option 4: class based dropping – Yet another way is to do class based dropping.  This allows you to match on multiple criteria at once and take action.  In this case you want to match all packets that are marked w/ a dscp value of af11, are between 1200 and 1250 in size and are icmp, then drop them.  This is a more common scenario with worms, where you don’t want to match a single criteria as that could give false positives.

class-map match-all MULTIMATCH_CM
match ip dscp af11
match packet length min 1200 max 1250
match protocol icmp

policy-map DROP_PM
class MULTIMATCH_CM
drop

inter fa0/0

service-policy input DROP_PM

All of these can be done in conjunction with one another.  So on the same interface you can have access-lists, policy based routing and service-policies while routing some traffic to null 0.  This gives you a lot of control over your packet dropping strategy throughout your network.  But remember the best policy is always applied at the point closest to the source, this way you don’t have 1 device trying to drop everything.

Author: Alex Jerrold

Posted at Geeknick

Dropping Traffic in IOS is a post from: Geeknick

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Torpig contains multiple information stealing pieces of Malware that scan the infected system for credentials, accounts and passwords as well as potentially allowing attackers full access to the computer. It is also purportedly capable of modifying data on the computer.  In 2009 a team of researchers were able to take control of the botnet for a period of ten days.  During that period, they extracted over 70GB of stolen data.

As these Malware variants continue to morph, the challenge for an organization becomes how to detect machines that have been compromised so that remediation can take place as soon as possible.  Trend Micro has a Threat Management System that can passively detect malware, worms, viruses, trojans and other undesirable network activity.  For more information on this solution go to http://www.adcapnet.com/partners/trend-micro/



Author: Mike Lundy

Posted at Geeknick

Mebroot and Torpig is a post from: Geeknick

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Author: Alex Jerrold

Posted at Geeknick

Anyconnect Essentials Licensing is a post from: Geeknick

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

VPN termination

The ASA offers multiple methods of VPN termination. For remote client access, the ASA supports traditional IPSec clients like Cisco’s VPN client but has added the capability for SSL VPN termination as well. May customers do not realize they are licensed for two concurrent SSL VPN sessions out of the box. SSL VPN offers the client tremendous flexibility for remote access to the business. The ASA can also be used for more traditional site to site VPN termination for connecting remote sites back in to the main site for full interoffice communications.

There is one caveat for SSL licensing customers need to be aware of and that is that the ASA can have only one SSL client license. That means that when a 10 session license is purchased, the customer only has 10 concurrent sessions, not 12 as some people have thought. These sessions are concurrent meaning that you can have more than 10 people with access to the device as long as 10 or fewer are logged in at any point in time.

IPS – Intrusion Prevention

Unlike the PIX firewall that had a limited subset of IPS signatures that it could inspect, an ASA equipped with the correct AIP module provides inline, wire speed inspection of traffic for the full complement of signatures available. This means a customer can be confident that the edge device is inspecting and protecting all traffic entering the organization and provides an excellent first line of defense.

Cisco incents its customers to purchase IPS capabilities as part of a bundle versus adding it after the fact. It is much less expensive for customers to purchase the IPS capabilities up front as opposed to buying the technology after the fact. As a result, customers should budget to add this capability upon initial purchase. This will not only save money, but it will increase the security of the customer environment from day one.

Multiple Firewall Contexts

While many people consider a firewall an edge device, more and more businesses are seeing the need to add additional layers of firewalling within their organization to separate internal users from business critical resources. While this can certainly be done with multiple physical appliances, it can also be done with a single ASA running multiple contexts. Multiple contexts allow customers to in essence run multiple firewalls with different rule sets in one physical appliance. The primary consideration for this type of deployment is to ensure your appliance has the proper throughput for your organization.

Multiple contexts can allow a network administrator to manage the appliance at the edge of the network while allowing the server team to administer the firewall rules for accessing the business critical resources. The multiple contexts allow different logins and configurations for the same physical appliance, maximizing the customer investment in that piece of equipment.

Conclusion

The ASA5500 is a family of robust security appliances that can help businesses secure both their network edge as well as mission critical applications. The device has many functions that can be enabled to provide a full range of features to all organizations. If you would like to learn more about the capabilities of the ASA5500 please contact your Adcap account manager.

Author: Mike Lundy

Posted at Geeknick

Cisco’s Adaptive Security Appliance – More Than Just a Firewall is a post from: Geeknick

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.