iptables as landmine subnet rejector

iptables as landmine subnet rejector

[Jim Mellander]

Hi all:

I'm working on replacing a freebsd box with custom C code with a linux box.

The code has a configured pcap filter, and does the following with
traffic that matches the pcap filter.  BTW, the pcap filter is not
complex, basically 'tcp and (net a.b.c.d/xx or net e.f.g.h/xx)', so
the equivalent should be easily mappable to iptables rules.

1. If TCP sends RST back as response (obviously not RST in response to RST)
2. Responds to pings, ICMP echo response sent in response to icmp echo request.

I starting porting the code, but it occurred to me that perhaps the
entire job could be done in iptables using DNAT

1. Nat the tcp connection and issue a -j REJECT, or redirect to a
closed port on the the responder host, which will send a RST.
2. NAT the icmp echo request

With a bit of experimentation, I'm fairly certain I could work this
out, but some pointer to get me in the right direction would be
appreciated.

Thanks in advance.

Re: iptables as landmine subnet rejector

[Jim Mellander]

Here's what I ended up doing

*nat
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]

# Just fwd to kernel to provide ping response
-A PREROUTING -d a.b.c.d/xx -p icmp --icmp-type echo-request -j REDIRECT

# Forward to a closed port
-A PREROUTING -d a.b.c.d/xx-p tcp -j DNAT --to-destination myhost:aaaa

.... and further down

*filter
# Here, we let the kernel send the RST from the closed port.
-A INPUT -p tcp -d myhost --dport aaaa -j ACCEPT
# This was a test to see if iptables would do a better job
#-A INPUT -p tcp -d myhost --dport aaaa -j REJECT --reject-with tcp-reset




....
For tcp, I tried the simpler
-A INPUT -d a.b.c.d/xx-p tcp -j REJECT --reject-with tcp-reset



.... but that didn't.  I wonder if anyone has any suggestions on how
to do this task more efficiently?  I'm happy with the ping response,
but natting tcp to a closed port seems kludgy.

Thanks in advance






On Thu, Nov 7, 2013 at 3:14 PM, Jim Mellander <jmellander@lbl.gov> wrote:
> Hi all:
>
> I'm working on replacing a freebsd box with custom C code with a linux box.
>
> The code has a configured pcap filter, and does the following with
> traffic that matches the pcap filter.  BTW, the pcap filter is not
> complex, basically 'tcp and (net a.b.c.d/xx or net e.f.g.h/xx)', so
> the equivalent should be easily mappable to iptables rules.
>
> 1. If TCP sends RST back as response (obviously not RST in response to RST)
> 2. Responds to pings, ICMP echo response sent in response to icmp echo request.
>
> I starting porting the code, but it occurred to me that perhaps the
> entire job could be done in iptables using DNAT
>
> 1. Nat the tcp connection and issue a -j REJECT, or redirect to a
> closed port on the the responder host, which will send a RST.
> 2. NAT the icmp echo request
>
> With a bit of experimentation, I'm fairly certain I could work this
> out, but some pointer to get me in the right direction would be
> appreciated.
>
> Thanks in advance.

Re: iptables as landmine subnet rejector

[Phil Oester]

On Wed, Nov 13, 2013 at 09:58:13AM -0800, Jim Mellander wrote:
> For tcp, I tried the simpler
> -A INPUT -d a.b.c.d/xx-p tcp -j REJECT --reject-with tcp-reset

If this isn't intended for the firewall itself, you should not
add this to the INPUT chain.  Try FORWARD instead.

Phil

Re: iptables as landmine subnet rejector

[Jim Mellander]

Thanks, I appreciate it, and it works fine.  However an analogous
method for UDP doesn't work correctly:

Below,
myip = host running the iptables that responds to...
landmine = subnet that is responded by myip (doesn't actually exist)
landmine_host = an ip in landmine subnet
bad_host = host on internet accessing landmine subnet

*nat
# nothing

*filter
-A FORWARD -d landmine -p udp -j REJECT


tcpdump output:
1384448210.669303 IP bad_host.23870 > landmine_host.61871: UDP, length 20
1384448210.669325 IP myip > bad_host ICMP bad_host udp port 61871
unreachable, length 56

Note that the ICMP port unreachable didn't come from landmine_host, as expected.



Here is natting all udp packets to myip, and the correct response
*nat
# UDP response for landmine nets
#  We send to a closed port, which causes the kernel to respond
-A PREROUTING -d landmine -p udp -j DNAT --to-destination myip:999

*filter
-A INPUT -p udp -d myip --dport 999 -j REJECT

tcpdump output:
1384447478.656874 IP bad_host.23703 > landmine_host.1819: UDP, length 20
1384447478.656887 IP landmine_host > bad_host: ICMP bad_host udp port
1819 unreachable, length 56


-----------------------------

I'm running SL 6.2 which is a recompile of RHEL 6.2 in case thats important

in sysctl.conf:

net.ipv4.ip_forward = 1


myip is where these landmine subnets are routed to, but they do not
really exist, we just want to respond to pings, tcp connection
attempts, and udp inbound

On Wed, Nov 13, 2013 at 2:17 PM, Phil Oester <kernel@linuxace.com> wrote:
> On Wed, Nov 13, 2013 at 09:58:13AM -0800, Jim Mellander wrote:
>> For tcp, I tried the simpler
>> -A INPUT -d a.b.c.d/xx-p tcp -j REJECT --reject-with tcp-reset
>
> If this isn't intended for the firewall itself, you should not
> add this to the INPUT chain.  Try FORWARD instead.
>
> Phil

Re: iptables as landmine subnet rejector

[Phil Oester]

On Thu, Nov 14, 2013 at 09:12:07AM -0800, Jim Mellander wrote:
> tcpdump output:
> 1384448210.669303 IP bad_host.23870 > landmine_host.61871: UDP, length 20
> 1384448210.669325 IP myip > bad_host ICMP bad_host udp port 61871
> unreachable, length 56
> 
> Note that the ICMP port unreachable didn't come from landmine_host, as expected.

That is how the REJECT target works.  The ICMP will come from the gateway.

Phil

Re: iptables as landmine subnet rejector

[Jim Mellander]

Thanks for the response!  I would expect that host_unreachable appear
to come from the gateway, but that a port_unreachable would appear to
come from the target host.  RFC 792 says: " Codes 0, 1, 4, and 5 may
be received from a gateway. Codes 2 and 3 may be received from a
host." - and I know that "may" doesn't mean "must", but the behavior
is different than what would be expected from traffic being sent to a
live host, and the port not being reachable.

In any event, I prefer the solution of NATing to a closed UDP port, as
the port_unreachable appears to come from the IP that the UDP packet
was sent to - I want to mimic as closely as possible the behavior of
hosts that are alive, but have no open ports.

On Tue, Nov 19, 2013 at 8:23 AM, Phil Oester <kernel@linuxace.com> wrote:
> On Thu, Nov 14, 2013 at 09:12:07AM -0800, Jim Mellander wrote:
>> tcpdump output:
>> 1384448210.669303 IP bad_host.23870 > landmine_host.61871: UDP, length 20
>> 1384448210.669325 IP myip > bad_host ICMP bad_host udp port 61871
>> unreachable, length 56
>>
>> Note that the ICMP port unreachable didn't come from landmine_host, as expected.
>
> That is how the REJECT target works.  The ICMP will come from the gateway.
>
> Phil