So putting aside the arguments, one of the issues with blocking outgoing connections based on IP has always failed (imagine the cloud of servers, if you were to block say yahoo mail). Now the Modular Policy Framework does support regex checking in the URL header to see which site it is going and block it, if you’d like to.

Here is the Cisco article describing the MPF in details {Here}

Now how do you block say access to facebook or myspace, from being utilized by your employees?? Pete has a good write-up on it and hence I’m not going to write it again here.

In short the configuration you need is; Thanks to Pete for providing such a detailed write-up.

On the Global Policy
————————————————-

regex domainlist1 "facebook.com"
class-map type regex match-any DomainBlockList 
  match regex domainlist1 
class-map type inspect http match-all BlockDomainsClass
  match request header host regex class DomainBlockList
policy-map type inspect http http_inspection_policy 
class BlockDomainsClass
  reset log
policy-map global_policy
  class inspection_default
  inspect http http_inspection_policy
service-policy global_policy global
———————————————-

With its own policy

———————————————–
regex BLOCKED_DOMAIN_1 "www.facebook.com"
access-list TRAFFIC_TO_INSPECT_FOR_BLOCKED_DOMAINS extended permit tcp any any eq http
class-map type regex match-any CLASS_MAP_BLOCKED_DOMAIN_LIST
  match regex BLOCKED_DOMAIN_1
class-map type inspect http match-all CLASS_MAP_DEFINE_TRAFFIC_TO_INSPECT
  match request header host regex class CLASS_MAP_BLOCKED_DOMAIN_LIST
class-map CLASS_MAP_HTTP_TRAFFIC
  match access-list TRAFFIC_TO_INSPECT_FOR_BLOCKED_DOMAINS
policy-map type inspect http POLICY_MAP_HTTP_INSPECTION
  parameters
  class CLASS_MAP_DEFINE_TRAFFIC_TO_INSPECT
  drop-connection log
policy-map POLICY_MAP_OUTSIDE_INTERFACE
class CLASS_MAP_HTTP_TRAFFIC
  inspect http POLICY_MAP_HTTP_INSPECTION
service-policy POLICY_MAP_OUTSIDE_INTERFACE interface outside

   1: static (inside,outside) tcp 1.1.1.2 www 10.10.10.2 www 255.255.255.255

   2: static (inside,outside) tcp 1.1.1.2 smtp 10.10.10.3 smtp 255.255.255.255

   3: static (inside,outside) tcp 1.1.1.2 domain 10.10.10.4 domain 255.255.255.255

   4: static (inside,outside) udp 1.1.1.2 domain 1010.10.4 domain 255.255.255.255

It could be either the IP address on the outside interface or an available public IP address as well. Now the problem here is, how do you allow ping to these servers.

The first line; maps HTTP traffic coming over to 1.1.1.2 and redirects to 10.10.10.2 on the inside LAN machine. Now, if I want to allow PING to work for the server 10.10.10.2 from anybody in the Internet, how do I do that?

I’m afraid the answer is ‘You Can’t’ The reason being, there is no 1-1 mapping

Normal Scenario’s where you can do this is, if you do a Static NAT instead of Static PAT as below;

   1: static (inside,outside) 1.1.1.2 10.10.10.4 255.255.255.255

   2:  

   3: access-list Outside-In permit tcp any host 1.1.1.2 eq HTTP

   4: access-list Outside-In permit icmp any host 1.1.1.2 echo

   5:  

   6: access-group Outside-In in interface outside

If you guys know that it can be done in any other way, lemme know as well

hostname(config)# nat(inside) 1 0.0.0.0 0.0.0.0
hostname(config)# global (outside) 1 interface

This tells the firewall that all traffic coming from inside (local lan) interface should be PAT’ed and route before it goes out through the outside (like internet). Now you can also define this with an access-list for much filtered Natting. Say; you have 2 networks in your local lan and want only one of them to be Pat’ed like above;

We call it, 10.0.0.0/8 and 192.168.1.0/24 and only the second one should be natted; This is achieved through the following statements;

hostname(config)# nat (inside) 1 192.168.1.0 255.255.255.0
hostname(config)# global (outside) 1 interface

Similarly, you can use an access-list for much controlled Natting like below;

hostname(config)# nat (inside) 1 access-list 10
hostname(config)# global (outside) 1 interface
access-list 10 permit ip 192.168.1.0 255.255.255.0

