Re: Proposal for new Security subsection for non-US
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 debian-security-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: