DNS Bordel

[Majklik]

tohle vypadá velmi dobře
arcw5z1.gm73ljplkqphswshw5v8vjkd2cv.uhb613mtd3v19wkiu2.3mzwlt2lerb77trs2t3rqde725.kwn7e5ksfeqsmrrk1srt9u95fb.avqs.mcafee.com

Ano, to vypadá dobře. Říká to, že tvůj zákoš používá McAfee a ten se ptá domů na každý otvíraný soubor, co o něm soudí tatínek. Je v tom hash souboru, jméno, id kdo se ptá.... Mít v síti živý fileserver s McAfee produkty na něm, tak takovýhle dotazů jedou desítky/sec...
Stejnou techniku používá spousta dalších aplikací. Některé takto přímo dělají IP tunel skrz DNS dotazy.

[jarda.jezek]

Takto šifruje CIA instrukce pro al.kajdu a předává je přes mrtvé schránky - cache DNS serverů.

Sent from Android by Tapatalk.

[hapi]

já nechci bejt zase za toho prudiče ale tohle vlákno pěkně ukazuje jakej máme všichni v síti bordel. Žádný ošetření podobných věcí atd.. Jak můžete mít z venku otevřený něco jako DNS resolvery? takhle právě pěkně vznikaji tyhle průsery. Ještě se vsadim že nemáte blokovaný spoofingnutý IPčka. Jistě že nemáte jelikož dělám po republice tunely a v pohodě odesílám cizí IP adresou data do netu a vraceji se mi přes datacentrum skrz tunel zpět. To jsou prostě základy. Dokonce i z polska nebo ruska se vraceji pakety s jinou ip adresou která je přitom naroutovaná v CZ a její ip adresa jako zdroj si vesele projde z ruska téměř kamkoliv. Pak se nesmíme divit že vznikají primitivně jednoduše téměř nevystopovatelný DDOS útoky protože se nedaji vyhledat ani podle zdroje jelikož určitě odtud nepocházejí a tečou určo z úplně jinýho směru.

Tim fakt nechci prudit ale je tu dost dlouholetých ISPíků a jejich vzdělávání za ta léta vůbec nikam nepokročilo.

Majklik ví o čem mluvim, nedavno okounovy psal určité zásady který by měl mít každej ve filtru na hraničnim routeru. Některý byly teda až schyzofrení ale neméně důležitě v těžkých časech jako jsou třeba ty když vám dodavatel konetivity odstřihne DNSko

[net.work]

A co tak radeji mene kecat a zalozit topic (treba v sekci pro zacatecniky) s tim co by mel mit kazdy ve FW? Myslim ze to neni zadne chranene know-how a ve vysledku to muze byt uzitecne vsem, treba prave pro zmirneni zminovanych ddos utoku...

[Dalibor Toman]

já nechci bejt zase za toho prudiče ale tohle vlákno pěkně ukazuje jakej máme všichni v síti bordel. Žádný ošetření podobných věcí atd.. Jak můžete mít z venku otevřený něco jako DNS resolvery?

tohle je treba u nas dano jednak historicky a jednak nejakou filozofii k tomu, co povazujeme za pripojeni k Internetu. Zakaznik ma verejnou IP adresu a teoreticky by mel mit moznost provozovat si sam cokoliv bez omezeni. Ano je to svym zpusobem z dnesniho pohledu naivni a ted uz bych nektere tyhle veci delal jinak. Ale pokud mas historicky defaultne neco povoleno tak to predelat do defaultne zakazano neni bezbolestne - problem zjistit , kdo si uz (dobre nastaveny) vlastni DNS server rozebehl apod. Takze radsi vymyslim zpusob jak detekovat zlobivce (analyza provozu ze zaznamu, ktery stejne vsichni povinne ukladame. Aspon se k necemu hodi)
Navic, co vsechno mam defaultne zakazat? Delat stavovy firewall na vsechny zakazniky? Dekuji pekne. Zatim se stale snazime se poskytovat pripojeni k Internetu a ne jeho nahrazku. A jsem rad, ze jsem se na gatewayich zbavil connection trackingu a usetril peknych par procent vykonu na routing atd.
Vcera to byl SMTP provoz, dneska DNS a zitra co?
BTW: Blokujes NTP (123) zmerem k zakaznikum? Ten je pro utocnika jeste vyhodnejsi k amplification utoku nez DNSko. Na druhou stranu NTP serveru zase sezene (snad) podstatne mene nez DNS serveru
A pri analyze jsem zjistil, ze mame klienty, jejichz resolver posila DNS request packety z portu 53 - takze pausalnim filtrem bych je odstrihl taky. Nemam potrebu nekomu vysvetlovat, ze ta krabicka, co si koupil pred 5ti lety a celou dobu s ni byl spokojenej je nyni na prd a ma si koupit novou...

takhle právě pěkně vznikaji tyhle průsery. Ještě se vsadim že nemáte blokovaný spoofingnutý IPčka.

tohle taky nechamu, ze si to spousta ISP nenastavi.
Poslat jim 'par' packetu se SRC z jejich rozsahu a oni si pak pri hledani problemu (pokud to zvladnou) nastavi treba i ten odchozi antispoofer filter

[ikk]

Já se připojuji s prosbou o nové téma, kde by se řešily vhodné pravidla pro FW. Myslím, že by tohle pomohlo spoustě lidí a sítí.

[_zp]

Já se připojuji s prosbou o nové téma, kde by se řešily vhodné pravidla pro FW. Myslím, že by tohle pomohlo spoustě lidí a sítí.

Antispoof filtering se dela na routerech, ne na firewallech. A nejjednodussi je to na boxech jako je cisco, kde se proste na kazdem rozhrani smerem k zakaznikum napise "ip verify unicast source reachable-via rx", problem to neni ani na linuxu, kde se pro vsechna rozhrani smerem k zakaznikum (ale jenom smerem k zakaznikum, smerem do upstreamu to nesmite naopak zapomenout vypnout) "echo 1 >/proc/sys/net/ipv4/conf/ethX/rp_filter" (rozhodne tam nedavat hodnotu 2, loose mode nic moc neresi).

Jo a neni spatne si taky prostudovat RFC, v tomto pripadne napriklad RFC2827: http://tools.ietf.org/html/rfc2827.html

[hapi]

přece všichni máme jeden hlavní router kde nastavim globálně pro všechny že se může forwardovat z vnitřku ven pouze adresy používající moje síť. Takže typicky 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 100.64.0.0/10 a pak ještě třeba doplnit své veřejné subnety. Tim by se měl spoofing zamáznout.

[_zp]

přece všichni máme jeden hlavní router kde nastavim globálně pro všechny že se může forwardovat z vnitřku ven pouze adresy používající moje síť. Takže typicky 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 100.64.0.0/10 a pak ještě třeba doplnit své veřejné subnety. Tim by se měl spoofing zamáznout.

Ne tak docela. Utocnik muze podvrhnout i adresu, ktera patri jinemu zakaznikovi vasi site.

[Dalibor Toman]

Já se připojuji s prosbou o nové téma, kde by se řešily vhodné pravidla pro FW. Myslím, že by tohle pomohlo spoustě lidí a sítí.

Antispoof filtering se dela na routerech, ne na firewallech. A nejjednodussi je to na boxech jako je cisco, kde se proste na kazdem rozhrani smerem k zakaznikum napise "ip verify unicast source reachable-via rx", problem to neni ani na linuxu, kde se pro vsechna rozhrani smerem k zakaznikum (ale jenom smerem k zakaznikum, smerem do upstreamu to nesmite naopak zapomenout vypnout) "echo 1 >/proc/sys/net/ipv4/conf/ethX/rp_filter" (rozhodne tam nedavat hodnotu 2, loose mode nic moc neresi).

Jo a neni spatne si taky prostudovat RFC, v tomto pripadne napriklad RFC2827: http://tools.ietf.org/html/rfc2827.html

tak zrovna rp_filteru v Linuxu bych si dal pozor zvlaste pak u boxu, co jsou multihomed a nastavil ho na vsech interfacech rp_filter=0. Dost spatne se to pak hleda, kdyz rp_filter zacne zahazovat packety - neni to nikde videt. V tomto smeru je jeste take zajimavy zdroj potizi arp_announce nastaveny na defaultni 0

Co se tyce cisca 'ip verify...' asi nebude (nepouzivam tak si nejsem jisty) moc fungovat na skutecnem hranicnim routeru (kde pobezi BGP), pac vsechny IPcka budou v routovaci tabulce.

Takze preferuju jak v Linuxu tak na ciscu stary dobry firewall. Tedy iptables resp ACL. To udela to co si nastavim a je to zretelne a monitorovatelne (countery atd). A divny SRC IPcka je dobre seknout take hned na zarizeni u zakaznika (povolit odchod jen jemu preddelenho IP jako SRC v packetech)

Navic rp_filter ani 'ip verify..' neresi druhou cast problemu - a to zamezeni prichodu mych IPcek ze sveta.

[hapi]

přece všichni máme jeden hlavní router kde nastavim globálně pro všechny že se může forwardovat z vnitřku ven pouze adresy používající moje síť. Takže typicky 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 100.64.0.0/10 a pak ještě třeba doplnit své veřejné subnety. Tim by se měl spoofing zamáznout.

Ne tak docela. Utocnik muze podvrhnout i adresu, ktera patri jinemu zakaznikovi vasi site.

to asi těžko když natují naše sxt jednotky který chtě nechtě přeloží src adresu na naší. hmm, to pak celej spoofing v naší síti nemůže fungovat když se přeloží na naše adresy ale jde spíše o veřejný klienty s veřejknou na stroji.

[_zp]

problem to neni ani na linuxu, kde se pro vsechna rozhrani smerem k zakaznikum (ale jenom smerem k zakaznikum, smerem do upstreamu to nesmite naopak zapomenout vypnout) "echo 1 >/proc/sys/net/ipv4/conf/ethX/rp_filter"

