|
What's the recommended approach when trying to correlate events together whenever the the events themselves don't all have a common fields? (e.g. There is no singular transaction field across all events) I'm wondering if there is a common technique here. I have a specific problem in mind that spans 3 different types of events, but there are some other problems that I would like to tackle that would require spanning even more.... Here is an example I've been wrestling with: I'm attempting to correlate a set of RAS (remote dial up access) logs with activity on our FTP logs. Our FTP file transfer logs contain IP address (which is assigned by the RAS server), but the most helpful of the RAS logs only contain the RAS comm port number but not the IP address. This gets tricky to visualize, so perhaps a little ASCII table will help...
The info I really want is in the "Stats" and "Unique Id" categories. But you can't get from My end goal is to get to the unique id information in the "FTP1" event and combine that with the stats info in "RAS2" event. So what I'm really looking for is a transaction command that lets me sometimes link based on my ip address, and other times let's me link based on User and Com Port; and the transaction command doesn't seem to like doing this. Additional complexities:
Here is an example that I came up with so far:
This search nearly works. My inner (first) Is there some search |
|
There are a couple of choices here. You can still use your basic search above with the second transaction based on clientip and use a The other possibility is to use a time-based lookup. If you record all of the RAS-SERVER transactions to a lookup table, you can match the route, route_name, port, etc. based on the clientip with a search against just the FTP-SERVER logs. Your
(23 Aug '10, 19:23)
Lowell ♦
|
|
from the ascii table that you've provided using connected=f in the transaction should get rid of the subsearch .... | transaction port clientip maxspan=2h endswith=("EventCode=20048") startswith=(EventCode=20200) connected=f to see why we need to set connected=f, consider the same table but in reverse time order (same way as transaction's command sees the events). We need to set connected to false because there is no transitive relationship established between RAS2 and FTP1 if viewing events in reverse chronological order
|

Also, I would really like to eliminate the sub-search (and the
appendsearch command) if at all possible.