По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В последние несколько лет всё чаще появляется информация об очередных хакерских атаках, направленных на сетевое оборудование различных производителей. И если оборудование класса 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-адресов.
Существует множество различных решений для управления Asterisk, основой которых, является FreePBX. К ним относятся - Elastix, PBX in a Flash (PIAF), Trixbox, AsteriskNOW и FreePBX Distro. Однако, с момента первого релиза FreePBX многое изменилось и большинство перечисленных проектов по-просту перестали существовать. Trixbox перестал поддерживать открытое ПО и переориентировался на коммерческую редакцию Trixbox Pro. Elastix и PIAF вообще дружно сменили свой движок с Asterisk на 3CX и для этих продуктов обновлений также больше нет. Кроме того, есть компании, которые до сих пор используют старые не поддерживаемые версии FreePBX и ежедневно испытывают трудности с их работой, а также те, кто установил FreePBX вручную на не поддерживаемые операционные системы.
Единственный продукт, который до сих пор обновляется и поддерживается разработчиком - это сам проект FreePBX и FreePBX Distro. Принимая это во внимание, разработчики FreePBX создали решение, которое позволяет сделать миграцию любой системы на базе FreePBX, (начиная с версии 2.9 до и включая версию 14) на свеженькую FreePBX Distro на базе ОС SNG 7, со всеми настройками и конфигурацией!
Итак, можно мигрировать с:
Elastix;
PBX in A Flash;
AsteriskNOW;
вручную установленного FreePBX (в том числе установленного на не поддерживаемой ОС);
FreePBX Distro
При этом система, с которой производится миграция не требует остановки эксплуатации или перезагрузки, так как инструмент всего лишь считывает конфигурацию с системы "донора" на свежую систему FreePBX Distro.
Как это работает:
Вам нужно будет установить свежую версию свежую версию FreePBX Distro , на которую будет происходить миграция и активировать её;
Запустить на новом сервере с FreePBX Distro скрипт конвертации командой: curl -s https://convert.freepbx.org | bash
Этой командой сервер запросит место (слот) в очереди на конвертацию. Когда слот будет успешно занят сгенерируется ключ, вида 2beb181b-14ed-4f56-a86b-f6e564ba6c43;
После этого, нужно запустить такую же команду на сервере - доноре, с которого вы хотите мигрировать и ввести полученный ключ;
Конвертер извлечёт необходимые данные с донора и загрузит их на новый сервер. Этот процесс не окажет никого влияния на донора, не внесёт на нем никаких изменений и не потребует выключения;
Скрипт также будет пробовать стянуть с донора всякие кастомные данные, такие как пользовательские голосовые файлы и данные провиженинга;
Все транки на новом сервере будут выключены, чтобы избежать конфликта с зарегистрированными линиями к провайдеру на старом сервере.
О том, как установить FreePBX читайте в нашей статье
Какие данные будут перенесены на новый сервер:
Внутренние номера (Extensions);
Маршруты (Inbound/Outbound Routes);
Линии к провайдеру (Trunks);
Музыка на ожидании (MoH);
Голосовые меню (IVR);
Группы вызова (Ring Groups);
Очереди (Queues);
Любые другие настройки, являющиеся стандартной частью FreePBX;
Звуковые файлы, включая: загруженную пользователем музыку на ожидании (MoH), записи голосовой почты и приветствия для голосовой почты, а также системные записи (System Recordings)
Какие данные не будут перенесены на новый сервер:
История звонков, то есть Call Data Report (CDR) и таблица Call Event Log (CEL);
Вы можете самостоятельно перенести эти данные на новый сервер, экспортируя их с помощью 'mysqldump' или аналогичной утилиты. Эти данные могут быть очень тяжёлыми, поэтому пользователь сам должен позаботиться об их переносе.
Настройки факса;
Эта часть претерпела огромные изменения с момента первого релиза FreePBX, поэтому придется самостоятельно перенастроить почты пользователей, которым нужен функционал факса.
Кастомные изменения конфигурационных файлов;
То есть всё, что было изменено в файлах вида *_custom.conf, например /etc/asterisk/extensions_custom.conf. Если у вас есть такие настройки, то переносить их на новый сервер нужно будет вручную.
Настройки не FreePBXовых модулей;
Ну например Elastix Call Center Module, Queue Metrics и остальные модули, которые не являются стандартными для FreePBX.
В общем и целом, звучит неплохо, правда? Мы можем безболезненно перенести большинство необходимых данных с неподдерживаемой системы и продолжить работу на новой, получая все актуальные обновления. Процесс миграции не представляется чем-то сверх сложным, так что давайте попробуем?
Процесс миграции
Итак, первое с чего нужно начать - это подготовка нового сервера с FreePBX Distro. Важно устанавливать именно 64-битную версию, поскольку 32-битная больше не поддерживается.
О том как установить FreePBX Distro подробно читайте в нашей статье.
Как только FreePBX Distro будет установлен, его необходимо активировать. Активация требуется для того чтобы сгенерировать криптографический ключ для защиты ваших данных для передачи на сервер конвертации https://convert.freepbx.org.
Данные передаются в зашифрованном виде, чтобы исключить возможность их утечки в случае атаки типа Man-in-the-Middle.
Затем необходимо настроить NAT. FreePBX Distro имеет свой встроенный модуль Firewall, который автоматически настраивает параметры NAT и Firewall через специальный помощник при первом запуске FreePBX.
О том как настраивать Firewall читайте в нашей статье.
После того как сервер с чистым FreePBX Distro настроен, необходимо зарезервировать слот для конвертации.
Это делается с помощью специального скрипта: curl -s https://convert.freepbx.org | bash. Когда Вам предложат ввести reservation ID, просто нажмите 'Enter'.
По окончанию процесса резервации слота, будет сгенерирован уникальный код конвертации вида: 2beb181b-14ed-4f56-a86b-f6e564ba6c43. Его потом нужно будет ввести на доноре.
После этого, новый сервер будет ожидать ответа от донора. Не останавливайте скрипт, нужно чтобы на экране была надпись Waiting for Donor….
Теперь нужно запустить такую же команду на сервере - доноре, с которого вы хотите мигрировать и ввести полученный ключ;
Возвращаемся на сервер-донор (Elastix, PIAF и так) с которого мы хотим мигрировать и запускаем тот же самый скрипт: curl -s https://convert.freepbx.org | bash
Когда вас попросят ввести ID, введите то что было сгенерировано при запуске скрипта на новом FreePBX Distro.
Это запускает процедуру экспорта всех данных и настроек с сервера донора и создание сжатого, криптографически защищённого архива с этими данными для отправки на новый сервер.
В зависимости от того, насколько давно был развёрнут старый сервер, существует возможность неудачной обработки команды скрипта, поскольку сервер может не поддерживать обработку TLS сертификатов. Если после запуска скрипта ничего не происходит, попробуйте запустить команду с отключением верификации TLS сертификата: curl --insecure https://convert.freepbx.org | bash
Как только процесс завершится, новый сервер будет иметь все настройки и данные, которые были на сервере доноре. Вы получаете полностью рабочий сервер со свежей версией FreePBX Distro, которая будет получать актуальные обновления софта и безопасности со всеми настройками, которые были на старом сервере!
Компьютерные сети это то, что можно встретить сейчас в любом доме, в любой организации. Более того, это одна из основных составляющих успешной деятельности современного предприятия. И чем крупнее организация, тем шире в ней компьютерная сеть. В этом случае для удобства организации работы имеет смысл разделить единую сеть на подсети. В этой статье мы рассмотрим, как правильно и без ошибок наладить работу с подсетями в рамках одной локальной сети.
p>
Прежде всего, стоит понимать, а нужно ли вообще разбивать сеть? Если фирма небольшая, на 3-4 сотрудника в одном офисе, то в такой разбивке нет необходимости. Однако, если сотрудники компаний занимают несколько кабинетов, или же отделы находятся в различных зданиях - в этом случае без сегментации на подсети не обойтись.
Вообще, интернет-провайдер рассматривает любую организацию как одну сеть, в идеале, имеющую один IP-адрес. На деле так получается далеко не всегда. Если организация крупная, то в ней по факту может быть несколько локальных подсетей, объединенных в одну сеть, которую и будет "видеть" провайдер. Эти подсети могут быть территориально удалены друг от друга, поэтому нужно правильно наладить их соединение, чтобы избежать ошибок в обмене данными.
Конечно, самым очевидным решением будет присвоение каждому устройству своего IP-адреса. Но если в сети есть несколько маршрутизаторов, такой вариант будет неприемлемым или исключительно сложным в реализации.
Что же делать в случае, если сеть организована через связанные между собой маршрутизаторы? В этом случае нужно присвоить IP-подсетям разные адреса.
Задачка: из пункта А в пункт Б выехал поезд…Упс, нет, не та задача. Пусть в организации есть несколько отделов. Чтобы понять, какое количество IP-адресов выдать на подсеть, необходимо знать потребности каждого отдела. Иными словами, знать максимальное количество компьютеров и сетевых устройств, которое планируется ставить в каждом отделе. Для каждого компьютера (и любого другого сетевого девайса) в рамках подсети будет установлен свой индивидуальный IP-адрес. Также нужны IP-адреса для виртуальных серверов, если таковые используются в организации. Не лишним будет создать запас IP-адресов на случай расширения отдела и установки новых рабочих станций.
Есть два варианта разделения сети. Это вариант с подсетями равного размера и вариант с подсетями разного размера. Рассмотрим первый случай:
Если вы на хотите заморачиваться с самостоятельным расчетом подсетей, то мы сделали все за вас 😌. Воспользуйтесь нашим готовым калькулятором подсетей
Вариант 1: Разделение сети на подсети одинакового размера:
Вообще, в сети, устроенной по протоколу IPv4 можно, как правило размещают 254 устройства (2^8-2 – два в восьмой степени минус 2. Минус два, так как один адрес широковещательный а другой сетевой, так называемый нулевой). Из адресного пространства узла (последние 8 бит) для адресации подсетей потребуется занять несколько бит. Если занять 1 бит получится 2 подсети, 2 бита 4 подсети, 3 бита 8 подсетей и так далее. Маска подсети будет увеличиваться на +1 за каждый занятый для разбивки бит.
Таким образом, определив нужное количество подсетей, мы можем начинать разбивку. Стоит помнить, что чем больше подсетей, тем меньше в них будет адресов. Например, если подсетей нужно сделать 7, то для адресации в адресном пространстве узла мы возьмем 3 бита, и еще 5 у нас останется для присвоения IP-адресов. Таким образом, в каждой подсети можно будет установить (2^5-2 – два в пятой степени минус два) = 30 устройств. Общая вместимость сети в данном случае составит (30*8) =240 устройств.
Диапазоны устройств в подсетях найти также несложно. Они будут распределены от 0 до 254, при этом адреса подсети уже будут зарезервированы (0, 32, 64, 96, 128, 160, 192, 224)
Пример:
1-я подсеть: 1.2.3.0 /27 диапазон 1.2.3.1 /27 1.2.3.30 /27
2-я подсеть: 1.2.3.32 /27 диапазон 1.2.3.33 /27 1.2.3.62 /27
3-я подсеть: 1.2.3.64 /27 диапазон 1.2.3.65 /27 1.2.3.94 /27
4-я подсеть: 1.2.3.96 /27 диапазон 1.2.3.97 /27 1.2.3.126 /27
5-я подсеть: 1.2.3.128 /27 диапазон 1.2.3.129 /27 1.2.3.158 /27
6-я подсеть: 1.2.3.160 /27 диапазон 1.2.3.161 /27 1.2.3.190 /27
7-я подсеть: 1.2.3.192 /27 диапазон 1.2.3.193 /27 1.2.3.222 /27
8-я подсеть: 1.2.3.224 /27 диапазон 1.2.3.225 /27 1.2.3.254 /27
Таким образом, наши IP - пакетики могут легко пройти через маршрутизаторы и найти нужный путь. Но в данном варианте есть и минус - множество IP-адресов в подсети остаются неиспользуемыми. Теперь рассмотрим второй вариант:
Вариант 2. Разделение сети на подсети различного размера:
В данном случае необходимо будет рекурсивно разделить сеть пополам. Посмотрите наглядную картинку:
И так далее. А затем для каждой подсети подобрать адрес с диапазоном нужного размера. Таким образом если в одной подсети 50 устройств, она будет в диапазоне 3 итерации деления, если же 5, то в 5 итерации.
Используя этот метод, мы экономим IP-адреса и можем разделять сеть на подсети разных размеров.
Подытоживая, можно отметить, что такое деление отлично подойдет в случае IPv6, но с учетом того, что там используется гораздо более объемное адресное пространство, там проблемы с экономией IP-адресов не стоит. Принцип деления сети на подсети будет тем же самым с поправкой на 128-битный адрес нового протокола.