03-postgresql

.gitignore

@@ -0,0 +1,2 @@
+**.docx
+**.pdf

pentest/01-network/01-tcpip/02-tcp/GOVNO.md

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

pentest/01-network/01-tcpip/02-tcp/volume/opt2.py

@@ -1,7 +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=55418, dport=23, flags="R", seq=3707590235)
+tcp = TCP(sport=40060, dport=23, flags="R", seq=1838235189)
 pkt = ip/tcp
 ls(pkt)
 send(pkt, verbose=0)

pentest/01-network/01-tcpip/02-tcp/volume/opt3.py

@@ -1,7 +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=60124, dport=23, flags="PA", seq=1386786213, ack=482847772)
+tcp = TCP(sport=54402, dport=23, flags="PA", seq=4125627535, ack=2474120203)
 data = "\r mkdir 1337 \r"
 pkt = ip/tcp/data
 ls(pkt)

pentest/01-network/02-scanner/01-ftp/README.md

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

pentest/01-network/02-scanner/01-ftp/vsftpd.conf

@@ -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

pentest/01-network/02-scanner/02-nmap/README.md

@@ -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.
+

pentest/01-network/02-scanner/03-postgresql/README.md

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

pentest/01-network/02-scanner/03-postgresql/docker-compose.yaml

@@ -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: