По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Для захвата трафика можно использовать маршрутизаторы Cisco, при помощи утилиты Cisco Embedded Packet Capture, которая доступна, начиная с версии IOS 12.4.20T. В этой статье мы расскажем, как настроить EPC для захвата пакетов на роутере, сохранять их на flash памяти или экспортировать на ftp/tftp сервер для будущего анализа, при помощи анализатора пакетов, например, такого как Wireshark.
Давайте рассмотрим некоторые из основных функций, которые предлагает нам Embedded Packet Capture:
Экспорт пакетов в формате PCAP, обеспечивающий анализ с помощью внешних инструментов
Возможность задать различные параметры буфера захвата
Отображение буфера захвата
Захват IPv4 и IPv6 пакетов в пути Cisco Express Forwarding
Прежде чем начать конфигурацию Cisco EPC необходимо разобраться с двумя терминами, которые будут использоваться в процессе – Capture Buffer(буфер захвата) и Capture Point (точка захвата)
Capture buffer – это зона в памяти для хранения пакетных данных. Существует два типа буферов захвата Linear (линейный) и Circular (кольцевой):
Linear Capture Buffer – когда буфер захвата заполнен, он перестает захватывать данные
Circular Capture Buffer – когда буфер заполнен, он продолжает захватывать данные, перезаписывая старые данные
Capture Point – это точка транзита трафика, в которой фиксируется пакет. Тут определяется следующее:
IPv4 или IPv6
CEF (Cisco Express Forwarding) или Process-Switched
Интерфейс (например Fast Ethernet 0/0, Gigabit Ethernet 1/0)
Направление трафика: входящий (in), исходящий (out) или оба
Настройка Cisco Embedded Packet Capture
Рассмотрим настройку на примере нашей схемы, где мы хотим захватить входящие и исходящие пакеты на интерфейсе FastEthernet 0/0 от ПК с адресом 192.168.1.5 до веб-сервера wiki.merionet.ru с адресом 212.193.249.136
Первым делом мы создадим буфер, который будет хранить захваченные пакеты. Для этого используем команду monitor capture buffer [имя] size[размер] [тип] . Создадим буфер merionet_cap, размером 1024 килобайта (1 мегабайт, стандартный размер) и сделаем его линейным.
Router#monitor capture buffer merionet_cap size 1024 linear
Далее мы можем настроить захват определенного трафика. В нашем случае нужно захватить трафик между 192.168.1.5 и 212.193.249.136. Это достигается при помощи списков контроля доступа ACL. Мы можем использовать стандартные или расширенные списки доступа в зависимости от требуемой детализации. Если список доступа не настроен, то захвачен будет весь трафик.
Router(config)#ip access-list extended web-traffic
Router(config-ext-nacl)#permit ip host 192.168.1.5 host 212.193.249.136
Router(config-ext-nacl)#permit ip host 212.192.249.136 host 192.168.1.5
Наш список доступа включает трафик, исходящий от обоих хостов, потому что мы хотим захватить двунаправленный трафик. Если бы мы включили только один оператор ACL, тогда был бы зафиксирован только односторонний трафик. Теперь свяжем наш буфер с access-list’ом, при помощи команды monitor capture buffer [название_буфера] filter access-list [название_ACL]
Router#monitor capture buffer merionet_cap filter access-list web-traffic
Затем следующем шагом мы определяем, какой интерфейс будет точкой захвата. В нашем случае это FastEthernet 0/0, и мы будем захватывать как входящие, так и исходящие пакеты. Во время этой фазы конфигурации нам нужно предоставить имя для точки захвата.
Также очень важно ввести команду ip cef для обеспечения минимального влияния на процессор маршрутизатора, при помощи Cisco Express Forwarding. Если ip cef не включен, то появится сообщение IPv4 CEF is not enabled.
Используем команду monitor capture point ip cef [имя_точки] [интерфейс] [направление] .
Router#monitor capture point ip cef MNpoint FastEthernet0/0 both
Теперь мы связываем сконфигурированную точку захвата с буфером захвата командой monitor capture point associate [название_точки][название_буфера] . На этом этапе мы готовы начать сбор пакетов.
Router#monitor capture point associate MNpoint merionet_cap
Чтобы начать сбор пакетов используем команду monitor capture point start [название_интерфейса] .
Router# monitor capture point start MNpoint
Чтобы остановить процесс захвата используется команда monitor capture point stop [название_интерфейса] .
Router# monitor capture point stop MNpoint
Полезные команды проверки:
show monitor capture buffer – показывает состояние буфера захвата
show monitor capture point – показывает состояние точки захвата
show monitor capture buffer [название_буфера] – показывает информацию о захваченных пакетах
show monitor capture buffer [название_буфера] dump – показывает содержание буфера
Экспорт данных
В большинстве случаев захваченные данные необходимо будет экспортировать в сетевой анализатор трафика (например, WireShark) для дополнительного анализа в удобном для пользователя интерфейсе. Захваченный буфер можно экспортировать в несколько местоположений, включая: flash: (на маршрутизаторе), ftp, tftp, http, https, scp и другие.
Для экспорта буфера используется команда monitor capture buffer[имя_буфера] export [адрес] .
Router#monitor capture buffer merionet_cap export tftp://192.168.1.10/capture.pcap
После этого файл capture.pcap появится на нашем TFTP сервере, и мы можем открыть его в сетевом анализаторе.
Протокол Syslog - это способ для сетевых устройств отправлять сообщения о событиях на сервер регистрации - обычно известный как Syslog сервер. Этот протокол поддерживается широким спектром устройств и может использоваться для регистрации различных типов событий. Например, маршрутизатор может отправлять сообщения о том, что пользователи подключаются через консоль, а веб-сервер может регистрировать события, в которых отказано в доступе.
Большинство сетевых устройств, таких как маршрутизаторы и коммутаторы, могут отправлять сообщения системного журнала. Кроме того, серверы *nix также могут генерировать данные системного журнала, как и большинство брандмауэров, некоторые принтеры и даже веб-серверы, такие как Apache. Серверы на базе Windows изначально не поддерживают Syslog, но большое количество сторонних инструментов позволяет легко собирать данные журнала событий Windows или IIS и пересылать их на сервер Syslog.
В отличие от SNMP, Syslog не может использоваться для «опроса» устройств для сбора информации. Например, SNMP имеет сложную иерархическую структуру, которая позволяет станции управления запрашивать у устройства информацию о таких вещах, как данные о температуре или доступное дисковое пространство. Это невозможно с Syslog - он просто отправляет сообщения в центральное место, когда инициируются определенные события.
Syslog серверы
Syslog - отличный способ объединить логи из нескольких источников в одном месте. Как правило, большинство серверов Syslog имеют несколько компонентов, которые делают это возможным.
Syslog слушатель: Syslog сервер должен получать сообщения, отправленные по сети. Процесс прослушивания собирает данные системного журнала, отправленные через 514 UDP порт. Как мы знаем UDP-сообщения не подтверждаются или не гарантируются, поэтому имейте в виду, что некоторые сетевые устройства будут отправлять данные Syslog через 1468 TCP порт для обеспечения доставки сообщений.
База данных: большие сети могут генерировать огромное количество данных syslog’а . Хорошие серверы будут использовать базу данных для хранения логов для быстрого поиска.
Программное обеспечение для управления и фильтрации: из-за больших объемов данных иногда бывает сложно найти конкретные записи в журнале. Решение состоит в том, чтобы использовать syslog сервер, который автоматизирует часть работы и позволяет легко фильтровать и просматривать важные сообщения журнала. Серверы должны иметь возможность генерировать оповещения, уведомления и алерты в ответ на выбранные сообщения, чтобы администраторы сразу узнавали, когда возникла проблема, и могли предпринять быстрые действия
Syslog сообщения
Сообщения системного журнала обычно содержат информацию, помогающую определить основную информацию о том, где, когда и почему был отправлен лог: IP-адрес, отметка времени и фактическое сообщение.
Системный журнал использует концепцию, называемое “facility”, чтобы идентифицировать источник сообщения на любом компьютере. Например, facility “0” будет сообщением ядра, а facility «11» будет сообщением FTP. Это восходит своими корнями к syslog'а UNIX. В большинстве сетевых устройств Cisco используются коды объектов «Local6» или «Local7».
Syslog сообщения также имеют поле уровня серьезности. Уровень серьезности указывает, насколько важным считается сообщение. Серьезность «0» является чрезвычайной ситуацией, «1» - это предупреждение, которое требует немедленных действий, а шкала продолжается вплоть до «6» и «7» - информационных и отладочных сообщений.
0
Emergency
Система не работоспособна
1
Alert
Система требует немедленного вмешательства
2
Critical
Состояние системы критическое
3
Error
Сообщения об ошибках
4
Warning
Предупреждения о возможных проблемах
5
Notice
Сообщения о нормальных, но важных событиях
6
Informational
Информационные сообщения
7
Debug
Отладочные сообщения
Недостатки syslog
У протокола syslog есть несколько недостатков.
Во-первых, проблема согласованности. Протокол Syslog не определяет стандартный способ форматирования содержимого сообщения - и существует столько же способов форматирования сообщения, сколько существует разработчиков. Некоторые сообщения могут быть удобочитаемыми, а некоторые нет. Syslog это не волнует - он просто предоставляет способ передачи сообщения.
Есть также некоторые проблемы, которые возникают из-за того, что syslog использует UDP в качестве транспорта - поэтому возможно потерять сообщения из-за перегрузки сети или потери пакетов.
Наконец, есть некоторые проблемы безопасности. В сообщениях syslog’а нет аутентификации, поэтому один компьютер может выдать себя за другой компьютер и отправить ложные события журнала. Он также подвержен повторным атакам.
Несмотря на это, многие администраторы считают, что syslog является ценным инструментом, и что его недостатки относительно незначительны.
У нас есть Windows Server 2008 R2 и сейчас мы сделаем из него Контроллер домена - Domain Controller (DC). Погнали!
Первым делом – запускаем Server Manager:
Затем выбираем опцию Roles и добавляем новую роль для нашего сервера, нажав Add Roles:
Нас встречает мастер установки ролей, а также просят убедиться, что учетная запись администратора имеет устойчивый пароль, сетевые параметры сконфигурированы и установлены последние обновления безопасности. Прочитав уведомление кликаем Next
Сервер, выступающий в роли DC обязан иметь статический IP адрес и настройки DNS Если данные настройки не были выполнены заранее, то нас попросят выполнить их в дальнейшем на одном из этапов.
В списке доступных ролей выбираем Active Directory Domain Services. Мастер сообщает, что для установки данной роли нужно предварительно выполнить установку Microsoft .NET Framework. Соглашаемся с установкой, нажав Add Required Features и кликаем Next
Нас знакомят с возможностями устанавливаемой роли Active Directory Domain Services (AD DS) и дают некоторые рекомендации. Например, рекомендуется установить, как минимум 2 сервера с ролями AD DS (т.е сделать 2 DC) на случай, чтобы при выходе из строя одного сервера, пользователи домена все ещё могли бы залогиниться с помощью другого. Также, нас предупреждают о том, что в сети должен быть настроен DNS сервер, а если его нет, то данному серверу нужно будет дать дополнительную роль – DNS. После того, как прочитали все рекомендации, кликаем Next чтобы продолжить установку.
Наконец, нам предоставляют сводную информацию об устанавливаемой роли и дополнительных компонентах для подтверждения. В данном случае, нас уведомляют о том, что будет установлена роль AD DS и компонент .NET Framework 3.5.1. Для подтверждения установки кликаем Install.
Дожидаемся пока завершится процесс установки роли и компонентов.
Через какое-то время перед нами появится результат установки, он должен быть успешным как для роли так и для компонентов Installation succeeded. Закрываем мастер установки, нажав Close.
Вернувшись в Server Manager мы увидим, что у нас появилась роль AD DS, однако ее статус неактивен. Чтобы продолжить настройку кликаем на Active Directory Domain Services.
Перед нами открывается уведомление о том, что наш сервер пока ещё не является контроллером домена, и чтобы это исправить нам следует запустить мастер настройки AD DS (dcpromo.exe). Кликаем на ссылку Run the Active Directory Domain Services Installation Wizard или же запускаем его через Пуск – Выполнить – dcpromo.exe.
Перед нами открывается мастер настройки AD DS. Расширенный режим установки можно не включать. Для продолжения кликаем Next
Нас встречает уведомление о том, что приложения и SMB клиенты, которые используют старые небезопасные криптографические алгоритмы Windows NT 4.0 при установке соединений, могут не заработать при взаимодействии с контроллерами домена на базе Windows Server 2008 и 2008 R2, поскольку по умолчанию, они не разрешают работу по данным алгоритмам. Принимаем данную информацию к сведению и кликаем Next
Далее нам нужно выбрать принадлежность данного контроллера домена. Если бы у нас уже имелся лес доменов, то данный DC можно было бы добавить туда, либо добавив его в существующий домен, либо же создав новый домен в существующем лесу доменов. Поскольку мы создаем контроллер домена с нуля, то на следующей вкладке мы выбираем создание нового домена и нового леса доменов Create a new domain in a new forest и кликаем Next.
После этого нам предлагают задать FQDN корневого домена нового леса. В нашем случае мы выбрали merionet.loc. Сервер проверит свободно ли данное имя и продолжит установку, нажимаем Next.
Далее задаем функциональный уровень леса доменов. В нашем случае - Windows Server 2008 R2 и кликаем Next.
Обратите внимание, что после задания функционального уровня, в данный лес можно будет добавлять только DC равные или выше выбранного уровня. В нашем случае от Windows Server 2008 R2 и выше.
Далее, нам предлагают выбрать дополнительные опции для данного DC. Выберем DNS Server и нажимаем Next.
В случае, если ваш сервер ещё не имеет статического IP адреса, перед вами появится следующее предупреждение с требованием установить статический IP адрес и адрес DNS сервера. Выбираем No, I will assign static IP addresses to all physical network adapters
Устанавливаем статические настройки IP адреса и DNS. В нашем случае – в роли DNS сервера выступает дефолтный маршрутизатор (Default Gateway) нашей тестовой сети.
Далее, установщик предлагает нам выбрать путь, по которому будут храниться база данных Active Directory, лог-файл и папка SYSVOL, которая содержит критичные файлы домена, такие как параметры групповой политики, сценарии аутентификации и т.п. Данные папки будут доступны каждому DC в целях репликации. Мы оставим пути по умолчанию, но для лучшей производительности и возможности восстановления, базу данных и лог-файлы лучше хранить в разных местах. Кликаем Next.
Далее нас просят указать пароль учетной записи администратора для восстановления базы данных Active Directory. Пароль данной УЗ должен отличаться от пароля администратора домена. После установки надежного сложного пароля кликаем Next.
Далее нам выводят сводную информацию о выполненных нами настройках. Проверяем, что все корректно и кликаем Next.
Мастер настройки приступит к конфигурации Active Directory Domain Services. Поставим галочку Reboot on completion, чтобы сервер перезагрузился по завершении конфигурирования.
После перезагрузки сервер попросит нас залогиниться уже как администратора домена MERIONET.
Поздравляем, Вы создали домен и контроллер домена! В следующей статье мы наполним домен пользователями и позволим им логиниться под доменными учетными записями.