On 11/10/11 9:54 AM, Justin J. Novack wrote:
The file attached is for DNS, not DHCP.
Events are timed when they come in to SEC, not when they come in to
the log file. If you spawn a dump of the log file which contains 1
entry per hour for 24 hours; SEC will see 24 events come in
immediately. It cannot parse the log file for the time the event came in.
If you include your DHCP sec.cfg, we might be better able to help.
--
Justin J. Novack
Official Disturber of the Peace
Ouch, how did that happen.. I see I did get the wrong config file.
Anyway, I am re-attaching.
To recap, I am interested in counting those events that are 'lost'. If
I rapid fire send out 20 DISCOVER messages, with no OFFER message, I
would expect that I would see that same number of 'DHCPOFFER lost'
events as a result of the PairWithWIndow. That is to say that the same
count of synthetic events will follow with a latency of <window=1>
second. I don't see that many. I see about 14 or so 'DHCPOFFER lost'
messages, so I never hit the <thresh=20> to trigger a 'DHCPOFFER
Repeated loss' in the SingleWith2Thresholds.
If I invoke 'sec.pl -debug=7 -input=- -log=- -conf=<path to sec.cfg>,
and I squirt to stdin (in rapid fire succession) the below message about
20 times within a few seconds total, I should see roughly 20 'DHCPOFFER
lost' messages a few seconds later.
foo dhcpd: DHCPOFFER on 1.2.3.4 to 01:02:03:04:05:06 via eth1 relay
1.2.3.254 lease-duration 3600
Tim
--
Tim Peiffer
Network Support Engineer
Office of Information Technology
University of Minnesota/NorthernLights GigaPOP
+1 612 626-7884 (desk)
#Nov 4 04:13:49 1.2.3.4 dhcpd[23024]: DHCPOFFER on 10.20.62.247 to
98:4b:e1:4c:99:61 via eth1 relay 10.20.63.254 lease-duration 300
#Nov 4 04:13:49 1.2.3.4 dhcpd[23024]: DHCPREQUEST for 10.20.62.247 (1.2.3.4)
from 98:4b:e1:4c:99:61 via 10.20.63.254
#
# If an offer is not responded to within (window) seconds, create a context
# indicating the loss for a given MAC address.
type=PairWithWindow
ptype=RegExp
pattern=(\S+) \S+ DHCPOFFER on \S+ to (\S+) via \S+ relay (\S+)
desc=DHCPOFFER lost
action=event 0 %s $1 $2 $3
ptype2=RegExp
pattern2=(\S+) \S+ DHCPREQUEST for \S+ \S+ from (\S+) via (\S+)
desc2=DHCPOFFER taken
action2=logonly %s $1 $2 $3
window=1
#
# If a context for loss of offer for a MAC exists, count the occurrences.
# If more than <threhold> events within <window> seconds, it is probably
# a good time to signal the event upward.
# If the DHCP offer loss goes to less than <thresh2 = 0>, and stays below
# that for <window2> seconds (1 hr?), then the larger event is complete.
#
type=SingleWith2Thresholds
ptype=RegExp
pattern=DHCPOFFER lost (\S+) (\S+) (\S+)
desc=DHCPOFFER Repeated loss
action=event 0 %s $1 $2 $3
rem=What is a good number 20 occurences in an hour?
window=3600
thresh=20
desc2=DHCPOFFER loss subsides
action2=event 0 %s $1 $2 $3
window2=3600
thresh2=0
#
# The Repeated loss continues, it is a good idea to log it, or take some
# sort of action (tickets?)
#
type=SingleWithThreshold
ptype=RegExp
pattern=DHCPOFFER Repeated loss (\S+) (\S+) (\S+)
desc=Continued loss of DHCP traffic
rem=We could ticket here, or just log for further analysis.
action=logonly %s for $2 via relay $3
rem=the holddown on notification is about 3 days
window=259200
thresh=1
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
