| Follow me on:

Blog offline.. and online again

July 19th, 2008 | 2 Comments

This blog was offline for a couple of days, because my ISP thought it would be cool to change the public IP address.

I bought a house with my girl and we are still rebuilding the place. However the end is near. I already signed up with an ISP, which is XS4ALL. It is always a difficult choice when choosing a new provider, but this one offered my a free Wii, so the choice was very easy. But because I am still rebuilding I haven’t been able to connect my router, so the Synology NAS with this web server is still running at my girls parents.

They had Orange as ISP, but Orange now merged with Online. And Online thought, lets change the public IP address of all the modems. At the moment I am in an hotel in the northern part of the Netherlands for 5 days. A friend told me, he couldn’t browse to the blog, so I thought there was a minor problem with the internet connection at home. After doing some research I noticed that the public IP had changed (I could have found the problem sooner if I had used something like DynDNS….).

So I thought, lets just change the NAT mappings in the router, but paranoia as I am, I configured a very strict ACL on the router, so I couldn’t remotely log in to it. Finally after some help from home, I managed to get into the router, change the NAT mappings and ACL statements and change the public DNS records. And see here, the blog is online again.

I hope Online doesn’t do the same trick again in the near future……..

Automatic Log In Reverse Proxy with FBA

July 10th, 2008 | 1 Comment

Recently I configured another ISA 2006 server as reverse proxy to publish the Exchange 2007 OWA environment on a secure way to the internet. The customer where I configured the reverse proxy is migrating from Novell GroupWise to Microsoft Exchange.

During the migration period, the customer has specific requirements when connecting to the webmail environment from the internet. The customer is using GroupWise and OWA next to each other. He build an own log in page for webmail. The user enters this credentials, which are check against a directory with the help of LDAP. Depending on the LDAP group the user is member of, he is redirected to GroupWise webmail or OWA.

The problem was that when the client gets redirected to OWA, he had to provide his credentials a second time to log in to OWA. The customer wants to use Single Sign On, so the user credentials should be automatically posted on the OWA sign in page. The customer has the option to edit his own sign in page, so specific parameters can be added when redirecting the client to the ISA 2006 reverse proxy.

I had to figure out, which URL is posted to the ISA reverse proxy after the user credentials are entered in the web browser. I started to search the internet and different forums, but the solution wasn’t found. So there was nothing else left, than starting the good old sniffer and capture the complete process. I always use WireShark as sniffer, which is a very powerful tool. I added a filter so only the traffic to and from the ISA 2006 server is captured.

I started the sniffer, logged in on the ISA 2006 server, stopped the sniffer and started analyzing the sniffer results. After some digging I found the POST statement, which is displayed below.

POST-STATEMENT

Looking at the POST statements, I now knew the exact URL which is posted to the ISA 2006 server. I copied the URL to notepad, changed the username and password to another account. Copied the new URL and pasted that one in my browser and HIEHOE. After hitting enter, I don’t get any sign in page, but get directly to my webmail. So exactly as the customer wants.

The default POST URL has the following format:

https://<DNS name>/CookieAuth.dll?Logon?curl=Z2Fowa&flags=0&forcedownlevel=0& formdir=1&trusted=0&username=<username>&password=<password>
&SubmitCreds=Log+On

ISA 2006 Authentication over HTTP

July 8th, 2008 | No Comments

I implemented different ISA 2006 Reverse Proxy servers in conjunction with Microsoft Exchange 2003 or Windows Exchange 2007.

Today I configured ISA 2006 with Exchange 2007. I configured the Reverse Proxy server as I did always. And the connection from outside the network works perfectly. On the internal Exchange server I configured Basic and Integrated Authentication on the OWA virtual directory. The problem is that internal users now automatically log in to their webmail box when entering the URL from the Exchange server.

This is not the desired configuration, because internal users should be able to open other people’s mailboxes by logging in as that user. The customer also has an ISA 2006 on the internal network for forwarding proxy purposes.

