🥇 Mitandrema amin'ny vulnerabilité izay mitondra ny fihodinan'ny asa. Fizarana 1: FragmentSmack/SegmentSmack

Salama daholo! Dmitry Samsonov no anarako, miasa amin'ny maha mpitantana ny rafitra ao amin'ny Odnoklassniki aho. Manana mpizara ara-batana maherin'ny 7 arivo izahay, kaontenera 11 arivo ao amin'ny rahonay ary fampiharana 200, izay amin'ny fanamafisana isan-karazany dia mamorona cluster 700 samihafa. Ny ankamaroan'ny mpizara dia mampiasa CentOS 7.
Tamin'ny 14 aogositra 2018, navoaka ny vaovao momba ny vulnerability FragmentSmack
(CVE-2018-5391) ary SegmentSmack (CVE-2018-5390). Ireo dia vulnerability miaraka amin'ny vector fanafihana amin'ny tambajotra ary naoty avo be (7.5), izay manohintohina ny fandavana ny serivisy (DoS) noho ny faharerahan'ny loharanon-karena (CPU). Ny fanamboarana kernel ho an'ny FragmentSmack dia tsy naroso tamin'izany fotoana izany; ankoatra izany, dia nivoaka taty aoriana lavitra noho ny famoahana vaovao momba ny vulnerability. Mba hanafoanana ny SegmentSmack, dia natolotra ny fanavaozana ny kernel. Ny fonosana fanavaozana dia navoaka tamin'io andro io ihany, ny hany sisa tavela dia ny fametrahana azy.
Tsia, tsy manohitra ny fanavaozana ny kernel mihitsy izahay! Na izany aza, misy ny nuances ...

Ahoana ny fanavaozana ny kernel amin'ny famokarana

Amin'ny ankapobeny, tsy misy sarotra:

