Sasabihin namin sa iyo ang isang nakakatakot na kuwento tungkol sa kung paano sinubukan ng "mga third party" na hadlangan ang trabaho ng aming mga kliyente, at kung paano nalutas ang problemang ito.
Kung paano nagsimula ang lahat
Nagsimula ang lahat noong umaga ng ika-31 ng Oktubre, ang huling araw ng buwan, kung saan marami ang lubhang nangangailangan upang malutas ang mga apurahan at mahahalagang bagay.
Isa sa aming mga kasosyo, na nagho-host ng ilang virtual machine para sa mga kliyenteng pinaglilingkuran niya sa aming cloud, ay nag-ulat na mula 9:10 hanggang 9:20 ay ilan WindowsHindi tumatanggap ng mga koneksyon sa remote access service ang mga server na tumatakbo sa aming Ukrainian site, at hindi ma-access ng mga user ang kanilang mga desktop. Gayunpaman, pagkalipas ng ilang minuto, tila nalutas na ang problema nang kusa.
Sinuri namin ang mga istatistika ng channel ng komunikasyon ngunit walang nakitang mga spike o pagbaba ng trapiko. Sinuri din namin ang mga istatistika ng pagkarga ng mapagkukunan ng computing - walang mga anomalya. Kaya ano iyon?
Pagkatapos ng isa pang kasosyo, na nagho-host ng halos isang daang higit pang mga server sa aming cloud, ay nag-ulat ng parehong mga problema na napansin ng ilan sa kanilang mga kliyente. Ito ay lumabas na ang mga server ay karaniwang naa-access (nagtugon sila nang tama sa mga pagsubok sa ping at iba pang mga kahilingan), ngunit ang serbisyo ng malayuang pag-access sa mga server na ito ay kung minsan ay tumatanggap ng mga bagong koneksyon, kung minsan ay tinatanggihan sila. Kasama dito ang mga server sa iba't ibang lokasyon, na may trapiko na nagmumula sa iba't ibang mga channel ng paghahatid ng data.
Tingnan natin ang trapikong ito. Dumating ang isang pakete ng kahilingan sa koneksyon sa server:
xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
Natanggap ng server ang packet na ito ngunit tinatanggihan ang koneksyon:
xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0
Nangangahulugan ito na ang problema ay malinaw na hindi sanhi ng anumang mga isyu sa imprastraktura, ngunit sa pamamagitan ng iba pa. Marahil ang lahat ng mga gumagamit ay nakakaranas ng mga isyu sa remote desktop licensing? Marahil ay nagawa ng ilang malware na makalusot sa kanilang mga system, at na-activate na ito ngayon, gaya ng nangyari sa... ilang taon na ang nakalipas. XData и petya?
Habang nag-iimbestiga kami, nakatanggap kami ng mga katulad na kahilingan mula sa ilang iba pang kliyente at kasosyo.
Ano pa rin ang nangyayari sa mga makinang ito?
Ang mga log ng kaganapan ay puno ng mga mensahe tungkol sa mga pagtatangka sa paghula ng password:
Karaniwan, ang mga naturang pagtatangka ay naka-log sa lahat ng mga server na gumagamit ng karaniwang port (3389) para sa malayuang pag-access at nagbibigay-daan sa pag-access mula sa kahit saan. Ang internet ay puno ng mga bot na patuloy na nag-i-scan sa lahat ng magagamit na koneksyon at nagtatangkang hulaan ang mga password (para sa kadahilanang ito, lubos naming inirerekomenda ang paggamit ng mga kumplikadong password sa halip na "123"). Gayunpaman, ang intensity ng mga pagtatangka sa araw na iyon ay napakataas.
Ano ang dapat kong gawin?
Irerekomenda ba sa mga kliyente na gumugol ng maraming oras sa pagpapalit ng mga setting para sa napakaraming end user para lang lumipat sa ibang port? Hindi magandang ideya; hindi matutuwa ang mga kliyente. Irerekomenda ba na payagan lang ang access sa pamamagitan ng VPN? Nagmamadaling mag-set up ng mga koneksyon ng IPSec dahil sa takot kapag hindi pa nila ito gumagana—marahil ay hindi rin ito magiging masaya para sa mga kliyente. Bagama't, dapat sabihin, maganda ito sa anumang kaso. Palagi naming inirerekomenda na itago ang server sa isang pribadong network at handa kaming tumulong sa pag-configure. Para sa mga mas gustong alamin ang mga bagay-bagay nang mag-isa, nagbabahagi kami ng mga tagubilin para sa pag-set up ng IPSec/L2TP sa aming cloud sa site-to-site o road-warrior mode. At kung may gustong mag-set up ng serbisyo ng VPN nang mag-isa, Windows-server – laging handang magbahagi ng mga tip kung paano itaas ang pamantayan ng RAS o OpenVPNPero gaano man kami ka-cool, hindi pa rin ito ang pinakamagandang panahon para turuan ang mga customer, dahil kailangan naming ayusin ang problema sa lalong madaling panahon nang may kaunting abala sa mga user.
Ang solusyon na aming ipinatupad ay ang mga sumusunod. Na-configure namin ang pagsusuri sa trapiko upang subaybayan ang lahat ng mga pagtatangka na magtatag ng koneksyon sa TCP sa port 3389 at tukuyin ang mga address na nagtatangkang kumonekta sa higit sa 16 na magkakaibang mga server sa aming network sa loob ng 150 segundo—ito ang mga pinagmumulan ng pag-atake. (Siyempre, kung ang sinuman sa aming mga kliyente o kasosyo ay may tunay na pangangailangan na magtatag ng mga koneksyon sa napakaraming server mula sa parehong pinagmulan, maaari naming palaging magdagdag ng mga naturang mapagkukunan sa whitelist.) Higit pa rito, kung higit sa 32 mga address ang nakita sa isang network ng Class C sa loob ng 150 segundong ito, makatuwirang harangan ang buong network. Ang panahon ng pag-block ay nakatakda sa loob ng 3 araw, at kung walang mga pag-atake mula sa isang partikular na pinagmulan ang natupad sa panahong ito, awtomatiko itong maaalis sa blacklist. Ang listahan ng mga naka-block na mapagkukunan ay ina-update bawat 300 segundo.
Ang listahang ito ay makukuha sa sumusunod na address: , maaari kang bumuo ng sarili mong mga ACL batay dito.
Ikinalulugod naming ibahagi ang source code para sa system na ito. Hindi ito masyadong kumplikado (ilang simpleng script, pinagsama-sama sa loob lang ng ilang oras), at maaari itong iakma at gamitin hindi lamang para protektahan laban sa mga naturang pag-atake, kundi para makita at harangan din ang anumang mga pagtatangka na i-scan ang network:
Bukod pa rito, gumawa kami ng ilang mga pagbabago sa aming mga setting ng system sa pagsubaybay, na ngayon ay mas malapit na sinusubaybayan ang tugon ng control group ng mga virtual server sa aming cloud sa mga pagtatangka na magtatag ng isang RDP na koneksyon: kung ang isang tugon ay hindi naganap sa loob ng isang segundo, ito ay dahilan ng pag-aalala.
Ang solusyon ay napatunayang lubos na epektibo: wala nang mga reklamo mula sa mga kliyente, kasosyo, o sistema ng pagsubaybay. Ang mga bagong address at buong network ay regular na idinaragdag sa blacklist, na nagpapahiwatig na ang pag-atake ay nagpapatuloy ngunit hindi na nakakaapekto sa mga operasyon ng aming mga kliyente.
May kaligtasan sa mga numero
Ngayon, nalaman namin na ang ibang mga operator ay nakaranas ng katulad na problema. Naniniwala pa rin ang ilan na gumawa ng ilang pagbabago ang Microsoft sa remote access service code (kung naaalala mo, pinaghihinalaan namin ang parehong bagay sa unang araw, ngunit mabilis naming ibinasura ang teoryang iyon) at nangangako na gagawin ang lahat ng posible upang makahanap ng solusyon sa lalong madaling panahon. Ang iba ay binabalewala lang ang problema at pinapayuhan ang mga kliyente na protektahan ang kanilang sarili (baguhin ang port ng koneksyon, itago ang server sa isang pribadong network, at iba pa). Sa pinakaunang araw, hindi lang namin nalutas ang problemang ito kundi naglatag din ng batayan para sa isang mas komprehensibong sistema ng pagtuklas ng banta, na pinaplano naming bumuo.
Isang espesyal na pasasalamat sa aming mga kliyente at kasosyo na hindi nanahimik o umupo sa tabing ilog, naghihintay ng bangkay ng kaaway na lumutang dito balang araw. Sa halip, agad nilang dinala sa amin ang problema, na nagpapahintulot sa amin na ayusin ito nang araw ding iyon.
Pinagmulan: www.habr.com
