Erinevus lehekülje "Itx8071-task2" redaktsioonide vahel

Allikas: Kursused
Mine navigeerimisribale Mine otsikasti
 
(ei näidata sama kasutaja 63 vahepealset redaktsiooni)
1. rida: 1. rida:
−
This homework assignment requires the knowledge from Modules 6 and 7.
+
This homework assignment requires the knowledge from Modules 6 and 7.  
  
−
====Create SEC rules that accomplish the following event correlation task:====
+
==== 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.
+
1) Monitor sshd log events for SSH probing of non-existing user accounts, and detect non-existing user accounts that have been probed over SSH from 3 distinct IP addresses within 60 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).
+
For example, suppose the following events appear in the log:
  
−
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).
+
Nov  7 12:53:11 myhost sshd[10477]: Failed password for invalid user admin2 from 10.3.6.22 port 50087 ssh2
 +
Nov  7 12:53:12 myhost sshd[10477]: Failed password for invalid user admin2 from 10.3.6.22 port 50087 ssh2
 +
Nov  7 12:53:39 myhost sshd[10479]: Failed password for invalid user oracle from 10.3.6.24 port 9899 ssh2
 +
Nov  7 12:53:40 myhost sshd[10479]: Failed password for invalid user oracle from 10.3.6.24 port 9899 ssh2
 +
Nov  7 12:53:55 myhost sshd[10499]: Failed password for invalid user oracle from 10.2.9.99 port 6133 ssh2
 +
Nov  7 12:54:01 myhost sshd[10527]: Failed publickey for invalid user admin2 from 10.1.2.52 port 40106 ssh2
 +
Nov  7 12:54:02 myhost sshd[10527]: Failed publickey for invalid user admin2 from 10.1.2.52 port 40106 ssh2
 +
Nov  7 12:54:07 myhost sshd[10543]: Failed password for invalid user admin2 from 10.17.8.9 port 32444 ssh2
  
−
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.
+
When above events appear, SSH probing for non-existing user admin2 should be reported, since this user was probed between 12:53:11 and 12:54:07 from 3 distinct IP addresses 10.3.6.22, 10.1.2.52 and 10.17.8.9. However, SSH probing for non-existing user oracle should not be reported, since this user was probed from only 2 distinct IP addresses.  
  
−
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).  
+
Also note that the detection should be done with a sliding window approach -- if the counting operation for some non-existing user has not seen enough events during 60 seconds, the 60 second detection window should be moved forward.
  
−
For example, consider the following events:
+
2) if the previous condition has been detected for 3 distinct non-existing users during 900 seconds (for example, admin2, oracle and testuser3 have been probed within 900 seconds), report this event to the local root-user via e-mail. After an e-mail has been sent, ensure than no repeated e-mails are generated during the following 3600 seconds.
  
−
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:04 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 within 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 within the last 60 seconds (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:
 
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,
 
* 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,
+
* if SSH probing for some non-existing user account is detected (as described in the first subtask), you could generate a relevant synthetic event for this user, in order to provide input for further event correlation rules.
−
* consider the use of Single rules for matching synthetic events and maintaining reporting contexts.
+
* all parts of the solution must be fully functional even when several non-existing user accounts are probed from several hosts in parallel (for example, contexts maintained by different counting operations must not interfere with each other).
 +
 
 +
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). Also, consider the examples from SEC tutorial (https://simple-evcorr.github.io/SEC-tutorial.pdf).

Viimane redaktsioon: 1. november 2024, kell 21:46

This homework assignment requires the knowledge from Modules 6 and 7.

Create SEC rules that accomplish the following event correlation task:

1) Monitor sshd log events for SSH probing of non-existing user accounts, and detect non-existing user accounts that have been probed over SSH from 3 distinct IP addresses within 60 seconds.

For example, suppose the following events appear in the log: 

Nov  7 12:53:11 myhost sshd[10477]: Failed password for invalid user admin2 from 10.3.6.22 port 50087 ssh2
Nov  7 12:53:12 myhost sshd[10477]: Failed password for invalid user admin2 from 10.3.6.22 port 50087 ssh2
Nov  7 12:53:39 myhost sshd[10479]: Failed password for invalid user oracle from 10.3.6.24 port 9899 ssh2
Nov  7 12:53:40 myhost sshd[10479]: Failed password for invalid user oracle from 10.3.6.24 port 9899 ssh2
Nov  7 12:53:55 myhost sshd[10499]: Failed password for invalid user oracle from 10.2.9.99 port 6133 ssh2
Nov  7 12:54:01 myhost sshd[10527]: Failed publickey for invalid user admin2 from 10.1.2.52 port 40106 ssh2
Nov  7 12:54:02 myhost sshd[10527]: Failed publickey for invalid user admin2 from 10.1.2.52 port 40106 ssh2
Nov  7 12:54:07 myhost sshd[10543]: Failed password for invalid user admin2 from 10.17.8.9 port 32444 ssh2

When above events appear, SSH probing for non-existing user admin2 should be reported, since this user was probed between 12:53:11 and 12:54:07 from 3 distinct IP addresses 10.3.6.22, 10.1.2.52 and 10.17.8.9. However, SSH probing for non-existing user oracle should not be reported, since this user was probed from only 2 distinct IP addresses.

Also note that the detection should be done with a sliding window approach -- if the counting operation for some non-existing user has not seen enough events during 60 seconds, the 60 second detection window should be moved forward.

2) if the previous condition has been detected for 3 distinct non-existing users during 900 seconds (for example, admin2, oracle and testuser3 have been probed within 900 seconds), report this event to the local root-user via e-mail. After an e-mail has been sent, ensure than no repeated e-mails are generated during the following 3600 seconds.

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,
  • if SSH probing for some non-existing user account is detected (as described in the first subtask), you could generate a relevant synthetic event for this user, in order to provide input for further event correlation rules.
  • all parts of the solution must be fully functional even when several non-existing user accounts are probed from several hosts in parallel (for example, contexts maintained by different counting operations must not interfere with each other).

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). Also, consider the examples from SEC tutorial (https://simple-evcorr.github.io/SEC-tutorial.pdf).

Pärit leheküljelt "http://courses.cs.taltech.ee/w/index.php?title=Itx8071-task2&oldid=11568"