-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 25 August 2005 06:56, Derick Anderson wrote:
> Out of curiosity (and the lack of fully understanding your intent), how
> would this DTD validate a ruleset? I imagine you'd be trying to go
> beyond syntax since netfilter will tell you when you do something silly
> like a --dport without a -p tcp|udp anyway. If that's so, what is your
> standard for failure of a ruleset? Or success of a ruleset?
The DTD is simply the document model by which the rule and/or rulesets can be
applied against.
This project can in no way perform logical evaluation of the rules. By this I
mean the following: say you want to rate-limit incoming type 8 ping messages.
To do so you would construct the following rules:
iptables -A INPUT -i eth0 -p icmp --icmp-type echo-request \
-m limit --limit 1/second -j ACCEPT
iptables -A INPUT -i eth0 -p icmp --icmp-type echo-request -j DROP
Using logical evaluation of these rules, we can determine the following with
respect to the pair:
- - Utilization of one rule without the other results in a completely different
behavior.
- - They must be introduced to netfilter in the order they are given --
otherwise the same is true again.
- - Both rules should be introduced adjacently. Otherwise there is chance for
another rule to intervene.
None of this can be performed by a DTD or an XML markup language. These
however can be evaluated as you say by use of an XSL stylesheet.
The DTD simply validates against a known and programmed structure. The
advantages of using XML and this approach are such:
- - Easy to develop according to the structured document model.
- - Anybody can construct new rules with a minimal effort of syntactical
correctness.
- - The netfiler rules can be processed with a custom stylesheet to produce
equivalent rules and/or rulesets in other forms for perimeter devices not
consistent with the netfilter syntax(other firewalls, routers, etc...).
- - The netfiler rules can be processed with a custom stylesheet to evaluate the
logical structure/intent of a given ruleset.
- - The rules can be digitally signed and encrypted by the administrative entity
to secure the content. This ensures that confidentiality and integrity of the
resources are intact.
- - The XML Security function(s) are standards-based. So inclusion into
regulatory requirements can be easily introduced without complications. i.e.
SOX
> I can submit
> a working ruleset that isn't optimal (accepting RELATED,ESTABLISHED
> connections as the last rule, for example) or that checks src/dst IPs
> but not which interface...
I am not here to judge yourself or the logical purpose of your rules. I simply
want to contribute to the community. None of my projects are for profit.
However, I do think that it could be a good starting point for new users to
the netfilter framework to be able to construct valid rules and/or rulesets.
> Admittedly I don't know that much about XML and DTDs. I don't know how
> powerful DTDs can be, but it seems to me like you'd need a high-level
> programming language in order to test for more than syntactical
> correctness.
That is a totally different beast. This is where the XSL stylesheets come into
play.
> A simulation environment for Netfilter rules is something
> I'd really like to see.
Agreed. Construction of pseudo datagrams and testing for resultant outcomes
would be a very interesting project.
Cheers,
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFDDddIoR5cE1e/kEIRAqn0AKDc0iJETnOHYDBWOQlekweswOj3sQCeIo/6
LhSsuJbNwjqcG9fSmV5Hw2U=
=0+PB
-----END PGP SIGNATURE-----
