По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В наших материалах по Cisco, посвященных конфигурации сетевых устройств мы часто встречаемся со стандартными листами (списками) контроля доступа. А теперь поговорим о расширенных. Расширенные листы могут также фильтровать трафик по следующим параметрам:
IP-адреса - фильтрация на основе IP-адреса источника и адреса назначения;
Порты - фильтрация на основе порта источника / порта назначения;
Тип протокола TCP/IP - протоколы TCP, UDP, IP и так далее;
Что делать?
Для начала необходимо создать лист. Сделаем это с помощью команды:
access list NUMBER permit|deny IP_PROTOCOL SOURCE_ADDRESS WILDCARD_MASK [PROTOCOL_INFORMATION] DESTINATION_ADDRESS WILDCARD_MASK PROTOCOL_INFORMATION
Синтаксис команды следующий:
NUMBER - номер листа;
PERMIT/DENY - разрешение или запрет трафика;
SOURCE/DESTINATION ADDRESS - адреса источника и назначения;
WILDCARD_MASK - обратная маска;
PROTOCOL_INFORMATION - название или номер протокола TCP, UDP, IP и так далее;
Кстати, для расчета wildcard (обратной) маски, вы можете воспользоваться нашим калькулятором подсетей:
Калькулятор подсетей
Следующим шагом необходимо применить наш свежесозданный лист на интерфейс и его направление (на вход или выход):
ip access-group NUMBER out
Параметры in и out определяют направление, на котором будет применен лист контроля доступа
Для нумерации расширенных листов контроля доступа необходимо использовать следующую нумерацию: со 100 до 199 и с 2000 до 2699
Пример настройки (сценарий №1)
В топологии указанной ниже, нам нужно разрешить пользователям из подсети 10.0.0.0/24 доступ к серверу S2 (адрес 192.168.0.1), но не к серверу S1 (адрес 172.16.0.1/24).
Для начала, напишем ACL и разрешим доступ к серверу S2. Сделаем это мы следующей командой:
access-list 100 permit ip 10.0.0.0 0.0.0.255 192.168.0.1 0.0.0.0
Данная команда разрешает весь трафик из подсети 10.0.0.0 на хост 192.168.1.0. Затем, запретим доступ к серверу S1:
access-list 100 deny ip 10.0.0.0 0.0.0.255 172.16.0.1 0.0.0.0
Наконец, применим данные листы контроля доступа на интерфейсе R1:
int fa0/0
ip access-group 100 in
Пример настройки (сценарий №2)
Приведем иной пример использования расширенных листов контроля доступа: У нас снова есть сеть 10.0.0.0/24 и сервер S1, который слушает порт 80. Нам нужно разрешить пользователям доступ к веб-ресурсам на данном сервере, но также необходимо запретить какой-либо другой доступ, к примеру Telnet.
Для начала, нам нужно разрешить трафик из пользовательской подсети к веб-серверу на порту 80, что выполняется командой
access-list 100 permit tcp 10.0.0.0 0.0.0.255 172.16.0.1 0.0.0.0 eq 80
Используя ключевое слово TCP, мы можем фильтровать пакеты по портам источника и назначения. В примере выше, мы разрешили путь трафику из подсети 10.0.0.0 на хост 172.16.0.1 на порт 80 (веб-порт).
Теперь нужно запретить Telnet трафик из подсети 10.0.0.0 в подсеть 172.16.0.1. Для этого нужен еще один аксес-лист, на этот раз с запрещающим выражением:
access-list 100 deny tcp 10.0.0.0 0.0.0.255 172.16.0.1 0.0.0.0 eq 23
Далее, применим его на интерфейс с помощью следующих команд:
int fa0/0
ip access-group 100 in
Как мы уже описывали в предыдущей статье, в конце каждого листа всегда есть всезапрещающее правило. После применения первого правила, весь остальной трафик ходить не будет.
Всем привет! На IP-телефонах Cisco, которые зарегистрированы на Cisco Unified Communications Manager (CUCM) , можно просматривать статусные сообщения о состоянии телефона и сетевую статистику в реальном времени. Эта информация доступна с самого телефона и может быть полезна при траблшутинге системы.
/p>
Для доступа к статусным сообщениям нужно на IP-телефоне Cisco нажать физическую кнопку Settings, далее в меню настроек выбрать Status (Состояние) и затем нажать Status Messages (Сообщения о состоянии). Сообщение отображается вместе со временем его появления.
Сообщение Описание
BootP server used Информационное сообщение, телефон получил IP адрес через BootP сервер, а не через DHCP сервер
File auth error Произошла ошибка, когда телефон пытался проверить подписанный файл. Это сообщение содержит имя файла, с которым возникла проблема. Вероятная проблема – файл поврежден, необходимо удалить и добавить заново телефон через Cisco Unified Communications Manager Administration tool. Либо это проблема с CTL файлом и в этом случае нужно запустить CTL клиент и обновить CTL файл, убедившись, что в него включены необходимые TFTP серверы.
CFG file not found Именной файл конфигурации и файл конфигурации по умолчанию не был найден на TFTP сервере. Файл конфигурации для определенного телефона создается при добавлении телефона в базу данных CUCM. Если телефон не был добавлен в базу данных, то TFTP-сервер генерирует ответ CFG File Not Found.
CFG TFTP Size Error Конфигурационный файл слишком большой для файловой системы телефона. Нужно перезагрузить телефон.
Checksum Error Скачанный файл ПО поврежден. Необходимо скачать новую копию файла прошивки телефона и поместить его в каталог TFTP.
DHCP timeout DHCP сервер не отвечает. Возможные проблемы: большая нагрузка на сеть (выполнить проверку, когда нагрузка уменьшится), нет сетевой связанности между DHCP сервером и телефоном (проверить сетевой доступ между этими элементами сети) или не работает сам DHCP сервер (проверить его конфигурацию).
DNS timeout DNS сервер не отвечает. Возможные проблемы: большая нагрузка на сеть (выполнить проверку, когда нагрузка уменьшится), нет сетевой связанности между DNS сервером и телефоном (проверить сетевой доступ между этими элементами сети) или не работает сам DNS сервер (проверить его конфигурацию).
DNS unknown host DNS не смог разрешить имя TFTP сервера или CUCM. Необходимо убедиться, что имена хостов TFTP сервера или CUCM настроены правильно в DNS или использовать IP-адреса вместо имен хостов.
Duplicate IP Другое устройство уже использует IP адрес, который присвоен телефону. Если телефону присвоен статический адрес, то нужно проверить, что ни у какого другого устройства нет такого же адреса, а если используется DHCP, то следует проверить конфигурацию DHCP сервера.
Error update locale Один или более файлов локализаций не был найден в директории TFTP или файл оказался не валидным, и локализация не была изменена. Необходимо убедиться что следующие файлы находятся в поддиректориях TFTP сервера: tones.xml, glyphs.xml, dictionary.xml, kate.xml
IP address released Телефон остается в режиме ожидания пока не включится питание или пока DHCP адрес не будет сброшен.
Load ID incorrect Load ID программного обеспечения неправильного типа. Нужно проверить Load ID, назначенный телефону (во вкладке Device - Phone) и убедиться, что он введен правильно.
Load rejected HC Загруженное приложение несовместимо с аппаратным обеспечением телефона. Эта ошибка возникает, когда происходит попытка установить на телефоне версию ПО, которое не поддерживает аппаратные изменения на этом телефоне.
No default router В DHCP или статической конфигурации не указан default router. Если телефон имеет статические адреса, то необходимо проверить что default router был указан, а если используется DHCP, то нужно проверить его конфигурацию.
No DNS server IP В DHCP или статической конфигурации не указан адрес DNS сервер. Нужно проверить что он указан на телефоне или на DHCP сервера.
Programming error Произошла ошибка во время программирования телефона. Нужно попробовать перезагрузить телефон и если проблема не устранится, то обратиться в службу техподдержки Cisco.
XmlDefault.cnf.xml, or .cnf.xml corresponding to the phone device name Информационное сообщение с указанием имени конфигурационного файла.
TFTP access error TFTP сервер указывает на директорию, которая не существует. Необходимо проверить что у DHCP сервера или телефона правильно указан адрес TFTP.
TFTP file not found Запрашиваемый файл (.bin) не найден в директории TFTP. Нужно проверить, что Load ID присвоен телефону (во вкладке Device - Phone) и что директория TFTTP сервера содержит .bin файл с этим идентификатором загрузки в качестве имени.
TFTP server not authorized Указанный TFTP-сервер не может быть найден в CTL телефона. Это может быть по нескольким причинам: DHCP-сервер настроен неправильно и не обслуживает правильный адрес сервера TFTP, если телефон использует статический IP-адрес, телефон может быть настроен с неправильным адресом сервера TFTP или если адрес сервера TFTP верен, может возникнуть проблема с файлом CTL (в этом случае нужно запустить CTL клиент и обновить CTL файл).
TFTP timeout TFTP сервер не отвечает. Возможные проблемы: большая нагрузка на сеть (выполнить проверку, когда нагрузка уменьшится), нет сетевой связанности между TFTP сервером и телефоном (проверить сетевой доступ между этими элементами сети) или не работает сам TFTP сервер (проверить его конфигурацию).
Теперь рассмотрим меню сетевой статистики. Чтобы попасть в него нужно на IP-телефоне Cisco нажать физическую кнопку Settings, далее в меню настроек выбрать Status (Состояние) и Netwkork Statistics (Статистика сети).
Там можно увидеть следующие поля
Поле Описание
Rcv (Rx Frames) Количество пакетов, полученных телефоном
Xmt Frames (Tx Frames) Количество пакетов, отправленных телефоном
REr (Rx Broadcasts) Количество broadcast пакетов, полученных телефонном
BCast Количество broadcast пакетов, отправленных телефонном
Phone Initialized Сколько времени прошло с момента инициализации телефона
Elapsed Time Сколько времени прошло с момента перезагрузки телефона
Port 1 Состояние PC порта телефона (скорость и дуплекс)
Port 2 Состояние Network порта
Привет! В предыдущей статье, посвященной основам WLAN, вы узнали о беспроводных клиентах, формирующих ассоциации с беспроводными точками доступа (AP) и передающих данные по Wi-Fi. В сегодняшней статье мы рассмотрим анатомию защищенного соединения в беспроводных сетях.
Основы защищенного соединения в беспроводных сетях.
Все клиенты и точки доступа, которые соответствуют стандарту 802.11, могут сосуществовать на одном канале. Однако не всем устройствам, поддерживающим стандарт 802.11, можно доверять. Нужно понимать, что данные передаются не как в проводной сети, то есть непосредственно от отправителя к получателю, а от приемника до ближайшей точки доступа, располагаемой в зоне досягаемости.
Рассмотрим случай, изображенный на рисунке ниже. Беспроводной клиент соединяется с каким-либо удаленным объектом с использованием зашифрованного пароля. В сети так же присутствуют два не доверенных пользователя. Они находятся в пределах диапазона сигнала клиента и могут легко узнать пароль клиента, перехватив данные, отправленные по каналу. Особенности беспроводной связи позволяют легко перехватывать пересылаемые пакеты злоумышленниками.
Если данные передаются по беспроводным каналам, как их можно защитить от перехвата и взлома? В стандарте 802.11 предусмотрены механизмы безопасности, которые используются для обеспечения доверия, конфиденциальности и целостности беспроводной сети. Далее более подробно разберем методы беспроводной безопасности.
Аутентификация.
Для того чтобы начать использовать беспроводную сеть для передачи данных, клиенты сначала должны обнаружить базовый набор услуг (BSS), а затем запросить разрешение на подключение. После чего клиенты должны пройти процедуру аутентификации. Зачем это делать? Предположим, что ваша беспроводная сеть позволяет подключиться к корпоративным ресурсам, располагающим конфиденциальной информацией. В этом случае доступ должен предоставляться только тем устройствам, которые считаются надежными и доверенными. Гостевым пользователям, если они вообще разрешены, разрешается подключиться к другой гостевой WLAN, где они могут получить доступ к не конфиденциальным или общедоступным ресурсам. Не доверенным клиентам, вообще рекомендуется запретить доступ. В конце концов, они не связаны с корпоративной сетью и, скорее всего, будут неизвестными устройствами, которые окажутся в пределах досягаемости вашей сети.
Чтобы контролировать доступ, WLAN могут аутентифицировать клиентские устройства, прежде чем им будет разрешено подключение. Потенциальные клиенты должны идентифицировать себя, предоставив информацию учетных данных для точки доступа. На рисунке ниже показан основной процесс аутентификации клиента.
Существует много методов аутентификации по «воздуху». Есть методы, которые требуют ввода только кодового слова, которое является общим для всех доверенных клиентов и AP. Кодовое слово хранится на клиентском устройстве и при необходимости передается непосредственно в точку доступа. Что произойдет, если устройство будет утеряно или похищено? Скорее всего, любой пользователь, владеющий данным устройством, сможет аутентифицироваться в сети. Другие, более строгие методы аутентификации требуют взаимодействия с корпоративной базой данных пользователей. В таких случаях конечный пользователь должен ввести действительное имя пользователя и пароль.
В обычной жизни, при подключении к любой беспроводной сети, мы неявно доверяем ближайшей точке доступа проверку подлинности нашего устройства. Например, если вы на работе, используя устройство с беспроводной связью, найдете WI-Fi, скорее всего, подключитесь к ней без колебаний. Это утверждение верно для беспроводных сетей в аэропорту, торговом центре, или дома - вы думаете, что точка доступа, которая раздает SSID, будет принадлежать и управляться организацией, в которой вы находитесь. Но как вы можете быть уверены в этом?
Как правило, единственная информация, которой вы владеете- это SSID транслируемый в эфир точкой доступа. Если SSID знаком, вы, скорее всего, подключитесь к ней. Возможно, ваше устройство настроено на автоматическое подключение к знакомому SSID, так что оно подключается автоматически. В любом случае, есть вероятность невольно подключиться к тому же SSID, даже если он рассылается злоумышленником.
Некоторые атаки, организованные злоумышленником, осуществляются посредством подмены точки доступа. «Поддельная» точка доступа, аналогично настоящей, так же рассылает и принимает запросы, и затем осуществляет ассоциацию клиентов с АР. Как только клиент подключается к «поддельной» AP, злоумышленник может легко перехватить все данные передаваемые от клиента к центральному узлу. Подменная точка доступа может также отправлять поддельные фреймы управления, которые деактивируют подключенных клиентов, для нарушения нормального функционирования сети.
Чтобы предотвратить этот тип атаки, называемой «man-in-the-middle», клиент должен сначала идентифицировать точку доступа, и только потом подключиться, используя логин и пароль (пройти аутентификацию). На рисунке ниже показан простой пример данного защищенного подключения. Также, клиент, получая пакеты управления, должен быть уверен, что они отправлены с проверенной и доверенной точки доступа.
Конфиденциальность сообщений.
Предположим, что клиент изображенный на рисунке 3, должен пройти аутентификацию перед подключением к беспроводной сети. Клиент должен идентифицировать точку доступа и её фреймы управления для подключения перед аутентификацией себя на устройстве. Отношения клиента с точкой доступа могли бы быть более доверительными, но передача данных по каналу все еще подвергается опасности быть перехваченной.
Чтобы защитить конфиденциальность данных в беспроводной сети, данные должны быть зашифрованы. Это возможно кодированием полезной нагрузки данных в каждом фрейме, пересылаемым по WI-Fi, непосредственно перед отправкой, а затем декодирования ее по мере поступления. Идея заключается в использование единого метода шифрования/дешифрования как на передатчике, так и на приемнике, чтобы данные могли быть успешно зашифрованы и расшифрованы.
В беспроводных сетях каждый WLAN может поддерживать только одну схему аутентификации и шифрования, поэтому все клиенты должны использовать один и тот же метод шифрования при подключении. Вы можете предположить, что наличие одного общего метода шифрования позволит любому клиенту сети перехватывать пакеты других клиентов. Это не так, потому что точка доступа при подключении к клиенту высылает специальный ключ шифрования. Это уникальный ключ, который может использовать только один клиент. Таким образом точка доступа рассылает каждому клиенту свой уникальный ключ. В идеале точка доступа и клиент- это те два устройства, которые имеют общие ключи шифрования для взаимодействия. Другие устройства не могут использовать чужой ключ для подключения. На рисунке ниже конфиденциальная информация о пароле клиента была зашифрована перед передачей. Только точка доступа может успешно расшифровать его перед отправкой в проводную сеть, в то время как другие беспроводные устройства не могут.
Точка доступа также поддерживает «групповой ключ» (group key), когда ей необходимо отправить зашифрованные данные всем клиентам ячейки одновременно. Каждый из подключенных клиентов использует один и тот же групповой ключ для расшифровки данных.
Целостность сообщения
Шифрование данных позволяет скрыть содержимое от просмотра, при их пересылке по общедоступной или ненадежной сети. Предполагаемый получатель должен быть в состоянии расшифровать сообщение и восстановить исходное содержимое, но что, если кто-то сумел изменить содержимое по пути? Получатель не сможет определить, что исходные данные были изменены.
Проверка целостности сообщений (MIC)- это инструмент безопасности, который позволяет защитить от подмены данных. MIC представляет собой способ добавления секретного штампа в зашифрованный кадр перед отправкой. Штамп содержит информацию о количестве битов передаваемых данных. При получении и расшифровке фрейма устройство сравнивает секретный шифр с количеством бит полученного сообщения. Если количество бит совпадает, то соответственно данные не были изменены или подменены. На рисунке ниже изображен процесс MIC.
На рисунке показано, что клиент отправляет сообщение точке доступа через WLAN. Сообщение зашифровано, «741fcb64901d». Сам процесс MIC заключается в следующем:
Исходные данные –«P@ssw0rd».
Затем вычисляется секретный шифр MIC (штамп).
После вычисления штампа происходит шифрование данных и MIC завершается.
На стороне получателя следует расшифровка, вычисление MIC и сравнение штампов.