Изпечатай

[emoto2]

Тествах това което са ми дали но само, че редактирано с порт 27016 и 25 length. Моя е грешката.

[KPETEH]

Тествах това което са ми дали но само, че редактирано с порт 27016 и 25 length. Моя е грешката.

Браво, че си се поправил и си разбрал, че всъщност е друг протокола, но в крайна сметка справи ли се с флуда !?

[emoto2]

Несъм, ако може да ми дадеш код който да спре флуда който идва само на порт 27015 и 27016 с големина 25

[10101]

iptables -A INPUT -p udp --dport 27015 -m lenght --lenght 25 -j DROP
iptables -A INPUT -p udp --dport 27016 -m lenght --lenght 25 -j DROP

Провери дали това работи с iptables -L -v -x -n

[emoto2]

Провери дали това работи с iptables -L -v -x -n

Как да проверя? Може ли подробно разяснение, че си нямам наидея какво си написъл?

[4096bits]

Не ми е ясно, как можеш да си спреш флуда. Няма как да стане. Каквото и да правиш с пакетите, те ще си идват. Говори ISP-то си.

[KPETEH]

Може да добавиш и тези правила:

Код:

iptables -N udp_flood
iptables -A INPUT -p udp -j udp_flood
iptables -A udp_flood -m state –state NEW –m recent –update –seconds 1 –hitcount 10 -j
RETURN
iptables -A udp_flood -j DROP

[petar258]

Не знам кой им дава тези идеи да пробват да блокират по размер на пакета, но това ще доведе само до едно - ще почнат да се спират и полезните пакети които случайно са със същата дължина. А и питащия е толкова зле че не знае какво му е написано "Провери дали това работи с iptables -L -v -x -n" и очаквате такъв човек да постигне нещо хаха. Флуда ще спре ако скоростта която ти дава доставчика е по-голяма от скоростта с която разполага флудещия, но ако ползва ботнет това трудно може да се постигне. Другия вариант е да си даваш данните за сървъра само на проверени хора, които добре познаваш. Иначе е голям шанса да попаднеш на озлобено на целия свят хлапе което ще те разплаче.

[4096bits]

То за да нафлудиш някой какво повече от IP и порт ти трябват. А тея неща се разбират супер лесно.

[10101]

Тези два порта за каква комуникация се използват?
Ако е само клиент/сървър има йезуитско, но сигурно решение, освен ако сървъра не е с комерсиална цел.

[gat3way]

Всъщност, за разлика от TCP, откриването на "отворени" UDP портове е доста по-хлъзгаво занимание. В зависимост от протокола, може да не направиш разлика между отворен и филтриран порт. Нямаш handshake и каквото пратиш, първо че може да не стигне, второ че самия протокол на по-горно ниво може да не предвижда да ти връща отговор. Така ако пратиш нещо на порт, на който няма нещо дето се е bind-нало, обикновено получаваш ICMP port unreachable и така знаеш че е "затворен". Ако обаче нашиеш някое DROP правило, няма как да знаеш слухти ли нещо там или трафика се дроп-ва.

Разбира се от масивния flood няма как да се оправиш с iptables правила, просто защото боклука ще продължи да си пристига при теб. Въпросът е че ако има някоя услуга която слухти на този порт и прави нещо с получените неща, освен честотната лента, може да си имаш и проблеми и с CPU или memory утилизацията, та по-добре да се филтрира.

[KPETEH]

Аз пък се чудя друго нещо възможно ли е клиентите на самата игра да са заразени с нещо , което генерира допълнителен трафик към сървъра и от там настъпва пълната лудница и после snort инсталиран на сървъра с IPS дали няма да засече аномалията и да дропне пакетите. И в крайна сметка има ли някакъв лог файл на самия counterstrike сървър, който да следи за грешки примерно ?

[4096bits]

Аз имах предив точно въпроса със запълването на лентата с безсмислен трафик. UDP не съдържаше в себе си IP на изпращача?

[BRADATA]

За разлика от TCP при UDP няма/не е задължително да има отговор. Т.е. "модерните" флудъри спират ако им дропиш пакетите защото си мислят, че услугата е паднала, а това се разбира само ако има или няма отговор от "жертвата". При UDP, понеже няма условие да има отговор, флуда продължава докато "атакуващият" реши да спре. На тема защита от флууд - решението е единствено при доставчика чрез изрязване на адресите/мрежите на атакуващия/те. И е ефективно само ако доставчика има капацитета да понесе входящия трафик без да му пречи на нормалната работа (задръстване на канала). Ако е някой квартален ланаджия - почти сигурно е, че и той трябва да търси съдействие от ъплинк провайдера си. Така, че защита от UDP флууд - достатъчно трудно начинание. Ако услугата, която се сервира, е официална и легална - тогава собственика на услугата може да пише писма на доставчика на фудъра с молба да бъде прекъснат достъпа на това IP до мрежата. Но това се случва (в БГ) само по желание на ISP-то.

Надявам се да съм бил полезен с информацията

/офтопик/
Още в началото се разбра за какво става въпрос.... За преодоляване на ситуацията е нужен капацитет, който не е наличен в конкретния случай.

[gat3way]

Source адреса може доста лесно да се подправи...единственият проблем е че нормалните доставчици по принцип трябва да филтрират трафик оригиниращ от тяхната access мрежа и с src адрес извън тяхното адресно пространство. Част от тях не го правят, моят преди години не го правеше примерно, след това се сетиха, но въпреки това си излизаха подправени пакети със src адрес на някой друг абонат на доставчика (това е по-сложен казус така или иначе). Сега на мтел нищо такова не може да излезе навън, което е както трябва да се правят нещата по принцип.