Reject non-ipsec traffic

Reject non-ipsec traffic

[Ryan Whelan]

I have IPSec setup between 2 hosts and would like to stop all
inter-host traffic thats not secured with IPSec (They have a GRE
tunnel between them, and I want to be sure the GRE traffic fails to
transmit if the IPSec daemon fails)

I'm testing from host hostA, trying to ping hostB.

This is what I've tried; allow only output traffic thats part of IPSec
to hostB. Else, reject it

iptables -A OUTPUT -p udp --dport 500 -d hostB.example.com -j ACCEPT
iptables -A OUTPUT -p tcp --dport 500 -d hostB.example.com -j ACCEPT
iptables -A OUTPUT -p esp -d hostB.example.com -j ACCEPT
iptables -A OUTPUT -d hostB.example.com -j REJECT

[root@hostA ~]# iptables -vL
Chain INPUT (policy ACCEPT 124 packets, 9920 bytes)
pkts bytes target     prot opt in     out     source
destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source
destination

Chain OUTPUT (policy ACCEPT 94 packets, 12768 bytes)
pkts bytes target     prot opt in     out     source
destination
   0     0 ACCEPT     udp  --  any    any     anywhere
hostB.example.com udp dpt:isakmp
   0     0 ACCEPT     tcp  --  any    any     anywhere
hostB.example.com tcp dpt:isakmp
   0     0 ACCEPT     esp  --  any    any     anywhere
hostB.example.com
   8   864 REJECT     all  --  any    any     anywhere
hostB.example.com reject-with icmp-port-unreachable
[root@hostA ~]#



The reject rule is rejecting all traffic to that host as you can see
from the pkt counter.  If i remove that rule, everything works and i
see the packets get counted on the ESP protocol rule.  I thought the
rules were processes in order until a match was found. Clearly I'm
wrong.

Is this possible without much complexity?

Re: Reject non-ipsec traffic

[Jan Engelhardt]

On Wednesday 2011-07-20 21:20, Ryan Whelan wrote:

>I have IPSec setup between 2 hosts and would like to stop all
>inter-host traffic thats not secured with IPSec (They have a GRE
>tunnel between them, and I want to be sure the GRE traffic fails to
>transmit if the IPSec daemon fails)
>
>iptables -A OUTPUT -p udp --dport 500 -d hostB.example.com -j ACCEPT
>iptables -A OUTPUT -p tcp --dport 500 -d hostB.example.com -j ACCEPT
>iptables -A OUTPUT -p esp -d hostB.example.com -j ACCEPT
>iptables -A OUTPUT -d hostB.example.com -j REJECT
>
>The reject rule is rejecting all traffic to that host[...]
>If i remove that rule, everything works and i
>see the packets get counted on the ESP protocol rule.  I thought the
>rules were processes in order until a match was found. Clearly I'm
>wrong.

They are indeed processed in order, and until a match is found --
and match _was_ found (packet which has dst=hostB, which is not
ESP, and which does not have tcpudp-500 in its headers).

A `ping hostB` would match the criteria of this 4th rules, as would
opening http://hostB.example.com in a browser, for example.

Re: Reject non-ipsec traffic

[Ryan Whelan]

On Wed, Jul 20, 2011 at 3:56 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> On Wednesday 2011-07-20 21:20, Ryan Whelan wrote:
>
>>I have IPSec setup between 2 hosts and would like to stop all
>>inter-host traffic thats not secured with IPSec (They have a GRE
>>tunnel between them, and I want to be sure the GRE traffic fails to
>>transmit if the IPSec daemon fails)
>>
>>iptables -A OUTPUT -p udp --dport 500 -d hostB.example.com -j ACCEPT
>>iptables -A OUTPUT -p tcp --dport 500 -d hostB.example.com -j ACCEPT
>>iptables -A OUTPUT -p esp -d hostB.example.com -j ACCEPT
>>iptables -A OUTPUT -d hostB.example.com -j REJECT
>>
>>The reject rule is rejecting all traffic to that host[...]
>>If i remove that rule, everything works and i
>>see the packets get counted on the ESP protocol rule.  I thought the
>>rules were processes in order until a match was found. Clearly I'm
>>wrong.
>
> They are indeed processed in order, and until a match is found --
> and match _was_ found (packet which has dst=hostB, which is not
> ESP, and which does not have tcpudp-500 in its headers).
>
> A `ping hostB` would match the criteria of this 4th rules, as would
> opening http://hostB.example.com in a browser, for example.
>

