Разного рода уязвимости в коде и атаки на дыры сайтов это только одна из нескольких областей безопасности. Знать про атаки и не плодить для них дырки своим кодом - удел прикладных программистов, за которыми закручивают контргайку тестировщики. Кроме прикладного программирования сервисов/сайтов в отдельные профессии выделяют управленцев инфраструктурой, в которой тоже может завестись дупло.
Картина в целом такова, что дыры могут быть на всех уровнях... И в операционной системе, и в корневых технологиях (программы-серверы, протоколы связи и шины обмена данными, хранящие базы данных, кэширующие базы данных, подключаемые библиотеки, вспомогательные утилиты, языки программирования и фреймворки). Современная разработка усложнилась до безумия - одни фреймворк базируется на другом фреймворке, к ним подключается груда библиотек, что при проблемах выливается в закономерное "если делали двое - виноватого не найти".
Большие и сложные системы идут путём разделения на множество маленьких и простых частей, каждую из которых возможно детально осмыслить одной головой. Хорошей практикой для безопасности и отказоустойчивости является изоляция частей: при взломе одной части - злоумышленнику придётся потрудиться для проникновения в остальные, а при падении части - можно быстро её перезапустить.
Для маленьких и монолитных проектов, которых в мире большинство, можно перенять у больших братьев некоторые подходящие решения. Сам практикую это и абстрактно в общих чертах, могу описать это как-то так...
Философия: ненужное не нужно.
Минусы: займёт время, а результат будет несовместим с тем "как у большинства".
Побочные эффекты: освобождение места и оперативки.
Большинство маленьких проектов берут за основу Ubuntu. Меньшинство больших - Alpine Llinux внутри контейнеров Docker. Использовать контейнеры не обязательно, можно просто поставить Alpine и пользоваться им.
Из сложностей, там нельзя бездумно "поставить пхп". Придётся ставить отдельно нужные модули, например GD для работы с изображениями. Там даже Op_Cache ставится отдельно. Зато получится только то, что нужно (меньше модулей - меньше рисков). Вот наглядное сравнение модулей PHP и зависимостей для работы PHP на сервере (для публикаций) и на домашнем компике (для локальной разработки).
Вот парочка несложных роликов...
Вместо sudo в Alpine можно пользоваться упрощённым doas. А чтобы не пользоваться su, можно заблокировать рута.
При блокировке нельзя будет становиться рутом через su, даже с правильным паролем будет возвращаться ошибка.
В лагере открытых исходников побывали предатели. Зависимость под забавным названием XZ, которая много для какого софта требуется, однажды была чёрным ходом для злоумышленников, которые втёрлись в доверие и поучаствовали в её разработке.
Тема безопасности устройств туда же, чтобы через клиентское устройство с доступами на сервер не пролезли. И вспоминаем, что существуют сервера на винде, где тоже хорошо было бы потушить всё лишнее.
Картина в целом такова, что дыры могут быть на всех уровнях... И в операционной системе, и в корневых технологиях (программы-серверы, протоколы связи и шины обмена данными, хранящие базы данных, кэширующие базы данных, подключаемые библиотеки, вспомогательные утилиты, языки программирования и фреймворки). Современная разработка усложнилась до безумия - одни фреймворк базируется на другом фреймворке, к ним подключается груда библиотек, что при проблемах выливается в закономерное "если делали двое - виноватого не найти".
Большие и сложные системы идут путём разделения на множество маленьких и простых частей, каждую из которых возможно детально осмыслить одной головой. Хорошей практикой для безопасности и отказоустойчивости является изоляция частей: при взломе одной части - злоумышленнику придётся потрудиться для проникновения в остальные, а при падении части - можно быстро её перезапустить.
Для маленьких и монолитных проектов, которых в мире большинство, можно перенять у больших братьев некоторые подходящие решения. Сам практикую это и абстрактно в общих чертах, могу описать это как-то так...
Философия: ненужное не нужно.
Минусы: займёт время, а результат будет несовместим с тем "как у большинства".
Побочные эффекты: освобождение места и оперативки.
Большинство маленьких проектов берут за основу Ubuntu. Меньшинство больших - Alpine Llinux внутри контейнеров Docker. Использовать контейнеры не обязательно, можно просто поставить Alpine и пользоваться им.
Из сложностей, там нельзя бездумно "поставить пхп". Придётся ставить отдельно нужные модули, например GD для работы с изображениями. Там даже Op_Cache ставится отдельно. Зато получится только то, что нужно (меньше модулей - меньше рисков). Вот наглядное сравнение модулей PHP и зависимостей для работы PHP на сервере (для публикаций) и на домашнем компике (для локальной разработки).
Вот парочка несложных роликов...
Вместо sudo в Alpine можно пользоваться упрощённым doas. А чтобы не пользоваться su, можно заблокировать рута.
Bash:
# заблокировать
doas passwd -l root
# разблокировать
doas passwd -u rootВ лагере открытых исходников побывали предатели. Зависимость под забавным названием XZ, которая много для какого софта требуется, однажды была чёрным ходом для злоумышленников, которые втёрлись в доверие и поучаствовали в её разработке.
Тема безопасности устройств туда же, чтобы через клиентское устройство с доступами на сервер не пролезли. И вспоминаем, что существуют сервера на винде, где тоже хорошо было бы потушить всё лишнее.