Download fonosana;
Apetraho amin'ny lohamilina maromaro izy ireo (anisan'izany ny mpizara mampiantrano ny rahonay);
Ataovy azo antoka fa tsy misy simba;
Ataovy azo antoka fa ampiharina tsy misy hadisoana ny fandrindrana kernel mahazatra rehetra;
Andraso andro vitsivitsy;
Jereo ny fahombiazan'ny mpizara;
Ampifamadiho amin'ny kernel vaovao ny fametrahana server vaovao;
Fanavaozana ny lohamilina rehetra amin'ny alàlan'ny foibe data (ivotoerana iray isaky ny mandeha mba hampihenana ny fiantraikan'ny mpampiasa raha misy olana);
Avereno indray ny mpizara rehetra.

Avereno ho an'ny sampana rehetra amin'ny voany ananantsika. Amin'izao fotoana izao dia:

Stock CentOS 7 3.10 - ho an'ny ankamaroan'ny mpizara mahazatra;
Vanilla 4.19 - ho antsika rahona tokana, satria mila BFQ, BBR, sns.;
Elrepo kernel-ml 5.2 - ho an'ny mpaninjara be entana, satria ny 4.19 dia nanana fitondran-tena tsy miovaova, saingy ilaina ny endri-javatra mitovy.

Araka ny efa noeritreretinao, ny famerenana ny lohamilina an'arivony dia mitaky fotoana lava indrindra. Satria tsy ny vulnerabilité rehetra no tena manan-danja ho an'ny mpizara rehetra, averinay indray ireo izay azo idirana mivantana amin'ny Internet. Ao amin'ny rahona, mba tsy hamerana ny fahafaha-manao, dia tsy mamatotra ny kaontenera azo idirana ivelany amin'ny mpizara tsirairay miaraka amin'ny kernel vaovao isika, fa avereno indray ny mpampiantrano rehetra tsy an-kanavaka. Soa ihany fa ny fomba fiasa any dia tsotra kokoa noho ny amin'ny mpizara mahazatra. Ohatra, ny kaontenera tsy misy fanjakana dia afaka mifindra fotsiny amin'ny mpizara hafa mandritra ny famerenana indray.

Na izany aza, mbola betsaka ny asa, ary mety haharitra herinandro maromaro izany, ary raha misy olana amin'ny dikan-teny vaovao, hatramin'ny volana maromaro. Ny mpanafika dia mahatakatra tsara izany, ka mila drafitra B.

FragmentSmack/SegmentSmack. Workaround

Soa ihany fa misy ny drafitra "B" ho an'ny fahalemena sasany, ary antsoina hoe Workaround izany. Matetika indrindra, fiovana eo amin'ny fikandrana kernel/application izay afaka manamaivana ny mety ho vokany na manala tanteraka ny fitrandrahana ny vulnerabilities.

Raha ny FragmentSmack/SegmentSmack natolotra ity Workaround ity:

«Azonao atao ny manova ny soatoavina default amin'ny 4MB sy 3MB amin'ny net.ipv4.ipfrag_high_thresh sy net.ipv4.ipfrag_low_thresh (sy ny mitovy aminy amin'ny ipv6 net.ipv6.ipfrag_high_thresh sy net.ipv6.ipfrag_low_thresh) ho 256 kB sy 192 kB tsirairay avy. ambany. Ny fitsapana dia mampiseho fihenam-bidy kely hatramin'ny lehibe amin'ny fampiasana CPU mandritra ny fanafihana miankina amin'ny fitaovana, ny toe-javatra ary ny fepetra. Na izany aza, mety hisy fiatraikany amin'ny fampisehoana noho ny ipfrag_high_thresh=262144 bytes, satria sombiny 64K roa ihany no afaka miditra amin'ny filaharana famerenana indray mandeha. Ohatra, mety ho tapaka ny fampiharana izay miasa miaraka amin'ny fonosana UDP lehibe".

Ny paramètre mihitsy ao amin'ny antontan-taratasy kernel voalaza toy izao:

ipfrag_high_thresh - LONG INTEGER Maximum memory used to reassemble IP fragments.

ipfrag_low_thresh - LONG INTEGER Maximum memory used to reassemble IP fragments before the kernel begins to remove incomplete fragment queues to free up resources. The kernel still accepts new fragments for defragmentation.

Tsy manana UDP lehibe izahay amin'ny serivisy famokarana. Tsy misy fifamoivoizana miparitaka amin'ny LAN; misy fifamoivoizana miparitaka amin'ny WAN, fa tsy manan-danja. Tsy misy famantarana - azonao atao ny mamoaka Workaround!

FragmentSmack/SegmentSmack. Ra voalohany

Ny olana voalohany sendra anay dia ny fampiasan'ny container cloud indraindray amin'ny ampahany ihany (ipfrag_low_thresh ihany), ary indraindray tsy nampihatra azy ireo mihitsy - nianjera fotsiny izy ireo tany am-piandohana. Tsy azo atao ny mamerina ny olana amin'ny fomba milamina (napetraka amin'ny tanana tsy misy fahasarotana ny fanovana rehetra). Tsy mora ihany koa ny fahafantarana ny antony nianjeran'ilay kaontenera tany am-piandohana: tsy nisy lesoka hita. Zavatra iray no azo antoka: mamaha ny olana amin'ny fianjeran'ny kaontenera ny famerenana ny fanovana.

Nahoana no tsy ampy ny mampihatra Sysctl amin'ny mpampiantrano? Ny kaontenera dia mipetraka ao amin'ny tamba-jotra natokana ho azy manokana, ka farafaharatsiny ampahany amin'ny tambajotra Sysctl paramètre ao anaty fitoeran-javatra dia mety tsy mitovy amin'ny mpampiantrano.

Ahoana marina ny fampiharana Sysctl ao amin'ny container? Koa satria tsy misy tombontsoa ny kaonteneray, dia tsy ho afaka hanova ny fika Sysctl ianao amin'ny fidirana ao amin'ny kaontenera mihitsy - tsy manana zo ampy ianao. Mba hampandehanana kaontenera, ny rahonay tamin'izany fotoana izany dia nampiasa Docker (ankehitriny podman). Nalefa tamin'ny Docker tamin'ny alàlan'ny API ny mari-pamantarana ny kaontenera vaovao, ao anatin'izany ny fanovana Sysctl ilaina.
Rehefa nikaroka ireo dikan-teny dia hita fa tsy namerina ny lesoka rehetra ny Docker API (farafaharatsiny amin'ny version 1.10). Rehefa nanandrana nanomboka ny kaontenera tamin'ny alàlan'ny "docker run" izahay, dia nahita zavatra farafaharatsiny:

write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.

Tsy mitombina ny sandan'ny paramètre. Fa nahoana? Ary nahoana izy io no tsy manan-kery indraindray? Hita fa i Docker dia tsy manome antoka ny filaharana izay ampiharana ny paramètre Sysctl (ny dikan-teny andrana farany dia 1.13.1), ka indraindray ipfrag_high_thresh dia nanandrana napetraka ho 256K raha mbola 3M ipfrag_low_thresh, izany hoe ambany ny fetra ambony. noho ny fetra ambany, izay nitarika ny fahadisoana.

Tamin'izany fotoana izany dia efa nampiasa ny mekanika manokana izahay hamerenana indray ny kaontenera aorian'ny fanombohana (manamaivana ny kaontenera aorian'ny vata fampangatsiahana vondrona ary manatanteraka baiko ao amin'ny namespace ny container via ip netns), ary nampianay koa ny fanoratana ny paramètre Sysctl amin'ity ampahany ity. Voavaha ny olana.

FragmentSmack/SegmentSmack. Ra voalohany 2

Talohan'ny nanananay fotoana nahatakatra ny fampiasana ny Workaround amin'ny rahona, dia nanomboka tonga ny fitarainana tsy fahita firy voalohany avy amin'ireo mpampiasa. Tamin'izany fotoana izany, herinandro maromaro no lasa hatramin'ny nanombohan'ny fampiasana Workaround tamin'ireo mpizara voalohany. Ny fanadihadiana voalohany dia naneho fa ny fitarainana dia voaray amin'ny serivisy tsirairay, fa tsy ny lohamilina rehetra amin'ireo serivisy ireo. Lasa tena tsy azo antoka indray ny olana.

Voalohany indrindra, izahay, mazava ho azy, nanandrana namerina ny Sysctl toe-javatra, fa tsy nisy vokany. Tsy nanampy ihany koa ny fanodinkodinana isan-karazany tamin'ny server sy ny fampiharana. Nanampy ny reboot. Ny famerenana indray ny Linux dia tsy voajanahary toy ny mahazatra ho an'ny Windows tamin'ny andro taloha. Na izany aza, nanampy izany, ary nofaritanay tamin'ny "fikorontanan'ny kernel" izany rehefa nampihatra ny fanovana vaovao ao amin'ny Sysctl. Tena tsinontsinona izany...

Telo herinandro taty aoriana dia niverina indray ilay olana. Tsotra ny fandrindrana ireo mpizara ireo: Nginx amin'ny mode proxy/balancer. Tsy dia be ny fifamoivoizana. Fanamarihana fampidirana vaovao: mitombo isan'andro ny isan'ny fahadisoana 504 amin'ny mpanjifa (Vanim-potoanan'ny vavahady). Ny tabilao dia mampiseho ny isan'ny fahadisoana 504 isan'andro ho an'ity serivisy ity:

Ny lesoka rehetra dia mitovy amin'ny backend iray ihany - momba ilay ao anaty rahona. Ny kisary fanjifana fahatsiarovana ho an'ny sombintsombiny amin'ity lamosina ity dia toa izao:

Io no iray amin'ireo fisehoan-javatra miharihary indrindra amin'ny olana amin'ny grafika rafitra miasa. Tao amin'ny rahona, tamin'izay fotoana izay ihany, dia nisy olana hafa momba ny tambajotra amin'ny fikandrana QoS (Fanaraha-maso ny fifamoivoizana). Ao amin'ny grafika amin'ny fanjifana fitadidiana ho an'ny sombintsombin'ny fonosana, dia mitovy tanteraka izany:

Tsotra ny fiheverana: raha mitovy ny fijery amin'ny grafika, dia mitovy ny antony. Ambonin'izany, tsy fahita firy ny olana amin'ity karazana fitadidiana ity.

Ny fototry ny olana raikitra dia ny nampiasanay ny fq packet scheduler miaraka amin'ny fikandrana default ao amin'ny QoS. Amin'ny alàlan'ny default, ho an'ny fifandraisana iray dia ahafahanao manampy fonosana 100 amin'ny filaharana, ary ny fifandraisana sasany, amin'ny toe-javatra misy ny tsy fahampian'ny fantsona, dia nanomboka nanenika ny filaharana. Amin'ity tranga ity, ny fonosana dia latsaka. Ao amin'ny statistika tc (tc -s qdisc) dia azo jerena toy izao:

qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0) backlog 0b 0p requeues 0 1024 flows (1021 inactive, 0 throttled) 0 gc, 0 highprio, 0 throttled, 464545 flows_plimit

"464545 flows_plimit" dia ny fonosana latsaka noho ny mihoatra ny filaharana fetran'ny fifandraisana iray, ary ny "nilatsaka 464545" dia ny fitambaran'ny fonosana rehetra nandatsaka an'ity fandaharam-potoana ity. Taorian'ny nampitomboana ny halavan'ny filaharana ho 1 arivo sy ny famerenana indray ny kaontenera dia nijanona ny olana. Afaka mipetraka sy misotro smoothie ianao.

FragmentSmack/SegmentSmack. Ra farany

Voalohany, volana maromaro taorian'ny nanambarana ny vulnerabilities ao amin'ny kernel, dia nisy fanamboarana ho an'ny FragmentSmack tamin'ny farany (mamelà ahy hampahatsiahy anao fa miaraka amin'ny fanambarana tamin'ny volana Aogositra, dia nisy fanamboarana ho an'ny SegmentSmack ihany no navoaka), izay nanome anay fahafahana handao ny Workaround, izay niteraka fahasahiranana be ho anay. Nandritra io fotoana io dia efa nahavita namindra ny sasany amin'ireo mpizara ho amin'ny kernel vaovao izahay, ary izao dia tsy maintsy nanomboka hatrany am-piandohana. Nahoana isika no nanavao ny kernel nefa tsy niandry ny fanamboarana FragmentSmack? Ny zava-misy dia ny fizotry ny fiarovana amin'ireo vulnerabilities ireo dia nifanandrify (ary nitambatra) tamin'ny dingan'ny fanavaozana ny CentOS mihitsy (izay mitaky fotoana bebe kokoa noho ny fanavaozana ny kernel fotsiny). Fanampin'izany, ny SegmentSmack dia vulnerability mampidi-doza kokoa, ary ny fanamboarana azy dia niseho avy hatrany, noho izany dia nisy dikany izany. Na izany aza, tsy afaka manavao fotsiny ny kernel amin'ny CentOS izahay satria ny vulnerability FragmentSmack, izay niseho nandritra ny CentOS 7.5, dia raikitra tamin'ny version 7.6 ihany, noho izany dia tsy maintsy nampiato ny fanavaozana tamin'ny 7.5 izahay ary nanomboka indray tamin'ny fanavaozana ny 7.6. Ary mitranga koa izany.

Faharoa, niverina taminay ny fitarainan'ny mpampiasa tsy fahita firy momba ny olana. Ankehitriny dia efa fantatsika tsara fa misy ifandraisany amin'ny fampiakarana rakitra avy amin'ny mpanjifa mankany amin'ny servery sasany izy ireo. Ambonin'izany, vitsy dia vitsy ny fampiakarana avy amin'ny fitambaran'ny faobe nandalo tamin'ireo lohamilina ireo.

Raha tadidintsika avy amin'ny tantara etsy ambony, ny famerenana ny Sysctl dia tsy nanampy. Nanampy ny reboot, saingy vonjimaika.
Tsy nesorina ny ahiahy momba ny Sysctl, fa tamin'ity indray mitoraka ity dia nilaina ny fanangonana fampahalalana betsaka araka izay tratra. Nisy ihany koa ny tsy fahampian'ny fahafahana mamerina ny olan'ny fampidinana amin'ny mpanjifa mba handalinana ny zava-mitranga.

Ny famakafakana ny antontan'isa rehetra sy ny diary rehetra dia tsy nahatonga anay hanakaiky kokoa ny fahatakarana ny zava-nitranga. Nisy ny tsy fahampian'ny fahaizana mamerina ny olana mba "hahatsapa" fifandraisana manokana. Farany, ireo mpamorona, amin'ny fampiasana dikan-teny manokana amin'ny fampiharana, dia nahavita nanamboatra olana amin'ny fitaovana fitsapana rehefa mifandray amin'ny Wi-Fi. Fihaonana tamin’ny fanadihadiana izany. Ny mpanjifa dia nifandray tamin'ny Nginx, izay nifindra tany amin'ny backend, izay fampiharana Java anay.

Ny fifanakalozan-kevitra momba ny olana dia toy izao (amboarina amin'ny lafiny proxy Nginx):

Mpanjifa: mangataka ny hahazo vaovao momba ny fampidinana rakitra.
Mpizara Java: valiny.
Mpanjifa: POST miaraka amin'ny rakitra.
Mpizara Java: fahadisoana.

Mandritra izany fotoana izany, ny mpizara Java dia manoratra amin'ny log fa 0 bytes ny angon-drakitra voaray avy amin'ny mpanjifa, ary ny proxy Nginx dia manoratra fa ny fangatahana dia naharitra 30 segondra mahery (30 segondra no fe-potoanan'ny fampiharana mpanjifa). Nahoana ny fotoana fiatoana ary nahoana no 0 bytes? Avy amin'ny fomba fijery HTTP, ny zava-drehetra dia miasa araka ny tokony ho izy, fa ny POST miaraka amin'ny rakitra dia toa manjavona ao amin'ny tambajotra. Ankoatra izany, dia manjavona eo anelanelan'ny mpanjifa sy Nginx. Fotoana izao hampiadiana ny tenanao amin'ny Tcpdump! Saingy aloha dia mila mahatakatra ny fikirakirana tambajotra ianao. Nginx proxy dia ao ambadiky ny L3 balancer NFware. Ny tonelina dia ampiasaina handefasana fonosana avy amin'ny mpandrindra L3 mankany amin'ny mpizara, izay manampy ny lohateniny amin'ny fonosana:

Amin'ity tranga ity, tonga amin'ity mpizara ity ny tambajotra amin'ny endrika fifamoivoizana misy marika Vlan, izay manampy ny sahany manokana amin'ny fonosana:

Ary ity fifamoivoizana ity dia azo zaraina ihany koa (io isan-jato kely amin'ny fifamoivoizana miparitaka miditra izay noresahintsika tamin'ny fanombanana ny loza avy amin'ny Workaround), izay manova ny votoatin'ny lohapejy:

Indray mandeha indray: fonosina miaraka amin'ny tenifototra Vlan ny fonosana, voarakotra amin'ny tonelina iray, voazarazara. Mba hahatakarana bebe kokoa ny zava-mitranga dia andao hojerentsika ny làlan'ny fonosana avy amin'ny mpanjifa mankany amin'ny proxy Nginx.

Ny fonosana dia mahatratra ny L3 balancer. Ho an'ny fampitaovana marina ao anatin'ny foibe angona, ny fonosana dia voarakitra ao anaty tonelina ary alefa any amin'ny karatra tambajotra.
Koa satria tsy mifanaraka amin'ny MTU ny lohatenin'ny packet + tunnel, dia tapaka ny fonosana ary alefa any amin'ny tambajotra.
Ny switch aorian'ny L3 balancer, rehefa mandray fonosana, dia manampy marika Vlan ao aminy ary mandefa azy.
Ny switch eo anoloan'ny proxy Nginx dia mahita (mifototra amin'ny firafitry ny seranan-tsambo) fa ny mpizara dia manantena fonosana misy Vlan-encapsulated, noho izany dia mandefa azy io araka ny tokony ho izy, tsy manala ny tag Vlan.
Linux dia maka ampahany amin'ny fonosana tsirairay ary manambatra azy ireo ho fonosana lehibe iray.
Manaraka, tonga any amin'ny interface Vlan ny fonosana, izay nesorina ny sosona voalohany - Vlan encapsulation.
Linux avy eo dia mandefa azy any amin'ny tonelina interface tsara, izay misy sosona hafa nesorina taminy - Tunnel encapsulation.

Ny fahasarotana dia ny mandalo izany rehetra izany ho paramètre amin'ny tcpdump.
Andao hanomboka amin'ny farany: misy fonosana IP madio (tsy misy lohateny tsy ilaina) avy amin'ny mpanjifa, miaraka amin'ny vlan sy tonelina encapsulation nesorina?

tcpdump host <ip клиента>

Tsia, tsy nisy fonosana toy izany tao amin'ny mpizara. Noho izany dia tsy maintsy ho eo aloha ny olana. Misy fonosana ve tsy misy afa-tsy Vlan encapsulation nesorina?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx no adiresy IP mpanjifa amin'ny endrika hex.
32:4 — adiresy sy halavan'ny saha misy ny SCR IP voasoratra ao amin'ny fonosana Tunnel.

Ny adiresin'ny saha dia tsy maintsy nofantenana tamin'ny herisetra, satria ao amin'ny Internet izy ireo dia manoratra momba ny 40, 44, 50, 54, saingy tsy nisy adiresy IP tao. Azonao atao ihany koa ny mijery ny iray amin'ireo fonosana amin'ny hex (ny -xx na -XX parameter amin'ny tcpdump) ary kajy ny adiresy IP fantatrao.

Misy sombintsombin'ny fonosana ve tsy nesorina ny encapsulation Vlan sy Tunnel?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Ity ody ity dia hampiseho amintsika ny sombiny rehetra, anisan'izany ny farany. Angamba, ny zavatra mitovy amin'izany dia azo sivana amin'ny IP, saingy tsy nanandrana aho, satria tsy dia betsaka loatra ny fonosana toy izany, ary ireo izay nilaiko dia mora hita tamin'ny fikorianan'ny ankapobeny. Ireto izy ireo:

14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500) 11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500) 33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448 0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A.... 0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8} 0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected]. 0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@.. 0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W....... 0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx 0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........