I decided to publish Exchange 2007 on the internal ISA 2006 server as well. The configuration should use Form Based Authentication (FBA) over HTTP. After configuring and trying the connection, the user can’t access the ISA logon page. In the logging you find that Authentication over HTTP isn’t allowed.

Error Code: 403 Forbidden. ISA Server is configured to block HTTP requests that require authentication. (12250)

This is a default setting in ISA 2006 which can be disable. To allow Authentication over HTTP go to the Listener configuration. Go to the Authentication tab and Select Advanced. In the next tab enable the option Allow client authentication over HTTP. This option enables the using FBA over HTTP.

Layer 2 security

July 6th, 2008 | 1 Comment

I attended the session layer 2 security, because I had some discussions about layer 2 security with one of my colleagues. We were discussing about using layer 2 security and especially implementing it in the environments from our customers.

Looking at my/our customers, I don’t see environments where layer 2 threats would be immediate. But in my opinion, you will never know when it will be immediate. I prefer to implement as much layer 2 security (and security in general) as possible. Maybe I am a little paranoia ;-).

I was very interested in the countermeasures used in active networks and the caveats to these countermeasures. Looking at layer 2 networks, the following topics these are the most common attacks.

VLAN HOPPING

Connections between two switches are mostly configured as trunk ports (IEEE 802.1Q). All VLAN travel these trunk connections. Cisco switches have the capability to dynamically negotiate a trunk port. This means that all edge ports can become trunk ports. When an attacker can spoof to be switch, he could configure a trunk connection with the switch. By configuring a trunk connections with the switch, the attacker has access to all VLAN configured on the trunk. You have to disable the DTP (Dynamic Trunking Protocol) on the edge ports to mitigate these attacks. DTP is disabled with the command switchport nonegotiate. When tagging VLAN’s to a trunk it is preferred to use VLAN allowed lists on the trunks. This prevents that all VLAN’s have access to the trunk, only the specified VLAN’s will have access to the trunk.

MAC ADDRESS ATTACKS

Flooding the CAM table with bogus entries makes a hub out of a switch. When the CAM table is full, all traffic without an entry in the CAM table will be flooded out every port on the switch. This means that an attacker can intercept all traffic from the switch. Flooding the CAM table of a switch can also resultant in full CAM tables on adjacent switches. Countermeasures against CAM flooding attacks is the use of port security. To fill the CAM table an attacker will send a lot of different bogus MAC address to the switch. By limiting the allowed MAC address on a switch port, this attack can be prevented. When limiting the number of allowed MAC addresses on a port, you should pay attention to the number of MAC address you configure. Think of features like CDP, LLDP (Link Layer Discovery Protocol), IP Phones, VMware and so one. These features could generate additional MAC entries on the specific switch port. An example configuration for port security is shown below:

switchport port-security
switchport port-security maximum 1 vlan voice
switchport port-security maximum 1 vlan access
switchport port-security violation restrict
switchport port-security aging time 2
switchport port-security aging type inactivity

DHCP ATTACK

DHCP is used in networks to dynamically assign IP addresses and other options to clients. A DHCP scope contains a range of IP addresses and options, which can be assigned to clients. A known attack against DHCP is DHCP starvation. During a DHCP starvation attack an attacker tries to lease all different IP addresses. Most of the tools on the Internet for DHCP starvation use one MAC address for every lease. This means that an attacker uses multiple MAC addresses on the switch port where he connects to the network. Knowing this, you already know the solution to this attack. Just like the MAC address attacks, the solution lies in only allowing a predefined number of MAC addresses on the switch port. There are tools which use the same MAC address, but change Client Hardware Address (CHADDR) in an IPv4 DHCP Packet. This kind of attacks are mitigated by using DHCP Snooping.

Another DHCP attack is adding an untrusted or rogue DHCP server to the network. This way an attacker can assign the “wrong” IP addresses and options, like gateway and DNS servers. This kind of attacks is also mitigated by using DHCP snooping. When turning on DHCP snooping all switch ports will become untrusted. It is important to trust the port to the real DHCP server. The next snippets show examples for configuring DHCP snooping.

