# Отчет по сетевой безопасности

Группа Admins:
1. На свитче CO-LAN-SW-1 видим, что трафик от группы admin не пересылается. Меняем эту опцию на "forward"

1. На FTP могут ходить все устройства
2. На WEB все, кроме HR

Для реализации задачи 1-2 правим вот этот access-list на Core-1 и Core-2 (он уже применен на обоих роутерах). Удаляем правило permit ip any any(иначе все настройки выше лишены смысла, а по умолчанию негласно в acl записывается deny any any)



3. На WEB-Server в dmz могут ходить все пользователи кроме FIN:

Прикрепляем к Core 2(e0/1.30) ACL на in(на Core-1 уже есть):

4. В интернет(Google) могут ходить только пользователи IT и HQ

Убираем правило из inside-in permit ip any any на CISCO ASA. Таким образом мы даем доступ в интернет только разрешенным пользователям.

5. Доступ из интернета (internet pc) может быть только до опубликованного веб сервера из dmz

Убираем правило permit icmp any any на CISCO ASA


Пользовательские (здесь ftp олицетворяет любое виндовое соединение)
1. ftp доступ с IT до всех должен быть разрешен

3. ftp доступ с HQ до всех кроме IT должен быть разрешен

Видим, что саб-интерфейс выключен. Включаем его

С ACL все в порядке

3. Весь  остальной доступ по ip c HR и FIN должен быть заблокирован

Для реализации убираем на Core 1 и Core 2 строку permit any any (этот access-list уже навешен на саб-интерфейс 0.20)

На Core-1 удаляем из правил строку permit ip tcp any any из access-list fin-in

## OSPF
Настройки ospf:
С самого начала сэмитируем обрыв кабеля и уберем два соединения, чтобы наша топология приняла вот такой вид, а так же выключим интерфейсы e0/1 на роутере Core 1 и e0/3 на роутере Core 2:

Для работы ospf на Core 1:
1. Включаем аутентификацию на интерфейсе e0/2:

3. Видим, что на данном маршрутизаторе отключена по умолчанию отправка Hello-пакетов на все интерфейсы. Включим ее только для e0/2. Так же включим аутентификацию для зоны 0.
Было:

Стало:
4. Далее включим на sub-интерфейсах core-2 ip helper-address 10.100.100.100. Это позволит пересылать нам широковещательные запросы DHCP от компьютеров в сети одним пакетом сразу на DHCP-сервер.(проделываем данный пункт и для core-1)

Смотрим через wireshark трафик от Core-2 (ip 10.0.0.3) и видим, что dhcp пересылается:

Смотрим маршруты на Core 1, видим на нем маршруты, полученные через ospf и делаем выводы, что у нас все "завелось":

Смотрим на маршруты Core 2:

И проверяем ping до DHCP сервера:


Теперь настраиваем ospf с wan-rt.

Во время настройки возникла проблема, что маршрутизаторы CORE-2/CORE-1 и WAN-RT не могли построить подключение из за "вечного" ожидания ответа. Данная проблема решилась путем отключения детекта mtu(ip ospf mtu-ignore)
Было:
WAN-RT:

CORE-2:

Стало:

Видим, что маршруты появились в таблице маршрутизации WAN-RT:

CORE-1 - включаем отправку hello-пакетов через интерфейс 0.6 и включаем аутентификацию на интерфейсе. Так же отключаем проверку mtu:

Видим, что соседи "поднялись":
WAN-RT:

CORE-1:

CORE-2:

Что касается роутера WAN-RT, прописываем в настройках ospf redistribute bgp 10, чтобы маршруты, полученные через bgp, могли передаваться на другие устройства через ospf.

## BGP
Видим, что настройка BGP в зоне 10 неправильная

Убираем строку network 0.0.0.0 и добавляем redistribute ospf 1. Данная настройка позволит передавать маршруты, полученные путем ospf-процесса с id 1 на другие маршрутизаторы по BGP.

Видим, что на BR2-RT нет 20-го соседа по bgp:

Исправляем:

P.s. тут я пока что не знаю, будет ли влиять добавление filter-list на работу bgp. Я знаю, что это правило разрешает анонс маршрутов внутри as-зоны.

Видим, что на BR1-RT нет 30-го соседа по bgp:

Исправляем:

## telnet

Подключение с IT-Admin на CO-LAN-SW1:

Подключение с IT-Admin на CO-LAN-SW2:

Подключение с IT-Admin на CORE-SW

Подключение с IT-Admin на CO-DC-SW

На CO-DC-SW навешиваем ACL

# HSRP

Данный протокол нужен для обеспечения отказоустойчивости системы. В таком случае несколько роутеров объединяется в группу, и этой группе назначается один ip-адрес(и, вроде бы, мак-адрес, но это не точно)

Меняем на Core 1 stadby 5 ip с 10.0.0.3 на 10.0.0.1. Теперь это виртуальный адрес для обоих маршрутизаторов, где Core-1 - запасной, а Core 2 - основной

На саб-интерфейсах 3.100, 1.10,1.20,1.30 у Core-2 и Core-1 настраиваем аутентификацию:

Core-1

Core-2

:::success
Stanby 99 потом удалил
:::

# NHRP
Добавляем на маршрутизаторы аутентификацию:
(аналогично для других двух)
Добавляем автоматическое соответствие между адресами маршрутизаторов
ip nhrp map multicast dynamic

На spoke-роутеры мы прописываем  где указываем, что хотим пересылать multicast-пакеты на hub-роутер по адресу 100.68.0.50(внешний адрес DMVPN-HUB)

# DMVPN
Видим, что tunnel-интерфейс имеет ip-адрес в качестве соответствия. Однако необходим физический интерфейс, меняем на tunnel source e0/0(на WAN-RT и BR2-RT)

WAN-RT

BR2-RT

Видим, что ipsec туннель строится до WAN-RT(проходят 4 фазы построения туннеля(я понимаю, что это не DMVPN, но дальше мои поиски зашли в тупик. Об этом в конце))

# ip dhcp snooping

Делаем порт коммутатора CO-LAN-SW-1 e0/0 доверенным портом для dhcp-snooping(аналогично CO-DC-SW)

:::success
Так делать не рекомендуется, лучше настроить через опцию 82 и включить на свитче настройки, при которой будет разрешаться пересылка пакетов, которые уже были помечены коммутатором
:::

На коммутаторе CO-LAN-SW-1 сделали dhcp snooping для vlan-ов.

Включили dhcp snooping на CO-DC-SW

# Проблемы

Не получилось настроить dmvpn в связи с тем, что не совсем понял, как работает эта технология. Я себе это представляю так:
1. Поднимаются mGRE интерфейсы
2. После этого через NHRP изучается соответствие виртуального адреса физическому. Эта вся информация хранится на hub-роутере(WAN-RT)
3. При генерировании трафика строится ipsec туннель со spoke до hub, hub пересылает информацию на искомы spoke, spoke отвечает hub, hub отвечает тому spoke, который запрашивал и далее два spoke разговаривают уже между собой по vpn-туннелю
4. Через BGP производится маршрутизация между этими точками

Но, NHRP-запросы не отправлялись до hub. Подозреваю, что это не безопасно делать через интернет в открытую, поэтому там открывается ipsec туннель для передачи этих данных до hub. Поэтому в wireshark трафик не видно NHRP, а IpSec видно. Причем видно 4 стадии, однако только при установлении канала от spoke до hub(видимо, я все-таки правильно додумался, но времени перенастроить нет).

И при просмотре dmvpn-сессий видно следующее:

# Рекомендации по безопасности
1. Сделать пароль при входе в режим enable
2. Как вариант - сделать аутентификацию для ipsec-туннелей на сертификатах. Можно на dhcp сервере развернуть NTP-сервер, чтобы время синхронизировалось и не приходилось настраивать вручную.
3. Сделать на DMZ внешний статичный ip-адрес, чтобы он лишний раз не ходил во внутрь сети + чтобы его ip-адрес не изменялся и был все время доступен.