14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40) 11.11.11.11 > 22.22.22.22: ip-proto-4 0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A.... 0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8} 0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C 0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q 0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............

Sombiny roa amin'ny fonosana iray (ID 53652 mitovy) misy sary (ny teny Exif dia hita ao amin'ny fonosana voalohany). Noho ny zava-misy fa misy fonosana amin'ity ambaratonga ity, fa tsy amin'ny endrika mitambatra ao amin'ny fanariam-pako, ny olana dia mazava tsara amin'ny fivoriambe. Farany dia misy porofo fanadihadiana momba izany!

Ny decoder fonosana dia tsy nanambara olana mety hisakana ny fananganana. Nanandrana azy teto: hpd.gasmi.net. Amin'ny voalohany, rehefa manandrana mametraka zavatra ao ianao dia tsy tian'ny decoder ny endrika fonosana. Hita fa nisy octet roa fanampiny teo anelanelan'i Srcmac sy Ethertype (tsy mifandray amin'ny fampahalalana sombiny). Rehefa avy nesorina izy ireo dia nanomboka niasa ny decoder. Tsy nahitana olana anefa izany.
Na inona na inona mety holazaina dia tsy nisy zavatra hafa hita afa-tsy ireo Sysctl. Ny hany sisa tavela dia ny fitadiavana fomba hamantarana ireo lohamilina misy olana mba hahatakarana ny haavony sy hanapahana hetsika fanampiny. Hita haingana ny kaontera ilaina:

