По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет, друг! В марте 2017 года на сайте разработчика FreePBX Distro появился новый дистрибутив, который включает в себя FreePBX 14 версии, Linux 7.3 и само ядро обработки телефонных вызовов – Asterisk (11, 13 и 14 версии). Отметим, что на момент написания статьи релиз проходит полномасштабное тестирование и доступен в формате «релиз - кандидата», или просто RC (Release Candidate). В статье рассмотрим процесс установки дистрибутива RC 1 SNG7-FPBX-64bit-1703-1 и проведем беглый обзор новых «фишек».
Установка
Установку мы будем производить на виртуальной машине в среде виртуализации Hyper-V. После загрузки .iso дистрибутива с сайта разработчика, сравниваем его MD5 - сумму и подключаем его к виртуальному приводу и включаем виртуальную машину:
Выбираем рекомендуемую опцию инсталляции и нажимаем Enter:
Выбираем опцию вывод детализации информации об установке через VGA и нажимаем Enter:
Оставляем селектор на стандартной установке и нажимаем Enter:
Начинается процесс установки, который занимает примерно 10-20 минут. По окончанию установки мы увидим соответствующее сообщение. Нажимаем Reboot:
Готово. Переходим к изучению нового интерфейса.
Новый интерфейс FreePBX 14
Из нововведений сразу в глаза бросается виджет Live Network Usage, который показывает загрузку виду Tx/Rx (передача/прием) на сетевом интерфейсе:
Пробежимся по вкладке Admin. Мы нашли дополнительный раздел Updates, в котором теперь можно планировать автоматическое обновление системы и модулей:
Во вкладке Applications появился модуль Calendar, который позволяет производить интеграцию с календарями (Outlook, iCal, CalDAV и обычный локальный календарь):
Важнейшей особенностью нового интерфейса является UCP (User Control Panel) 14 версии, в котором полностью переделана графическая компонента, визуализация информации, добавлена гибкая система настройки «дашбордов» и настройки виджетов:
Мы продолжим следить за новым релизом и держать вас в курсе :)
Зачастую взлом инфраструктуры происходит не с помощью сверхсекретных разработок или специально созданных "организмов" ("вирусов", "червей", "пауков", "дятлов" - нужное подчеркнуть), а из-за стандартных ошибок в настройках и дизайне. Ликвидировать эти недочёты - проще простого, но с такой же простотой они и создают огромные возможности для хакерских атак. Как отмечают специалисты по безопасности, появления подобных упущений в системе встречается настолько часто, что создаётся впечатление, что для таких ошибок существуют спецкурсы. Поэтому задачей данной статьи не является рассказ о самых современных методах защиты - мы просто постараемся заставить читателей задаться вопросом: "А всё ли хорошо в нашей системе безопасности и всё ли мы предусмотрели для того, чтобы конкуренты не смогли воспользоваться нашими данными и разработками и как устранить неполадки в нашей системе?".
Локальная учётная запись? Забудьте об этом.
Уж сколько раз твердили миру... Слова дедушки Крылова как нельзя лучше характеризуют данную ситуацию - она постоянно возникает и о ней всё время напоминают. Не надо (совсем нельзя) создавать доменной групповой политикой локальные учетные записи на хостах в вашем домене. Говоря военными терминами - уровень опасности красный.
Причина самая банальная - данные по записи (в том числе и пароль) хранится в открытом доступе и по умолчанию доступен всем участникам группы. Если кому интересно, то он находится в файле groups.xml, в ресурсе sysvol контроллера домена, но при этом ключ один на всех. Таким образом, любой желающий может скачать файл и путём нехитрых телодвижений стать администратором группы. Думаю о последствиях говорить не надо.
Чтобы не получилось подобных конфузов надо просто добавлять только доменные учетные записи в локальные группы на хостах.
Права юзеров - на необходимый минимум.
Каждая учётная запись имеет свои права для работы в системе и создана для работы конкретной направленности. Поэтому необходимо минимизировать права каждого пользователя системы, так чтобы они подходили под зону его ответственности. Таким образом, снизится риск утраты контроля над записью, и каждый будет знать только свою, необходимую ему информацию.
UAC - на максимум!
Поставьте на максимум User Account Control (UAC). Его, конечно, можно обойти, но он создаст лишнюю нагрузку для атаки, а время в таких вопросах - играет Вам на руку.
Никакого доступа к учетным данным и хэшам
MIMIKATZ - это утилита, которая очищает память процесса, ответственного за проверку подлинности Windows (LSASS). Затем она и выдает пароли в виде открытого текста и хеш-коды NTLM, которые злоумышленник может использовать для перемещения по сети. Чтобы защититься от неё, надо соблюдать несколько простых правил:
Обновите ваш Active Directory как минимум до 2012 R2;
Следите за обновлениями Windows и постоянно их устанавливайте;
Помещайте важные учетные записи в группу защищенных пользователей и установите параметр реестра;
Не предоставляйте учетной записи больше прав администратора, чем им нужно;
Продолжим тему NTLM, поднятую в предыдущем пункте. Его нужно запретить - от слова совсем. Есть такая замечательная штука, как pass-the-hash. Она, как это можно понять из названия, передаёт хеш NTLM на абсолютно любой хостинг, где разрешён NTLM и атакующий всё про вас узнает. Более того, его также можно передавать вместо учетной записи и ее пароля при атаках.
Навешайте ярлыков на рабочий стол
В прямом смысле - поставьте ярлыки на рабочий стол, которые будут связывать с общими файловыми ресурсами. Тем самым Вы уйдёте от сетевых дисков, а malware почти никогда не воспримет их как сетевые ресурсы. Причина, как всегда, банальная - malware путём перебора букв ищет названия дисков. Конечно, данный совет подходит не всем компаниям, но если возможность подобного похода существует - попробуйте.
Отключите скрытые файловые ресурсы!
И вновь из-за банальной причины. Они - первоочередная цель действия malware и злоумышленников. Конечно, это не все инструменты защиты инфраструктуры, но каждый случай нужно рассматривать отдельно, как и индивидуальные настройки для каждой инфраструктуры.
Пока что это обсуждение предполагает, что сетевые устройства будут учитывать отметки, обнаруженные в IP-пакете. Конечно, это верно в отношении частных сетей и арендованных сетей, где условия доверия были согласованы с поставщиком услуг. Но что происходит в глобальном Интернете? Соблюдают ли сетевые устройства, обслуживающие общедоступный Интернет-трафик, и соблюдают ли значения DSCP, а также устанавливают ли приоритет одного трафика над другим во время перегрузки? С точки зрения потребителей Интернета, ответ отрицательный. Общедоступный Интернет - лучший транспорт. Нет никаких гарантий ровной доставки трафика, не говоря уже о расстановке приоритетов.
Даже в этом случае глобальный Интернет все чаще используется как глобальный транспорт для трафика, передаваемого между частными объектами. Дешевые услуги широкополосного доступа в Интернет иногда предлагают большую пропускную способность по более низкой цене, чем частные каналы глобальной сети, арендованные у поставщика услуг. Компромисс этой более низкой стоимости - более низкий уровень обслуживания, часто существенно более низкий. Дешевые каналы Интернета дешевы, потому что они не предлагают гарантий уровня обслуживания, по крайней мере, недостаточно значимых, чтобы вселить уверенность в своевременной доставке трафика (если вообще). Хотя можно отмечать трафик, предназначенный для Интернета, провайдер не обращает внимания на эти отметки. Когда Интернет используется в качестве транспорта WAN, как тогда можно эффективно применять политику QoS к трафику?
Создание качественного сервиса через общедоступный Интернет требует переосмысления схем приоритизации QoS. Для оператора частной сети публичный интернет-это черный ящик. Частный оператор не имеет никакого контроля над общедоступными маршрутизаторами между краями частной глобальной сети. Частный оператор не может установить приоритет определенного трафика над другим трафиком на перегруженном общедоступном интернет-канале без контроля над промежуточным общедоступным интернет-маршрутизатором.
Решение для обеспечения качества обслуживания через общедоступный Интернет является многосторонним:
Контроль над трафиком происходит на границе частной сети, прежде чем трафик попадет в черный ящик общедоступного Интернета. Это последняя точка, в которой оператор частной сети имеет контроль над устройством.
Политика QoS обеспечивается в первую очередь путем выбора пути и, во вторую очередь, путем управления перегрузкой.
В понятие выбора пути неявно подразумевается наличие более одного пути для выбора. В развивающейся модели программно-определяемой глобальной сети (SD-WAN) два или более канала глобальной сети рассматриваются как пул полосы пропускания. В пуле индивидуальный канал, используемый для передачи трафика в любой момент времени, определяется на момент за моментом, поскольку сетевые устройства на границе пула выполняют тесты качества по каждому доступному каналу или пути. В зависимости от характеристик пути в любой момент времени трафик может отправляться по тому или иному пути.
Какой трафик отправляется по какому пути? SD-WAN предлагает детализированные возможности классификации трафика за пределами управляемых человеком четырех-восьми классов, определяемых метками DSCP, наложенными на байт ToS. Политика выбора пути SD-WAN может быть определена на основе каждого приложения с учетом нюансов принимаемых решений о пересылке. Это отличается от идеи маркировки как можно ближе к источнику, а затем принятия решений о пересылке во время перегрузки на основе метки. Вместо этого SD-WAN сравнивает характеристики пути в реальном времени с определенными политикой потребностями приложений, классифицированных в реальном времени, а затем принимает решение о выборе пути в реальном времени.
Результатом должно быть взаимодействие пользователя с приложением, аналогичное полностью находящейся в собственности частной глобальной сети со схемой приоритизации QoS, управляющей перегрузкой. Однако механизмы, используемые для достижения подобного результата, существенно отличаются. Функциональность SD-WAN зависит от способности обнаруживать и быстро перенаправлять потоки трафика вокруг проблемы, в отличие от управления проблемой перегрузки после ее возникновения. Технологии SD-WAN не заменяют QoS; скорее они предоставляют возможность "поверх" для ситуаций, когда QoS не поддерживается в базовой сети.