but if i remove that the last rule, the 3 rule starts counting matches
(the ESP protocol rule). If that rule matches, why does it continue to
look at rule 4 if rule 3 matches?

Re: Reject non-ipsec traffic

[Jan Engelhardt]

On Wednesday 2011-07-20 22:13, Ryan Whelan wrote:
>On Wed, Jul 20, 2011 at 3:56 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>> On Wednesday 2011-07-20 21:20, Ryan Whelan wrote:
>>
>>>I have IPSec setup between 2 hosts and would like to stop all
>>>inter-host traffic thats not secured with IPSec (They have a GRE
>>>tunnel between them, and I want to be sure the GRE traffic fails to
>>>transmit if the IPSec daemon fails)
>>>
>>>iptables -A OUTPUT -p udp --dport 500 -d hostB.example.com -j ACCEPT
>>>iptables -A OUTPUT -p tcp --dport 500 -d hostB.example.com -j ACCEPT
>>>iptables -A OUTPUT -p esp -d hostB.example.com -j ACCEPT
>>>iptables -A OUTPUT -d hostB.example.com -j REJECT
>>>
>>>The reject rule is rejecting all traffic to that host[...]
>>>If i remove that rule, everything works and i
>>>see the packets get counted on the ESP protocol rule.  I thought the
>>>rules were processes in order until a match was found. Clearly I'm
>>>wrong.
>>
>> They are indeed processed in order, and until a match is found --
>> and match _was_ found (packet which has dst=hostB, which is not
>> ESP, and which does not have tcpudp-500 in its headers).
>>
>> A `ping hostB` would match the criteria of this 4th rules, as would
>> opening http://hostB.example.com in a browser, for example.
>
>but if i remove that the last rule, the 3 rule starts counting matches
>(the ESP protocol rule).

Sure, because once you are not dropping the original packet in rule
4, it has a chance to get encrypted, show up as ESP, and match rule
3.

Re: Reject non-ipsec traffic

[Ryan Whelan]

On Wed, Jul 20, 2011 at 4:30 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> On Wednesday 2011-07-20 22:13, Ryan Whelan wrote:
>>On Wed, Jul 20, 2011 at 3:56 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>>> On Wednesday 2011-07-20 21:20, Ryan Whelan wrote:
>>>
>>>>I have IPSec setup between 2 hosts and would like to stop all
>>>>inter-host traffic thats not secured with IPSec (They have a GRE
>>>>tunnel between them, and I want to be sure the GRE traffic fails to
>>>>transmit if the IPSec daemon fails)
>>>>
>>>>iptables -A OUTPUT -p udp --dport 500 -d hostB.example.com -j ACCEPT
>>>>iptables -A OUTPUT -p tcp --dport 500 -d hostB.example.com -j ACCEPT
>>>>iptables -A OUTPUT -p esp -d hostB.example.com -j ACCEPT
>>>>iptables -A OUTPUT -d hostB.example.com -j REJECT
>>>>
>>>>The reject rule is rejecting all traffic to that host[...]
>>>>If i remove that rule, everything works and i
>>>>see the packets get counted on the ESP protocol rule.  I thought the
>>>>rules were processes in order until a match was found. Clearly I'm
>>>>wrong.
>>>
>>> They are indeed processed in order, and until a match is found --
>>> and match _was_ found (packet which has dst=hostB, which is not
>>> ESP, and which does not have tcpudp-500 in its headers).
>>>
>>> A `ping hostB` would match the criteria of this 4th rules, as would
>>> opening http://hostB.example.com in a browser, for example.
>>
>>but if i remove that the last rule, the 3 rule starts counting matches
>>(the ESP protocol rule).
>
> Sure, because once you are not dropping the original packet in rule
> 4, it has a chance to get encrypted, show up as ESP, and match rule
> 3.
>

