Erinevus lehekülje "Itx8071-task2" redaktsioonide vahel

Allikas: Kursused
Mine navigeerimisribale Mine otsikasti
 
(ei näidata sama kasutaja 64 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) if netfilter firewall blocked packet events have been seen for the same host repeatedly during 2 minutes, so that the host has probed at least 5 distinct TCP and/or UDP ports, memorize that host for the following 1 hour as suspicious host. Note that ports must be distinguished not only by port number, but transport protocol should also be considered (for example, ports 53/tcp and 53/udp must be regarded different).
  
−
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, if the following events appear for host 192.168.56.1, this host should be memorized as suspicious, since it has probed 5 distinct ports 161/udp, 21/tcp, 23/tcp, 25/tcp, and 123/udp within 2 minutes:
  
−
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 14:14:48 localhost kernel: iptables: IN=enp0s8 OUT= MAC=08:00:27:ce:72:9a:0a:00:27:00:00:00:08:00 SRC=192.168.56.1 DST=192.168.56.103 LEN=32 TOS=0x00 PREC=0x00 TTL=64 ID=32591 DF PROTO=UDP SPT=46062 DPT=161 LEN=12
 +
Nov  7 14:15:06 localhost kernel: iptables: IN=enp0s8 OUT= MAC=08:00:27:ce:72:9a:0a:00:27:00:00:00:08:00 SRC=192.168.56.1 DST=192.168.56.103 LEN=32 TOS=0x00 PREC=0x00 TTL=64 ID=34001 DF PROTO=UDP SPT=37036 DPT=161 LEN=12
 +
Nov  7 14:15:18 localhost kernel: iptables: IN=enp0s8 OUT= MAC=08:00:27:ce:72:9a:0a:00:27:00:00:00:08:00 SRC=192.168.56.1 DST=192.168.56.103 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=37323 DF PROTO=TCP SPT=38954 DPT=21 WINDOW=29200 RES=0x00 SYN URGP=0
 +
Nov  7 14:15:22 localhost kernel: iptables: IN=enp0s8 OUT= MAC=08:00:27:ce:72:9a:0a:00:27:00:00:00:08:00 SRC=192.168.56.1 DST=192.168.56.103 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3465 DF PROTO=TCP SPT=51418 DPT=23 WINDOW=29200 RES=0x00 SYN URGP=0
 +
Nov  7 14:15:23 localhost kernel: iptables: IN=enp0s8 OUT= MAC=08:00:27:ce:72:9a:0a:00:27:00:00:00:08:00 SRC=192.168.56.1 DST=192.168.56.103 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3466 DF PROTO=TCP SPT=51418 DPT=23 WINDOW=29200 RES=0x00 SYN URGP=0
 +
Nov  7 14:16:01 localhost kernel: iptables: IN=enp0s8 OUT= MAC=08:00:27:ce:72:9a:0a:00:27:00:00:00:08:00 SRC=192.168.56.1 DST=192.168.56.103 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=60601 DF PROTO=TCP SPT=50250 DPT=25 WINDOW=29200 RES=0x00 SYN URGP=0
 +
Nov  7 14:16:02 localhost kernel: iptables: IN=enp0s8 OUT= MAC=08:00:27:ce:72:9a:0a:00:27:00:00:00:08:00 SRC=192.168.56.1 DST=192.168.56.103 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=60602 DF PROTO=TCP SPT=50250 DPT=25 WINDOW=29200 RES=0x00 SYN URGP=0
 +
Nov  7 14:16:46 localhost kernel: iptables: IN=enp0s8 OUT= MAC=08:00:27:ce:72:9a:0a:00:27:00:00:00:08:00 SRC=192.168.56.1 DST=192.168.56.103 LEN=32 TOS=0x00 PREC=0x00 TTL=64 ID=39224 DF PROTO=UDP SPT=41553 DPT=123 LEN=12
  