The beauty is, you can even control this Natting using specific protocols/ports combination. Say, if you want to allow only internet browsing (http & https) to be allowed, then;

hostname(config)# nat (inside) 1 access-list 100
hostname(config)# global (outside) 1 interface
access-list 100 permit tcp 192.168.1.0 255.255.255.0 any eq 80
access-list 100 permit tcp 192.168.1.0 255.255.255.0 any eq 443

See an advantage here? You can avoid having a separate access-list to be inserted for this purpose on the outside interface. Now, there is another way where you don’t want to nat, achieved through nat(inside)0. Typically this is used for VPN connections. When you have VPN terminated onto ASA/PIX, You won’t be Natting the traffic going through that and you achieve it by adding;

nat(inside)0 access-list 10
access-list 10 permit 10.0.0.0 255.0.0.0

OR

nat(inside)0 10.0.0.0 255.0.0.0

However there is a difference with nat (inside) 0 statements, you cannot control the NAT functionality based on protocols/ports, it is only IP. For example;

nat (inside) 0 access-list 100
access-list 100 permit tcp 192.168.1.0 255.255.255.0 any eq 80

The above will not work. This is the limitation and you’d have to go for regular access-lists on your interfaces if you want to stop these traffic.

In Cisco’s own words;

On ASA, the policy nat cannot be applied on nat(0) statements and is not supported;

Identifies the local addresses and destination addresses using an extended access list, also known as policy NAT. Create the access list using the access-list command. You can optionally specify the local and destination ports in the access list using the eq operator. If the NAT ID is 0, then the access list specifies addresses that are exempt from NAT. NAT exemption is not the same as policy NAT; you cannot specify the port addresses, for example.
Note      Access list hit counts, as shown by the show access-list command, do not increment for NAT exemption access lists.

Source : { Here }

If you don’t know especially if you’re a newbie with Cisco Routers, one of the annoying thing is the message;

Translating….. domain server (255.255.255.255)

Well, it is there for a reason and is doing something that may not be obvious. So here is the deal in Cisco’s own words;

By default, when a command in user or enable mode is entered into a router and this command is not recognized, the router believes that this is the host name of a device that the user is attempting to reach using telnet. Therefore, the router tries to resolve the unrecognized command into an IP address by doing an IP domain lookup. If no specific domain server has been configured on the router, the router will issue a broadcast for the command to be translated into an IP address. It can take several seconds for the router prompt to return while the router waits for a response to its Domain Name System (DNS) broadcast.

Simple fix?

Just add ‘no ip domain-lookup’ and save it. It should be gone!

Source : [ Cisco Online Doc ]

Lan connected to an Cisco router which has 2 ISP connections. The main one is terminated on serial0/0 and another aDSL link at serial0/1. The internal lan is connected to Fe0/1

There are other complexities of VPN and stuff, lets leave that aside. So basic requirement as to route all the traffic through serial0/0 => means the default route on the router would be pointing to serial0/0 and the user wanted all the internet web browsing traffic to go over the aDSL link and save link space on the main link. Something like this is always good to have and actually we can have this done based on policy based routing and include even fault-tolerance by having the aDSL link as backup link in case the main link goes down.

   1: default route & default route with higher metric, so it gets inserted to routing table 

   2: in case the first one goes down.

   3:  

   4: ip route 0.0.0.0 0.0.0.0 serial0/0 

   5: ip route 0.0.0.0 0.0.0.0 serial0/1 10 

   6:  

   7: The above helps in backup-route. 

   8:  

   9: The following route-map decides if the traffic is web browsing and if so then sends

  10: packet out through aDSL link, otherwise traffic goes through the main link.

  11:  

  12: route-map webtraffic permit 10

  13:   match ip address 200

  14:   set ip next-hop <aDSL Interface remote side ip>

  15:  

  16: access-list 200 permit tcp <Internal Network> <Wildcard Mask> any eq 80

  17: access-list 200 permit tcp <Internal Network> <Wildcard Mask> any eq 443

  18:  

  19: It is assigned to the interface, so that it can be evaluated at the entry level in

  20: local lan which is connected to Fe0/1

  21: int Fe0/1

  22: ip policy route-map webtraffic 

So you can put a cisco router in bridge mode this way;

bridge 1 protocol ieee

int fa0/0   <–connected to ISP (change interface accordingly)
no ip address
bridge-group 1

int fa0/1  <–connected to ASA (change interface accordingly)
no ip address
bridge-group 1

