Erinevus lehekülje "Itx8071-task2" redaktsioonide vahel

Allikas: Kursused
Mine navigeerimisribale Mine otsikasti
 
(ei näidata sama kasutaja 80 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: ====
  
−
# The ruleset must track SSH login failures and su authentication failures for targeted users, so that all suspicious events for any given user would be stored into one SEC context. Events that must be stored into the context are described below (see points (2) and (3)). Before the first event is added to the context, the context must be created with the lifetime of 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.
−
# If user X fails to log in over SSH from client host Y, and there will be no successful SSH login for user X from client Y during the following 20 seconds, add the following event into the context for user X: "User X failed to log in from Y over SSH".
 
−
# If user Y fails to switch to user X with su utility, and user Y will not manage to successfully switch to user X during the following 20 seconds, add the following event into the context for user X: "User Y failed to switch to user X with su".
 
−
# 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:
+
For example, suppose the following events appear in the log:
  
−
  Nov  6 17:13:03 localhost sshd[3914]: Failed password for root from 192.168.56.1 port 37326 ssh2
+
  Nov  7 12:53:11 myhost sshd[10477]: Failed password for invalid user admin2 from 10.3.6.22 port 50087 ssh2
−
  Nov  6 17:13:33 localhost su: pam_unix(su:auth): authentication failure; logname=student uid=1000 euid=0 tty=pts/1 ruser=student rhost=  user=root
+
  Nov  7 12:53:12 myhost sshd[10477]: Failed password for invalid user admin2 from 10.3.6.22 port 50087 ssh2
−
Nov  6 17:13:43 localhost su: pam_unix(su:session): session opened for user root by student(uid=1000)
+
  Nov  7 12:53:39 myhost sshd[10479]: Failed password for invalid user oracle from 10.3.6.24 port 9899 ssh2
−
  Nov  6 17:14:12 localhost sshd[4065]: Failed password for chrony from 192.168.56.7 port 37386 ssh2
+
  Nov  7 12:53:40 myhost sshd[10479]: Failed password for invalid user oracle from 10.3.6.24 port 9899 ssh2
−
  Nov  6 17:14:13 localhost sshd[4065]: Failed password for chrony from 192.168.56.7 port 37386 ssh2
+
  Nov  7 12:53:55 myhost sshd[10499]: Failed password for invalid user oracle from 10.2.9.99 port 6133 ssh2
−
  Nov  6 17:14:48 localhost su: pam_unix(su:auth): authentication failure; logname=student uid=1000 euid=0 tty=pts/1 ruser=student rhost=  user=chrony
+
  Nov  7 12:54:01 myhost sshd[10527]: Failed publickey for invalid user admin2 from 10.1.2.52 port 40106 ssh2
−
Nov  6 17:15:01 localhost sshd[4115]: Failed password for chrony from 192.168.56.7 port 37388 ssh2
+
  Nov  7 12:54:02 myhost sshd[10527]: Failed publickey for invalid user admin2 from 10.1.2.52 port 40106 ssh2
−
  Nov  6 17:23:29 localhost su: pam_unix(su:auth): authentication failure; logname=student uid=1000 euid=0 tty=pts/1 ruser=student rhost=  user=root
+
  Nov  7 12:54:07 myhost sshd[10543]: Failed password for invalid user admin2 from 10.17.8.9 port 32444 ssh2
−
Nov  6 17:28:19 localhost sshd[4318]: Failed password for student from 192.168.56.1 port 37724 ssh2
 
−
  Nov  6 17:28:23 localhost sshd[4318]: Failed password for student from 192.168.56.1 port 37724 ssh2
 
−
  Nov  6 17:28:26 localhost sshd[4318]: Accepted password for student from 192.168.56.1 port 37724 ssh2
 
  
−
Since the SSH login failure event for user ''root'' from client ''192.168.56.1'' at 17:13:03 is not followed by successful login for ''root'' from ''192.168.56.1'' during 20 seconds, reporting context must be created at 17:13:24 for user ''root'' with the lifetime of 120 seconds. After that, event ''User root failed to log in from 192.168.56.1 over SSH'' must be stored into newly created context. Note that no event must be stored into the context of user ''root'' when user ''student'' fails to switch to user ''root'' at 17:13:33, since this failure is followed by successful switch from ''student'' to ''root'' at 17:13:43 (i.e., within 20 seconds since initial failure).
+
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.  
  
−
Because the SSH login failure event for user ''chrony'' from client ''192.168.56.7'' at 17:14:12 is not followed by successful login for ''chrony'' from ''192.168.56.7'' during 20 seconds, another reporting context must be created at 17:14:33 for user ''chrony'', and event ''User chrony failed to log in from 192.168.56.7 over SSH'' must be stored into this context (note that previously created context for ''root'' must not be used for storing this event, since the event concerns a different user). Because user ''student'' fails to switch to ''chrony'' at 17:14:48 without successful switch during 20 seconds, event ''User student failed to switch to user chrony with su'' must be appended to reporting context for ''chrony'' at 17:15:09. Finally, event ''User chrony failed to log in from 192.168.56.7 over SSH'' must be appended to the context at 17:15:22, since SSH login failure at 17:15:01 was not followed by successful login.
+
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.
  
−
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, reporting of following events for ''root'' user should be disabled for 1 hour, and therefore the event from 17:23:29 must not be stored into any reporting context.
+
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.
  
−
When reporting context for ''chrony'' expires at 17:16:34, all stored events from this context must be e-mailed to chrony@localhost:
+
-----
  
−
User chrony failed to log in from 192.168.56.7 over SSH
+
Some hints for accomplishing this assignment:
−
User student failed to switch to user chrony with su
+
* don't try to solve the whole assignment with just one rule, but rather write several rules which interact,
−
User chrony failed to log in from 192.168.56.7 over SSH
+
* 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).
  
−
After that, reporting of following events for ''chrony'' user should be disabled for 1 hour.
+
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).
−
 
 
−
Finally, no reporting context must be created for user ''student'', since SSH login failure events at 17:28:19 and 17:28:23 are followed by successful login at 17:28:26 for this user.
 

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"