refactored. 01-02-03 done

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

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.

Binary file not shown.

Binary file not shown.

After

Width:  |  Height:  |  Size: 138 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 139 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 43 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 72 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 26 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 246 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 269 KiB

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

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.

Binary file not shown.

After

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 37 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 191 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 224 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 40 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 47 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 48 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 145 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 40 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 49 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 46 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 121 KiB

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.

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:

Binary file not shown.

After

Width:  |  Height:  |  Size: 62 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 54 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 54 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 54 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 55 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 55 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 97 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 97 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 55 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 59 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 122 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 110 KiB

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.

Binary file not shown.

After

Width:  |  Height:  |  Size: 24 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 124 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 60 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 121 KiB