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

O SmtpGreetingMessage=$j ESMTP InsecureMailserver

Или sendmail.mc:

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

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

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 и передача тому данных для записи (см. врезку).