port based filtering and IPsec 2.6

port based filtering and IPsec 2.6

[Valentijn Sessink]

Hello list,

https://lists.netfilter.org/pipermail/netfilter/2003-July/045710.html and
following discuss port based filtering and IPsec, AKA 
http://www.ussg.iu.edu/hypermail/linux/kernel/0308.2/1132.html

The issue: if you have a host-to-host connection and you try to use iptables
to filter, you'll see only ESP packets in the INPUT chain. Those are of no
use, as the content (and ports and the like) are all hidden. FreeS/WAN
doesn't have this problem, as it uses a separate dummy interface that
handles the unencrypted packets.

Now there seems a solution that is a bit of a hack, but it does work. Simply
use a *tunnel* between the two hosts, and define the subnets to be
"tunneled" to be the hosts themselves, like so:

add $foo $bar esp 0xf00 -m tunnel   
        -E 3des-cbc $secret1 -A hmac-md5 $secret2; 
spdadd $foo $bar any -P out ipsec
        esp/tunnel/$here-$distant/require;
add $bar $foo esp 0xf01 -m tunnel
	-E 3des-cbc $secret3 -A hmac-md5 $secret4;
spdadd $bar $foo any -P in ipsec
	esp/tunnel/$bar-$foo/require;

Now you'll find double logs from each packet, like so:

$foo:~# iptables -A INPUT -s $bar -j LOG
... to my surprise tells me things like:
Jan 14 14:43:08 $foo kernel: IN=eth1 OUT=
MAC=52:54:05:e5:de:c9:00:02:fd:39:8f:13:08:00 SRC=bar
DST=foo LEN=112 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=ESP SPI=0x302
Jan 14 14:43:08 $foo kernel: IN=eth1 OUT=
MAC=52:54:05:e5:de:c9:00:02:fd:39:8f:13:08:00 SRC=bar
DST=foo LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP
SPT=22 DPT=1028 WINDOW=5792 RES=0x00 ACK SYN URGP=0  

I'm not exactly sure what are drawbacks here (if any). I saw comments by
Bruce Schneier http://www.schneier.com/paper-ipsec.html, recommending the
eliminiation of transport mode anyway, but I'm not sure if this is still
debated. So use at your own risk.

Valentijn
-- 
http://www.openoffice.nl/   Open Office - Linux Office Solutions
Valentijn Sessink  valentyn+sessink@nospam.openoffice.nl

Re: [despammed] port based filtering and IPsec 2.6

[Andreas Kretschmer]

am  Wed, dem 14.01.2004, um 17:26:23 +0100 mailte Valentijn Sessink folgendes:
> Now there seems a solution that is a bit of a hack, but it does work. Simply
> use a *tunnel* between the two hosts, and define the subnets to be
> "tunneled" to be the hosts themselves, like so:
> 
> Now you'll find double logs from each packet, like so:

Okay, but you can't filtering packets. It's not possible to filter, for
instance, all traffic from/to telnet-port and enable all traffic to/from
ssh-port. For this reasen there are the ipsecX-interface in FreeSwan. On
the ethX you see only the crypted traffic, and on ipsecX the plain
traffic. So you can filtering, you can enable only ah/esp on ethX and
enable only ssh on ipsecX.
I miss this option in Kernel 2.6.


Andreas, and sorry about my english...
-- 
Diese Message wurde erstellt mit freundlicher Unterstützung eines freilau-
fenden Pinguins aus artgerechter Freilandhaltung.   Er ist garantiert frei
von Micro$oft'schen Viren. (#97922 http://counter.li.org)     GPG 7F4584DA
Was, Sie wissen nicht, wo Kaufbach ist? Hier: N 51.05082°, E 13.56889° ;-)

Re: [despammed] port based filtering and IPsec 2.6

[netfilter.lists.samba.org]

On Sat, 17 Jan 2004 14:45:19 +0100, Andreas Kretschmer
<andreas_kretschmer@despammed.com> wrote:
>Okay, but you can't filtering packets. It's not possible to filter, for
>instance, all traffic from/to telnet-port and enable all traffic to/from
>ssh-port. For this reasen there are the ipsecX-interface in FreeSwan. On
>the ethX you see only the crypted traffic, and on ipsecX the plain
>traffic. So you can filtering, you can enable only ah/esp on ethX and
>enable only ssh on ipsecX.
>I miss this option in Kernel 2.6.

Actually, not being able to filter traffic from an ipsec tunnel is a
killer. Either for netfilter, or for kernel 2.6 ipsec. I suspect it
will kill kernel 2.6 ipsec. Which is really bad since frees/wan
positively sucks.

