Názory k článku
Akamai odrazil rekordní útok, přicházelo při něm 809 milionů paketů za sekundu
-
Smazaný profil
1 byte nákladu, urcite? Payload, se bezne preklada jako "zatez". https://cs.wikipedia.org/wiki/Paket
-
Filip JirsákStříbrný podporovatelV mezinárodní lodní dopravě by „zátěž“dávalo mnohem větší smysl, než u paketu. Myslím, že náklad na lodi má nějakou tíhu, virtuální bajty nikoli.
-
Filip JirsákStříbrný podporovatel
Doporučuju ke zvážení, zda z tvrzení „A má mnohem větší smysl, než B“ nutně vyplývá, že B nemá vůbec žádný smysl.
Mimochodem, váš příspěvek podporuje názor, že překlad „náklad“ je zrovna v tomto případě lepší, než „zátěž“. Poukazujete na význam slova „zátěž“, který zpomaluje práci – čím více je zátěže, tím pomaleji s ní půjde nebo pojede kůň, člověk, loď nebo procesor. Jenže princip útoku je přesně opačný – náklad tam nemusí být prakticky žádný, na jeho velikosti totiž nezáleží.
-
Především si myslím, že to v češtině není nijak ustálené. Technici jsou líní hledat česká slova, dávají i v česky psaném textu přednost anglickým. Vypadá to příšerně, je to nekulturní, ale mnozí to považují za přednost a atribut jejich vzdělání.
Dělá mi radost, když vidím snahu sdělovacích prostředků užívat náš jazyk. Náklad paketu je podle mě v češtině výstižnější, než zátěž. V jiných oborech může být zátěž naopak příhodnějším překladem.
Hlavně je konina takovou okrajovost vůbec řešit :).
-
Pro "paket" v našem oboru nemáme žádnou "víc" českou alternativu (ani mě nenapadá). "Paket" už je přijatý i do slovníku spisovné češtiny. Je to navíc tak moc rozšířené slovo, že je dost nepravděpodobné, že by se začalo místo něj prosazovat slovo jiné. Opisem (s neznatelně jiným významem) by se snad dal použít "datagram", což by byl tvar Čechovi blízký (srov. "telegram"), ale nebylo by to o nic víc české slovo.
-
Je pozoruhodné, jak se umíte kousnout na jednom slově. Zvlášť, když je to slovo běžné, české a v téhle situaci naprosto srozumitelné. Odmítám plnit české texty zbytečnými anglikanismy, pokud je možné najít trefný a vhodný český výraz. Nebudu psát kernel, když máme jádro, nebudu psát kompjůtr, když máme počítač a nebudu psát payload, když můžu napsat náklad. Je to můj text, já volím slova. Budete se s tím muset smířit nebo si napsat vlastní text s drajvrama, kernelem, defaultama a opšnama.
-
Tak teď nevím, zda jste vůbec pochopil, o čem je tu řeč. Podezřívat mě z používání „s drajvrama, kernelem, defaultama a opšnama“ může jen nepozorný čtenář, nebo demagog.
Podstata problému spočívá ve skutečnosti, že prostým překladem anglického termínu bohužel NEZÍSKÁME kýžený český termín, naopak hrozí zavlečení matoucích okřídlených výrazů, ve kterých si anglická terminologie tolik libuje.
Už je to jasné? -
Mě spíš zaujalo UDP :-)
*UDP* na port 80? To já už bych posílal radši TCP SYN :-) A popravdě... na portu 80 poběží nejspíš jenom nějaký jednořádkový redirect na HTTPS na portu 443... Velmi energické plácnutí do vody... nebo ne? Žeby někdo testoval konkrétně QUIC?
https://en.wikipedia.org/wiki/QUIC -
Díky za reakci, zjevně máte přehled. Měl byste čas to trochu rozvést? Mě totiž překvapuje, že čekáte obranu proti SYN flood "všude po cestě". Já bych to na základě svých reznoucích zkušeností viděl trochu jinak :-)
Pokud začnu na konci u zombíka = na napadeném počítači u někoho doma nebo v malé firmě, tak první po cestě bude nějaký SoHo router. Ten určitě dělá NAT/maškarádu směrem ven, takže stateful inspection a connection tracking tabulka tam bude určitě. Ale rate-limit na TCP SYN směrem ven? Pochybuju. Ačkoli je možné, že i ten jeden zombík malému SoHo routeru pěkně ucpe conntrack tabulku, zejména pokud bude střídat zdrojové TCP porty = tomu bych rozuměl.
Pokud není po cestě od zombíka do divokého internetu žádný další NAT, tak už bych tam tím méně čekal box, který bude mít sílu, dělat jednotlivým SoHo koncákům rate-limit proti SYN floodingu. (Možná jsem mimo branži už moc dlouho.) Pokud to neudělá CPE, tak osobně na access vsázím míň. Páteře se tím myslím už vůbec nezabývají (core, provider edge a podobné routery) - ledaže v dnešní době SDN by měly API pro selektivní filtrování příchozího trafficu na konkrétní lokální cíle, na požádání. To si cucám z prstu.
Jak se blížíme k serverovému konci tak uznávám, že banky a podobné finanční instituce mívají nejeden firewall, a nebývají to firewally levné :-) Ovšem pokud se týče samotného webového "serveru v první linii", tak před ním může být předsunutý cca 1 firewall. Pokud vůbec nějaký. Konkrétně když slyším AKAMAI, tak mi to zní spíš jako nějaký cloud/farma, nájemné paralelizované řešení stavěné na vysokou průchodnost. Tam bych před serverem nečekal předsunutý klasický dýchavičný firewall - ale co třeba content switch? Nějaký load-balancer, patrně postavený na HW akceleraci. A souhlas, ten by asi mohl umět reagovat na SYN flood.
Takže nakonec, pokud srovnám možnost zaútočit na port 80 TCP, vs. port 80 UDP, tak při použití TCP SYN floodingu aspoň trochu potrápím connection tracking na straně serveru (resp. v předsunutém content switchi) - kdežto UDP na port 80 bude padat rovnou do /dev/null, pokud náhodou není ve firewallu / content switchi explicitně nakonfigurován jako podporovaný. Pokud UDP není podporovaný, tak jeho dropnutí je výpočetně mnohem míň náročné, než reakce na TCP syn flooding na bázi rate-limitu navázaného na connection tracking.
