Re: [RFR] fwsnort package
On Oct 20, 2008, Franck Joncourt wrote:
> http://lists.debian.org/debian-l10n-english/2008/10/msg00034.html
>
> So that Michael can understand what we are talking about :)
> If you answer to this email, please CC Michael as well.
>
> Justin B Rye wrote:
> > Franck Joncourt wrote:
> >> ---- debian/control file
> >> Description: makes use of Snort rules in an iptables-based firewall
> >
> > That's a perfectly good verb phrase (saying what the package does);
> > but synopsis lines should be noun phrases (saying what it is).
> > Something like:
> >
> > Description: Snort rules converter for iptables
> > Description: firewall builder using Snort rules
> > Description: Snort-to-iptables rule translator
>
> I think I will take the third description :)
Agreed.
> >> Fwsnort translates Snort rules into iptables rule approximations and
> >> generates a Bourne shell script that implements the resulting iptables
> >> commands.
> >
> > When you say "iptables rule approximations", are they in fact only
> > approximate or should it be "equivalent iptables rules"?
> >
> > (It's possible that the pedantically correct term is "Netfilter
> > rules", or even "Xtables rules"...)
>
> According to me, they are equivalent. However my knowledge in writing
> snort rules is not good enough to trust me about that. So if Michael
> could answer to this question, that would make it clear.
Saying that the translated iptables rules are equivalent is probably
best in the sense that traffic that triggers a Snort rule will also be
matched by a translated iptables rule. However, there are cases where
the original Snort rule will trigger but the iptables rule will not.
For example, if an attacker splits an attack payload across multiple
packets in a TCP connection, then the Snort stream preprocessor can
reassemble the data before sending it to the pattern matcher, whereas
iptables cannot perform such a reassembly operation (well, technically
you could have iptables set a series of marks, but this gets far too
unwieldy too fast to be practical). iptables can match on connection
states very effectively, yes, but it won't reassemble payload data.
Also, Snort can normalize URL-encoded data before sending to the pattern
matcher, but iptables cannot. Of course, you can always write multiple
iptables rules to try and catch every combination of URL-encoded
characters in the original pattern, but obviously this becomes
impractical very quickly as the number of characters in the pattern
grows. So, technically, the translated iptables rules do not behave
exactly the same, and this is the source of the word "approximation".
But, most users will not know about this distinction and so from a
practical standpoint "equivalent" is probably best - though I should
perhaps document the above better in the fwsnort man page. ?
> From my point of view, I would talk about Netfilter layout with the
> different hooks, and Xtables add-ons that add new targets to iptables,
> and thus I think "iptables rules" is fine.
>
> Am I mistaken Michael ?
"iptables rules" is correct. Here is an excerpt from an email I
received from Pablo Neira Ayuso about the distinction between
"Netfilter and iptables" (this is in reference to my book):
<BEGIN Pablo email>
I still need more in-deep analysis about your work, so my comments are
just based on early impressions. I think that sometimes you say
netfilter when you mean iptables in chapter 2. You probably know this:
Netfilter is just the framework and the name of the project, iptables is
built on top of it, so it is iptables that has tables, chains, matches
and targets. So my question is: is everything in the book based on
iptables or you require some netfilter facilities at some point?
Depending on the answer you could use the term "iptables" or "netfilter"
in the book.
There is a in-kernel framework called netfilter. With this framework you
can implement functions that can be hooked to the network stack at
different stages (prerouting, input...). You can have a look at the file
core.c that lives in net/netfilter/. iptables is the userspace tool and
a set of modules that lives in kernel space, the userspace tool
basically parses the command-line and send to kernel space the rules in
a certain format. The kernel part of iptables is a set of modules that
implement functions that hooked to the stack by means of the netfilter
framework. So, basically you can build your own firewall tool on top of
the netfilter framework. I know, it can be a bit confusing.
So depending on what you talk you can use iptables or netfilter. Say you
talk about filtering, then you're likely to be using iptables since
netfilter does not filter itself, just provides the facilities to
implement a firewall. For example, the connection tracking system is
build on top of the netfilter framework, it is independent of iptables
but their interaction enable stateful filtering since iptables can
define filtering policies based on the information that the connection
tracking system provides.
</END Pablo email>
> > What does it mean these days to say something is a _Bourne_ shell
> > script? After all, it'll probably be dash that executes it...
>
> You are right.
> So, "generates a shell script that implements" should be better.
Agreed. I will fix this in the fwsnort man page as well.
> >> This ruleset allows network traffic that exhibits Snort signatures
> >> to be logged and/or dropped by iptables directly without putting any
> >> interface into promiscuous mode or queuing packets from kernel to
> >> user space.
> >
> > What ruleset is "This ruleset" referring to? The simplest fix would
> > be to take out the word "ruleset" and leave a vague "this" pointing
> > at the whole previous paragraph.
> >
> > Saying that traffic "exhibits" signatures seems obscure; couldn't it
> > just say it "matches" them?
>
> "This allows network traffic that matches Snort signatures"
>
> I would say that does not sound bad :p!
> I do not have any ideas that could go against your proposition.
Agreed. Saying "This allows network traffic that matches Snort
signatures..." is better. I will change this as well in the fwsnort man
page.
> >> ---- debian/README.Debian
> > ...
> >> ---- debian/fwsnort.templates
> >
> > These look fine to me.
>
> Ok.
Thanks for all of the useful comments.
--
Michael Rash
http://www.cipherdyne.org/
Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271
>
> Thanks,
>
> --
> Franck Joncourt
> http://debian.org - http://smhteam.info/wiki/
> Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE
>
Reply to: