Tantara momba ny fonosana DNS tsy hita avy amin'ny fanohanana ara-teknika Google Cloud

Avy amin'ny Google Blog Editor: Efa nanontany tena ve ianao hoe ahoana no fomba itondran'ny injeniera Google Cloud Technical Solutions (TSE) ny fangatahana fanohananao? Ny Injeniera Fanohanana Teknika TSE dia tompon'andraikitra amin'ny famantarana sy fanitsiana ireo loharanon'ny olana ambaran'ny mpampiasa. Ny sasany amin'ireo olana ireo dia tena tsotra, fa indraindray ianao dia mahita tapakila izay mitaky ny sain'ny injeniera maromaro indray mandeha. Amin'ity lahatsoratra ity, ny iray amin'ireo mpiasan'ny TSE dia hilaza amintsika ny olana iray tena sarotra tamin'ny fanaony vao haingana - tranga tsy misy fonosana DNS. Ho hitantsika ato amin'ity tantara ity ny fomba nandaminan'ireo injeniera ny toe-javatra, ary inona ireo zava-baovao nianarany nandritra ny fanamboarana ilay fahadisoana. Manantena izahay fa ity tantara ity dia tsy hanabe anao fotsiny momba ny bibikely lalim-paka, fa manome anao koa ny fomba fiasa amin'ny fametrahana tapakila fanohanana amin'ny Google Cloud.

Ny famahana olana dia sady siansa no zavakanto. Izany rehetra izany dia manomboka amin'ny fananganana petra-kevitra momba ny anton'ny fitondran-tena tsy manara-penitra ao amin'ny rafitra, ary avy eo nozahana ny heriny. Na izany aza, alohan'ny handrafetana petra-kevitra iray, dia tsy maintsy mamaritra mazava sy mamolavola ny olana isika. Raha toa manjavozavo loatra ilay fanontaniana, dia tsy maintsy mandinika tsara ny zava-drehetra ianao; Ity no "art" amin'ny famahana olana.

Eo ambanin'ny Google Cloud, dia lasa sarotra be ny dingana toy izany, satria miezaka mafy ny Google Cloud mba hiantohana ny tsiambaratelon'ny mpampiasa azy. Noho izany, ny injeniera TSE dia tsy manana fahafahana hanitsy ny rafitrao, na ny fahafahana mijery ny fandrindrana amin'ny ankapobeny tahaka ny ataon'ny mpampiasa. Noho izany, mba hitsapana ny hevitsika rehetra, tsy afaka manova haingana ny rafitra izahay (injeniera).

Ny mpampiasa sasany dia mino fa hanamboatra ny zava-drehetra toy ny mekanika amin'ny serivisy fiara izahay, ary alefaso aminay fotsiny ny id amin'ny milina virtoaly, fa raha ny marina, ny dingana dia atao amin'ny endrika fifampiresahana: fanangonana vaovao, fananganana sy fanamafisana (na fandavana) vinavina, ary, amin'ny farany, ny olana momba ny fanapahan-kevitra dia mifototra amin'ny fifandraisana amin'ny mpanjifa.

Olana resahina

Androany dia manana tantara misy fiafarana tsara isika. Ny iray amin'ireo antony mahomby amin'ny famahana ny raharaha natolotra dia ny famaritana mazava tsara ny olana. Eto ambany ianao dia afaka mahita ny dika mitovy amin'ny tapakila voalohany (voaova mba hanafenana fampahalalana tsiambaratelo):

Ity hafatra ity dia misy fampahalalana mahasoa maro ho antsika:

• VM manokana voatondro
• Ny olana mihitsy no voalaza - DNS tsy mandeha
• Aseho ny toerana misy ny olana - VM sy container
• Ny dingana nataon'ny mpampiasa hamantarana ny olana dia aseho.

Ny fangatahana dia voasoratra ho "P1: Critical Impact - Service Unusable in production", izay midika hoe fanaraha-maso tsy tapaka ny toe-javatra 24/7 araka ny drafitra "Araho ny Masoandro" (azonao atao ny mamaky bebe kokoa momba ny laharam-pahamehana amin'ny fangatahan'ny mpampiasa), miaraka amin'ny famindrana azy avy amin'ny ekipa mpanohana ara-teknika iray mankany amin'ny iray hafa isaky ny fiovan'ny faritra. Raha ny marina, tamin'ny fotoana nahatongavan'ny olana tamin'ny ekipanay tao Zurich dia efa nanodidina ny tany izy io. Tamin'io fotoana io dia efa nandray fepetra fanalefahana ny mpampiasa, saingy natahotra ny hiverenan'ny toe-javatra amin'ny famokarana, satria tsy mbola hita ny fotony.

Tamin'ny fotoana nahatongavan'ny tapakila tany Zurich dia efa nanana ireto fampahalalana manaraka ireto izahay:

• Hevitra ato Anatiny /etc/hosts
• Hevitra ato Anatiny /etc/resolv.conf
• famaranana iptables-save
• Nangonin'ny ekipa ngrep pcap file

Miaraka amin'ity angona ity dia vonona ny hanomboka ny "fanadihadiana" sy ny famahana olana izahay.

Ny dingana voalohany ataontsika

Voalohany indrindra, nanamarina ny diary sy ny satan'ny mpizara metadata izahay ary nahazo antoka fa mandeha tsara izy io. Ny mpizara metadata dia mamaly ny adiresy IP 169.254.169.254 ary, ankoatra ny zavatra hafa, dia tompon'andraikitra amin'ny fanaraha-maso ny anaran-tsehatra. Nanamarina indroa ihany koa izahay fa ny firewall dia miasa tsara amin'ny VM ary tsy manakana ny fonosana.

Karazana olana hafahafa izany: nolavin'ny fisavana nmap ny hevi-dehibenay momba ny fahaverezan'ny fonosana UDP, noho izany dia nahita safidy sy fomba maro hafa hijerena azy ireo izahay:

• Voafantina ve ny fonosana? => Hamarino ny fitsipika iptables
• Tsy kely loatra ve izany? MTU? => Jereo ny vokatra ip a show
• Misy fiantraikany amin'ny fonosana UDP na TCP ihany koa ve ny olana? => Mandroaka dig +tcp
• Naverina ve ny fonosana novokarin'ny dig? => Mandroaka tcpdump
• Miasa tsara ve ny libdns? => Mandroaka strace hanamarina ny fifindran'ny fonosana amin'ny lafiny roa

Eto izahay dia manapa-kevitra ny hiantso ny mpampiasa hamaha olana mivantana.

Mandritra ny antso dia afaka manamarina zavatra maromaro izahay:

• Aorian'ny fisavana maromaro dia esorinay amin'ny lisitry ny antony ny fitsipika iptables
• Manamarina ny fifandraisana amin'ny tambajotra sy ny latabatra fitetezana izahay, ary manamarina indroa fa marina ny MTU
• Hitanay izany dig +tcp google.com (TCP) dia miasa araka ny tokony ho izy, saingy dig google.com (UDP) tsy mandeha
• Nandroaka tcpdump mbola miasa dig, hitantsika fa averina ny fonosana UDP
• Mamily fiara izahay strace dig google.com ary hitantsika ny fomba fiantsoan'ny dig sendmsg() и recvms(), na izany aza ny faharoa dia tapahina noho ny fahatapahan'ny fotoana

Indrisy anefa fa tonga ny fiafaran'ny fiovana ary voatery hampiakatra ny olana any amin'ny faritra manaraka. Ny fangatahana anefa dia niteraka fahalianana tamin'ny ekipanay, ary ny mpiara-miasa iray dia nanoro hevitra ny hamorona ny fonosana DNS voalohany amin'ny fampiasana ny maody Python scrapy.

from scapy.all import *

answer = sr1(IP(dst="169.254.169.254")/UDP(dport=53)/DNS(rd=1,qd=DNSQR(qname="google.com")),verbose=0)
print ("169.254.169.254", answer[DNS].summary())

Ity ampahany ity dia mamorona fonosana DNS ary mandefa ny fangatahana amin'ny mpizara metadata.

Ny mpampiasa dia mitantana ny code, averina ny valin'ny DNS, ary ny fampiharana dia mandray izany, manamafy fa tsy misy olana eo amin'ny sehatry ny tambajotra.

Taorian'ny “fitsangatsanganana eran-tany” hafa, dia niverina tany amin'ny ekipanay ny fangatahana, ary afindrako ho ahy tanteraka izany, mieritreritra fa mety kokoa ho an'ny mpampiasa izany raha mijanona mihodidina amin'ny toerana iray ny fangatahana.

Mandra-pahatongan'izany, manaiky am-pitiavana ny mpampiasa hanome sarin'ny sarin'ny rafitra. Vaovao tsara tokoa ity: ny fahaizana mitsapa ny rafitra ny tenako dia mahatonga ny famahana olana haingana kokoa, satria tsy mila mangataka amin'ny mpampiasa intsony aho handefa baiko, alefaso amiko ny valiny ary mamakafaka azy ireo, afaka manao ny zava-drehetra aho!

Manomboka mitsiriritra ahy kely ny mpiara-miasa amiko. Mandritra ny sakafo antoandro dia miresaka momba ny fiovam-po izahay, saingy tsy misy mahafantatra ny zava-mitranga. Soa ihany fa ny mpampiasa mihitsy no efa nandray fepetra hanalefahana ny voka-dratsiny ary tsy maika, ka manam-potoana handinihana ny olana. Ary satria manana sary izahay dia afaka manao fitsapana izay mahaliana anay. Mahafinaritra!

Mihemotra

Ny iray amin'ireo fanontaniana fanadihadiana malaza indrindra ho an'ny toeran'ny injeniera rafitra dia: "Inona no mitranga rehefa ping ianao www.google.com? Tsara ny fanontaniana, satria ny kandidà dia mila mamaritra ny zava-drehetra manomboka amin'ny akorandriaka mankany amin'ny habaka mpampiasa, mankany amin'ny kernel system ary avy eo amin'ny tambajotra. Mitsiky aho: indraindray ny fanontaniana amin'ny dinidinika dia lasa mahasoa amin'ny tena fiainana...

Manapa-kevitra ny hampihatra ity fanontaniana HR ity amin'ny olana ankehitriny aho. Amin'ny ankapobeny, rehefa manandrana mamaritra anarana DNS ianao dia mitranga izao manaraka izao:

1. Ny fampiharana dia miantso tranomboky rafitra toy ny libdns
2. Ny libdns dia manamarina ny rafitra rafitra izay tokony hifandraisany amin'ny mpizara DNS (amin'ny kisary dia 169.254.169.254, mpizara metadata)
3. Ny libdns dia mampiasa antso an-tariby mba hamoronana socket UDP (SOKET_DGRAM) ary handefa fonosana UDP miaraka amin'ny fangatahana DNS amin'ny lalana roa.
4. Amin'ny alàlan'ny interface sysctl dia azonao atao ny manamboatra ny stack UDP amin'ny haavon'ny kernel
5. Ny kernel dia mifandray amin'ny hardware mba handefasana fonosana amin'ny tambajotra amin'ny alàlan'ny interface interface
6. Ny hypervisor dia misambotra sy mampita ny fonosana amin'ny mpizara metadata rehefa mifandray aminy
7. Ny mpizara metadata, amin'ny alàlan'ny majika, dia mamaritra ny anarana DNS ary mamerina valiny amin'ny fomba mitovy

Mamelà ahy hampahatsiahy anao ny hevitra efa nodinihinay:

Hypothesis: Tranomboky simba

• Fitsapana 1: mandehana strace ao amin'ny rafitra, jereo fa ny dig dia miantso ny antso an-tariby marina
• Vokany: Antsoina ny antson'ny rafitra marina
• Fitsapana 2: mampiasa srapy hijerena raha afaka mamaritra anarana mandalo ny tranomboky rafitra isika
• Vokany: afaka
• Fitsapana 3: mihazakazaka rpm –V amin'ny fonosana libdns sy ny rakitra md5sum tranomboky
• Vokatra: ny kaody famakiam-boky dia mitovy tanteraka amin'ny kaody ao amin'ny rafitra miasa miasa
• Fitsapana 4: apetaho eo amin'ny VM ny sarin'ny rafitra fakan'ny mpampiasa raha tsy misy an'io fihetsika io, mandehana chroot, jereo raha miasa ny DNS
• Vokany: mandeha tsara ny DNS

Famaranana mifototra amin'ny fitsapana: tsy ao amin'ny tranomboky ny olana

Hypothesis: Misy hadisoana amin'ny fikandrana DNS

• Fitsapana 1: jereo ny tcpdump ary jereo raha alefa sy averina tsara ny fonosana DNS rehefa avy mihazakazaka dig
• Vokany: alefa tsara ny fonosana
• Fitsapana 2: jereo indroa ny mpizara /etc/nsswitch.conf и /etc/resolv.conf
• Vokany: marina daholo ny zava-drehetra

Famaranana mifototra amin'ny fitsapana: ny olana dia tsy ny DNS configuration

Hypothesis: simba ny fotony

• Fitsapana: mametraka kernel vaovao, jereo ny sonia, avereno indray
• Vokany: fihetsika mitovy

Famaranana mifototra amin'ny fitsapana: tsy simba ny kernel

Hypothesis: fitondran-tena diso ataon'ny tambazotran'ny mpampiasa (na ny seha-pifandraisana hypervisor)

• Fitsapana 1: Jereo ny firafitry ny firewall
• Vokany: mandalo fonosana DNS amin'ny mpampiantrano sy GCP ny firewall
• Fitsapana 2: manakana ny fifamoivoizana ary manara-maso ny fahamarinan'ny fandefasana sy famerenana ny fangatahana DNS
• Vokany: Manamafy ny tcpdump fa nahazo fonosana miverina ny mpampiantrano

Famaranana mifototra amin'ny fitsapana: tsy ao anaty tambazotra ny olana

Hypothesis: tsy mandeha ny mpizara metadata

• Fitsapana 1: jereo ny diarin'ny mpizara metadata raha misy tsy mety
• Vokany: tsy misy anomaliana ao amin'ny diary
• Fitsapana 2: Mandalo ny mpizara metadata amin'ny alàlan'ny dig @8.8.8.8
• Vokany: tapaka ny fanapahan-kevitra na dia tsy mampiasa mpizara metadata aza

Famaranana mifototra amin'ny fitsapana: tsy ny mpizara metadata no olana

Fehiny: notsapainay ny subsystem rehetra afa-tsy fandrindrana runtime!

Midira ao amin'ny Kernel Runtime Settings

Mba hanamboarana ny tontolon'ny famonoana kernel dia azonao atao ny mampiasa safidy andalana baiko (grub) na ny interface sysctl. Nijery tao aho /etc/sysctl.conf ary eritrereto fotsiny, nahita toe-javatra mahazatra maromaro aho. Tsapako ho toy ny nihazona zavatra aho, dia nariako avokoa ny firafitry ny tsy-tambajotra na ny tsy-tcp, nijanona tamin'ny firafitry ny tendrombohitra. net.core. Avy eo dia nandeha tany amin'ny toerana misy ny fahazoan-dàlana mpampiantrano ao amin'ny VM aho ary nanomboka nampihatra ny fanovana tsirairay, nifandimby, niaraka tamin'ny VM tapaka, mandra-pahitako ilay meloka:

net.core.rmem_default = 2147483647

Indro izy io, fanefena manimba DNS! Hitako ilay fitaovam-piadiana famonoana. Fa nahoana no mitranga izany? Mbola nila antony manosika aho.

Ny haben'ny fonosana fonosana DNS fototra dia amboarina amin'ny alàlan'ny net.core.rmem_default. Ny sanda mahazatra dia manodidina ny 200KiB, fa raha mahazo fonosana DNS be dia be ny mpizara anao dia azonao atao ny mampitombo ny haben'ny buffer. Raha feno ny buffer rehefa tonga ny fonosana vaovao, ohatra, satria tsy ampy ny fanodinana azy haingana ny fampiharana, dia manomboka very packet ianao. Nampitombo tsara ny haben'ny buffer ny mpanjifanay satria natahotra ny fahaverezan'ny angona izy, satria nampiasa fampiharana fanangonana metrika amin'ny alàlan'ny fonosana DNS izy. Ny sanda napetrany no ambony indrindra azo atao: 231-1 (raha apetraka amin'ny 231, ny kernel dia hamerina ny "ARGUMENT INVALID").

Tampoka teo dia tonga saina aho hoe nahoana ny nmap sy ny scapy no niasa tsara: mampiasa socket manta izy ireo! Ny socket manta dia tsy mitovy amin'ny socket mahazatra: mandingana ny iptables izy ireo, ary tsy misy buffer!

Fa maninona no miteraka olana ny "buffer be loatra"? Mazava ho azy fa tsy mandeha araka ny tokony ho izy.

Amin'izao fotoana izao dia afaka mamerina ny olana amin'ny kernel maro sy fizarana maro aho. Ny olana dia efa niseho tamin'ny kernel 3.x ary ankehitriny dia niseho koa tamin'ny kernel 5.x.

Raha ny marina, rehefa manomboka

sysctl -w net.core.rmem_default=$((2**31-1))

Nitsahatra tsy niasa ny DNS.

Nanomboka nitady soatoavina miasa amin'ny alàlan'ny algorithm fikarohana binary tsotra aho ary nahita fa niasa tamin'ny 2147481343 ilay rafitra, saingy isa tsy misy dikany amiko io isa io. Nanoro hevitra ny mpanjifa aho hanandrana io isa io, ary namaly izy fa niasa tamin'ny google.com ny rafitra, saingy mbola nanome hadisoana tamin'ny sehatra hafa, ka nanohy ny fanadihadiana aho.

Efa nametraka aho dropwatch, fitaovana tokony ho nampiasaina teo aloha: asehony tsara hoe aiza no misy fonosana iray ao amin'ny kernel. Ny meloka dia ny asany udp_queue_rcv_skb. Nisintona ny loharano kernel aho ary nanampy vitsivitsy asa printk mba hanaraha-maso hoe aiza marina no hiafaran'ilay fonosana. Hitako haingana ny toe-javatra mety if, ary nibanjina tsotra izao nandritra ny fotoana kelikely, satria tamin'izay dia nitambatra ho sary iray manontolo ny zava-drehetra: 231-1, isa tsy misy dikany, sehatra tsy miasa... __udp_enqueue_schedule_skb:

if (rmem > (size + sk->sk_rcvbuf))
		goto uncharge_drop;

Mariho tsara:

• rmem dia karazana int
• size dia karazana u16 (tsy misy sonia enina ambin'ny folo-bit int) ary mitahiry ny haben'ny fonosana
• sk->sk_rcybuf dia karazana int ary mitahiry ny haben'ny buffer izay, raha ny famaritana, dia mitovy amin'ny sanda in net.core.rmem_default

rehefa sk_rcvbuf Manakaiky ny 231, raha mamintina ny haben'ny fonosana dia mety hiteraka integer overflow. Ary satria int io, lasa ratsy ny sandany, ka lasa marina ny fepetra rehefa tokony ho diso (afaka mamaky bebe kokoa momba an'io ianao ao amin'ny rohy).

Ny fahadisoana dia azo ahitsy amin'ny fomba tsy misy dikany: amin'ny alàlan'ny fanariana unsigned int. Nampihatra ny fanamboarana aho ary namerina ny rafitra ary niasa indray ny DNS.

Ny tsiron'ny fandresena

Nalefako tany amin'ny mpanjifa ny zavatra hitako ary nalefako LKML kernel patch. Faly aho: mifanentana ny ampahany rehetra amin'ny piozila, azoko hazavaina tsara hoe nahoana no nandinika ny zavatra hitanay izahay, ary ny tena zava-dehibe dia afaka nahita vahaolana tamin'ny olana izahay noho ny fiaraha-miasa!

Tsara ny manamarika fa tsy fahita firy ny tranga, ary soa ihany fa zara raha mahazo fangatahana sarotra toy izany avy amin'ny mpampiasa izahay.

Source: www.habr.com