On Mon, Jun 24, 2002 at 07:33:12AM -0400, Anthony DeRobertis wrote: > > On Sunday, June 23, 2002, at 05:21 , Matthew Sackman wrote: > > >If I've missed something obvious, please shout at me ;-) > > Only problem is that a Snort that has reached its second > birthday may not be happy with the new definitions.
OK, fair enough. In that case there would be a choice: a) stick with the binary package you have and no longer update your definitions; b) upgrade that package to testing/unstable and thus keep track of updated packages. This could be a problem: eg what if unstable/testing moves onto a new libc: all the packages must be back ported so that they will run on stable. This is what the security updates do anyway right? So this is actually a bit of a non-problem: if there is an update to a definition/configuration file for a package that results in a more up-to-date version of that package being required, then a new package is made for 'stable'. Is this possible/do-able/acceptable? Priliminary list that would require a seperate definition/configuration package: (these are taken from a woody listing) Definates: snort * Probables: snmpd heartbeat ntp ntpdate ntp-simple nessusd cvsupd krb5-kdc openssl slpd bsign * dmachinemon-master * dmachinemon-servent * francine * webmin-ALL * bsd-ftpd * dante-server * fakebo * fspd * ircd * mailutils-imap4d * mailutils-pop3d * sfs-server * spong-client * spong-server * telnetd * tftpd * twoftpd * mgetty * mgetty-fax * hylafax-server * mserver * atftpd * bird * dancer-ircd * ftpd * ftpd-ssl * lukemftpd * nis * openldapd * wu-ftpd * Not Sure: lire checkservice swatch tct libsasl-gssapi-mit * libsasl-krb4-mit * bind9 bind darxite * dhcp * dhcp3-server * udhcpd * hpsockd * krb5-ftpd * krb5-telnetd * muddleftpd * pyftpd * slapd * snort-mysql * socks4-server * umich-ldapd * * means that I don't have this package installed, I don't know very much about it, so I am not sure whether it would need a seperate definitions package too. It's rather difficult coming up with this list: on the one hand you could say that only (N)IDS's actually need this. You could argue that logcheckers should have this too: that way if a new vulnerability appears, the log checker knows to notice it and highlight it. OTOH, you could end up with a list like the one above that is massively over the top: in this case I think that I have found far too many packages, packages where configuration files would be tuned by the sysadmin of the machine and therefore a package which provides a 'safe' configuration file is absolutely useless. I have deliberately not included any MTAs for this reason. I'm also sure that I've missed some. If other people on this list could go through and remove packages that are clearly wrongly listed above then that should get us down to a manageable list and somewhere to start. Thanks, Matthew -- Matthew Sackman Nottingham England BOFH Excuse Board: not properly grounded, please bury computer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