netstat -s | grep "packet reassembles failed”

Izy io koa dia ao amin'ny snmpd eo ambanin'ny OID=1.3.6.1.2.1.4.31.1.1.16.1 (ipSystemStatsReasmFails).

"Ny isan'ny tsy fahombiazana hitan'ny algorithm famerenan'ny IP (na inona na inona antony: tapitra ny fotoana, fahadisoana, sns.)."

Anisan'ireo vondrona mpizara izay nandinika ny olana, tamin'ny roa dia nitombo haingana kokoa io kaontera io, tamin'ny roa miadana kokoa, ary tamin'ny roa hafa dia tsy nitombo mihitsy. Ny fampitahana ny dinamikan'ity kaontera ity amin'ny dinamikan'ny hadisoana HTTP amin'ny mpizara Java dia nanambara fifandraisana iray. Izany hoe azo araha-maso ny metatra.

Ny fananana famantarana azo antoka momba ny olana dia tena zava-dehibe mba hahafahanao mamaritra tsara raha manampy ny famerenana ny Sysctl, satria amin'ny tantara teo aloha dia fantatsika fa tsy azo takarina avy hatrany amin'ny fampiharana izany. Ity famantarana ity dia ahafahantsika mamantatra ny faritra misy olana rehetra amin'ny famokarana alohan'ny hahitan'ny mpampiasa azy.
Taorian'ny namerenana an'i Sysctl dia nijanona ny lesoka fanaraha-maso, ka voaporofo ny anton'ny olana, ary koa ny hoe manampy ny famerenana.