tak zrovna rp_filteru v Linuxu bych si dal pozor zvlaste pak u boxu, co jsou multihomed a nastavil ho na vsech interfacech rp_filter=0. Dost spatne se to pak hleda, kdyz rp_filter zacne zahazovat packety - neni to nikde videt. V tomto smeru je jeste take zajimavy zdroj potizi arp_announce nastaveny na defaultni 0

Pro jistotu jsem podstatnou cast informace zvyraznil

Co se tyce cisca 'ip verify...' asi nebude (nepouzivam tak si nejsem jisty) moc fungovat na skutecnem hranicnim routeru (kde pobezi BGP), pac vsechny IPcka budou v routovaci tabulce.

Bude. Loose mode uRPF je "ip verify unicast source reachable-via any" a ten je skutecne lepsi nepouzivat.

Takze preferuju jak v Linuxu tak na ciscu stary dobry firewall. Tedy iptables resp ACL. To udela to co si nastavim a je to zretelne a monitorovatelne (countery atd). A divny SRC IPcka je dobre seknout take hned na zarizeni u zakaznika (povolit odchod jen jemu preddelenho IP jako SRC v packetech)
Navic rp_filter ani 'ip verify..' neresi druhou cast problemu - a to zamezeni prichodu mych IPcek ze sveta.

Jiste. Proto je rozumnym resenim kombinace obeho (ACL+uRPF). Samotne ACL maji jednu zasadni chybu a sice, ze to je reseni, ktere velmi obtizne skaluje.

[Majklik]

Jenomže rp filter je v ROS celkem limitován, jednak stále je jen pro IPv4 a ne i pro IPv6 a pak se dá nastavit jen hromadně, nejde ho dát pro jednotlivá rozhranní.

[to asi těžko když natují naše sxt jednotky který chtě nechtě přeloží src adresu na naší. hmm, to pak celej spoofing v naší síti nemůže fungovat když se přeloží na naše adresy ale jde spíše o veřejný klienty s veřejknou na stroji.

Tohle, koncová jendotka, kde mám jeden port do lAN a druhý do netu je ideální místo pro rp-filtr tak, jak jej umí ROS6. Při zapnutí (/ip settings set rp-filter=strict) zkrátka z LAN ven nepustí/nenatne nic, co nemá IPčko patřící do LAN nebo na co není do LAN existující routa. Taktéž brání podvržení zdrojové adresy odpovídající LAN straně z WAN strany dovnitř.
Pro IPv6 nutno řešit firewallem.

[Majklik]

K tomu DNS, od kterého to dost uteklo - nepoužívejte tu DNS cache v ROSu, je těžce pomalá a dost podivně implementovaná z pohledu DNS protokolu. Jo, koncové domácí RB, kde je zaplá (s patřičným firewall pravidlem bránícím dotazům zvenčí) nebo malá firma, tak OK. Ale jak to použijete pro pár set lidí, které tam nasměřujete, začne problém. Hlavně ve chvíli, kdy do toho začne i jen legálně bušit některá z apliakcí, co dneska přes DNS sosá kde co, např výše uvedený McAfee, to ji pak odvaříte.
Na zákazníky to, jak psal hapi - malej linux (paranoidně 2x), na tom unboud/bind dle preference, jako rekurzivní resolver (dneska asi včetně aktivního DNSSEC validujícícho resolveru) a na to nasměrované koncové domácí routery přímo. Případně v DHCP můžou koncové rotuery posílat koncové počítače přímo na ty linux resolvery - to v případě, že si někdo donase domů firemní notebook s Win7+, co je členem MS domény s debilně nastavneou DNS politikou, že DNSSEC na vše.

Jinak k tomu filtrování. Ano, měl bych hlídat to, co mi chodí od zákanzíků, že od nich jde jen jim přidělená IP/blok (ať už ne/veřejná), aby si nedělali porazy na sebe nebo na mě a taktéž tu stranu uplinku. Pokud mám tu jednoduchou konfiguraci, kde mám jednu hlavní bránu a jedene uplink ven, tak se to dá dobře nastavit. Jenom pokud brána dělá i NAT, tak je problém, žeo bčas pouští ven nenatnutý provoz. Proto ten filtr dát třeba do switche na uplink linku, který ty pravidla ustojí v HW. Nepusítm k sobě paket, kde zdrojová IP je některý speciální blok nebo moje vlastní, nepustím k sobě paket, kde cílová IP není mě přidělená, taktéž opačným směrem nepustím ven nic, kde zdrojová adresa není moje veřejná (likvidace selhaného NATu a spoofingu) a nepustím ven ani nic, kde cílová adresa je nějaqký ten speciál.
Jde ot řešit vícero způsoby, ať už RPF, blackhole routing, firewall, ..., ale je vohndé to nějak nastavit. Čili dle BCP38/RFC2827 a pro seznam speciálních prefixů BCP153/RFC6890.

[shooter]

Já se připojuji s prosbou o nové téma, kde by se řešily vhodné pravidla pro FW. Myslím, že by tohle pomohlo spoustě lidí a sítí.

+1