Sabihin natin sa iyo ang isang cool na kuwento tungkol sa kung paano sinubukan ng "mga third party" na makagambala sa gawain ng aming mga kliyente, at kung paano nalutas ang problemang ito.
Kung paano nagsimula ang lahat
Nagsimula ang lahat noong umaga ng Oktubre 31, ang huling araw ng buwan, kung kailan marami ang lubhang nangangailangan na magkaroon ng panahon upang malutas ang mga madalian at mahahalagang isyu.
Ang isa sa mga kasosyo, na nagpapanatili ng ilang virtual machine ng mga kliyenteng pinaglilingkuran niya sa aming cloud, ay nag-ulat na mula 9:10 hanggang 9:20 maraming Windows server na tumatakbo sa aming Ukrainian site ang hindi tumanggap ng mga koneksyon sa remote access service , hindi nagawa ng mga user. upang mag-log in sa kanilang mga desktop, ngunit pagkatapos ng ilang minuto ang problema ay tila nalutas mismo.
Itinaas namin ang mga istatistika sa pagpapatakbo ng mga channel ng komunikasyon, ngunit wala kaming nakitang anumang pagdagsa o ββpagkabigo sa trapiko. Tiningnan namin ang mga istatistika sa pag-load sa mga mapagkukunan ng computing - walang mga anomalya. At ano iyon?
Pagkatapos ng isa pang kasosyo, na nagho-host ng humigit-kumulang isang daang higit pang mga server sa aming cloud, ay nag-ulat ng parehong mga problema na napansin ng ilan sa kanilang mga kliyente, at lumabas na sa pangkalahatan ang mga server ay naa-access (wastong tumutugon sa ping test at iba pang mga kahilingan), ngunit ang serbisyo ng malayuang pag-access sa mga server na ito ay tumatanggap ng mga bagong koneksyon o tinatanggihan ang mga ito, at pinag-uusapan natin ang tungkol sa mga server sa iba't ibang mga site, ang trapiko kung saan nagmumula sa iba't ibang mga channel ng paghahatid ng data.
Tingnan natin ang trapikong ito. Dumating sa server ang isang packet na may kahilingan sa koneksyon:
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 problema sa pagpapatakbo ng imprastraktura, ngunit sa iba pa. Siguro lahat ng user ay nagkakaproblema sa remote desktop licensing? Maaaring may ilang uri ng malware na nakapasok sa kanilang mga system, at ngayon ay na-activate na ito, tulad ng nangyari noong nakaraang taon. XData ΠΈ petya?
Habang inaayos namin ito, nakatanggap kami ng mga katulad na kahilingan mula sa marami pang kliyente at kasosyo.
Ano ba talaga ang nangyayari sa mga makinang ito?
Ang mga log ng kaganapan ay puno ng mga mensahe tungkol sa mga pagtatangkang hulaan ang password:
Karaniwan, ang mga naturang pagtatangka ay nakarehistro sa lahat ng mga server kung saan ang karaniwang port (3389) ay ginagamit para sa serbisyo ng malayuang pag-access at ang pag-access ay pinapayagan mula sa lahat ng dako. Ang Internet ay puno ng mga bot na patuloy na ini-scan ang lahat ng magagamit na mga punto ng koneksyon at sinusubukang hulaan ang password (ito ang dahilan kung bakit mahigpit naming inirerekomenda ang paggamit ng mga kumplikadong password sa halip na "123"). Gayunpaman, ang intensity ng mga pagtatangka sa araw na iyon ay masyadong mataas.
Ano ang dapat kong gawin?
Inirerekomenda na gumugol ng maraming oras ang mga customer sa pagbabago ng mga setting para sa malaking bilang ng mga end user na lumipat sa ibang port? Hindi magandang ideya, hindi magiging masaya ang mga customer. Inirerekomenda na payagan lang ang pag-access sa pamamagitan ng VPN? Sa pagmamadali at gulat, ang pagtataas ng mga koneksyon sa IPSec para sa mga hindi nakataas sa kanila - marahil ang gayong kaligayahan ay hindi rin ngumingiti sa mga kliyente. Bagaman, dapat kong sabihin, ito ay isang makadiyos na bagay sa anumang kaso, palagi naming inirerekumenda na itago ang server sa isang pribadong network at handang tumulong sa mga setting, at para sa mga gustong malaman ito sa kanilang sarili, nagbabahagi kami ng mga tagubilin para sa pag-set up ng IPSec/L2TP sa aming cloud sa site-to-site o road mode -warrior, at kung sinuman ang gustong mag-set up ng serbisyo ng VPN sa sarili nilang Windows server, lagi silang handa na magbahagi ng mga tip sa kung paano mag-set up ng karaniwang RAS o OpenVPN. Ngunit, gaano man kami ka-cool, hindi ito ang pinakamagandang oras para magsagawa ng gawaing pang-edukasyon sa mga kliyente, dahil kailangan naming ayusin ang problema sa lalong madaling panahon nang may kaunting stress para sa mga user.
Ang solusyon na aming ipinatupad ay ang mga sumusunod. Nag-set up kami ng pagsusuri sa pagdaan ng trapiko sa paraang masubaybayan ang lahat ng mga pagtatangka na magtatag ng koneksyon sa TCP sa port 3389 at pumili mula dito ng mga address na, sa loob ng 150 segundo, nagtatangkang magtatag ng mga koneksyon sa higit sa 16 na magkakaibang mga server sa aming network - ito ang mga mapagkukunan ng pag-atake ( Siyempre, kung ang isa sa mga kliyente o kasosyo ay may tunay na pangangailangan na magtatag ng mga koneksyon sa napakaraming mga server mula sa parehong pinagmulan, maaari mong palaging idagdag ang mga naturang mapagkukunan sa "puting listahan." Bukod dito, kung sa isang class C network sa loob ng 150 segundong ito, higit sa 32 address ang natukoy, makatuwirang harangan ang buong network. Ang pagharang ay itinakda sa loob ng 3 araw, at kung sa panahong ito ay walang mga pag-atake na ginawa mula sa isang ibinigay na pinagmulan, ang source na ito ay awtomatikong inalis sa βblack list.β Ang listahan ng mga naka-block na source ay ina-update kada 300 segundo.
Ang listahang ito ay makukuha sa address na ito: , maaari mong buuin ang iyong mga ACL batay dito.
Handa kaming ibahagi ang source code ng naturang sistema; walang masyadong kumplikado sa loob nito (ito ay ilang mga simpleng script na pinagsama-sama sa literal ng ilang oras sa tuhod), at sa parehong oras maaari itong iakma at gamitin nang hindi para lamang maprotektahan laban sa gayong pag-atake, ngunit para matukoy at harangan din ang anumang mga pagtatangka na i-scan ang network:
Bilang karagdagan, gumawa kami ng ilang mga pagbabago sa mga setting ng sistema ng pagsubaybay, na ngayon ay mas malapit na sinusubaybayan ang reaksyon ng isang control group ng mga virtual server sa aming cloud sa isang pagtatangka na magtatag ng isang koneksyon sa RDP: kung ang reaksyon ay hindi sumunod sa loob ng isang pangalawa, ito ay isang dahilan upang bigyang pansin.
Ang solusyon ay naging medyo epektibo: wala nang mga reklamo mula sa parehong mga kliyente at kasosyo, at mula sa 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 gawain ng aming mga kliyente.
Nag-iisa sa bukid ay hindi isang mandirigma
Ngayon nalaman namin na ang ibang mga operator ay nakaranas ng katulad na problema. May naniniwala pa rin na ang Microsoft ay gumawa ng ilang pagbabago sa code ng remote access service (kung naaalala mo, pinaghihinalaan namin ang parehong bagay sa unang araw, ngunit napakabilis naming tinanggihan ang bersyon na ito) at nangangako na gagawin ang lahat ng posible upang mabilis na makahanap ng solusyon . Ang ilang mga tao ay binabalewala lamang ang problema at pinapayuhan ang mga kliyente na protektahan ang kanilang sarili sa kanilang sarili (baguhin ang port ng koneksyon, itago ang server sa isang pribadong network, at iba pa). At sa pinakaunang araw, hindi lang namin nalutas ang problemang ito, ngunit lumikha din kami ng ilang batayan para sa isang mas pandaigdigang sistema ng pagtuklas ng banta na pinaplano naming bumuo.
Espesyal na pasasalamat sa mga kliyente at kasosyo na hindi nanahimik at hindi umupo sa pampang ng ilog na naghihintay sa bangkay ng isang kaaway na lumutang sa tabi nito isang araw, ngunit agad na iginuhit ang aming pansin sa problema, na nagbigay sa amin ng pagkakataong maalis. ito sa parehong araw.
Pinagmulan: www.habr.com