По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В последние несколько лет всё чаще появляется информация об очередных хакерских атаках, направленных на сетевое оборудование различных производителей. И если оборудование класса Enterprise, такое как Cisco, Juniper, Extreme, HP и так далее, обычно обслуживается армией высококвалифицированных специалистов, которые постоянно проводят обновления и закрывают “дыры”, то с оборудованием класса SOHO (MikroTik, Netgear, TP-Link, Lynksys) дела, зачастую, обстоят совсем иначе. А ведь недостаточное внимание, уделяемое сетевому оборудованию, может нанести вред любому бизнесу.
В данной статье мы хотим рассказать о ещё одном крайне действенном способе защиты оборудования MikroTik, которое не потребует о вас больших усилий в настройке и будет само автоматически обновлять свою конфигурацию без вашего вмешательства.
Предыстория
В конце марта 2018 года появилась информация о хакерской активности, которая как раз направлена на SOHO сегмент. В частности – на роутеры MikroTik под управлением RouterOS ниже версии v6.38.5. Суть заключалась в том, что некий хакерский ботнет сканировал множество публичных IP-адресов на предмет открытых портов 80 (www) и 8291 (WinBox), чтобы по ответам оборудования определить, что это RouterOS, а также выяснить его версию. Тогда производитель заявил, что уязвимость реализации протокола www (80), которую можно было бы использовать, была закрыта ещё в марте 2017 версией v6.38.5 и рекомендовал всем обновиться, а также отключить небезопасный сервис www. Нужно отметить, что ботнет только собирал информацию, никаких атак не предпринималось.
Внимание! Если на вашем роутере MikroTik установлена версия прошивки ниже v6.38.5, мы рекомендуем незамедлительно произвести обновление до последней актуальной версии. Как это сделать, вы можете почитать в нашей статье. Также, рекомендуем закрыть сервис www и настроить доступ к WinBox только с доверенных IP-адресов более подробно о том как это сделать читайте здесь.
А совсем недавно на сайте подразделения Cisco, которое занимается кибербезопасностью - Talos, появилась информация о вредоносном программном обеспечении, которое использует ту самую уязвимость. Оно получило название VPNFilter, хоть и не имеет ничего общего с VPN туннелями. Вероятно потому, что после заражения оно создаёт директории /var/run/vpnfilterw и /var/run/vpnfilterm для дальнейшей работы.
По самым поверхностным оценкам, вредонос способен красть пользовательские данные и данные вэб-приложений, устанавливать без ведома пользователя модули, которые взаимодействуют с серверами в сети Tor, а также полностью выводить оборудования из строя посредством изменения критически важных файлов прошивки. До конца вредонос ещё не изучен и актуальные данные по нему всё ещё поступают. Пока известно о том, что уязвимости подвержено всего 3 модели оборудования MikroTik -1016, 1036 и 1072, но защитить другие модели будет не лишним.
Настройка
Итак, перейдём собственно к тому самому универсальному методу защиты, о котором мы упомянули вначале. Данный метод основан на простом блокировании заведомо вредоносных IP-адресов, которые были замечены в подозрительной активности (сканнирование, брутфорс, неудачные попытки доступа к различным сервисам) но только не вручную, а в автоматическом режиме. Существует много открытых ресурсов, которые собирают информацию о таких “чёрных” IP-адресах и генерируют актуальные списки, которые мы можем просто загружать на наш роутер с помощью нехитрого скрипта.
К таким ресурсам относятся:
Blocklist.DE - бесплатный открытый ресурс, созданный специалистами, чьи сервера часто подвергаются различного рода атакам, таким как атаки ssh, почтовых и файловых сервисов, вэб-серверов и другое. IP-адреса атакующих заносятся в список и выкладываются в общий доступ;
dshield.org - генерирует списки из топ-20 подсетей, из которых за последние 3-е суток совершалось наибольшее число атак;
Spamhaus - генерирует списки IP-адресов, замеченных в “спаммерской” активности, а также “угнанных” устройств, с помощью которых также осуществляется вредоносная деятельность;
Итак, чтобы нам заблокировать адреса из этих списков, нужно сначала создать блокирующее правило на нашем роутере. Для этого подключаемся к нашему MikroTik и даём в консоль следующие команды:
ip firewall raw add chain=prerouting src-address-list="sbl dshield" action=drop comment="sbl dshield"
ip firewall raw add chain=prerouting src-address-list="sbl spamhaus" action=drop comment="sbl spamhaus"
ip firewall raw add chain=prerouting src-address-list="sbl blocklist.de" action=drop comment="sbl blocklist.de"
Тем самым, мы создали 3 правила, которые будут блокировать подключения к нашему роутеру из списков каждого ресурса соответственно – dshield, spamhaus и blocklist.de.
Теперь нужно настроить автоматический загрузчик, который будет обращаться на данные ресурсы за актуальными списками и загружать их в конфигурацию роутера. Для этого через WinBox откроем вкладку System → Sheduler → +
И создадим задачу на проверку обновления списков вредоносных ресурсов начиная с полуночи следующего числа каждые 12 часов. Обращение будет происходить посредством простого http запроса к ресурсу www.squidblacklist.org/downloads/drop.malicious.rsc. Для этого в поле On Event напишем простой скрипт:
/tool fetch address=www.squidblacklist.org host=www.squidblacklist.org mode=http src-path=/downloads/drop.malicious.rsc
Мы будем обращаться к ресурсу www.squidblacklist.org, потому что его специалисты любезно скомпоновали списки с dshield, spamhaus и blocklist.de в одном месте и нам не придётся писать скрипт обращения для каждого ресурса.
Должно получиться как то так:
Теперь создадим ещё одну задачу на импорт списка в конфигурацию роутера, спустя минуту после того, как отработает проверка актуальности списков из первой задачи. На этот раз в поле On Event напишем:
:log warning "Disabling system Logging";
import drop.malicious.rsc
/system logging enable 0
Теперь наш роутер будет автоматически запрашивать актуальные списки вредоносных IP-адресов и добавлять их в блок. Вы так же можете использовать другие открытые ресурсы, на которых публикуются списки опасных IP-адресов.
В интернете можно найти множество статей с описанием шаблонов масштабирования баз данных (БД), но, в основном, это разрозненная информация с перечислением методик и практически без объяснений.
Ниже приведено подробное руководство по шаблонам масштабирования БД, пошаговым объяснением принципов их работы и примерами использования.
Практический пример
Предположим, вы создали стартап, который предлагает совместные поездки по дешевой цене. Вы выбрали город для поездок, а первая реклама привлекла не более 10 клиентов.
Вы храните информацию обо всех клиентах, поездках, местах, бронированиях и историях заказов в одной и той же БД и, скорее всего, на одной физической машине. У вас нет навороченного кеширования или конвейера обработки больших данных, ведь ваше приложение только появилось. На данный момент это – идеальный вариант: в базе мало клиентов, и система, вряд ли, бронирует по поездке каждые 5 минут.
Но время идет. В вашей системе регистрируется все больше людей, ведь это самый дешевый сервис на рынке. Да и реклама сделала свое дело. Вы получаете по 10 заказов в минуту. Постепенно это количество увеличивается до 20, а затем и 30 бронирований в минуту.
В этот момент вы замечаете, что система начинает тормозить: время отклика API сильно увеличилось, а некоторые транзакции блокируются или зависают и, в конечном итоге, не проходят. Время ответа приложения также увеличилось, что вызвало недовольство клиентов. Как же решить эту проблему?
Шаблон №1 – оптимизация запросов и реализация пула соединений
Первое решение, которое приходит на ум: кэш слишком часто использует нединамические данные (история бронирования, история платежей, профили пользователей и т.д.). Но прикладным уровнем кеширования вы не сможете решить проблему с временем отклика API, предоставляющим динамические данные (текущее местоположение водителя, ближайшая машина для конкретного клиента, текущая стоимость поездки после выхода на маршрут и т.д.).
Вы приходите к выводу, что база данных слишком нормализована, поэтому вы решаете ее немного «разбавить» и добавляете несколько избыточных столбцов (такие столбцы часто попадают в операторы WHERE или JOIN ON в запросах). Это сокращает количество запросов на соединение, разбивает большие запросы на несколько маленьких и добавляет их результаты на прикладной уровень.
Можно заняться и параллельной оптимизацией – настроить подключения к базам данных. Внешние и клиентские библиотеки БД доступны практически для всех языков программирования. Для кеширования подключений к БД можно воспользоваться библиотеками пула соединений. Либо вы можете настроить размер пула соединений в самой СУБД.
Создание сетевого подключения – вещь весьма затратная, поскольку требует двусторонней коммуникации между клиентом и сервером. Пулы соединений помогают оптимизировать количество подключений. Библиотеки пула соединений реализуют мультиплексирование подключений – несколько потоков приложения могут пользоваться одним и тем же подключением.
Вы замеряете время отклика API и замечаете снижение задержки на 20-50% (или даже больше). На данный момент это хорошая оптимизация.
Затем вы расширили бизнес на еще один город и получили больше клиентов. Постепенно вы доходите до 80-100 бронирований в минуту. Ваша система не в состоянии справиться с таким объемом. Вы вновь замечаете увеличение времени ожидания API, а слой базы данных не справляется с нагрузкой. Но в этот раз оптимизация запросов не дает вам существенного улучшения производительности. Вы проверяете метрики системы и видите, что дисковое пространство заполнено, ЦП занят в 80% времени, а ОЗУ переполняется слишком быстро.
Шаблон № 2 – вертикальное масштабирование или масштабирование вверх
Изучив все системные метрики, вы не находите другого решения, кроме как обновить аппаратное обеспечение системы. Вы увеличиваете размер оперативной памяти в 2 раза, а объем диска – раза в 3. Это называется вертикальным масштабированием. Вы сообщаете группе по обслуживанию инфраструктуры, команде devops или агентам сторонних центров обработки данных (ЦОД) о необходимости обновления вашей машины.
Но как настроить саму машину для вертикального масштабирования?
Вы выделяете машину большего объема. Один из подходов заключается в том, чтобы не переносить данные со старой машины вручную, а настроить новую машину в качестве копии, или реплики (replica), уже существующего устройства, или источника (primary), прописав временную конфигурацию первичной реплики (primary replica). После завершения репликации назначьте новую машину в качестве primary и отключите старую. Поскольку обрабатывать запросы планируется на этой новой машине, все чтение/запись также будет вестись на ней.
Отлично. Вы прокачали систему, и теперь все работает намного быстрее.
Ваш бизнес идет на ура, и вы решаете расшириться еще до 3 городов. Теперь вы ведете деятельность в 5 городах. Трафик увеличился втрое, вы получаете по 300 заказов в минуту. Проблема с производительностью вернулась: размер индекса сильно сказывается на памяти, базу данных необходимо постоянно поддерживать, а сканирование таблицы с индексом замедлилось до невозможности. Вы подсчитали стоимость дальнейшего масштабирования системы, но цена не внушает доверия. Так что же делать?
Шаблон №3 – разделение ответственности на команды и запросы (CQRS):
Вы понимаете, что та самая большая машина не в состоянии обработать все запросы на чтение/запись. Да и чаще всего компаниям нужны транзакционные возможности на запись (write), а не чтение (read). Вас даже устраивает небольшая несогласованность данных или замедление операций read. В принципе, раньше это тоже не казалось вам проблемой. Вы решаете, что неплохо было бы разделить операции чтения и записи на физической машине. Это позволит отдельным машинам выполнять больше операций чтения/записи.
Теперь вы берете целых 2 большие машины и настраиваете их репликами для текущего компьютера. Репликация базы данных решит вопрос с переносом данных с primary машины на реплики. Вы перенаправляете все запросы на чтение (буква Q в CQRS, что означает «запрос» - Query) в реплики – любая реплика может обслуживать любой запрос на чтение. А все запросы на запись остаются на первичной машине. Возможна небольшая задержка в репликации, но в вашем конкретном случае это не критично.
Вариант с настройкой primary-replica вполне подходит для большинства стартапов среднего масштаба, получающих по сотням тысяч запросов ежедневно… но при условии, что компании периодически архивируют старые данные.
Вы вновь расширились на 2 города, и замечаете, что primary-машина не справляется со всеми запросами на запись. Многие такие запросы приходят с опозданием. Более того, задержка между primary и replica начинает сказываться на клиентах и водителях. Например, поездка завершена, клиент успешно ее оплачивает, но водитель не видит платеж, поскольку активность клиента – это запрос на запись, который идет на машину primary, а активность водителя – это запрос на чтение, который приходит на одну из реплик. Вся система настолько замедлилась, что водитель не видит платежа как минимум секунд 30, и это вызывает недовольство как со стороны клиента, так и у самого водителя. Как же поступить сейчас?
Шаблон №4 – репликация с несколькими источниками
Конфигурация primary-replica помогла вам успешно масштабироваться, однако теперь для операций записи не хватает возможностей. Быть может, вы согласитесь слегка пожертвовать быстротой запросов на чтение. А почему бы не перенести запросы на запись тоже в реплики?
В модели с несколькими источниками (multi-primary) все машины работают как источник, и как реплика. Такая структура чем-то напоминает замкнутый круг из машин: A->B->C->D->A. «B» может реплицировать данные из «A», «C» – реплицирует данные из «В», «D» – дублирует данные из «C», а «A» делает тоже самое из «D». Вы можете выполнять операцию чтения и одновременно записывать данные в любой узел; вы можете транслировать запрос во все узлы, а значение вернет один из откликнувшихся узлов. Все узлы имеют одинаковую схему БД, один и тот же набор таблиц, индекс и т.д. Но нужно следить, чтобы в узлах одной таблицы не было конфликта по id , иначе при трансляции запросов несколько узлов вернут разные данные по одному и тому же id.
Вообще считается, что для ID лучше использовать UUID или GUID. Еще один недочет данной системы: из-за трансляции запросов и поиска корректного результата, запросы на чтение могут оказаться неэффективными. Это, своего рода, принцип распределения/сборки в действии.
И вот вы вновь масштабировали бизнес. В этот раз на 5 новых городов. Система не справляется. Теперь вам нужно обрабатывать по 50 запросов в секунду. Вам очень не хватает обработки большого количества параллельных запросов. Но как это сделать?
Шаблон №5 – декомпозиция
Вы знаете, что база данных location получает много трафика на чтение/запись. Вполне возможно, что соотношение записи к чтению составляет 7:3. Это создает большую нагрузку на существующие БД. В таблицах location содержится несколько первичных данных: долгота (longitude), широта (latitude), отметка времени (timestamp), ID водителя (driver id), ID поездки (trip id) и т.д.
Там практически нет информации о поездках или данных пользователя, его платежах и т.д. Возможно, стоит разделить таблицы location на отдельную схему? Как насчет того, чтобы распределить эту БД по отдельным машинам с корректно настроенной конфигурацией primary-replica или multi-primary?
Это называется декомпозицией данных по функциональности. В разных БД можно хранить данные, разделенные по функциональному признаку, а результат (при необходимости) агрегируется на серверном уровне. Такой способ позволит вам масштабировать нужный функционал с большим количеством запросов на чтение/запись. В то же время прикладной или серверный уровень приложения должен будет заняться объединением результатов, что приведет к значительному изменению кода.
Теперь представьте себе, что вы масштабировались до 20 городов в своей стране и планируете открыть филиалы в Австралии. Растущий спрос на ваше приложение требует все более быстрого времени ответа. Ни один из методов выше с этим не поможет. Вам нужно масштабировать систему так, чтобы при расширении в другие страны/регионы не приходилось слишком часто проектировать и менять архитектуру. Как же тогда поступить?
Шаблон №6 – горизонтальное масштабирование
Вы хорошо загуглили эту тему, почитали массу статей о том, как другие компании решали такую проблему, и поняли, что настал момент масштабироваться горизонтально. Вы выделили, скажем, 50 машин – все с одинаковой схемой БД и одинаковыми наборами таблиц. На каждой машине хранится лишь часть данных.
Поскольку во всех БД хранится один и тот же набор таблиц, вы можете спроектировать систему таким образом, чтобы реализовать привязку данных (то есть все связанные данные хранятся на одной машине). В каждой машине может быть своя реплика; реплики используются для восстановления после сбоя. Каждая такая база данных называется «шардом». На физической машине может быть один или несколько шардов – их количество зависит от нужной вам схемы проектирования. Вы должны придумать ключ шардирования, который бы всегда относился к одной и той же машине. Представьте себе много машин с кучей связанных данных в одном наборе таблиц; операции на чтение/запись запрашиваются для одной и той же строки или набора ресурсов на одной и той же машине с БД.
Реализовать шардинг довольно сложно. По крайней мере, так говорят инженеры. Но при обслуживании миллионов или даже миллиардов запросов, рано или поздно вам придется пойти на столь непростой шаг.
Настроив шардинг, вы уверены, что сможете масштабироваться во многие страны. Ваш бизнес разросся настолько, что инвесторы вынуждают вас расширяться на другие континенты. И тут опять возникают проблемы. Все то же время отклика API. Ваш сервис находится в США, и у пользователей из Вьетнама возникают трудности при бронировании. Но почему? И что же делать?
Шаблон №7 – умное сегментирование центров обработки данных
Ваш бизнес развивается в Америке, Южной Азии и нескольких странах Европы. Каждый день вы получаете миллионы заказов, а ваш сервер атакуют миллиарды запросов. Поздравляю! Это пиковый момент в вашей деятельности.
Запросы из приложения поступают с разных континентов и проходят через сотни или даже тысячи серверов в интернете, поэтому время отклика растет. Может, распределить трафик по центрам обработки данных? Вы могли бы настроить ЦОД в Сингапуре, и он бы обрабатывал все запросы из Южной Азии. Затем сделать еще один в Германии – он займется всеми запросами из европейских стран, и оставить ЦОД в Калифорнии для обработки американских запросов.
Кроме того, вам понадобится репликация между ЦОД – на случай, если потребуется восстановление после сбоя. Если центр обработки данных в Калифорнии выполняет репликацию сингапурского ЦОД, то в случае аварии в Калифорнии (стихийные бедствия, отсутствие электричества и т.д.), все запросы из США будут передаваться в Сингапур и наоборот.
Такой метод масштабирования подходит для: обслуживания миллионов клиентов из разных стран, сохранения всех данных и поддержания постоянной доступности системы.
Заключение
В статье приведены общие методы по масштабированию базы данных. Стоит сказать, что у большинства инженеров нет достаточных возможностей для реализации всех шаблонов. Но лучше знать о существовании таких схем, которые в будущем могут помочь вам с проектированием архитектуры и систем.
В данной статье, разберем, как управлять файлами настройки оболочки пользователя. Псевдонимы и функции определяются в файлах с окончанием RC - Bash.bashrc, bashrc, ~/.bashrc.
В зависимости от того в каком файле мы употребим псевдоним или функцию он будет использоваться для конкретного пользователя или для всех пользователей. Посмотрим на конкретном примере пользователя, поэтому будет использоваться файл ~/.bashrc , который находится в домашней директории пользователя и определят настройки конкретного пользователя.
Псевдоним (alias) – текст для вызова команды с ключами. Например: la = ‘ls -A’.
Функция – текст для вызова скрипта, из нескольких команд. Например:
function Hello (){echo “Hello,dear,I am awake for:”; uptime –p;}
Заходим в Ubuntu и попадаем в домашнюю директорию. Следовательно в этой домашней папке есть файл .profile, который является ссылкой на файл bashrc. И в этом файле есть много чего, но в частности есть псевдонимы.
Можно увидеть псевдоним для команды ls, который вызывает команду ls, но с автоматической настройкой цвета. Мы знаем, что у команды ls. Которая выводит список файлов и папок, есть куча различных опций и ключей и в Ubuntu, когда мы вызываем данную команду он по-разному подсвечивает разные файлы в зависимости от того, какие на них установлены биты или это файл скрытый, или это папка. Он все это отображает цветом и шрифтом потому, что установлен параметр --color-auto.
Есть часть параметров закомментированные. Это когда ставится значок # и интерпретатор скрипта понимает, что данная строчка является комментарием.
Если ниже посмотреть можно найти еще несколько алиасов для разных версий операционных систем семейства Linux. Можно видеть, что данные алиасы позволяют запустить одну и ту же команду листинга с различными ключами. Попробуем вызвать эти алиасы.
Команда ll дает вот такой вывод:
Алиас la выводит вот такой вид:
Хотя такой команды в linux нет – это просто записанный алиас вызывает команду ls с ключами.
Для лучшего понимания можно создать свой псевдоним. Есть такая команда uptime. Данная команда выводит сколько работает данная система, показывает сколько пользователей в системе.
Ключи данной команды может каждый посмотреть самостоятельно - man uptime. В рамках задачи по созданию алиаса нам интересен ключ pretty. Хорошо, можно создать алиас, который будет запускать команду uptime –p, т.е непосредственно саму команду с ключом –p. Алиас будет называться forhowlong, такой команды точно в установке по умолчанию операционной системы Ubuntu нет.
Создадим такую команду. Для этого необходимо отредактировать файл nano .bashrc. Спускаемся в конец файла и добавляем комментарий #some aliases for uptime. Строчка закомментирована, она не будет считываться интерпретатором, создание комментариев хороший тон для написания скриптов и модификации конфигурационных файлов. А далее добавляем строчку alias forhowlong=’uptime -p’. т.е название алиаса, его имя и через знак равно, то что он будет делать. Сохраняем и выходим. Если мы попробуем использовать алиас, то мы получим, что такой команды не существует. Это логичное поведение потому, что bashrc применяется при инициализации оболочки. Выйдем из терминала и зайдем. Попробуем еще раз. Все работает!
Или можно было еще раз командой bash перезапустить оболочку. Можно так же перезаписать действующую команду, чтобы она сразу запускалась, как это необходимо. Например, alias uptime=’uptime -p’ мы добавляем в .bashrc и перезапускаем оболочку командой bash. Теперь команда uptime будет сразу запускаться с ключем –p. Для чего это может понадобится? Например, если вы перешли с другого дистрибутива и там вывод команды делался такой же, как в данном дистрибутиве с ключем. Или вы хотите пользователю облегчить работу и пропишите псевдонимы заранее.
Немного о функциях. Например, мы хотим придумать команду FTW. Естественно такой команды нету и при попытке ввода нам выдаст ошибку. Следовательно, ее необходимо написать и это будет функция. Функция от алиаса отличается тем, что можно последовательность команд написать некий скрипт. И этот скрипт будет отрабатывать как функция. Для этого нам понадобится тот же файл .bashrc. Напоминаю, что мы работаем с файлом из профиля и, следовательно, все эти функции и алиасы будут работать только для данного пользователя. Если мы хотим, чтобы действие распространялось на всех пользователей, но нам нужен одноименный глобальный файл.
Заходим в файл nano .bashrc профиле. И так же внизу добавляем комментарий и новую функцию.
function FTW() {
echo “you name is:”;
whoami;
echo “today is:”;
date;
echo “you are there:”;
pwd; }
Функция, далее имя функции, затем скобки, пустые чтобы показать, что она работает без аргумента, а вообще можем применить аргумент – например имя пользователя тем самым привязать к пользователю. Но в данном примере – это и не требуется, мы сейчас рассматриваем функцию, не зависящую от каких-либо аргументов и просто выполняющую последовательность команд. Ну из команд думаю понятно, что будет выполнять данная функция.