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

version «Microsoft DNS»;

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

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

Во 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-файлов, ее грамотной настройке и о том, что из нее вообще можно выжать.

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

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

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

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

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

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

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

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

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

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

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

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

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

ЛИСТИНГ

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

authpriv.* -/var/log/secure

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

*.emerg *

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

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