So the outbound traffic is being processed by netfilter before getting
wrapped by IPSec?

Re: Reject non-ipsec traffic

[Jan Engelhardt]

On Wednesday 2011-07-20 22:33, Ryan Whelan wrote:
>>>
>>>iptables -A OUTPUT -p udp --dport 500 -d hostB.example.com -j ACCEPT
>>>iptables -A OUTPUT -p tcp --dport 500 -d hostB.example.com -j ACCEPT
>>>iptables -A OUTPUT -p esp -d hostB.example.com -j ACCEPT
>>>iptables -A OUTPUT -d hostB.example.com -j REJECT
>>>
>>>but if i remove that the last rule, the 3 rule starts counting matches
>>>(the ESP protocol rule).
>>
>> Sure, because once you are not dropping the original packet in rule
>> 4, it has a chance to get encrypted, show up as ESP, and match rule
>> 3.
>
>So the outbound traffic is being processed by netfilter before getting
>wrapped by IPSec?

Both before and after.

Re: Reject non-ipsec traffic

[Ryan Whelan]

On Wed, Jul 20, 2011 at 4:34 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Wednesday 2011-07-20 22:33, Ryan Whelan wrote:
>>>>
>>>>iptables -A OUTPUT -p udp --dport 500 -d hostB.example.com -j ACCEPT
>>>>iptables -A OUTPUT -p tcp --dport 500 -d hostB.example.com -j ACCEPT
>>>>iptables -A OUTPUT -p esp -d hostB.example.com -j ACCEPT
>>>>iptables -A OUTPUT -d hostB.example.com -j REJECT
>>>>
>>>>but if i remove that the last rule, the 3 rule starts counting matches
>>>>(the ESP protocol rule).
>>>
>>> Sure, because once you are not dropping the original packet in rule
>>> 4, it has a chance to get encrypted, show up as ESP, and match rule
>>> 3.
>>
>>So the outbound traffic is being processed by netfilter before getting
>>wrapped by IPSec?
>
> Both before and after.
>

Is there a way to accomplish this? Maybe a way to only accept a
non-esp packets if it destined for the ipsec stack; is that possible?
The only other recourse I can think of is dropping on the receiving
side any non-esp packets.  Thats better than nothing, but I'd like to
not send anything unencrypted if possible.

These machines will be forwarding more traffic than they originate.
Should I put this filtering on the `mangle` to catch both forwarded
and sent packets?

Re: Reject non-ipsec traffic

[Petr Pisar]

On 2011-07-21, Ryan Whelan <rcwhelan@gmail.com> wrote:
>
> Is there a way to accomplish this? Maybe a way to only accept a
> non-esp packets if it destined for the ipsec stack; is that possible?

I know you ask about netfilter, but consider IPsec security policies
(defined by setkey tool) can be used to force xfrm based on network or
transport source or destinatino addresses.

-- Petr

Re: Reject non-ipsec traffic

[Ryan Whelan]

The policy is setup (openswan configures it)

# ip xfrm poli
src 111.222.333.444/32 dst 444.333.222.111/32 proto gre
	dir out priority 2080
	tmpl src 111.222.333.444 dst 444.333.222.111
		proto esp reqid 16385 mode tunnel
src 444.333.222.111/32 dst 111.222.333.444/32 proto gre
	dir fwd priority 2080
	tmpl src 444.333.222.111 dst 111.222.333.444
		proto esp reqid 16385 mode tunnel

The issue is that IPSec is protecting a GRE tunnel and if IPSec fails
for some reason, GRE will be happy to work without it; tunnelling
everything in the clear.  I was just hoping to put some kind of fail
safe in place so if IPSec stopped working or failed to start,
unencrypted traffic wouldn't be transmitted.

