четверг, 25 декабря 2008 г.

OpenSSH: Fake Banner

Конечно, хорошо пользоваться различными сканерами безопасности, которые позволяют определить ОС на удаленном хосте, который является целью Вашего pentesting'а. Но иногда злоумышленнику достаточно прочитать баннер сервиса (отметим, что пакеты GNU/Debian очень любят дописывать в свой баннер версию самой операционной системы). Например, в сконфигурированном нами OpenSSH баннер выглядит следующим образом
SSH-2.0-OpenSSH_4.3p2 Debian-9etch3

Прочитать этот баннер злоумышленник может, подсоединившись с помощью утилиты telnet к 8022 порту сервера.
Тогда перед системным администратором встает задача модифицировать баннер OpenSSH сервера.

Подготовка площадки
Сначала убедимся, что в файле /etc/apt/sources.list содержится запись на deb-src репозитарий.
root@cave:~# cat /etc/apt/sources.list | grep deb-src
#deb-src http://security.debian.org/ etch/updates main contrib
deb-src ftp://debian.sectorb.msk.ru/debian/ etch main
deb-src ftp://debian.sectorb.msk.ru/debian-security/ etch/updates main
Предполагаем, что в системе установлены пакеты up-to-date, если нет, то в целях обеспечения безопасности пакеты требуется обновить.
Если у Вас не установлены пакеты для сборки/пересборки .deb пакетов, то требуется выполнить следующую команду.
root@cave:~# apt-get install build-essential dpkg-dev debhelper devscripts fakeroot
В моем случае, так как установка производилась с netinstall дистрибутивом, требуется установить дополнительные пакеты (листинг только для build-essential)
The following extra packages will be installed:
binutils cpp cpp-4.1 dpkg-dev g++ g++-4.1 gcc gcc-4.1 libc6-dev libssp0 libstdc++6-4.1-dev linux-kernel-headers make patch
Подтвердите установку выбрав Y (Do you want to continue [Y/n]? Y), но прежде внимательно прочтите, не требуется ли apt-get (или aptitude) удалить нужные вам пакеты
The following NEW packages will be installed:
binutils build-essential cpp cpp-4.1 dpkg-dev g++ g++-4.1 gcc gcc-4.1 libc6-dev libssp0 libstdc++6-4.1-dev linux-kernel-headers make patch
0 upgraded, 15 newly installed, 0 to remove and 0 not upgraded.
Need to get 14.7MB of archives.
Также необходимо установить все библиотеки, которые необходимы для создания пакета, который Вы хотите модифицировать, а именно нужно выполнить команду
root@cave:~/openssh-4.3p2# apt-get build-dep openssh-server

Модификация исходников
Чтобы скачать исходники openssh-server нужно выполнить следующую команду
root@cave:~# apt-get source openssh-server
В результате ее выполнения в директории, откуда была запущенна команда появятся несколько файлов, в моем случае
root@cave:~# ls -la | grep openssh
drwxr-xr-x 7 root root 12288 2008-12-25 15:45 openssh-4.3p2
-rw-r--r-- 1 root root 275859 2008-09-17 01:02 openssh_4.3p2-9etch3.diff.gz
-rw-r--r-- 1 root root 1310 2008-09-17 01:02 openssh_4.3p2-9etch3.dsc
-rw-r--r-- 1 root root 920186 2006-05-12 16:17 openssh_4.3p2.orig.tar.gz
Если почитать немного исходники, а именно файлы openssh-4.3p2/version.h и openssh-4.3p2/debian/rules (можете добавить себе памятку, что debian/rules - это скрипт, который осуществляет сборку пакетов, иными словами, это Makefile), то становится понятным, как формируется баннер OpenSSH сервера. Номер версии и параметр PORTABLE (в данном случае приставка p2 в названии пакета) сервера определяется в version.h
#define SSH_VERSION "OpenSSH_4.3"
#define SSH_PORTABLE "p2"
Название дистрибутива в version.h содержится в
#define SSH_EXTRAVERSION
определяется данный параметр в файле rules

SSH_EXTRAVERSION := Debian-$(shell dpkg-parsechangelog | sed -n -e '/^Version:/s/Version: //p' | sed -e 's/[^-]*-//')
Чтобы изменить баннер достаточно несколько модернизировать файл openssh-4.3p2/version.h (в общем случае openssh-x.xx/debian/), исправив значение SSH_RELEASE, например, так
/* #define SSH_RELEASE SSH_VERSION SSH_PORTABLE SSH_EXTRAVERSION */
#define SSH_RELEASE "OpenSSH_0.9beta OpenBSD3.1"
Необходимо также внести изменения в changelog (чтобы при обновлении репозитария наши изменения не были затерты).
Чтобы сделать это можно поступить двумя способами.
  1. Открываем файл openssh-4.3p2/debian/changelog любимым текстовым редактором и правим первую строку - необходимо немного изменить название пакета, я бы сделал следующим образом
    openssh (1:4.3p2-9etch3FakeBanner) stable-security; urgency=high
    Этот способ прост, но он правильнее выбрать второй, так как он приучает к хорошему тону, красивому стилю и т.д.
  2. Находясь в директории модифицируемого пакета (в моем случае openssh-4.3p2), запускаем команду
    dch -i
    которая откроет файл debian/changelog для редактирования в текстовом редакторе по-умолчанию. Разница с 1-ым способом в том, что сразу будут сформированы блоки, согласно правилам описания модификаций пакетов (с данными правилами можно ознакомиться здесь). Ниже приведен мой пример записи в changelog
    openssh (1:4.3p2-9etch3FakeBanner) stable-security; urgency=low
    * only fake banner
    -- gurza Thu, 25 Dec 2008 16:38:41 +0300
Установка OpenSSH Fake Banner
Теперь необходимо собрать модифицированный пакет (полный мануал по сборке/пересборки пакетов GNU/Debian можно найти по адресу http://wiki.debian.org/DebianRussian/DebinstPackages и http://gq.net.ru/2007/03/16/building-deb-packages/). Находясь в директории модифицируемого пакета (в моем случае openssh-4.3p2), выполняем
root@cave:~/openssh-4.3p2# dpkg-buildpackage -rfakeroot
и откидываемся на спинку кресла. Все таки, имхо, GNU/Debian это дистрибутив для ленивых системных администраторов, которые не любят ждать выполнения ./configure && make && make install. Ну ради изменения баннера, или ради какой-нибудь более высокой цели подождать иногда приходится. Результатом выполнения данной команды будут deb пакеты в дирриктории выше.
Удаляем старый пакет OpenSSH Server (также придется временно удалить и клиента) командой
root@cave:~# dpkg -r openssh-server openssh-client
Удаление производится в смысле deinstall
deinstall
The package is selected for deinstallation (i.e. we want to remove all files, except configuration files).
То есть удаляются только бинарные файлы, а файлы конфигурации и сгенерированные ключи остаются на месте. Теперь необходимо установить модифицированные пакеты
root@cave:~# dpkg -i openssh-server_4.3p2-9etch3FakeBanner_amd64.deb openssh-client_4.3p2-9etch3FakeBanner_amd64.deb
Проверим теперь баннер OpenSSH сервера
root@cave:~# telnet localhost 8022
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_0.9beta OpenBSD3.1
^]
telnet> quit
Connection closed.
Все работает именно так, как мы и хотели.


Читать дальше...

вторник, 23 декабря 2008 г.

OpenSSH: установка и конфигурирование sshd

Официальный сайт: 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 (самое, на мой взгляд, интересное).





Читать дальше...

Мой блог начал свое существование...

Нужно запомнить или как-нибудь пометить этот день в календаре, сегодня начал существовать мой блог. Здесь я буду публиковать свои креативы по администрированию linux серверов, кодингу (больше всего меня интересует сетевое программирование под linux на C/C++, но профессиональная деятельность также связана с программированием на PHP, Java), а также по информационной безопасности...
Читать дальше...