But what is it about? It is actually at first difficult to conceive, as we are all so used that IP addresses identify both a person (or a company) and its location. It is like this by design because Internet is based on a hierarchical routing model.

What I wrote below is just a bad summary of this article by David Meyer. See it as a memo or as a short introduction if you don’t want to get deep into LISP. Otherwise, jump immediately to the original article or to Packetlife which gives some more links.

Now, why would we want to change it? Because with the growing lack of IPv4 free blocks, it became very difficult for the network providers to maintain contiguous blocks. So now the routing tables are bigger than they should be and not optimized. Customers want multihomming and mobility, while providers want to limit the routing overload. Two different point of views which can’t be satisfied with the hierarchical routing of today. BGP partially addresses some of these issues, but it has limits and misconfigurations with deep impacts (eg blackholes) happen regularly. Note that IPv6 can’t be of any help in this case.

But LISP tries. And in a nice way, as it is totally transparent to the end-users. Only the core network of the providers are impacted.

Basically, the customer IP stack remains untouched during the transit. With LISP, the customer IP address is only the identifier, no more the locator.

Then, LISP add a new IP stack on routers configured by the provider. These routers, named ITR (Ingress Tunnel Router) and ETR (Egress Tunnel Router) according to the direction of the flow, encapsulate the packets with the new IP stack with their own address as origin. A little bit as a proxy but at a lower level, their purpose is to route the packets on behalf of the customer.

In short, the role of an ITR is to find the appropriate ETR for the destination, to route the packet correctly. LISP comes with a directory used for the ETR lookup. The directory is supposed to be “manually” maintained by the provider (the overload should be acceptable because we are in a core network, where changes in topology don’t happen all the time). Now that the ITR knows what the location for the recipient is, it sends out the packet with the ETR as destination IP. The way back works just the same.

Between the ITR and the ETR, of course, there can be a number of different providers and routers, not supporting LISP, the routing part being handled by classic routing protocoles like BGP.

You should see clearly now the beauty of LISP : if a customer moves with his IP block, for the provider it is just a matter of updating the location within the LISP directory. There are also some great features like support of load balancing in the case of multi-homing . LISP appears to be efficient and straightforward, but not yet validated by the IETF. Keep an eye on this work in progress!

Follow this link.

The mere concept of a physical attack implies that you have a direct physical access to your target, giving you the ability to modify it as you wish.
This is an ideal situation for an attacker, not quite common. And in that case, there is nothing much to be done on the defensive side.

It is one of the reason why, as a computer security enginneer, a lot of attention must be always payed on the physical security : access to the machine in a locked room, identification of the persons entering with an electronic card, etc.
Without it, the best security software setting is useless.

There can be many way to implement a physical layer attack : modifying the firmware of a router at the maker itself, plug an electronic sniffer on a network segment, inserting a hub, etc.

Attacks on wireless networks are the most popular and easy to do, because of the nature itself of wifi.
Check at the man of aircrack-ng or one of the numerous wifi craking tutorial on the Net if by any chance you were not aware of it.

Another kind of attacks, that can be done without interfering directly with the hardware, concern the MAC address manipulation.

The MAC address is the “physical” way to identify a machine on the network. This address, supposedly unique world-wide, is set by the network card maker.
It is coded with 48 bits, generally on a read-only chip (ROM) to ensure that it can’t be modified. In reality, all operating systems allow to override this value at a logical level (as seen by the network stack of the system).

On Windows XP, changing the MAC address of a network card is as easy as going in the advanced properties of the network card driver, changing the value and deactivating / reactivating the network card.

Changing the MAC address on Windows

In case it does not work (it depends on the driver), there is a free specific tool : Macshift.

On GNU/Linux, it is even easier. Just fire up these two commands :

$ ifconfig eth1 down hw ether 00:00:00:00:00:01
$ ifconfig eth1 up

As you can see, the MAC address really cannot be considered as reliable way of identification.

At last, the MAC duplicating attack consists in using on the hostile node the same MAC address as an active machine of the same network.
A basic or unprotected switch will see the same MAC address coming from two different ports and transfer the packets to both.

The FTP server is on the DMZ area, and therefore I natted a public IP to the private IP in the DMZ subnet of this server.

static (dmz,outside) <public IP> <private_IP> netmask 255.255.255.255

Doing so, I expect that my FTP server (like Vsftpd on Linux) to be reachable within its public IP, from the Asa external interface.

Choosing a FTP transfer mode

Before going further, let’s recall the two modes in which the FTP protocol can work :

• active mode : this is the historical mode, but should be considered obsolete now because of the numerous issues it contains. In this mode, after the client initiate the communication on the port 21 (command chanel), the server initiate the data transfert chanel from its port 20 toward a port specified by the client. It causes two big problems :
  • the client must configure its firewaling to allow incomming traffic on this port. In the real life, this is most likely to be like allowing the 1024-65535 range port for incoming traffic. Not really secure, isn’t it ?
  • if the client is behind a NAT, it won’t work ! As the server initiate the connection, the router does not have any entry for the flow in its NAT table. It will just drop the connexion.
