LAND check: 2.4.20

LAND check: 2.4.20

[Vishwas Manral]

Hi folks,

I found no check in the iptables module for LAND attack source
port/ipAddr == destination port/ipAddr.
http://www.cert.org/advisories/CA-1997-28.html

Would we want to add that in ipt_unclean.c in the functions check_tcp
and check_udp?

Thanks,
Vishwas

Re: LAND check: 2.4.20

[Martijn Lievaart]

Vishwas Manral said:
> Hi folks,
>
> I found no check in the iptables module for LAND attack source
> port/ipAddr == destination port/ipAddr.
> http://www.cert.org/advisories/CA-1997-28.html
>
> Would we want to add that in ipt_unclean.c in the functions check_tcp
> and check_udp?

IMO, your anti spoofing rules should catch this.

M4

RE: LAND check: 2.4.20

[Vishwas Manral]

Hi Martin/ folks,

Thanks. That was a lot of help. Can you point me to the code where the
checks have been made?

There is another issue I found. There are checks in the TCP code to see
if any of the reserved flags are set. However reserved flags do not seem
to take care of the NS flag (similar to ECE and CWR) which was
introduced some time back.

Would we want changes for the same in the kernel?

Thanks,
Vishwas
-----Original Message-----
From: Martijn Lievaart [mailto:m@rtij.nl] 
Sent: Monday, March 14, 2005 8:21 PM
To: Vishwas Manral
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: LAND check: 2.4.20

Vishwas Manral said:
> Hi folks,
>
> I found no check in the iptables module for LAND attack source
> port/ipAddr == destination port/ipAddr.
> http://www.cert.org/advisories/CA-1997-28.html
>
> Would we want to add that in ipt_unclean.c in the functions check_tcp
> and check_udp?

IMO, your anti spoofing rules should catch this.

M4

RE: LAND check: 2.4.20

[Martijn Lievaart]

Vishwas Manral said:
> Hi Martin/ folks,
>
> Thanks. That was a lot of help. Can you point me to the code where the
> checks have been made?

They should be in your ruleset or you can use the Linux built in routing
checks. If you have an interface that connects to specific networks, there
is no reason to accept packets from another interface with a source
address in those specific networks. Your ruleset can and should check for
that. That should catch the LAND attack.

Obviously this does not work for every firewall, if you have some complex
multirouting scenario this may not be possible. But that is typically not
a firewall protecting Windows hosts, so in practice that should not be a
problem.

M4

RE: LAND check: 2.4.20

[Cedric Blancher]

Le mardi 15 mars 2005 à 17:42 +0100, Martijn Lievaart a écrit :
> They should be in your ruleset or you can use the Linux built in routing
> checks.

There are 2 major cases :

	. Packet is seen by a filtering box, then rp_filter should
	  destroy the packet as source is not routed through receiving
	  interface.
	. Packet is received by destination, then routing code will
	  destroy it as a packet with local IP as source must be
	  received on loopback.

I don't think there's a real security issue that implies hardcoding.


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

RE: LAND check: 2.4.20

[Vishwas Manral]

Hi Cedric/ Martin,

Thanks for the reply. There are a few things you may be missing:-

1. They cannot be in the rule set, unless we can put a rule which says for any Source-IP/ Port if destination will be the same value then drop. You cannot put the value of every possible IP/port in your rule set. Besides as you yourself mentioned the solution you state it may not work for all scenarios.

2. The source and destination address may be routed, though the same. So from a machine X I could send a packet with source and Destination IP of Y.

3. I am not sure which routing code checks for Source IP Address? Can you point me to some code (destroy it as a packet with local IP as source must be received on loopback)?

The solution as done by most firewalls is to add a simple check in the check_tcp and check_udp. I think we need to add this to the iptables code.

