Archives for category: Security

IPv4 MTU issues can be hard to spot initially, there is a solution and its called Path MTU Discovery (RFC1191). The RFC describes it as the following “a technique for using the Don’t Fragment (DF) bit in the IP header to dynamically discover the PMTU of a path”

Further to that the RFC states “The basic idea is that a source host initially assumes that the PMTU of a path is the (known) MTU of its first hop, and sends all datagrams on that path with the DF bit set. If any of the datagrams are too large to be forwarded without fragmentation by some router along the path, that router will discard them and return ICMP Destination Unreachable messages with a code meaning “fragmentation needed and DF set” (Type 3, code 4)

The unfortunate issue is that the message that’s sent back doesn’t actually say what the MTU is.

A colleague of mines who is a Windows 7 expert, has reliably informed me that by default Windows 7 has PMTUD enabled.

The important point to focus on is the ICMP unreachable (Type 3, code 4). To put this quite simply, if you don’t receive an ICMP message back with the code for fragmentation needed then, your PC will assume that the MTU is fine and continue to send the packets even though somewhere in the path the packets are potentially being dropped.

There can be a number of reasons for this, including firewalls blocking the message, ICMP unreachable disabled on an interface, a transparent host between 2 endpoints (Often done in service provider networks) that has a lower MTU value.

I recently ran into an issue where IP connectivity between 2 sites looked to be fine, ping, traceroute and SSH were all working, but certain applications and protocols were not, most notably HTTPS.

Below I will explain how to spot this issue.

Take a look at the diagram below, i have deliberately used a transparent device as its most likely what you might see in a L3VPN (MPLS) network. The last mile provider provides a layer 2 path (perhaps a L2TPv3) from CE to PE and the underlying hops are hidden from us.  From the service provider perspective the routers are directly connected.

This is perhaps where an MTU issue has occurred. For this scenario I have reduced it quite significantly for effect.

Capture3

Lets say for example you have a perfectly functioning network where MTU is fine along the path. Initially you can send a ping with 1460bytes and you will get a reply. Lets increase this to something we know is to big (1550bytes). This works great in a perfectly functioning network where you receive an ICMP type 3, you will get the “packet needs to be fragmented but DF set” message.

Capture2

Now lets try that through our network where the MTU is set lower but the sending device doesn’t know about it.

Capture4

At first you think its OK because you can ping along the path and get a reply, you try SSH and it works too. Now lets try to ping with different MTU sizes. Remember your PC doesn’t receive the ICMP message this time, so what happens is you get a “request timed out” message.

Capture5

The reason for that is the packet is being dropped and the ICMP message isn’t being returned. If I ping with an MTU that is lower than the 1000 i get a reply.

Capture6

Now the question, why would HTTPS not work? well in some cases web applications or your client might set the Do Not Fragement bit in the IP header SYN request. This means the packet should not be fragmented, so when we send this on our network with the bad MTU in the path, the packet is dropped and the sending device never receives the ICMP message. It never knows that it has to reduce the MTU value. The packet capture below shows where the DF bit is set.

Capture7

I had a look through the RFC2246 for TLS1.0 and it doesn’t specify that the DF bit should be set. It’s most likely a vendor or O/S specific setting, so your observed results may differ from vendor to vendor.

RH

This blog will cover setting up 2 Cisco ASA firewall’s Active / Standby, so if one of the firewalls has a power issue or hardware failure, the standby firewall will wait a set amount of time before taking over from the failed device and resuming the traffic as if nothing happened. You can use stateful failover to resume IPsec sessions, NAT xlate, TCP, UDP, ARP etc. From version 8.4 routing information is also replicated.

The first thing you should know is you only need to set up 1 individual firewall, so my recommendation would be to get a firewall fully functional with all the configuration necessary, then the secondary firewall only needs a few commands before taking an entire copy of the primary firewall’s config, and becoming a standby firewall.

Before we begin lets take a look at the diagram, I used GNS3 but if you require to do this in real-life you would use crossover cables between the failover interfaces.This diagram depicts a single point of failure as the LAN switch but this is not the point of the blog, You would have more than one switch within your core design.

Active-Standby

We will just use the basic config of the firewall, in my setup i have an IPsec tunnel between my ASA and R3, I used this to confirm that IPsec tunnel failover was working as expected.
You will need to decide beforehand which address space you will use for your failover interfaces, and your standby IP’s must be another useable IP within your primary IP subnet.

On ASA 1 use a console or SSH session and input the following commands. Be sure to use “no shutdown” on any interfaces you decide to use.

interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address 192.168.1.1 255.255.255.0 standby 192.168.1.2
!
interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 172.16.1.1 255.255.255.0 standby 172.16.1.2
!
failover lan interface lan_fail1 gig3
failover interface ip lan_fail1 10.2.2.1 255.255.255.252 standby 10.2.2.2
!
failover link stateful_fail2 gig2
failover interface ip stateful_fail2 10.1.1.1 255.255.255.252 standby 10.1.1.2
!
failover key cisco123
!
failover lan unit primary
!
failover replication http
!
prompt hostname priority state
!
failover

