Generating Ethernet Header in Prerouting?

Generating Ethernet Header in Prerouting?

[Nader Al-Naji]

Hello, I'm writing a netfilter prerouting hook and my goal is to intercept an incoming packet, change the IP  information, ports, etc.. and send it back to the host it came from (and hopefully other hosts once I get this working) without ever exposing it to the higher layers. I'm modifying the packet information, making enough space for an ethernet header to be written (but not writing any ethernet information myself), and then calling dev_queue_xmit and returning NF_STOLEN. The problem I'm running into is the ethernet header is incorrect; it's actually uaually backwards, ie src followed by dst just the way it came in and appears to not send at all when random IP's are written. I was actually quite surprised when I found out that dev_queue_xmit apparently does some ARP'ing; I still don't q
 uite see where the ARP'ing happens in the code. That said, I'm pretty sure it's just an ARP table look-up gone awry. I was wondering if anyone could help me out. I've been looking this up online for a while now and nobody really has any good information on how to send a packet before a struct sock is attained, which is the case in prerouting.

This is a snippet the offending code. I would really appreciate any help at all. And if more information is needed let me know!:

//The main hook function
static unsigned int myhook_in_func(unsigned int hooknum,
               struct sk_buff *skb,
               const struct net_device *in,
               const struct net_device *out,
               int (*okfn)(struct sk_buff *))
{
      .....
      MODIFY THE PACKET IN SOME WAY HERE.
      .....

      skb_push(skb, ETH_HLEN);
      dev_queue_xmit(skb);

     return NF_STOLEN;
}

//This is a netfilter hook.
static struct nf_hook_ops my_hook_in =
{
       .hook = myhook_in_func, // Function that executes when a packet hits this hook.
       .hooknum = NF_IP_PRE_ROUTING, // For inbound traffic only.
       .pf = PF_INET, // Only for IP packets.
       .priority = NF_IP_PRI_FIRST, // My hook executes first.
};

static int __init my_hook_init(void)
{
       printk(KERN_ALERT "Starting up!\n");
       nf_register_hook(&my_hook_in);
       start_time = jiffies;
       return 0;
}

static void __exit my_hook_exit(void)
{
       printk(KERN_ALERT "Exiting...\n");
       nf_unregister_hook(&my_hook_in);
}

MODULE_LICENSE("GPL");
module_init(my_hook_init);
module_exit(my_hook_exit);

Thanks in advance!
--Nader Al-Naji

Iptables State Table

[netfilter]

Given the following simplified rules:
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

When the system boots, various daemons create persistent connections
that stay established indefinitely to authentication servers like the
following:
clientSytem:44444 ----->  authServer:389
This creates an entry in the iptables state table which works fine. 
But, occasionally the state table gets cleared out.  Usually by
something simple like someone restarting iptables. Once that happens the
established connection is still there, but when the authServer sends a
packet back to the clientSystem the packet is viewed as new and
eventually gets dropped since their is nothing in the state table.  The
only way I can think of allowing for this is to create a rule that
allows new connections from the authServer:389 to the clientSystem:any. 
Is there a better way?

Re: Iptables State Table

[netfilter]

On Thu, 07 Jul 2011 16:12 +0100, "Jonathan Tripathy"
<jonnyt@abpni.co.uk> wrote:
> 
> 
> netfilter@buglecreek">netfilter@buglecreek.com wrote:
> > Given the following simplified rules:
> > iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
> > iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
> >
> > When the system boots, various daemons create persistent connections
> > that stay established indefinitely to authentication servers like the
> > following:
> > clientSytem:44444 ----->  authServer:389
> > This creates an entry in the iptables state table which works fine. 
> > But, occasionally the state table gets cleared out.  Usually by
> > something simple like someone restarting iptables. Once that happens the
> > established connection is still there, but when the authServer sends a
> > packet back to the clientSystem the packet is viewed as new and
> > eventually gets dropped since their is nothing in the state table.  The
> > only way I can think of allowing for this is to create a rule that
> > allows new connections from the authServer:389 to the clientSystem:any. 
> > Is there a better way?
> > --
> > 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
> >   
> Shouldn't the software in question detect a connection drop and then 
> re-attempt to connect to the server?
> 
The connection never drops.  Netstat shows the connection as
ESTABLISHED, but the iptables state table does not have the connection
since it was cleared.  So, if there were no iptables running the
connection would carry on normal comms. Since there are rules that only
allow established connections the packet gets dropped due to the
clearing of the state table. Hope that makes sense.