Thanks,
Vishwas
-----Original Message-----
From: netfilter-devel-bounces@lists.netfilter.org [mailto:netfilter-devel-bounces@lists.netfilter.org] On Behalf Of Cedric Blancher
Sent: Tuesday, March 15, 2005 10:23 PM
To: Martijn Lievaart
Cc: netfilter-devel@lists.netfilter.org; Vishwas Manral
Subject: RE: LAND check: 2.4.20

Le mardi 15 mars 2005 à 17:42 +0100, Martijn Lievaart a écrit :
> They should be in your ruleset or you can use the Linux built in routing
> checks.

There are 2 major cases :

	. Packet is seen by a filtering box, then rp_filter should
	  destroy the packet as source is not routed through receiving
	  interface.
	. Packet is received by destination, then routing code will
	  destroy it as a packet with local IP as source must be
	  received on loopback.

I don't think there's a real security issue that implies hardcoding.


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: LAND check: 2.4.20

[Patrick Schaaf]

> 3. I am not sure which routing code checks for Source IP Address? Can you point me to some code (destroy it as a packet with local IP as source must be received on loopback)?

net/ipv4/fib_frontend.c, function fib_validate_source().

The logic will be: destroy it because the route back to that source IP
resolves to destination device lo, and not the device the packet came from.

> The solution as done by most firewalls is to add a simple check in the check_tcp and check_udp. I think we need to add this to the iptables code.

No, we don't.

best regards
  Patrick

RE: LAND check: 2.4.20

[Vishwas Manral]

Hi Peter,

Thanks for pointing out. The check is called uRPF check needs to be
enabled only in case we have symmetric routing and we are not using
multihoming.

If you are saying RPF is done by default, it's a bigger problem. You may
want to see the IETF opsec mailing list for the same.

Thanks,
Vishwas
-----Original Message-----
From: Patrick Schaaf [mailto:bof@bof.de] 
Sent: Wednesday, March 16, 2005 12:00 PM
To: Vishwas Manral
Cc: Cedric Blancher; Martijn Lievaart;
netfilter-devel@lists.netfilter.org
Subject: Re: LAND check: 2.4.20

> 3. I am not sure which routing code checks for Source IP Address? Can
you point me to some code (destroy it as a packet with local IP as
source must be received on loopback)?

net/ipv4/fib_frontend.c, function fib_validate_source().

The logic will be: destroy it because the route back to that source IP
resolves to destination device lo, and not the device the packet came
from.

> The solution as done by most firewalls is to add a simple check in the
check_tcp and check_udp. I think we need to add this to the iptables
code.

No, we don't.

best regards
  Patrick

Re: LAND check: 2.4.20

[Martijn Lievaart]

Vishwas Manral wrote:

>Hi Cedric/ Martin,
>
>Thanks for the reply. There are a few things you may be missing:-
>
>1. They cannot be in the rule set, unless we can put a rule which says for any Source-IP/ Port if destination will be the same value then drop. You cannot put the value of every possible IP/port in your rule set. Besides as you yourself mentioned the solution you state it may not work for all scenarios.
>  
>

Yes they can. You don't need a rule that syas srcip==dstip. If eth0 is 
connected to 1.2.3.0/24, put in a rule that drops traffic from any other 
interface with source address 1.2.3.0/24. In practice this works in any 
scenario where it matters imo.

>2. The source and destination address may be routed, though the same. So from a machine X I could send a packet with source and Destination IP of Y.
>  
>

Yes, that is possible. However, do you want to catch LAND attacks on a 
machine that has such weird routing functionality? If this really 
bothers you, write a custom match, it should be trivial.

>3. I am not sure which routing code checks for Source IP Address? Can you point me to some code (destroy it as a packet with local IP as source must be received on loopback)?
>  
>

See Patricks reply.

>The solution as done by most firewalls is to add a simple check in the check_tcp and check_udp. I think we need to add this to the iptables code.
>  
>

If you really need this functionality, it is trivial to write a custom 
match for it. If case 2 above is a reality for you, you need the 
flexibility of a custom match anyhow, as you cannot solve the problem 
generically in that case.

M4