Package: porlock
porlockMonitor event logs for potentially fraudulent activityPremiseOftentimes, specific events in and of themselves don't indicate a
risk to your systems.  However, when viewed in the context of surrounding
events, we can identify potentially risky behavior.Take the following scenario, represented by the events below:A user calls customer service and requests and one time token for login.The user logs in, and the system requires a password updateA few days later, the user comes to the site (from a new IP) and requests a password resetThe user proceeds to change their passwordEvent: otp_login, date: 2022-11-01 13:43:17 EST, user_id: 1, ip: 10.0.0.1
Event: password_change, date: 2022-11-01 13:45:53 EST, user_id: 1, ip: 10.0.0.1
Event: password_reset, date: 2022-11-07 17:31:22 EST, user_id: 1, ip: 192.168.0.1
Event: password_change, date: 2022-11-07 17:33:11 EST, user_id: 1, ip: 192.168.0.1None of the above events, in isolation, look particularly risky, and while it
is possible that the user simply forgot their new password, when
viewed along with other events, this sequence of events points to a potential account hijack.porlock provides a rule framework to help make finding these events and flagging them
possible.  By identifying events, and subsequent matching events, porlock parses
logs over a specified time period to flag risky behavior.Basic RulesRules are written in a simple list formatNote: future versions may support yaml rules[
       "Password Change After OTP Login",
       "otp login",
       "followed by",
       "any",
       ["password change"],
       "after",
       "2d",
       "user",
       ["password change"],
       "before",
       "1h",
       "14d",
       "30d"
    ]Rule Name: A human readable description of the ruleEvent Name: The name of the initial event to search forWhen:followed byorpreceded by(Currently onlyfollowed byis supported)Match: What type of match toany,all,none,oneMatching Events: a list of events to matchPeriod When: whether or not this event should happenbeforeorafterthePeriodparameterPeriod: How longafterthe initial event to start looking (or when to stop looking forbefore)Identifier: The field to match events on.  This is typically either a user id, email, or IP addressSecondary Event: For future useSecondary Period When: For future useSecondary Period: For future useMatch time frame: The time frame after (forfollowed by) the initial event occurred to check for matching eventsLog time frame: For future use; The time frame to return all events for a particularidentifierfrom the logsParametersWhenfollowed by- the matching events should come after the initial eventpreceded by- the matching events should come before the initial event (Note: This is still a work in progress)Matchany- can match any of the listed eventsall- must match all of the listed eventsnone- must match none of the listed eventsone- must match one and only one of the listed eventsPeriod Whenbefore- indicates to check all events prior to thePeriodparameterafter- indicates to check all events after to thePeriodparameterPeriodThe period should be specified by a number followed by one ofs(seconds),m(minutes),h(hours),d(days), orw(weeks)