−
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.
+
2) if a host has been previously memorized as suspicious, and from this host 3 distinct non-existing user accounts are probed over SSH within 1 minute, send an alert e-mail to the local root user (root@localhost). After e-mail has been sent, disable all further alert e-mails for the same host for the following 3 hours.
  
−
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, suppose the host 192.168.56.1 has been memorized as suspicious less than 1 hour ago, and the following events are observed:
  
−
For example, consider the following events:
+
Nov  7 14:36:09 localhost sshd[1336]: Failed none for invalid user admin from 192.168.56.1 port 36404 ssh2
 +
Nov  7 14:36:10 localhost sshd[1336]: Failed password for invalid user admin from 192.168.56.1 port 36404 ssh2
 +
Nov  7 14:36:16 localhost sshd[1338]: Failed password for invalid user oracle from 192.168.56.1 port 36406 ssh2
 +
Nov  7 14:36:50 localhost sshd[1340]: Failed none for invalid user sybase from 192.168.56.1 port 36412 ssh2
 +
Nov  7 14:36:53 localhost sshd[1340]: Failed password for invalid user sybase from 192.168.56.1 port 36412 ssh2
  
−
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'''
+
Since 3 distinct non-existing user accounts admin, oracle, and sybase have been probed over SSH from suspicious host 192.168.56.1 within 1 minute, an alert e-mail about this host must be sent to root@localhost at 14:36:50. Also, further alerting must be disabled for 192.168.56.1 for 3 hours.
−
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), a 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.
+
Note that all parts of the solution must be '''fully functional''' even when port probing or user account probing is conducted from '''several hosts in parallel''' (for example, contexts maintained by different counting operations must '''not''' interfere with each other).
  
−
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), a 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).
+
=== Some hints for accomplishing this assignment: ===
  
−
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 a 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).
+
* consider the technique outlined on slides 17-18 of Module 7,
−
 
+
* as an alternative, consider the technique described in section 6.4 of the SEC tutorial (https://simple-evcorr.github.io/SEC-tutorial.pdf),
−
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).
+
* make sure you have a good understanding of the lab assignment solutions of Modules 6 and 7.
−
 
 
−
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.
 

Viimane redaktsioon: 13. november 2025, kell 16:27

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

Create SEC rules that accomplish the following event correlation task:

1) if netfilter firewall blocked packet events have been seen for the same host repeatedly during 2 minutes, so that the host has probed at least 5 distinct TCP and/or UDP ports, memorize that host for the following 1 hour as suspicious host. Note that ports must be distinguished not only by port number, but transport protocol should also be considered (for example, ports 53/tcp and 53/udp must be regarded different).

For example, if the following events appear for host 192.168.56.1, this host should be memorized as suspicious, since it has probed 5 distinct ports 161/udp, 21/tcp, 23/tcp, 25/tcp, and 123/udp within 2 minutes: 

Nov  7 14:14:48 localhost kernel: iptables: IN=enp0s8 OUT= MAC=08:00:27:ce:72:9a:0a:00:27:00:00:00:08:00 SRC=192.168.56.1 DST=192.168.56.103 LEN=32 TOS=0x00 PREC=0x00 TTL=64 ID=32591 DF PROTO=UDP SPT=46062 DPT=161 LEN=12 
Nov  7 14:15:06 localhost kernel: iptables: IN=enp0s8 OUT= MAC=08:00:27:ce:72:9a:0a:00:27:00:00:00:08:00 SRC=192.168.56.1 DST=192.168.56.103 LEN=32 TOS=0x00 PREC=0x00 TTL=64 ID=34001 DF PROTO=UDP SPT=37036 DPT=161 LEN=12 
Nov  7 14:15:18 localhost kernel: iptables: IN=enp0s8 OUT= MAC=08:00:27:ce:72:9a:0a:00:27:00:00:00:08:00 SRC=192.168.56.1 DST=192.168.56.103 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=37323 DF PROTO=TCP SPT=38954 DPT=21 WINDOW=29200 RES=0x00 SYN URGP=0 
Nov  7 14:15:22 localhost kernel: iptables: IN=enp0s8 OUT= MAC=08:00:27:ce:72:9a:0a:00:27:00:00:00:08:00 SRC=192.168.56.1 DST=192.168.56.103 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3465 DF PROTO=TCP SPT=51418 DPT=23 WINDOW=29200 RES=0x00 SYN URGP=0 
Nov  7 14:15:23 localhost kernel: iptables: IN=enp0s8 OUT= MAC=08:00:27:ce:72:9a:0a:00:27:00:00:00:08:00 SRC=192.168.56.1 DST=192.168.56.103 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3466 DF PROTO=TCP SPT=51418 DPT=23 WINDOW=29200 RES=0x00 SYN URGP=0 
Nov  7 14:16:01 localhost kernel: iptables: IN=enp0s8 OUT= MAC=08:00:27:ce:72:9a:0a:00:27:00:00:00:08:00 SRC=192.168.56.1 DST=192.168.56.103 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=60601 DF PROTO=TCP SPT=50250 DPT=25 WINDOW=29200 RES=0x00 SYN URGP=0 
Nov  7 14:16:02 localhost kernel: iptables: IN=enp0s8 OUT= MAC=08:00:27:ce:72:9a:0a:00:27:00:00:00:08:00 SRC=192.168.56.1 DST=192.168.56.103 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=60602 DF PROTO=TCP SPT=50250 DPT=25 WINDOW=29200 RES=0x00 SYN URGP=0 
Nov  7 14:16:46 localhost kernel: iptables: IN=enp0s8 OUT= MAC=08:00:27:ce:72:9a:0a:00:27:00:00:00:08:00 SRC=192.168.56.1 DST=192.168.56.103 LEN=32 TOS=0x00 PREC=0x00 TTL=64 ID=39224 DF PROTO=UDP SPT=41553 DPT=123 LEN=12

2) if a host has been previously memorized as suspicious, and from this host 3 distinct non-existing user accounts are probed over SSH within 1 minute, send an alert e-mail to the local root user (root@localhost). After e-mail has been sent, disable all further alert e-mails for the same host for the following 3 hours.

For example, suppose the host 192.168.56.1 has been memorized as suspicious less than 1 hour ago, and the following events are observed: 

Nov  7 14:36:09 localhost sshd[1336]: Failed none for invalid user admin from 192.168.56.1 port 36404 ssh2
Nov  7 14:36:10 localhost sshd[1336]: Failed password for invalid user admin from 192.168.56.1 port 36404 ssh2
Nov  7 14:36:16 localhost sshd[1338]: Failed password for invalid user oracle from 192.168.56.1 port 36406 ssh2
Nov  7 14:36:50 localhost sshd[1340]: Failed none for invalid user sybase from 192.168.56.1 port 36412 ssh2
Nov  7 14:36:53 localhost sshd[1340]: Failed password for invalid user sybase from 192.168.56.1 port 36412 ssh2

Since 3 distinct non-existing user accounts admin, oracle, and sybase have been probed over SSH from suspicious host 192.168.56.1 within 1 minute, an alert e-mail about this host must be sent to root@localhost at 14:36:50. Also, further alerting must be disabled for 192.168.56.1 for 3 hours.

Note that all parts of the solution must be fully functional even when port probing or user account probing is conducted from several hosts in parallel (for example, contexts maintained by different counting operations must not interfere with each other).

Some hints for accomplishing this assignment:

  • consider the technique outlined on slides 17-18 of Module 7,
  • as an alternative, consider the technique described in section 6.4 of the SEC tutorial (https://simple-evcorr.github.io/SEC-tutorial.pdf),
  • make sure you have a good understanding of the lab assignment solutions of Modules 6 and 7.
Pärit leheküljelt "http://courses.cs.taltech.ee/w/index.php?title=Itx8071-task2&oldid=11990"