• passive mode : the difference here is that the server chooses on what port the data transfert will be operated. The port is given to the client when this one initiate the communication. Actually, the server never initiate any connexion, so the name “passive”. The only thing to do on the server side is to set the right firewall rule to allow the server ports. The client then initiate the transfert on the given port. It solves the client side firewalling problem, because the firewall will see it as outbound traffic. With correct rules, especially if the firewall is statefull, this is an easy thing.

Configuring the passive mode on the server

So, is the passive mode the end of all problems ?

Not yet…

By default, the FTP server will be listening on its netword interface and answer to the FTP requests with its private IP, if, like probably in many case, the FTP server is located on a DMZ network.

In such a case, the client gets a private IP to connect with… and can never reach the server properly.

To workaround this problem, most of FTP servers can be configured to answer with there public IP.

With VSFTP, this is a line like :

pasv_address = $public_IP

There another two issues for that :

• the server won’t be reachable anymore within its private IP, for instance from the local subnet
• the Cisco Asa firewall drops the traffic

Cisco Asa issue

The Asa log file shows :

FTP port command different address: $IP_addr ($IP_addr2) to $IP_addr_3 on interface int_name

The explanation from the cisco website :
A client issued an FTP port command and supplied an address other than the address used in the connection. This error message is indicative

of an attempt to avert the site’s security policy. For example, one might attempt to hijack an FTP session by changing the packet on the way, and putting

different source information instead of the correct source information. The PIX Firewall drops the packet, terminates the connection, and logs the event.

In the error message displayed, the IP address in parentheses is the address from the PORT command.
Well, as there is nothing to do against this behaviour, I won’t use the pasv_address option.

Private IP issue

So, for now we stick with a server sending its private IP address in any case. That solves any issue in the local subnet, but is it possible to do anything for external clients which needs to get a public IP ?

Actually, and this is really not a satisfying answer, it depends on the client. Most of the FTP client must have the some options to workaround this issue, but not all.

Let’s check how it is with a few FTP clients.

Basic FTP command line client (Linux)

$ ftp X.X.X.X
ftp> dir
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
-rw-rw-r--    1 102      1001           21 Aug 16 10:53 test
226 Directory send OK.

Humm… it is working, but it shouldn’t as my server is configured for passive mode.

Let’s see what is going on with Wireshark… Two packets are interesting :

28    35    192.168.1.2    X.X.X.X   FTP    Request: PORT 192,168,1,2,173,87
29    36    X.X.X.X    192.168.1.2    FTP    Response: 200 PORT command successful. Consider using PASV.

From the client, we have a PORT request, which shows that our client is connecting in active mode.

Surprise, the server replies ! And says successful, even if the IP given is a private one. That should not work and, if any response, not go out of the external firewall…
Note : (192,168,1,2,173,87) is the FTP way to manage IPs and port. The IP is simply given by the four first numbers : 192,168,1,2 <=> 192.168.1.2.
The 2 last ones gives you the port number with this formula : 173,87 => 173 x 256 + 87 = port n°44375
Anyway, let’s try the passive mode :

ftp> passive on
Passive mode on.
ftp> dir
227 Entering Passive Mode (10,1,1,1,15,195)
receive aborted
waiting for remote to finish abort

We tried to switch to passive mode. The server gaves its IP, but its private one (192.168.10.1). The client trying to reach this address can’t and falls in timeout (I killed it, no more patience ) .

Now, let’s summarize.
Using the ftp basic client, we can’t go through in passive mode. We get a private IP and we have no workaround.
The active mode works, but it is thanks to the behaviour of VSFTP.

A look on the man page of VSFTP gives some answers : the

port_enable

directive, set to YES by default, allow the PORT command from the client even in passive mode. So, we could add in the vsftd.conf configuration file :

port_enable=NO

After that the server will answer

550 Permission denied

when a PORT command is issued. At the end, I won’t set this, because such a behaviour is actually nice.

I still wonder how VSFTP could get the public IP when the PORT command send the private IP. I guess, and it would be a smart behaviour, that the program checks the underlying protocol layers and takes the right IP from the IP header… I will have it confirmed and update this post.

Gftp

This Gnome FTP client behave like the ftp command line client in passive mode : it falls into timeout.

It doesn’t try by default to fail over active mode.

You can configure either active mode or ignoring the passive command IP in the options :

Filezilla

Filezilla has the most interesting behaviour. When the standard passive mode fails, it is able to fail over by using active mode or using the public IP seen from the server.

This can be configured in the connexion options :

When Filezilla uses the public IP address instead of the transmitted one :

 PASV
227 Entering Passive Mode (10,1,1,1,15,209)
LIST
150 Here comes the directory listing.
226 Directory send OK.

When it is configured to switch to active mode :

PASV
227 Entering Passive Mode (10,1,1,1,15,179)
PORT 192,168,1,2,130,1
200 PORT command successful. Consider using PASV.
LIST
150 Here comes the directory listing.
226 Directory send OK.

Conclusion

I could not reach the point where I can be 100% sure that it will work in all configurations. The best I could do is a series of small fixes to get the best compromise as possible.