Greetings
Marc

-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber          |   " Questions are the         | Mailadresse im Header
Karlsruhe, Germany  |     Beginning of Wisdom "     | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: port based filtering and IPsec 2.6

[Antony Stone]

On Saturday 17 January 2004 5:47 pm, netfilter.lists.samba.org@marc-haber.de 
wrote:

> Actually, not being able to filter traffic from an ipsec tunnel is a
> killer. Either for netfilter, or for kernel 2.6 ipsec. I suspect it
> will kill kernel 2.6 ipsec. Which is really bad since frees/wan
> positively sucks.

What do you think is wrong with FreeS/WAN?

Antony.

-- 
Perfection in design is achieved not when there is nothing left to add, but 
rather when there is nothing left to take away.

 - Antoine de Saint-Exupery

                                                     Please reply to the list;
                                                           please don't CC me.

Re: port based filtering and IPsec 2.6

[Marc Haber]

On Sat, 17 Jan 2004 18:29:56 +0000, Antony Stone
<Antony@Soft-Solutions.co.uk> wrote:
>On Saturday 17 January 2004 5:47 pm, netfilter.lists.samba.org@marc-haber.de 
>wrote:
>> Actually, not being able to filter traffic from an ipsec tunnel is a
>> killer. Either for netfilter, or for kernel 2.6 ipsec. I suspect it
>> will kill kernel 2.6 ipsec. Which is really bad since frees/wan
>> positively sucks.
>
>What do you think is wrong with FreeS/WAN?

FreeS/WAN is - as somebody else said very nicely - at war with the
kernel routing machinery. It makes me sick to see two identical
routing table entries, one pointing to the physical interface and one
pointing to the logical interface, with some hidden magic favoring the
ipsec0 route.

FreeS/WAN is a kernel patch with a very strange applying mechanism
which makes it hard but impossible to use any pre-fabricated patching
framework. I have never been able to get the new module approach to
run. FreeS/WAN needs to be tailored for each new kernel version which
keeps the possibility of a new exploit being fixed, breaking
FreeS/WAN, forcing me to choose between staying exploitable or living
without my VPN connections until the FreeS/WAN project has adapted.

The latest FreeS/WAN version I have successfully used is 1.99. Later
versions insist on establishing a "default route" (manifested as one
route for 0.0.0.0/1 and one for 128.0.0.0/1 which is one more proof of
being at war with the normal routing mechanisms) which breaks the test
boxes unencrypted network connection.

The FreeS/WAN-Users mailing list is flooded with spam because the
mailing list owners refuse to establish even the most trivial of spam
prevention measure because they're afraid of handicapping free speech
without realizing that a spam flooded mailing list is a bad handicap
of free speech because nobody would use it.

I hope that I made my point clear.

Greetings
Marc

-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber          |   " Questions are the         | Mailadresse im Header
Karlsruhe, Germany  |     Beginning of Wisdom "     | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: port based filtering and IPsec 2.6

[Antony Stone]

On Sunday 18 January 2004 9:14 am, Marc Haber wrote:

> On Sat, 17 Jan 2004 18:29:56 +0000, Antony Stone wrote:
>
> > What do you think is wrong with FreeS/WAN?
>
> FreeS/WAN is - as somebody else said very nicely - at war with the
> kernel routing machinery.
>
> FreeS/WAN is a kernel patch with a very strange applying mechanism
>
> The latest FreeS/WAN version I have successfully used is 1.99.
>
> The FreeS/WAN-Users mailing list is flooded with spam
>
> I hope that I made my point clear.

Indeed, thanks.   I understand now why you dislike it.

I guess I've just been lucky that I prefer compiling my own kernels anyway, I 
don't mind a strange patching mechanism so long as it works, and I've not 
joined the mailing list because I've found the info I need in the 
documentation or in the list archives.

I agree with the point made earlier however that it's a very poor situation if 
the 2.6 kernel IPsec won't allow filtering unencrypted packets.

Antony.

-- 
In science, one tries to tell people
in such a way as to be understood by everyone
something that no-one ever knew before.

In poetry, it is the exact opposite.

 - Paul Dirac

                                                     Please reply to the list;
                                                           please don't CC me.

Re: port based filtering and IPsec 2.6

[Marc Haber]

On Sun, Jan 18, 2004 at 09:34:21AM +0000, Antony Stone wrote:
> On Sunday 18 January 2004 9:14 am, Marc Haber wrote:
> > I hope that I made my point clear.
> 
> Indeed, thanks.   I understand now why you dislike it.
> 
> I guess I've just been lucky that I prefer compiling my own kernels
> anyway, I don't mind a strange patching mechanism so long as it
> works, and I've not joined the mailing list because I've found the
> info I need in the documentation or in the list archives.

