2008-03-20 08:15:47 -06:00
|
|
|
/* (C) 1999-2001 Paul `Rusty' Russell
|
|
|
|
|
* (C) 2002-2006 Netfilter Core Team <coreteam@netfilter.org>
|
|
|
|
|
* (C) 2008 Patrick McHardy <kaber@trash.net>
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/types.h>
|
|
|
|
|
#include <linux/random.h>
|
|
|
|
|
#include <linux/netfilter.h>
|
2011-07-15 09:47:34 -06:00
|
|
|
#include <linux/export.h>
|
2012-08-26 11:14:06 -06:00
|
|
|
|
2008-03-20 08:15:47 -06:00
|
|
|
#include <net/netfilter/nf_nat.h>
|
|
|
|
|
#include <net/netfilter/nf_nat_core.h>
|
2012-08-26 11:14:06 -06:00
|
|
|
#include <net/netfilter/nf_nat_l3proto.h>
|
|
|
|
|
#include <net/netfilter/nf_nat_l4proto.h>
|
2008-03-20 08:15:47 -06:00
|
|
|
|
2012-08-26 11:14:06 -06:00
|
|
|
bool nf_nat_l4proto_in_range(const struct nf_conntrack_tuple *tuple,
|
|
|
|
|
enum nf_nat_manip_type maniptype,
|
|
|
|
|
const union nf_conntrack_man_proto *min,
|
|
|
|
|
const union nf_conntrack_man_proto *max)
|
2008-03-20 08:15:47 -06:00
|
|
|
{
|
|
|
|
|
__be16 port;
|
|
|
|
|
|
2011-12-23 05:59:49 -07:00
|
|
|
if (maniptype == NF_NAT_MANIP_SRC)
|
2008-03-20 08:15:47 -06:00
|
|
|
port = tuple->src.u.all;
|
|
|
|
|
else
|
|
|
|
|
port = tuple->dst.u.all;
|
|
|
|
|
|
|
|
|
|
return ntohs(port) >= ntohs(min->all) &&
|
|
|
|
|
ntohs(port) <= ntohs(max->all);
|
|
|
|
|
}
|
2012-08-26 11:14:06 -06:00
|
|
|
EXPORT_SYMBOL_GPL(nf_nat_l4proto_in_range);
|
2008-03-20 08:15:47 -06:00
|
|
|
|
2012-08-26 11:14:06 -06:00
|
|
|
void nf_nat_l4proto_unique_tuple(const struct nf_nat_l3proto *l3proto,
|
|
|
|
|
struct nf_conntrack_tuple *tuple,
|
|
|
|
|
const struct nf_nat_range *range,
|
|
|
|
|
enum nf_nat_manip_type maniptype,
|
|
|
|
|
const struct nf_conn *ct,
|
|
|
|
|
u16 *rover)
|
2008-03-20 08:15:47 -06:00
|
|
|
{
|
2018-02-14 09:21:19 -07:00
|
|
|
unsigned int range_size, min, max, i;
|
2008-03-20 08:15:47 -06:00
|
|
|
__be16 *portptr;
|
2008-04-14 03:15:46 -06:00
|
|
|
u_int16_t off;
|
2008-03-20 08:15:47 -06:00
|
|
|
|
2011-12-23 05:59:49 -07:00
|
|
|
if (maniptype == NF_NAT_MANIP_SRC)
|
2008-03-20 08:15:47 -06:00
|
|
|
portptr = &tuple->src.u.all;
|
|
|
|
|
else
|
|
|
|
|
portptr = &tuple->dst.u.all;
|
|
|
|
|
|
|
|
|
|
/* If no range specified... */
|
2011-12-23 05:59:49 -07:00
|
|
|
if (!(range->flags & NF_NAT_RANGE_PROTO_SPECIFIED)) {
|
2008-03-20 08:15:47 -06:00
|
|
|
/* If it's dst rewrite, can't change port */
|
2011-12-23 05:59:49 -07:00
|
|
|
if (maniptype == NF_NAT_MANIP_DST)
|
2010-08-02 09:20:54 -06:00
|
|
|
return;
|
2008-03-20 08:15:47 -06:00
|
|
|
|
|
|
|
|
if (ntohs(*portptr) < 1024) {
|
|
|
|
|
/* Loose convention: >> 512 is credential passing */
|
|
|
|
|
if (ntohs(*portptr) < 512) {
|
|
|
|
|
min = 1;
|
|
|
|
|
range_size = 511 - min + 1;
|
|
|
|
|
} else {
|
|
|
|
|
min = 600;
|
|
|
|
|
range_size = 1023 - min + 1;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
min = 1024;
|
|
|
|
|
range_size = 65535 - 1024 + 1;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
2012-08-26 11:14:06 -06:00
|
|
|
min = ntohs(range->min_proto.all);
|
2018-02-14 09:21:19 -07:00
|
|
|
max = ntohs(range->max_proto.all);
|
|
|
|
|
if (unlikely(max < min))
|
|
|
|
|
swap(max, min);
|
|
|
|
|
range_size = max - min + 1;
|
2008-03-20 08:15:47 -06:00
|
|
|
}
|
|
|
|
|
|
netfilter: nf_nat: add full port randomization support
We currently use prandom_u32() for allocation of ports in tcp bind(0)
and udp code. In case of plain SNAT we try to keep the ports as is
or increment on collision.
SNAT --random mode does use per-destination incrementing port
allocation. As a recent paper pointed out in [1] that this mode of
port allocation makes it possible to an attacker to find the randomly
allocated ports through a timing side-channel in a socket overloading
attack conducted through an off-path attacker.
So, NF_NAT_RANGE_PROTO_RANDOM actually weakens the port randomization
in regard to the attack described in this paper. As we need to keep
compatibility, add another flag called NF_NAT_RANGE_PROTO_RANDOM_FULLY
that would replace the NF_NAT_RANGE_PROTO_RANDOM hash-based port
selection algorithm with a simple prandom_u32() in order to mitigate
this attack vector. Note that the lfsr113's internal state is
periodically reseeded by the kernel through a local secure entropy
source.
More details can be found in [1], the basic idea is to send bursts
of packets to a socket to overflow its receive queue and measure
the latency to detect a possible retransmit when the port is found.
Because of increasing ports to given destination and port, further
allocations can be predicted. This information could then be used by
an attacker for e.g. for cache-poisoning, NS pinning, and degradation
of service attacks against DNS servers [1]:
The best defense against the poisoning attacks is to properly
deploy and validate DNSSEC; DNSSEC provides security not only
against off-path attacker but even against MitM attacker. We hope
that our results will help motivate administrators to adopt DNSSEC.
However, full DNSSEC deployment make take significant time, and
until that happens, we recommend short-term, non-cryptographic
defenses. We recommend to support full port randomisation,
according to practices recommended in [2], and to avoid
per-destination sequential port allocation, which we show may be
vulnerable to derandomisation attacks.
Joint work between Hannes Frederic Sowa and Daniel Borkmann.
[1] https://sites.google.com/site/hayashulman/files/NIC-derandomisation.pdf
[2] http://arxiv.org/pdf/1205.5190v1.pdf
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2013-12-20 14:40:29 -07:00
|
|
|
if (range->flags & NF_NAT_RANGE_PROTO_RANDOM) {
|
2012-08-26 11:14:06 -06:00
|
|
|
off = l3proto->secure_port(tuple, maniptype == NF_NAT_MANIP_SRC
|
|
|
|
|
? tuple->dst.u.all
|
|
|
|
|
: tuple->src.u.all);
|
netfilter: nf_nat: add full port randomization support
We currently use prandom_u32() for allocation of ports in tcp bind(0)
and udp code. In case of plain SNAT we try to keep the ports as is
or increment on collision.
SNAT --random mode does use per-destination incrementing port
allocation. As a recent paper pointed out in [1] that this mode of
port allocation makes it possible to an attacker to find the randomly
allocated ports through a timing side-channel in a socket overloading
attack conducted through an off-path attacker.
So, NF_NAT_RANGE_PROTO_RANDOM actually weakens the port randomization
in regard to the attack described in this paper. As we need to keep
compatibility, add another flag called NF_NAT_RANGE_PROTO_RANDOM_FULLY
that would replace the NF_NAT_RANGE_PROTO_RANDOM hash-based port
selection algorithm with a simple prandom_u32() in order to mitigate
this attack vector. Note that the lfsr113's internal state is
periodically reseeded by the kernel through a local secure entropy
source.
More details can be found in [1], the basic idea is to send bursts
of packets to a socket to overflow its receive queue and measure
the latency to detect a possible retransmit when the port is found.
Because of increasing ports to given destination and port, further
allocations can be predicted. This information could then be used by
an attacker for e.g. for cache-poisoning, NS pinning, and degradation
of service attacks against DNS servers [1]:
The best defense against the poisoning attacks is to properly
deploy and validate DNSSEC; DNSSEC provides security not only
against off-path attacker but even against MitM attacker. We hope
that our results will help motivate administrators to adopt DNSSEC.
However, full DNSSEC deployment make take significant time, and
until that happens, we recommend short-term, non-cryptographic
defenses. We recommend to support full port randomisation,
according to practices recommended in [2], and to avoid
per-destination sequential port allocation, which we show may be
vulnerable to derandomisation attacks.
Joint work between Hannes Frederic Sowa and Daniel Borkmann.
[1] https://sites.google.com/site/hayashulman/files/NIC-derandomisation.pdf
[2] http://arxiv.org/pdf/1205.5190v1.pdf
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2013-12-20 14:40:29 -07:00
|
|
|
} else if (range->flags & NF_NAT_RANGE_PROTO_RANDOM_FULLY) {
|
|
|
|
|
off = prandom_u32();
|
|
|
|
|
} else {
|
2008-08-18 22:32:32 -06:00
|
|
|
off = *rover;
|
netfilter: nf_nat: add full port randomization support
We currently use prandom_u32() for allocation of ports in tcp bind(0)
and udp code. In case of plain SNAT we try to keep the ports as is
or increment on collision.
SNAT --random mode does use per-destination incrementing port
allocation. As a recent paper pointed out in [1] that this mode of
port allocation makes it possible to an attacker to find the randomly
allocated ports through a timing side-channel in a socket overloading
attack conducted through an off-path attacker.
So, NF_NAT_RANGE_PROTO_RANDOM actually weakens the port randomization
in regard to the attack described in this paper. As we need to keep
compatibility, add another flag called NF_NAT_RANGE_PROTO_RANDOM_FULLY
that would replace the NF_NAT_RANGE_PROTO_RANDOM hash-based port
selection algorithm with a simple prandom_u32() in order to mitigate
this attack vector. Note that the lfsr113's internal state is
periodically reseeded by the kernel through a local secure entropy
source.
More details can be found in [1], the basic idea is to send bursts
of packets to a socket to overflow its receive queue and measure
the latency to detect a possible retransmit when the port is found.
Because of increasing ports to given destination and port, further
allocations can be predicted. This information could then be used by
an attacker for e.g. for cache-poisoning, NS pinning, and degradation
of service attacks against DNS servers [1]:
The best defense against the poisoning attacks is to properly
deploy and validate DNSSEC; DNSSEC provides security not only
against off-path attacker but even against MitM attacker. We hope
that our results will help motivate administrators to adopt DNSSEC.
However, full DNSSEC deployment make take significant time, and
until that happens, we recommend short-term, non-cryptographic
defenses. We recommend to support full port randomisation,
according to practices recommended in [2], and to avoid
per-destination sequential port allocation, which we show may be
vulnerable to derandomisation attacks.
Joint work between Hannes Frederic Sowa and Daniel Borkmann.
[1] https://sites.google.com/site/hayashulman/files/NIC-derandomisation.pdf
[2] http://arxiv.org/pdf/1205.5190v1.pdf
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2013-12-20 14:40:29 -07:00
|
|
|
}
|
2008-03-20 08:15:47 -06:00
|
|
|
|
2010-08-02 09:35:49 -06:00
|
|
|
for (i = 0; ; ++off) {
|
2008-04-14 03:15:46 -06:00
|
|
|
*portptr = htons(min + off % range_size);
|
2010-08-02 09:35:49 -06:00
|
|
|
if (++i != range_size && nf_nat_used_tuple(tuple, ct))
|
2008-04-14 03:15:46 -06:00
|
|
|
continue;
|
netfilter: nf_nat: add full port randomization support
We currently use prandom_u32() for allocation of ports in tcp bind(0)
and udp code. In case of plain SNAT we try to keep the ports as is
or increment on collision.
SNAT --random mode does use per-destination incrementing port
allocation. As a recent paper pointed out in [1] that this mode of
port allocation makes it possible to an attacker to find the randomly
allocated ports through a timing side-channel in a socket overloading
attack conducted through an off-path attacker.
So, NF_NAT_RANGE_PROTO_RANDOM actually weakens the port randomization
in regard to the attack described in this paper. As we need to keep
compatibility, add another flag called NF_NAT_RANGE_PROTO_RANDOM_FULLY
that would replace the NF_NAT_RANGE_PROTO_RANDOM hash-based port
selection algorithm with a simple prandom_u32() in order to mitigate
this attack vector. Note that the lfsr113's internal state is
periodically reseeded by the kernel through a local secure entropy
source.
More details can be found in [1], the basic idea is to send bursts
of packets to a socket to overflow its receive queue and measure
the latency to detect a possible retransmit when the port is found.
Because of increasing ports to given destination and port, further
allocations can be predicted. This information could then be used by
an attacker for e.g. for cache-poisoning, NS pinning, and degradation
of service attacks against DNS servers [1]:
The best defense against the poisoning attacks is to properly
deploy and validate DNSSEC; DNSSEC provides security not only
against off-path attacker but even against MitM attacker. We hope
that our results will help motivate administrators to adopt DNSSEC.
However, full DNSSEC deployment make take significant time, and
until that happens, we recommend short-term, non-cryptographic
defenses. We recommend to support full port randomisation,
according to practices recommended in [2], and to avoid
per-destination sequential port allocation, which we show may be
vulnerable to derandomisation attacks.
Joint work between Hannes Frederic Sowa and Daniel Borkmann.
[1] https://sites.google.com/site/hayashulman/files/NIC-derandomisation.pdf
[2] http://arxiv.org/pdf/1205.5190v1.pdf
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2013-12-20 14:40:29 -07:00
|
|
|
if (!(range->flags & NF_NAT_RANGE_PROTO_RANDOM_ALL))
|
2008-04-14 03:15:46 -06:00
|
|
|
*rover = off;
|
2010-08-02 09:20:54 -06:00
|
|
|
return;
|
2008-03-20 08:15:47 -06:00
|
|
|
}
|
|
|
|
|
}
|
2012-08-26 11:14:06 -06:00
|
|
|
EXPORT_SYMBOL_GPL(nf_nat_l4proto_unique_tuple);
|
2008-04-14 03:15:47 -06:00
|
|
|
|
2014-06-29 19:19:32 -06:00
|
|
|
#if IS_ENABLED(CONFIG_NF_CT_NETLINK)
|
2012-08-26 11:14:06 -06:00
|
|
|
int nf_nat_l4proto_nlattr_to_range(struct nlattr *tb[],
|
|
|
|
|
struct nf_nat_range *range)
|
2008-04-14 03:15:47 -06:00
|
|
|
{
|
|
|
|
|
if (tb[CTA_PROTONAT_PORT_MIN]) {
|
2012-08-26 11:14:06 -06:00
|
|
|
range->min_proto.all = nla_get_be16(tb[CTA_PROTONAT_PORT_MIN]);
|
|
|
|
|
range->max_proto.all = range->min_proto.all;
|
2011-12-23 05:59:49 -07:00
|
|
|
range->flags |= NF_NAT_RANGE_PROTO_SPECIFIED;
|
2008-04-14 03:15:47 -06:00
|
|
|
}
|
2008-04-14 03:15:47 -06:00
|
|
|
if (tb[CTA_PROTONAT_PORT_MAX]) {
|
2012-08-26 11:14:06 -06:00
|
|
|
range->max_proto.all = nla_get_be16(tb[CTA_PROTONAT_PORT_MAX]);
|
2011-12-23 05:59:49 -07:00
|
|
|
range->flags |= NF_NAT_RANGE_PROTO_SPECIFIED;
|
2008-04-14 03:15:47 -06:00
|
|
|
}
|
2008-04-14 03:15:47 -06:00
|
|
|
return 0;
|
2008-04-14 03:15:47 -06:00
|
|
|
}
|
2012-08-26 11:14:06 -06:00
|
|
|
EXPORT_SYMBOL_GPL(nf_nat_l4proto_nlattr_to_range);
|
2008-04-14 03:15:47 -06:00
|
|
|
#endif
|