Erinevus lehekülje "Itx8071-task2" redaktsioonide vahel

Allikas: Kursused
Mine navigeerimisribale Mine otsikasti
 
(ei näidata sama kasutaja 50 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), 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:
 
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).
−
* 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
+
 
 +
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"