---
# System prepended metadata

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

---

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

Группа Admins:
1. На свитче CO-LAN-SW-1 видим, что трафик от группы admin не пересылается. Меняем эту опцию на "forward"
![](https://i.imgur.com/iYRO3nj.png)

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

![](https://i.imgur.com/68ZS8b5.png)

![](https://i.imgur.com/dcMsNzw.png)

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


Прикрепляем к Core 2(e0/1.30) ACL на in(на Core-1 уже есть):
![](https://i.imgur.com/NqplquK.png)
 
4. В интернет(Google) могут ходить только пользователи IT и HQ

Убираем правило из inside-in permit ip any any на CISCO ASA. Таким образом мы даем доступ в интернет только разрешенным пользователям.
![](https://i.imgur.com/j305GV2.png)



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

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

![](https://i.imgur.com/MuCRlEq.png)



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

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

Видим, что саб-интерфейс выключен. Включаем его
![](https://i.imgur.com/jOX3Piw.png)

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

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

Для реализации убираем на Core 1 и Core 2 строку permit any any (этот access-list уже навешен на саб-интерфейс 0.20)
![](https://i.imgur.com/zsnhb3I.png)

На Core-1 удаляем из правил строку permit ip tcp any any из access-list fin-in
![](https://i.imgur.com/grGceuI.png)


## OSPF
Настройки ospf:
С самого начала сэмитируем обрыв кабеля и уберем два соединения, чтобы наша топология приняла вот такой вид, а так же выключим интерфейсы e0/1 на роутере Core 1 и e0/3 на роутере Core 2:
![](https://i.imgur.com/cdxJgF3.png)

Для работы ospf на Core 1:
1. Включаем аутентификацию на интерфейсе e0/2:
![](https://i.imgur.com/RfSePf5.png)

3. Видим, что на данном маршрутизаторе отключена по умолчанию отправка Hello-пакетов на все интерфейсы. Включим ее только для e0/2. Так же включим аутентификацию для зоны 0.
    Было:
    ![](https://i.imgur.com/LwjCCCW.png)
 
    Стало:
    ![](https://i.imgur.com/2v1Pk7t.png)
4. Далее включим на sub-интерфейсах core-2 ip helper-address 10.100.100.100. Это позволит пересылать нам широковещательные запросы DHCP от компьютеров в сети одним пакетом сразу на DHCP-сервер.(проделываем данный пункт и для core-1) 
![](https://i.imgur.com/cbsyVw7.png)

Смотрим через wireshark трафик от Core-2 (ip 10.0.0.3) и видим, что dhcp пересылается:
![](https://i.imgur.com/R43n37Q.png)


Смотрим маршруты на Core 1, видим на нем маршруты, полученные через ospf и делаем выводы, что у нас все "завелось":
![](https://i.imgur.com/prOLqOP.png)

Смотрим на маршруты Core 2:
![](https://i.imgur.com/AusaO9J.png)


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

![](https://i.imgur.com/L38Q12l.png)

Теперь настраиваем ospf с wan-rt.
![](https://i.imgur.com/WjwrSpF.png)

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

CORE-2:
![](https://i.imgur.com/izBitpB.png)

Стало:
![](https://i.imgur.com/QNnTSTW.png)

Видим, что маршруты появились в таблице маршрутизации WAN-RT:
![](https://i.imgur.com/JI4ZcBF.png)

CORE-1 - включаем отправку hello-пакетов через интерфейс 0.6 и включаем аутентификацию на интерфейсе. Так же отключаем проверку mtu:
![](https://i.imgur.com/y3Pd78Y.png)
![](https://i.imgur.com/ttWTETV.png)

Видим, что соседи "поднялись":
WAN-RT:
![](https://i.imgur.com/8pNrLCm.png)

CORE-1:
![](https://i.imgur.com/4N4n4Jc.png)

CORE-2:
![](https://i.imgur.com/DA4iZld.png)

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



## BGP
Видим, что настройка BGP в зоне 10 неправильная
![](https://i.imgur.com/MFh7kth.png)

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

Видим, что на BR2-RT нет 20-го соседа по bgp:
![](https://i.imgur.com/unMcGQW.png)

Исправляем:
![](https://i.imgur.com/YKQg269.png)

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

Видим, что на BR1-RT нет 30-го соседа по bgp:
![](https://i.imgur.com/0d3QmQO.png)

Исправляем:
![](https://i.imgur.com/bVwMrcI.png)





## telnet

Подключение с IT-Admin на CO-LAN-SW1:
![](https://i.imgur.com/5AFTgPe.png)

Подключение с IT-Admin на CO-LAN-SW2:
![](https://i.imgur.com/9anJFYq.png)

Подключение с IT-Admin на CORE-SW
![](https://i.imgur.com/KfwjIXC.png)

Подключение с IT-Admin на CO-DC-SW
![](https://i.imgur.com/PIZtbAN.png)

На CO-DC-SW навешиваем ACL
![](https://i.imgur.com/Yk86qmv.png)


# 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
![](https://i.imgur.com/s0XZsTe.png)

Core-2
![](https://i.imgur.com/ud6Dfnr.png)

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





# NHRP
Добавляем на маршрутизаторы аутентификацию:
![](https://i.imgur.com/7HhYjch.png) 
(аналогично для других двух)
Добавляем автоматическое соответствие между адресами маршрутизаторов
ip nhrp map multicast dynamic

На spoke-роутеры мы прописываем ![](https://i.imgur.com/uDwPQfM.png) где указываем, что хотим пересылать multicast-пакеты на hub-роутер по адресу 100.68.0.50(внешний адрес DMVPN-HUB)

# DMVPN
Видим, что tunnel-интерфейс имеет ip-адрес в качестве соответствия. Однако необходим физический интерфейс, меняем на tunnel source e0/0(на WAN-RT и BR2-RT)
![](https://i.imgur.com/FpQoHIi.png)

WAN-RT
![](https://i.imgur.com/4fqGalv.png)


BR2-RT
![](https://i.imgur.com/nhnThZU.png)

Видим, что ipsec туннель строится до WAN-RT(проходят 4 фазы построения туннеля(я понимаю, что это не DMVPN, но дальше мои поиски зашли в тупик. Об этом в конце))
![](https://i.imgur.com/CblYtKr.png)



# ip dhcp snooping

Делаем порт коммутатора CO-LAN-SW-1 e0/0 доверенным портом для dhcp-snooping(аналогично CO-DC-SW)
![](https://i.imgur.com/me0BR33.png)

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

На коммутаторе CO-LAN-SW-1 сделали dhcp snooping для vlan-ов.
![](https://i.imgur.com/2VskF5U.png)

Включили dhcp snooping на CO-DC-SW
 ![](https://i.imgur.com/NcO9931.png)


# Проблемы

Не получилось настроить 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-сессий видно следующее:
![](https://i.imgur.com/aix7JbO.png)


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