Comments 19
Годная статья. Благодарю.
Хорошо собрали в одну статью, спасибо. Немного не хватает конкретики по действиям, понимаю, что не планировали, ну типа пошагово, как внедрять безопасность встраиваемых систем Linux.
Если добавить конкретики в каждый раздел, то тогда пост превратится в книгу. Подобными задачами безопасности занимаются целые коллективы. Много материала взято от компании Toradex . В планах каждый из разделов постараться отдельно рассмотреть, но на это уйдет много времени. Первый на очереди стоит раздел — Контейнеры (Docker).
да, это хорошая база для дальнейшего рассмотрения темы, если не переводная статья.
в частности, исходя из описываемых здесь терминов уже можно в общих чертах описывать ту же подсистему безопасности, на которую в виде модуля вешаются исполнительные системы selinux, apparmor и прочие.
лет 15 назад, когда занимался данной темой, очень не хватало единого согласования терминов, т.к. в наших нормотворческих документах разных контор, определяющих безопасность (ФСТЭК, ФСБ, ЦБ, СредМаш и прочие — терминология была разной).
сейчас — надо посмотреть текущее состояние.
в частности, исходя из описываемых здесь терминов уже можно в общих чертах описывать ту же подсистему безопасности, на которую в виде модуля вешаются исполнительные системы selinux, apparmor и прочие.
лет 15 назад, когда занимался данной темой, очень не хватало единого согласования терминов, т.к. в наших нормотворческих документах разных контор, определяющих безопасность (ФСТЭК, ФСБ, ЦБ, СредМаш и прочие — терминология была разной).
сейчас — надо посмотреть текущее состояние.
Самое сложное было правильно подобрать терминологию, Linux capabilities — дословно «Возможности Linux». Пришлось взять термин в русскоязычной редакции из Active Directory Windows Server, когда учетной записи не назначаются права Администратора, а выдаются права только на отдельные административные функции. То что касается открытых российских документов по безопасности, то старые варианты ничего похожего на Hardware Threat Landscape and Good Practice Guide от ENISA и близко не содержат. На мой взгляд российские документы содержат крайне устаревшую концепцию ИБ, мир в техническом плане ушел гораздо дальше чем то, что там описывается. Таким образом, оценка рисков становится неверной, а модель нарушителя неактуальной.
Закрыть все неиспользуемые порты TCP/UDP
если порт никаким сервисом не используется, то зачем его "закрывать" ?
Если порт не используется, то в случае сканирования, будет ответ от хоста что порт не обслуживается. Если порт блокируется брандмауэром, то не будет никакого ответа, в результате это осложнит сканирование портов хоста. Wiki Сканер портов.
Хм, если сканер портов быстро поймет что, например, на хосте кроме 22 и 80 порта ничего не открыто, то как это помешает работе этого хоста? Ведь уязвимость образуется на открытых портах, а не на неиспользуемых.
Концепция защиты заключается в создание максимальных «трудностей» злоумышленнику. Сканер портов быстро не поймет, потому что можно настроить защиту так, что бы ответ был только в соответствие с требуемым протоколом. А без этого, злоумышленник со 100% гарантией поймет что доступно, а что нет.
Мы ведь говорим про неиспользуемые порты, потому и не пойму какая польза в том что злоумышленник быстро или чуть медленно поймет что на порту ничего нет, атака ведь по нему не пойдет никогда.
Мне кажется даже наоборот, не получив ответа от, например закрытого порта 12345, он на него еще пакетов накидает от разных типов скана.
Так хорошо, если накидает пакетов. Файрвол сможет гораздо точнее определить вид и характер атаки. С точки зрения защиты необходимо так же изучать злоумышленника. И чем больше о нем будет собрана информации, тем точнее будет составлен профиль и модель поведения. Это позволит в дальнейшем точнее его идентифицировать. На первый раз злоумышленника заблокируем, а для второго случая создадим для него приманку в виде — HoneyPot. Небольшая статья на Хабре — Подробное руководство по Honeypot.
Если он поймет чуть медленнее, то это увеличит время, в течении которого осуществляется сканирование. Суммарные затраты времени на сканирование увеличиваются, иногда существенно.
согласен. ещё более «зверская» в 90е была ситуация, когда один студент на ИС ВГУ писал дипломную и в 98 году на dec альфе главного корпуса ставил honeypotы.
частично использовал какое-то защитное по dec, и для разных адресов альфа имитировала себя как 4.0, 3.52НТ, линукс 2.2, bsd разной степени. дальнейшей судьбы этой работы не знаю, но насколько помню — там даже частично настройки ip стека менялись, на типовые для данной платформы. благо каналы были до 1-2мбита на предприятиях и диалап у пользователей того времени.
О, не посмотрел — дальше ты тоже про honeypots описываешь.
частично использовал какое-то защитное по dec, и для разных адресов альфа имитировала себя как 4.0, 3.52НТ, линукс 2.2, bsd разной степени. дальнейшей судьбы этой работы не знаю, но насколько помню — там даже частично настройки ip стека менялись, на типовые для данной платформы. благо каналы были до 1-2мбита на предприятиях и диалап у пользователей того времени.
О, не посмотрел — дальше ты тоже про honeypots описываешь.
А потом под всей вот этой красотой выполняется Hello World :D
Или ещё лучше - условный Зум с ключами в текстовом файлике и встроенным мастер-ключём)
Да хоть просто «Hello». Все зависит от того какие активы необходимо защищать. Если вам злоумышленник перепрограммирует домашнюю морозильную камеру, где хранятся продукты, и выставит положительную температуру, ну выбросите продукты и все. А если это охлаждающая камера на опасном химическом производстве? Увеличение температуры может создать критическую ситуацию более опасную, чем просто испорченные продукты.
Хорошая статья, спасибо.
Вообще начав читать статью подумал что будет безопасность в вакууме без конкретики, а потом такое мясо пошло. Хорошая статья, спасибо.
Благодарю всех за положительные отзывы!
Sign up to leave a comment.
Безопасность встраиваемых систем Linux