По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Восьмая часть тут. Формат Type Length Value (TLV) является еще одним широко используемым решением проблемы маршалинга данных. На рисунке 1 показан пример протокола маршрутизации от промежуточной системы к промежуточной системе IS-IS. На рисунке 1 пакет состоит из заголовка, который обычно имеет фиксированную длину, а затем из набора TLV. Каждый TLV форматируется на основе своего типа кода. В этом случае показаны два типа TLV (в IS-IS есть много других типов; два используются здесь для иллюстрации). Первый тип - 135, который несет информацию о версии 4 протокола IP (IPv4). Этот тип имеет несколько полей, некоторые из которых имеют фиксированную длину, например, метрика. Другие, однако, такие как префикс, имеют переменную длину; длина поля зависит от значения, размещенного в каком-либо другом поле в TLV. В этом случае поле длины префикса определяет длину поля префикса. Существуют также суб-TLV, которые имеют аналогичный формат и несут информацию, связанную с этой информацией IPv4. Тип 236 аналогичен 135, но он несет информацию по IPv6, а не IPv4. По существу, TLV можно рассматривать как полный набор автономной информации, переносимой в более крупном пакете. TLV состоит из трех частей: Тип кода, который описывает формат данных Длина, которая описывает общую длину данных Значение или сами данные Форматы на основе TLV менее компактны, чем форматы фиксированной длины, поскольку они содержат больше метаданных в самом пакете. Информация о типе и длине, содержащаяся в данных, предоставляет информацию о том, где искать в словаре информацию о форматировании, а также информацию о грамматике для использования (как каждое поле отформатировано и так далее). Форматы TLV компенсируют возможность изменять форматирование информации, передаваемой протоколом, не требуя обновления каждого устройства или позволяя некоторым реализациям выбирать не поддерживать все возможные TLV по сравнению с дополнительными метаданными, передаваемыми по проводам. TLV обычно считаются очень гибким способом маршалинга данных в протоколах. Словари общих объектов Одной из основных проблем с полями фиксированной длины является фиксированность определений полей; если вы хотите изменить протокол поля фиксированной длины, вам нужно увеличить номер версии и изменить пакет, или вы должны создать новый тип пакета с различными кодировками для полей. Форматирование TLV решает эту проблему путем включения встроенных метаданных с передаваемыми данными за счет передачи большего количества информации и уменьшения компактности. Общие скомпилированные словари пытаются решить эту проблему, помещая словарь в общий файл (или библиотеку), а не в спецификацию. Рисунок 2 иллюстрирует процесс. На рисунке 2 этот процесс начинается с того, что разработчик создает структуру данных для организации определенного набора данных, которые будут передаваться по сети. Как только структура данных построена, она компилируется в функцию или, возможно, копируется в библиотеку функций (1) и копируется в приемник (2). Затем приемник использует эту библиотеку для написания приложения для обработки этих данных (3). На стороне передатчика необработанные данные кодируются в формат (4), а затем передаются по протоколу через сеть к приемнику (5). Получатель использует свою общую копию формата данных (6) для декодирования данных и передачи декодированной информации принимающему приложению (7). Этот вид системы сочетает в себе гибкость модели на основе TLV с компактностью протокола фиксированного поля. Хотя поля имеют фиксированную длину, определения полей задаются таким образом, чтобы обеспечить быстрое и гибкое обновление при необходимости изменения формата маршалинга. Пока общая библиотека отделена от приложения, использующего данные, словарь и грамматика могут быть изменены путем распространения новой версии исходной структуры данных. Потребуется ли «День флага», если будет распространена новая версия структуры данных? Необязательно. Если номер версии включен в структуру данных, чтобы получатель мог сопоставить полученные данные с правильной структурой данных, то в системе одновременно может существовать несколько версий структуры данных. Как только отправитель не найден с использованием более старого формата данных, старая структура может быть безопасно отброшена по всей системе. Важно: в то время как системы фиксированного формата и TLV рассчитывают на то, что разработчики читают спецификации и пишут код как форму совместного использования грамматики и словаря, системы общей структуры данных, описанные в этих лекциях, рассчитывают на то, что общий словарь будет распространяться каким-то другим способом. Есть много различных способов сделать -это, например, новая версия программного обеспечения может быть распространена среди всех отправителей и получателей, или некоторая форма распределенной базы данных может использоваться для обеспечения того, чтобы все отправители и получатели получали обновленные словари данных, или некоторая часть приложения, которая специально управляет маршалингом данных, может быть распределена и сопряжена с приложением, которое генерирует и потребляет данные. Некоторые системы такого рода передают общий словарь как часть первоначальной настройки сеанса.
img
Во любой цепочке безопасности самым слабым звеном был и остается человек. Забывчивые сотрудники, которые пароли хранят в открытом виде, иногда даже приклеивают на монитор; любопытные пользователи, которые не прочь покликать по первой попавшейся кнопке или ссылке. Чем сидеть и ждать, когда кто-то извне взломает и потом принять меры, лучше самому выявить таких нарушителей и предотвратить взлом со всеми его последствиями. Одной из наиболее распространённых видов атак является фишинг атака. Фишинг это такой вид атаки, когда злоумышленник создает поддельную страницу, которая точь-в-точь копирует легальный сайт. Невнимательный пользователь перейдя по поддельной ссылке попадает на эту страницу. Так как внешний вид похож на доверенный ресурс, никто не догадывается проверить URL. Далее он, как ни в чем не бывало, вводит свои данные и нажимает на соответствующую кнопку. Страница перезагружается и перебрасывает пользователя уже на реальный сайт, а последний думает, что где-то ввёл что-то неправильно и еще раз вводит. А тем временем злоумышленник уже получил нужную ему информацию. Это могут быть пароли, номера кредитных карт и т.п. Данную атаку может провернуть даже начинающий хакер. Но мы лишим его такого удовольствия и сами раскинем свою сеть и посмотрим кто туда попадётся. В этом деле нам поможет бесплатный фреймворк gophish. Фреймворк мультиплатформенный, но я предпочитаю и советую поднять всё это на Linux машине. Подойдёт абсолютно любая версия. Перед тем как начать, посмотрите наш ролик "Информационная безопасность компании. Никаких шуток": Погнали. На сайте разработчика переходим по ссылке Download и качаем нужный нам дистрибутив. На Linux машину можно скачать сразу. Копируем ссылку на zip архив и в терминале вводим: wget https://github.com/gophish/gophish/releases/download/v0.8.0/gophish-v0.8.0-linux-64bit.zip Далее разархивируем скачанный файл: unzip gophish-v0.8.0-linux-64bit.zip Если в системе нет пакета unzip качаем его. Для Debian/Ubuntu apt-get install unzip Для RedHat/CentOS: yum install unzip Затем открываем файл config.json любым удобным вам редактором: nano config.json Меняем указанные ниже значения admin_server.listen_url 127.0.0.1:3333 IP/Port админ панели gophish admin_server.use_tls False Нужно ли защищённое соединение с админ панелью admin_server.cert_path example.crt Путь к SSL сертификату admin_server.key_path example.key Путь к приватному ключу SSL phish_server.listen_url 0.0.0.0:80 IP/Port самого фишинг сервера, куда переходят пользователи по ссылке Здесь первый параметр я поменял на 0.0.0.0:3333 так как мой сервер находится за межсетевым экраном и доступа извне туда нет. Но при необходимости можно организовать это. Также я отключил требование TLS. Во внутренней сети особой надобности в нем нет. Далее просто запускаем файл gophish командой: ./gophish И переходим на админскую часть нашего фишинг сервера. По умолчанию имя пользователя admin, а пароль gophish. Всё это можно потом поменять, но по порядку. При входе открывается панель, где видны проведённые атаки и результаты. Кликнув на иконке статистики можно перейти к детальным отчётам. Тут отображается вся информация о пользователях, которые перешли по ссылке, ввели данные. Есть еще отчёт по открытым письмам, но если пользователь не кликнул на ссылку в письме и не перешёл на нашу фишинговую страницу, то это значение не меняется. Поэтому, на мой взгляд, это просто лишняя информация. Теперь начнём непосредственно настраивать систему и готовить нашу атаку. Пойдем снизу вверх. На вкладке User Management можно создать новых пользователей. Для этого переходим на нужную страницу и нажимает на кнопку Add user: Хотя и пользователям можно назначать права, особого смысла тут тоже нет. Потому, что пользователь, во-первых, не видит никакие кампании другого пользователя, во-вторых, имеет те же самые права, что и администратор, с тем лишь отличием, что он не может создавать других пользователей или сбрасывать их пароли. На этой всё странице интуитивно понятно, так что не буду слишком углубляться. На вкладке Account Settings можно поменять имя пользователя пароль текущего пользователя. Следующая вкладка Sending Profiles. Вот тут то и переходим к этапу подготовки нашей атаки. На этой странице настраиваются профили, от имени которых будет идти атака. Вводим название профиля, e-mail, с которого будут рассылаться письма, адрес SMTP сервера и порт, имя пользователя и пароль при необходимости. Тут бы я хотел остановиться поподробней. Когда планировали свою атаку, мы решили создать почту на общедоступном почтовом ресурсе. Но там стоял лимит на число получателей, что в принципе и правильно. Поэтому первая наша кампания провалилась. И тогда мы оперативно создали новую DNS запись на нашем AD и провернули затею. Создание доменной записи я тут не буду объяснять, ибо этим занялись наши сисадмины, за что им спасибо. Далее можно создать mail заголовки, но для тестовой среды это не критично. После ввода данных можно отправить тестовое письмо, дабы проверить работоспособность нашего профиля: Затем переходим к созданию самой страницы. Делается это на вкладке Landing Pages. Здесь можно пойти двумя путями: сверстать свою страницу с нуля или же просто скопировать с реального сайта и подкорректировать нужное. Для этого предусмотрен очень удобный инструмент в самой системе. Нажав на кнопку Import Site вы можете ввести URL любого сайта и фреймворк сам подтянет оттуда весь дизайн, только учтите, что для этого системе нужен доступ в интернет. Чтобы перехватывать введённые данные, нужно поставить соответствующие галочки. Capture Submitted Data и Capture Passwords. Учтите, что пароли не шифруются и хранятся в базе системы в открытом виде! Также не забываем прописать адрес ресурса, куда будет перенаправляться пользователь после ввода данных. Следующий шаг создание шаблона письма, для чего переходим на страницу Email Template. Тут тоже можно и самому набрать текст или же импортировать уже готовое письмо. Ещё один минус, нельзя вставлять фото из локального ресурса, что досадно. Можно только вставить ссылку на картинку, что в моём случае тоже не сработало картинка не открывалась. Но есть и удобные фичи: переменные например. Ниже приведён список переменных, которые можно указать в тексте, создавая персонализированные письма. {{.RId}} Уникальный ID цели {{.FirstName}} Имя цели {{.LastName}} Фамилия цели {{.Position}} Должность {{.Email}} Почтовый адрес {{.From}} Отправитель {{.TrackingURL}} Ссылка отслеживания {{.Tracker}} Псевдоним <img src="{{.TrackingURL}}"/> {{.URL}} Адрес фишинг ссылки {{.BaseURL}} Та же фишинг ссылка, только без RID Далее создаем пользователя или группу пользователей, которые получат наше письмо. Делается это на вкладке Users & Groups. Здесь тоже разработчики предусмотрели массовый импорт адресов. Если у вас настроен AD и Exchange Server, попросите админов отдать вам список всех акттвных пользователей в формате CSV. Затем импортируйте их в систему. И, наконец, переходим к созданию самой атаки. Для этого переходим на вкладку Campaigns. Здесь в принципе дублируется основная панель. Выбираем New Campaign задаём название кампании, из выпадающих списков выбираем ранее созданные шаблоны письма и фейковой страницы, указываем профиль, с которого пойдут письма, и определяем целевую группу. В URL прописываем адрес нашего сервера. Здесь можно написать и IP или же, что еще лучше, задать доменное имя, которое похоже на доверенный ресурс. В этом случае пользователь в адресной строке увидит не IP, а полноценный домен. Также можно выставить дату начала кампании. И, собственно, запускаем кампанию и ждем пока кто-то попадётся на нашу удочку. Система заботливо показывает текущий статус отправки, и, в случае ошибки, указывает почему не удалось отправить письмо. На этом, пожалуй все. Система очень лёгкая, интуитивно понятная. Удачи в реализации!
img
Мы продолжаем рассказывать про протокол DHCP (Dynamic Host Configuration Protocol) . Мы уже знаем про принципы работы протокола и про его настройку на оборудовании Cisco, и сегодня речь пойдет о том, как находить и исправлять проблемы (заниматься траблшутингом) при работе с DHCP. Проблемы с DHCP могут возникать по множеству причин, таких как проблемы программного обеспечения, в операционных системах, драйверов сетевых карт или агентах ретрансляции, но наиболее распространенными являются проблемы с конфигурацией DHCP. Из-за большого числа потенциально проблемных областей требуется систематический подход к устранению неполадок. Задача 1. Устранение конфликтов IP адресов Срок действия адреса IPv4 может истекать у клиента, все еще подключенного к сети. Если клиент не возобновляет аренду, то сервер может переназначить этот IP-адрес другому клиенту. Когда клиент перезагружается, то он запрашивает адрес и если DHCP сервер не отвечает быстро, то клиент использует последний IP-адрес. Тогда возникает ситуация, когда два клиента используют один и тот же адрес, создавая конфликт. Команда show ip dhcp conflict отображает все конфликты адресов, записанные сервером DHCP. Сервер использует команду ping для обнаружения клиентов. Для обнаружения конфликтов клиент использует протокол ARP. Если обнаружен конфликт адресов, адрес удаляется из пула и не назначается, пока администратор не разрешит конфликт. Выгладит это так: Router# show ip dhcp conflict IP address Detection Method Detection time 192.168.1.33 Ping Feb 19 2018 10:33 AM 192.168.1.48 Gratuitous ARP Feb 19 2018 11:29 AM В столбце IP address указывается конфликтный адрес, в строке Detection Method указывается метод обнаружения (Ping – адрес был обнаружен когда при назначении нового адреса получил положительный ответ на пинг, Gratuitous ARP – конфликт обнаружен в ARP таблице) и Detection time показывает время обнаружения. Чтобы посмотреть список всех выданных адресов сервером используется команда show ip dhcp binding. Задача 2. Проверка физического подключения Сначала нужно проверить, что интерфейс маршрутизатора, действующий как шлюз по умолчанию для клиента, является работоспособным. Для этого используется команда show interface [интерфейс] , и если интерфейс находится в каком либо состоянии кроме как UP, то это означает что порт не передает трафик, включая запросы клиентов DHCP. Задача 3. Проверка связности, используя статический IP адрес При поиске проблем DHCP проверить общую работоспособность сети можно задав статический IP адрес у клиента. Если он может достичь сетевых ресурсов со статически настроенным адресом, то основной причиной проблемы является не DHCP. Задача 4: Проверить конфигурацию порта коммутатора Если DHCP клиент не может получить IP адрес с сервера, то можно попробовать получить адрес вручную, заставляя клиента отправить DHCP запрос. Если между клиентом и сервером DHCP есть маршрутизатор и клиент не может получить адрес, то причиной могут быть настройки портов. Эти причины могут включать в себя проблемы, связанные с транками и каналами, STP и RSTP. Конфигурация PortFast и настройка пограничных портов разрешают наиболее распространенные проблемы клиента DHCP, возникающие при первоначальной установке коммутатора. Задача 5: Проверка работы DHCP в одной и той же подсети или VLAN Важно различать, правильно ли работает DHCP, когда клиент находится в одной подсети или VLAN, что и DHCP-сервер. Если DHCP работает правильно, когда клиент находится в одной подсети, то проблема может быть ретранслятором DHCP (relay agent). Если проблема сохраняется даже при тестировании в одной подсети, то проблема может быть с сервером DHCP. Проверка конфигурации DHCP роутера Когда сервер DHCP находится в отдельной локальной сети от клиента, интерфейс маршрутизатора, обращенный к клиенту, должен быть настроен для ретрансляции запросов DHCP путем настройки helper адреса. Чтобы проверить конфигурацию маршрутизатора для начала нужно убедиться, что команда ip helper-address настроена на правильном интерфейсе. Она должна присутствовать на входящем интерфейсе локальной сети, содержащей DHCP клиентов, и должна быть направлена на правильный сервер DHCP. Для проверки используется команда show ip interface [интерфейс] . Далее нужно убедиться, что в глобальном режиме не была введена команда no service dhcp . Эта команда отключает все функции сервера DHCP и ретрансляции на маршрутизаторе. Для проверки используется команда show running-config | include no service dhcp. Если команда была введена, то она отобразится в выводе. Дебаг DHCP На маршрутизаторах, настроенных как DHCP-сервер, процесс DHCP не выполняется если маршрутизатор не получает запросы от клиента. В качестве задачи по траблшутингу нужно убедиться, что маршрутизатор получает запрос от клиента. Для этого дебага понадобится конфигурация ACL (Access Control List). Нужно создать расширенный Access List, разрешающий только пакеты с UDP портами назначения 67 или 68. Это типичные порты, используемые клиентами и серверами при отправке сообщений DHCP. Расширенный ACL используется с командой debug ip packet для того чтобы отображать только сообщения DHCP. Router(config)# access-list 100 permit udp any any eq 67 Router(config)# access-list 100 permit udp any any eq 68 Router(config)# end Router# debug ip packet 100 IP packet debugging is on for access list 100 *IP: s-0.0.0.0 (GigabitEthernet1/1), d-255.255.255.255, len 333, rcvd 2 *IP: s-0.0.0.0 (GigabitEthernet1/1), d-255.255.255.255, len 333, stop process pak for forus packet *IP: s-192.168.1.1(local), d-255.255.255.255 (GigabitEthernet1/1), len 328, sending broad/multicast Результат в примере показывает, что маршрутизатор получает запросы DHCP от клиента. IP-адрес источника равен 0.0.0.0, поскольку клиент еще не имеет адреса, адрес назначения - 255.255.255.255, потому что сообщение об обнаружении DHCP от клиента отправляется в виде широковещательной передачи. Этот вывод показывает только сводку пакета, а не сообщение DHCP. Тем не менее, здесь видно, что маршрутизатор получил широковещательный пакет с исходными и целевыми IP-адресами и портами UDP, которые являются правильными для DHCP. Другой полезной командой для поиска неполадок DHCP является команда событий debug ip dhcp server. Эта команда сообщает о событиях сервера, таких как назначения адресов и обновления баз. Router(config)#debug ip dhcp server events DHCPD: returned 192.168.1.11 to address pool POOL-1 DHCPD: assigned IP address 192.168.1.12 to client 0011:ab12:cd34 DHCPD: checking for expired leases DHCPD: the lease for address 192.168.1.9 has expired DHCPD: returned 192.168.1.9 to address pool POOL-1
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59