Category Archives: Protocols

Consider learning LISP

No, not the infamous programming language! But LISP as Location/Identifier Separation Protocol. (I know I am repeating the joke everyone does but I couldn’t help).

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!

Introduction to network attacks : Physical Layer

That will be a short article, mainly because of two things. First, some methods are beyond my knowledge, involving electronics or hardware manipulation. Second, such methods are not efficient compare to higher level ones, and so rarely used.

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.

Continue reading

FTP configuration issues

I found that it was a real mess to set up a FTP server in a DMZ, behind a firewall Cisco Asa (501 model with IOS version 7.0).

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.
Continue reading

Perl : how to monitor a service remotely using sockets

I came to program my first Perl script based on sockets, after setting an IPSEC tunnel.

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 :

IPSEC tunnel with OpenBSD as a VPN gateway

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

Continue reading

OpenVPN and DNS on a linux client

I got a weired issue with Linux clients while it worked fine with Windows machines. For some reason, the /etc/resolv.conf did not get updated. I found out a workaround thanks to this page. Of course, your server configuration file must contain (if 192.168.1.1 is your DNS server):

push "dhcp-option DNS 192.168.1.1"

Continue reading