RE: port-based filtering of IPsec packets?

RE: port-based filtering of IPsec packets?

[George Vieira]

>Surely there must be some way of doing port-based filtering of ESP
>packets that are known to be bound for the local host.
If the packet isn't intended for the firewall/ipsec server, then it's forwarded unencrypted to the internal hosts.... I'm sure by then the data in decrypted right? Because it can't pass an encrypted packet to a host who isn't using IPSEC.

Can you put -j LOG rules in the FORWARD chain to filter on it? Mine appear to pickup port 23 telnet sessions... sorry if what you want isn't this..


[root@firewall root]# iptables -I FORWARD -i ipsec0 -o eth0 -p tcp --dport 23
[root@firewall root]# iptables -L FORWARD -n -v -x
Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       2      104            tcp  --  ipsec0 eth0    0.0.0.0/0            0.0.0.0/0          tcp dpt:23


Thanks,
____________________________________________
George Vieira
Systems Manager
georgev@citadelcomputer.com.au

Citadel Computer Systems Pty Ltd
http://www.citadelcomputer.com.au
 

RE: port-based filtering of IPsec packets?

[Rick Kennell]

On Thu, 2003-07-24 at 16:37, George Vieira wrote:
> >Surely there must be some way of doing port-based filtering of ESP
> >packets that are known to be bound for the local host.
> If the packet isn't intended for the firewall/ipsec server, then
> it's forwarded unencrypted to the internal hosts.... I'm sure by
> then the data in decrypted right? Because it can't pass an encrypted
> packet to a host who isn't using IPSEC.
> 
> Can you put -j LOG rules in the FORWARD chain to filter on it?
> Mine appear to pickup port 23 telnet sessions... sorry if what
> you want isn't this..
> 
> 
> [root@firewall root]# iptables -I FORWARD -i ipsec0 -o eth0 -p tcp --dport 23
> [root@firewall root]# iptables -L FORWARD -n -v -x
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>     pkts      bytes target     prot opt in     out     source               destination
>        2      104            tcp  --  ipsec0 eth0    0.0.0.0/0            0.0.0.0/0          tcp dpt:23

You're using FreeS/WAN, and you're right that it creates an ipsec0
network device where you can see unencapsulated packets.

Meanwhile, I'm using the IPsec built-in to Linux v2.6.
No user-land daemon.
No ipsec0 device.
And no port-based filtering of ESP packets.

Maybe what I'm asking is going to be a FAQ in a few months when the
in-kernel IPsec catches on.  I'm fairly convinced that port- or
payload-based filtering of IPsec packets isn't presently possible with
such that environment.  Either something needs to change or I need to
get a little smarter.

Time to bother the folks on netfilter-devel?

-- 
Rick Kennell <kennell@ecn.purdue.edu>
Purdue University School of Electrical and Computer Engineering

port-based filtering of IPsec packets?

[Rick Kennell]

I'm curious how I might do port-based filtering of IPsec packets with
iptables.  Presently, filtering IPsec-encrypted packets is an
all-or-nothing proposition because iptables can't look inside an ESP
section to get the port info.  It can only filter ESP packets based on
the SPI.  Actually, I'm not even sure how I'd get iptables to do
address-based filtering of IPsec packets.

Why would I want this?  Well, I might want to do opportunistic IPsec and
allow arbitrary parties to interact with my host, but I still want to
make sure that only selected services are made available.

I noticed that a similar thing was asked over on the FreeBSD side of the
world:

   http://www.bsdforums.org/forums/showthread.php?threadid=11725

Somehow, I don't expect the iptables solution to be quite so easy.

-- 
Rick Kennell <kennell@ecn.purdue.edu>
Purdue University Department of Electrical and Computer Engineering

Re: port-based filtering of IPsec packets?

[Ramin Dousti]

Once the IPsec traffic has been terminated (decapsulated) you can
filter it based on the services (tcp or udp ports) prior to that
you only can filter based on the outer IP header...

Ramin

On Wed, Jul 23, 2003 at 02:35:19PM -0500, Rick Kennell wrote:

> 
> I'm curious how I might do port-based filtering of IPsec packets with
> iptables.  Presently, filtering IPsec-encrypted packets is an
> all-or-nothing proposition because iptables can't look inside an ESP
> section to get the port info.  It can only filter ESP packets based on
> the SPI.  Actually, I'm not even sure how I'd get iptables to do
> address-based filtering of IPsec packets.
> 
> Why would I want this?  Well, I might want to do opportunistic IPsec and
> allow arbitrary parties to interact with my host, but I still want to
> make sure that only selected services are made available.
> 
> I noticed that a similar thing was asked over on the FreeBSD side of the
> world:
> 
>    http://www.bsdforums.org/forums/showthread.php?threadid=11725
> 
> Somehow, I don't expect the iptables solution to be quite so easy.
> 
> -- 
> Rick Kennell <kennell@ecn.purdue.edu>
> Purdue University Department of Electrical and Computer Engineering
> 