Re: Iptables State Table

[Jonathan Tripathy]

netfilter@buglecreek.com wrote:
> 
> On Thu, 07 Jul 2011 16:12 +0100, "Jonathan Tripathy"
> <jonnyt@abpni.co.uk> wrote:
>>
>> netfilter@buglecreek">netfilter@buglecreek.com wrote:
>>> Given the following simplified rules:
>>> iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
>>> iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>>>
>>> When the system boots, various daemons create persistent connections
>>> that stay established indefinitely to authentication servers like the
>>> following:
>>> clientSytem:44444 ----->  authServer:389
>>> This creates an entry in the iptables state table which works fine. 
>>> But, occasionally the state table gets cleared out.  Usually by
>>> something simple like someone restarting iptables. Once that happens the
>>> established connection is still there, but when the authServer sends a
>>> packet back to the clientSystem the packet is viewed as new and
>>> eventually gets dropped since their is nothing in the state table.  The
>>> only way I can think of allowing for this is to create a rule that
>>> allows new connections from the authServer:389 to the clientSystem:any. 
>>> Is there a better way?
>>> --
>>> 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
>>>   
>> Shouldn't the software in question detect a connection drop and then 
>> re-attempt to connect to the server?
>>
> The connection never drops.  Netstat shows the connection as
> ESTABLISHED, but the iptables state table does not have the connection
> since it was cleared.  So, if there were no iptables running the
> connection would carry on normal comms. Since there are rules that only
> allow established connections the packet gets dropped due to the
> clearing of the state table. Hope that makes sense.

Yes, I understand what's happening :)

What I am confused about though is why netstat is showing the state as 
still ESTABLISHED. Surely if the packets can't get through the filter, 
this should be class as an effective connection drop, so the software 
should restart the connection?

Most good firewalls (not just iptables) include a feature to reset the 
state table. I know that if I reset the state table in my firewall, all 
connections are effectively dropped and the individual bits of software 
running throughout the LAN will re-connect.

Re: Iptables State Table

[Jan Engelhardt]

On Thursday 2011-07-07 18:33, Jonathan Tripathy wrote:
>>> netfilter@buglecreek">netfilter@buglecreek.com wrote:
>>>> Given the following simplified rules:
>>>> iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
>>>> iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Use -m conntrack.

>>>> When the system boots, various daemons create persistent connections
>>>> that stay established indefinitely to authentication servers like the
>>>> following:
>>>> clientSytem:44444 ----->  authServer:389
>>>> This creates an entry in the iptables state table which works fine.

Nope, it creates an entry in nf_conntrack's connection tracking table,
besides also creating a TCB in each of the connections endpoints.

>>>> Once that happens the
>>>> established connection is still there, but when the authServer sends a
>>>> packet back to the clientSystem the packet is viewed as new and
>>>> eventually gets dropped since their is nothing in the state table.

(Slight nitpick.) If there is no entry in the CT table, there is no
room to store a state like NEW.

>>>> The only way I can think of allowing for this is to create a rule that
>>>> allows new connections from the authServer:389 to the clientSystem:any. Is
>>>> there a better way?

NFCT has a sysctl net.netfilter.nf_conntrack_tcp_be_liberal that, if set
to 1, can pick up TCP connections from something else than a SYN.

>>> Shouldn't the software in question detect a connection drop and then
>>> re-attempt to connect to the server?

Yes, though it may take a longer time for the TCB timeout to expire.
If it is a local network service, sending RSTs, i.e. letting extraneous
packets run into a reject-type rule, is thus preferred.

>> The connection never drops.  Netstat shows the connection as
>> ESTABLISHED

Use ss(8). netstat is of the same type of unmaintained buggy tools like
ifconfig-it's a pest.

>> but the iptables state table does not have the connection
>> since it was cleared.  So, if there were no iptables running the

(iptables always runs unless you unload the kernel module.)

>> connection would carry on normal comms. Since there are rules that only
>> allow established connections the packet gets dropped due to the
>> clearing of the state table. Hope that makes sense.

So make sure that the NFCT entry does not expire. Normally, it
should follow the TCB lifetime, which is like, 5 days.

> What I am confused about though is why netstat is showing the state as still
> ESTABLISHED.

ss/netstat shows the TCB state, *not* the NFCT state!

> Most good firewalls (not just iptables) include a feature to reset the state
> table.

Which is `conntrack -F` on Linux.


[And for God's sake, don't strip the Cc list.]