Зачем придумывать проблему обмена данными между современной Apple macOS и устаревшей "классической" Mac OS, которую официально похоронили? Всё просто: желание иногда поиграть в старые игры на реальном "древнем" компьютере. Поэтому возникает вопрос доставки образов на этот компьютер. По USB 1.1 копирование данных занимает вечность, записывать CD/DVD может быть невозможно из-за отсутствия привода, покупать жёсткие диски с портом FireWire нецелесообразно, к тому же, можно столкнуться с проблемой отсутствия портов FW на современных компьютерах. Таким образом, в качестве самого приемлемого варианта, остаётся сетевой обмен с использованием таких протоколов как AFP, NFS, SMB, SFTP, FTP.
-
Варианты сетевой передачи файлов между современной Apple macOS и устаревшей "классической" Mac OS с использованием протоколов AFP, NFS, SMB, SFTP, FTP
-
Сканирование сети на предмет выявления модулей управления ИБП APC уязвимых к Ripple20
В прошлом году компанией JSOF была публично раскрыта информация о целом наборе уязвимостей, корни которых уходят в древнюю библиотеку компании Treck, реализующую функции стека протоколов TCP/IP. Эту библиотеку на протяжении многих лет использовали разные производители аппаратного обеспечения для обеспечения работы TCP/IP во встроенном микрокоде firmware на множестве разных типов устройств. Данный пакет уязвимостей получил общее название Ripple20.
Уязвимости, входящие в состав Ripple20, имеют разные уровни критичности и среди них есть некоторые опасные уязвимости, позволяющие удалённо вызвать отказ в обслуживании или даже получать полный доступ над устройством со всеми вытекающими последствиями.
Данная проблема была освещена на множестве интернет-ресурсов, связанных с темой информационной безопасности. Вот некоторые из них:
- Блог Касперского - Ripple20: 19 уязвимостей в библиотеке TCP/IP
- SecurityLab - Уязвимости Ripple20 затрагивают миллиарды устройств по всему миру
- "Хакер" - Сотни миллионов IoT-устройств в опасности из-за уязвимостей Ripple20
Часть вендоров на протяжении нескольких месяцев после огласки Ripple20 выпустили обновления микрокода для своих продуктов, в которых закрываются данные уязвимости. Однако некоторые производители намеренно отказались от обновления микрокода некоторых своих продуктов, снятых с текущей поддержки. Таким образом, все уязвимые устройства, не имеющие обновления, но по прежнему эксплуатируемые в рамках локальных/глобальных сетей, вошли в группу повышенных рисков нарушения режима ИБ.
Проблема с уязвимостями Ripple20 заключается в том, что работа по снижению рисков в рамках больших корпоративных сетей с множеством устройств разных производителей и моделей, требует комплексного подхода с применением разных методик защиты, таких как обновление микрокода, ужесточение правил меж-узлового взаимодействия на уровне сети, использование систем обнаружения сетевых аномалий и т.д.
Применительно к вопросу обновления микрокода на эксплуатируемых сетевых устройствах, требуется отдельное планирование и немалый объём работы по устройствам каждого отдельно взятого производителя и модели. В данной заметке мы рассмотрим вариант сбора информации относительно модулей управления источников бесперебойного питания (ИБП) марки APC ("APC by Schneider Electric"), которые широко используются для защиты электропитания серверного и сетевого оборудования.
-
Настраиваем высоко-доступный сервер FTP в существующем файловом кластере на базе Windows Server 2012 R2 Failover Cluster (без выделенного диска под роль FTP)
Возникла необходимость в развёртывании сервера FTP с анонимной авторизацией для внутренних задач в локальной сети. И чтобы не плодить лишние сущности, то есть не разворачивать дополнительный сервер исключительно под эту задачу, возникло желание использовать существующие файловые сервера. В нашем случае файловый сервис реализован на базе двух серверов состоящих в кластере Failover Cluster на Windows Server 2012 R2 и использующих общее дисковое хранилище. Решение предлагаемое Microsoft для кластеризации FTP на базе Failover Cluster в статье KB974603 - How to configure FTP for IIS 7.0 or higher in a Windows Server 2008 or Windows Server 2012 failover cluster нам в чистом виде не подошло, так как оно предполагает наличие выделенного общего кластерного диска, а в нашей ситуации вся доступная ёмкость общего дискового хранилища в кластере уже была отдана под роль файлового сервиса. Статья The Admin's Window - Configuring highly available FTP server on a Windows Server 2008 failover cluster (without FTP dedicated storage) натолкнула на размышления о том, как можно обойти эту ситуацию.