On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)
On Sun, Aug 24, 2003 at 07:32:10PM -0400, Noah L. Meyerhans wrote:
>
> Snort depends on a set of rules to detect potentially malicious traffic.
> Obviously this set of rules needs to be updates on a regular basis in
> order to keep up with new security issues. The problem is that the
> version of snort in stable is old enough that the upstream maintainers
> are no longer releasing new rulesets for it. 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.
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)
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. Since in most cases there is no code
involved, it's just data, maybe the Release Manager could be convinced
to include new versions in revisions of the stable release.
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.
That's the approach that all packages that depend on up-to-date data should
take, and is sometimes something that should be coordinated with upstream.
The fact that security-related software is more prone to this problem is
just related to the way attacks are constantly appearing for vulnerable
software. Unless a package providing a security tool does not implement the
above there is no way (save for backports) that security software will be
100% useful and up-to-date (giving our release process) in a Debian stable
release. That includes:
- vulnerability assesment scanners (nessus, nikto, since new checks depend
on new signatures)
- anti-virus tools (clamav...)
- intrusion detection systems if based on signatures (such as snort, but
others, for example Tiger, might but not completely dependant on them)
- spam-filter tools based on rules (spamassasin comes to mind)
But keep in midn that's not just related to security tools (think of
lintian, for example). That doesn't mean that it's worthless, however, it's
just that it's usefulness decreases as time goes by and the tool's _data_
is not updated.
Regards
Javi
Reply to: