Внимание! Данный шаг снижает безопасность узлов. Выполнять его можно только в учебной среде, когда весь виртуальный стенд работает на вашем локальном компьютере, и виртуальные машины не доступны из сети.
Да, я знаю про sudo и авторизацию по ключам. Приведена эта фраза именно для упрощения материала. Debian, в отличии от Ubuntu, не содержит (по умолчанию) в себе sudo. Эту утилиту нужно ставить дополнительно, и кроме того настраивать пользователю на неё использование. Поэтому про sudo было решено не писать.
С точки зрения безопаности. Debian, по умолчанию, использует парадигму "su", то есть вы входите под юзером, а потом перепрыгиваете на root. По факту подобная схема при двойной нагрузке на пользователя (нужно помнить два пароля) дает очень маленький выхлоп безопасности, с точки зрения подбора паролей можно просто увеличить пароль root на один символ и будет безопасней (математика не даст соврать).
Теперь к sudo. Сам по себе sudo дает только два положительных эффекта: 1 - он позволяет логгировать действия суперпользователей когда их несколько и они не читят типа (sudo -i или sudo bash); 2 - он (как и su) позволяет держать в секрете логин администратора (пользователя с правами sudo), что может быть актуально если у вас настроена блокировка авторизации при входе (интерактивно или ssh). Все, больше она ничего не дает. Хотя конечно можно придумать про случайный запуск вредоноса сразу root'ом, но это фэнтази при работе на серверах.
Резюмируя все сказанное, для учебных машин, на которых будет работать только один человек с правами администратора использование sudo не имеет ни малейшего смысла, равно как и su. Поскольку блокировка аккаунта не используется и вся безопасность держится на конфиденциальности пароля.
Заметьте я не говорю, что sudo - это бесполезная вещь. Просто все должно использоваться под задачу и с учетом специфики (модели актуальных угроз), а не просто, из-за того, что кто-то сказал что так правильно.
Ответы в стиле "ПО в АСУТП лучшая защита в мире. Недостижимая для ИТ. В АСУТП есть бекапы всего." Как-бы по мягче сказать.... это не ответ технического специалиста. Поясню. На одном заводе может быть бэкапы, а на другом нет. Проецировать единичный опыт на всю отрасль не вполне корректно.
Будьте добры аргументировать свои тезисы верифицируемой информацией.
почему, несмотря на десятилетия страхов о кибератаках, не зафиксировано случаев массовых разрушений или гибели людей из-за взлома АСУТП?
А вам не кажеться что инцидентов нет именно из-за ИБ? Пример очень напоминает классическое высказывание: зачем на админ, если и так все работает.
"На фармацевтическом предприятии запрет на удалённый доступ к SCADA вынудил технолога лететь из Германии в Индию для настройки дозатора."
Это не проблема ИБ, а проблема организации работ, когда требуемый технолог отсуствует на площадке.
Как в данной ситуации защитят приводимые вами "физические системами безопасности" если хакер изменит сломает настройку дозатора?
4. Удалённый доступ: Запрет, который стоит миллионов
В современном мире есть много встариваемого в человека мед. оборудования: кардиостимуляторы, инсулиновые помпы и т.д. Вот скажите, вы хотели бы, что у дорогоих вам людей подобное оборудование (если не дай бог пришлось бы его устанавливать) работало бы с вожможностью удаленного доступа и ошибка настройки которого могла привести к фатальному исходу?
Вы хотели бы жить рядом с вредным/опасным производством, где для удобства администраторов сделан доступ к системам управления через Wi-Fi?
Баланс ИБ польза vs сопуствующие издержки найти довольно сложно. Но большая часть приведенных примеров сводится к "давайте запретим замки, ибо сотрудникам требуется их открывать, что приводит к издержкам в работе".
Основная часть статьи сосредоточена на вопросе запуска двух сервисов на одном сокете. В результате, часть сетевых пакетов будут отправляться к одному сервису, а часть – ко второму. Если между веб-клиентом и веб-сервером происходит множество взаимодействий, это может быть заметным – например, половина изображений может не загрузиться.
Да, именно так, и это является демаскирующим признаком.
НО RAT может быть написан таким образом, чтобы отдавать нецелевой трафик обратно основному процессу, под который он маскируется и тогда эта проблема решится.
Касательно защиты, то NGFW частично может помочь, но только частично. Без организации комплексной безопасности узла (замкнутая программная среда, контроль использования ресурсов и т.д.) все усилия тщетны.
Под межсетевыми экранами Palo Alto или Fortinet вы скорее всего понимаете устройства с анализом трафика приложений, так называемые NGFW. Писать про них не буду, так как у меня под рукой их нет, а также из-за того, что производители очень не любят отрицательные отзывы о своей продукции.
У меня был практический опыт тестирования подобного оборудования, и оно из 6 тестов, осуществленных с помощью дефолтного Kali Linux смогло отловить только 0.5 атаки. После этого был conf-call с производителем, где настоятельно просили не раскрывать результаты тестов. Но это так, лирика.
Возвращаясь к вашему вопросу, в статье есть все исходники, и любой желающий может провести тесты самостоятельно. Если NGFW обладает должным функционалом и нормально настроен, то приведенные примеры скорее всего работать не будут, так как они специально написаны таким образом, чтобы демонстрировать проблему, а не быть готовыми эксплойтами. НО для специалистов переделать их, чтобы пробивать NGFW, не составит больших проблем. Достаточно будет только понять, по каким критериям устройство классифицирует трафик, и подделать сообщение таким образом, чтобы он был похож на легитимный для FW трафик. В статье реализован blind shell, а для того, чтобы он сработал, достаточно, чтобы FW пропустил всего одно сообщение прикладного уровня. Классифицировать трафик по одному сообщению можно разве что путем анализа синтаксиса.
Хакер - это не только некая личность в Интернете. Это может быть и уволившейся админ, доступ которому заблокировали не сразу. Не исключено, что подобный товарищь мог оставить себе лазейку, чтоб вернуться обратно, особенно если на сервере есть что-то ценное.
Поэтому основной смысл статьи в том, чтобы расскзать куда нужно смотреть, чтобы "точно" закрыть все форточки, а не ограничиваться банальной блокировкой учеток и выявлением активности reverse shell.
Вообще-то в случае оговоренного в статье линукса, самая популярная библиотека - libpcap - выхватывает пакеты до оговоренного же в статье nftables. Так что видно будет абсолютно всё, неважно что вы там в nftables делаете.
В моих тестах дефолтных debian tcpdump не фидел фильтрованный трафик. Да и к тому же это только в статье рассматривается локальный netfilter. Эти же способы могут использоваться и для обхода шлюзовых FW. Разве что какой-нибудь особо умный NGFW сможет что-то сделать.
У всех способов есть плюсы и минусы. Специально не стал рассказывать как бороться с проблемами, чтоб не делать готовый RAT. Те кому надо сами разберутся, а новички не будут играть в чудо-хакеров.
Можно и в рамках одного виджета. Но разделение на технические и эмоциональные реакции быть должно. Иначе будет как в статье "Умер всеми любимый <такой-то человек>"
Главная проблема реакций была в том их было слишком мало, в результате чего было непонятно что ставить, так как ничего из предложенного не нравилось и нужных ассоциаций не вызывало.
Возможно нужно было взять стандартные иконки реакций, что были в соц. сетях, так было бы понятней. А вообще оценка контента действительно должна быть двух уровневой. Поясню.
Возьмем пример, статья "Умер всеми любимый <такой-то человек>". Когда вы плюсуете статью - вы выражаете радость от смерти или то что статья хорошо написана? Чтобы избежать это неоднозначности эмоциональный отклик на статью и должен быть двух уровневым:
Первый уровень - качество статьи, всеми привычный рейтинг. Здесь мы благодарим автора за то что он написал статью и сделал это качественно. Тогда плюс под "Умер всеми любимый <такой-то человек>" будет означать не то, что мы радумеся смерти, а то что автор молодец и мы хотим, чтобы как можно больше людей узнало об этом.
Второй уровень - это эмоции, которые вызвал контент статьи. Например, печаль, боль, радость, удивление, воодушевление, "хм.. прикольно", "хабр торт" и т.д. Этот уровень ни на что не влияет и просто позволяет поделиться, дать эмоциональную оценку событию описанному в статье.
И еще когда вводятся какие-либо оценки нужно учить пользователей ими пользоваться. В противном случае будет как у некоторых профессоров ВУЗов. У одних "5 - это значит вы усвоили программу", а у других "4 - это значит что вы усвоили программу, а 5 - это Wow, вы должны знать больше чем я".
Двух уровневая оценка сделает нормальной ситуацию, когда статья "Умер всеми любимый <такой-то человек>" наберет рейтинг +1000 и будет содержать 1000 эмоциональных реакци боли и утраты.
Пример ущербности одноуровневой оценки успешно показан в сериале "Загрузка". Здесь главная героиня всеми силами пытается развлечь бессмертного оцифрованного старика и старательно изображает утку для охоты.
Однако старику не смотря на все старания работницы не нравится забава и он оценивает ее на 3 бала, что снижает ее эффективный рейтинг как работника и влечет финансовые последствия.
Для инсталляции сервера (любого) делаю install.sh, который все ставит и настраивает. Скрипт рассчитан на работу в ОС с minimal install составе. Если его запустить 2 раза, то ничего не сломается и все будет тем же что и требуется, но дело не в этом.
Ansible хорош при управлении большим числом узлов, если массовости не требуется, то он избыточен и проще (быстрее) сделать скриптами.
Основная фишка данного подхода - возможность работы отовсюду, даже из BIOS. Для некоторых сценариев беспроводной доступ может быть запрещен на уровне политики безопасности.
Если люди не умеют читать и не видят фразу:
их ничто не спасет.
Хорошо, будут тогда ману копить на обновление)
Да, я знаю про sudo и авторизацию по ключам. Приведена эта фраза именно для упрощения материала. Debian, в отличии от Ubuntu, не содержит (по умолчанию) в себе sudo. Эту утилиту нужно ставить дополнительно, и кроме того настраивать пользователю на неё использование. Поэтому про sudo было решено не писать.
С точки зрения безопаности. Debian, по умолчанию, использует парадигму "su", то есть вы входите под юзером, а потом перепрыгиваете на root. По факту подобная схема при двойной нагрузке на пользователя (нужно помнить два пароля) дает очень маленький выхлоп безопасности, с точки зрения подбора паролей можно просто увеличить пароль root на один символ и будет безопасней (математика не даст соврать).
Теперь к sudo. Сам по себе sudo дает только два положительных эффекта: 1 - он позволяет логгировать действия суперпользователей когда их несколько и они не читят типа (sudo -i или sudo bash); 2 - он (как и su) позволяет держать в секрете логин администратора (пользователя с правами sudo), что может быть актуально если у вас настроена блокировка авторизации при входе (интерактивно или ssh). Все, больше она ничего не дает. Хотя конечно можно придумать про случайный запуск вредоноса сразу root'ом, но это фэнтази при работе на серверах.
Резюмируя все сказанное, для учебных машин, на которых будет работать только один человек с правами администратора использование sudo не имеет ни малейшего смысла, равно как и su. Поскольку блокировка аккаунта не используется и вся безопасность держится на конфиденциальности пароля.
Заметьте я не говорю, что sudo - это бесполезная вещь. Просто все должно использоваться под задачу и с учетом специфики (модели актуальных угроз), а не просто, из-за того, что кто-то сказал что так правильно.
Карго культ must die.
Давайте так, как закончите изучение статьи скиньте мне все найденные проблемы и ваши предложения по их обходу. Я их перепроверю и обновлю статью.
Можно конкретику по моим вопросам?
Ответы в стиле "ПО в АСУТП лучшая защита в мире. Недостижимая для ИТ. В АСУТП есть бекапы всего." Как-бы по мягче сказать.... это не ответ технического специалиста. Поясню. На одном заводе может быть бэкапы, а на другом нет. Проецировать единичный опыт на всю отрасль не вполне корректно.
Будьте добры аргументировать свои тезисы верифицируемой информацией.
А вам не кажеться что инцидентов нет именно из-за ИБ? Пример очень напоминает классическое высказывание: зачем на админ, если и так все работает.
Это не проблема ИБ, а проблема организации работ, когда требуемый технолог отсуствует на площадке.
Как в данной ситуации защитят приводимые вами "физические системами безопасности" если хакер изменит сломает настройку дозатора?
В современном мире есть много встариваемого в человека мед. оборудования: кардиостимуляторы, инсулиновые помпы и т.д. Вот скажите, вы хотели бы, что у дорогоих вам людей подобное оборудование (если не дай бог пришлось бы его устанавливать) работало бы с вожможностью удаленного доступа и ошибка настройки которого могла привести к фатальному исходу?
Вы хотели бы жить рядом с вредным/опасным производством, где для удобства администраторов сделан доступ к системам управления через Wi-Fi?
Баланс ИБ польза vs сопуствующие издержки найти довольно сложно. Но большая часть приведенных примеров сводится к "давайте запретим замки, ибо сотрудникам требуется их открывать, что приводит к издержкам в работе".
P.S. Хотелось бы видить пруфы на примеры.
Да, именно так, и это является демаскирующим признаком.
НО RAT может быть написан таким образом, чтобы отдавать нецелевой трафик обратно основному процессу, под который он маскируется и тогда эта проблема решится.
Касательно защиты, то NGFW частично может помочь, но только частично. Без организации комплексной безопасности узла (замкнутая программная среда, контроль использования ресурсов и т.д.) все усилия тщетны.
Под межсетевыми экранами Palo Alto или Fortinet вы скорее всего понимаете устройства с анализом трафика приложений, так называемые NGFW. Писать про них не буду, так как у меня под рукой их нет, а также из-за того, что производители очень не любят отрицательные отзывы о своей продукции.
У меня был практический опыт тестирования подобного оборудования, и оно из 6 тестов, осуществленных с помощью дефолтного Kali Linux смогло отловить только 0.5 атаки. После этого был conf-call с производителем, где настоятельно просили не раскрывать результаты тестов. Но это так, лирика.
Возвращаясь к вашему вопросу, в статье есть все исходники, и любой желающий может провести тесты самостоятельно. Если NGFW обладает должным функционалом и нормально настроен, то приведенные примеры скорее всего работать не будут, так как они специально написаны таким образом, чтобы демонстрировать проблему, а не быть готовыми эксплойтами. НО для специалистов переделать их, чтобы пробивать NGFW, не составит больших проблем. Достаточно будет только понять, по каким критериям устройство классифицирует трафик, и подделать сообщение таким образом, чтобы он был похож на легитимный для FW трафик. В статье реализован blind shell, а для того, чтобы он сработал, достаточно, чтобы FW пропустил всего одно сообщение прикладного уровня. Классифицировать трафик по одному сообщению можно разве что путем анализа синтаксиса.
Хакер - это не только некая личность в Интернете. Это может быть и уволившейся админ, доступ которому заблокировали не сразу. Не исключено, что подобный товарищь мог оставить себе лазейку, чтоб вернуться обратно, особенно если на сервере есть что-то ценное.
Поэтому основной смысл статьи в том, чтобы расскзать куда нужно смотреть, чтобы "точно" закрыть все форточки, а не ограничиваться банальной блокировкой учеток и выявлением активности reverse shell.
В моих тестах дефолтных debian tcpdump не фидел фильтрованный трафик. Да и к тому же это только в статье рассматривается локальный netfilter. Эти же способы могут использоваться и для обхода шлюзовых FW. Разве что какой-нибудь особо умный NGFW сможет что-то сделать.
У всех способов есть плюсы и минусы. Специально не стал рассказывать как бороться с проблемами, чтоб не делать готовый RAT. Те кому надо сами разберутся, а новички не будут играть в чудо-хакеров.
Можно и в рамках одного виджета. Но разделение на технические и эмоциональные реакции быть должно. Иначе будет как в статье "Умер всеми любимый <такой-то человек>"
Нажать вместо одной кнопки 2?
Не сложно, а не привычно. Поэтому и нужно обучение.
Главная проблема реакций была в том их было слишком мало, в результате чего было непонятно что ставить, так как ничего из предложенного не нравилось и нужных ассоциаций не вызывало.
Возможно нужно было взять стандартные иконки реакций, что были в соц. сетях, так было бы понятней. А вообще оценка контента действительно должна быть двух уровневой. Поясню.
Возьмем пример, статья "Умер всеми любимый <такой-то человек>". Когда вы плюсуете статью - вы выражаете радость от смерти или то что статья хорошо написана? Чтобы избежать это неоднозначности эмоциональный отклик на статью и должен быть двух уровневым:
Первый уровень - качество статьи, всеми привычный рейтинг. Здесь мы благодарим автора за то что он написал статью и сделал это качественно. Тогда плюс под "Умер всеми любимый <такой-то человек>" будет означать не то, что мы радумеся смерти, а то что автор молодец и мы хотим, чтобы как можно больше людей узнало об этом.
Второй уровень - это эмоции, которые вызвал контент статьи. Например, печаль, боль, радость, удивление, воодушевление, "хм.. прикольно", "хабр торт" и т.д. Этот уровень ни на что не влияет и просто позволяет поделиться, дать эмоциональную оценку событию описанному в статье.
И еще когда вводятся какие-либо оценки нужно учить пользователей ими пользоваться. В противном случае будет как у некоторых профессоров ВУЗов. У одних "5 - это значит вы усвоили программу", а у других "4 - это значит что вы усвоили программу, а 5 - это Wow, вы должны знать больше чем я".
Двух уровневая оценка сделает нормальной ситуацию, когда статья "Умер всеми любимый <такой-то человек>" наберет рейтинг +1000 и будет содержать 1000 эмоциональных реакци боли и утраты.
Пример ущербности одноуровневой оценки успешно показан в сериале "Загрузка". Здесь главная героиня всеми силами пытается развлечь бессмертного оцифрованного старика и старательно изображает утку для охоты.
Однако старику не смотря на все старания работницы не нравится забава и он оценивает ее на 3 бала, что снижает ее эффективный рейтинг как работника и влечет финансовые последствия.
Для инсталляции сервера (любого) делаю install.sh, который все ставит и настраивает. Скрипт рассчитан на работу в ОС с minimal install составе. Если его запустить 2 раза, то ничего не сломается и все будет тем же что и требуется, но дело не в этом.
Ansible хорош при управлении большим числом узлов, если массовости не требуется, то он избыточен и проще (быстрее) сделать скриптами.
Каждый инструмент хорош для своей задачи.
Редактирование текстовых конфигов скриптами кажется простым только тем, кто с этим никогда не сталкивался в проде ;-)
Ansible хорош, но не панацея. Довольно часто, то что он делает значительно проще сделать Shell скриптами.
ФСТЭК, ФСБ ... мало органов?
Именно так. Забыл написать про KVM в статье, а хотел )
Основная фишка данного подхода - возможность работы отовсюду, даже из BIOS. Для некоторых сценариев беспроводной доступ может быть запрещен на уровне политики безопасности.