Pull to refresh

Побеждаем широковещательный флуд в корпоративной локальной вычислительной сети

Reading time 3 min
Views 89K

Симптомы


Случилось у нас в организации, страшное дело – сеть работала, работала и вдруг, вроде без особых на то причин, стала работать нестабильно. Выглядело всё это очень странно (впервые столкнулся с проблемой сабжа) – некоторые компьютеры в сети (их небольшое количество) перестали получать IP-адреса (в логах пишут, что не получен ответ от DHCP), причем с утра одни, с обеда другие – пользователи звонят, волнуются, а мы ничего понять не можем.


Если это аппаратный сбой, то должен он по всем канонам, в каком-то одном месте находится, или хотя бы более массово проявляться (как например, с кольцом в Ethernet), а тут какие-то редкие всплески (примерно 5 из 300), а в целом все работает. Более детальный анализ географии больных компьютеров, показал, что они находятся на коммутаторах 3 и более очереди, от шлюза (рисунок 1).

image
Рисунок 1. География проблемы.

Поиск и выявление


От гипотезы проблемы с железом, отказались не сразу – отключали нижестоящие коммутаторы, и вроде бы получали более-менее кратковременное улучшение, но проблема до конца не исчезала.

Естественно возникла версия, что это некий вирус на ПК – мешает им получать IP-адрес. Она была отвергнута после, того как адрес не получил сетевой принтер. Как оказалось зря (точнее почти зря).

Параллельно с этим пытались анализировать трафик, но из-за неопытности специалистов, анализировался только трафик DHCP.

Итак, первые несколько дней решения проблемы не принесли. Пришлось расширять поле зрение сниффера. И вот в этот момент причина проблемы была обнаружена – при анализе всего широковещательного трафика, обнаружилось, что более 80% запросов ищут, некий сервер – в смысле один и тот же.

Как. позже мы почерпнули из интернета, называется данная проблема широковещательный флуд.
Эх… если бы знать об этом раньше.

Выяснилось, что некая служба под названием «PcounterPrint», очень истерично пытается найти свой сервер, которого как это ни странно нет. Служба ведет аудит печати сотрудников корпорации, и известна в миру под названием FollowMe Printing. Как выяснилось позже – сервер данной службы был успешно выведен из эксплуатации, естественно без какого либо уведомления, вышестоящими корпоративными системными администраторами.
По сути ПК пользователей выступили в качестве ботов, для DDOS-атаки нашего сетевого оборудования.

Дело осталось за малыми задушить эту службу на ПК пользователей.

Массовое удаление


По хорошему, нужно было эту задачу отдать вышеописанным системным администраторам, но ведь и самим интересно и вот, после 25-минутных поисков в интернет рожден скрипт в power-shell:

Здесь код скрипта
main
function main 
{
    $computers = Get-Content C:\Scripts\Computers.txt
    $service = "PcounterPrint"
    foreach ($computer in $computers) 
    {
        (Write-Host "computer - $computer") 
        if (ping-host $computer)
        {
            $srv = (gwmi win32_service -computername $computer -filter "name='$service'")
            if ($srv -ne $null)
            {
              $result = $srv.stopservice()
              $result = $srv.ChangeStartMode("Disabled")
              (Write-Host "Service is disabled")
            }
            else
            { (Write-Host "No service") }
         }
        else
        { (Write-Host "No host") } 
    }
} 

function ping-host 
{ 
    param($computer) 
    $status = Get-WmiObject -Class Win32_PingStatus -Filter 
    "Address='$computer'"
    if( $status.statuscode -eq 0) { return 1 } 
    else { return 0 } 
}



Переменная $computers получает список компьютеров из файла, скрипт последовательно обходит все ПК из этого списка, и отключает на них злополучную службу.

Далее проверяем широковещательный трафик сниффером, если кто-то остался – корректируем список, и выполняем скрипт повторно, и так делаем несколько итераций, до полного удаления зловредного трафика.

Естественно, после этого сеть заработала стабильно.

Выводы


Как говорится в одном, известном, преферансистском анекдоте: так за это же нужно канделябром по голове…

В общем, административные выводы, я здесь писать не буду, хотя в основном напрашиваются именно они.

С технической точки, зрения, есть несколько мероприятий для профилактики, этой беды:
1. Сегментировать сеть на несколько виртуальных сетей
2. Уменьшить с помощью первого пункта глубину сети
3. Установить более умные коммутаторы

Хотя это конечно мероприятия эти спорны: а надо ли, ведь придется тратить время и деньги, тем более что персонал теперь знаком с данной ситуацией и в последующем, сможет быстро ее победить, хотя как знать…
Tags:
Hubs:
+12
Comments 70
Comments Comments 70

Articles