Текст книги "Спецвыпуск журнала «Хакер» 47, октябрь 2004 г."

Автор книги: Хакер Журнал

сообщить о нарушении

Текущая страница: 14 (всего у книги 21 страниц)

Хитрый тюнинг и грамотная защита / Приемы настройки сервера

Toxa (toxa@cterra.ru)

Ты поставил и настроил сервер. У тебя все работает, пользователи довольны, и теперь настало время добавить в систему ту самую изюминку, о которую, возможно, сломает зуб не один взломщик.

Тюнингуем систему

Первый шаг – обезопасить себя встроенными средствами. Общение с ядром будем проводить через sysctl – удобный интерфейс для тюнинга сетевой подсистемы. Расскажу на примере FreeBSD. В этой системе нужно обратить внимание, как минимум, на следующие переменные:

Листинг

net.inet.tcp.blackhole=2

net.inet.udp.blackhole=1

По стандарту, если на закрытый порт сервера приходит SYN-пакет, машина должна ответить RST-пакетом. Это упрощает сканирование портов, а также дает достаточное количество информации (в виде ответов от сканируемого сервера) для определения версии ОС. «Черные дыры» заставляют FreeBSD быть предельно лаконичной, не отсылая ничего в ответ на запросы к закрытым портам. Идем дальше.

Маршрутизацию от источника можно смело отключить:

Листинг

net.inet.ip.sourceroute=0

net.inet.ip.accept_sourceroute=0

Чтобы сервер не стал жертвой DoS-атаки, можно включить механизм syncookies, который служит для защиты сервера от SYN-флуда.

При серьезной атаке может не менее серьезно выручить. Выстави следующую переменную:

Листинг

net.inet.tcp.syncookies=1

Чтобы затруднить определение версии твоей ОС анализом приходящих от нее пакетов, изменим значение Time To Live:

Листинг

net.inet.ip.ttl=64

Современная система не должна отвечать на широковещательные пинги, но и по сей день существуют сети, которые могут стать источником DoS-атаки. Чтобы не попасть в их список, выставляем:

Листинг

net.inet.icmp.bmcastecho=0

Если ты хочешь отслеживать коннекты на закрытые порты твой машины, используй следующую переменную:

Листинг

net.inet.tcp.log_in_vain=1

На нагруженном сервере, правда, тебя может засыпать количеством сообщений.

Если не нужна поддержка смешного протокола T/TCP (TCP for Transactions), то пакеты с флагами SYN+FIN можно смело отбрасывать как неликвидные :). Протокол редко где используется, а потому это имеет смысл.

Листинг

net.inet.tcp.drop_synfin=1

Обманываем сканеры

Вторжение в систему начинается со сканирования – это прописная истина. Можно (и нужно) уже на этом этапе усложнить жизнь злоумышленнику. Так, пакетный фильтр OpenBSD PF имеет встроенную возможность определения и блокирования сканеров, используя технологию Passive OS Fingerprinting. Достаточно добавить правило «block quick from any os NMAP» в pf.conf, чтобы результаты работы популярного сканера nmap заставили хакера почесать затылок. Также nmap'у можно противодействовать с помощью «scrub in all» и фильтрации TCP-пакетов с особыми флагами, к примеру:

Листинг

block return-rst in log quick proto tcp all flags FP/FP

block return-rst in log quick proto tcp all flags SE/SE

block return-rst in log quick proto tcp all flags FUP/FUP

Но можно обойтись и userland-средствами. Например, утилитой portsentry.

Она открывает для прослушивания указанные TCP/UDP-порты, логирует обращения к ним и позволяет реагировать на сканирование. После скачивания с http://packetstormsecurity.nl/UNIX/IDS/ и установки portsentry правим portsentry.conf:

Листинг

TCP_PORTS="42,88,135,139,145,389,443,445,464,593,636,637,1025,1026,1027,1029,1433,3372,3389»

UDP_PORTS="»

Я указал набор TCP-портов, очень похожий на тот, что открывает Windows 2000 Server в дефолтовой установке. UDP-порты прослушивать мы не будем – их редко сканируют.

После этого имеет смыл указать хосты, чье сканирование мы будем игнорировать, например, машины из локалки. Пропиши путь к файлу со списком игнорируемых хостов:

Листинг

IGNORE_FILE="/usr/local/psionic/portsentry/portsentry.ignore»

Чтобы portsentry не занималась ненужным отображением IP-адреса в имя хоста, отключи обратный резольвинг:

Листинг

RESOLVE_HOST = «0»

Далее блокируем IP-адреса хостов, с которых производится сканирование:

Листинг

BLOCK_TCP="1»

А теперь укажи, как ты хочешь это делать. Например, добавлением правила фаервола:

Листинг

KILL_ROUTE="/sbin/ipfw add 1 deny all from $TARGET$:255.255.255.255 to any»

Также можно заносить атакующих в hosts.deny для усиления защиты демонов, использующих tcpwrappers:

Листинг

KILL_HOSTS_DENY="ALL: $TARGET$ : DENY»

Наконец, можно указать баннер, выдаваемый при подключении к порту, прослушиваемому portsentry:

Листинг

PORT_BANNER="WHOM DO YOU WANT TO HACK TODAY?»

Учти, что блокировать хосты таким образом – крайняя мера, так как есть возможность превратить network в notwork, заблокировав легитимных клиентов. В общем случае я бы не рекомендовал использовать KILL_ROUTE. У меня уже два с лишним года работает машинка, приспособленная в свое время именно для снятия подобной статистики (ради интереса). В настоящее время в hosts.deny содержится 12373 записи, и помимо злачных притонов интернета в черный список попали вполне легитимные адреса. Сервисы, работающие на том сервере, не используют tcpwrappers, так что никто не страдает. Но сам факт достоин внимания.

Меняем баннеры

Любой демон, принимающий внешние соединения, так или иначе «демонстрирует себя» баннером – однострочным приветствием, выдающимся клиенту в ответ на соединение с ним. Самый простой способ увидеть это – совершить соединение telnet'ом с сервером на порт, прослушиваемый демоном:

Листинг

[(22:42)(29.10%)(p1):~/articles/tricksec ] telnet smtp.gameland.ru 110

Trying 62.213.71.4…

Connected to smtp.gameland.ru.

Escape character is '^]'.

+OK Microsoft Exchange Server 2003 POP3 server version 6.5.7226.0 (server500.gameland.ru) ready.

Почти всегда это служебная информация, нужная для работы сервиса, но иногда – совершенно бесполезная и даже вредная. Разные сервисы ведут себя по-разному: кто-то ограничивается лаконичным именем хоста и типом сервиса (domain.com ESMTP), а кто-то выдает себя с потрохами, раскрывая свое имя и версию. Если в нашем примере будет найдена уязвимость в определенных версиях Exchange, то взломщик за пару минут напишет баннер-граббер, который соединяется с хостами и снимает с них версию Exchange. Таким нехитрым способом можно легко найти уязвимый хост. Теперь понятно, почему смена баннера имеет смысл: она позволяет скрыть версию сервиса или даже ввести в заблуждение взломщика. По этой причине многие демоны имеют возможность считывать баннер прямо из конфига. Если же нет – мы в мире OpenSource и не поленимся залезть в исходники. Учти, смена баннера не даст нам полной иллюзии «другого» сервиса. Шанс определить демона и, например, отличить Apache от IIS все равно остается – по поведению программы в ответ на различные запросы, коду ошибок, специфичных сообщений, формированию заголовков писем (в случае SMTP-сервера) и т.п., так как жестких стандартов поведения того же почтового сервера нет и каждый реализует протокол по-своему. Однако от примитивных механизмов определения демона мы защитимся (подробнее про fingerprinting читай в другой статье этого номера).

OpenSSH

Самый популярный пакет для удаленного администрирования по протоколу ssh, хоть и написанный весьма компетентными хакерами из OpenBSD team, но имеющий длинную историю взломов. Баннер в конфиге не выставляется, так что будем править сорцы. Найди в файле version.h следующие строки:

#define SSH_VERSION «OpenSSH_3.8p1»

Их и следует изменить. Полностью удалять строку не нужно, согласно стандарту, сервер обязан выдать версию ssh-протокола, а затем – имя демона. Я советую ограничиться удалением версии openssh, но ты можешь проявить фантазию. Затем собирай openssh как обычно.

Apache

Это классика. Смена баннера самого популярного web-сервера – весьма частое развлечение админов. Здесь тоже не обойтись без правки исходных текстов. В каталоге с исходниками найди файл src/include/httpd.h, а в нем – следующие строки:

Листинг

#define SERVER_BASEPRODUCT «Apache»

#define SERVER_BASEREVISION «1.3.29»

Теперь меняй их на Microsoft-IIS 4.0 и коллекционируй сигнатуры старых добрых unicode-атак :). В Apache 2.0.x надо править файл include/ap_release.h, строки:

Листинг

#define AP_SERVER_BASEPRODUCT «Apache»

#define AP_SERVER_MAJORVERSION «2»

#define AP_SERVER_MINORVERSION «0»

#define AP_SERVER_PATCHLEVEL «50»

Postfix

Этот удобный и (относительно, как и все в этом мире) безопасный SMTP-сервер позволяет указать баннер прямо в конфиге, main.cf:

$smptd_banner = $mydomain ESMTP MyCoolServer

Sendmail

По умолчанию sendmail выдает слишком много информации. В нем часто находят уязвимости, так что светить версией – себе дороже. Можно поправить sendmail.cf:

O SmtpGreetingMessage=$j ESMTP InsecureMailserver

Или sendmail.mc:

define(`confSMTP_LOGIN_MSG', `$j ESMTP UnsecureMailserver')

BIND

Named – популярный DNS-сервер от Internet Software Consorcium. Известен прежде всего своей историей уязвимостей, так что рассказать миру о том, какая у тебя версия named – значит жить как на иголках до следующей Security Advisory. Правь named.conf, в глобальной секции options {} пиши:

version «Microsoft DNS»;

VsFTPd

Это чрезвычайно безопасный ftp-сервер с поддержкой ssl-соединений. Указать баннер можно прямо в vsftpd.conf:

ftpd_banner=mydomain.com Microsoft FTP Service (Version 5.0)

BSD FTPd

Во Free/Net/OpenBSD можно поправить приветствие стандартного ftpd. Для этого нужно найти в файле /usr/src/libexec/ftpd/ftpd.c строчку:

reply(220, «%s FTP server (%s) ready.», hostname, version);

Она может встретиться несколько раз, так, во FreeBSD за баннер отвечает конструкция:

Листинг

if (hostinfo)

reply(220, «%s FTP server (%s) ready.», hostname, version);

else

reply(220, «FTP server ready.»);

В обоих случаях в выводе строки можно написать, что душа пожелает (а можно поступить более 31337-но – изменить значение hostinfo на 0 перед вышеуказанным блоком if).

Эти нехитрые трюки, конечно, помогут тебе изменить поведение сервера, но они не закрывают уязвимостей в сервисах, так что маскировка не лишает тебя главной задачи – патчить, патчить и еще раз патчить. Желаю тебе как можно реже испытывать в этом необходимость.

Мнение эксперта

Андрей «Andrushock» Матвеев, редактор рубрики «Unixoid» журнала «Хакер»:

«Идеальной или совершенной защиты не бывает. Мы можем только стремиться к обеспечению должного уровня безопасности за счет своевременного обновления программного обеспечения, грамотного разграничения доступа, корректной настройки интернет-служб и, конечно же, предотвращения утечек информации – здесь я подразумеваю весь спектр предпринимаемых действий начиная от сокрытия сервисных баннеров и заканчивая воспрепятствованию перехвату конфиденциальных данных организации. Очень многое зависит от системного администратора, от его политики, опыта, навыков работы и знаний. Известны случаи, когда правильно сконфигурированные серверы на базе Red Hat Linux могли похвастаться тысячедневными аптаймами, в то время как хосты под управлением OpenBSD не выдерживали и недельного натиска глобальной сети. За счет открытого исходного кода можно каждый день изменять поведение системы и/или стека TCP/IP, главное – придерживаться одного простого правила: не ломать стандарты, задокументированные в RFC.

Маршрутизация от источника – механизм, с помощью которого внешний хост может получить информацию о внутренних адресах сети. Механизм старый, мало где использующийся, кроме проблем, как правило, ничего не несет.

SYN-флуд – переполнение очереди открытых соединений в состоянии SYN-sent.

Утилита portsentry проверена временем – она написана еще в 1998 году.

Узнать конкретную версию какого-либо сервиса не из баннера значительно труднее.

Логи для умных / Система log-файлов для *nix-систем

the_Shadow (theshadow@sources.ru)

Логи – органы чувств администратора в чреве системы. В этой статье я постараюсь рассказать тебе о работе системы ведения log-файлов, ее грамотной настройке и о том, что из нее вообще можно выжать.

Теория

При старте системы запускается механизм протоколирования, состоящий из двух подсистем ведения протокола – ядра и процессов. Собственно, работа их начнется сразу после того, как syslogd и klogd стартанутся в процессе init. Тогда создастся сокет /dev/log, на который в дальнейшем смогут поступать логи с удаленных машин, также откроются файлы, описанные для логирования в твоей системе.

С этого момента система будет ждать твоих логов.

klogd

Сообщения ядра – это не самое важное, но упомянуть о них я обязан. Ты наверняка встречался с этими сообщениями, так как при загрузке система вовсю выводит их на консоль. Их можно получить также в любой момент с помощью команды dmesg либо заглянув в файлы /var/adm/messages и /var/adm/syslog, в которых по умолчанию хранится весь протокол ядра.

Все сообщения от ядра и его модулей хранятся в кольцевом буфере, размер которого – 16 Кб по умолчанию. Если размера буфера не хватает (к примеру, если ты используешь его для вывода отладочных сообщений от твоего модуля), то его можно увеличить, подкорректировав сорцы ядра. Именно за работу с данным буфером и отвечает демон klogd, который во многом похож на рассматриваемый ниже syslogd (без него он, кстати, даже работать не может).

syslogd

syslogd – демон, отвечающий как за протоколирование сообщений процесса, так и всей системы в целом. Процесс, которому надлежит, по замыслу авторов, протоколировать свои данные, должен включать в свое тело библиотечные функции, при вызове которых происходит обращение к syslogd и передача тому данных для записи (см. врезку).

Как правило, большая часть демонов, функционирующих в системе, имеет в опциях конфигурации настройку параметров подсистемы протоколирования (см. тот же BIND). Со стороны системы все еще проще. Существует файл (у меня это /etc/syslog.conf) – основа для конфигурации всей работы демона syslogd, и если что-то надо поменять в протоколировании сообщений системы, то именно здесь.

В принципе, нам никто не мешает работать с логами даже из простого приложения. Таким образом, в протокол можно сбрасывать все действия приложения/пользователя, что применимо для отладки, хотя для отладки приложения есть другие и более адекватные механизмы. А вот для чего это точно может понадобиться, так это для контроля за действиями пользователя. Своего рода «черный ящик» для систем, где действия пользователей стоит записывать.

Настройка syslog

Для настройки надо понять, что есть ряд уровней («уровней приоритета» или «серьезности») того или иного условия, которое протоколируется, и ряд типов приложений («средств»). Для каждой конкретной системы они описаны в коде ядра. И их значения разъяснены в манах.

«Серьезность» имеет 8 значений (0-7), где 0 – аварийная ситуация, когда всем пользователям шлется широковещательное сообщение и система останавливает свою работу. После такого отказа система, в принципе, может и не завестись. 7 – отладочное сообщение (для отладки приложения, и не более). Стоит заметить, что аналогичные уровни серьезности используются и в Cisco IOS. Эта система протоколирования очень похожа на никсовую.

«Средства» – это ряд типов процессов от ядра до подсистемы почтовых сообщений, включая аутентификацию, авторизацию, демонов etc.

То есть любая запись в файлы логов производится на основании того, что процесс хочет записать и с каким уровнем серьезности. Система (syslogd) перехватывает вывод процесса и отправляет строку в файл, указанный в конфиге. Как видишь, все просто.

Настраивая демона syslogd через /etc/syslog.conf, вполне можно добиться достойной нас информативности.

Вот пример (кусок реального файла) с комментариями:

ЛИСТИНГ

#Все, что касаемо аутентификации.

authpriv.* -/var/log/secure

#Все сообщения уровня Emergency (0) всем пользователям.

*.emerg *

#Писать сообщения от info до warn для сервисов, за исключением

#authpriv, cron – для этих сервисов есть другое место

#см. первую строку.

.info;*.!warn;

authpriv.none, cron.none -/var/log/messages

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

Далее. Есть еще горячая парочка логов – wtmp и utmp, бинарные файлы, и с ними нам придется работать аккуратно. В них хранится информация о подключении пользователей к системе. Но есть ряд тонкостей:

1) utmp хранит данные о подключении пользователей в текущий момент (см. команду who, к примеру);

2) wtmp хранит данные обо всех подключениях к системе. Если, к примеру, некто вошел в систему и сразу вышел, то именно здесь он и «наследил». Самые свежие записи хранятся в начале файла;

3) если файлов в системе нет, syslogd их создавать не станет. Самому придется создать через touch. Но! Если они были, то где они теперь?

Безопасность

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

К примеру, есть роутер Cisco, есть web-сервер, FTP-сервер (на одной системе), есть мэйл-сервер и DNS (на второй). Знаю, что не по правилам, но так уж вышло.

Также есть тачка админа, который для повседневной работы использует ту же систему, что и на его серверах. Где писать логи? Ответ сам напрашивается: на компьютере админа! Если система взломана, то логов хакер на ней не найдет! Придется еще и систему админа ломать :).

Что писать? Аутентификация – раз, подсистемы (FTP, mail …) – два. Это минимум. В данном случае любые попытки доступа и/или использования наших серверов будут записываться. Получаем картинку того, что в сети творится.

Во-вторых (я противник такого метода, но… он самый надежный), все логи, поступающие на машину админа, следует немедленно отправлять на печать. Даже в случае взлома системы админа, при котором все логи, конечно, будут неизменны, у нас останется жесткая копия. Здесь, правда, перед нами встает этический вопрос – а стоит ли весь этот бред жизни деревьев, переводимых на бумагу :)?

Получив логи, отвечающие должным требованиям, не стоит забывать об их обслуживании.

Обслуживание логов

Как правило, рекомендации «лучших собаководов» сводятся к тому, что необходимо поставить некий софт, отвечающий за работу с логами. Все верно. Но это должен быть софт, написанный тобой лично. Тут поможет Perl, писавшийся, между прочим, специально для этих целей.

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

«Что искать», – спросишь ты? Все подозрительное: некорректные входы в систему, отказы в аутентификации пользователя, строки login/password etc. Как пример, многие win-пользователи привыкли к тому, что при входе в систему имя пользователя уже введено и остается только вбить пароль. В *nix это не так. В результате, в логе вполне могут оказаться актуальные пароли, вбитые как имя пользователя. Система, конечно же, не пропустила, но в лог записала. Если это повторится, то пора с данным юзером профилактическую беседу проводить.

Особое внимание стоит уделить поиску строк типа /bin/sh. В этом случае, если строчка чередуется с «мусором», вполне логично предположить, что тебя пытались поломать (и ты видишь shell-код).

Кроме того, при логировании сетевых служб следует искать некорректные входы в систему, попытки подбора пароля.

Здесь самое главное – опыт админа. Чутье ищейки и знание того, что же ты должен увидеть, понимание, как тот или иной механизм должен работать. Я подчеркиваю, это важно как при конфигурации системы протоколирования, так и при анализе результатов ее работы.

Логи должны храниться в течение некоторого разумного времени (к примеру, в течение недели). В особенных случаях можно писать логи на CD и хранить их столько, сколько нужно. Для этих целей есть фича logrotate. Идея такова: прописать в /etc/logrotate.conf, как и что хранить (пересылать ли на e-mail, копировать, сжимать, обрезать размер до нуля – см. man logrotate), а затем через cron раз в какой-то период запускать этого хозяйство. Важно то, что ты сам можешь настроить механизм замены логов так, как это нужно. К примеру, все отладочные сообщения просто и без затей уничтожать, доступ к HTTP – хранить и т.д.

На этом все! Если возникли вопросы, то читай маны, рой сеть и только потом пиши мне :).

Учимся писать логи

Сначала добавляем к сорцу хидер .

Открываем подсистему логов из приложения с помощью функции openlog, прототип которой можно найти в хидере.

На этом этапе можно писать лог с помощью функции syslog(уровень_серьезности, сообщение) или vsyslog(), которая работает с форматированным выводом, как и printf.

В конце закрываем подсистему: closelog().

Для программного доступа к буферу ядра есть функция (man klogctl), которая очень похожа на syslog(). По идеям. По релизу – разберешься.

Увеличить размер буфера ядра можно (к примеру, для Linux-2.4.20 в файле /usr/src/linux/kernel/printk.c). Тебе должно быть интересно значение LOG_BUF_LEN. Естественно, придется пересобрать ядро.

Демон syslog работает на порту 514/UDP (сокет /dev/log), но можно перенаправить его и на иной порт через фаервол.

Хранилище логов в любом случае должно принадлежать root'у.