HTML Guardian де-обфускация

Задача. Есть javascript с защитой от дурака, но страница прошла обфускацию с помощью продукта HTML Guardian. Необходимо расшифровать.

Все, что нужно для этого вписать в body следующий вызов

body onunload="alert(document.body.innerHTML)"

После обновления страницы можно читать код в нормальном виде.

Забавный взлом с элементами волшебства :)
Читать дальше...

Мониторинг ресурсов и информация о железе в GNU/Linux

В данной заметке содержится информация об утилитах GNU/Linux, позволяющих производить мониторинг ресурсов компьютера, а также выводить информацию об установленном компьютере "железе".

Информация о процессоре
Информацию о частоте процессоре, объеме кэша и множество другое можно получить следующим образом

cat /proc/cpuinfo

Информация о памяти в системе
Информацию об установленных планках можно получить с помощью команды

sudo dmidecode -t memory

Информация о свободной и используемой памяти в системе выводим с помощью

free

Например,

gurza@cave:~$ free
total used free shared buffers cached
Mem: 509144 502728 6416 0 13348 66424
-/+ buffers/cache: 422956 86188
Swap: 995988 494180 501808

где
total - всего доступной физической памяти. Некоторая область оперативной памяти может быть зарезервирована ядром, поэтому показатель total может быть меньше реального объема оперативной памяти.
used - используется памяти (used=total-free)
free - незадействованая память. На самом деле память задействованная в кэшах(cached) тоже является свободной и может быть использована в любое время, если есть на то нужда какого-то процесса. Работает принцип "свободная память - потерянная память".
shared - память распределенная между процессами, но по непонятной причине всегда показывает 0 :)
buffers - память используемая в буферах.
cached - память используемая для кэширования.
-/+ buffers/cache - использованная память без учета буферов и кэшей/свободная память с учётом буферов и кэшей
swap - использование swap-области


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

PHP: определение возраста

Проблема: На сайте могут регистрироваться только совершеннолетние пользователи. При регистрации нового пользователя спрашивается его дата рождения. Необходимо определить достиг пользователь совершеннолетия или нет?

Решение.
В начале необходимо обработать данные, введенные пользователем. В данном случае пользователь вводит дату в формате DD.MM.YYYY, иными словами имеем

$date="11.08.1984";

Ту часть кода, которая проверяет введенные данные пользователем на соответствие формату, я опущу. Непосредственно сама обработка данных выглядит следующим образом:

$arr = explode('.',$date);
$day = $arr[0];
$month = $arr[1];
$year = $arr[2];

Функция explode() используется для разделение строки на элементы по разделителю (первый параметр). В данном примере разделитель - точка.
Далее формируем строку, которую можно было бы передать функции strtotime(), которое возвращает метку времени в Unix.

$date1 = arr[2].'-'.arr[1].'-'.arr[0];

И вот кульминация :) На многочисленных сайтах в сети расписываются сложные функции, которые пытаются подсчитать количество високосных лет, делят, умножают... Я это сделал красиво

echo (gmdate('Y', time() - strtotime($date1)) - 1970);

З.Ы. Камень в M$ :)
PHP Manual: gmdate

The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer). However, before PHP 5.1.0 this range was limited from 01-01-1970 to 19-01-2038 on some systems (e.g. Windows).

А если почитать что писали в мануале к PHP4, например, из данного учебника.

Замечание: В семействе ОС Microsoft Windows системные библиотеки, реализующие эту функцию, содержат ошибки, поэтому функция gmdate() на этих системах не поддерживает отрицательные значения аргумента timestamp.

В операционных системах Unix/Linux эта проблема не возникает, так как системные библиотеки в этих системах реализованы корректно.

PHP не может исправить ошибки в системных библиотеках. Для решения этой и подобных проблем обращайтесь к производителю операционной системы.

Последний абзац приятно улыбнул)))

Реализация проверки даты на сайте (попросил расшарить один человек)

if (isset($_GET['bday'])) {
if (!eregi('^[0-9]{1,2}\.[0-9]{1,2}\.[0-9]{4}$', $_GET['bday'])) {
$message = 'Некорректный формат даты.
';
$message .= 'Введите пожалуйста Вашу дату рождения в формате дд.мм.гггг (например, 29.11.1985).';
} else {
$arr = explode('.',$_GET['bday']);
$day = $arr[0];
$month = $arr[1];
$year = $arr[2];

$bday = $arr[2].'-'.$arr[1].'-'.$arr[0];
if ( $bday=strtotime($bday) ) {
$bday = (gmdate('Y', time() - $bday) - 1970);
} else {
$valid = 'false';
$message = 'Некорректный формат даты.
';
$message .= 'Введите пожалуйста Вашу дату рождения в формате дд.мм.гггг (например, 29.11.1985).';
echo "[{val:'$valid',msg:'$message'}]"; exit;
}
if ( $bday>=18 ) {$valid = 'true'; $message='';
} else {
$valid='false';
$message = 'Извините, но согласно правилам регистрироваться на сайте могут только совершеннолетние.';
}
}
}

Подразумевается, что после выполнения данной проверки будет сформирован ответ в формате json, вида [{val:'$valid',msg:'$message'}]. На самом деле без полного кода проверки формы регистрации этот кусок кода нельзя просто взять и использовать. Но если кому-нибудь лень написать элементарное регулярное выражение, то можете скопировать с моей реализации :)

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

Первоначальная настройка сетевых интерфейсов

В данной статье будет рассмотрена первоначальная настройка сетевых интерфейсов (беспроводные сетевые интерфейсы не рассматриваются) в операционной система Debian GNU/Linux. Конфигурирование будет производиться путем редактирования специфичных для Debian конфигурационных файлов, а также будут приведены примеры использования профессиональной утилиты администрирования сети ip.

Установка утилиты ip
Вообще говоря, первоначальное конфигурирование сетевых интерфейсов можно легко произвести и без утилиты ip, пользуясь стандартной утилитой ifconfig, которая присутствует в каждом (думаю, что не ошибся) дистрибутиве GNU/Linux. Но помимо конфигурирования сети нашей целью будет являться освоение утилиты ip, которая, безусловно, понадобится нам впоследствии. Установка производится командой

root@debian:~# apt-get install iproute

Настройка IP-адреса сетевых интерфейсов
Прежде чем приступать к конфигурированию сети, необходимо узнать названия сетевых карт для соответствующих интерфейсов. Сделать это можно, выполнив команду

root@cave:~# dmesg | grep -i eth
r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
eth0: RTL8169s/8110s at 0xffffc20000030000, 00:0f:ea:66:40:f6, IRQ 193
eth1394: eth0: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
r8169: eth1: link up

В примере, показанном в листинге выше, все достаточно просто. В компьютере установлено только два контроллера, причем меня интересует настройка только Ethernet сетевой карты Realtek, которой соответствует сетевой интерфейс eth0. Приведу еще один пример

root@gn:~# zcat /var/log/messages.6.gz | grep -i eth
Nov 10 19:11:51 gn kernel: e100: eth0: e100_probe: addr 0xfe9fd000, irq 169, MAC addr 00:30:48:22:2B:F8
Nov 10 19:11:51 gn kernel: e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
Nov 10 19:11:51 gn kernel: e1000: eth3: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex

Во-первых, стоит заметить, что использовалась другая команда для определения соответствия сетевых карт и интерфейсов. Дело в том, что команда dmesg выводит на экран только содержание файла /var/log/messages, но так как сервер gn, листинг с которого приведен в примере, имеет uptime порядка 50 дней, то записи стоит искать в более старом файле. Сетевой интерфейс eth0 соответствует интеловской сетевой карте, встроенной на материнской плате, eth1 и eth3 – две гигабитные карты, которые когда-то использовались для соединения двух различных сегментов сети. Получив эту информацию можно переходить к настройке.

Настройка статического IP адреса
Открываем файл /etc/network/interfaces своим любимым текстовым редактором и создаем следующие записи

root@cave:~# cat /etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth1
iface eth1 inet static
address 192.168.1.11
netmask 255.255.255.0
gateway 192.168.1.1

Рассмотрим настройки более подробно. Запись auth eth0 означает, что интерфейс должен быть автоматически запущен при загрузке операционной системе.

iface eth1 inet static

Означает, что происходит конфигурирование сетевого интерфейса eth1 и что IP-адрес будет задан статическим.

address 192.168.1.11 – непосредственно IP-адрес, присваиваемый сетевому интерфейсу;
netmask 255.255.255.0 – маска сети;
gateway 192.168.1.1 – шлюз, который должен осуществлять маршрутизацию в сети.

Настройка динамического IP адреса
Рассмотрим пример файла /etc/network/interfaces, позволяющий сконфигурировать сетевой интерфейс для получения динамического IP-адреса.

root@cave:~# cat /etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth1
iface eth1 inet dchp

Легко видеть, что строка iface eth1 inet dchp определяет получение сетевого адреса по протоколу DHCP, то есть сетевой интерфейс получит динамический IP-адрес.
Замечание. Для получения динамического адреса в операционной системе GNU/Debian должен быть установлен пакет DHCP-клиента.

root@cave:~# dpkg -l | grep dhcp
ii dhcp3-client 3.0.4-13 DHCP Client
ii dhcp3-common 3.0.4-13 Common files used by all the dhcp3* packages

Замечание. Обычно, для облегчения работы пользователей компьютерной сети системный администратор настраивает DHCP сервер таким образом, чтобы он передавал адреса первичного и вторичного DNS серверов при выдачи динамического адреса. Поэтому для некоторых настройка сети ограничивается записью двух строчек в файл /etc/network/interfaces. Но не лишним будет знать, как все-таки прописать руками доверенные DNS сервера в систему.

Настройка адресов DNS-серверов
Задать адреса DNS-серверов в GNU/Debian можно в файле /etc/resolv.conf, отредактировав его в любимом текстовом редакторе. Например, так

root@cave:~# vim /etc/resolv.conf

Адреса прописываются следующим образом

nameserver 192.168.1.1
nameserver 4.2.2.2

Отметим, что записей nameserver может быть произвольное количество.

Изменение MAC-адреса сетевого интерфейса
Вопрос изменения MAC-адреса волнует, хоть это может показаться странным, многих пользователей. Очень часто провайдер делает привязку MAC-адреса сетевого интерфейса к порту управляемого свитча, чтобы ограничить количество устройств, которые пользователь услуг данного провайдера может использовать. Универсальным решением в такой ситуации для пользователя становится установка собственного активного сетевого оборудования, которое будет предоставлять доступ к ресурсам провайдерам внутренней сети пользователя. Но иногда банально не хочется звонить провайдера лишь по тому, что у пользователя появился на несколько дней, неделю новый лаптоп, с которого необходим доступ к сети. Но этим примером, конечно, не исчерпывается весь список, когда нужно сменить MAC-адрес сетевой карты.
Приведу несколько способов изменения MAC-адреса в GNU/Debian. Если требуется использовать новый MAC достаточно длительный промежуток времени, то его целесообразно задать в файле /etc/network/interfaces. Делается это следующим образом

auto eth0
iface eth0 inet dhcp
hwaddress ether 01:02:03:04:05:06

Конечно, вместо 01:02:03:04:05:06 – необходимо указать нужный Вам MAC. Отметим, что при использовании стационарного IP-адреса MAC-адрес будет прописываться точно также.
Если требуется задать MAC-адрес только для данной сессии (имеется в виду, что после перезагрузки компьютера будет использоваться MAC по умолчанию).

root@cave:~# ifconfig eth0 down
root@cave:~# ifconfig eth0 hw ether 01:02:03:04:05:06
root@cave:~# ifconfig eth0 up

Применение настроек
Чтобы настройки сетевых интерфейсов (касается внесения изменений в конфигурационные файлы resolv.conf и interfaces) вступили в силу в GNU/Debian необходимо выполнить следующую команду

root@cave:~# /etc/init.d/networking restart

Мониторинг настроек и работы сетевых интерфейсов
Для наблюдения за состоянием сетевых интерфейсов мы будем использовать утилиту ip.

root@debian:~# ip addr show

Позволяет вывести на экран сведения о всех сетевых интерфейсах системы. Для вывода информации по конкретному интерфейсу нужно использовать команду

root@debian:~# ip addr show eth0

Чтобы узнать какие используются DNS-сервера в системе, необходимо выполнить команду nslookup.

gurza@hird:~$ nslookup
> server
Default server: 193.232.114.64
Address: 193.232.114.64#53
Default server: 212.192.229.127
Address: 212.192.229.127#53

В приведенном примере на компьютере hird используются два DNS-сервера, с IP-адресами 193.232.114.64 и 212.192.229.127 соответственно. Связь осуществляется по стандартному 53 порту.
В качестве запроса в консоли nslookup можно задавать IP-адреса, чтобы получить в ответ доменное имя

gurza@hird:~$ nslookup
> 4.2.2.2
Server: 193.232.114.64
Address: 193.232.114.64#53

Non-authoritative answer:
2.2.2.4.in-addr.arpa name = vnsc-bak.sys.gtei.net.

а также доменные имена, чтобы получить в ответ IP-адреса.

gurza@hird:~$ nslookup
> gurza.ipib.msu.ru
Server: 193.232.114.64
Address: 193.232.114.64#53

Name: gurza.ipib.msu.ru
Address: 212.192.237.30

Временно перенаправить запрос к другому DNS-серверу можно следующим образом

gurza@hird:~$ nslookup
> server 4.2.2.2
Default server: 4.2.2.2
Address: 4.2.2.2#53
> lab110.imec.msu.ru
Server: 4.2.2.2
Address: 4.2.2.2#53

Non-authoritative answer:
lab110.imec.msu.ru canonical name = hird-u.imec.msu.ru.
Name: hird-u.imec.msu.ru
Address: 193.232.114.5

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

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.

Все работает именно так, как мы и хотели.


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

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), а также по информационной безопасности...
Читать дальше...