Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.development.system > #560 > unrolled thread

Question using libiptc

Back to article view | Back to comp.os.linux.development.system

Contents

  Question using libiptc Jeremy Brown <bjeremy32@gmail.com> - 2013-10-24 13:32 -0700
    Re: Question using libiptc Richard Kettlewell <rjk@greenend.org.uk> - 2013-10-24 21:39 +0100
      Re: Question using libiptc Jeremy Brown <bjeremy32@gmail.com> - 2013-10-24 13:56 -0700
        Re: Question using libiptc Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-10-24 22:37 +0100
          Re: Question using libiptc Jeremy Brown <bjeremy32@gmail.com> - 2013-10-24 15:19 -0700
            Re: Question using libiptc Jeremy Brown <bjeremy32@gmail.com> - 2013-10-24 15:25 -0700
            Re: Question using libiptc Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-10-25 15:38 +0100
              Re: Question using libiptc Jeremy Brown <bjeremy32@gmail.com> - 2013-10-25 11:04 -0700
                Re: Question using libiptc Jeremy Brown <bjeremy32@gmail.com> - 2013-10-25 12:04 -0700
    Re: Question using libiptc Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-10-25 13:34 +0000
      Re: Question using libiptc Jeremy Brown <bjeremy32@gmail.com> - 2013-10-25 07:26 -0700
        Re: Question using libiptc Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-10-25 21:20 +0100
          Re: Question using libiptc Jeremy Brown <bjeremy32@gmail.com> - 2013-10-25 14:23 -0700
          Re: Question using libiptc Richard Kettlewell <rjk@greenend.org.uk> - 2013-10-25 22:27 +0100
            Re: Question using libiptc Richard Kettlewell <rjk@greenend.org.uk> - 2013-10-25 22:29 +0100
              Re: Question using libiptc Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-10-25 22:43 +0100

#560 — Question using libiptc

Greetings,

I have a little c program that will use the libiptc api that will dynamically add rules to iptables. To try and circumvent responses asking me why I want to do this instead of using system(), the reason is I wish to dynamically update the iptables from an external program and the entries will only be known at runtime. I also wish to have feedback as to the success or failure of these aditions/deletions.

In any event, the test program works for standard targets (i.e. Accept, Drop, etc), however I can not find a way to use -j TEE. I always seem to get the same error on iptc_commit: "No chain/target/match by that name". However I did verify that the xt_TEE module is loaded, and that I could add entries using -j TEE by hand on the command line.

I'm sure it is a matter of filling out the struct xt_standard_target incorrectly (or using a different target struct entirely).  I'm not sure how to do that for tee or the xt_tee_tginfo (--gateway) that will also be needed.

I was wondering if someone may have sample code for provisioning that target that could help me do this.

Jeremy

[toc] | [next] | [standalone]

#561

Jeremy Brown <bjeremy32@gmail.com> writes:
> I was wondering if someone may have sample code for provisioning that
> target that could help me do this.

Inspect the source to iptables and see what it does?

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#562

> 
> Inspect the source to iptables and see what it does?


Hmmm... actually I am, are you familiar with that code enough that you could actually answer questions or will they be more of the same helpful suggestions?

[toc] | [prev] | [next] | [standalone]

#563

Jeremy Brown <bjeremy32@gmail.com> writes:
>> Inspect the source to iptables and see what it does?
>
>
> Hmmm... actually I am, are you familiar with that code enough that you
> could actually answer questions or will they be more of the same
> helpful suggestions?

Ehh ... sorry ... but iptables has code demonstrating how create a
firewall rule jumping to an extension target. I'm not particularly
familiar with this code as I have added only 1 - 2 new features to it
but it isn't that complicated, just fairly byzantine. Judgeing from the
code of the version I looked at (1.4.8, used in the product of my
employer), you will need the extension code for any extension you want
to use in addition to the libiptc code.

This means the short answer to your problem statement is: Use iptables.

[toc] | [prev] | [next] | [standalone]

#564

> 
> Ehh ... sorry ... but iptables has code demonstrating how create a
> 
> firewall rule jumping to an extension target. 

Which file are you referring to?