It is nice to use the RDP to be on a different port for security purposes. If a firewall scanner finds out that port 3389 is allowed then it is pretty obvious that it is an RDP hole in the firewall punched in.

So how about port 12345 ?

2 options;

1. Change the port on the windows itself to custom port.

  Lets assume you want it on port 12345, This case you change it to;

static (inside,outside) <Public_IP> <Private_IP>netmask 255.255.255.255
access-list 102 permit tcp any host <Public_IP>eq 12345
access-group 102 in interface outside

http://support.microsoft.com/kb/306759

The link above would show you how to change the port in windows.

2. Change the port on the static nat statement so that you connect to a random port but pix would route it to default  rdp port.

static (inside,outside) tcp <Public_IP> 12345 <Private_IP>3389 netmask 255.255.255.255
access-list 102 permit tcp any host <Public_IP>eq 12345
access-group 102 in interface outside

Then launch Remote Desktop Client and then type in address as <Public_IP>:12345  Kewl…

Read More …

Now that I answered the same question twice @ EE, it would be better that I bookmark it for the sake of others here;

So, the question is when it comes to a platform with Cisco to be a Firewall, do we use Cisco Router or Cisco PIX Firewall ? Both has a lot of similar feature set and the argument of using router as firewall instead of shelling more money on PIX/ASA ?

PIX (Packet Internet Exchange)

These are the firewall series from Cisco Networks (Now moving towards ASA). It is a hybrid firewall with capabilities of stateful firewall, Application proxy etc. The way it works is known as ASA (Adaptive Security Algorithm). This gear is specifically meant for doing firewall functions to much higher level

http://www.examcram2.com/articles/article.asp?p=101741&seqNum=4&rl=1

Cisco Routers

These are general routing engine which is made with different types of interfaces supporting routing in big scale. For example, pix can support only primitive level of routing but Cisco Routers can run almost all routing protocols that are available now. Now if you ask whether the firewall functionalities can be done by these routers? YES. Special image needs to be used and a Cisco Router can work as a vpn endpoint and a firewall. This is called CBAC (Context Based Access Control)

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scprt3/scdcbac.htm#wp1000981

So what is the difference. The numbers of throughput, while Routers are meant to have different idea the PIX is made only for the firewall functions. So firewall related outputs (VPN, Encryption speed etc..) are high in the PIX.

If VPN is only what you’re looking at then probably a Cisco Router would do, but *encryption speeds* matter, with PIX/ASA it would be much faster.

As well, application awareness is more in PIX/ASA than a normal Router. You could turn a router into a firewall but it is good only for layer 3 and layer 4 traffic to a major extent, while ASA or PIX would do more that that.

So when you say control ICMP on a pix firewall, it is 2 fold.

1. Control icmp traffic through pix firewall
2. Control icmp traffic that is *destined* for pix firewall, whether internal or extern

For the first one, it is easy and control it using access-lists.

For the second, you use the command ’icmp’;

icmp permit/deny <source> <icmp-type> <interface>

if I say ’icmp permit host 172.16.1.1 echo-reply inside’ => What it tells the pix is that allow to send echo-reply msgs to the

host 172.16.1.1 from inside network.

For a detailed explanation of icmp-types, look at Cisco Site.

So to be perfect in saying ’access rules for ICMP traffic that terminates at a security appliance interface use icmp commands.

Cisco Router :

ip nat inside source static <protocol> <InternalIP> <Port> <PublicIP> <Port>

access-list <Number> permit tcp any host <PublicIP> eq <Port>

int <Internal>
ip nat inside

int <External>
ip nat outside
ip access-group <Number> in

So using the above if I want to allow web server access, the configuration would be as below; Assuming Public IP = 11.12.13.14 and Private IP = 10.10.10.10, Internal Interface = Ethernet0/0, External Interface = Serial0/0

ip nat inside source static tcp 10.10.10.10 80 11.12.13.14 80

access-list 100 permit tcp any host 11.12.13.14 eq 80

int e0/0
ip nat inside

int s0/0
ip nat outside
ip access-group 100 in

Cisco PIX Firewall :

static (inside,outside) <PublicIP> <Private IP> netmask 255.255.255.255

access-list <Name> permit <Protocol> any host <PublicIP> eq <service>

access-group <Name> in interface outside

So using the above if I want to allow web server access, the configuration would be as below; Assuming Public IP = 11.12.13.14 and Private IP = 10.10.10.10

