Kriss Andsten wrote:
"Again, it's the stuff it sends down the wire that is my concern here. If
you can 'force' something to send five, ten, maybe twenty times the data
you use to trigger the log entry, you're a good way closer to denial of
service. It may be high this, high that, high everything - if it makes
something vulnerable from normal usage (logging selective IP traffic could
very well be considered normal usage, imo), it's an achilles heel. Of
course, I might be barking up the wrong tree myself thinking it's better
do use standard stuff than specialities in order to keep stuff running in
a somewhat secure way. Am I?"

Well, I think it's always better to use something that thousands of people
are working with daily, rather than something cobbled together by one or
two part-time engineers -- until, of course, thousands of other engineers
are also cobbling.  (How about Linux as an example?)

But you have put your finger on it - we have to make a judgement call about
the resources necessary to handle some real-world needs for robust and
secure network logging.  My feeling is that an organization with real
enough needs will spend some money on these resources, so that neither
network nor CPU bandwidth nor disk storage is a likely DoS weakness.  All
three of these are so cheap now, and falling precipitously.

However, there are many schools and universities (and, who knows, day-care
centers) that need secure logging and cannot afford these resources.
Perhaps this is not a solution for them;  but I think it's closer than full
IPSEC tunnels would be.

For these applications I think there should be some consideration of
additional extensions to existing syslog that provide some privacy as well
as authentication -- perhaps S/MIME, or one of the other secure email
message formats?  No guarantee any of them would fit in a UDP packet.

This is all a ripe topic for discussion around the BOF.

Alex Brown <[EMAIL PROTECTED]> +1 508 323 2283


NB:  I will be away from my desk much of this week;  I can be reached most
easily at:
Alex Brown <[EMAIL PROTECTED]> +1 617 504 8761



Reply via email to