[toc] | [prev] | [next] | [standalone]

#565

On Thursday, October 24, 2013 5:19:30 PM UTC-5, Jeremy Brown wrote:
> > 
> 
> > Ehh ... sorry ... but iptables has code demonstrating how create a
> 
> > 
> 
> > firewall rule jumping to an extension target. 
> 
> 
> 
> Which file are you referring to?

Actually... I think I got passed one problem.. I wasn't setting my target revision correctly... It seems now it recognizes "TEE" for a target user name, now I just need to look at filling out the xt_tee_tginfo correctly.

[toc] | [prev] | [next] | [standalone]

#568

Jeremy Brown <bjeremy32@gmail.com> writes:
>> 
>> Ehh ... sorry ... but iptables has code demonstrating how create a
>> 
>> firewall rule jumping to an extension target. 
>
> Which file are you referring to?

iptables.c, the do_command routine and what is called from that (when
processing -j).

[toc] | [prev] | [next] | [standalone]

#569

> iptables.c, the do_command routine and what is called from that (when
> 
> processing -j).

Yes.., I've been looking at the iptables code. I can see that we need to add the tee_tg_info struct to the xt_standard_target->data.. But apparently the parser does not like something. I can add the command manually, so I know its something in the code, either the size or offset is wrong or I'm not setting some...

Anyway, I attached the simple test code that I'm using in case anyone can spot the error.

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

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <libiptc/libiptc.h>
#include <arpa/inet.h>
#include <linux/netfilter/x_tables.h>
#include <linux/netfilter/xt_TEE.h>

static int
insert_rule (const char *table,
        const char *chain,
        unsigned int src,
        unsigned int smask,
        unsigned short sport,
        int inverted_src,
        unsigned int dest,
        unsigned int dmask,
        unsigned short dport,
        int inverted_dst,
        unsigned short proto,
        const char *target)
{
   printf ("insert_rule entry\n");
  
   struct ipt_entry* entry;
   struct ipt_entry_target* ipt_entry_target;
   struct xt_tee_tginfo* tee_info;
  
   unsigned int size_ipt_entry, size_target, total_length, size_tee_tg_info;
  
   struct iptc_handle *h;
   int ret = 1;
  
  
   size_ipt_entry = XT_ALIGN(sizeof (struct ipt_entry));
  
   size_target =  XT_ALIGN(sizeof (struct xt_standard_target));
  
   size_tee_tg_info = XT_ALIGN(sizeof(struct xt_tee_tginfo));
  
   total_length = size_ipt_entry + size_target + size_tee_tg_info;

   entry = (struct ipt_entry*)calloc(1, total_length);
   if (entry == NULL)
   {
      printf("malloc failed!\n");
      exit(1);
   }
   
   entry->target_offset = size_ipt_entry;
   entry->next_offset = total_length;
  

   /* target */
  
   ipt_entry_target = (struct ipt_entry_target* ) (entry->elems);
   ipt_entry_target->u.user.target_size = size_target + size_tee_tg_info;
  
                                                     
   ipt_entry_target->u.user.revision=1;
   strncpy (ipt_entry_target->u.user.name, target, sizeof (ipt_entry_target->u.user.name));
  
   tee_info =  (struct xt_tee_tginfo*) (ipt_entry_target->data);
   tee_info->gw.in.s_addr=0x0a0a0b0c;
  
   if (src)
   {
      entry->ip.src.s_addr = src;
      entry->ip.smsk.s_addr = smask;
      if (inverted_src)
         entry->ip.invflags |= IPT_INV_SRCIP;
   }

   if (dest)
   {
      entry->ip.dst.s_addr = dest;
      entry->ip.dmsk.s_addr = dmask;
      if (inverted_dst)
         entry->ip.invflags |= IPT_INV_DSTIP;
   }

   if (proto)
   {
      entry->ip.proto = proto;
   }

   h = iptc_init (table);
   if (!h)
   {
      printf ("Could not init IPTC library: %s\n", iptc_strerror (errno));
      goto out;
   }

   if (!iptc_append_entry (chain, (struct ipt_entry *) entry, h))
   {
      printf ("Could not insert a rule in iptables (table %s): %s\n", table, iptc_strerror (errno));
      goto out;
   }

   if (!iptc_commit (h))
   {
      printf ("Could not commit changes in iptables (table %s): %s\n", table, iptc_strerror (errno));
      goto out;
   }

   ret = 0;

out:
   if (h)
   iptc_free (h);

   return ret;
}

