Содержание
Напомню, что SSH – Secure Shell – безопасный терминал, намного более безопасный, чем какой-нибудь там TELNET. К слову сказать, настраиваю свои сервера как раз через SSH.
Настроить его на Linux-машине элементарно просто, ssh сервер ubuntu или вот на Debian. Будем считать, что это не проблема.
Теперь, как же можно защитить наш эсэсаш?
Запрещаем root-logon
Суть этого метода, что в настройках сервера мы делаем невозможным аутентификацию суперпользователя root. Таким образом, даже если подберут пароль на нашего пользователя (или иным способом захватят наше подключение), ничего это им не даст кроме домашнего каталога и привилегий пользователя. Потеря же рутового аккаунта может стать фатальной.
Если подберут юзера, то им придется затем ковырять и рута, а два аккаунта для взлома – это лучше, чем один.
Кроме того, я встречал рекомендацию поменять логины. Например, завести пользователя вроде master с uid:gid 0:0, а пользователю rootдать uid:1001. И даже если злоумышленник сможет получить доступ к “руту”, его постигнет жесткое разочарование в том, что прав у него – как у обычного юзера. Думаю, что 90% всех систем имеют рута – суперюзером, остальные переименовались. Лишняя палка в колёса взломщикам не помешает.
Лезем в файл /etc/ssh/sshd_config
Меняем порт на нестандартный
Суть этого метода в том, что сервер ssh будет слушать не 22-ой порт, а какой-нибудь ещё. Многие зловреды сканируют сеть тем же nmap-ом и найдя открытый 22-ой порт не без основания считают, что там поднят ssh (а на большинстве серверов он поднят) и предпринимают попытки взлома (подбора паролей по словарю). Зачем же нам лишний раз искушать судьбу?
Настроки в файле /etc/ssh/sshd_config
Используем аутентификацию ключами
Это более прогрессивный метод аутентификации, чем интерактивный логин:пароль. Я подробно расписывал этот метод по ссылке в начале статьи, суть в том, что мы формируем пару ключей (открытый и закрытый). Ключи генерируются на клиенте. Затем открытый ключ заливаем на сервер в специальный файл. (/home/user/.ssh/authorized_keys)
Очень советую прочитать статью, так как важно не перепутать закрытый и открытый ключи. А так же, что ключи есть на сервер и на пользователя. Так вот, если в хранилище сервера есть публичный ключ пользователя, то этот пользователь при коннекте с клиента сможет войти без пароля.
Port Knocking
Суть этого метода в том, что специальным образом мы постучимся (попытаемся приконнектиться) на определенный порт сервера, и только после этого нам откроется ssh-порт.
Допустим, мы настраиваем knockd на сервере так, что при получении пакетов на интерфейс:
udp:5341, tcp:7717, udp:1234 с интервалом в 5 секунд
выполнилась определенная команда, например, добавление IP, с которого пришли пакеты в белый список. Я как-нибудь напишу статью об этом в ближайшее время, всвязи с участившимся случаями брутфорса со стороны Китая
Разрешаем доступ только с определенных IP
Очень высокая степень защиты, но уменьшается гибкость. Суть в том, что мы просто на уровне файрволла разрешаем доступ на 22 (или другой порт) только с определенного адреса (диапазона), а лучше вообще извне запрещать. Сразу отсекается львиная доля атак. Ну а если надо будет настроить что-то находясь в отпуске? Тогда сочетание с предыдущим решением, постучать в бубен порт.
Ну и в завершении, куча лулзов, как незатейливый хакер попался в ханипот
Comments: