the impossible "iptables -C" option

the impossible "iptables -C" option

[Bruno Negrão]

Hi guys, I didn't understand the following question and answer on
netfilter's faq:

"3.18 Why isn't the 'iptables -C' (--check) option implemented?

Well, first of all, we're lazy ;). To be honest, implementing a check
option is almost impossible as soon as you start to do stateful
firewalling. Traditional stateless firewalling bases it's decision just on
information present in the packets header. But with connection tracking
(and '-m state' based rules), the outcome of the filtering decision depends
on header+payload, as well as header+payload of previous packets within
this connection."

First of all, what does they mean about "--check"? What would they check?

What is "packet payload"? How does it make the "--check" option impossible
to be implemented?

thanks in advance,
bruno negrao

Re: the impossible "iptables -C" option

[Antony Stone]

On Saturday 24 July 2004 12:24 am, Bruno Negrão wrote:

> Hi guys, I didn't understand the following question and answer on
> netfilter's faq:
>
> "3.18 Why isn't the 'iptables -C' (--check) option implemented?
>
> Well, first of all, we're lazy ;). To be honest, implementing a check
> option is almost impossible as soon as you start to do stateful
> firewalling. Traditional stateless firewalling bases it's decision just on
> information present in the packets header. But with connection tracking
> (and '-m state' based rules), the outcome of the filtering decision depends
> on header+payload, as well as header+payload of previous packets within
> this connection."
>
> First of all, what does they mean about "--check"? What would they check?

I understand it to mean "check what would happen to a packet of this type if 
it went through the ruleset"

ie: iptables -C INPUT -p tcp --dport 22

Would tell you whether your firewall would accept (to itself) an SSH packet or 
not.

> What is "packet payload"? How does it make the "--check" option impossible
> to be implemented?

Payload is the data inside the packet (the useful bit beyond the IP / TCP / 
UDP etc headers).

It makes it impossible to implement --check because there's no way to provide 
the payload on the command line.

Regards,

Antony.

-- 
If you want to be happy for an hour, get drunk.
If you want to be happy for a year, get married.
If you want to be happy for a lifetime, get a garden.

                                                     Please reply to the list;
                                                           please don't CC me.

Re[2]: the impossible "iptables -C" option

[mortar]

Witam

Saturday, July 24, 2004, 9:56:03 AM, you wrote:

AS> It makes it impossible to implement --check because there's no way to provide
AS> the payload on the command line.

But maybe we can generate test packet and save it to a file, and then
test with --check? I dont know, it's just my improvisation :)

Anyway, there is another big problem described in FAQ: '-m state'
based rules, and I think this make this option hard to implement ;)

-- 
Pozdrawiam
 Marcin                            mailto:slacklist@op.pl

Re: the impossible "iptables -C" option

[Chris Brenton]

On Sat, 2004-07-24 at 03:56, Antony Stone wrote:
>
> I understand it to mean "check what would happen to a packet of this type if 
> it went through the ruleset"

Yup, that's what it did under ipchains. :)

> > What is "packet payload"? How does it make the "--check" option impossible
> > to be implemented?
> 
> It makes it impossible to implement --check because there's no way to provide 
> the payload on the command line.

Not quite true as you would just use a sting match, same as you would in
a filtering rule.

The problem is a majority of the time check would end up reporting "it
depends". For example what if you try and check what would happen to "a
packet coming from the Internet to an internal system from 22/TCP to an
upper port number, with the ACK flag set and "foo" in the payload. You
may not have a rule that specifically lets this traffic through, but it
might actually pass if it ends up being a state match due to an initial
outbound SYN packets. So how iptables would handle this packet "depends"
on what traffic went by prior to it.

The check option has said it would be implemented "real soon now" since
iptables was alpha code. I'm guessing the option will never happen. Its
just a carry over from ipchains. ;-)

HTH,
C

Re: the impossible "iptables -C" option

[Antony Stone]

On Saturday 24 July 2004 11:16 am, Chris Brenton wrote:

> On Sat, 2004-07-24 at 03:56, Antony Stone wrote:
> > I understand it to mean "check what would happen to a packet of this type
> > if it went through the ruleset"
>
> Yup, that's what it did under ipchains. :)
>
> > > What is "packet payload"? How does it make the "--check" option
> > > impossible to be implemented?
> >
> > It makes it impossible to implement --check because there's no way to
> > provide the payload on the command line.
>
> Not quite true as you would just use a sting match, same as you would in
> a filtering rule.

I'll assume you meant the "string" match :)   Although the idea of a sting 
match in a firewall rule is an interesting one....

I agree that for textual content you could say "a packet from this IP address 
to TCP port 23 containing the string 'root'", however lots of protocols use 
binary data (eg: ssh which encrypts the datastream, and http which commonly 
gzips it), and this would be hard to represent in a command-line request.

However, as discussed by other people, there is more than one reason why 
"check" is hard to implement, payload is just one of them (and I agree that 
state is a more significant problem, and much harder to deal with).

I don't believe it'll be implemented either.

Regards,

Antony.

-- 
All matter in the Universe can be placed into one of two categories:

1. Things which need to be fixed.
2. Things which need to be fixed once you've had a few minutes to play with 
them.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: the impossible "iptables -C" option

[Chris Brenton]

On Sat, 2004-07-24 at 06:27, Antony Stone wrote:
>
> > Not quite true as you would just use a sting match, same as you would in
> > a filtering rule.
> 
> I'll assume you meant the "string" match :)   Although the idea of a sting 
> match in a firewall rule is an interesting one....

Dooh! Typing before my morning Pepsi. I think we already sort of have a
"sting" option, its called "Tarpit" ;-)

