Erinevus lehekülje "Itx8071-task2" redaktsioonide vahel

Allikas: Kursused
Mine navigeerimisribale Mine otsikasti
 
(ei näidata sama kasutaja 186 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 tasks:
+
==== Create SEC rules that accomplish the following event correlation task: ====
 
 
1) the rules must process netfilter firewall syslog events about blocked
 
packets sent to local TCP and UDP ports. For example, the following two
 
events represent accesses to local ports 23/tcp and 25/tcp which were blocked
 
by the local firewall:
 
 
 
Oct 25 01:13:02 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=192.168.1.67 DST=192.168.1.107
 
LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=20049 DF PROTO=TCP SPT=44963 DPT=23 WINDOW=49640 RES=0x00 SYN
 
URGP=0
 
 
 
Oct 25 01:13:08 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=192.168.1.104 DST=192.168.1.107
 
LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=36362 DF PROTO=TCP SPT=56918 DPT=25 WINDOW=29200 RES=0x00 SYN
 
URGP=0
 
 
 
2) if some port has been probed repeatedly during 15 minutes, so that time
 
between two successive probes does not exceed 30 seconds, memorize that port
 
for the following 1 hour as a "noisy port". For example, if at 18:30:06
 
the local netfilter firewall starts to log events about
 
blocked access attempts to port 21/tcp, and such events continue to appear
 
once in 3-4 seconds until 18:45:06, then the port 21/tcp should be memorized
 
as a noisy port for 1 hour.
 
On the other hand, if the following 5 events are seen in 15 minutes,
 
the port 21/tcp must not be considered noisy, since the fourth and fifth
 
event are separated by more than 30 seconds.
 
 
 
Oct 25 18:30:06 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=10.1.1.7 DST=10.13.25.59 LEN=60
 
TOS=0x00 PREC=0x00 TTL=62 ID=1881 DF PROTO=TCP SPT=16333 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0
 
  
Oct 25 18:30:27 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=10.1.1.2 DST=10.13.25.59 LEN=60
+
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.
TOS=0x00 PREC=0x00 TTL=62 ID=23421 DF PROTO=TCP SPT=34342 DPT=21 WINDOW=29200 RES=0x00 SYN URGP=0
 
  
Oct 25 18:30:52 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=10.1.1.29 DST=10.13.25.59 LEN=60
+
For example, suppose the following events appear in the log:
TOS=0x00 PREC=0x00 TTL=62 ID=31442 DF PROTO=TCP SPT=47846 DPT=21 WINDOW=49640 RES=0x00 SYN URGP=0
 
  
  Oct 25 18:31:04 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=10.1.1.93 DST=10.13.25.59 LEN=60
+
  Nov  7 12:53:11 myhost sshd[10477]: Failed password for invalid user admin2 from 10.3.6.22 port 50087 ssh2
  TOS=0x00 PREC=0x00 TTL=62 ID=17209 DF PROTO=TCP SPT=11652 DPT=21 WINDOW=7290 RES=0x00 SYN URGP=0
+
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
  
Oct 25 18:44:46 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=10.1.1.84 DST=10.13.25.59 LEN=60
+
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.  
TOS=0x00 PREC=0x00 TTL=62 ID=7439 DF PROTO=TCP SPT=31959 DPT=21 WINDOW=6280 RES=0x00 SYN URGP=0
 
  
3) if some host probes 5 different ports within 60 seconds, so that none of
+
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.
the probed ports has been memorized as noisy within the last 1 hour, send
 
an e-mail about the offending host to root@localhost. Note that ports
 
should be distinguished not only by port number but also by transport protocol
 
(in other words, ports 53/tcp and 53/udp must be considered different ports).
 
  
Also note that the detection should be done with a sliding window approach --
+
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.
if the counting operation for some host has not seen enough events
 
during 60 seconds, the 60 second detection window should be moved forward.
 
  
After an e-mail alert has been issued about the host, disable further alerts
+
-----
for this host for 4 hours.
 
 
 
