(D)DoS UDP útok na VoIP PBX

[rteppp]

Poslední dobou se mi rozmnožily neúměrně útoky na SIP účty na VoIP ústřednách, které provozuji (celkem 2 .
Vzhledem k tomu, že takovýchto problémů bude přibývat nejen u mě dovoluji si požádat fórum o pomoc s obecným řešením.
Doposud to vždy skončilo dočasným "vyřazením" služby, manuálním zapsáním útočící IP do Address Listu, restartem PBX, což není dlouhodobým řešením

Na rozhraní je RB450G, ether1 je WAN, ether2 DMZ1 (pro VoIP PBX), ether3 DMZ2, ether3-5 LAN.
Útoky jsou prováděny UDP tokem na port 5060 veřejné adresy PBX, který musí být dostupný i z WAN, neb se na něj přihlašují telefony, které jsou mimo LAN. Datové toky dosahují až 1,5Mbit/sec (cca 450paketů/sec).
Útočník se snaží, jak jsem se díval do obsahu paketů, získat tímto přihlášení na vnitřní účet pobočnové linky a pak si zatelefonovat....
K zablokování dochází díky tomu, že ústředna odpovídá stejnou rychlostí - zamítá pokusy o přihlášení se špatným heslem a výsledek je jasný....

Potřebuji poradit jak:
1. jednoduše detekovat UDP útok, tj. mnoho spojení na UDP port 5060 a zablokovat jej, zařadit útočníka na fixní block list
2. odstřelit již navázaná spojení (zatím to řeším tak, že na chvíli shodím rozhraní ether2 (pro DMZ1, za kterým je PBX)
3. odeslat e-mail o útoku na zadanou adresu - potřebuji být informován o útoku, neb to není krátkodobá záležitost a zatím se to vždy řešilo na úrovni třeba APNIC nebo správce Amazon EC2 cloudu v jednotkách dní (((
Korespondence s těmito správci je značně otravná, neb většinou odmítají reagovat a až na v průměru třetí, čtvrté oznámení se něco děje.... Kdyby jste někdo věděl o tom, jak efektivně řešit tento problém budu vděčný za radu...

Předem dějuji za pomoc

PetrP

[andreas4all]

ak sa da, tak presun vsetko co je mimo LAN na VPN tunel, potom zhod PBX z verejnej IP a bude dostupna z LAN a VPN.

[rteppp]

ak sa da, tak presun vsetko co je mimo LAN na VPN tunel, potom zhod PBX z verejnej IP a bude dostupna z LAN a VPN.

To je sice krásné řešení, ale bohužel nerealizovatelné v mém případě, neb se na PBX přihlašují známí, kteří jsou v různých končinách zeměplochy a VPN je pro ně neznámý pojem (ne každý je informatik ) a i vzhledem k mixu HW a SW telefonů je to neřešitelné...
Bohužel PBX MUSÍ mit veřejnou adresu. Nějak to musí fungovat, protože poskytovaté veřejných VoIP služeb to mají taky nějak vyřešeno, fungují a nevěřím, že tíhle kreténi na ně nepořádají hony.

[soooc]

ak sa da, tak presun vsetko co je mimo LAN na VPN tunel, potom zhod PBX z verejnej IP a bude dostupna z LAN a VPN.

To je sice krásné řešení, ale bohužel nerealizovatelné v mém případě, neb se na PBX přihlašují známí, kteří jsou v různých končinách zeměplochy a VPN je pro ně neznámý pojem (ne každý je informatik ) a i vzhledem k mixu HW a SW telefonů je to neřešitelné...
Bohužel PBX MUSÍ mit veřejnou adresu. Nějak to musí fungovat, protože poskytovaté veřejných VoIP služeb to mají taky nějak vyřešeno, fungují a nevěřím, že tíhle kreténi na ně nepořádají hony.

A kdybys dal do firewallu pravidlo, ktere omezi pocet UDP packetu z jedne ip adresy za vterinu? I to mikrotik umi

[rteppp]

ak sa da, tak presun vsetko co je mimo LAN na VPN tunel, potom zhod PBX z verejnej IP a bude dostupna z LAN a VPN.

To je sice krásné řešení, ale bohužel nerealizovatelné v mém případě, neb se na PBX přihlašují známí, kteří jsou v různých končinách zeměplochy a VPN je pro ně neznámý pojem (ne každý je informatik ) a i vzhledem k mixu HW a SW telefonů je to neřešitelné...
Bohužel PBX MUSÍ mit veřejnou adresu. Nějak to musí fungovat, protože poskytovaté veřejných VoIP služeb to mají taky nějak vyřešeno, fungují a nevěřím, že tíhle kreténi na ně nepořádají hony.

A kdybys dal do firewallu pravidlo, ktere omezi pocet UDP packetu z jedne ip adresy za vterinu? I to mikrotik umi

Ano, i toto řešení mám za sebou, pořád totiž zůstává provoz, na který MUSÍ ústředna odpovídat. Jediným řešením jej detekovat jako útok (moc UDP spojení za čas), umístit na black list a zaříznout. Poté zlikvidovat stávající spojení, na kterém útočník generuje pokusy o prihlášení a je klid na ústředně, MKT to zařízne před ní. Experimentáně vyzkoušený fungující proces, ale bohužel vyžadující mauální obsluhu, která nemá vždy čas a tak občas není spojení a díky tomu i velení (na jedné z PBX je i VIP (tchýně))...
Pro mě je neřešitelný ten UDP provoz, na TCP si s tím umím poradit - detekovat, zapsat a zaříznout, ale na UDP je to mimo mě (zatím ).
+ automatické odeslání mailu na základě události (zařazení útočníka na black list).

PetrP

[pepulis]

A co tam pouštět takový provoz, který souvisí s chodem voip = přes L7 layer. To by mohlo pomoct ne? Rozlišovat provoz voip (na portu 5060 ...) přes L7 a zbytku nastavit malou / nulovou rychlost. Možná ale jen tak plácám ...

[rteppp]

A co tam pouštět takový provoz, který souvisí s chodem voip = přes L7 layer. To by mohlo pomoct ne? Rozlišovat provoz voip (na portu 5060 ...) přes L7 a zbytku nastavit malou / nulovou rychlost. Možná ale jen tak plácám ...

Neumím posoudit, protože pro mě je tohle vysoká dívčí Tuto funkčnost MKT jsem ještě nikdy nepoužil a potřeboval bych nějak nakopnout, neb v tomto okamžiku došlo pět ke změně útočících IP adres. Zareagoval jsme sice manuálně, ale stejně jsem musel restartnou zase ústřednu. JE to otravné. UDP datový tok směřující aktuálně na PBX je 1,5Mbit/sec

Zkusím zjednodušit otázku:

Jak detekovat vysoký UDP tok, identifikovat IP útočníka a zapsat ji do blacklistu - to je můj základní problém

PetrP

[pepulis]

Vemu to z jine stranky, tak se nezlob ze neodpovim na tvoji otazku presne, ale.....

VOIP musi byt z venku dostupne proc? Kvuli tvym znamym? Ano? Potom je to v pohode. Kazdy znamy ma nějakou IP, udělas dvě "skupiny" mangle. Do jedne budou patřit ip, které chceš ty sám a do druhé zbytek. Omanglueš, nastavíš QT ...

[rteppp]

Vemu to z jine stranky, tak se nezlob ze neodpovim na tvoji otazku presne, ale.....

VOIP musi byt z venku dostupne proc? Kvuli tvym znamym? Ano? Potom je to v pohode. Kazdy znamy ma nějakou IP, udělas dvě "skupiny" mangle. Do jedne budou patřit ip, které chceš ty sám a do druhé zbytek. Omanglueš, nastavíš QT ...

Dobře míněná rada, ale toto řešení mám už za sebou. Synové jsou na kolejích, mají HW VoIP telefony, DHCP přidělování adres v tom dělá guláš, totéž ADSL poskytovatelé ve Francii, Kanadě, GB a i O2 mění u ADSL přípojek pravidelně adresy. Nemluvě o tom, když člověk používá NTB a bývá v různých firmách, kde mají různé adresní prostory. Zde to u mě jistí VPNka, ale kolik lidí s ní umí pracovat bez problémů a už jsem se setkal s firmama, kde byl odchozí VPN provoz defaultně blokován...
Na začátku se jeví problém jako jednoduše řešitelný, ale když se vezmou v potaz všechny používané druhy provozu/uživatelů, pak to není jednoduché...

Právě proto se snažím problém zjednodušit a z toho vyplynul můj prvotní požadavek na stanovení metodiky/pravidel pro detekci DoS UDP útoku, zařazení útočníka do black listu, odsřelení již navázaných spojení a informování o útoku via mail. Pokud by někdo znal řešení těchto jednotlivých bodů výsledek plně vyhovuje a je velmi obecný => spolehlivý, přehledný a minimálně omezující uživatele.

PetrP

[pepulis]

Globálně řešit omezení počtu spojení u UDP nejde, takže jediné co lze je omezit provoz na počet paketů za nějakou časovou jednotku. Jak moc by tohle bylo použitelné netuším. Šlo by udělat to, že kdo překročí daný počet pkaetů, zapíše se do address listu a pravidlem ve fw se automaticky zakáže. Jaký provoz = počet paketů ale vyžaduje hovor, tak aby nespadnul do adress listu, asi globálně nepůjde říct, takže hrozí, že se zablokuje i ten kdo nemá. Nevím no, jak poradit .....

[Maxik]

to by se myslim dalo celkem snadno zjistit kolik staci a zbytek pridat do listu a drop.

[rteppp]

Globálně řešit omezení počtu spojení u UDP nejde, takže jediné co lze je omezit provoz na počet paketů za nějakou časovou jednotku.

Nehodlám globálně omezovat počet spojení UDP. Ano, chci natvrdo omezit na základě počtu paketů za časovou jednotku jednu konkrétní IP adresu s tím, že ji zabanuji.

Šlo by udělat to, že kdo překročí daný počet pkaetů, zapíše se do address listu a pravidlem ve fw se automaticky zakáže. Jaký provoz = počet paketů ale vyžaduje hovor, tak aby nespadnul do adress listu, asi globálně nepůjde říct, takže hrozí, že se zablokuje i ten kdo nemá. Nevím no, jak poradit .....

Ano, to je základní úvaha, ale opět se ptám: Jak detekovat počet UDP paketů za časovou jednotku z jedné odchozí adresy? TO je pro mě jádro pudla, na TCP vím jak to udělat, ale jak to udělat nad UDP pakety nikolivěk
Co se týče počtu paketů ohledně hovoru, je to tak, že na portu 5060 se jen dohodne spojení, to pak probíhá jinde. DoS v tomto případě směřuje a) k vyřazení služby nebo b) rozlousknutí přihlašovacího hesla interního účtu na PBX a následně jeho "vytunelování" vytelefonováním do zahraničí = klasická krádež alá dialer apod. Problém je to, že při přihlašování telefonu na PBX se neposílá heslo, ale pouze žádost o přihlášení, PBX odpoví hashem hesla, ten je v telefonu "zpracován" a odeslán zpět do PBX, která zná správnou opověď na zaslaný hash a pokud je odpověď správná je přihlášení autorizováno.... Z výše uvedeného vyplývá, že při přihlášení telefonu na PBX se vymění pouze pár paketů a je vyřízeno, kdežto útočník musí útočit hrubou silou....
Potřebuji monitorovat pouze jednu veřejnou IP na příchozím směru, jeden port (5060), velký provoz překračující nějaký limit zmonitorovat, detekovat útočníka, zapsat na black list, blokovat jej a odeslat jeden avizo mail.....


PetrP

[pepulis]

Omezeni poctu paketu za urcitou dobu: forward src adress napr. 192.168.1.2 protokol udp, v zalozce extra nastavit limit rate 50 / sec burst 5. Tohle jestli se nepletu omezi pocet udp paketů na 50 za sec. Kdybych se pletl, opravte mě.

Ty si to upravis jen podle sebe - tj. src bude cokoliv = nenastaveno a dst adress bude verejna ip tve voip, zbytek bude stejny ...

[Selič]

Globálně řešit omezení počtu spojení u UDP nejde, takže jediné co lze je omezit provoz na počet paketů za nějakou časovou jednotku. Jak moc by tohle bylo použitelné netuším. Šlo by udělat to, že kdo překročí daný počet pkaetů, zapíše se do address listu a pravidlem ve fw se automaticky zakáže. Jaký provoz = počet paketů ale vyžaduje hovor, tak aby nespadnul do adress listu, asi globálně nepůjde říct, takže hrozí, že se zablokuje i ten kdo nemá. Nevím no, jak poradit .....

Na linuxu to funguje, konkretne to funguje v distribuci dd-wrt. na Ciskach neco takoveho taky funguje. Tam se za jedno UDP spojeni bere komunikace z/na jedne unikatni IP na/z unikatni port s nejakym timeoutem. Kdyz pak treba nejaky trojan zurive skanuje nejaky server nebo dela DoS utok, tak se necha treba po 50 navazanych spojenich za sekundu zariznout a je klid. Podle vypisu UDP z trackingu mikrotiku by to v nem melo fungovat/ jit implementovat taky.
Obecne se mi zda sprava UDP paketu v mikrotiku a hlavne ve wireless nejaka nedovarena.

[rteppp]

Podle vypisu UDP z trackingu mikrotiku by to v nem melo fungovat/ jit implementovat taky.
Obecne se mi zda sprava UDP paketu v mikrotiku a hlavne ve wireless nejaka nedovarena.

O.K.
Otázka zní: JAK?

Nezajímá mě bezdrát, konektivitu mám via drát, osazen je Mikrotik bez možnosti změny za WRT, můžu jít pouze výše, tj. malé Cisco (zatím se mi nechce z různých důvodů), ale ne dolů, takže opakuji, jak implementovat testování limitního počtu UDP paketů za časovou jednotku s následným zápisem do blacklistu a blokováním?

PetrP