Re: port-based filtering of IPsec packets?

[Garcia Ruiz]

Maybe I'm wrong because I don't know very well the way IPSec traffic is
encrypted-decrypted inside the firewall, but I think that in one side
(external interface, internet) there is IPSec protocol (protocols 50, 51)
and in other side (internal interface, intranet) there are plain protocols
and ports. Couldn't be possible to filter taking into account the internal
interface where it is suppose not to be encrypted?

JBGR


----- Original Message ----- 
From: "Ramin Dousti" <ramin@cannon.eng.us.uu.net>
To: <netfilter@lists.netfilter.org>
Sent: Wednesday, July 23, 2003 10:42 PM
Subject: Re: port-based filtering of IPsec packets?


> Once the IPsec traffic has been terminated (decapsulated) you can
> filter it based on the services (tcp or udp ports) prior to that
> you only can filter based on the outer IP header...
>
> Ramin
>
> On Wed, Jul 23, 2003 at 02:35:19PM -0500, Rick Kennell wrote:
>
> >
> > I'm curious how I might do port-based filtering of IPsec packets with
> > iptables.  Presently, filtering IPsec-encrypted packets is an
> > all-or-nothing proposition because iptables can't look inside an ESP
> > section to get the port info.  It can only filter ESP packets based on
> > the SPI.  Actually, I'm not even sure how I'd get iptables to do
> > address-based filtering of IPsec packets.
> >
> > Why would I want this?  Well, I might want to do opportunistic IPsec and
> > allow arbitrary parties to interact with my host, but I still want to
> > make sure that only selected services are made available.
> >
> > I noticed that a similar thing was asked over on the FreeBSD side of the
> > world:
> >
> >    http://www.bsdforums.org/forums/showthread.php?threadid=11725
> >
> > Somehow, I don't expect the iptables solution to be quite so easy.
> >
> > -- 
> > Rick Kennell <kennell@ecn.purdue.edu>
> > Purdue University Department of Electrical and Computer Engineering
> >
>
>

Re: port-based filtering of IPsec packets?

[Rick Kennell]

On Wed, 2003-07-23 at 16:11, Garcia Ruiz wrote:
> Couldn't be possible to filter taking into account the internal
> interface where it is suppose not to be encrypted?

I should clarify that I'm not using FreeS/WAN so there's no extra
network interface that gives me access to unencrypted packets.

On Wed, 2003-07-23 at 15:42, Ramin Dousti wrote: 
> Once the IPsec traffic has been terminated (decapsulated) you can
> filter it based on the services (tcp or udp ports) prior to that
> you only can filter based on the outer IP header...

OK.  Is there a way to decapsulate an ESP packet in iptables?

-- 
Rick Kennell <kennell@ecn.purdue.edu>
Purdue University Department of Electrical and Computer Engineering

Re: port-based filtering of IPsec packets?

[Ramin Dousti]

On Wed, Jul 23, 2003 at 04:23:55PM -0500, Rick Kennell wrote:

> > Once the IPsec traffic has been terminated (decapsulated) you can
> > filter it based on the services (tcp or udp ports) prior to that
> > you only can filter based on the outer IP header...
> 
> OK.  Is there a way to decapsulate an ESP packet in iptables?

No, if the IPsec tunnel terminates on your firewall then you'll see the
decapsulated packet while it's being forwarded to its internal destination.
If it does not terminate on your firewall then you're out of luck and must
only rely on the outer IP header to filter...

Ramin

Re: port-based filtering of IPsec packets?

[Rick Kennell]

On Wed, 2003-07-23 at 20:08, Ramin Dousti wrote:
> On Wed, Jul 23, 2003 at 04:23:55PM -0500, Rick Kennell wrote:
> 
> > > Once the IPsec traffic has been terminated (decapsulated) you can
> > > filter it based on the services (tcp or udp ports) prior to that
> > > you only can filter based on the outer IP header...
> > 
> > OK.  Is there a way to decapsulate an ESP packet in iptables?
> 
> No, if the IPsec tunnel terminates on your firewall then you'll see the
> decapsulated packet while it's being forwarded to its internal destination.
> If it does not terminate on your firewall then you're out of luck and must
> only rely on the outer IP header to filter...
> 
> Ramin

I'm not using a tunnel.  I'll describe what (I believe) is happening:

I have two systems that are set up with an IPsec policy that requires
all packets sent between them to have an AH header and the payload
encapsulated in an ESP section.  Interaction with other hosts is normal.

When the packet comes in, netfilter sees it as an ESP packet.  Even the
INPUT chains in the mangle and filter tables see the packet as an ESP
packet.  I don't see a reason why the INPUT chains wouldn't want to see
a decrypted (or, as you put, decapsulated) packet.  Instead, it appears
that the packet is decapsulated after it's out of the filter table's
INPUT chain.  i.e. it gets decapsulated between netfilter and the
application.

