Официальный сайт:
http://openssh.org/
OpenSSH это свободно распространяемая версия утилиты, позволяющей создавать SSH соединения. Те пользователи, которые пользуются telnet, rlogin и прочими программами передачи файлов, возможно, даже не понимают, что их пароль передается через незашифрованные соединения Интернет или локальной сети, поэтому злоумышленник может его перехватить. Их незнание ничего не изменяет, это реальность. OpenSSH шифрует весь трафик, включая и пароли, чтобы эффективно устранить прослушивание каналов, hijacking и другие атаки. Кроме того, OpenSSH предоставляет возможность безопасного создания туннелей и реализует несколько различных методов аутентификации, поддерживает все версии протокола SSH.
На русской версии сайта openSUSE (http://ru.opensuse.org/OpenSSH) OpenSSH переводят, расшифровывают как открытый безопасный Shell. Но я несколько не согласен с этим переводом. Правильнее будет сказать, что OpenSSH – это OpenBSD Security Shell, то есть, действительно, безопасный Shell разработанный программистами команды OpenBSD. Поэтому утилита OpenSSH заслуживает как минимум внимания, ведь она стала стандартом не только для операционных систем семейства *BSD, но для GNU/Linux, да и вообще для всех *nix.
Установка OpenSSH в GNU/Linux Debian
Для установки, что неудивительно, нам потребуются рутовские права. Вначале убедимся, что пакет сервера OpenSSH еще неустановлен.
root@cave:~# dpkg -l | grep openssh
ii openssh-client 4.3p2-9etch3 Secure shell client, an rlogin/rsh/rcp repla
Как видно из листинга, приведенного выше, на моем сервере сейчас стоит только клиент. Ищем нужный пакет сервера.
root@cave:~# apt-cache search openssh
Данный запрос выведет относительно небольшой список, из которого нам нужен только
openssh-server - Secure shell server, an rshd replacement
Устанавливаем его
root@cave:~# apt-get install openssh-server
Установщик сообщит нам, что пакет openssh-server нуждается в установке пакета openssh-blacklist (если, конечно, он не был установлен ранее). Соглашаемся на установку openssh-blacklist. После установки пакетов сразу запустится процесс генерации ключей для сервера OpenSSH, что упрощает процесс конфигурирования.
Собственное все, процесс установки завершен. Чтобы убедиться, что OpenSSH сервер запущен, посмотрим, какие порты открыты на сервере и какие сервисы их прослушивают.
root@cave:~# netstat -tanp | grep LISTEN
tcp6 0 0 :::22 :::* LISTEN 4098/sshd
Из листинга становится понятным, что открыт 22 порт на всех сетевых интерфейсах. Прослушивает его sshd, pid (process identify – номер процесса) его 4098. Нас, как привередливых администраторов, уже сейчас не должно устраивать то, что сервис доступен на всех интерфейсах (возможно, что в целях безопасности администратор должен получать доступ только с определенных локальных интерфейсов), а также то, что используется неактуальный (по крайней мере, для меня) протокол tcp6 по верх tcp4. Поэтому переходим к конфигурированию под себя нового сервиса.
Конфигурирование сервера OpenSSH (sshd)
Конфигурационный файл: /etc/ssh/sshd_config
Открываем конфигурационный файл сервера любимым текстовым редактором и начинаем его править. Возможно, я повторю всем известную истину, но… Человек, который установил на свой персональный компьютер, ноутбук или сервер операционную систему GNU/Linux должен прийти к тому, что вначале нужно искать ответ на свой вопрос в мануале, который идет вместе с дистрибутивом. Тонкий намек на это содержится в первых строках конфигурационного файла.
# Package generated configuration file
# See the sshd(8) manpage for details
Поэтому, если что-то не ясно сначала лучше набрать
root@cave:~# man 8 sshd
и уже из него узнать, что есть sshd_config(5). В идеале привычка читать чужие мануалы и искать в них ответ должна привести к желанию и реализации написания собственных понятных, полезных мануалов к разрабатываемым программным средствам.
Общие настройки сервера sshd
Port 22
Традиционно для SSH-соеднинений используется TCP-порт под номер 22. Чтобы избежать брутфорс атак изменим порт на 8022. В действительности, это избавит нас только от бездумных сетевых сканеров, которые ищут открытый 22-ой TCP-порт, а потом пытаются подключиться к сервису удаленного доступа. Если Ваш сервер станет целью атаки человека, то он сможет обнаружить нужный порт. С другой стороны на 22-ой порт в дальнейшем можно будет повесить honeypot (утилиту, которая будет фиксировать попытки соединений и выполнять в ответ определенные действия, например, добавлять в черный список ip-адреса предполагаемых злоумышленников). Поэтому меняем порт на 8022.
Port 8022
Чтобы отучить сервер OpenSSH использовать tcp6 добавим в конфигурационный файл запись.
AddressFamily inet
Если значение AddressFamily не указано в конфигурационном файле, то оно принимается равным any (то есть сервер работает и с протоколами IPv4 и IPv6). Установленное значение inet укажет серверу работать только с протоколами IPv4.
На данный момент существуют стабильные версии прокола SSH с номерами 1.3, 1.5 и 2.0 Правда проколы первой версии считаются недостаточно защищенными, поэтому можно смело отказаться от поддержки их нашим сервером. (Безопасности и уязвимости протоколов SSH будет посвящена отдельная статья.)
Protocol 2
Проблем с клиентами, которые поддерживают прокол 2-го семейства, возникнуть не должно. Под *nix можно использовать ssh (клиент из пакета OpenSSH), а под Windows, я советую, пользоваться утилитой putty (скачать можно с http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html).
Чтобы ограничить возможности злоумышленников укажем только те сетевые интерфейсы, с которых нам требуется получать удаленный доступ. Если Вы настраиваете локальный сервер, то обратите особое внимание на возможность выбора сетевых интерфейсов.
ListenAddress 0.0.0.0
Мне требуется иметь доступ и с локальной сети и с любой точки мира. Поэтому я указываю в конфигурационном файле качестве интерфейса – все интерфейсы.
Казалось бы безобидная функция проверки работоспособности состояния клиента KeepAlive при перехвате пакетов и анализе содержания злоумышленником может приводить к успешной реализации на отказ обслуживания (Denial of Service), поэтому рекомендуется отключать данную опцию
TCPKeepAlive no
Специалисты по сетевой безопасности рекомендуют использовать специальные опции (поддерживаются только для 2-ой версии протокола SSH), а именно
ClientAliveInterval 20
ClientAliveCountMax 3
Опция ClientAliveInterval определяет промежуток времени в секундах, по истечению которого клиенту отправляется специальное сообщение, позволяющее проверить подключен клиент, или соединение было неожиданно оборвано (в том смысле, что сервер не получил сообщение о закрытии соединения). Опция ClientAliveCountMax определяет количество сообщений, после отправки которых без получения подтверждения о получении считается, что клиент отвалился от сервера.
Настройки разграничение доступа (Authentication)
Перейдем теперь к настройкам разграничения доступа к серверу. Первым делом запретим пользователю root получать удаленный доступ по SSH (злоумышленнику в общем случае, не известно, какой логин у Вас в системе, поэтому чаще всего брутфорс атака проводится на стандартных пользователей, например, root, journal, admin).
PermitRootLogin no
Если потребуется привилегии суперпользователя, то Вы сможете воспользоваться утилитой su или sudo.
Запретим доступ к серверу с пустым паролем
PermitEmptyPasswords no
Включим, так называемый, StrictModes
StrictModes yes
Это укажет sshd проверить права и владельца домашнего каталога пользователя, который пытается получить удаленный доступ к системе, перед тем как вызвать login.
LoginGraceTime 60
Означает, что сервер разорвет соединение с пользователем по истечению 60 секунд, если пользователь не залогинится.
Значение переменной MaxStartups я установил следующим
MaxStartups 3:30:10
Это означает, что сервер разорвет соединение с пользователем после 3 (первый параметр) неудачных попыток залогиниться с вероятностью 30% (второй параметр), которая будет линейно увеличиваться при следующих попытках, и сервер оборвет соединение с клиентом с вероятностью 100% при 10 (третий параметр) неверных попытках залогиниться. Все это происходит во временном промежутке определенном параметром LoginGraceTime. Если среди администраторов Linux систем есть любители теории игр, или тервера, то они могут создать какую-нибудь игровую модель и поэкспериментировать.
Очень эффективно для разграничения удаленного доступа между пользователями, зарегистрированными на сервере, использовать переменные AllowUsers, AllowGroups. Как следует из названия AllowUsers определяет список тех и только пользователей, которым администратор разрешает подключаться к серверу sshd. AllowGroups – соответственно определяет группы. Рассмотрим несколько примеров
AllowUsers gurza admin
В данном примере удаленный доступ разрешается только пользователям с логинами gurza и admin (логины перечисляются через пробел, запитые не используются).
AllowUsers gurza@172.16.16.1
Доступ разрешается только пользователю gurza, причем успешно залогиниться он может только с компьютера, имеющего IP-адреса 172.16.16.1
В своем конфигурационном файле я установил
AllowGroups staff
Отметим, что в конфигурационном файле sshd также можно указывать значения переменных DenyUsers и DenyGroups.
Опознавать пользователя, который пытается получить удаленный доступ, будет по текстовому паролю и ключам, то есть нам необходимо включить опции
PasswordAuthentication yes
[todo] Аутентификация по ключу
Остальные варианты аутентификации отключим. Выключим опцию ChallengeResponseAuthentication, задав
ChallengeResponseAuthentication no
Данная опция может понадобиться, если для аутентификации пользователя будут использоваться pam-модули. Для меня это излишнее, поэтому я отключаю. Если Вам вообще ничего не говорит словосочетание pam-модуль, то тоже смело отключайте, на функциональности sshd не отразится.
Аутентификации по GSSAPI и Kerberos я тоже пользоваться не буду (заметим, что возможно использовать только для 2-го протокола SSH), поэтому отключаю.
GSSAPIAuthentication no
KerberosAuthentication no
Для любознательных оставлю ссылки на ресурсы, где можно прочитать про Kerberos, GSSAPI
Прежде всего RFC:
http://tools.ietf.org/html/rfc4120
http://tools.ietf.org/html/rfc4121
http://tools.ietf.org/html/rfc1510 - уточнения некоторых аспектов протокола
И свободная энциклопедия: http://en.wikipedia.org/wiki/Generic_Security_Services_Application_Program_Interface
http://ru.wikipedia.org/wiki/Kerberos
Аналогично поступаем и с HostBase аутентификацией
HostbasedAuthentication no
Вообще очень хорошим правилом является отключение всего лишнего, что не планируется использовать. Во-первых, с сервера снимается лишняя нагрузка, а во-вторых, наш сервер не упадет или не будет взломан атаками на сервисы, которые мы отключили (очень логично).
Журналирование (logging)
Рассмотрим опции журналирования (logging, по-простому ведение логов, журналов сообщений) сервера sshd. В своем конфигурационном файле я использовал следующие значения
SyslogFacility AUTH
LogLevel INFO
Опция SyslogFacility определяет, список каких событий администратор хочет видеть в лог-файле сервера. Меня интересует только авторизация (а вообще доступны: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7). Опция LogLevel определяет уровень детализации сообщений. Практика показала, что самым оптимальным (в смысле, стремление к единице отношения информативность информации и ее количество) является пара AUTH, INFO для соответствующих опций.
Дополнительные настройки (Additional)
Теперь перейдем к дополнительным настройкам сервера sshd. Сначала рассмотрим опции, которые позволяют выводить полезную информацию при подключении к серверу.
Banner /etc/ssh/banner
PrintMotd no
PrintLastLog yes
Опция PrintMotd выводит при подключении к sshd так называемое сообщение дня, что на самом деле является содержимым файла /etc/motd. Опция PrintLastLog очень полезна, так как она отображает информацию о том, когда Вы последний раз и с какого хоста заходили на сервер. Иногда она позволяет определить, что кто-то подобрал Ваш пароль и теперь может как угодно распоряжаться Вашим аккаунтом. Опция Banner определяет место положения файла-баннера, который будет выведен на экран, при попытке подключиться к серверу sshd. Обязательно убедитесь в существовании файла, указанного в качестве параметра опции Banner.
Этот текст не является полностью законченным, в ближайшее время (пара дней) я планирую добавить мануала о генерации ключей и использования авторизации с помощью rsa-ключей. Продолжая тему гибкости и мега функциональности OpenSSH я напишу парочку статей о том, как можно защитить (защифровать) данные других приложений используя OpenSSH и о создании туннелей средствами OpenSSH (самое, на мой взгляд, интересное).
Читать дальше...