> I agree that for textual content you could say "a packet from this IP address 
> to TCP port 23 containing the string 'root'", however lots of protocols use 
> binary data

Agreed but that's kind of outside of the scope of the check option. ;-)

We're getting more into "what does a better job of checking payload,
stateful inspection or proxy". I agree proxies are better when it comes
to payload content, but I find the string match useful mostly because of
its simplicity. No proprietary, undocumented language to learn, just set
a few command line switches and away you go. :)

> However, as discussed by other people, there is more than one reason why 
> "check" is hard to implement, payload is just one of them (and I agree that 
> state is a more significant problem, and much harder to deal with).

Ya why burn cycles on trying to code something you can easily check with
nmap, hping & tcpdump. ;-)

Cheers!
Chris

Re: the impossible "iptables -C" option

[Les Mikesell]

On Sat, 2004-07-24 at 05:16, Chris Brenton wrote:

> The problem is a majority of the time check would end up reporting "it
> depends". For example what if you try and check what would happen to "a
> packet coming from the Internet to an internal system from 22/TCP to an
> upper port number, with the ACK flag set and "foo" in the payload. You
> may not have a rule that specifically lets this traffic through, but it
> might actually pass if it ends up being a state match due to an initial
> outbound SYN packets. So how iptables would handle this packet "depends"
> on what traffic went by prior to it.

I'm not sure how that affects the ability to report what it would
do with a packet "right now" and why, or the users need for this
report when trying to debug a problem.  I have a situation where
I can see strange results with tcpdump and would like to know
what combination of rules is causing it.

---
  Les Mikesell
   les@futuresource.com

Re: the impossible "iptables -C" option

[Antony Stone]

On Saturday 24 July 2004 7:46 pm, Les Mikesell wrote:

> I have a situation where I can see strange results with tcpdump and would
> like to know what combination of rules is causing it.

I suggest you take some of the features you can see from the tcpdump output 
and create some logging rules to find out how far through your ruleset the 
packets are getting.

Regards,

Antony.

-- 
Tax inspectors are just accountants who work for the evil dictators of 
democracy.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: the impossible "iptables -C" option

[Les Mikesell]

On Sat, 2004-07-24 at 15:13, Antony Stone wrote:
> On Saturday 24 July 2004 7:46 pm, Les Mikesell wrote:
> 
> > I have a situation where I can see strange results with tcpdump and would
> > like to know what combination of rules is causing it.
> 
> I suggest you take some of the features you can see from the tcpdump output 
> and create some logging rules to find out how far through your ruleset the 
> packets are getting.

The problem is that in this case the rules are built by a perl
script that writes a shell script that lives in /etc/rc.d/init.d
and both contain variables and conditionals interpreted at
runtime.  The point of using this particular system is that
you normally don't have to understand how it all works because
the configuration is all scripted.  So it isn't 'my' rules
I want to see - I just want to know which of the existing
rules I have to work around.

I suppose I can build another one on an isolated network
where I can send only the packet types that are going wrong
and look at the counters on the rules, but it would be a
lot easier if iptables took a command that would simulate
a packet and at every point the counters on a rule would
increment it would log or display the match instead.

I think there might be a hint about what is happening in
/proc/net/ip_conntrack:
unknown  47 598 src=192.168.254.3 dst=192.168.254.1 [UNREPLIED]
src=192.168.254.1 dst=167.90.78.10 use=1

What is supposed to happen is that the cisco on eth1 sends
GRE packets from 192.168.254.3 (a loopback interface) to
192.168.254.1 (a loopback on the remote router) and these
are sent through the CIPE vpn interface by a static route.
Howver, it looks like it has somehow associated with the
address of eth0 (the 167.90.78.10 address).  Could this
make it source-nat subsequent packets incorrectly as they
go through the CIPE interface?

---
  Les Mikesell
   les@futuresource.com

Re: the impossible "iptables -C" option

[Antony Stone]

On Sunday 25 July 2004 6:50 pm, Les Mikesell wrote:

> On Sat, 2004-07-24 at 15:13, Antony Stone wrote:
> > On Saturday 24 July 2004 7:46 pm, Les Mikesell wrote:
> > > I have a situation where I can see strange results with tcpdump and
> > > would like to know what combination of rules is causing it.
> >
> > I suggest you take some of the features you can see from the tcpdump
> > output and create some logging rules to find out how far through your
> > ruleset the packets are getting.
>
> The problem is that in this case the rules are built by a perl
> script that writes a shell script that lives in /etc/rc.d/init.d
> and both contain variables and conditionals interpreted at
> runtime.  The point of using this particular system is that
> you normally don't have to understand how it all works because
> the configuration is all scripted.  So it isn't 'my' rules
> I want to see - I just want to know which of the existing
> rules I have to work around.

Well, you can find out what the ruleset really is once it's all been scripted, 
run and installed, by asking netfilter for a listing:

iptables -L -nvx; iptables -L -t nat -nvx

Then you can can add LOGging rules at whatever points you like in the ruleset 
by using "-I CHAIN #" where # is the position you want the rule to occupy.

You could even take this to an extreme and insert a LOGging rule between every 
two other rules with a little script of your own:

for((a=2;a<100;a+=2))
do
  iptables -I FORWARD $a -j LOG --log-prefix="rule $a "
done

(assuming you have 50 rules at present, so the last new LOG rule needs to go 
in position 100)

This will create some verbose output, but you'll certainly find out what's 
happening to your packets...

Regards,

Antony.

-- 
I don't know, maybe if we all waited then cosmic rays would write all our 
software for us. Of course it might take a while.

 - Ron Minnich, Los Alamos National Laboratory

                                                     Please reply to the list;
                                                           please don't CC me.