GLOBAL CONFIG

ip dhcp snooping vlan 1,10,100

no ip dhcp snooping information option

ip dhcp snooping

UNTRUSTED CLIENT INTERFACE CONFIG

no ip dhcp snooping trust

ip dhcp snooping limit rate 10

TRUSTED SERVER OR UPLINK INTERFACE CONFIG

ip dhcp snooping trust

By enabling DHCP snooping the switch starts building a DHCP snooping binding table. The DHCP snooping binding table is crucial when using DHCP snooping. This table contains the mappings of MAC, IP address, lease time, type of packet, VLAN and snooped interface, like the example below.

DHCP Snooping

The most clients do another DHCP request in the event of a link down and link up event, but not all clients to. For example some Linux systems won’t re-DHCP in the event of link down and link up. When a switch reboots, the DHCP snooping binding table will be lost. If a client doesn’t re-DHCP, the client is denied access to the network, because there is no entry in the DHCP snooping binding table. This means that it is important to backup the DHCP snooping binding table in the event of a switch failure. The DHCP snooping binding table can be written to bootflash, ftp, rcp, slot0 and tftp, like the example shows.

ip dhcp snooping database tftp://10.10.1.1/tftpboot/dhcp-snooping-table

ip dhcp snooping database write-delay 60

Entries in the DHCP snooping binding table stay there until the lease timer expires. When you can a real mobile network it is advised to tune the DHCP lease timers.

ARP ATTACKS

An ARP entry maps a MAC address to an IP address. An attacker can claim, by poisoning the ARP table, to be for example the default gateway of the subnet. This is achieved by replying and poisoning the network by “telling” that the attackers MAC address should be mapped to the default gateway IP address. This way the attacker receives all the traffic designated to the default gateway, which gives the attacker the possibility to perform a man-in-the-middle attack.

An ARP attack can be mitigated by the use of Dynamic ARP Inspection. By using Dynamic ARP Inspection (DIA) the switch checks the IP/MAC mappings in the DHCP snooping binding table. This implies that DHCP snooping is needed for DIA. Another method of mitigating ARP attacks is by checking the source and/or destination MAC addresses and/or IP addresses.

GLOBAL CONFIG

ip dhcp snooping vlan 4,104
no ip dhcp snooping information option
ip dhcp snooping
ip arp inspection vlan 4,104
ip arp inspection log-buffer entries 1024
ip arp inspection log-buffer logs 1024 interval 10

UNTRUSTED CLIENT INTERFACE CONFIG

no ip dhcp snooping trust

ip dhcp snooping limit rate 10

no ip arp inspection trust

TRUSTED SERVER OR UPLINK INTERFACE CONFIG

ip dhcp snooping trust
ip arp inspection trust

ENABLE ALL VALIDATION COMMANDS

ip arp inspection validate src-mac dst-mac ip

SPOOFING ATTACKS

In an spoofing attack the attacker uses the MAC address or IP address of a “real” networking component. Spoofing attacks are performed for the following reasons:

MAC SPOOFING

  • when using MAC authentication on the network the attacker can gain access to the network;
  • the attacker takes over the identity of someone already known on the network;

IP SPOOFING

  • Ping of death attack;
  • ICMP unreachable storm;
  • SYN floods on the network;
  • the attacker takes over the identity of someone already known on the network;

The countermeasure for spoofing attacks is the use of IP Source Guard. IP Source Guard can be compared with Dynamic ARP Inspection, the difference lies in the fact that IP Source Guard checks every packet and not only ARP packets.

These are the most common layer 2 attacks known today. There are some more, like attacks on the Spanning Tree Protocol. These attacks can be mitigated with techniques like BPDUGuard and RootGuard.

I will definitely start using more of the techniques mentioned above in customer environments. It will be a real challenge to implement some of the techniques without disrupting the daily work on the network.