###### tags: `Network Labs`
# Отчёт по лабораторной работе №5
Выполнил: Запорожец Арсений
## Часть 1. - DHCP Starvation
### Атака
Для выполнения данной атаки нам понадобится pyDHCPStarvator. Его можно скачать с github из одноимённого репозитория.
В качестве первого шага добудим mac-address цели. Для этого в нашем случае достаточно необходимо ввести команду `arp`:

Скачаем и установим зависимости pyDHCPStarvator. Запустим его командой. Для успешной атаки необходимо выполнить две команды:
`python3 starvit.py -i eth0 -net 192.168.1.0/24 -start 1 -end 254 -dst_mac 50:00:00:05:00:01`:
`python3 listener.py -i eth0 -starvation-attack`:

Просмотрев трафик мы можем увидеть множество исходящих DHCP запоросов:

После атаки мы можем увидеть забитую таблицу ip адресов:

### Защита
Для защиты от данного вида атаки необзодимо всего-лишь ограничить количество mac адресов для текущего DHCP сервера. По мере добавления машин пул можно расширять. Также в данном случае неплохо помогает DHCP snooping, которая ограничивает количество запросов в секунду на хост (рекомендуется не больше 100). Пользователь не привысит это значение, а вот злоумышленник будет обнаружен:

## Часть 2. - Атака DHCP Rouge
### Атака
Для этой атаки нам понадобится помощь yarshini'и. Запустим на ней DHCP rouge сервер:

Т.к. мы заполнили ip таблицу основного сервера, то отвечать хостам будет уже кто-то другой, а именно наш DHCP сервер. Я запустил dhclient на debian. Вот результаты:

В самой же vershinia можно анализировать трафик, рассматривая, кому именно был выдан IP адрес:

Как мы можем увидеть, некоторые запросы перенаправляются на машину с kali linux. Это позволяет нам прослушивать трафик, что может привести к серьёзному ущербу, в том числе и серьёзной утечки данных.

### Защита
Тот же самый случай, что и при DHCP Starvation:

## Часть 3. - Атака CAM table overflow
### Атака
Скачаем утилиту Macof.py и запустим её. В моём случае запуск проводился с kali linux. Атака была проведена на switch. Результаты:

Как мы можем увидеть, таблица mac адресов успешно была забита.
Вот показания анализатора трафика:

### Защита
Официально рекомендуемый метsод – включение port-security на интерфейсе коммутатора. Ограничим возможности атакующих, ограничив число возможных mac адресов с 1 интерфейса:

С помощью этих настроек мы ограничили число mac-адресов до 5.

## Часть 4. - Атака Mac-Spoofing
### Атака
Атака подразумивает ручную смену mac-address'а на какой-либо другой внутри сети. Это позволяет злоумышленнику получать пакеты, которые до этого он видеть не мог:

### Защита
Всё достаточно просто. Для защиты от подобного вида атак всего-лишь достаточно закрепить за отедльным пользователем отедльный mac-адрес. Сделать это нам поможет port security:

## Часть 5. - VLAN hopping
## Атака
Данная атака позволяет проникнуть в недоступный VLAN и прослушивать его содержимое. Для простейшей реализации данной атаки необходимо просто настроить файл /etc/network/interfaces следующим образом:

Далее, если, например, пустить arp запросы по сети, то, запустив wireshark, мы сможем увидеть их в 20 vlan'е:

## Защита
Здесь можно дать несколько рекомендаций.
Т.к. эта атака возможна только если интерфейс работает в режиме транка, то есть простой совет - никогда не оставлять интерфейсы настроенными на автоматическую работу в режиме транка.
Ну и ещё одно, то, что будет продемонстрировано на экране - ещё один возможный способ взлома. DTP. Его отключение повысит надёжность системы:

## Часть 6. - ACL настройка
Перейдём к настройке ACL.

-Debian10 (192.168.20.10)-
Для этого придётся в роутере создавать правила и уже после этого отправлять их. Начнём с конца. Debian10 не должен иметь доступ никуда, кроме интернета. Значит создаём правило:

Небольшое разъяснение, зачем нужен permit ip any any в конце. Дело в том, что если за правило ни одно условие не сработало, то пакет просто сгорит, а нам нужно его отправить, в случае если Debian стучиться ни во VLAN 1 (который, кстати, не рекомендуется использовать ввиду угрозы атаки VLAN hopping), ни во VLAN10. Выгружаем правило:

Перезагружаем сеть и проверяем работу правила:
Debian потерял доступ к VLAN1 и 10, но доступ к интернету сохранил, а значит задача выполнена.

-Windows7- (192.168.10.10)
С ней уже немного по другому. Доступа нужно лишить только до VLAN20. Это делает нашу работу немного легче. Создаём правило:

И выгружаем его:

Делаем проверку и вуоля - есть контакт с интернетом и VLAN1, но нету с VLAN20:

При этом kali всё также имеет контакт с VLAN20:

-KaliLinux- (192.168.1.10)
Самое, пожалуй, простое правило, которое, однако, требует понимания, что именно нужно взять в настройках. Создадим его:

Выгрузим правило:

Теперь проверим конфигурацию. С Windows всё работает:

Но вот у kali доступа нет:

И проблема здесь явно не в том, что хост вне зоны досягаймости:

Конфигурация роутера (скриншоты сделаны чуть раньше правил, они были добавлены позже):

Здесь уже полное описания каждого правила, где 101 - vlan1, 103 - vlan20: