Здравствуйте! Я почти 10 лет работаю в сфере ИТ и ИБ, всегда интересовался практической безопасностью, в настоящее время работаю пентестером. За все время работы я постоянно сталкивался с типовыми ошибками в настройках и дизайне инфраструктуры. Ошибки эти чаще всего досадные, легко устранимые, однако быстро превращают сеть в полигон для взлома. Порой кажется, что где-то специально учат так настраивать, насколько часто они встречались. Это и побудило меня написать данную статью, собрав все самое основное, что может улучшить защищенность.

В этой статье я не буду рассказывать про использование сложных паролей, максимального ограничения прав доступа, смене учетных записей по умолчанию, обновлению ПО, и других «типовых» рекомендациях. Цель статьи – рассказать о самых частых ошибках в настройках, заставить администраторов и специалистов ИБ задуматься над вопросом – «а все ли в моей сети хорошо?», а также показать, как можно оперативно прикрыть те или иные типовые уязвимости, используя встроенные или бесплатные средства, не прибегая к дополнительным закупкам.

Инструкций-рецептов намеренно не прикладываю, так как многое ищется очень легко по ключевым словам.

Maximum transmission unit (MTU) это максимальный объём данных, который может быть передан протоколом за одну итерацию. К примеру, Ethernet MTU равняется 1500, что означает, что максимальный объём данных, переносимый Ethernet фреймом не может превышать 1500 байт (без учёта Ethernet заголовка и FCS — Рис. 1).


Рис. 1

Давайте пробежимся с MTU по уровням OSI:

В данной статье рассмотрим такую интересную, на мой взгляд, технологию, как Private VLANs в теории и практике.

Для начала вспомним, что такое VLANы. VLAN – отдельная подсеть, отдельный домен бродкаста, используется для логической сегментации сети, ограничения домена широковещательной рассылки, безопасности и т.д.

Обычно сеть делится на VLANы, далее c помощью router-on-the-stick либо многоуровнего свича (любого устройства 3 уровня) включается маршрутизация (разрешается весь трафик), а потом, с помощью списков контроля доступа, прописывается кому, с кем и по какому протоколу разрешено “общаться” (или применяется контроль трафика исходя из требований политики безопасности вашей организации, как было бы написано в учебнике Cisco).

Одновременное использование двух провайдеров

Если в первом случае все понятно и однозначно, то в случае с одновременным использованием двух провайдеров возникают проблемы.
Для начала: нам надо обоих провайдеров проверять на «живость» и переключать все потоки на одного в случае, если кто то «упал». Это делается полностью аналогично проверке ISP1 в главе про Резервирование. С тем лишь отличием, что оба маршрута по умолчанию имеют одинаковую административную дистанцию

  ip route 0.0.0.0 0.0.0.0 Gate(ISP1) track 11
  ip route 0.0.0.0 0.0.0.0 Gate(ISP2) track 22

Типичная задача, которая тем не менее, продолжает вызывать массу вопросов.

Попробую вкратце описать суть технологии и подводные камни.

Итак, пусть у нас есть один пограничный маршрутизатор cisco с одним внутренним портом (g0/0) и двумя внешними (f0/0, f0/1). Есть подключение к двум провайдерам, каждый из которых выдал свой пул адресов Pool(ISP1) и Pool(ISP2) (это некоторые сети, принадлежащие конкретному провайдеру). Пусть для простоты адреса интерфейсов f0/0 и f0/1 из этих же пулов. И адреса шлюзов из этих же пулов (Gate(ISP1) и Gate(ISP2) соответственно).
Так как у нас нет возможности поднять BGP, значит мы должны на каждого из провайдеров прописать маршрут по умолчанию. И вот тут возникает первый вопрос: какую задачу мы хотим решить? Резервирование или одновременная работа с двумя провайдерами?

Будем считать, что вы уже активно осваиваете хитрости настройки через консоль. Пришло время рассказать ещё несколько тонкостей. О чём имеет смысл подумать при настройке маршрутизаторов и коммутаторов cisco.

Тонкость 1. Аккуратность.
Часто возникает задача что-нибудь добавить в текущую конфигурацию. Наверняка вы знаете, что многие элементы пишутся отдельно, а отдельно применяются (на интерфейс, ко всей железке и т.д.). Будьте крайне осторожны, изменяя настройки таких технологий, как PBR (route-map), QoS (policy-map), IPSec (crypto map), NAT. Лучше всего сначала снять их с использования, потом изменить, потом повесить снова. Связано это с тем, что все изменения вы вносите сразу же в состояние железки. Иногда то, что уже работает (например, подгружено в оперативку) конфликтует с новым конфигом. Не редки ситуации, когда железка уходит в перезагрузку после попытки изменения конфига.

Пример: пусть у нас есть route-map, примененный на интерфейс. Пусть нам надо его изменить. Наиболее «чистый» способ такой: