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