I compile my own kernels as well, but I package them for easier
distribution to the productive machines. And I like to have .diff
files that can easily be reproduced by my colleagues.

> I agree with the point made earlier however that it's a very poor
> situation if the 2.6 kernel IPsec won't allow filtering unencrypted
> packets.

Yes. It that's really impossible, it's a killer for kernel 2.6 ipsec
in my environment.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany |  lose things."    Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature |  How to make an American Quilt | Fax: *49 721 966 31 29

Re: [despammed] port based filtering and IPsec 2.6

[Valentijn Sessink]

At Sat, Jan 17, 2004 at 06:47:46PM +0100, netfilter.lists.samba.org@marc-haber.de wrote:
> >Okay, but you can't filtering packets. It's not possible to filter, for
> Actually, not being able to filter traffic from an ipsec tunnel is a
> killer.

You *can* filter traffic from an ipsec tunnel. So there's no killer at all.

V.
-- 
Linux: geen virusgevaar, geen licentiekosten.
-
http://www.openoffice.nl/   Open Office - Linux Office Solutions
Valentijn Sessink  valentyn+sessink@nospam.openoffice.nl

Re: [despammed] port based filtering and IPsec 2.6

[Valentijn Sessink]

At Sat, Jan 17, 2004 at 02:45:19PM +0100, Andreas Kretschmer wrote:
> > Simply use a *tunnel* between the two hosts, and define the subnets to
> > be "tunneled" to be the hosts themselves
> Okay, but you can't filtering packets. It's not possible to filter, for
> instance, all traffic from/to telnet-port and enable all traffic to/from
> ssh-port.

Yes you can. Re-read my post, and be creative.

Example: suppose you want to setup a secure connection between host1 and
host2, and you want to allow POP3 between these, but only if the POP3 came
in through IPsec.

Steps to take:
1) set up a VPN between host1 and host2. NOTE: use tunnel mode for this, not
transport mode! I repeat: use tunnel mode, not transport! NOTE 2: when using
tunnel mode, you MUST use authentication, otherwise your VPN is not secure!

2) set up your firewalling:
# first, we set a "mark" on every IPsec packet that comes in.
iptables -A INPUT -p esp -t mangle -j MARK --set-mark 1

# the Linux kernel keeps the MARK after a packet has been decrypted, so
# we can check for the mark to see if a packet came in through IPsec. This
# is equivalent to the ipsec0 virtual interface that FreeS/WAN has.
#
# we are silly firewall builders and we accept every "marked" packet that
# goes to port 110. DO NOT DO THIS AT HOME, you should probably use stateful
# firewalling for this.
iptables -A INPUT -p tcp --dport pop3 -m mark --mark 1 -j ACCEPT
# we drop all other packets to port 110
iptables -A INPUT -p tcp --dport pop3 -j DROP

V.
-- 
Blokkeer die vervelende popup-advertenties met Mozilla: www.mozilla.org
-
http://www.openoffice.nl/   Open Office - Linux Office Solutions
Valentijn Sessink  valentyn+sessink@nospam.openoffice.nl

Re: [despammed] port based filtering and IPsec 2.6

[Marc Haber]

On Wed, Jan 21, 2004 at 04:37:48PM +0100, Valentijn Sessink wrote:
> Yes you can. Re-read my post, and be creative.

That will work for incoming packets. And how do I protect myself
against configuration errors sending out unencrypted packets? I'd need
to put the mark on the packets for destination networks, which is
error prone.

The idea is nice, but it looks like an ugly hack. And it _is_ an ugly
hack.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany |  lose things."    Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature |  How to make an American Quilt | Fax: *49 721 966 31 29

Re: [despammed] port based filtering and IPsec 2.6

[Valentijn Sessink]

At Wed, Jan 21, 2004 at 04:44:20PM +0100, Marc Haber wrote:
> On Wed, Jan 21, 2004 at 04:37:48PM +0100, Valentijn Sessink wrote:
> > Yes you can. Re-read my post, and be creative.
> That will work for incoming packets. And how do I protect myself
> against configuration errors sending out unencrypted packets? I'd need
> to put the mark on the packets for destination networks, which is
> error prone.

Why is that error prone? If your concern is putting out unencrypted packets
to certain networks, you can just use -p esp. And yes: a firewall setup with
IPsec *is* error prone. That's no different in FreeS/WAN, I think.

It is no more or less complicated to say "-i ipsec0" or "-m mark --mark 1".

