Vlákno názorů k článku DDoS útok na servery Internet Info: pohled administrátora od Dr.Str. - Jednoho krásného dne snad někoho napadne vytvořit automatický...
-
Karel (neregistrovaný)
Já bych tuhle službu chtěl. Nebo alespoň něco podobného, co by mi dokázalo nabonzovat okamžik, kdy chytnu breberku a stanu se součástí botnetu. Zkrátka antivirus na straně providera, co bude analyzovat můj outbound traffic a dá vědět, pokud bude divný.
Existuje třebas nějaký router, který by tohohle byl schopen?
-
Na libovolném routeru s podporou OpenWRT by teoreticky mělo jít pustit nějaké IDSko, jako je třeba Suricata, Snort nebo Sagan, na odchozí provoz.
Jedinou reklamu na Turris, který má ochranu proti známým zdrojům malware (plus zdrojová data pro pravidla na FW), zatím vidím od Vás :).
Co se týče ISP, tak osobně znám člověka, kterému UPC odpojilo přípojku do doby, než si vyčistí počítač od malware... Ale už je to pár let zpátky.
-
Ondřej CaletkaZlatý podporovatelKdyž vidím to množství iptables pravidel, říkám si, jestli nemáte v plánu začít používat ipset. Při představě, že pro každý paket chudák Turris prochází tisícovku pravidel mi je ho trochu líto :) A skoro bych se bál že takhle už to gigabit neuroutuje.
-
Yenya (neregistrovaný)
Už jsem měl pročtenou skoro celou diskusi a říkal jsem si, že o ipsetu sem teda budu muset napsat, ale dva příspěvky před koncem (aktuálně) jsem se dočkal. Ano, ipset je v podstatě jediná rozumná cesta, jak na Linuxu blokovat větší množství IP adres.
Dosud jsme používali ip rules (viz man ip), což kvůli routing cachi bylo docela rychlé, ale v posledních kernelech se myslím routing cache nějak ruší, takže se to vrátilo k sekvenčnímu procházení pro každý packet zvlášť. Přešli jsme na ipset a to pomohlo.
No a když už tady píšu naše zkušenosti, tak dost pomáhá síťová karta. Je potřeba mít síťovou kartu s multiqueue (pozná se tak, že typicky zabírá víc než jedno přerušení, má třeba 16 front na vstupu a 16 na výstupu). Pak se jednotlivá přerušení namapují každé zvlášť na samostatné jádro (zápisem do /proc/irq/<číslo>/smp_affinity) a zpracování příchozích packetů může běžet paralelně na více jádrech.
Samozřejmostí je, že by síťová karta i driver měly podporovat polling režim v případě vyššího provozu - že na konci IRQ handleru se driver podívá, jestli mezitím nepřišel další packet, a pokud jo, tak packet zpracuje, až do nějakého limitu (třeba 50 packetů). Při překročení limitu se IRQ zakáže, skončí handler, jádro má prostor na zpracování právě přišlých packetů, a až by se procesor měl přepnout do idle (volně řečeno), tak se zase případně zapne přerušení. Takto přerušení nevyžere veškerý CPU time, aniž by byl čas pak ty packety zpracovat, a navíc se ušetří opakované přerušování pro každý packet. Jde to poznat tak, že od jisté hranice s rostoucím počtem příchozích packetů začne počet přerušení za jednotku času na té síťové kartě _klesat_.
-Yenya, http://www.fi.muni.cz/~kas/blog/
-
Jo karty v tom hraji urcite velkou roli. Ty Broadcomy co DELL dava v podstate vsude nektere veci dilem neumi v HW a dilem neumi v ovladaci, protoze Broadcom se vyvoji kernelu nevenuje.
Mam tu dokonce tip, ktery chci nekdy vyzkouset, ze Intel 10Ge karty dokonce umi na HW urovni filtrovat pres u32, takze clovek si trochu pohraje s tc a pak uz si jen vycte pocitadla z karty, aby vedel co vsechno vubec nedorazilo do kernelu. To by dobre fungovalo na utoky, kde by byl stejny zdrojovy port nebo stejna velikost paketu. Pokud tu kartu sezenu, tak by o tom mohl byt pekny clanek.
-
Admin (neregistrovaný)
Aspoň s tou reklamou na Turris nejsem sám - všimnul jste si že se Vám do příspěvku dostaly dva reklamní odkazy? ;-)
S tím UPC to taky může být tak že dostali stížnost a pak to řešili - to musí každý ISP, ale je to něco jiného než proaktivní sledování co jejich zákazníci dělají.
-
Honza S. (neregistrovaný)
Podobne komercni reseni (byt dost drahe) uz na trhu je tusim od roku 2011, cituji User Guide :
"When Cloud Signaling is activated, Pravail APS signals to the cloud service provider (HS: e.g. ISP or scrubbing service provider) that mitigation help is needed. When the service provider begins the mitigation process, the attack that is congesting the upstream links is redirected to the cloud service’s scrubbing center. At the same time, service availability is protected and the attack traffic immediately diminishes or disappears altogether from your network's access links. The service provider mitigates the attack, and then routes the cleaned traffic back to your network.
Note: It is possible for a cloud service provider to decide not to mitigate an attack. Therefore, mitigation does not necessarily occur every time it is requested."
Samozrejme to neni vselek a je to zamerene dle meho hlavne na volumetricke utoky. Prakticke zkusenosti s tim ale zatim nemam.
ČLÁNKY DO MAILU