I will try putting a filter on the ingress side to reject all GRE
traffic so if it not tunneled in IPSec, it will get dropped.  At least
that way, tunnelled TCP sessions can't get setup.


On Thu, Jul 21, 2011 at 12:55 PM, Petr Pisar <petr.pisar@atlas.cz> wrote:
> On 2011-07-21, Ryan Whelan <rcwhelan@gmail.com> wrote:
>>
>> Is there a way to accomplish this? Maybe a way to only accept a
>> non-esp packets if it destined for the ipsec stack; is that possible?
>
> I know you ask about netfilter, but consider IPsec security policies
> (defined by setkey tool) can be used to force xfrm based on network or
> transport source or destinatino addresses.
>
> -- Petr
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Reject non-ipsec traffic

[Steven Kath]

On Thu, 2011-07-21 at 13:05 -0400, Ryan Whelan wrote:
> The issue is that IPSec is protecting a GRE tunnel and if IPSec fails
> for some reason, GRE will be happy to work without it; tunnelling
> everything in the clear.  I was just hoping to put some kind of fail
> safe in place so if IPSec stopped working or failed to start,
> unencrypted traffic wouldn't be transmitted. 

You could create a private loopback address on each endpoint, and use
those loopback addresses in the encryption policy.  The only way the
loopback addresses can reach each other is while the IPsec associations
are up.  Then set up the GRE tunnel with the loopbacks as its endpoints.
That way, when the IPsec tunnel is down, GRE will no longer be happy to
work without it.  

Re: Reject non-ipsec traffic

[Jan Engelhardt]

On Thursday 2011-07-21 21:01, Steven Kath wrote:

>On Thu, 2011-07-21 at 13:05 -0400, Ryan Whelan wrote:
>> The issue is that IPSec is protecting a GRE tunnel and if IPSec fails
>> for some reason, GRE will be happy to work without it; tunnelling
>> everything in the clear.  I was just hoping to put some kind of fail
>> safe in place so if IPSec stopped working or failed to start,
>> unencrypted traffic wouldn't be transmitted. 
>
>You could create a private loopback address on each endpoint, and use
>those loopback addresses in the encryption policy.  The only way the
>loopback addresses can reach each other is while the IPsec associations
>are up.  Then set up the GRE tunnel with the loopbacks as its endpoints.
>That way, when the IPsec tunnel is down, GRE will no longer be happy to
>work without it.  

What I thought of was the use of veth, such that you have a way to 
distinguish between a packet that remained unencrypted, or one that is 
yet to possibly get encrypted.

Re: Reject non-ipsec traffic

[Petr Pisar]

