Easier transition between Dynamic IPs; IKE Vulnerability Scanner

-----BEGIN PGP SIGNED MESSAGE-----



lists.freeswan.org Email Summary for Tuesday November 11, 2003
===============================================================================
by Claudia Schmeing                                        [email protected]


This week, Michael Richardson gave instructions for how to manage a connection 
with two dynamic IPs, using keys posted to DNS. That's in Item 1. 
In Item 2, Michael Thumann has created some nifty IPsec audit tools that the 
community might want to know about.

Enjoy.



This Week in Brief....

1.  Easier transition between Dynamic IPs
2.  IKE Vulnerability Scanner
3.  Interesting FreeS/WAN uses: IPSec bridging thesis, FreeS/WAN on busybox


 ------------------------------------------------------------------------------

1.  Easier transition between Dynamic IPs
    =====================================
    11 posts Nov 9 - 11
    http://lists.freeswan.org/archives/design/2003-November/msg00036.html


The traditional way to connect two dynamic IPs has been to use a Road Warrior 
on the more volatile dynamic end, and static configuration on the other. But, 
as Brian J. Murrell discovered, this can be cumbersome, requiring periodic
intervention by a sysadmin:

    In order to get this one troublesome connection to work I have had to
    configure one end as "initiator" (me) and the other as "receiver".  In
    other words, the initiator (me) has an IP (FQDN actually) configured for
    the peer, but the peer is configured as if it receiving connections from
    Road Warriors (which technically I guess it is).
                                                                                
    This is all fine and good if it is my end (initiator) who's IP gets
    changed (because when my IP is changed I just do a "service ipsec
    stop/service ipsec start" on the release and renewal of the IP). However
    if the receiver's IP gets changed, the connection gets stalled until the
    initiator does an:
                                                                                
    # ipsec auto --replace foo-bar
    # ipsec auto --up foo-bar
                                                                                
    for every SA between the two peers.  Nothing short of an operator getting
    involved and doing the above steps seems to resolve the stall.

Brian asked whether an easier solution was available to him. After determining 
that Brian could not easily change to a static IP, Michael Richardson proposed
a step-by-step plan that relied on OE to ease the transitions. One advantage
of the plan was that any updates of IP information were moved from the local
box into the realm of DNS.

Michael's strategy relies on "split DNS" lookups: where a machine
uses the regular DNS tree for most lookups, yet for special cases, uses a 
private DNS server with locally relevant information. Michael outlined how to 
use the private portion:

     set up dynamic DNS. Have all the machines that have dynamic IPs
     update some name in your DNS. (the A record) Use "nsupdate".

Here's an example of what such a dynamically updated forward record might look
like. This record is for Brian's gateway box which is directly connected to 
the DSL:

           stupidbell.example.com.      IN      A 1.2.3.4
           stupidbell.example.com       IN      TXT
           "X-Ipsec(1)[email protected] base64-of-key"

This is a simple dynamic forward lookup, where another machine, knowing
the name of its IPsec peer, can find its address. In addition, it finds
its RSA public key which enables it to build an IPsec tunnel.

Reverse DNS records are also required, for the machines which are to be
protected by the dynamic connections. In Brian's case, he's protecting a 
private (192.168.xxx.xxx) subnet behind the DSL gateway. Michael offered
this sample reverse record:
                                                                                
      $ORIGIN 1.168.192.in-addr.arpa.
      $GENERATE 1-254       $       TXT     "X-Ipsec(10)[email protected]"                                                                               f 
      where stupidbell.example.com lives in front of the 192.168.1.0/24 network.

This record refers parties wishing to make connections to the subnet 
192.169.1.1/24, to the IPsec server stupidbell.example.com.

Michael added a few instructions by which Brian could then configure OE 
trivially on the DSL gateway (and its IPsec peers). With these configs, 
which need not be changed as the IPs go up and down, connections are created 
on an as-needed basis, and a custom firewall script is also invoked at 
need.

When his IP changes, Brian need only change the DNS data; perhaps even only 
in the forward DNS. No local configuration changes are required. Michael's 
concise instructions may be of use to others in Brian's situation.

Although these connections are created with the OE mechanism, they are not
designed for use by strangers who do not know about the private DNS entries. 
Michael pointed out that, with some adjustments, the boxes might be made more 
broadly accessible via OE.



2.  IKE Vulnerability Scanner
    =========================
    2 posts Nov 7
    http://lists.freeswan.org/archives/users/2003-November/msg00249.html


Michael Thumann has released IKEprobe, a vulnerablity scannner for the 
IKE (Internet Key Exchange) protocol. IKE is the key exchange portion of IPsec.
While FreeSWAN is not vulnerable to this attack, the FreeS/WAN community 
may wish to be aware of these tools for testing purposes.

The scanner, which runs on Windows, facilitates the attack that Michael and 
colleague Enno Rey described in the paper, "PSK Attack using IKE Aggressive
Mode", available at http://www.ernw.de/download/pskattack.pdf .
The attack allows an unauthenticated user with access to the wire, to create 
an IPsec tunnel to a box which is configured for Aggressive Mode, Road 
Warriors, and PSK (shared secrets).

This attack uses the program ikecrack (ikecrack.sourceforge.net) to capture an 
unencrypted hash of a PSK from an Aggressive Mode exchange. Offline, ikecrack 
can determine the PSK via dictionary and brute force methods. An intruder 
with this PSK can then trivially obtain a Road Warrior connection. As one of 
the few IPsec implementations which does not support Aggressive Mode, 
FreeS/WAN is not vulnerable to this strategy.

IKEprobe is available at www.ernw.de/download/ikeprobe.zip .
Similar facilities are included in the more general security audit tool 
Cain & Abel, from www.oxid.it. Michael Thurman explained "Cain & Abel can 
crack MD5 and SHA1 based preshared keys while ikecrack can only crack MD5 
based preshared keys."

Thanks to Paul Wouters for forwarding Michael's announcement to the FreeS/WAN
list, and keeping us aware of these tools.



3.  Interesting FreeS/WAN uses: IPSec bridging thesis, FreeS/WAN on busybox
    =======================================================================
    3 posts Nov 7
    http://lists.freeswan.org/archives/users/2003-November/msg00263.html
    http://lists.freeswan.org/archives/design/2003-November/msg00029.html


A couple of interesting uses of FreeS/WAN have come to our attention on the
lists lately. First, Kifah Abbad is in the process of writing a thesis on 
IPsec bridging. He's started in a BSD environment, but is considering moving 
to Linux. He commented:

    IPSEC bridging is used for example, to install a transparent ipsec
    gateway, or transparent firewall, without the user behind it noticing
    any difference, or having to change IP, since the ipsec-bridge or
    gateway uses same ip as client

While FreeS/WAN might provide the IPsec functionality, Kifah wondered what
Red Hat might offer in the way of bridging software. Ken Dyke pointed him 
in the direction of a sourceforge project, ebtables. From 
ebtables.sourceforge.net:

    The ebtables program is a filtering tool for a bridging firewall. The 
    filtering is focussed on the Link Layer Ethernet frame fields. Apart 
    from filtering, it also gives the ability to alter the Ethernet MAC 
    addresses and implement a brouter.

    This website is also a reference for the Linux bridge-nf code, which 
    gives Linux bridging IP firewall functionality by letting iptables 'see' 
    the bridged IP packets.

These tools are also available in the 2.6 kernel code. Perhaps Kifah's results
shall be of interest to others in the FreeS/WAN community; or perhaps there 
are others here who have experience to contribute to his work.

Another unusual project popping up on the list recently was Niki Weibel's
work with FreeS/WAN on busybox embedded Linux, (www.busybox.net). Niki managed 
to get FreeS/WAN working on an "embedded uclibc, busybox, tinylogin system 
(linux-2.6 kernel without modules)". He noted the minor difficulties he'd 
encountered getting there, and included a patch with fixes. Patch and notes 
are at:

    http://lists.freeswan.org/archives/design/2003-November/msg00029.html

Thanks, Niki, for your well organized and helpful comments.


 ------------------------------------------------------------------------------
lists.freeswan.org Email Summary                          Tuesday, Nov 11, 2003

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBP7HEkHDIYXPDEHodAQGolgP8DmaFfWvRZyMnGTjio7X8hejRfK4rM2IM
gB81uvQaSUESLspZ8QOVClBzvH/GLkCYFCd6Akt7wIFjb0BjLiUGoQy5/YkZyFLb
GyxzFAJSZ+TS4N5RozEAGJ/c8GiLJT1ATmj7D4pBBLp/UyjKrzm0EIrJOu/wNuyH
JOtmjMRJmY0=
=zD6f
-----END PGP SIGNATURE-----