Naverinay indray ny firafitry ny fizarazarana teo amin'ny lohamilina hafa, izay nidiran'ny fanaraha-maso vaovao, ary tany amin'ny toerana iray dia nanome fahatsiarovana bebe kokoa ho an'ny sombintsombiny noho ny teo aloha teo aloha (anisan'ny UDP io, ny fahaverezan'ny ampahany izay tsy hita amin'ny ankapobeny) .

Ny fanontaniana manan-danja indrindra

Nahoana ny fonosana no mizarazara amin'ny mpifandanja L3? Ny ankamaroan'ny fonosana tonga avy amin'ny mpampiasa ho an'ny balancers dia SYN sy ACK. Kely ny haben'ireo fonosana ireo. Saingy satria ny ampahany amin'ny fonosana toy izany dia tena lehibe, manoloana ny fiaviany dia tsy tsikaritray ny fisian'ireo fonosana lehibe izay nanomboka nizarazara.

Ny anton'izany dia ny script configuration simba advmss amin'ny lohamilina misy fifandraisana Vlan (vitsy dia vitsy ny mpizara misy marika fifamoivoizana amin'ny famokarana tamin'izany fotoana izany). Ny Advmss dia ahafahantsika mampita amin'ny mpanjifa ny fampahalalana fa ny fonosana mankany amin'ny lalanay dia tokony ho kely kokoa ny habeny ka rehefa avy mametaka lohapelin'ny tonelina amin'izy ireo dia tsy voatery ho tapaka.

Nahoana no tsy nanampy ny famerenana indray ny Sysctl, fa ny reboot? Ny famerenana indray ny Sysctl dia nanova ny habetsaky ny fahatsiarovana azo ampiasaina amin'ny fampifangaroana fonosana. Tamin'izany fotoana izany, toa ny fihoaran'ny fitadidiana ho an'ny sombintsombiny no nahatonga ny fihenan'ny fifandraisana, izay nahatonga ny sombintsombiny nahemotra ela tao amin'ny filaharana. Izany hoe nandeha tsingerina ny dingana.
Ny reboot dia nanala ny fahatsiarovana ary niverina tamin'ny filaminana ny zava-drehetra.

Azo atao ve ny manao tsy misy Workaround? Eny, saingy misy risika lehibe hamela ireo mpampiasa tsy misy serivisy raha misy fanafihana. Mazava ho azy fa niteraka olana isan-karazany ny fampiasana ny Workaround, anisan'izany ny fihenan'ny iray amin'ireo serivisy ho an'ny mpampiasa, saingy na izany aza dia mino izahay fa ara-drariny ny hetsika.

Misaotra betsaka an'i Andrey Timofeev (atimofeyev) ho fanampiana amin'ny fanatanterahana ny fanadihadiana, ary koa i Alexey Krenev (fitaovanax) - ho an'ny asa titanika amin'ny fanavaozana Centos sy kernel amin'ny mpizara. Dingana iray izay tsy maintsy natomboka hatrany am-boalohany tamin’ity tranga ity, ka izay no nahatonga azy nitaredretra nandritra ny volana maro.

Source: www.habr.com

Mitandrema amin'ny vulnerability izay mitondra fihodinana asa. Fizarana 1: FragmentSmack/SegmentSmack