int main (int argc, char **argv)
{
   unsigned int a, b;

    printf ("main entry\n");
   inet_pton (AF_INET, "1.2.3.4", &a);
   inet_pton (AF_INET, "1.2.3.5", &b);

   insert_rule("filter",
               "INPUT",
               a,
               htonl(0xffffff00),
               8888,
               0,
               b,
               htonl(0xffffff00),
               7777,
               0,
               0,
               "TEE");

   return 0;
}

[toc] | [prev] | [next] | [standalone]

#570

On Friday, October 25, 2013 1:04:07 PM UTC-5, Jeremy Brown wrote:
> > iptables.c, the do_command routine and what is called from that (when
> 
> > 
> 
> > processing -j).
> 

Problem solved... For some reason it took me a while to realize I could dmesg the error and it turns out there is a problem with XT_ALIGN(sizeof xt_tee_tginfo) where it was returning the sizeof the stuct as 44 bytes, but the kernel was expecting 40 bytes. After tweaking, everything is working as expected.

[toc] | [prev] | [next] | [standalone]

#566

On Thu, 2013-10-24, Jeremy Brown wrote:
> Greetings,
>

> I have a little c program that will use the libiptc api that will
> dynamically add rules to iptables. To try and circumvent responses
> asking me why I want to do this instead of using system(), the reason
> is I wish to dynamically update the iptables from an external program
> and the entries will only be known at runtime. I also wish to have
> feedback as to the success or failure of these aditions/deletions.

I'm not really asking you why, but I note that your requirements don't
exclude using iptables(8) ... For example, I assume it has a useful
exit code like any sensible Unix utility.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#567

On Friday, October 25, 2013 8:34:47 AM UTC-5, Jorgen Grahn wrote:
> On Thu, 2013-10-24, Jeremy Brown wrote:
> 
> > Greetings,
> 
> >
> 
> 
> 
> > I have a little c program that will use the libiptc api that will
> 
> > dynamically add rules to iptables. To try and circumvent responses
> 
> > asking me why I want to do this instead of using system(), the reason
> 
> > is I wish to dynamically update the iptables from an external program
> 
> > and the entries will only be known at runtime. I also wish to have
> 
> > feedback as to the success or failure of these aditions/deletions.
> 
> 
> 
> I'm not really asking you why, but I note that your requirements don't
> 
> exclude using iptables(8) ... For example, I assume it has a useful
> 
> exit code like any sensible Unix utility.
> 
> 
> 
> /Jorgen
> 
> 
> 
> -- 
> 
>   // Jorgen Grahn <grahn@  Oo  o.   .     .
> 
> \X/     snipabacken.se>   O  o   .

In this case the number of rule updates can be frequent and performance does matter.

[toc] | [prev] | [next] | [standalone]

#571

Jeremy Brown <bjeremy32@gmail.com> writes:
> On Friday, October 25, 2013 8:34:47 AM UTC-5, Jorgen Grahn wrote:
>> On Thu, 2013-10-24, Jeremy Brown wrote:
>> > I have a little c program that will use the libiptc api that will
>> > dynamically add rules to iptables. To try and circumvent responses
>> > asking me why I want to do this instead of using system(), the reason
>> > is I wish to dynamically update the iptables from an external program
>> > and the entries will only be known at runtime. I also wish to have
>> > feedback as to the success or failure of these aditions/deletions.
>> 
>> I'm not really asking you why, but I note that your requirements don't
>> exclude using iptables(8) ... For example, I assume it has a useful
>> exit code like any sensible Unix utility.
>
> In this case the number of rule updates can be frequent and
> performance does matter.

