Как стать автором
Обновить

Комментарии 16

Спасибо за пост. Как новичку в Линуксе мне советы довольно актуальны — хотя наверное более продвинутые пользователи все это и так знают.
Некоторые моменты очень устарели. В наши дни мало кому доводится порулить машиной с inetd, telnetd или fingerd.
Если вводить 100500 паролей при загрузках/расшифровках — пользоваться такой системой будет малоприятно…
hosts.allow
in.telnetd: 123.12.41., 126.27.18., .mydomain.name, .another.name
in.ftpd: 123.12.41., 126.27.18., .mydomain.name, .another.name

2016 года, это уже за гранью добра и зла… Вы ссылаетесь на документ, который ещё был написан на SGML. SGML, Карл!

«малоприятно» — не то слово, захотел к примеру поставить MQ manager, а он на каждое сообщение шифрует/дешифрует диск. Сообщений допустим по 30к/мин — это уже невозможно. Единственно действующую защиту на практике — видел только контроль доступа.
Некоторые из этих советов — хорошие и не всегда очевидные (например, отключение ненужных сервисов). Но вот совет шифровать весь диск — это уже какой-то серьезный градус паранойи, и нужно различать, скажем, «сервер с маленькой и очень дорогой базой контрагентов, физически стоящий в чужом датацентре», и «виртуальный веб-сервер, не являющийся основным бизнесом компании, в нашем собственном офисе». Во втором случае LUKS представляется довольно бесполезным и даже вредным — безопасности он не добавит, а вот ущерб для быстродействия и простоты администрирования критически важного сервиса будет.

Кстати, желающие дальнейшего повышения градуса паранойи могут почитать про Cold Boot Attack и подумать, как мы можем защитить от нее наш бедный Линукс-сервер с hosts.allow. Поскольку биос закрыт паролем, атака будет осуществляться вскрытием корпуса, охлаждением памяти и втыканием ее в устройство злоумышленника.
И что вам это даст, если диск пошифрован?
Ключ для подмонтированного шифрованного диска находится в памяти. Я не буду утверждать, что получение его абсолютно элементарно, но при внезапном отключении питания (без размонтирования дисков и очистки памяти) вполне технически выполнимо.
А если сервер виртуальный, то дамп памяти снять — дело пары команд. Если нужно иметь контроль над данными, то физический контроль над сервером обязателен.
Несколько вопросов, если позволите:
«Поскольку биос закрыт паролем...» неужели в сфере линукс были существенные проблемы с дырявостью BIOS?? Если да, то почему древнюю технологию UEFI внедрили только 10-15 лет спустя с момента ее изобретения??? И как много было прецедентов взлома систем?? Неужели падучая файловая система FAT32 добавляет безопасности серьезным серверным решениям?
Еще я бы настоятельно советовал:
1. Устанавливать сервер в минимальной конфигурации и уже потом доставлять только то, что необходимо;
2. Изменять порт SSH;
3. Использовать только официальные репозитории с подписанными пакетами;
4. Никогда (НИКОГДА) не отключать SElinux, а научиться с ним дружить;
5. Читать системные логи и логи безопасности, настроить уведомления по определенным событиям.
Подскажите, а как настроить автообновления только безопасности?
В случае с ubuntu –> crontab + unattended-packages (подробнее: https://help.ubuntu.com/community/AutomaticSecurityUpdates )
А в чем смысл статьи? Упомянули простейшие способы «защиты», более того, среди упомянутого — мамонты в виде inetd. Да, вспомнили вскользь о SELinux, не сказав ни слова о том, как им пользоваться.
Интересно, что практический к каждой статье есть такой комментарий с некоторыми вариациями и очень редко с конструктивными предложениями. Это я к тому: посоветуйте автору что следует выкинуть, а что добавить. Статья станет лучше.
Хм, согласен, разумно.
На мой взгляд стоило бы убрать упоминание о софте, который уже практически не используется. А вот добавить бы стоило много чего.
Раз уж заговорили о фаерволе, то стоило дать рекомендации по его настройкам, как минимум поверхностные, например, предложить несколько схем его настройки («разрешить все кроме» и «запретить все кроме»), рассказать о разнице между ними и привести примеры настройки фаервола хотя бы для одного из популярных дистрибутивов. Вот такая информация могла бы помочь начинающим администраторам, и могла бы быть отправной точкой в настройке.
Далее, был упомянут SELinux, по нему тоже стоило более расширенно написать, начать банально с того, как его включить/выключить, заканчивая тем, как им пользоваться. Понятное дело, SELinux — тема не на одну статью, но можно было бы дать базовую информацию по этому ПО.

А вообще, статья больше похожа на заметку из серии «надо не забыть при настройке очередного сервера». В идеале сделать бы из нее некий каталог ссылок на статьи, которые более глубоко описывают каждый раздел. ИМХО, в таком варианте она имела бы большую ценность.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.