По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Ищете вариант автоматического сохранения (резервного копирования) конфигурации на Cisco ASA? Если да, тогда Вам сюда. Многие делают бэкапирование конфигурации через меню ASDM. Но как это автоматизировать? Ответ ниже.
Сегодня мы рассмотрим вариант автоматического сохранения конфигурации Cisco ASA на удаленный FTP-сервер. Также возможен вариант бэкапирования на TFTP-сервер. Отличие лишь в синтаксисе команды. Данный функционал поддерживается на версии программного обеспечения 9.2(1) и выше. Также стоит учесть, что Cisco Embedded Event Manager может быть запушен только тогда, когда устройство работает в одно контекстном режиме.
Ниже я приведу примеры настройки данного функционала как через ASDM, так и с помощью командной строки. Для этих целей мы будем использовать возможности Cisco Embedded Event Manager. Если коротко, то это механизм, позволяющий создавать сценарии для автоматизации работы устройств. Подробнее о нем можно почитать на официальном сайте Cisco на английском языке.
И так, приступим.
Вариант через ASDM (Adaptive Security Device Manager)
Переходим на вкладку "Configuration", далее "Device manager". Слева в древовидной структуре выбираем "Advanced" и далее "Embedded Event Manager":
Справа нажимаем "Add" и заполняем форму:
Пойдем по пунктам:
"Applet Name" - имя нашего апплета
"Description" - описание
Дальше самое интересное:
"Events" - здесь мы описываем необходимое нам событие
Из выпадающего списка выбираем "Once-a-day timer". Он нас как раз и интересует. Также указываем время для ежедневного выполнения:
Далее переходим к пункту "Actions". Здесь нам необходимо указать порядковый номер команды "Sequence", например 10. В следующей строке вводим саму команду:
backup /noconfirm location ftp://user:password@ip_вашего_ftp_сервера//
В итоге получается вот так:
Далее идем по накатанному пути: "Apply" и "Save".
Теперь каждый день в 21:05:00 Cisco ASA будет создавать резервную копию конфигурации на наш FTP-сервер. В качестве FTP-сервера использовался один из сетевых дисковых накопителей.
Используем CLI
Здесь все намного проще. Переходим в режим глобального конфигурирования и вводим следующие команды:
Задаем имя апплета:
event manager applet Backup
Описание апплета:
description Backup configuration
Создаем наше событие:
event timer absolute time 21:05:00
И сама команда:
action 10 cli command "backup /noconfirm location ftp://user:password@ip_вашего_ftp_сервера//
Далее стандартное:
wr
Как я уже писал в начале статьи, возможен вариант использования TFTP-сервера. В этом случае команда будет выглядеть заметно короче:
action 10 cli command "backup /noconfirm location tftp://ip_вашего_tftp_сервера//
Запустить апплет можно командой:
event manager run имя_апплета
Для просмотра всех настроенных задач вводим команду:
show running-config event manager
Также присутствует возможность посмотреть стандартные счетчики:
show counters protocol eem
Пример вывода:
# show counters protocol eem<
Protocol Counter Value Context
EEM COMMANDS 11 Summary
EEM FILE_ERRORS 1 Summary
Ну и конечно же команда отладки:
show debug event manager
Автор предпочитает использовать вариант именно с CLI. Например с помощью Ansible мы можем настроить бэкапирование на всех имеющихся Cisco ASA. Пример можно подглядеть в официальной документации по Ansible.
В этой статье мы разберем принцип работы и настройку IP-телефонии по Ethernet сетям.
В мире IP-телефонии телефоны используют стандартные порты Ethernet для подключения к сети, и поэтому для отправки и приема голосового трафика, передаваемого посредством IP-пакетов, они используют стек протоколов TCP/IP. Чтобы это работало, необходимо, чтобы порт коммутатора работал как порт доступа, но, в то же время, этот порт работал как магистраль для передачи другого трафика.
Принцип работы VLAN для передачи данных и голоса
До IP-телефонии компьютер и телефон располагались на одном рабочем месте. Телефон подключался по специальному телефонному кабелю (телефонный UTP-кабель). Причем этот телефон был подключен к специальному голосовому устройству (часто называемому voice switch или частной телефонной станцией private branch exchange [PBX]). ПК, конечно же, подключался с помощью Ethernet кабеля (UTP витой пары) к обычному коммутатору локальной сети, который находился в коммутационном шкафу - иногда в том же коммутационном шкафу, что и голосовой коммутатор (voice switch). На рисунке показана эта идея.
Предположим, что у нас есть три виртуальные сети VLAN1, VLAN2 и VLAN3. Виртуальные сети VLAN 1 и VLAN 3 содержат по две пары ПК, которые подключаются к коммутатору через отдельные интерфейсы. Для сети VLAN 1 отведены четыре интерфейса "fa0/12", "fa0/11", "fa0/22", и "fa0/21" соответственно. Аналогично, 4 интерфейса отведены для сети VLAN 3 - "fa0/15", "fa0/16", "fa0/23", и "fa0/24" соответственно. Сеть VLAN 2 состоит из двух ПК, которые подключаются к коммутатору через интерфейсы "Fa0/13" и " Fa0/14". Два коммутатора соединены между собой через магистраль, и интерфейсы "Gi0/1" и "Gi0/2".
Термин IP-телефония относится к отрасли сети, в которой телефоны используют IP-пакеты для передачи и приема голоса, представленного битами в части данных IP-пакета. Телефоны подключаются к сети, как и большинство других устройств конечных пользователей, используя либо кабель Ethernet, либо Wi-Fi. Новые IP-телефоны не подключаются непосредственно по кабелю к голосовому коммутатору, а подключаются к стандартной IP-сети с помощью кабеля Ethernet и порта Ethernet, встроенного в телефон. После чего телефоны связываются по IP-сети с программным обеспечением, которое заменило операции вызова и другие функции АТС.
Переход от использования стационарных телефонов, которые работали (некоторые работают по сей день) с использованием телефонных кабелей к новым IP-телефонам (которые нуждались в UTP-кабелях, поддерживающих Ethernet) вызвал некоторые проблемы в офисах.
В частности:
Старые, не IP-телефоны, использовали категорию UTP-кабелей, у которых частотный диапазон не поддерживал скорость передачи данных в 100-Mbps или 1000-Mbps.
В большинстве офисов был один кабель UTP, идущий от коммутационного шкафа к каждому столу. Теперь же на два устройства (ПК и IP-телефон) требовалось два кабеля от рабочего стола к коммутационному шкафу.
Прокладка нового кабеля к каждому рабочему месту вызовет дополнительные финансовые затраты, и плюс потребуется больше портов коммутатора.
Чтобы решить эту проблему, компания Cisco встроила небольшие трехпортовые коммутаторы в каждый телефон.
IP-телефоны включают в себя небольшой коммутатор локальной сети, расположенный в нижней части телефона. На рисунке показаны основные кабели, причем кабель коммутационного шкафа подключается напрямую к одному физическому порту встроенного коммутатора телефона, ПК подключается патч-кордом к другому физическому порту телефона, а внутренний процессор телефона подсоединяется к внутреннему порту коммутатора телефона.
Компании, использующие IP-телефонию, теперь могут подключать два устройства к одному порту доступа. Кроме того, лучшие практики Cisco, для проектирования IP-телефонии, советуют поместить телефоны в один VLAN, а ПК в другой VLAN. Чтобы это работало, порт коммутатора действует частично в режиме канала доступа (для трафика ПК) и частично как магистраль (для трафика телефона).
Особенности настройки VLAN’ов на этом порту:
VLAN передачи данных: та же идея настройки, что и VLAN доступа на access порту, но определенная как VLAN на этом канале для пересылки трафика для устройства, подключенного к телефону на рабочем месте (обычно ПК пользователя).
Voice VLAN: VLAN для пересылки трафика телефона. Трафик в этой VLAN обычно помечается заголовком 802.1 Q.
На рисунке изображена типичная конструкция локальной сети. Имеется коммутатор, подключенный к двум последовательным уровням сетей, VLAN 11 и VLAN 10, где сеть VLAN 11- Voice VLAN, содержащая 4 IP-телефона, и сеть VLAN 10 - Data VLAN, состоящая из 4 ПК.
Настройка и проверка работы Data и Voice VLAN
Для настройки порта коммутатора, который сможет пропускать голосовой трафик и информационные данные, необходимо применить всего несколько простых команд. Однако разобраться в командах, позволяющих просмотреть настройки режима работы порта, непросто, так как порт действует как access порт во многих отношениях.
Ниже показан пример настройки. В данном примере используются четыре порта коммутатора F0/1F0/4, которые имеют базовые настройки по умолчанию. Затем добавляются соответствующие VLAN’ы: VLAN 10 Data Vlan, VLAN 11- Voice Vlan. Далее все четыре порта настраиваются как порты доступа и определяется VLAN доступа (Vlan 10 Date Vlan). В конце настройки определяем на порт VLAN для передачи голосовых данных (Vlan 11- Voice Vlan). Данный пример иллюстрирует работу сети, изображенную на рисунке:
При проверке состояния порта коммутатора, из примера выше, увидим разницу в отображаемой информации выходных данных, по сравнению с настройками по умолчанию порта доступа и магистрального порта. Например, команда show interfaces switchport показывает подробные сведения о работе интерфейса, включая сведения о портах доступа. В примере 2 отображены эти детали (подчеркнуты) для порта F0/4 после добавления настроек из первого примера.
Первые три выделенные строки в выходных данных отображают детали настройки, соответствующие любому порту доступа. Команда switchport mode access переводит порт в режим порта доступа. Далее, как показано в третьей выделенной строке, команда switchport access vlan 10 определила режим доступа VLAN.
Четвертая выделенная строка показывает новый фрагмент информации: идентификатор Voice VLAN, активированная командой switchport voice vlan 11. Эта небольшая строка является единственной информацией об изменении состояния порта.
Фаервол на Микротике основан на базе принципов 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.