I guess that using VSFTD as a server and recomanding a good client as Filezilla will work pretty well – and that won’t be a big deal to get to such a configuration.

If anyone has some better ideas, or see I fooled somewhere before my conclusion, please let me know.

But anyway, really, FTP sucks. It is anoying that the use of this protocol is still required by some companies.

This tunnel is linking the remote peer and the local peer through an OpenBSD VPN gateway (managed with Isakmp).

The problem is that time allowed for this connection is limited, for security policy reasons. So it is not a 24- hour standard tunnel, but rather an on-demand type connection.

Note that the connection is automatically reset by the remote peer, by invalidating the connection cookie and therefore oblige to renegotiate the VPN tunnel from the beginning (phase 1 of the key exchange).

In other words, the Isakmp service has to be restarted every time we need the tunnel to be up.

Of course, it is not the purpose of Isakmp to have such a mechanism and what we want is to start the tunnel from the local peer, every time it needs to do some transfer.

The graph below summarizes the situation :

That is why I came to develop a script that opens a socket and allows the peer to remotely restart the Isakmp service.

Perl is once again the perfect language for someone like me, who is not a developer. My script uses mainly 2 CPAN modules : NetServer::Generic to manage the socket and Proc::ProcessTable to get the PID of a running process.

You can dowload it here : IsakmpdMon.

And here is the documentation on how to use it : IsakmpdMon Synopsys.

ATTENTION : for security reason, only trusted IPs should be allowed to send the commands.

To have your commands accepted, edit the line :

my ($allowed) = ['10\.80\.1\.2'];

with your IPs. It can be a list of IPs or hostnames separated by commas. You can use some jockers (*) for the names. Please refer to the NetServer::Generic documentation for more info.

Note that this script can be adapted to any usage to manage all kinds of services remotely…

push "dhcp-option DNS 192.168.1.1"

First, you will need the resolvconf program. In debian :

$ apt-get install resolvconf

Then, you will need to add these lines into the configuration file of your Linux client (let’s say /etc/openvpn/client.conf) :

up /etc/openvpn/domain.up plugin /usr/lib/openvpn/openvpn-down-root.so /etc/openvpn/domain.down

The plugin provided by OpenVpn gives back root privilege (when initialized, OpenVPN needs root access but drops it soon).
Now let’s create the scripts :

/etc/openvpn/domain.up :

 #!/bin/sh
    # really naff script to add nameserver entry on up
    DEV=$1
    set | sed -n "      s/^foreign_option_.* DNS \(.*\)'/nameserver \1/; T next; p;
    :next; s/^foreign_option_.* DOMAIN \(.*\)'/domain \1/; T; p;
      " | resolvconf -a $DEV
    resolvconf -u

/etc/openvpn/domain.down :

 #!/bin/sh
  # really naff script to delete nameserver entry on down
  DEV=$1
  resolvconf -d $DEV
  resolvconf -u

Now let’s give them the suitable rights :

$ chmod +x domain*

Finally, just restart openvpn and that should be fine !

UPDATE 2008/07/11 : The two scripts above are kind of obsolete, because, at least in Debian Etch, a similar script is included in the OpenVPN package.

There it is :

#!/bin/bash
#
# Parses DHCP options from openvpn to update resolv.conf
# To use set as 'up' and 'down' script in your openvpn *.conf:
# up /etc/openvpn/update-resolv-conf
# down /etc/openvpn/update-resolv-conf
#
# Used snippets of resolvconf script by Thomas Hood <jdthood@yahoo.co.uk>
# and Chris Hanson
# Licensed under the GNU GPL.  See /usr/share/common-licenses/GPL.
#
# 05/2006 chlauber@bnc.ch
#
# Example envs set from openvpn:
# foreign_option_1='dhcp-option DNS 193.43.27.132'
# foreign_option_2='dhcp-option DNS 193.43.27.133'
# foreign_option_3='dhcp-option DOMAIN be.bnc.ch'

[ -x /sbin/resolvconf ] || exit 0

case $script_type in

up)
	for optionname in ${!foreign_option_*} ; do
		option="${!optionname}"
		echo $option
		part1=$(echo "$option" | cut -d " " -f 1)
		if [ "$part1" == "dhcp-option" ] ; then
			part2=$(echo "$option" | cut -d " " -f 2)
			part3=$(echo "$option" | cut -d " " -f 3)
			if [ "$part2" == "DNS" ] ; then
				IF_DNS_NAMESERVERS="$IF_DNS_NAMESERVERS $part3"
			fi
			if [ "$part2" == "DOMAIN" ] ; then
				IF_DNS_SEARCH="$part3"
			fi
		fi
	done
	R=""
	if [ "$IF_DNS_SEARCH" ] ; then
        	R="${R}search $IF_DNS_SEARCH"
	fi
	for NS in $IF_DNS_NAMESERVERS ; do
        	R="${R}nameserver $NS"
	done
	echo -n "$R" | /sbin/resolvconf -a "${dev}.inet"
	;;
down)
	/sbin/resolvconf -d "${dev}.inet"
	;;
esac