Erinevus lehekülje "Itx8071-task2" redaktsioonide vahel
(Lehekülg asendatud tekstiga 'To be announced.') |
|||
1. rida: | 1. rida: | ||
− | + | 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 one SEC reporting context. 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 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 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: 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: 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: 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: 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: 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:08 localhost su: 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: 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: 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: 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: 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: 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 during the last 60 seconds (previous two failed attempts took place at 17:14:02 and 17:14:38), 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 a lifetime of 120 seconds, and 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 (previous two login failures took place at 17:14:12 and 17:14:13), 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 root at 17:15:08, 17:15:10 and 17:15:13 should not generate a synthetic event "User student repeatedly failed to switch to user chrony with su" at 17:15:13, since 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 a 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 root expires at 17:15:25, all stored events from this context must be e-mailed to root@localhost (the context contains one event "User root failed to log in from 192.168.56.1 over SSH"). After that, all following events for root user should be ignored during 1 hour, and therefore the event from 17:23:29 must not be stored into any reporting context. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | Apart from studying the examples from the course slides, have a look at the SEC man page (installed at the virtual machines or found at https://simple-evcorr.github.io/man.html). |
Redaktsioon: 3. november 2020, kell 14:32
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 one SEC reporting context. 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 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 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: 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: 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: 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: 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: 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:08 localhost su: 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: 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: 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: 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: 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: 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 during the last 60 seconds (previous two failed attempts took place at 17:14:02 and 17:14:38), 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 a lifetime of 120 seconds, and 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 (previous two login failures took place at 17:14:12 and 17:14:13), 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 root at 17:15:08, 17:15:10 and 17:15:13 should not generate a synthetic event "User student repeatedly failed to switch to user chrony with su" at 17:15:13, since 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 a 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 root expires at 17:15:25, all stored events from this context must be e-mailed to root@localhost (the context contains one event "User root failed to log in from 192.168.56.1 over SSH"). After that, all following events for root user should be ignored during 1 hour, and therefore the event from 17:23:29 must not be stored into any reporting context.
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.
Apart from studying the examples from the course slides, have a look at the SEC man page (installed at the virtual machines or found at https://simple-evcorr.github.io/man.html).