Lab 3 Technical Report

Tools used: wireshark, snort

1
Table of Contents
Task 1:..................................................................................................................... 3

Working hypothesis..............................................................4

Plausible explanation............................................................7

Event or incident...................................................................9

Solution & Suggestions:.......................................................9

Snort rule:...........................................................................10

Task 2:................................................................................................................... 11

Working hypothesis.............................................................11

Plausible explanation..........................................................13

Event or incident.................................................................15

Solution & Suggestions:.....................................................16

Snort rule:...........................................................................17

2
Task 1:
Protocols: TCP, ICMPv6, SSDP, IGMPv2
Type and function: tcp server

using endpoints we can see all the ip involved in the packet

udp:

3
Working hypothesis
1. A developer could be trying to access a tcp server from port 80 to port 4444 and
injecting with cli commands (ifconfig, ls).
Proof:

4
2. The server try to access the website fedoraproject.org through dns resolve 192.168.1.1
and access the website through ipv6 to port 80.

5
3. Another developer could be accessing a tcp server at 192.168.1.105 port 8080.

6
Plausible explanation
Due to the above signal and proof, we can conclude:
server ip 192.168.1.105
1. a tcp server running at port 4444.
2. a tcp server running at port 8080.
3. the request comes from a webserver from port 80.
4. there are two routers one from linksys on 192.168.1.1 and one from cisco on
192.168.1.2

5. through I/O graph, we can see the packet peaked at about 25seconds into the capture.
At the peak of capture, a decent amount of SSDP packets were traced, which could lead
to a potential SSDP Ddos attack to overwhelm the system if not restricted.

Proof:

7
8
Event or incident
According to above explanation, this is an EVENT.

1. Client tries to access port 4444 and 8080 without testing if it is open. Therefore they
must know what they were doing.
2. SSDP packets were sent from internal network 192.168.1.116 which could be when
the device just joined the network.

Score:
Criticality = 3 – target machine is Linux/Windows system running web service.
Lethality = 5 – attacker can easily gain root access from port 4444 on tcp server.
System CM = 3 – patches missing, older system.
Network CM = 2 – permissive firewall, traffic is allowed in and out.
Severity = (criticality + lethality) – (System + Network countermeasures)
= (3+5) – (3+2) = 3 (medium)

Solution & Suggestions:

9
Snort rule:

alert tcp any 80 -> $HOME_NET any (msg:"syn connection from port 80"; flags:S;
sid:1000003;)
alert udp any any -> $HOME_NET 1900 (msg:"SSDP flood 10 count per 30s";
threshold: type threshold, track by_dst, count 10 , seconds 30; sid:1000004;)

10
Task 2:
Protocols: TCP, ICMPv6, SSDP, IGMPv2
Type and function: tcp server

using endpoints we can see all the ip involved in the packet

Working hypothesis
1. Client 192.168.47.171 established huge amount of sessions with src port increment by
1 to server 192.168.47.200 port 23 – (telnet server)
I/O graph shows the rate pattern:
The packets were peaked in intervals of 6 seconds. This could be a scripted brute force
attack.

11
Endpoint graphs show all tcp sessions established.

12
Plausible explanation
Due to the above signal and proof, we can conclude:
server ip 192.168.47.200
1. a telnet server running on port 23.

13
2. The client 192.168.47.171 is compromised and initiating the attack to the telnet
server.
We can see it is also trying a lot of common used password to guess into the telnet
server. (password such as 123456, qwerty, password)

14
Event or incident
According to above explanation, this is an INCIDENT.

1. The client 192.168.47.171 could be compromised and do a telnet brute force attack.
Proof: even connection is blocked, the client still tries to send username and password.

15
2. The server does not have proper protection and IDS setup to block potential internal
telnet access attempt.

Score:
Criticality = 3 – target machine is Vmware running web service.
Lethality = 5 – attacker can easily gain root access from port brute force telnet attack.
System CM = 2 – patches missing, Vmware system.
Network CM = 2 – permissive firewall, traffic is allowed in and out.
Severity = (criticality + lethality) – (System + Network countermeasures)
= (3+5) – (3+2) = 4 (medium high)

Solution & Suggestions:

16
Snort rule:

alert tcp $HOME_NET 23 -> any any (msg:"telnet failed connection"; content:"|4c 6f 67
69 6e 20 46 61 69 6c 65 64 0d 0a|"; sid:1000005;)
alert tcp any any -> $HOME_NET 22 (msg:"SSH brute forcing"; flags: S+; threshold:
type both, track by_src, count 3, seconds 30; sid:1000006;)

17