Once that is complete, you can now configure the secondary firewall, you can use the command “clear config all” on the secondary firewall to clear all config before you input the commands below. This is the absolute minimum you require to get the secondary firewall up and running, again be sure to use “no shutdown” on any interfaces you need.

interface gig3
no shutdown
!
failover lan interface lan_fail1 gig3
failover interface ip lan_fail1 10.2.2.1 255.255.255.252 standby 10.2.2.2
!
failover key cisco123
!
failover lan unit secondary
!
failover

After you enter the commands you will see the message “detected and active mate” this will confirm the 2 firewalls can see each other. The firewalls will begin to synchronise their configurations, the primary ASA will send over the configuration to the secondary. You will notice the prompt changes to ASA1/sec/stby# we use the command “prompt hostname priority state” for this purpose, so we can be sure which firewall is which.
The primary firewall prompt will be ASA1/pri/act#.

After this point you only need to make changes to the primary unit and any changes to the configuration and “write memory” you do on the primary will also be replicated to the standby unit.

The command “show failover” will provide you with all the necessary information you require should you need to troubleshoot or confirm your configuration is working as expected.

To manually failover the devices you can use the command “no failover active” on the active firewall or from the standby you can use ” failover active” note that when the primary unit recovers from a failure it does not automatically assume the active role.

You can have the ASA alert you when a failover has taken place by setting up email alerts.

logging mail critical
logging from-address asa1@yourdomain.com
logging recipient-address rh@mydomain.com
smtp-server x.x.x.x

This was one of my favourite blogs to write because the with the Cisco ASA everything just “works”

RH.

A common scenario you might come across is having a device on your network that needs to be restricted. So for example a third party PC that doesn’t meet your security requirements but needs to access a production server.

If your network can support it then you would segment this part of your network with a VLAN then route between them on a layer 3 switch or at the router. So in my example its a layer 3 switch, write the access list then apply it at the VLAN interface either inbound or outbound.

Below is the basic config for VLAN 10, anything in this VLAN will only be able to access the production server at 10.50.5.10 which happens to be on VLAN 20, this would apply to devices or whole subnets on a different switch or even across the WAN. I’ll make this interesting and allow the clients only access on TCP port 80, and also allow the clients to lookup DNS on the same server this is UDP port 53.

ACL_pic

Create your ACL
————————————-
ip access-list extended 100
permit ip any 192.168.1.0 0.0.0.255
permit tcp any host 10.50.5.10 eq www
permit udp any host 10.50.5.10 eq domain
deny ip any any log 

Apply your ACL to the VLAN interface
————————————-
interface vlan 10
ip access-group 100 in

That’s all you have to do to restrict the traffic, its very simple the inbound and outbound commands are hard to understand at first but just imagine yourself standing on top of the switch and think of traffic direction, so in my case its inbound to the switch.

RH

When you receive your new Cisco switch, its inherently insecure out of the box so here’s a few things you might want to think about before you go ahead and use in a production environment.

1. Set an enable password “(config)#enable secret 0 cisco12345” using the secret will encrypt your password with a strong MD5 hash.

2. Encrypt any plain text passwords with “(config)#service password-encryption”

3. Use a range command on your interfaces, enable spanning-tree portfast and switchport mode access in one go with this handy command “(config-if)#switchport host” this also disables etherchannel capabilities.

4. Still inside the range command you could use “(config-if)#spanning-tree bpduguard enable” this will shut down the port should another bogus switch be plugged into any of the ports and start sending BPDU’s, you can also enable this globally with the command “(config)#spanning-tree bpduguard default”

5. A simple yet effective practice is to never use VLAN1 for anything unless you really need to!

6. Use a blackhole VLAN like some obscure unused VLAN 999, put all unused ports in there so should an attacker plug into an unused port they just aren’t going to get access to anything, or simply shut the unused port down until needed.

7. Use port-security to restrict the amount of MAC address’s you expect to see on a switch so for example on a normal data / voice port you’d expect to see 1 PC and 1 VoIP device. “(config)#switchport port-security maximum 2” next enable it on the port with “(config)#switchport port-security” So any more than 2 MAC address’s seen on the port and it will disable. There are other more granular options with this command so investigate them and use what suits you.

8. Create a local user with this command “(config)#username admin_cisco privilege 15 secret 0 cisco54321”

9. Secure your console and VTY lines with this command use under (line console 0 and vty 0 15) “(config)#login authentication local”

These steps are very simple and easy, and hopefully you will think about using them to secure your device. I will say that this list is not exhaustive so do some research.

RH