static (inside,outside) 11.12.13.14 10.10.10.10 netmask 255.255.255.255

access-list Outside_In permit tcp any host 11.12.13.14 eq 80

access-group Outside_In in interface outside

No comments

Say for example if my SubnetA has an ip of 10.10.10.0/24, SubnetB has an ip of 10.10.20.0/24 and I have 2 public ip addresses (PublicIPA, PublicIPB), I could do the patting for each individual networks. This gives the granularity of auditing based on exit public ip address. So here is what I think can be done.

If this is done on PIX Firewall:

global (outside) 1 PublicIPA
nat (inside) 1 10.10.10.0 255.255.255.0

global (outside) 1 PublicIPB
nat (inside) 1 10.10.20.0 255.255.255.0

If this has to be done on a Cisco Router:

ip nat pool SubnetA PublicIPA PublicIPA netmask 255.255.255.255

ip nat inside source list 1 pool SubnetA overload

access-list 1 permit ip 10.10.10.0 0.0.0.255

ip nat pool SubnetB PublicIPB PublicIPB netmask 255.255.255.255

ip nat inside source list 2 pool SubnetB overload

access-list 2 permit ip 10.10.20.0 0.0.0.255

int <Internal_Int>

ip nat inside

int <External_Int>

ip nat outside

Cool.

Above includes the various p2p blocking using PIX firewall, one of the hottest and greediest on your networks  

StartMenu->Programs->Cisco VPN Client->SetMTU

So it is a peaceful life and don’t have go through the GUid in registry finding out which adaptor you want to set it

Oh yEAH! Using CVPN Client on Microsoft XP ? Don’t forget to get the latest version, 4.8 which is the stable one and you can download it from Cisco Site.

Internal—–PIX1–Outside———-Outside–PIX2—–Internal

With all configuration options as mentioned at cisco site (Click here to Cisco config sample for this), the tunnel still doesn’t come up!!! A point where I started scratching my head Then one of my friend at Experts-Exchange came along and said like ‘even though the outside interfaces are connected directly, still you need to have a default route (or route) configured on the PIX to have this get it working’. It was great and was right above all.

Check out the link to see the whole discussion at the forum;

http://www.experts-exchange.com/Security/Q_21934020.html

Consider this network;

10.1.1.1——–(10.1.1.2)Router(100.100.100.100)—-(100.100.100.101)(PIX)(200.200.200.200)—–InternetIP

Trace route will list;

10.1.1.2

100.100.100.101

InternetIP

The PIX interfaces will not be listed in it, either the trace route in ‘inbound’ or ‘outbound’! This is by design until 6.3(5) and in 7.0 version, you have an option of choose to disable natting. Once that is done, PIX acts as a router and the interfaces will be displayed.

[Click to redirect to article @ Cisco] 

1. The hostname is different

2. The ip address will be private and won’t resolve to http://www.domain.com

In such situations, one of the ways you can make it possible would be something called DNS Doctoring…

Letz take an example;

The internal ip address of the webserver : 10.1.1.1

The Host Name of the webserver : mywebserver

Public Name of the webserver : www.domain.com

So in the PIX firewall, you make the following configuration;

Let the PIX know that you are trying to reach the internal machine by modifying the following static NAT;

static (Inside,Outside) x.x.x.x 10.1.1.1 netmask 255.255.255.255

(The above statement tells pix that any request coming to the ip address x.x.x.x should be natted to 10.1.1.1)

Change the above to;

static (Inside,Outside) tcp x.x.x.x www 10.1.1.1 www DNS netmask 255.255.255.255

                                                                             ^^^

(Watch the ‘DNS’ keyword in the modifed ‘static’ statement. This tells the pix that DNS resolution also should be taken care).

From now onwards any internal user can also browse the website using http://www.domain.com What makes this possible is that, PIX intelligently resolves it for you! Kinda cool huh ??

How else can this be done ?

Add an ‘A’ record in the internal DNS server as www (assuming that your domain name is also domain.com) pointing to 10.1.1.1
                                                                                        

1. Create 2 groups (Group1 and Group2)

2. Create 2 pools (Pool1 and Pool2)

Put “THE” user in Group1 and have Pool1 be assigned to him. Configure in such a way that Pool1 has only one ip address.

Put all the other users into the second group and configure Pool2 be assigned to them with regular pool. Comes very handy for administrators…