Hello John, Tnx for the quick response(Code 3). Yes, I have all my zones logging to their respective DOM0 which then logs to a central loghost. I'm in the process of running these at the moment and will reply back shortly. --joe nremt
On Aug 8, 2009, at 14:14:30:EDT, John P. Rouillard wrote: > > In message <[email protected]>, > J Carvalho writes: > >> I'd like to watch the traffic on my virtual interfaces. Being the >> interface traffic never actually touches the physical device, I can't >> use pcap to grab it. >> I'm using ipf/ipmon to look for tcp syn fin, ackfin, etc, and I'd >> like >> to correlate the events to a conversation, date/time-length, size. > > Ok, so you have the info: > > source ip > source port > dest ip > dest port > > Also you can identify the opening/first packet/event and the last > packet/event. > >> Does this look to be an exercise in futility? > > No, not futile at all. > >> As always, your time and effort are appreciated. >> >> Here's a sample of the traffic: >> Jul 26 04:04:32 10.50.12.32 ipmon[137]: [local2.info] [ID 702911 >> local2.info] 04:04:31.438987 e1000g0 @-1:-1 L 10.50.12.32,10050 -> >> 10.50.13.2,45380 PR tcp len 20 55 -AFP OUT >> Jul 26 04:04:32 10.50.12.32 ipmon[137]: [local2.info] [ID 702911 >> local2.info] 04:04:31.439524 e1000g0 @-1:-1 L 10.50.13.2,45380 -> >> 10.50.12.32,10050 PR tcp len 20 40 -AF IN >> Jul 26 04:06:35 10.50.12.32 ipmon[137]: [local2.info] [ID 702911 >> local2.info] 04:06:34.912206 e1000g0 @-1:-1 L 10.50.13.2,59290 -> >> 10.50.12.32,10050 PR tcp len 20 52 -S IN > > Your example seems to have multiple flows mixed together, so I am not > quite sure where the sequence you want to find begins/ends but > assuming "-S" identifies the original opening salvo of the flow. > > For the inital packet you use the rule: > > type = single > desc = recognize opening syn packet of new flow > ptype = regexp > pattern = e1000g0 ........ ([0-9.]+),([0-9]+) -> ([0-9.]+), > ([0-9]+).*-S > context = !flow_$1_$2_$3_$4 && !flow_$3_$4_$1_$2 > action = create flow_$1_$2_$3_$4; \ > alias flow_$1_$2_$3_$4 flow_$3_$4_$1_$2; \ > add flow_$1_$2_$3_$4 $0 > > This creates a unique context based on src IP/port and dest IP/port > number. This 4-ple uniquely identifies the flow. Then it aliases the > context using a name that is unique to the dest IP/port and src > IP/port so that the return traffic (i.e. the current destination > becomes the source) is placed into the same context. > > Then a rule like: > > type = single > desc = accumulate events associated with existing flow > ptype = regexp > pattern = e000g1 ........ ([0-9.]+),([0-9]+) -> ([0-9.]+),([0-9]+) > context = flow_$1_$2_$3_$4 && flow_$3_$4_$1_$2 > action = add flow_$1_$2_$3_$4 $0 > > accumulates all the events for a particular flow. Note that this > supports flows in either direction since the flow_$1_$2_$3_$4 and > flow_$3_$42_$1_$2 are the same context because of the alias in the > prior rule. That is also why we require both flows to be defined (by > the context expression) before this rule is executed. > > Then when the flow ends (I assume the -AFP means ack/fin packet?) use: > > type = single > desc = recognize fin/ack of existing flow > ptype = regexp > pattern = e1000g0 ........ ([0-9.]+),([0-9]+) -> ([0-9.]+), > ([0-9]+).*-AFP > context = flow_$1_$2_$3_$4 && flow_$3_$4_$1_$2 > action = add flow_$1_$2_$3_$4 $0 ; \ > report flow_$1_$2_$3_$4 /bin/Mail -s \ > "flow data between $1,$2 and $3,$4" [email protected] ; \ > delete flow_$1_$2_$3_$4; > > which detects the close of the session and reports it. Now this > doesn't handle the case where one side has done a fin/ack and the > other side is still waiting to send the ack. Since the completion > usually occurs quickly, you could instead tell the context to time out > in say 30 seconds and report when it times out using: > > action = set flow_$1_$2_$3_$4 30 (report flow_$1_$2_$3_$4 /bin/Mail > -s \ > "flow data between $1,$2 and $3,$4" [email protected] ) > > to replace the report action in the -AFP. This way the accumulate rule > will still accumulate for another 30 seconds after this packet. Then > the context lifetime on flow_$1_$2_$3_$4 will expire, the report will > be done and all the aliases to the flow_$1_$2_$3_$4 context and the > context itself will be deleted. > > There are a few corner cases you may also want to look at: > > The accumulate rule will only work if both contexts exist. Do you want > to add a new rule similar to the syn recognition rule that will create > the contexts even if no syn was seen? E.G. something like > > type = single > desc = recognize previously unseen flow whenre no syn packet seen > ptype = regexp > pattern = e1000g0 ........ ([0-9.]+),([0-9]+) -> ([0-9.]+),([0-9]+).* > context = !flow_$1_$2_$3_$4 && !flow_$3_$4_$1_$2 > action = create flow_$1_$2_$3_$4; \ > alias flow_$1_$2_$3_$4 flow_$3_$4_$1_$2; \ > add flow_$1_$2_$3_$4 $0; > pipe '$0' /bin/Mail -s "New flow w/o syn recognized" \ > [email protected] > > Rather than using single rules, you could use pair rules. I have had > issues getting them to work well when there are multiple possible > matches for the ending (pattern2) condition. You can do it by having > the inital syn activate all the pair rules by setting > > continue = takenext > > on all the pair rules but the last. That opens some number of pair > correlations each recognizing a different end condition. You have to > reset all pair correlations when any one of them recognizes the end of > flow condition. I have found that to be messier than a set of single > rules linked with contexts. > > Make sure to add catchall rules at the end of your rules to forward > any unhandled events: > > type = single > desc = catchall > ptype = regexp > pattern = e1000g0 ........ ([0-9.]+),([0-9]+) -> ([0-9.]+),([0-9]+).* > context = catchall > action = add catachall $0 > > type = single > desc = catchall > ptype = regexp > pattern = e1000g0 ........ ([0-9.]+),([0-9]+) -> ([0-9.]+),([0-9]+).* > context = !catchall > action = create catchall 5 (report catchall /bin/Mail -s \ > "flow data between $1,$2 and $3,$4" [email protected] ); \ > add catchall $0; > > so you can revise your rules to handle them. > > Hopefully this has given you some ideas. > > If you get a working rule set that handles this I would love to see it > along with some sample inputs. I think this would make a good > supplimentary > example for my SEC log analysis class. > > -- > -- rouilj > John Rouillard > = > = > = > = > = > ====================================================================== > My employers don't acknowledge my existence much less my opinions. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Simple-evcorr-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