Something I did in the past for an embedded system (based on a 200Mhz
ARM9 CPU) after invoking iptables for each rule was found to be a
performance problem: I changed that such that it read 'iptables
commands' from standard input and executed them. Putting an iptables
process on one end of a socketpair (could use SOCK_DGRAM so that there
wouldn't be a need to parse the input) and using a simple, bidirectional
protocol, eg control process sends command, iptables replies with OK or
ERROR, would be an option.

This would just require some (fairly simple) modifications to the driver
program (iptables) and would then work with all compatible extensions
without the need to duplicate the extension-specific code creating the
necessary data structures for each and every extension.

[toc] | [prev] | [next] | [standalone]

#572

> 
> This would just require some (fairly simple) modifications to the driver
> 
> program (iptables) and would then work with all compatible extensions
> 
> without the need to duplicate the extension-specific code creating the
> 
> necessary data structures for each and every extension.

thanks for the input.

[toc] | [prev] | [next] | [standalone]

#573

Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> Something I did in the past for an embedded system (based on a 200Mhz
> ARM9 CPU) after invoking iptables for each rule was found to be a
> performance problem: I changed that such that it read 'iptables
> commands' from standard input and executed them. Putting an iptables
> process on one end of a socketpair (could use SOCK_DGRAM so that there
> wouldn't be a need to parse the input) and using a simple, bidirectional
> protocol, eg control process sends command, iptables replies with OK or
> ERROR, would be an option.
>
> This would just require some (fairly simple) modifications to the driver
> program (iptables) and would then work with all compatible extensions
> without the need to duplicate the extension-specific code creating the
> necessary data structures for each and every extension.

Sounds suspiciously like iptables-save?

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#574

Richard Kettlewell <rjk@greenend.org.uk> writes:
> Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
>> Something I did in the past for an embedded system (based on a 200Mhz
>> ARM9 CPU) after invoking iptables for each rule was found to be a
>> performance problem: I changed that such that it read 'iptables
>> commands' from standard input and executed them. Putting an iptables
>> process on one end of a socketpair (could use SOCK_DGRAM so that there
>> wouldn't be a need to parse the input) and using a simple, bidirectional
>> protocol, eg control process sends command, iptables replies with OK or
>> ERROR, would be an option.
>>
>> This would just require some (fairly simple) modifications to the driver
>> program (iptables) and would then work with all compatible extensions
>> without the need to duplicate the extension-specific code creating the
>> necessary data structures for each and every extension.
>
> Sounds suspiciously like iptables-save?

I mean iptables-restore, of course.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#575

Richard Kettlewell <rjk@greenend.org.uk> writes:
> Richard Kettlewell <rjk@greenend.org.uk> writes:
>> Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
>>> Something I did in the past for an embedded system (based on a 200Mhz
>>> ARM9 CPU) after invoking iptables for each rule was found to be a
>>> performance problem: I changed that such that it read 'iptables
>>> commands' from standard input and executed them. Putting an iptables
>>> process on one end of a socketpair (could use SOCK_DGRAM so that there
>>> wouldn't be a need to parse the input) and using a simple, bidirectional
>>> protocol, eg control process sends command, iptables replies with OK or
>>> ERROR, would be an option.
>>>
>>> This would just require some (fairly simple) modifications to the driver
>>> program (iptables) and would then work with all compatible extensions
>>> without the need to duplicate the extension-specific code creating the
>>> necessary data structures for each and every extension.
>>
>> Sounds suspiciously like iptables-save?
>
> I mean iptables-restore, of course.

Not quite: restore/ save work with a specific text file format supposed to
exchange the complete packet-filter configuration and with some totally
bizarre parser implementation. Since I already had code to generate the
necessary arguments for calling iptables, all I wanted was to execute
these without starting a new process for every rule.

It is also somewhat pointless to have the control program create real
'shell command lines' including quoting and then let iptables
'unshellcommand' these instead of just sending the number of arguments
in binary, followed by the 'contents' of an argv-vector, ie, a sequence
of 0-terminated strings. For this case, the receiving process gets a
'message' including all the necessary information in one go (AF_UNIX
SOCK_DGRAM), allocates a char *[] of the required size and populates
that with a single pass through the message without the need to do any
kind of fancy syntactical analysis.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.development.system

csiph-web