Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 <p>В сегодняшней публикации мы коснёмся<strong>основ безопасности Linux-систем</strong>в общем понимании. Речь скорее пойдёт об общих принципах построения защищённой системы, чем о написании конкретных конфигов и настройки тех или иных сервисов.</p>

2 <p>Материал не претендует на полную и абсолютную истинность. Однако указанные советы несомненно будут полезными при эскизном проектировании ИБ, а также смогут послужить как отправные точки для написания различного рода внутренних регламентов и политик безопасности.</p>

3 <p>Чтобы сервер был безопасен, надо соблюдать ряд действий и правил. Простых и не очень. Опишу всё по порядку.</p>

4 <h3>1. Ставить везде разные и везде сложные пароли</h3>

5 <p>Ну, я думаю, зачем это, объяснять не нужно, если с фантазией сложно, можно использовать утилиту<strong>pwgen</strong>, которая сгенерирует пароли за вас.</p>

6 <h3>2. Не использовать стандартные порты</h3>

7 <p>Это, как ни странно, полезно. Многие сканеры уязвимостей ищут их только на определённых портах. Если даже у вас есть уязвимая служба на другом порту, сканер может её не определить.</p>

8 <h3>3. Читать и проверять логи</h3>

9 <p>Все сообщения об ошибках пишутся в логах, также можно понять многое и о уязвимостях, найденных другими, просто просмотрев их.</p>

10 <h3>4. Не сидеть постоянно под рутом</h3>

11 <p>Дело в том, что и вы можете ошибиться и что-то удалить, да и, если попадёте в ловушку из-под рута, злоумышленник также будет владеть полными правами.</p>

12 <h3>5. Выставлять безопасные права на файлы и папки, владельцев</h3>

13 <p>Также хочу заметить, что не повредит<strong>selinux</strong>(модуль ядра, разработанный американскими военными для более сложных уровней доступа) и<strong>bindfs</strong>(можно примонтировать папку как отдельную файловую систему).</p>

14 <h3>6. Chroot'ить всё, что можно, что может дать доступ к системе</h3>

15 <p><strong>Черут</strong>- это создание окружения с нужными файлами и утилитами, после этой команды корень файловой системы будет именно в этом каталоге, в который вы черутите. Разумеется, там нужны многие системные файлы, но плюсы в том, что вы можете скопировать только нужные утилиты в папку /bin/ и у людей, закрытых в этой директории, будут урезанные возможности, и даже если они что-то натворят, то только в этой папке. Поэтому<strong>надо черутить всё</strong>, что так или иначе может дать доступ к системе, например, апач. Многие программы в конфиге позволяют настроить черут для некоторых юзеров. Например, пользователей<strong>proftpd</strong>можно закрыть в любом каталоге и выше него они не подымутся, это делается всё также - черутом, но уже без вашего участия, а автоматически программами.</p>

16 <h3>7. Запускать службы и демоны, которые могут дать доступ к системе под отдельным пользователем, урезанным в правах</h3>

17 <p>И снова можно привести пример с апачем. Если в нём найдётся уязвимость, то можно будет выполнять команды от юзера, запустившего его, поэтому стоит позаботится об ограничении прав для этого пользователя. В убунте уже есть юзер, специально созданный для этого дела, -<strong>www-data</strong>, и веб-серверы запускаются от его имени.</p>

18 <h3>8. Использовать программы для безопасной работы, фаерволы, блокировщики (iptables, fail2ban и т. п.)</h3>

19 <p>Вы можете настроить политику подключений и пропускать те пакеты, которые удовлетворяют вашей политике безопасности. Для этого существует хороший фаервол -<strong>консольный iptables</strong>.</p>

20 <p><strong>Fail2ban</strong>, к примеру, блокирует пользователей по ssh или другим службам (можно настроить) после некоторых попыток неправильного ввода пароля. Позволяет защититься от перебора паролей автоматически. Существует много подобных интересных программ (пишите в комменты, делитесь опытом).</p>

21 <h3>9. Использовать антивирусы</h3>

22 <p>Вирусы в линукс, конечно, не так опасны, но могут причинить вред пользователям, если речь идет о сайте, и он заражен. Я использую на своем сервере<strong>clamav</strong>.</p>

23 <h3>10. Отключать неиспользуемые протоколы</h3>

24 <p>Действительно, зачем они нам, если косвенно могут предоставлять опасность? Лучше их отключить, например,<strong>IPv6</strong>, если не используем.</p>

25 <h3>11. Дополнительную авторизацию для служб, которые вещают в сеть, вешать на https</h3>

26 <p>Яркий пример -<strong>phpmyadmin</strong>, лучше его повесить на<strong>https</strong>, чтобы никто не перехватывал трафик с паролями, а также для большей безопасности лучше повесить на дополнительную авторизацию веб-сервера.</p>

27 <h3>12. Ограничить подключения только c<strong>localhost</strong>, если не планируется подключаться удалённо</h3>

28 <p>Например, к базе данных. Если все подключения строго с сервера, то нет смысла открывать порт и вещать в сеть, лучше запретить внешние подключения в конфигурации базы данных.</p>

29 <h3>13. Авторизация ssh по ключу, ограничение доступа</h3>

30 <p>Пароли можно подобрать, а ключ, он ключ.<strong>Авторизация ключом безопаснее</strong>. Если юзер нужен вообще для определённых целей, но не нужен для ssh, лучше его запретить для этого юзера или черутить.</p>

31 <p>Есть ещё программа<strong>jailkit</strong>, как раз позволяет черутить. Но она не очень-то и гибкая, я вам скажу, навязывает свою структуру и запирает пользователя строго в домашнем каталоге. Но попробовать стоит. Также, если предполагается подключение только узкого круга лиц, стоит ограничить его для подключения строго с определенных ip-адресов.</p>

32 <h3>14. Регулярный бэкап</h3>

33 <p><strong>Не бывает ничего безопасного</strong>. Лучше настроить регулярный бэкап. При этом так, чтобы данные дополнительно хранились на сторонних ПК либо на облачных сервисах.</p>

34 <p><em>Есть что добавить? Пишите в комментариях!</em></p>