По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Domain Name System DNS - это сетевая система, содержащая информацию о каждом web-сайте в Интернете. Каждый сайт имеет свой уникальный IP-адрес, имеющий вид 111.222.111.222, а также доменное имя, например merionet.ru. Человеку гораздо проще запомнить доменное имя сайта, нежели набор цифр входящих в IP-адрес. Для этих целей и была разработана система DNS. Подобно записной книжке, в ней хранится таблица соответствия доменного имени сайта и его IP-адреса.
В DNS используется иерархическая древовидная структура серверов и имен. Самый верхний уровень это “root”, представляющий из себя точку (.) и следующий за ним домен верхнего уровня (Top Level Domain). Эти домены бывают двух типов:
Generic Top Level Domain (gTLD)
Например: .com (коммерческие web-сайты), .net(web-сайты сетевых структур), .org (вэб- сайты организаций), .edu (web-сайты образовательных структур)
Country Code Top Level Domain (ccTLD)
Например: .ru (Россия), .us (США), .uk (Великобритания), .in (Индия)
Данные, которые сообщают веб-серверу, как ответить на ваш запрос называются DNS записи или Zone Files. Каждая запись содержит информацию о конкретном объекте. DNS-сервер использует записи, чтобы отвечать на запросы хостов из определенной доменной зоны. Например, запись address mapping (A) отвечает за связку host name и IP-адреса, а запись reverse-lookup pointer (PTR), за связку IP-адреса и host name. Стоит отметить, что в терминологии DNS очень много различных записей, мы же приведем основные:
A Record - Содержит информацию об определенном доменном имени и соответствующем IP-адресе. DNS-сервер обращается к данной записи, чтобы ответить на запрос, содержащий доменное имя. Ответом будет IP-адрес, указанный в записи.
PTR Record - Связывает IP-адрес с определенным доменным именем.
NS (Name Server) Record - Связывает доменное имя со списком DNS-серверов, отвечающих за данный домен.
MX (Mail Exchange) Record - Связывает доменное имя со списком серверов почтового обмена для данного домена. Например, при отправке письма на адрес example@merionet.ru, данное письмо будет перенаправлено на сервер, указанный в MX записи.
Типы запросов DNS
В терминологии DNS существует три типа запросов:
Recursive – Такие запросы можно представить так: “Какой IP-адрес у a.merionet.ru?”
При получении recursive запроса, DNS-сервер выполняет следующие действия:
Хост отправляет локальному DNS-серверу запрос “Какой IP-адрес у a.merionet.ru?”
DNS-сервер проверяет наличие записи a.merionet.ru в локальных таблицах и не находит ее.
DNS-сервер отправляет запрос IP-адреса a.merionet.ru к root-серверу
Root-сервер отвечает, что надо обратиться к TLD серверу, отвечающий за домен .ru
DNS-сервер, получив ответ от root-сервера, отправляет recursive запрос одному из ccTLD-серверов, отвечающих за домен .ru
TLD-сервер отвечает, что нужно обратиться к серверу, отвечающему за домен merionet.ru
DNS-сервер отправляет запрос IP-адреса a.merionet.ru к серверу, отвечающему за домен merionet.ru
Сервер обращается к A Record и находит там соответствующий IP-адрес для a.merionet.ru
Таким образом, хост получает запрашиваемую страницу по адресу a.merionet.ru
Второй тип DNS-запросов – это Iterative запросы. Данные запросы передаются между DNS-серверами, когда один из них не имеет соответствующих записей. Таким образом, инициатор запроса будет контактировать с сервером, который имеет нужную запись
Последний тип запросов – Inverse. Собственно из названия данного запроса понятно, что они работают по инверсному принципу, то есть при известном IP-адресе запрашивается информация о доменном имени.
Последние два года выдались для роутеров MikroTik нелегкими. Они подвергались сканированию, уводились в ботнеты, майнили крипту без ведома хозяев и почти всё это стало возможным благодаря всего одной уязвимости в сервисе www, а точнее – незащищённому открытому 80 порту. (Используется для настройки роутера через web интерфейс)
Мы беспокоимся о своих читателях, поэтому хотим ещё раз предупредить всех обладателей роутеров MikroTik о данной проблеме.
Впервые, информация о том, что в роутерах MikroTik присутствует критическая уязвимость, позволяющая злоумышленнику исполнить произвольный код в случае успешной эксплуатации, появилась на весьма специфичном ресурсе – WikiLeaks, в рамках серии публикаций об средствах, которыми пользуется ЦРУ для взлома электронных девайсов, под названием Vault 7. Эксплоит получил название Chimay Red, точно также называется одно бельгийское пиво, вкусное или нет - не знаем.
Итак, давайте знакомиться – Chimay Red, cheers, друзья!
Вот лишь некоторый список того, на что способен данный эксплойт:
Удаленно выполнить код, в командной строке роутера. Например, перезагрузить устройство без Вашего ведома;
Извлекать пользовательские логины и пароли;
На моделях роутеров с жидкокристаллическим экраном, можно вывести на него какое-нибудь сообщение;
Скрыть все логи устройства;
И даже - заставить роутер играть какую-нибудь монофоническую мелодию. Например, из Super Mario :)
Согласитесь, не очень приятно знать, что кто-то может заставить Ваш роутер "петь" Super Mario.
В общем, для тех, кто не хочет читать дальше сообщаем - MikroTik выпустил прошивки чтобы закрыть эту уязвимость, поэтому если версия RouterOS у Вас ниже 6.37.5 или 6.38.5, то срочно обновитесь!
А мы продолжаем. Благодаря уязвимости Chimay Red, позже стало возможным создание вредоносных инструментов для проведения ряда атак.
VPNfilter
Вредонос, который обнаружило подразделение кибербезопасности Cisco Talos. Помимо роутеров MikroTik, данный вредонос бил и по другим устройствам класса SOHO. Сначала было непонятно, как вредоносные файлы загружались на роутеры MikroTik, однако позже выяснилось, что всему виной может быть уязвимость в сервисе www.
Несмотря на то, что вредонос получил название VPNfilter, ничего общего с технологией VPN он не имеет.
Что умеет VPNfilter:
Подслушивать ваш трафик;
Внедрять вредоносный контент в трафик, проходящий через роутер, и, с помощью этого, устанавливать вредоносное ПО на подключенные устройства;
Тупо выводить роутер из строя;
Извлекать пользовательские пароли и другую чувствительную информацию;
Устанавливать соединения в анонимные сети TOR к командному серверу и делать роутер частью ботнет сети.
Как понять, что Ваше устройство инфицировано:
Ваш роутер устанавливает неидентифицированные соединения по управляющим портам ко внешним неизвестным ресурсам;
Проверить можно на вкладке IP → Firewall → Connections. Там не должно быть соединений от вашего роутера к публичным IP адресам по портам удаленного администрирования, о которых Вы не знаете.
Допустим, внешний адрес Вашего роутера – 91.191.191.91
На Вашем роутере появились следующие директории:
var/run/vpnfilterm
/var/run/vpnfilterw
var/run/torr
var/run/tord
Ваш роутер самопроизвольно отключается, перезагружается, появляются изменения конфигурации, которые Вы не вносили
Как защитить устройство от вредоноса или удалить его, если оно уже заражено:
Итак, если Вы давно не обновлялись и используете старую версию RouterOS, а также у вас открыт доступ по 80 порту из Интернета, то ваше устройство может быть заражено.
Перезагрузить устройство. Однако, данная мера может не помочь, т.к вредонос способен "пережить" перезагрузку. Так что надёжнее будет сделать сброс к заводским настройкам. Предварительно, сохраните конфигурацию устройства
Обновить версию RouterOS на выпущенную после марта 2017 года. Исправления появились в 6.38.5, 6.37.5. Рекомендуется установить последнюю актуальную версию и патчи для Вашего устройства
Сменить пароль, особенно на встроенных профилях (admin). По возможности, отключите устройство от публичной сети, выполняя данный шаг
Настроить Firewall для сервиса www (порт 80). Лучше всего будет запретить использование данного сервиса и обращения к порту 80 из Интернета. Однако, если это невозможно, то необходимо разрешить доступ только с доверенных адресов.
Данный вредонос поразил такое большое количество устройств и вызвал такой большой резонанс, что компания Symantec даже разработала специальный ресурс, позволяющий определить, заражён ли Ваш роутер VPN filter'ом. Инструмент может проверить Ваш роутер на наличие плагина ssler, который вредонос устанавливает на определенной стадии заражения:
Symantec
Просто перейдите по ссылке компьютера, находящегося за роутером, который Вы хотите проверить и нажмите Run VPNfilter Check.
Даже если проверка не выявит признаков заражения ssler, роутер всё равно может быть заражён другими модулями VPNfilter.
Ботнет
Немного иначе обстоят дела с другим "вредоносом", а точнее целым ботнетом - Hajime. Этот ботнет уже попадал в поле зрения исследователей, когда захватывал в свои ряды умные устройства (IoT), однако, в марте 2018 года, ботнет резко переключился на роутеры MikroTik. Это подтверждается тем, что ботнет начал сканировать рандомные подсети по 80 (www) и 8291 (WinBox) порту. Сканирование порта 8291, говорит от том, что оно направлено именно на оборудование MikroTik.
После успешной идентификации устройства, ботнет применял ряд эксплоитов, чтобы ввести его в свои ряды.
Дальше дело пока не заходило, ботнет Hajime пока не был замечен ни в массированных DDoS атаках, ни даже в рассылке спама. Есть даже предположение, что автор Hajime - это добрый хакер (white hat), который укрепляет безопасность систем. Исследователи Symantec нашли в заражённых устройствах зашифрованное сообщение именно такого содержания.
Так или иначе, ещё раз рекомендуем установить последние обновления для Ваших роутеров и регулярно следить, чтобы прошивка была актуальной.
Если Вы подозреваете, что Ваше устройство заражено или просто хотите это проверить, то предлагаем воспользоваться следующим способом.
В интернете есть множество открытых ресурсов, которые следят за вредоносной активностью в сети и ведут соответствующие записи.
Такие ресурсы как:
VirusTotal
AbusedIP
Spamhaus
IBM-X Threat
Cisco Talos
Помогут Вам определить, замечался ли Ваш публичный IP адрес во вредоносной активности.
Просто введите его в строку поиска на соответствующем ресурсе и посмотрите результат.
Данный способ актуален только если у вас статический IP адрес или, если он динамический, то Вы точно знаете когда он менялся.
Друг, начнем с цитаты:
Redis – это высокопроизводительная БД с открытым исходным кодом (лицензия BSD), которая хранит данные в памяти, доступ к которым осуществляется по ключу доступа. Так же Редис это кэш и брокер сообщений.
Надо признаться, определение не дает точного понимания, что же такое Redis. Если это так круто, то зачем вообще нужны другие БД? На самом деле, Redis правильнее всего использовать в определенных кейсах, само собой, зная про подводные камни – именно об этом и поговорим.
Про установку Redis в CentOS 8 мы рассказываем в этой статье.
Redis как база данных
Говорим про случай, когда Redis выступает в роли базы данных:
Пару слов про ограничения такой модели:
Размер БД ограничен доступной памятью
Шардинг (техника масштабирования) ведет к увеличению задержки
Это NoSQL - никакого языка SQL
LUA скриптинг в качестве альтернативы
Это нереляционная СУБД!
Нет сегментации на пользователей или группы пользователей. Отсутствует контроль доступа
Доступ по общему паролю. Что скажут ваши безопасники?
Теперь про преимущества модели:
Скорость
Хранение данных в памяти делает быстрее работу с ними
Скрипты на LUA
Выполнение прямо в памяти, опять же, ускоряет работу
Удобные форматы запросов/данных
Geospatial – геоданные (высота, ширина, долгота и так далее)
Hyperloglog – статистическе алгоритмы
Hash – если коротко, то хэш в Redis делают между строковыми полями и их значениями
Алгоритмы устаревания данных
Примеры использования
Представь, у нас есть приложение, где пользователям необходимо авторизоваться, чтобы выполнять какие – либо действия внутри приложения. Каждый раз, когда мы обновляем авторизационные данные клиента, мы хотим их получать для последующего контроля.
Мы могли бы отправлять лист авторизационных параметров (с некими номерами авторизаций, сроком действия с соответствующими подписями), чтобы каждое действие внутри приложения, сопровождалось авторизацонной транзакцией из листа, который мы прислали клиенту. С точки зрения безопасности, в этом подходе нет ничего плохого, если мы храним на своей стороне данные в безопасности и используем Javascript Object Signing and Encryption (JOSE), например. Но проблема появится в том случае, когда наш пользователь имеет более одной авторизации внутри приложения – такие схемы плохо поддаются масштабированию.
А что если вместо отправки листа авторизационных параметров, мы сохраним его у себя, а пользователю отправим некий токен, который они должны отправлять для авторизации? Далее, по этому токену, мы легко сможем найти авторизации юзера. Это делает систему гораздо масштабируемой. Redis, такой Redis.
Итого, для указанной выше схемы, мы хотим:
Скорость
Мы не хотим, чтобы пользователь долго ожидал авторизации
Масштабирумость системы
Сопоставление ключа (токена) с авторизациями юзера
А вот, что на эти вызовы может ответить Redis:
Redis хранит данные в памяти – он быстрый.
Redis можно кластеризовать через компонент Sentinel. Масштабируемость? Пожалуйста.
В Redis куча вариантов хранения списков. Самый простой будет являться набором данных.
В качестве бонуса от Redis, вы получите механизм экспайринга токенов (устаревания). Все будет работать.
Redis как кэш!
Redis почти заменил memcached в современных приложениях. Его фичи делают супер – удобным кэширование данных.
Ограничения:
Значения не могут превышать 512 МБ
Отсутствует искусственный интеллект, который будет очищать ваше хранилище данных
Профит:
Совместное использование кэша разными сервисами по сети
Удобные фичи, такие как LUA скриптинг, который упрощает работы с кэшом
Временные ограничения для данных
Еще один кейс
Предположим, перед нами такая задача: приложение, отображает пользователям данные с определенными значениями, которые можно сортировать по множеству признаков. Все наши данные хранятся в БД (например, MySQL) и показывать отсортированные данные нужно часто. Дергать БД каждый раз весьма тяжело и ресурсозатратно, а значит, нам нужно кэшировать данные в отсортированном порядке.
Окей, кейс понятен. Рэдис, что скажешь на такие требования?
Кэш должен хранить сортированные наборы данных
Нам нужно вытаскивать наборы данных внутри наборов данных (для пагинации, например, то есть для переключения между страницами)
Это должно быть быстрее, чем пересчет данных с нуля
Что скажет Redis:
Хранить наборы данных - легко
Может вытаскивать сабсеты из наборов - легко
Конечно быстрее. Ведь данные хранятся в памяти
Redis как брокер сообщений
Редис может выступать в качестве брокера сообщений. Схема обычная и весьма базовая - publish–subscribe (pub/sub), или как можно перевести на русский язык «Издатель - подписчик».
Как и раньше, давайте обсудим плюсы и минусы, хотя их тут и не так много. Минусы:
Только тривиальная модель pub/sub
Отсутствие очередей сообщений
Ну а плюсы, как обычно для Редиса – скорость и стабильность.
Кейс напоследок
Простой пример – коллаборация сотрудников одной компании. Предположим, у них есть приложение, где они работают над общими задачами. Каждый пользователь делает свой набор действий, о котором другие пользователи должны знать. А так же, юзеры могут иметь разные экземпляры приложений – десктоп, мобильный или что то еще.
Требования по этой задаче:
Низкая задержка
Мы не хотим иметь трудности в процессе совместной работы сотрудников
Стабильная работа и непрерывность
Масштабирование
Кампания растет и развивается
Редис, твой выход!
Низкая задержка – да, говорили об этом ранее
Стабильность – минимальное количество точек отказа в Redis
Стабильная работа и непрерывность
Масштабирование – сделаем кластер, нет проблем.
Выводы
Redis - крутая штука, которая позволяет объединять сервисы и следовать 12 принципам приложений. Для приложений, в которых нагрузка ориентирована на быстрое изменение наборов данных и высокая безопасность данных не имеет завышенных требований – Redis прекрасный выбор.
Если данные нуждаются в усиленной защите, Редис подойдет в меньшей степени, лучше посмотрите в сторону MongoDB или Elasticsearch.