Самый популярный пакет для удаленного администрирования по протоколу ssh, хоть и написанный весьма компетентными хакерами из OpenBSD team, но имеющий длинную историю взломов. Баннер в конфиге не выставляется, так что будем править сорцы. Найди в файле version.h следующие строки:
#define SSH_VERSION «OpenSSH_3.8p1»
Их и следует изменить. Полностью удалять строку не нужно, согласно стандарту, сервер обязан выдать версию ssh-протокола, а затем – имя демона. Я советую ограничиться удалением версии openssh, но ты можешь проявить фантазию. Затем собирай openssh как обычно.
Это классика. Смена баннера самого популярного 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»
Этот удобный и (относительно, как и все в этом мире) безопасный 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')
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-файлов для *nix-систем
the_Shadow (theshadow@sources.ru)
Логи – органы чувств администратора в чреве системы. В этой статье я постараюсь рассказать тебе о работе системы ведения log-файлов, ее грамотной настройке и о том, что из нее вообще можно выжать.
При старте системы запускается механизм протоколирования, состоящий из двух подсистем ведения протокола – ядра и процессов. Собственно, работа их начнется сразу после того, как syslogd и klogd стартанутся в процессе init. Тогда создастся сокет /dev/log, на который в дальнейшем смогут поступать логи с удаленных машин, также откроются файлы, описанные для логирования в твоей системе.
С этого момента система будет ждать твоих логов.
Сообщения ядра – это не самое важное, но упомянуть о них я обязан. Ты наверняка встречался с этими сообщениями, так как при загрузке система вовсю выводит их на консоль. Их можно получить также в любой момент с помощью команды dmesg либо заглянув в файлы /var/adm/messages и /var/adm/syslog, в которых по умолчанию хранится весь протокол ядра.
Все сообщения от ядра и его модулей хранятся в кольцевом буфере, размер которого – 16 Кб по умолчанию. Если размера буфера не хватает (к примеру, если ты используешь его для вывода отладочных сообщений от твоего модуля), то его можно увеличить, подкорректировав сорцы ядра. Именно за работу с данным буфером и отвечает демон klogd, который во многом похож на рассматриваемый ниже syslogd (без него он, кстати, даже работать не может).
syslogd – демон, отвечающий как за протоколирование сообщений процесса, так и всей системы в целом. Процесс, которому надлежит, по замыслу авторов, протоколировать свои данные, должен включать в свое тело библиотечные функции, при вызове которых происходит обращение к syslogd и передача тому данных для записи (см. врезку).
Как правило, большая часть демонов, функционирующих в системе, имеет в опциях конфигурации настройку параметров подсистемы протоколирования (см. тот же BIND). Со стороны системы все еще проще. Существует файл (у меня это /etc/syslog.conf) – основа для конфигурации всей работы демона syslogd, и если что-то надо поменять в протоколировании сообщений системы, то именно здесь.
В принципе, нам никто не мешает работать с логами даже из простого приложения. Таким образом, в протокол можно сбрасывать все действия приложения/пользователя, что применимо для отладки, хотя для отладки приложения есть другие и более адекватные механизмы. А вот для чего это точно может понадобиться, так это для контроля за действиями пользователя. Своего рода «черный ящик» для систем, где действия пользователей стоит записывать.