Booches.nl

IPplan – IP address management

A lot of customers have different methods for their IP address management. Most of them use some kind of static documentation, like an Excel sheet. In the past I implemented IPplan multiple times. I like this tool, because it dynamically scans multiple IP subnets, using ICMP and/or Nmap. Another advantage of IPplan is its ability to perform hostname lookups.

Often I install IPplan on an active management system, like CactiEZ. The following howto shows the steps to implement IPplan under CactiEZ.

The first step is downloading the appropriate tar.gz file and extract his file in /var/www/html, like shown below.

tar zxvf ipplan-4.92a.tar.gz

Next I change the ownership and permissions of the ipplan directory.

chown –R apache:apache ipplan
chmod –R 750 ipplan

After changing the permissions I create the necessary database for ipplan.

mysql –u root –p
mysql> create database ipplan;

This creates a database called ipplan. Now we need to create a user with the appropriate permissions for the ipplan database.

mysql> GRANT SELECT,INSERT,UPDATE,DELETE on ipplan.* \
    -> TO ipplan@localhost IDENTIFIED by ‘password’;

You can change the value ‘password’ to a password you wish. Change the credentials, configured in the previous step, in the file called config.php.

Open a web browser and point it to the installation script in the admin directory (http://ip-address/ipplan/admin/install.php). You will be prompted to create the database schema. The user created above does not have enough permissions to create tables so you will need to either copy the statements into the database, or temporarily change the database password in the config.php file to a database user that has enough rights to do this. You could be asked to enter user credentials for the website. This user credentials can be found in config.php.

I always load the statements by copying the display output from the install.php script into a file (ipplan.sql) and then executing the file using mysql statements.

mysql –u root –p ipplan < ipplan.sql

The basic installation is now complete. We will now go ahead and create a private menu. Open the file config.php and find the section START OF MENU EXTENSION. Change this section into the following to create a private menu.

// private menu extensions to the ipplan menu system
define(“MENU_PRIV”, TRUE);
define(“MENU_EXTENSION”,
“.|4IP
..|Show used area’s|http://<ip address>/ipplan/user/modifyarearange.php?cust=1
..|Show used subnets|http://<ip address>/ipplan/user/treeview.php
..|Create new subnets|http://<ip address>/ipplan/user/createsubnetform.php
..|Edit subnets|http://<ip address>/ipplan/user/modifybaseform.php
“
);

The IPplan poller needs to be added to the crontab configuration. The IPplan poller uses a custom file to know which IP addresses the scan. I normally create a .txt file. The following output show the syntax for the .txt file.

172.22.2.0/24
10.10.0.0/22

I configure the poller to run every day at 9, 12 and 15. You can edit the crontab with the command:

crontab –e

# Crontab for IPplan poller
0 9,12,15 * * * php /var/www/html/ipplan/contrib/ipplan-poller.php -hostnames -c 1 -f /var/www/html/ipplan/4IP-Networks.txt

There is one last step to take. When you manually execute the command above, you will receive the following error message:

Cannot find NMAP!

The last step is to install NMAP and configure its location in config.php. CactiEZ uses yum to install packages. So I use the following command to install nmap.

yum install nmap

Nmap can be found in the directory /usr/bin/. Look for the nmap section in config.php and change the nmap configuration to the following.

//define(“NMAP”, ”);
define(“NMAP”, ‘/usr/bin/nmap’);

The rest of the configuration needs to be done through the web interface. My advise is to configure some user groups and users, before adding subnets to IPplan. You can also change more settings in config.php to match it to your own environment, like the e-mailserver and helpdesk e-mail address.

Sometimes you receive Fatal error: require_once(): Failed opening required ‘../adodb/adodb.inc.php’ message. I resolved this issue by changing line 42 & 43 in ipplan-poller.php from:

require_once(“../adodb/adodb.inc.php”);
require_once(“./config.php”);

to

require_once(“/var/www/html/ipplan/adodb/adodb.inc.php”);
require_once(“/var/www/html/ipplan/config.php”);

This should solve the problem.

Microsoft Outlook through Citrix Access Gateway SSL IP VPN

One of our customers wants you use their locally installed Microsoft Outlook through a Citrix Access Gateway (CAG). Sales people from that customer travel through the country and use the Outlook offline to read or prepare e-mail to send later. These people use UMTS technology to connect their laptops to the Internet. The customers wants these sales people to have the ability to use their Outlook offline and actually send/receive mail when connected to a network with Internet access.

The customer is using CAG’s to publish multiple services to the Internet, so together with my colleague Edwin Houben from DigiPulse, we started to look at a suitable solution. The CAG is located behind a CheckPoint firewall and traffic to the internal network needs to go through an ISA server firewall.

First we started to look at the ports Microsoft Outlook uses to connect to the Exchange server. Looking at the settings from a laptop, the connection is made by FQDN of the Exchange server. While performing a netstat -na we noticed that Outlook uses two ports to connect to the Exchange server.

The Outlook clients connects to the Exchange server on FQDN. So the laptop needs to have an IP connection to the Exchange server. So we decided to use the Citrix Secure Access Client to give the user the ability to establish an secure IP connection to the network.

Looking at the customers network, we had to configure access-lists on two locations to make the solution more secure. The first location is a Network Resource in the CAG. The Network Resource enables only the above ports to the Exchange server IP address. The second location is allowing the IP address of the CAG to connect to the Exchange server on the above port numbers through the ISA server.

After configuring both access-list, we did some testing and the solution works perfectly. You can now use the laptop on the internal network and externally with the Citrix Secure Access Client without making any changes in the Outlook configuration.

Later, the customer noticed that he couldn’t use Microsoft Outlook anymore in conjunction with the Citrix Secure Access Client. After digging a bit deeper in the traffic flow between Microsoft Outlook and the Exchange server, I noticed that, beside TCP/135, random ports above 1024 are used. So I changed the Network Resource  and the ISA servers to allow TCP/135 and the range TCP/1024-2000. I haven’t used the complete range of registered port numbers, so I hope Exchange doesn’t use a port above TCP/2000.

FUNNY ADD-ON

I didn’t some Googleing (or Googling or whatever) on TCP port 135 and I found some “funny” things:

Some well known Root kits also use this port to transmit data back to home base and download more malware. I also suspect may be an entry point for some root kit /malware for un patched systems or systems that did not patch correctly. Source 

Currently inbound scans are likely the Nachi or MSBlast worms. Source

The problem with port TCP 135 is that it is used for multiple services, which are listed below. So blocking port TCP 135 could affect communication between devices or the usage of services.

Telnet Time-Out is killing me….

Aaarrrgggghhh, I hate it when I would like to telnet into a device and enter the wrong IP address. This means, by default, waiting for 30 seconds before being able to correct the IP address and start a new telnet session, because there is no escape sequence.

SW01#telnet 10.100.12.250
Trying 10.100.12.250 …
% Connection timed out; remote host not responding

Luckily there is a command to lessen the time for timing out the connection:

SW01(config)# ip tcp synwait-time <seconds>       (Set time to wait on new TCP connections)

Hoera, tcp synwaiting saves the day….

Layer 2 security

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.

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.

Port-channel Cisco vs. VMware ESX

I have had different discussions with different customers about the load-balancing algorithms between a Cisco switch, configured with a port-channel and a VMware ESX server using multiple NICs. Our VMware consultants always choose Route based on IP hashes as load-balancing algorithm. This means that load-balancing happens on layer 3 of the OSI model (source-destination-IP).

In my opinion, the switch should be configured the same way. Depending on the model switch, you can have different default load-balancing algoritmhs. For example, the Cisco Catalyst 3750 uses src-mac load-balancing and the Cisco Catalyst 6500 use src-dst-ip load-balancing. You can check the configured load-balancing algorithm with the following command:

show etherchannel load-balancing

If you would like you change the load-balancing algorithm you can use the global configuration command:

port-channel load-balancing <option>

Be aware that this is a global configuration command, so it affects all the configured port-channels on the switch.

To check the load-balancing between the different NICs, you should have a tool to look at real-time bandwidth statistics. I normally use the tool SNMP Traffic Grapher to monitor the different switch ports. On the ESX console you can check the load-balancing with the commands:

1. esxtop [enter]
2. s2 (schedule interval of 2 seconds) [enter]
3. n [network]

The load should be spread fairly even across the different switch ports en vmnics.