Apart from that, I do not exactly understand your point. AFAIK, FreeS/WAN
will only let you setup a tunnel or no tunnel, nothing in between. If you
would want to send some traffic through the tunnel, you would need a whole
lot of non-trivial policy routing rules. (But maybe I'm mistaken here).

> The idea is nice, but it looks like an ugly hack. And it _is_ an ugly
> hack.

IPsec tunnel mode is an ugly hack? You might want to explain that to Bruce
Scheier: http://www.schneier.com/paper-ipsec.html

I wouldn't know what is ugly about marking packets to post-process them
later.

V.
-- 
http://www.openoffice.nl/   Open Office - Linux Office Solutions
Valentijn Sessink  valentyn+sessink@nospam.openoffice.nl

Re: [despammed] port based filtering and IPsec 2.6

[Marc Haber]

On Wed, Jan 21, 2004 at 05:31:30PM +0100, Valentijn Sessink wrote:
> At Wed, Jan 21, 2004 at 04:44:20PM +0100, Marc Haber wrote:
> > On Wed, Jan 21, 2004 at 04:37:48PM +0100, Valentijn Sessink wrote:
> > > Yes you can. Re-read my post, and be creative.
> > That will work for incoming packets. And how do I protect myself
> > against configuration errors sending out unencrypted packets? I'd need
> > to put the mark on the packets for destination networks, which is
> > error prone.
> 
> Why is that error prone? If your concern is putting out unencrypted packets
> to certain networks, you can just use -p esp.

My concern is that I'd need to maintain the list of networks that
should be reached only via ipsec twice: Once in the ipsec setup, and
once in the packet filter. With a dedicated interface, I'd only have
to maintain it in the ipsec setup with the packet filter automatically
following with rules on --out-int ipsecfoo.

> It is no more or less complicated to say "-i ipsec0" or "-m mark --mark 1".

But the interface comes automatically, while one would need to worry
about putting the mark on the packet.

This works "fine" for incoming packets, but gets ugly for outgoing
packets.

> Apart from that, I do not exactly understand your point. AFAIK, FreeS/WAN
> will only let you setup a tunnel or no tunnel, nothing in between. If you
> would want to send some traffic through the tunnel, you would need a whole
> lot of non-trivial policy routing rules. (But maybe I'm mistaken here).

You mean a setup like "send everything to a.b.c.d/e through the ipsec
tunnel, except for traffic to a.b.c.d/e TCP port 22"? Right, that's
not possible with FreeS/WAN. Can 2.6 ipsec do that?

> > The idea is nice, but it looks like an ugly hack. And it _is_ an ugly
> > hack.
> 
> IPsec tunnel mode is an ugly hack?

Not at all. Looks like two non-native speakers misunderstanding each
other.

> I wouldn't know what is ugly about marking packets to post-process them
> later.

Well, most systems make a tunnel look like a dedicated connection on a
"virtual network interface". This makes sense, and is more natural to
handle, IMO, than having to fiddle with marks in a number space that
might already be populated for traffic shaping or policy routing.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany |  lose things."    Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature |  How to make an American Quilt | Fax: *49 721 966 31 29

Re: [despammed] port based filtering and IPsec 2.6

[Valentijn Sessink]

Hello Marc,

At Wed, Jan 21, 2004 at 10:46:43PM +0100, Marc Haber wrote:
> > Why is that error prone? If your concern is putting out unencrypted packets
> > to certain networks, you can just use -p esp.
> My concern is that I'd need to maintain the list of networks that
> should be reached only via ipsec twice: Once in the ipsec setup, and
> once in the packet filter. With a dedicated interface, I'd only have
> to maintain it in the ipsec setup with the packet filter automatically
> following with rules on --out-int ipsecfoo.

That wouldn't help you with egress-filtering. You'd still need a rule to
prevent unencrypted packets going out to your eth0 interface.

> > It is no more or less complicated to say "-i ipsec0" or "-m mark --mark 1".
> But the interface comes automatically, while one would need to worry
> about putting the mark on the packet.

Easy enough: put a mark on *all* outgoing packets, then filter ESP packets
with a mark in the POSTROUTING table.

> This works "fine" for incoming packets, but gets ugly for outgoing
> packets.

OK, I think I understand what you mean, and I think I've found a solution
here, too. Your concern is that once a packet is in OUTPUT, it could be gone
if there's no post-encryption stage. Luckily, I found out there is one.
 On output, the output packets go unencrypted in the OUTPUT table,
then go encrypted through POSTROUTING, so you can filter unwanted
un-encrypted packets there.

Suppose you have something like
filter bla bla bla $foo $portnumberfoo -o ethX
filter bla bla bla $bar $portnumberbar -o ipsec0

What you "conceptually" say is that for some port/IPsec combinations you
would do Something, and for some port/unencrypted combinations you would do
SomethingElse

Suppose you want to convert this to 2.6 IPsec. You would setup a tunnel and
make rules to mark the combinations:

mark --set-mark 1 -A OUTPUT bla bla bla $foo $portnumberfoo
mark --set-mark 2 -A OUTPUT bla bla bla $bar $portnumberbar

Then use this mark to filter in the POSTROUTING chain to do Something or
SomethingElse.

> You mean a setup like "send everything to a.b.c.d/e through the ipsec
> tunnel, except for traffic to a.b.c.d/e TCP port 22"? Right, that's
> not possible with FreeS/WAN. Can 2.6 ipsec do that?

FreeS/WAN can do that, too, I think, but you'd need policy routing for that.
Yes, 2.6 IPsec can do that by design.

> Not at all. Looks like two non-native speakers misunderstanding each
> other.

Grin ;-)
Unsere Amerikanische Freunde werden kein Deutsch verstehen. En Nederlands is
misschien ook voor jou wat lastig.

> Well, most systems make a tunnel look like a dedicated connection on a
> "virtual network interface". This makes sense, and is more natural to
> handle, IMO, than having to fiddle with marks in a number space that
> might already be populated for traffic shaping or policy routing.

I now understand. Yes, the concept is different and there is not enough
documentation about the table traversing of the packets. I did some testing
to find this out, but still have no 100% idea of the route packets take. A
nice ASCII drawing could really help here ;-)

