RE: [logs] Reliably detecting things like the SQL worm....

SCarrollat_private

Comments at bottom.

# -----Original Message-----
# From: Chris Adams [mailto:cadamsat_private]
# Sent: Sunday, January 26, 2003 4:53 PM
# To: loganalysisat_private
# Subject: Re: [logs] Reliably detecting things like the SQL worm....
# 
# 
# > Of course, I should be able to detect that there is 
# something going on
# > due to the sharp increase in network traffic and - as far as the
# > firewalled sites are concerned - the number of firewall 
# alerts. HOWEVER,
# > most of this data is reported by syslog. This being UDP is 
# one of the
# > first things to be thrown away during congestion. I think 
# the worm is
# > the first situation that in reality proves whether or not 
# syslog is able
# > to provide a high enough message delivery rate to trigger 
# alerts - or be
# > of no use at all.
# 
# The biggest lesson is simply network structure: if you have 
# all of your
# control and logging going over the same network (or a VLAN 
# without some sort
# of prioritization or reserved bandwidth), you're screwed.
# 
# One interesting syslog aspect involves the replacement 
# protocols. Is there a
# syslog replacement out there which uses QoS so that routers 
# can prioritize
# critical errors ahead of the flood of low-priority errors 
# (e.g. per-probe
# notifications) and worm traffic?
# 
# Most of the syslog replacements seem to focus on application-level
# prioritization, which doesn't help much if you envision a 
# future where most
# hosts speak the syslog replacements natively - the most you 
# could do in that
# case would be pushing aggregators further out towards the 
# edge, which is
# expensive and unlikely to happen on most networks. Even 
# regular syslog would
# be better in this case if you had a version which set the 
# appropriate IP QoS
# bits before sending.

Chris,

My first reaction is, there's generally enough information in packets coming into a switch from a server to uniquely identify important traffic (by ip, protocol, and port).  And so, you can identify syslog traffic by (UDP) port, tag it, and know that all syslog traffic is prioritized.  It's hard for me to believe that so much non-critical syslog traffic would be generated that you'd wish to distinguish it from "important" syslog traffic and have the syslog daemon tag it.

Strikes me as a "feature" that would take away from (desired) simplicity.

My comments are driven by two paradigms: (1) qos bits are best set at the network device, where there's centralized control over it, and a consistent implementation, and (2) try hard to do something with what's already available before asking someone to write new code

-Shawn
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis