Система Orphus

среда, 7 апреля 2010 г.

История одного "инцидента" или оконная пакость

Скажу сразу: слово "инцидент" взято в кавычки, т.к. на самом деле никакого инцидента не было. Это была "стабильная" работа форточек...


Сижу себе на работе, никого не трогаю, читаю книгу "Linux Advanced Routing & Traffic Control HOWTO"...
Заорали коллеги, мол инета нету. Подключаюсь к шлюзу, он у меня на pfSense 1.2.3, иду в Status -> Traffic graph: канал забит исходящим трафиком. Лезу в Services -> BandwidthD, нахожу подозрительный комп (192.168.0.197), у которого UDP трафик в несколько десятков метров, выдергиваю его кабель из свитча, смотрю на графики шлюза, инет ожил. Втыкаю кабель, опять исходящий трафик забивает канал. Заблокировал его на фаере и пошел к этому компу.
Закрыл все проги. Запустил netstat, ничего подозрительного, в диспетчере задач тоже чисто. Т.ж. проверил след. утилитами: TCPView, Autoruns и Process Explorer. Чисто! Скачал и проверил через AVZ. Чисто! Запустил сканирование антивирем. Чисто! Просканировал еще двумя. Чисто! Загрузился с LiveCD, просканировал еще раз. Чисто! Волосы уже дыбом, мозг в шоке.
Вернулся к себе, пошел в Diagnostics -> State Summary, делаю поиск по странице по адресу "192.168.0.197" и в разделе "By IP Pair" нахожу следующее:
IP                                # States   Proto   # States   Src Ports   Dst Ports
192.168.0.197 -> 207.46.232.182   2
udp     2          1           1
Были и другие, но меня интересовал протокол UDP. Смотрю, что это за IP:
$ host 207.46.232.182
В ответе вижу много DNS-имен, что меня напрягает, а слудующее и вовсе удивило:
182.232.46.207.in-addr.arpa domain name pointer agent.microsoft.com.
182.232.46.207.in-addr.arpa domain name pointer channels.microsoft.com.

Уже чуть ли не в ярости, иду в Diagnostics -> Packet Capture и запускаю захват всех пакетов, которые идут с/на 207.46.232.182. В ответ вижу следующее:
15:37:25.117132 IP 192.168.0.197.123 > 207.46.232.182.123: UDP, length 48
15:37:25.123705 IP 207.46.232.182.123 > 192.168.0.197.123: UDP, length 48
Порт 123 это же NTP, убеждаюсь:
$ grep 123 /etc/services 
ntp  123/tcp
ntp  123/udp    # Network Time Protocol
Да, все верно.

Иду опять к той машине, тыкаю дважды по часам, на последней закладке снимаю единственную галку, OK... Вауля, трафик перестал идти (т.ж. мониторчики справа внизу погасли). Для верности т.ж. вырубаю службу времени форточек.
Возвращаюсь к себе, ввожу в терминале:
$ host time.windows.com
В ответ получаю:
time.windows.com is an alias for time.microsoft.akadns.net.
time.microsoft.akadns.net has address 207.46.232.182



И вот еще додумайся (без анализа трафика, конечно), что это популярная и "надежная" ОСь просто захотела мозг мне по__ть, а не какой-нибудь очередной, свежий трой прикрытый руткитом.

В очередной раз я убедился, что "Службу времени Windows" стоит вырубать.





PS: Цель поста: показать на примере начинающим админам, как можно определить и разоблачить "аномалии" в сети.

PPS: Для тех, кто не знает pfSense... По умолчанию пакеты "BandwidthD" и "States Summary" не устанавливаются. Их надо ставить самостоятельно в System -> Packages.

PPPS: Это кросс-пост моего поста с хабра.



Информация с сайта http://angel2s2.blogspot.com/. Если Вы читаете информацию на другом сайте, пожалуйста свяжитесь с автором сайта http://angel2s2.blogspot.com/.

Похожие статьи

11 коммент.:

Noble Ossage комментирует... пятница, 9 апреля 2010 г. в 19:55:00 GMT+3

Мда..... А вот объясните не-админу, что, служба времени требует так много трафика??? Она кроме синхронизации часов еще много чего делает??? мегабайты передает на микрософт? о чем? О марках моих часов?

Unknown комментирует... понедельник, 12 апреля 2010 г. в 10:10:00 GMT+3

Не пугайтесь :)) Ничего о вас она не передает. Она просто запрашивает текущее время с сервера точного времени.

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

Много трафика она не жрет. Не думаю, что больше нескольких килобайт в день (не вдавался в эти подробности).

Анонимный комментирует... понедельник, 3 мая 2010 г. в 06:13:00 GMT+3

Чувак я люблю тебя!!! Твой пост решил проблему которая уже год не даёт мне спать!))))))) Спасибо огромное)))))) И всё дело в одной грёбаной галочке...........

Анонимный комментирует... понедельник, 3 мая 2010 г. в 06:15:00 GMT+3

Но почему у меня трафа в день уходило по несколько сот мегабайт на тайм-синхронизацию до сих пор непонятно...

Unknown комментирует... понедельник, 3 мая 2010 г. в 18:49:00 GMT+3

Рад что помогло :)))

Несколько сот метров в день?? о_О Нифига себе... Слов аж нету...

Анонимный комментирует... среда, 1 сентября 2010 г. в 13:26:00 GMT+3

немного не по теме как заставить работать BandwidthD на pfsense 2.0b нет никаких графиков

Unknown комментирует... среда, 1 сентября 2010 г. в 14:12:00 GMT+3

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

maxa комментирует... четверг, 3 февраля 2011 г. в 16:44:00 GMT+2

Ммм... за 2 часа 30 ГБ исходящего трафика по UDP (при хорошем канале), может конечно что-то другое, но сейчас проверить уже могу, т.к. Win2008 полностью переустановил. Аналогично проверял на вирусы, чем только можно - ноль. Спасибо, попробую уже на новой OS отключить службу времени.

Unknown комментирует... четверг, 3 февраля 2011 г. в 16:52:00 GMT+2

Не за что :)
Но на сервере не советую отключать, тем более, если сервер является контроллером домена, dns, dhcp и т.п. Т.е. если на нем крутят службы чувствительные ко времени. Лучше указать другой сервер, который поближе к тебе находится. Или даже, если есть возможность, настроить, например, на шлюзе ntpd (я про никсы) и все что внутри локалки уже с этим шлюзом синхронизировать.

Анонимный комментирует... пятница, 4 февраля 2011 г. в 19:58:00 GMT+2

Ох блин. СПАСИБО ТЕБЕ, ДОБРЫЙ Angel 2S2!!!)))) Жаль по инете нельзя руку пожать и пиво попить...((

Unknown комментирует... суббота, 5 февраля 2011 г. в 13:30:00 GMT+2

Не за что :) Рад, что помогло :))

Отправить комментарий