Erinevus lehekülje "Itx8071-task2" redaktsioonide vahel
| 9. rida: | 9. rida: | ||
3) If the same user Y fails to switch to user X with su utility 3 times during 60 seconds, generate a new synthetic event "User Y repeatedly failed to switch to user X with su". Also, make sure that the same event for the same combination of attacking user Y and target user X will not be generated again during the following 10 minutes (600 seconds). | 3) If the same user Y fails to switch to user X with su utility 3 times during 60 seconds, generate a new synthetic event "User Y repeatedly failed to switch to user X with su". Also, make sure that the same event for the same combination of attacking user Y and target user X will not be generated again during the following 10 minutes (600 seconds). | ||
| − | 4) If a synthetic event described in point (2) or (3) is observed, extract the user name from the event, and add the event to the reporting context for the given user, creating the context if it does not exist yet. After adding event to the context, extend the context lifetime for 120 seconds. | + | 4) If a synthetic event described in point (2) or (3) is observed, extract the user name X from the event, and add the event to the reporting context for the given user, creating the context if it does not exist yet. After adding event to the context, extend the context lifetime for 120 seconds. |
5) When the lifetime of the reporting context for user X expires, all events stored into this context must be e-mailed to user X. After that, all event recording for user X must be disabled for the following 1 hour (3600 seconds). | 5) When the lifetime of the reporting context for user X expires, all events stored into this context must be e-mailed to user X. After that, all event recording for user X must be disabled for the following 1 hour (3600 seconds). | ||
Redaktsioon: 6. detsember 2020, kell 12:18
This homework assignment requires the knowledge from Modules 6 and 7.
Create SEC rules that accomplish the following event correlation task:
1) The ruleset must track SSH login failures and su authentication failures for targeted users, so that suspicious events for any given user would be stored into a SEC reporting context for this user. Events that must be stored into the reporting context are described below (see points (2) and (3)). Each time a new event is added to the context, the context lifetime must be extended by 120 seconds.
2) If 3 SSH login failures for existing user X are observed from the same client host Y during 60 seconds, generate a new synthetic event "Repeated login failures for user X from Y over SSH". Also, make sure that the same event for the same combination of user X and client host Y will not be generated again during the following 10 minutes (600 seconds).
3) If the same user Y fails to switch to user X with su utility 3 times during 60 seconds, generate a new synthetic event "User Y repeatedly failed to switch to user X with su". Also, make sure that the same event for the same combination of attacking user Y and target user X will not be generated again during the following 10 minutes (600 seconds).
4) If a synthetic event described in point (2) or (3) is observed, extract the user name X from the event, and add the event to the reporting context for the given user, creating the context if it does not exist yet. After adding event to the context, extend the context lifetime for 120 seconds.
5) When the lifetime of the reporting context for user X expires, all events stored into this context must be e-mailed to user X. After that, all event recording for user X must be disabled for the following 1 hour (3600 seconds).
For example, consider the following events:
Nov 6 17:14:02 localhost su[3903]: pam_unix(su:auth): authentication failure; logname=student uid=1000 euid=0 tty=pts/1 ruser=student rhost= user=chrony Nov 6 17:14:03 localhost sshd[3914]: Failed password for root from 192.168.56.7 port 37326 ssh2 Nov 6 17:14:12 localhost sshd[4065]: Failed password for chrony from 192.168.56.7 port 37386 ssh2 Nov 6 17:14:13 localhost sshd[4065]: Failed password for chrony from 192.168.56.7 port 37386 ssh2 Nov 6 17:14:18 localhost su[4071]: pam_unix(su:auth): authentication failure; logname=alice uid=1001 euid=0 tty=pts/2 ruser=alice rhost= user=chrony Nov 6 17:14:22 localhost su[4073]: pam_unix(su:auth): authentication failure; logname=student uid=1000 euid=0 tty=pts/1 ruser=student rhost= user=adm Nov 6 17:14:38 localhost su[4074]: pam_unix(su:auth): authentication failure; logname=student uid=1000 euid=0 tty=pts/1 ruser=student rhost= user=chrony Nov 6 17:14:49 localhost su[4075]: pam_unix(su:auth): authentication failure; logname=student uid=1000 euid=0 tty=pts/1 ruser=student rhost= user=chrony Nov 6 17:15:01 localhost sshd[4115]: Failed password for chrony from 192.168.56.7 port 37388 ssh2 Nov 6 17:15:04 localhost sshd[4115]: Failed password for chrony from 192.168.56.7 port 37388 ssh2 Nov 6 17:15:08 localhost su[4122]: pam_unix(su:auth): authentication failure; logname=student uid=1000 euid=0 tty=pts/1 ruser=student rhost= user=chrony Nov 6 17:15:10 localhost su[4123]: pam_unix(su:auth): authentication failure; logname=student uid=1000 euid=0 tty=pts/1 ruser=student rhost= user=chrony Nov 6 17:15:13 localhost su[4124]: pam_unix(su:auth): authentication failure; logname=student uid=1000 euid=0 tty=pts/1 ruser=student rhost= user=chrony Nov 6 17:15:51 localhost su[4145]: pam_unix(su:auth): authentication failure; logname=student uid=1000 euid=0 tty=pts/1 ruser=student rhost= user=oracle Nov 6 17:15:54 localhost su[4146]: pam_unix(su:auth): authentication failure; logname=student uid=1000 euid=0 tty=pts/1 ruser=student rhost= user=oracle Nov 6 17:16:16 localhost su[4147]: pam_unix(su:auth): authentication failure; logname=student uid=1000 euid=0 tty=pts/1 ruser=student rhost= user=oracle
Since at 17:14:49 the user student has failed to switch to user chrony for the third time within the last 60 seconds (previous two failed attempts took place at 17:14:02 and 17:14:38), the synthetic event "User student repeatedly failed to switch to user chrony with su" should be generated. Since there is no reporting context for user chrony, it should be created with the lifetime of 120 seconds, and the synthetic event should be added to this context.
Also, since by 17:15:01 there have been three login failures for user chrony from client host 192.168.56.7 within the last 60 seconds (previous two login failures took place at 17:14:12 and 17:14:13), the synthetic event "Repeated login failures for user chrony from 192.168.56.7 over SSH" should be generated. This synthetic event should be added to reporting context for user chrony, and the lifetime of the context should be extended for 120 seconds (in other words, until 17:17:01).
Note that su failure events for attacking user student and target user chrony at 17:15:08, 17:15:10 and 17:15:13 should not generate the synthetic event "User student repeatedly failed to switch to user chrony with su" at 17:15:13, since a synthetic event with the same text has already been generated within the last 10 minutes (at 17:14:49).
On the other hand, su failure events at 17:15:51, 17:15:54 and 17:16:16 should create the synthetic event "User student repeatedly failed to switch to user oracle with su" at 17:16:16, and this synthetic event should trigger the creation of the reporting context for user oracle with the lifetime of 120 seconds (in other words, until 17:18:16).
When reporting context for chrony expires at 17:17:02, all stored events from this context must be e-mailed to chrony@localhost:
User student repeatedly failed to switch to user chrony with su Repeated login failures for user chrony from 192.168.56.7 over SSH
After that, all following synthetic events for user chrony should be ignored during 1 hour.
When reporting context for oracle expires at 17:18:17, all stored events from this context must be e-mailed to oracle@localhost:
User student repeatedly failed to switch to user oracle with su
After that, all following synthetic events for user oracle should be ignored during 1 hour.
Some hints for accomplishing this assignment:
- don't try to solve the whole assignment with just one rule, but rather write several rules which interact,
- consider the use of SingleWithThreshold rules for detecting SSH login failures and su authentication failures that need reporting, and generate synthetic events for them,
- consider the use of Single rules for matching synthetic events and maintaining reporting contexts,
- for matching two different synthetic events by the same Single rule, consider the use of alternation (|) for defining two different branches, and capturing the username with the same named match variable in both branches.