Флууд по igmp?

[Стоян Иванов]

Добър ден момчета. Имам един проблем, който няколко дни вече не мога да реша и затова се обръщам към вас, по-разбиращите за помощ. Преди седмица поставих един микротик в офис, в който имаха оплаквания от проблеми с нета и чести прекъсвания. Първата ми стъпка бе да заменя съществуващия netgear с hap-lite и проблемните им места се видяха. Мисля че  ги отстаних, но остана един неприятен флууд по igmp (multicast), които вече нямам идея как да погася. Изглежда ми като Dos от спуфнати адреси, защото в Interface/torch  виждам заявки от няколко почти цели мрежи. Написах доста правила, но сякаш колкото повече рестрикции слагам, толкова по-брутален става. В началото бе 3-4Mbps, а сега на моменти достига 13-15Mbps. Недостатъчен е за да запълни канала и свързаност има, нета не пада, но ме е яд, че вече нямам идея как да противостоя на това. В мрежата има ДВР с камери по коаксиал плюс две  по ip. Разгледал съм им настройките и мисля че при тях няма проблем, но като гледам резултатите съмненията ми падат върху тях и един мрежови WIFI принтер, които за момента съм изключил . Някакви идеи какво е това чудо и може ли да се погаси по някакъв начин?

Единственото устройство с конекция по igmp е тъпия принтер.

[byte]

То ако по WAN порта ти идва igmp, звънни на провайдера си. 

[Inkas]

Като за начало забрани порта към DVR-a да видим дали пак ще го има ...

[Стоян Иванов]

Да, отвън е. Но има ли търсене, има и предлагане. Затова реших да намеря устройството което търси. Наблюдавайки и днес следобед логовете, съм сигурен че търсенето идва от принтера, които се опитва да вкара адреси от публичната мрежа в лана.

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

В случая доставчика е Телекабел, които има и услуга IPTV, но се съмнявам да са толкова смотани за да си нафлудят цялата мрежа с мултикаст!?

[byte]

Добре де, прати мултикаст мрежите 224.0.0.0/4 в трета глуха т.е. blackhole

[111111]

В микротик има една приятна реализация RAW която дропва всичко преди да е стигнало на софтуерния firewall.

Добави комуникацията на принтера с интернет в тази графа и кажи какъв е резултата.

Погледни и ДНС кеша в какво състояние е.

[Стоян Иванов]

Преди 8 часа, 111111 написа:

В микротик има една приятна реализация RAW която дропва всичко преди да е стигнало на софтуерния firewall.

Добави комуникацията на принтера с интернет в тази графа и кажи какъв е резултата.

Погледни и ДНС кеша в какво състояние е.

Днес минах през офиса и погледнах как стоят нещата с конфигурацията на въпросния принтер. Хората си бяха пуснали всички "благинки" които могат да се пуснат. UPnP, Уеб печат и тн. Спрях ненужните и несигурни неща, сложих му една добра парола и принтера се кротна. Колкото пъти проверих логовете днес, не го видях никъде. Още миналата седмица дропих целия мултикаст на входа, но снощи след като видях коментара на byte реших да си направя труда и да напиша едно правило с blacklist на  224.0.0.0/4 , за да видя колко адреса ще хвана по igmp - около 40. След като сработиха правилата, днес виждам че и по входящия DNS  вече е спокойно. Остана само една конекция, която доколкото разбирам е от частните адреси 10.0.0.0 ~ 10.255.255.255 (10.0.0.0/8) и държи един постоянен трафик от 5-10Mbps (според зависи, колкое на кеф D:). Е моите силици и умствени възможности за момента са до тук. Доколкото успях да разбера по използвания порт:52755, това би трябвало да част облачна услуга (Xsan или  SANS - Ейпъл), която откъде идва и на къде отива, един господ знае...

 

 

Редактирано 29 Януари, 2018 от Стоян Иванов

[byte]

Още не съм се разсънил, но явно ти виждаш трафика на някой друг клиент ?!

 

[111111]

/ip firewall filter
add action=drop chain=forward comment="default configuration invalid drop" connection-state=invalid
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface=WAN

Хубаво е да има някои правила по подразбиране

[byte]

Е тоя трафик мислиш ли, че се forward-ва ?

[111111]

Преди 1 час, byte написа:

Е тоя трафик мислиш ли, че се forward-ва ?

А какъв е шанса да не се подтиква от вътрешна заявка?

/ip firewall filter
add action=jump chain=input jump-target=icmp protocol=icmp
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input protocol=gre
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop all from WAN" in-interface=WAN
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related,untracked
add action=accept chain=icmp comment="echo reply" icmp-options=0:0 protocol=icmp
add action=accept chain=icmp comment="net unreachable" icmp-options=3:0 protocol=icmp
add action=accept chain=icmp comment="host unreachable" icmp-options=3:1 protocol=icmp
add action=accept chain=icmp comment="host unreachable fragmentation required" icmp-options=3:4 protocol=icmp
add action=accept chain=icmp comment="allow source quench" icmp-options=4:0 protocol=icmp
add action=accept chain=icmp comment="allow echo request" icmp-options=8:0 protocol=icmp
add action=accept chain=icmp comment="allow time exceed" icmp-options=11:0 protocol=icmp
add action=accept chain=icmp comment="allow parameter bad" icmp-options=12:0 protocol=icmp
add action=drop chain=icmp comment="deny all other types"

трябва да се разреши достъп отвън с по горестоящо правило 

/ip fi fi
add action=accept chain=input comment="allow port" dst-port=8291,3389,1723,500,433 protocol=tcp

 

[kokaracha]

И какво като го дропи,тои няма да спре да идва ? По добре се обади на доставчика си,само той може да спре този трафик,при условие че предлага иптв надали ще стане обаче.

[Стоян Иванов]

Тези дни излязоха други проблеми за решаване и този остана на заден план, така че все още не съм намерил пълно решение. Всичко е филтрирано на входа + fasttrack и правила на nat-a. Мултикаста вече почти го няма или е пренебрежимо малък, но тази между 10.222.0.1 - 10.222.0.73 все още се появява понякога и си прави по 10-15М с часове.

[111111]

Оплачи се на доставчика проблема е от неговата мрежа.