Maybe the implementation should be changed to decapsulate the packet
just after the routing decision but before the INPUT chains?

Surely there must be some way of doing port-based filtering of ESP
packets that are known to be bound for the local host.

-- 
Rick Kennell <kennell@ecn.purdue.edu>
Purdue University Department of Electrical and Computer Engineering

Re: port-based filtering of IPsec packets?

[Ramin Dousti]

On Thu, Jul 24, 2003 at 03:50:26PM -0500, Rick Kennell wrote:

> I'm not using a tunnel.  I'll describe what (I believe) is happening:
> 
> I have two systems that are set up with an IPsec policy that requires
> all packets sent between them to have an AH header and the payload
> encapsulated in an ESP section.  Interaction with other hosts is normal.
> 
> When the packet comes in, netfilter sees it as an ESP packet.  Even the
> INPUT chains in the mangle and filter tables see the packet as an ESP
> packet.  I don't see a reason why the INPUT chains wouldn't want to see
> a decrypted (or, as you put, decapsulated) packet.  Instead, it appears
> that the packet is decapsulated after it's out of the filter table's
> INPUT chain.  i.e. it gets decapsulated between netfilter and the
> application.
> 
> Maybe the implementation should be changed to decapsulate the packet
> just after the routing decision but before the INPUT chains?
> 
> Surely there must be some way of doing port-based filtering of ESP
> packets that are known to be bound for the local host.

Then I'm sorry. I don't know. I've always had problems with the interaction
between FreeS/WAN and netfilter. If the traffic is meant for the localhost
then, you're right, it should be visible in the clear to the INPUT chain.
The only thing I heard which is promissing is 2.5 has native IPsec support
in the kernel which is supposed to work well with the other subsystem.

Ramin

> -- 
> Rick Kennell <kennell@ecn.purdue.edu>
> Purdue University Department of Electrical and Computer Engineering

Re: port-based filtering of IPsec packets?

[James A. Pattie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Garcia Ruiz wrote:
| Maybe I'm wrong because I don't know very well the way IPSec traffic is
| encrypted-decrypted inside the firewall, but I think that in one side
| (external interface, internet) there is IPSec protocol (protocols 50, 51)
| and in other side (internal interface, intranet) there are plain protocols
| and ports. Couldn't be possible to filter taking into account the internal
| interface where it is suppose not to be encrypted?

In a freeSwan scenario you have Interfaces called ipsec0, ipsec1, etc.
You do your filtering using them as the source/dest interface to be able
to filter traffic leaving your vpn tunnel or entering your vpn tunnel.

See the PCX Firewall (http://pcxfirewall.sf.net/) for a script that will
help you automate creating these rules.  It supports freeSwan vpns out
of the box (though you still have to configure freeSwan).

|
| JBGR
|
|
| ----- Original Message -----
| From: "Ramin Dousti" <ramin@cannon.eng.us.uu.net>
| To: <netfilter@lists.netfilter.org>
| Sent: Wednesday, July 23, 2003 10:42 PM
| Subject: Re: port-based filtering of IPsec packets?
|
|
|
|>Once the IPsec traffic has been terminated (decapsulated) you can
|>filter it based on the services (tcp or udp ports) prior to that
|>you only can filter based on the outer IP header...
|>
|>Ramin
|>
|>On Wed, Jul 23, 2003 at 02:35:19PM -0500, Rick Kennell wrote:
|>
|>
|>>I'm curious how I might do port-based filtering of IPsec packets with
|>>iptables.  Presently, filtering IPsec-encrypted packets is an
|>>all-or-nothing proposition because iptables can't look inside an ESP
|>>section to get the port info.  It can only filter ESP packets based on
|>>the SPI.  Actually, I'm not even sure how I'd get iptables to do
|>>address-based filtering of IPsec packets.
|>>
|>>Why would I want this?  Well, I might want to do opportunistic IPsec and
|>>allow arbitrary parties to interact with my host, but I still want to
|>>make sure that only selected services are made available.
|>>
|>>I noticed that a similar thing was asked over on the FreeBSD side of the
|>>world:
|>>
|>>   http://www.bsdforums.org/forums/showthread.php?threadid=11725
|>>
|>>Somehow, I don't expect the iptables solution to be quite so easy.
|>>
|>>--
|>>Rick Kennell <kennell@ecn.purdue.edu>
|>>Purdue University Department of Electrical and Computer Engineering
|>>
|>
|>
|
|
|
|


- --
James A. Pattie
james@pcxperience.com

Linux  --  SysAdmin / Programmer
Xperience, Inc.
http://www.pcxperience.com/
http://www.xperienceinc.com/

GPG Key Available at http://www.pcxperience.com/gpgkeys/james.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQE/Hv5qtUXjwPIRLVERAvUNAJwKffPGjDYeo0GmU72pyHN/cGjtAgCg8+Ix
1GuH8Ld7DE2x2B6yIwzUnpA=
=MVUN
-----END PGP SIGNATURE-----


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.