เราจะมาเล่าเรื่องราวดีๆ เกี่ยวกับวิธีที่ "บุคคลที่สาม" พยายามแทรกแซงงานของลูกค้าของเรา และวิธีแก้ปัญหานี้
ทุกอย่างเริ่มต้นอย่างไร
ทุกอย่างเริ่มต้นในเช้าวันที่ 31 ตุลาคม ซึ่งเป็นวันสุดท้ายของเดือน ซึ่งหลายคนต้องการเวลาแก้ไขปัญหาเร่งด่วนและสำคัญอย่างยิ่ง
หนึ่งในพันธมิตรที่เก็บเครื่องเสมือนหลายเครื่องของลูกค้าที่เขาให้บริการไว้ในระบบคลาวด์ของเรา รายงานว่าตั้งแต่เวลา 9:10 ถึง 9:20 น. เซิร์ฟเวอร์ Windows หลายเครื่องที่ทำงานบนไซต์ภาษายูเครนของเราไม่ยอมรับการเชื่อมต่อกับบริการการเข้าถึงระยะไกล ผู้ใช้ไม่สามารถ เพื่อเข้าสู่ระบบเดสก์ท็อป แต่หลังจากนั้นไม่กี่นาทีปัญหาก็ดูเหมือนจะคลี่คลายไปเอง
เรายกสถิติการทำงานของช่องทางการสื่อสาร แต่ไม่พบปริมาณการจราจรที่เพิ่มขึ้นหรือความล้มเหลว เราดูสถิติเกี่ยวกับภาระของทรัพยากรการประมวลผล - ไม่มีความผิดปกติ และนั่นคืออะไร?
จากนั้นพันธมิตรอีกรายหนึ่งซึ่งโฮสต์เซิร์ฟเวอร์ประมาณร้อยเซิร์ฟเวอร์ในระบบคลาวด์ของเรา รายงานปัญหาเดียวกันกับที่ลูกค้าบางรายระบุไว้ และปรากฎว่าโดยทั่วไปแล้วเซิร์ฟเวอร์สามารถเข้าถึงได้ (ตอบสนองต่อการทดสอบ ping และคำขออื่น ๆ อย่างเหมาะสม) แต่ บริการการเข้าถึงระยะไกลบนเซิร์ฟเวอร์เหล่านี้ยอมรับการเชื่อมต่อใหม่หรือปฏิเสธ และเรากำลังพูดถึงเซิร์ฟเวอร์บนไซต์ที่แตกต่างกัน ปริมาณการใช้งานที่มาจากช่องทางการส่งข้อมูลที่แตกต่างกัน
ลองดูที่การจราจรนี้ แพ็กเก็ตที่มีการร้องขอการเชื่อมต่อมาถึงเซิร์ฟเวอร์:
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
เซิร์ฟเวอร์ได้รับแพ็กเก็ตนี้ แต่ปฏิเสธการเชื่อมต่อ:
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
ซึ่งหมายความว่าปัญหาไม่ได้เกิดจากปัญหาใด ๆ ในการทำงานของโครงสร้างพื้นฐานอย่างชัดเจน แต่เกิดจากสิ่งอื่น ผู้ใช้ทุกคนอาจประสบปัญหากับสิทธิ์การใช้งานเดสก์ท็อประยะไกลใช่หรือไม่ บางทีมัลแวร์บางชนิดสามารถเจาะระบบของพวกเขาได้ และวันนี้มันก็ถูกเปิดใช้งานเหมือนเมื่อสองสามปีก่อน เอ็กซ์ดาต้า и Petya?
ขณะที่เรากำลังจัดการเรื่องนี้ เราได้รับคำขอที่คล้ายกันจากลูกค้าและพันธมิตรหลายราย
เกิดอะไรขึ้นกับเครื่องเหล่านี้จริงๆ?
บันทึกเหตุการณ์เต็มไปด้วยข้อความเกี่ยวกับการพยายามเดารหัสผ่าน:
โดยทั่วไปแล้ว ความพยายามดังกล่าวจะถูกลงทะเบียนบนเซิร์ฟเวอร์ทั้งหมดที่ใช้พอร์ตมาตรฐาน (3389) สำหรับบริการการเข้าถึงระยะไกล และอนุญาตให้เข้าถึงได้จากทุกที่ อินเทอร์เน็ตเต็มไปด้วยบอทที่สแกนจุดเชื่อมต่อที่มีอยู่ทั้งหมดอย่างต่อเนื่องและพยายามเดารหัสผ่าน (นี่คือเหตุผลที่เราขอแนะนำอย่างยิ่งให้ใช้รหัสผ่านที่ซับซ้อนแทน "123") อย่างไรก็ตาม ความพยายามเหล่านี้เข้มข้นในวันนั้นสูงเกินไป
ฉันควรทำอย่างไร?
แนะนำให้ลูกค้าใช้เวลาส่วนใหญ่ในการเปลี่ยนการตั้งค่าสำหรับผู้ใช้ปลายทางจำนวนมากเพื่อเปลี่ยนไปใช้พอร์ตอื่น ไม่ใช่ความคิดที่ดีลูกค้าจะไม่มีความสุข แนะนำให้อนุญาตการเข้าถึงผ่าน VPN เท่านั้น? ด้วยความเร่งรีบและตื่นตระหนกทำให้การเชื่อมต่อของ IPSec สำหรับผู้ที่ไม่มีพวกเขาเพิ่มขึ้น - บางทีความสุขดังกล่าวอาจไม่ยิ้มให้กับลูกค้าเช่นกัน แม้ว่าฉันต้องบอกว่านี่เป็นสิ่งที่ศักดิ์สิทธิ์ไม่ว่าในกรณีใด แต่เราแนะนำให้ซ่อนเซิร์ฟเวอร์ในเครือข่ายส่วนตัวเสมอและพร้อมที่จะช่วยเหลือในการตั้งค่า และสำหรับผู้ที่ต้องการคิดออกเอง เราก็แบ่งปันคำแนะนำ สำหรับการตั้งค่า IPSec/L2TP บนคลาวด์ของเราในโหมด site-to-site หรือ road -warrior และหากใครต้องการตั้งค่าบริการ VPN บนเซิร์ฟเวอร์ Windows ของตนเอง พวกเขาก็พร้อมเสมอที่จะแบ่งปันคำแนะนำในการตั้งค่า RAS มาตรฐานหรือ OpenVPN แต่ไม่ว่าเราเจ๋งแค่ไหน นี่ไม่ใช่เวลาที่ดีที่สุดในการทำงานด้านการศึกษากับลูกค้า เนื่องจากเราจำเป็นต้องแก้ไขปัญหาโดยเร็วที่สุดโดยให้ผู้ใช้เกิดความเครียดน้อยที่สุด
แนวทางแก้ไขที่เราดำเนินการมีดังนี้ เราได้ตั้งค่าการวิเคราะห์การรับส่งข้อมูลในลักษณะที่จะตรวจสอบความพยายามทั้งหมดในการสร้างการเชื่อมต่อ TCP ไปยังพอร์ต 3389 และเลือกจากที่อยู่นั้นพยายามสร้างการเชื่อมต่อกับเซิร์ฟเวอร์ที่แตกต่างกันมากกว่า 150 แห่งในเครือข่ายของเราภายใน 16 วินาที - สิ่งเหล่านี้คือแหล่งที่มาของการโจมตี ( แน่นอนว่าหากลูกค้าหรือพันธมิตรรายใดรายหนึ่งมีความต้องการอย่างแท้จริงในการสร้างการเชื่อมต่อกับเซิร์ฟเวอร์จำนวนมากจากแหล่งเดียวกัน คุณสามารถเพิ่มแหล่งที่มาดังกล่าวใน "รายการสีขาว" ได้ตลอดเวลา นอกจากนี้ หากระบุที่อยู่มากกว่า 150 รายการในเครือข่ายคลาส C เดียวเป็นเวลา 32 วินาทีก็สมเหตุสมผลที่จะบล็อกเครือข่ายทั้งหมด การบล็อกถูกตั้งค่าเป็นเวลา 3 วันและหากในช่วงเวลานี้ไม่มีการโจมตีจากแหล่งที่กำหนด แหล่งที่มานี้จะถูกลบออกจาก "บัญชีดำ" โดยอัตโนมัติ รายการแหล่งที่มาที่ถูกบล็อกจะได้รับการอัปเดตทุกๆ 300 วินาที
รายการนี้มีให้ตามที่อยู่นี้: คุณสามารถสร้าง ACL ของคุณตามนั้นได้
เราพร้อมที่จะแบ่งปันซอร์สโค้ดของระบบดังกล่าว ไม่มีอะไรซับซ้อนเกินไป (นี่คือสคริปต์ง่ายๆ หลายสคริปต์ที่คอมไพล์ในเวลาไม่กี่ชั่วโมงบนเข่า) และในขณะเดียวกันก็สามารถดัดแปลงและใช้งานได้ เพื่อป้องกันการโจมตีดังกล่าวเท่านั้น แต่ยังเพื่อตรวจจับและบล็อกความพยายามในการสแกนเครือข่ายด้วย:
นอกจากนี้ เราได้ทำการเปลี่ยนแปลงการตั้งค่าของระบบการตรวจสอบ ซึ่งขณะนี้จะติดตามปฏิกิริยาของกลุ่มควบคุมของเซิร์ฟเวอร์เสมือนในระบบคลาวด์ของเราอย่างใกล้ชิดยิ่งขึ้นต่อความพยายามที่จะสร้างการเชื่อมต่อ RDP: หากปฏิกิริยาไม่เกิดขึ้นภายใน ประการที่สองนี่คือเหตุผลที่ต้องให้ความสนใจ
วิธีแก้ปัญหาค่อนข้างมีประสิทธิผล: ไม่มีการร้องเรียนจากทั้งลูกค้าและคู่ค้า และจากระบบการตรวจสอบอีกต่อไป ที่อยู่ใหม่และเครือข่ายทั้งหมดจะถูกเพิ่มเข้าไปในบัญชีดำเป็นประจำ ซึ่งบ่งชี้ว่าการโจมตียังคงดำเนินต่อไป แต่ไม่มีผลกระทบต่องานของลูกค้าของเราอีกต่อไป
หนึ่งในสนามไม่ได้เป็นนักรบ
วันนี้เราได้เรียนรู้ว่าโอเปอเรเตอร์รายอื่นประสบปัญหาคล้ายกัน บางคนยังคงเชื่อว่า Microsoft ได้ทำการเปลี่ยนแปลงรหัสของบริการการเข้าถึงระยะไกล (หากคุณจำได้เราสงสัยสิ่งเดียวกันในวันแรก แต่เราปฏิเสธเวอร์ชันนี้อย่างรวดเร็วมาก) และสัญญาว่าจะทำทุกอย่างที่เป็นไปได้เพื่อค้นหาวิธีแก้ไขอย่างรวดเร็ว . บางคนเพิกเฉยต่อปัญหาและแนะนำให้ลูกค้าป้องกันตนเอง (เปลี่ยนพอร์ตการเชื่อมต่อ ซ่อนเซิร์ฟเวอร์ในเครือข่ายส่วนตัว และอื่นๆ) และในวันแรก เราไม่เพียงแต่แก้ไขปัญหานี้เท่านั้น แต่ยังสร้างรากฐานสำหรับระบบการตรวจจับภัยคุกคามระดับโลกที่เราวางแผนจะพัฒนาอีกด้วย
ขอขอบคุณเป็นพิเศษสำหรับลูกค้าและพันธมิตรที่ไม่นิ่งเงียบและไม่นั่งบนฝั่งแม่น้ำเพื่อรอซากศพของศัตรูลอยไปตามทางในวันหนึ่ง แต่ดึงความสนใจของเราไปที่ปัญหาทันทีซึ่งทำให้เรามีโอกาสที่จะกำจัด ในวันเดียวกัน
ที่มา: will.com