Resolvující DNS server má drtivá většina domácích routerů. Problém je v tom, pokud ten server vyřizuje i dotazy, které přišly z internetu (ne jen ty, které přišly z vnitřní sítě). Nakonfigurovat takhle jde asi většina z nich, otázka je, jaké je výchozí nastavení (které většina lidí nemění). Netýká se to tedy konkrétního modelu, ale prakticky všech routerů.
Pro provozovatele toho routeru to bohužel moc velký problém není, stejně jako když rozesílá spam - jenom mu to mírně zatěžuje linku (DNS ještě méně, než spam). Problém je to samozřejmě pro toho, na koho je útok zacílen.
Google má asi servery ošetřeny tak, aby k zesilujícímu útoku nešly použít. A i kdyby šly, DDoS útok pocházející z jedné nebo dvou IP adres není žádný DDoS útok. Cíl útoku by prostě pakety z 8.8.8.8 a 8.8.4.4 poslal do /dev/null a měl by problém vyřešen.
Problémy to také dělá provozovatelům těch resolvujících DNS serverů, protože pokud DNS servery domény použité pro útok neodpovídají, rychle se zaplní fronta požadavků a server pak nezvládá vyřídit normální provoz.
Strkat do logovacich polickek apostrofy a zkouset oblafnout praci nekoho kdo neumi spravne napsat a spustit SQL dotaz je out. Koukam ze dnes se tam davaji mezery a obchazi se prace nekoho kdo neumi napsat IF :-)
Mozna mam spatnou predstavivost, ale nenapada mne, jak takovou chybu udelat omylem. Leda by pokrok dospel uz tak daleko, ze objektove orientovani maniaci dokazali pomoci ruznych dedicnosti, rozhrani a syntaktickych cukriku zatemnit a ucinit nedeterministickou i takovou vec jakou je kontrola hesla :-(
Já už podobné chyby viděl. Zdrojem je fakt, že programátor zadaný text prožene funkcí trim a výsledek použije v podmínce. V řadě databázových implementací pokud trim dostane jen text s mezerami, tak vrací null a nikoliv prázdný řetězec.
Nevěřil byste kolik programátorů pracujících s SQL a podobnými technologiemi netuší, co je výsledkem "IF a != b" pokud je jedno z toho null. Už několikrát se mi stalo, že mi nový kolega ukazoval kus kódu, který se nespustil ani s podmínkou rovno, ani s nerovno, a on nechápal proč. No prostě proto, že podmínka s null není nikdy rovno ani nerovno, jejím výsledkem je také null.
Bývaly doby, kdy podobné triky byly známkou dobrých programátorů. Zkracovalo to zápis, šetřilo to místo a kolikrát to i bylo rychlejší. Ale někdy kolem přelomu tisíciletí to vyšlo z módy a dnes by za to řada lidí zabíjela.
Kde to má stále místo jsou různé soutěže (co vše se dá nacpat do 256 bytů) a embedded systémy, kde i dnes jde často o každý byte nebo takt. Vzpomínám na to s nostalgií.
Jenže tohle byl opravdu prase programátor.
Jednak porovnání s konstantou je většinou rychlejší než porovnání dvou hodnot, a pak, když jsem ten program přepsal tak, že byl čitelný a přitom efektivní, běhal šestkrát rychleji (a protože to byla nějaká složitá analýza databáze, tak to znamenalo, že místo dvou dnů to stihli za jednu směnu).
Dneska je v mode si na to porovnani vytvorit objekt, prislusny konstruktor a destruktor ... a samozrejme alespon nekolik metod. Vstupy se pak zasadne proveruji tak, ze se zavola metoda do ktery se jako parametr flakne ten vstup, a ceka se, jestli to vyvola vyjimku. Kdyz ne ... nastava po par dnech/tydnech/mesicich ... velka divenice, co ze to tam vklada za hovadiny, a kde ze sou vsechna ta data.
Checknout si jeste pred jakymkoli pouzitim, ze to cislo ... je vazne cislo ... to neni dostatecne khul a in.
No, tady jde buď o nemyslící programátory, nebo o programátory, kteří předpokládají nemyslící uživatele, kteří cut&pastují uživatelské jméno a heslo z textového souboru, a občas při tom vezmou i mezeru okolo. Typicky k tomu dochází tak, že se zachází stejně s heslem jako s uživatelským jménem (což je ta hloupost).