You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I very much like the idea behind fwsnort, it seems to be a very nifty utility. I happened to try it out, but I have stumbled upon a few thing that are not quite clear to me.
I have attempted to find some answers in your book Linux Firewalls: Attack Detection and Response with iptables, psad, and fwsnort, but I was only partially successful.
So, may I to ask you a few questions, please?
It seems that fwsnort has been cooperating mainly with snort-rules from emerging-threats.net and they are compatible as much as possible (I see why pcre field is hard to convert). However, Snort also features with their own native set of rules (regardless if with paid VRT subscription or not) and their format seems to be a bit different and fwsnort happens to fail on them completely.
Does fwsnort plan to support or test against these rules as well? I don't really understand why it seems not to, when these are the "primary" rules for Snort.
Digging a little deeper, I have learned a few reasons why Snort VRT rules don't work. Putting the pcre situations aside, often the problem is presence of:
a) byte_test and byte_jump
b) metadata field
From what I read in you book (page 171 - section Unsupported Snort Rule Options), byte_test, byte_jump and similar rely on u32 iptables module, which is now very much available for current kernels and iptables version. I have noticed that u32 support is also enlisted in your TODO. Do you think these features and u32 support might be available any time soon?
Regarding the metadata field, as I understand the situation, this usually describes either IPS action to be taken (e.g. drop) or some sort of extra information. In the first case, conversion to iptables seems clear to me (-j DROP perhaps), in the second case I can see that users might be okay with discarding this information in order to conversion otherwise to succeed.
Could you comment on these topic when you have a minute?
Regards,
Dan
The text was updated successfully, but these errors were encountered:
Yes, indeed the u32 module is required for byte_test and byte_jump conversions, and I do plan to add support for these keywords in the next release of fwsnort (although this is going to be a while since I'm deep in fwknop development right now). Agreed on the metadata field as well - some functionality seems like a faithful translation could be made, or metadata could be ignored completely. If you want ignore it with the current fwsnort release, then just apply the following patch:
so I created a patch for metadata parsing. I don't know Perl much, I understand it might not be the nicest coding ever, but it seems to work for my needs, at least for now.
http://pastebin.com/Nu1Bhy1e
You may incorporate it in your source or other users might use it, too. Perhaps it will help someone :)
Hi,
I very much like the idea behind fwsnort, it seems to be a very nifty utility. I happened to try it out, but I have stumbled upon a few thing that are not quite clear to me.
I have attempted to find some answers in your book Linux Firewalls: Attack Detection and Response with iptables, psad, and fwsnort, but I was only partially successful.
So, may I to ask you a few questions, please?
pcre
field is hard to convert). However, Snort also features with their own native set of rules (regardless if with paid VRT subscription or not) and their format seems to be a bit different and fwsnort happens to fail on them completely.Does fwsnort plan to support or test against these rules as well? I don't really understand why it seems not to, when these are the "primary" rules for Snort.
pcre
situations aside, often the problem is presence of:a)
byte_test
andbyte_jump
b)
metadata
fieldFrom what I read in you book (page 171 - section Unsupported Snort Rule Options),
byte_test
,byte_jump
and similar rely onu32
iptables module, which is now very much available for current kernels and iptables version. I have noticed thatu32
support is also enlisted in your TODO. Do you think these features andu32
support might be available any time soon?Regarding the
metadata
field, as I understand the situation, this usually describes either IPS action to be taken (e.g.drop
) or some sort of extra information. In the first case, conversion to iptables seems clear to me (-j DROP
perhaps), in the second case I can see that users might be okay with discarding this information in order to conversion otherwise to succeed.Could you comment on these topic when you have a minute?
Regards,
Dan
The text was updated successfully, but these errors were encountered: