Jump to content
  • 0

UDP Flood DoS


2GOOD

Въпрос

  • Администратор

Здравейте,

Доста рових из нета въобще за някакво елегантно решение на проблема или поне ограничаването му, но така и не намерих начин. Ето и за какво става въпрос.

Хоствам Два HLDS (Counter Strike) Сървъра на машина зад НАТ:


chain=srcnat src-address=192.168.222.0/24 action=masquerade

chain=dstnat dst-address=87.120.xxх.ххх protocol=udp dst-port=27015 action=dst-nat to-addresses=192.168.222.1 to-ports=0-65535

chain=dstnat dst-address=87.120.xxх.ххх protocol=udp dst-port=27016 action=dst-nat to-addresses=192.168.222.1 to-ports=0-65535

като единият е на 27015 а другия съответно на 27016

Проблема е, че има някакъв tool за flood на тези сървъри, който прави много "конекции" от едно ИП забелязвал съм по 300-400 от поредни портове насочени към един от тези двата 27015/16. Засега се държи, но понякога играчите се оплакват от "лаг" заради натоварването на ЪП канала ми. По принцип имам и Queue Tree PCQ като тези съврари са с висок приоритет за да няма проблеми с лага.

Знам, че UDP е "connectionless" протокол, но все пак има ли начин да се ограничат броя на заявките от едно IP да кажем на 20, другото което ми хрумна е някакъв вид shaping така, че на ip да не се дава повече от 256 kbps през UDP.

Знам основните неща на микротика, но се смятам за noob, така че бъдете нежни :)

Благодаря

Редактирано от PsychoTraining
Адрес на коментара
Сподели в други сайтове

6 отговори на този въпрос

Recommended Posts

  • 0

UDP is connection-less, meaning there is no such thing as true connection. You can limit packet rates of UDP though just like any other limiting. Use something like this if you are concerned about too many packets per second of UDP:

chain=input in-interface=1-coxBiz protocol=udp limit=5,5

connection-state=new action=log log-prefix="UDPLIMIT"

not sure the connection-state=new does anything but I think so if you have connection-tracking turned on. There really isn't such a thing as connections in UDP but the stateful firewall will keep track of them. You can see in the firewall / connections tab there are UDP connections being tracked, so as far as MT goes you can limit just like anything else.

Sam

След като Source портовете на "UDP конекциите" са различни, вероятно RouterOS ще успеее да ги лимитира. Ако с WinBox не можеш да избереш limit за udp - пробвай през Terminal.

Последните версии RouterOS имат limit и за UDP в WinBox.

Също ако покажеш Queue Tree-то си заедно с mangle-а за него, ще можем да погледнем и евентуално да предложим промени там.

Поздрави.

Адрес на коментара
Сподели в други сайтове

  • 0

Sunday and Monday were horrible days...

It was the first time our network became the source of DDoS attack. TechSupport woke me up at about 13:00 - users were complaining about very slow Internet access with high packet drop rate. Guess what I did first? Yes, after a few minutes I rebooted the router :) And guess what? After reboot, the picture stayed the same. Even pinging router's address (or 127.0.0.1) from the router itself was showing 200-500ms RTT with 50% of timeouts.

After about fifteen minutes of searching and trying I identified that the reason was my firewall filter fules for limiting the number of simultaneous TCP connections per user: they were showing high rate of dropped packets, and when I was disabling them, router was becoming stable again.

It appeared that some kind of virus or botnet on customers' computers was attacking single IP address (some Lineage II game server) by creating huge number of HTTP requests to the host (when I blocked any packets to that server, filter rule was dropping about 4000 new connections per second). So, when 'connection-limit' matcher was trying to count active user's connections a few thousand times per second, it was killing the router completely.

In Monday, attacked IP addresses changed, so this horror returned back :) After a dozen of minutes I came to this solution:

/ip firewall filter

add chain=forward connection-state=new action=jump jump-target=block-ddos

add chain=forward connection-state=new src-address-list=ddoser dst-address-list=ddosed action=drop

add chain=block-ddos dst-limit=50,50,src-and-dst-addresses/10s action=return

add chain=block-ddos action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m

add chain=block-ddos action=add-src-to-address-list address-list=ddoser address-list-timeout=10m

It dynamically creates two address lists: attackers ('ddoser') and attacked hosts ('ddosed'), and blocks packets from the former to the latter. Works like a charm =)

Hope this will help somebody to protect his routers from flooding...

Т.е. идеята е като се засече IP адреса който прави прекално много "UDP конекции" - да се дропи директно по IP адрес. И аз така си ги правя - както Chupaka е успял.

Адрес на коментара
Сподели в други сайтове

  • 0
  • Администратор

Попаднах и аз на този пост, но не бях сиг. дали ще ми свърши работа. Сега ще го сложа и ще докладвам след няколко дни или по-рано ако намеря въпросния tool да тествам сам.

Благодарности

Редактирано от PsychoTraining
Адрес на коментара
Сподели в други сайтове

  • 0

Има и по лесно решение което се отнася за самите CS сървъри сложи този модул и си решаваш проблема http://cs-bg.info/plugin/17/ :)

Редактирано от Balthazar
Адрес на коментара
Сподели в други сайтове

  • 0
  • Администратор

Има и по лесно решение което се отнася за самите CS сървъри сложи този модул и си решаваш проблема http://cs-bg.info/plugin/17/ :)

Доколкото разбрах от sourc-a и от readme-то този плъгин следи само за say съобщения, което мисля го има вградено в последното dproto, но това няма нищо общо с чиста D/DoS атака

Адрес на коментара
Сподели в други сайтове

  • 0

Не съм го чел изрових го от някакъв форум.. видях че го препоръчват.. :) ползвай тогава правилата които са ти дали колегите те трябва да ограничат опитите за конекция.. ако беше с линукс щях да ти кажа как да го направиш но при микротик друг вариянт не виждам освен това което са ти написали

Адрес на коментара
Сподели в други сайтове

Създайте нов акаунт или се впишете, за да коментирате

За да коментирате, трябва да имате регистрация

Създайте акаунт

Присъединете се към нашата общност. Регистрацията става бързо!

Регистрация на нов акаунт

Вход

Имате акаунт? Впишете се оттук.

Вписване
  • Потребители разглеждащи страницата   0 потребители

    • No registered users viewing this page.
×
×
  • Създай нов...

Important Information

By using this site, you agree to our Terms of Use.