Нет никаких причин для того, чтобы держать в сети незащищённые системы. Целость и сохранность ваших данных напрямую зависит от того, насколько ваши компьютеры надёжны и защищены. Пять несложных методов, описанных в этой заметке, могут в некоторых случаях существенно повысить уровень безопасности отдельных систем, а значит, и всей ваши сети в целом. Сегодня с программе: блокировка учётных записей, ограничение использования cron'а, блокировка доступа к службам, отключение root-доступа к SSH и смена TCP-порта SSH-сервера.
Блокировка учётных записей
Автоматическая блокировка учётных записей при нескольких неудачных попытках входа в систему иногда добавляет головной боли системным администраторам, ввиду того, что не всякий пользователь утруждает себя запоминанием собственного пароля с первого раза. С другой стороны, функция автоматической блокировки учётных записей позволяет администраторам вовремя выявить некоторые попытки несанкционированного доступа к системе и своевременно заставить пользователя сменить пароль.
Обычно удалённая система разрывает соединение после трёх неудачных попыток входа в систему. Однако, вы можете сразу же подключиться заново и продолжить попытки входа. Разрешая подобное поведение системы, вы делаете её более уязвимой к брутфорс-атакам. Не обходите стороной этот момент и настройте блокировку учётной записи после определённого количества неудачных входов в систему. Я обычно устанавливаю порог равным трём неудачным попыткам.
Добавьте следующие строка в файл /etc/pam.d/system-auth:
auth required /lib/security/$ISA/pam_tally.so onerr=fail no_magic_root
account required /lib/security/$ISA/pam_tally.so per_user deny=3 no_magic_root reset
Если в вашем дистрибутиве указанно файла не обнаружится, тогда вместо него можно использовать файл /etc/pam.d/login.
Ограничение Cron
В многопользовательских системах хорошим решением будет ограничить возможность использования планировщика cron только суперпользователем root. Если какие-то пользователи системы нуждаются в нём, добавьте соответствующие учётные записи в файлы /etc/cron.allow и /etc/at.allow. Если вы будете самостоятельно создавать эти файлы, то также должны быть созданы ещё два файла: /etc/cron.deny и /etc/at.deny. Они могут быть пустыми, но обязательно должны присутствовать. Не создавайте файл /etc/cron.deny прежде, чем будет создан /etc/cron.allow и в него будут добавлены нужные учётные записи, поскольку присутствие в системе пустого /etc/cron.deny разрешит всем пользователям пользоваться командой crontab. То же самое касается и планировщика at.
Добавив только учётную запись root в файлы /etc/cron.allow и /etc/at.allow, вы настроите систему так, что управлять заданиями планировщиков сможет только суперпользователь. Затем, если нужно, добавьте таким же образом (по одной учётной записи в строке) всех остальных пользователей системы, которым необходимо предоставить возможность создавать задания.
Запрещаем, запрещаем и ещё раз запрещаем
«Запретить всё» звучит несколько угрожающе, не так ли? Однако с точки зрения безопасности системы это является вполне оправданной политикой. Специалисты по безопасности рекомендуют использовать файл /etc/hosts.deny для того, чтобы закрыть доступ извне отовсюду сразу ко всем службам в системе. Одна простая инструкция и к вашей системе больше никто не достучится по сети:
#
# hosts.deny This file describes the names of the hosts which are
# *not* allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow. In particular
# you should know that NFS uses portmap!
ALL: ALL
Если вы редактируете файл /etc/hosts.deny, зайдя в систему через SSH, то не завершайте сессию, пока не добавите адрес хоста, с которого заходите, в файл /etc/hosts.allow. В противном случае, вы больше не сможете подключиться к системе, и вам придётся заходить с консоли, чтобы исправить ситуацию. Затем отредактируйте файл /etc/hosts.allow так, чтобы разрешить доступ только тем хостам/сетям, которым этот доступ действительно необходим. О формате файла и подробнее можно узнать из man hosts.allow.
Отключение root-доступа через SSH
Возможность захода в систему через SSH от имени root имеет одну очень неприятную особенность: очень сложно, а иногда невозможно узнать, какие команды, кем и когда запускались от имени привилегированного пользователя. Лучшим выходом из этой ситуации будет разрешение пользователям на заход по SSH только под своими учётными записями. И уж если кому нужен привилегированный доступ, то для этого существуют su и sudo. Для того, чтобы root не мог регистрироваться в системе по SSH, достаточно одной строки в файле конфигурации /etc/ssh/sshd_config:
Смена порта SSH-сервера
«Пересадив» SSH-сервер на другой, нестандартный TCP-порт, вы избавите вашу систему от немалой доли взломщиков, использующих «традиционные» методы атак. Многие рекомендуют изменять номер занимаемого SSH порта на что-то, вроде 2022 или 9922 (вроде как, легче запомнить). Я, в свою очередь, не рекомендовал бы вам придерживаться такой тактики. Лучше всего брать номер вообще «с потолка» и желательно, чтобы в нём не было двух повторяющихся подряд двоек.
Для того, чтобы сменить номер занимаемого демоном SSH порта, откройте файл /etc/ssh/sshd_config, найдите директиву Port, уберите комментирующую решётку, если она там есть, и укажите нужный номер порта:
Не забудьте после этого перезапустить SSH-сервер, а также исправить соответствующие правила брэндмауэра, если таковые имеются.