Best regards,

Valentijn
-- 
http://www.openoffice.nl/   Open Office - Linux Office Solutions
Valentijn Sessink  valentyn+sessink@nospam.openoffice.nl

Re: [despammed] port based filtering and IPsec 2.6

[Marc Haber]

Hi Valentijn,

sorry for not getting back to you for a long time, but there have been
significant changes in my life recently :-(

On Thu, Jan 22, 2004 at 01:43:23PM +0100, Valentijn Sessink wrote:
> At Wed, Jan 21, 2004 at 10:46:43PM +0100, Marc Haber wrote:
> > > Why is that error prone? If your concern is putting out unencrypted packets
> > > to certain networks, you can just use -p esp.
> > My concern is that I'd need to maintain the list of networks that
> > should be reached only via ipsec twice: Once in the ipsec setup, and
> > once in the packet filter. With a dedicated interface, I'd only have
> > to maintain it in the ipsec setup with the packet filter automatically
> > following with rules on --out-int ipsecfoo.
> 
> That wouldn't help you with egress-filtering. You'd still need a rule to
> prevent unencrypted packets going out to your eth0 interface.

yes, but that rule would only contain interface names, and no IP
addresses.

[Other stuff snipped, but kept for later reference. I won't need it at
the moment, but maybe in a few months].

> > Well, most systems make a tunnel look like a dedicated connection on a
> > "virtual network interface". This makes sense, and is more natural to
> > handle, IMO, than having to fiddle with marks in a number space that
> > might already be populated for traffic shaping or policy routing.
> 
> I now understand. Yes, the concept is different and there is not enough
> documentation about the table traversing of the packets. I did some testing
> to find this out, but still have no 100% idea of the route packets take. A
> nice ASCII drawing could really help here ;-)

Yes, documentation is an issue. However, not having a virtual
interface for the unencrypted packages will also break a lot of
pcap-based applications, for example ippl and tcpdump. With 2.6 ipsec,
it is not possible any more to debug on application level with
tcpdump, since tcpdump only sees the encrypted packets - useless.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany |  lose things."    Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature |  How to make an American Quilt | Fax: *49 721 966 31 29

Re: [despammed] port based filtering and IPsec 2.6

[Valentijn Sessink]

Hello Marc,

At Tue, Feb 17, 2004 at 04:02:14PM +0100, Marc Haber wrote:
> sorry for not getting back to you for a long time, but there have been
> significant changes in my life recently :-(

The :-( doesn't sound like fun, exactly.

And, while we're at it: IPsec 2.6 isn't fun, too. It's broken, which is
probably due to the non-interface'd way it works. There are all sorts of
problems due to fragmentation. See
http://www.ussg.iu.edu/hypermail/linux/net/0402.2/0000.html for that.

Unfortunately, no replies yet - and I cannot find my message on the kernel
mailing list, maybe I'll just have to wait.

V.
-- 
http://www.openoffice.nl/   Open Office - Linux Office Solutions
Valentijn Sessink  valentyn+sessink@nospam.openoffice.nl