On 2011-07-21, Ryan Whelan <rcwhelan@gmail.com> wrote:
> The policy is setup (openswan configures it)
>
> # ip xfrm poli
> src 111.222.333.444/32 dst 444.333.222.111/32 proto gre
> 	dir out priority 2080
> 	tmpl src 111.222.333.444 dst 444.333.222.111
> 		proto esp reqid 16385 mode tunnel
> src 444.333.222.111/32 dst 111.222.333.444/32 proto gre
> 	dir fwd priority 2080
> 	tmpl src 444.333.222.111 dst 111.222.333.444
> 		proto esp reqid 16385 mode tunnel
>
I don't know openswan syntax. setkey syntax provides level `require'
which means if security association is missing, the packet will not be
sent. I guess the openswan `reqid' is the same as setkey `unique' which
is the same as `require' bound to specific security association.

Please note the security policies can be loaded into kernel independently
on IKE daemon, so you are guarded even if daemon does not start.

> The issue is that IPSec is protecting a GRE tunnel and if IPSec fails
> for some reason, GRE will be happy to work without it; tunnelling
> everything in the clear.  I was just hoping to put some kind of fail
> safe in place so if IPSec stopped working or failed to start,
> unencrypted traffic wouldn't be transmitted.
>
I see, another independent meassure. Unfortunatelly you are out of luck
in case of netfilter on egress traffic.

-- Petr

RE: Reject non-ipsec traffic

[Greg Scott]

But wait a minute - something else has gotta be going on here.  The
original rules had an ACCEPT for UDP and TCP port 500 and then for ESP
and AH. And then the DROP all rule.  When the drop all rule is removed,
then everything comes through because the packet does its thing, gets
re-injected, and now it's ESP. 

So that original packet must be something other than UDP 500  - right?
Something else must happen during the original handshake setting up the
IPSEC SA - because if it was all UDP 500, you'd ACCEPT it - right?  I
think I kind of remember some UDP port 4500 stuff gets in the act
somehow.  Before getting too fancy, maybe insert a -J LOG rule right in
front of that DROP rule so you can see what you're dropping.  That might
give some clues.

- Greg Scott


-----Original Message-----
From: netfilter-owner@vger.kernel.org
[mailto:netfilter-owner@vger.kernel.org] On Behalf Of Petr Pisar
Sent: Friday, July 22, 2011 12:15 AM
To: netfilter@vger.kernel.org
Subject: Re: Reject non-ipsec traffic

On 2011-07-21, Ryan Whelan <rcwhelan@gmail.com> wrote:
> The policy is setup (openswan configures it)
>
> # ip xfrm poli
> src 111.222.333.444/32 dst 444.333.222.111/32 proto gre
> 	dir out priority 2080
> 	tmpl src 111.222.333.444 dst 444.333.222.111
> 		proto esp reqid 16385 mode tunnel
> src 444.333.222.111/32 dst 111.222.333.444/32 proto gre
> 	dir fwd priority 2080
> 	tmpl src 444.333.222.111 dst 111.222.333.444
> 		proto esp reqid 16385 mode tunnel
>
I don't know openswan syntax. setkey syntax provides level `require'
which means if security association is missing, the packet will not be
sent. I guess the openswan `reqid' is the same as setkey `unique' which
is the same as `require' bound to specific security association.

Please note the security policies can be loaded into kernel
independently
on IKE daemon, so you are guarded even if daemon does not start.

> The issue is that IPSec is protecting a GRE tunnel and if IPSec fails
> for some reason, GRE will be happy to work without it; tunnelling
> everything in the clear.  I was just hoping to put some kind of fail
> safe in place so if IPSec stopped working or failed to start,
> unencrypted traffic wouldn't be transmitted.
>
I see, another independent meassure. Unfortunatelly you are out of luck
in case of netfilter on egress traffic.

-- Petr

--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Reject non-ipsec traffic

[Jan Engelhardt]

On Monday 2011-07-25 00:40, Greg Scott wrote:

>But wait a minute - something else has gotta be going on here.  The
>original rules had an ACCEPT for UDP and TCP port 500 and then for ESP
>and AH.

Yes, and where was the accept for unencrypted packets that do not 
belong to IKE? That's the whole point.

>And then the DROP all rule.  When the drop all rule is removed,
>then everything comes through[...]

Re: Reject non-ipsec traffic

[Jan Engelhardt]

On Thursday 2011-07-21 02:09, Ryan Whelan wrote:
>>>
>>>So the outbound traffic is being processed by netfilter before getting
>>>wrapped by IPSec?
>>
>> Both before and after.
>
>Is there a way to accomplish this? Maybe a way to only accept a
>non-esp packets if it destined for the ipsec stack; is that possible?
>The only other recourse I can think of is dropping on the receiving
>side any non-esp packets.  Thats better than nothing, but I'd like to
>not send anything unencrypted if possible.

And don't strip the Cc list.


You can use -m policy in OUTPUT to check for packets destined to be 
xfrmed (output path) or having come out of xfrm (input path), i.e.

-A OUTPUT -m policy --dir out --pol ipsec -j ACCEPT
-A OUTPUT [ike port 500/4500] -j ACCEPT
-A OUTPUT -p esp -j ACCEPT