По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Фаервол на Микротике основан на базе принципов iptables в Linux позволяет фильтровать входящий и исходящий трафик по определенным правилам. В статье мы хотим рассказать про ключевые компоненты Firewall, дизайне и реализации этого инструмента. Погнали!
Общее представление
Основная идея любого фаервола это определение того, что разрешено и запрет всего остального. Так работают все современные инструменты фильтрации. При наличии фаервола, сеть можно разделить на ненадежные, полу - надежные и надежные.
Firewall Chains
Цепочки (последовательности) фаерволов сопоставляют по своим правилам входящий и исходящий с интерфейса трафик. После того, как трафик попал под определенное правило («сматчился»), вы можете совершать определенные манипуляции с ним: разрешить, блокировать, отклонить, внести в лог запись и так далее. В Mikrotik есть следующие флаги: Input, Output и Forward.
Input Chain
Input матчит входящий на интерфейсы маршрутизатора трафик. Условно говоря – это прилетающие на роутера IP - пакеты. Обычная практика – дропать пакеты, прилетающие на WAN, направленные на сканирование портов, попытки взлома и прочие. Помимо этого, многие блокируют входящий трафик изнутри локальной сети (например, допуск к Winbox или SSH должен быть только с определенного VLAN – остальные дропаются).
Всегда используйте VLAN – это базовое разграничение, которое позволит вам обеспечить современные стандарты безопасности.
Output Chain
Как можно догадаться по названию, данный инструмент направлен на фильтрацию исходящего от роутера трафика. Здесь можно блокировать запросы, исходящие непосредственно с роутера: например, DNS или ICMP запрос с роутера.
Forward Chain
Самое интересное – данный инструмент «матчит» трафик проходящий через Mikrotik с одного интерфейса на другой. Пример: пакет, отправленный с хоста внутри LAN через маршрутизатор в сторону провайдера. Пакет прилетает на внутренний интерфейс, а выходит через WAN.
Firewall Actions
Правила на фаерволе могут делать множество вещей, основные из которых: accept (принять), drop (сбросить) и отклонить (reject).
Accept
Данное правило позволяет просто «пропустить» проходящий через фаервол трафик. Никакой модификации или изменения маршрута – пакету будет позволено продолжить свой изначальный путь.
Reject
Фаервол может легко отклонить (сделать reject) пакетов, которые попадут под определенное правило. При этом, источнику такого пакета будет отправлено уведомление о соответствующей блокировке.
В данном методе есть один весомый минус: в случае, если злоумышленник попробует «сканировать» порты или совершить другой вид атаки – отправленные в его сторону REJECT сообщения лишь помогут ему в злодеяниях. Поэтому, в целях безопасности, мы рекомендуем использовать DROP.
Drop
Данное правило «дропает» пакет без отправления уведомления об этом источнику. Этот метод наиболее безопасен на этапе защиты своего Mikrotik от сканирования портов и прочих атак.
Firewall Rules
Правила Firewall определяют пакеты, которые будут обработаны на уровне фаервола, а какие будут отброшены. Каждое правило – это комбинация параметров IP – адресации (источник/получатель пакета), цепочек (chains), действий (actions), интерфейсов и прочих опций. Как мы говорили ранее – хорошо настроенный фаервол пропустит только необходимый для бизнеса трафика, дав запрет на пропуск всего остального потока трафика. Указывая набор разрешающих правил, всегда замыкайте их на конце строчкой «DENY ALL» (запретить все).
Chains
Каждое создаваемое правило назначается определенной цепочке (chain). После определения принадлежности к цепочке, пакеты проходят проверку через последовательность правил в порядке убывания (сверху вниз).
Порядок правил в фаерволе играет важную роль! Поэтому, от последовательности проверки зависит эффективность фильтрации.
Actions
Правило отрабатывает по одному из основных действий: принять (accept), отклонить (reject) и отбросить (drop). Выше мы подробнее рассказывали про каждое из указанных действий.
Адресация
Нашему правилу можно сказать, по какому критерию проводить блокировку: это может быть протокол, IP – адрес (это может быть как хост с /32 маской, так и целая подсеть с /24, например). Помимо этого, критерием могут быть физические или логические интерфейсы (eth/GRE).
Комментарии
Создавая правила комментируйте их. Это важно, как и при программировании – код без комментариев очень сложно анализировать и понимать в будущем.
Советы
Хотим так же поделиться парой полезных советов по настройке Firewall:
Разрешайте только необходимый для работы трафик - да, это сложно. Но методом проб и ошибок мы рекомендуем добиться той настройки фаервола, в рамках которой все ваши подключения будут ясны и понятны.
Подключения только с определенного пула адресов - это может быть удаленный офис, IP – адреса ЦОД или VPN адресация. Тут нужно быть особенно бдительным.
В конце правил всегда используйте «deny all» - после того, как вы выполнили первую и вторую рекомендации и весь тип трафика по протоколам, адресации, источникам (в том числе L7, например) четко определен – в конце цепочки добавьте правило запрета всего. Это будет означать, дословно: «Все, что не разрешено - запрещено».
Атакуйте свою сеть! - да, да, вы не ослышались. Конечно, без фанатизма :) Мы предлагаем периодически сканировать порты на вашем фаерволе. Например, это можно делать с помощью утилиты исследования сети Nmap.
Всем привет! Мы начинаем рассказывать о продуктах унифицированных коммуникаций разработанных компанией Cisco Systems. В сегодняшней статье мы рассмотрим подключение и регистрацию IP-телефона Cisco к Cisco Unified Communications Manager (CUCM) .
Как это работает?
При подключении IP-телефона Cisco к CUCM используются следующие функции и сервисы:
Network Time Protocol (NTP)
Cisco Discovery Protocol (CDP)
Dynamic Host Configuration Protocol (DHCP)
Power Over Ethernet (PoE)
Trivial File Transfer Protocol (TFTP)
Domain Name System (DNS)
Процесс регистрации телефона происходит следующим образом:
Телефон получает питание c помощью блока питания или при помощи PoE;
Телефон загружает ПО, которое хранится локально в его памяти;
Телефон узнает голосовой VLAN ID при помощи CDP;
Телефон использует DHCP чтобы узнать свой IP адрес, маску подсети, шлюз и адрес TFTP сервера;
Телефон связывается с TFTP сервером и запрашивает конфигурационный файл. (У каждого телефона есть конфигурационный файл, который имеет вид SEP<мак_адрес>.cnf.xml);
Телефон регистрируется на CUCM, который указан в конфигурационном файле;
Файл SEP<мак_адрес>.cnf.xml содержит список CUCM серверов, в том порядке, в котором телефон должен проходить регистрацию. Также он содержит список TCP портов, которые используются в SCCP коммуникации, список ПО для каждой модели телефона и сервисные URI, которые используются телефоном.
Телефоны добавить в CUCM можно несколькими путями:
Ручное добавление: Добавление нового телефона и настройка всех параметров вручную
Авторегистрация: Добавление и настройка телефона автоматически, при подключении к сети
Использование Bulk Administration Tool (BAT) : Добавление нескольких телефонов при помощи .csv файла
Настройка
В данной статье мы разберем ручное подключение IP-телефона к CUCM. Для этого нужно выполнить следующие шаги:
Заходим в веб-интерфейс CUCM и переходим в меню Device –Phone, где нажимаем Add New для добавления нового телефона.
Выбираем модель телефона в выпадающем списке и нажимаем Next.
Выбираем протокол, по которому будет работать телефон (SCCP или SIP; некоторые телефоны поддерживают только один протокол и в таком случае этот шаг будет пропущен).
На этой странице указываем информацию о телефоне. У четырех пунктов нет дефолтных значений и их нужно вести вручную:
MAC Address: в этом поле указываем уникальный MAC-адрес телефона, который можно посмотреть либо в меню телефона, либо на самом аппарате;
Device Pool: этот пункт содержит общие настройки телефона, которые зависят от его местоположения и будущего пользователя. Для базовой настройки выбираем Default;
Phone Button Template: этот пункт определяет какой шаблон кнопок будет применен к телефону;
Device Security Profile: этот пункт отвечает за применение настроек, относящихся к безопасности. Можно использовать стандартную настройку – Standard SCCP/SIP Non-Secure Profile;
После этих шагов нажимаем Save и после перезагрузки страницы слева появится панель Association Information.
В ней нажимаем Line [1] – Add New DN чтобы добавить Directory Number для этого телефона. В открывшемся окне указываем следующие параметры:
Directory Number – номер конечного устройства;
Alerting Name – имя телефону, которое будет видно звонящему (тут можно вводить на русском языке);
ASCII Alerting Name – имя которое будет отображаться у телефонов, не поддерживающих Unicode;
Display – имя, которое используется как внутренний CallerID;
Line Text Label – текст, который будет отображаться на телефоне, для описания выбранной линии;
После того как мы прописали всю необходимую информацию нажимаем Save. Затем возвращаемся в предыдущий раздел где нажимаем кнопку Apply Config чтобы загрузить на новый конфигурационный файл на телефон.
В последующем добавлять новые телефоны такой же модели можно если в меню Phone Configuration нажать на COPY и ввести данные нового телефона.
Всем привет! Мы продолжаем рассказывать про протокол маршрутизации OSPF. В этой статье мы рассмотрим создание конкретных типов областей. Подробнее про области можно прочитать в предыдущей статье.
Предыдущие статьи:
Расширенные возможности OSPF: Области
Короткая Область (Stubby Area)
Рисунок 1 - топология OSPF
Пришло время сделать нашу область 1 из рисунка 1 короткой областью. Это внесение небольших настроек в конфигурацию. На каждом устройстве в этой области нам нужно установить область 1 в качестве заглушки. Вот наша конфигурация:
ATL2# configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
ATL2 (config)#router ospf 1
ATL2 (config-router)#area 1 stub
ATL2 (config-router)#end
ATL2#
ORL# configuration terminal
Enter configuration commands, one per line. End with CNTL/Z .
ORL(config)#router ospf 1
ORL(config-router)#area 1 stub
ORL(config-router)#end
ORL#
Это вызовет сброс соседства. После внесения изменений настало время просмотреть таблицу маршрутизации и базу данных OSPF.
show ip route ospf
Как мы и надеялись, теперь таблица маршрутизации стала меньше! Больше нет детализации внешних префиксов из ASBR. Вместо этого у нас есть маршрут по умолчанию, автоматически генерируемый ABR. Этот маршрут по умолчанию конечно необходим, потому что маршрутизаторы в области 1 все еще должны иметь возможность доступа к удаленным префиксам (если это необходимо).
Теперь пришло время изучить базу данных OSPF. Это именно то, что мы ожидали бы увидеть в области заглушки:
show ip ospf database
Type 4 LSA и Type 5 LSA фильтруются, и теперь существует Type 3 LSA для маршрута по умолчанию.
Видео: протокол OSPF (Open Shortest Path First) за 8 минут
Полностью Короткая Область (Totally Stubby Area)
Если мы хотим быть еще более эффективными в нашем примере, мы можем преобразовать область 1 в полностью короткую область. Это устранит Type 3 LSA, которые используются для объявления Loopback 0 на ATL и связей между ATL и AT2. Конечно, все равно будет объявлен маршрут по умолчанию, потому что теперь он нужен больше, чем когда-либо! Вот такая конфигурация и верификация:
ATL2# configuration terminal
Enter configuration commands , one per line . End with CNTL/Z.
ATL2 (config)#router ospf 1
ATL2 (config-router )#area 1 stub no-summary
ATL2 (config-router )#end
ATL2#
show ip route ospf
show ip ospf database
Not So Stubby Area (NSSA)
Если вам необходимо ввести внешние префиксы в область заглушки, вы должны сделать ее Not So Stubby Area (NSSA). Это позволяет внешние префиксы, которые будут пересылаться через зону-заглушку, определять как LSA типа 7. Затем ABR преобразует их в LSA типа 5 для распространения через домен OSPF (потенциально).
Ниже настройка для нашей схемы:
ATL2# configuration terminal
Enter configuration commands , one per line. End with CNTL/Z.
ATL2 (config)#router ospf 1
ATL2 (config-router)#no area 1 stub
ATL2 (config-router)#area 1 nssa
ATL2 (config-router)#end
ATL2#
ORL# configuration terminal
Enter configuration commands , one per line . End with CNTL/Z.
ORL(config)#router ospf 1
ORL(config-router)#no area 1 stub
ORL(config-router)#area 1 nssa
ORL(config)#interface loopback10
ORL(config-if)#ip address 172.16.10.З 255.255.255.0
ORL(config)#interface loopback20
ORL(config-if)#ip address 172.16.20.З 255.255.255.0
ORL(config-if)#exit
ORL(config)#router eigrp 200
ORL(config-router)#network 172.16.10.З 0.0.0.0
ORL(config-router)#network 172.16.20.З 0.0.0.0
ORL(config-router)#exit
ORL(config)#router ospf 1
ORL(config-router)#redistribute eigrp 200 subnets metric 1000
ORL(config-router)#end
ORL#
Интересно просмотреть результаты нашей настройки. Давайте начнем с изучения маршрутов OSPF и базы данных OSPF на ORL:
show ip route ospf
show ip ospf database
Из таблицы маршрутизации видно, что мы снова изучаем объявления Type 3 из области 0 (1.1.1.1 и 10.12.12.0). База данных OSPF доказывает, что NSSA работает так, как объявлено на данный момент. Мы можем видеть внешние префиксы, внесенные в область 1 как Type 7 в базе данных. Давайте быстро проверим ATL, чтобы увидеть, появляются ли они там как Type 5 LSA, как мы ожидаем.
show ip route ospf
show ip ospf database
Да, выводимая информация дает нам полное понимание, как работает NSSA. Префиксы существуют как Type 5s, и мы видим это в таблице маршрутизации.
Примечание: область NSSA не имеет динамически генерируемого маршрута по умолчанию без настройки этой функции. Так, наша сеть не будет работать! Чтобы создать маршрут по умолчанию, просто используйте следующую команду на маршрутизаторе ATL2:
area 1 nssa default-information-originate
Totally NSSA
Поскольку вы уже освоили Totally Stubby, скорее всего вы уже понимаете, что происходит с Totally NSSA. Здесь мы блокируем дополнительные типы LSA из этой области. К ним относятся Type 3 LSA. И снова для нас автоматически создается маршрут по умолчанию.
Вот настройки и результирующие проверки:
ATL2# configuration terminal
Enter configuration commands , one per line . End with CNTL/Z.
ATL2 (config)#router ospf 1
ATL2 (config-router )#area 1 nssa no-summary
ATL2 (config-router )#end
ATL2#
show ip route ospf
show ip ospf database
Как видно из выводимой информации, что у нас невероятно сжатая таблица маршрутизации (для OSPF) на роутере ORL.
Как вы можете видеть, OSPF отлично справляется с автоматической фильтрацией маршрутов за счет использования специальных областей и типов LSA. В следующий раз мы рассмотрим варианты ручной фильтрации маршрутов в OSPF.