Re: [Sysadmins] osec & DoS

[Michael Shigorin <mike@osdn.org.ua>]

On Wed, Aug 22, 2007 at 06:28:15PM +0400, Алексей Шенцев wrote:
> > > Поздно: 1) сервер запущен в работу; 2) сервак у меня завис
> > > так, что даже на клаву не реагировал. На экране было такое:
> > > int=eth0 его мак-адрес bla-bla-bla SRC=125.190.36.89

BTW не вижу -j log в iptables.

> > > bla-bla-bla
> > Фотографировать надо.
> Не было под рукой чем фотать ... хотя идея ... 

Значит, карандашиком на бумагу из принтера.

> > Более интересно другое -- какой комплект софта у тебя смотрит
> > в сеть?
> Что смотрит в инет: named, postfix, apache2. Остальные: squid,
> proftpd, mysql слушают только локалку.  Для apache2 во многие
> каталоги можно попасть либо только из локалки, либо только с
> определённых машин локалки.

Если named -- 9.x, а apache2 -- 2.2.x посвежей, то какие-либо
проблемы могли быть с тем, что на нём из веб-софта публично
доступно.

На будущее -- выдёргиваешь (или блокируешь) внешний канал 
и НЕ РЕБУТАЯ тазик, смотришь pstree (его редко пытаются троянить,
даже если получили локального рута и посадили руткит с подменой
бинарников).  Если в нём болтается, скажем, sendmail или smbd -D,
а у тебя там постфикс и самбы нет -- pstree -p, пишешь PID-ы
и лезешь в /proc/PID смотреть, откуда exe растёт.  Если
откуда-нить из /tmp/.чтонитьэтакое и владельцем -- apache,
то вот тебе и ниточка.

После ребута конкретно такое можно и не найти, если /tmp/.чт*
было хитрым и удалило себя в процессе выполнения (получился
безымянный файл, который существует на диске, пока процесс
не завершится).

А вообще по forensic analysis есть куча всего, но, к сожалению,
скорее помогает смотреть, как опытные люди раскапывают такие
системы -- или изучать какой-нить древний редхат.

С моими системами был один случай с rebuild from scratch
(поскольку известная уязвимость класса remote root -- была
в openssh -- и странноватое поведение системы скорее даже 
"по ощущениям", поскольку прямых улик не нашлось) и два
-- когда был выполнен чужой процесс из-под apache; оба по
причине дырявых веб-скриптов третьих людей (причём один раз
я заранее проверил на наличие уязвимой библиотеки все сайты,
кроме одного, который вёл очень доверенный человек -- и именно
через него в ту же ночь проспамили, а второй раз -- болтался
uselib24 и всё, ничего этот эксплойт сделать не мог).

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

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/