For example, suppose the following events are observed and the port 21/tcp
 
has been previously memorized as noisy:
 
 
 
Oct 25 18:51:01 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=10.1.1.7 DST=10.13.25.59 LEN=60
 
TOS=0x00 PREC=0x00 TTL=62 ID=1881 DF PROTO=TCP SPT=16333 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0
 
 
 
Oct 25 18:51:07 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=10.1.1.7 DST=10.13.25.59 LEN=60
 
TOS=0x00 PREC=0x00 TTL=62 ID=23421 DF PROTO=TCP SPT=34342 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
 
 
 
Oct 25 18:51:08 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=10.1.1.7 DST=10.13.25.59 LEN=60
 
TOS=0x00 PREC=0x00 TTL=62 ID=23421 DF PROTO=TCP SPT=34342 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
 
 
 
Oct 25 18:51:12 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=10.1.1.7 DST=10.13.25.59 LEN=60
 
TOS=0x00 PREC=0x00 TTL=62 ID=31442 DF PROTO=TCP SPT=47846 DPT=21 WINDOW=49640 RES=0x00 SYN URGP=0
 
 
 
Oct 25 18:51:14 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=10.1.1.93 DST=10.13.25.59 LEN=60
 
TOS=0x00 PREC=0x00 TTL=62 ID=17209 DF PROTO=TCP SPT=11652 DPT=23 WINDOW=7290 RES=0x00 SYN URGP=0
 
 
 
Oct 25 18:51:52 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=10.1.1.7 DST=10.13.25.59 LEN=60
 
TOS=0x00 PREC=0x00 TTL=62 ID=31442 DF PROTO=TCP SPT=47846 DPT=445 WINDOW=49640 RES=0x00 SYN URGP=0
 
 
 
Oct 25 18:52:02 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=10.1.1.7 DST=10.13.25.59 LEN=60
 
TOS=0x00 PREC=0x00 TTL=62 ID=7439 DF PROTO=TCP SPT=31959 DPT=6000 WINDOW=6280 RES=0x00 SYN URGP=0
 
 
 
Oct 25 18:52:03 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=10.1.1.7 DST=10.13.25.59 LEN=60
 
TOS=0x00 PREC=0x00 TTL=62 ID=7439 DF PROTO=TCP SPT=31959 DPT=6001 WINDOW=6280 RES=0x00 SYN URGP=0
 
 
 
Oct 25 18:52:05 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=10.1.1.7 DST=10.13.25.59 LEN=60
 
TOS=0x00 PREC=0x00 TTL=62 ID=7439 DF PROTO=TCP SPT=31959 DPT=6002 WINDOW=6280 RES=0x00 SYN URGP=0
 
 
 
Oct 25 18:52:14 localhost kernel: iptables: IN=eth0 OUT= MAC=X SRC=10.1.1.93 DST=10.13.25.59 LEN=60
 
TOS=0x00 PREC=0x00 TTL=62 ID=17209 DF PROTO=TCP SPT=11652 DPT=23 WINDOW=7290 RES=0x00 SYN URGP=0
 
 
 
The event correlation rules must produce an alarm at Oct 25 18:52:05 about
 
offending host 10.1.1.7, since this host has accessed five distinct ports
 
80/tcp, 445/tcp, 6000/tcp, 6001/tcp and 6002/tcp between Oct 25 18:51:07
 
and Oct 25 18:52:05 (access attempt to noisy port 21/tcp at Oct 25 18:51:12
 
must be ignored, while access attempt to port 25/tcp at Oct 25 18:51:01 does
 
not fit into the 60 second window).
 
  
 
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,
* in order to accomplish subtask 2 (detection of 15 minute event sequence with max 30 second intervals), use Single rules that set up contexts with specific actions-on-expire.
+
* 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
+
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).
man page (installed at the virtual machines or found at  
 
http://simple-evcorr.github.io/man.html).
 

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).