Re: On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)
Quoting Javier Fernández-Sanguino Peña (jfs@computer.org):
> > Thus, it can't detect potentially harmful traffic.
> That's not correct, it cannot detected _new_ potentially harmful traffic.
> There's quite a lot of potentially harmful traffic (stable) snort can
> detect. The fact that it's not up-to-date does not mean that it's useless,
> it means that it won't detect new attacks (but it will detect old attacks).
> Depending on your security policy that might, or might not, be enough.
If you don't care that much about security, snort isn't the right tool
anyhow. Snort starts raising hell when a large ping packet comes across
your interface, someone with such a low security interrest as you
described would go nuts with snort. But, that aside, cause it's not what
this is all about ;)
> Really, the way to fix this package X needs data Y to be up-to-date is to:
> a) separate data from the package (Nessus plugins are available in the
> 'nessus-plugins' package and can be updated separately, for example)
snort has that. snort-rules-default is the default set of rules found on
snort.org for the release that is in debian, almost always updated when a
new debian-release of the package is done. People can start packaging
their own rulesets, maybe even local rulesets or something.
> b) provide some way to retrieve new data (signatures, attacks, whatever)
> either: downloading them from the main site directly (as
> nessus-update-plugins does) or providing backported packages (and have them
> included in stable revisiones.
This problem only exists for snort packages that aren't going to be
updated, like the ones that reach stable. The unstable package is up to
date enough to have all correct rules, imho.
The other thing is, snort.org's people quickly start to drop old rule
formats when newer formats are used. Should I be the one that has to
convert every rule back to the old format to have stable users of snort
safe and sound? It'll take alot of time. And I believe it is not always
scriptable.
So, although it sounds nice to have scripts to update rulefiles, I don't
really see it happening, because of the problems amentioned above.
> c) have a way to determine properly when new data needs a new engine and
> won't work with older versions and warn the user about it. This means that
> the engine needs to be programmed beforehand to understand a given dataset
> version and complain when the dataset is of a newer (and potentially
> worthless) version.
Well. Snort just fails to start if it can't parse the rule files. And
usually that is with every major upstream release. :(
Sander.
--
| Ik zit met een dilemma en ik heb geen flauw idee wat ik ermee moet doen
| 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D
Reply to: