- กลุ่มแฮกเกอร์ยูเครน ร่วมมือกับหน่วยข่าวกรองทางทหาร ทำให้โครงสร้างพื้นฐาน IT ของ Gaskar Integration ผู้ผลิตโดรนรายใหญ่ของรัสเซียเป็นอัมพาต
- ข้อมูลสำคัญและข้อมูลสำรอง มากกว่า 47TB ถูกลบ ส่งผลให้การดำเนินงานธุรกิจหลักหยุดชะงัก
- ระบบภายในโรงงาน รวมถึงโปรแกรมบัญชีและการผลิตทั้งหมด อยู่ในสภาพใช้งานไม่ได้
- แม้แต่ประตูทางเข้าออกโรงงานผลิตก็ถูกปิดกั้น ทำให้พนักงานต้องใช้ทางออกฉุกเฉินในการเข้าออก
- ข้อมูลที่ถูกดึงออกไปมีทั้งข้อมูลส่วนบุคคลของพนักงานและเอกสารทางเทคนิคของโดรน และถูกส่งมอบให้กระทรวงกลาโหมยูเครน
เนื้อหาหลัก
- นักเคลื่อนไหวไซเบอร์ของยูเครนร่วมมือกับหน่วยข่าวกรองทางทหาร โจมตีเครือข่ายและโครงสร้างพื้นฐานเซิร์ฟเวอร์ของ Gaskar Integration ซึ่งเป็นหนึ่งในผู้ผลิตรายใหญ่ที่สุดที่จัดหาโดรนให้กองทัพรัสเซีย
- การโจมตีครั้งนี้ทำลายข้อมูลทางเทคนิคมากกว่า 47TB และข้อมูลสำรองอีก 10TB โดยข้อมูลดังกล่าวยังมีร่องรอยความร่วมมืออย่างใกล้ชิดระหว่างรัสเซียกับจีนรวมอยู่ด้วย
- จากการแฮก ทำให้ทั้งอินเทอร์เน็ต โปรแกรมการผลิต โปรแกรมบัญชี และทุกระบบภายในบริษัท เป็นอัมพาต ส่งผลให้ศูนย์วิจัยและพัฒนาของ Gaskar ไม่สามารถดำเนินงานได้ตามปกติด้วย
- ประตูทุกบานภายในโรงงานผลิตโดรนถูกปิดกั้น ทำให้พนักงานต้องใช้ทางออกฉุกเฉินในการเลิกงานและเคลื่อนย้าย
- ข้อมูลที่ถูกดึงออกมาประกอบด้วย แบบสอบถามลับของพนักงาน เอกสารทางเทคนิคเกี่ยวกับการผลิตโดรน เป็นต้น และข้อมูลดังกล่าวถูกส่งต่อให้ผู้เชี่ยวชาญภายใต้กระทรวงกลาโหมยูเครน
ภูมิหลังเพิ่มเติม
- ผู้เชี่ยวชาญไซเบอร์สังกัดหน่วยข่าวกรองทางทหารเคยมีกรณี ทำให้เว็บไซต์การรถไฟรัสเซียใช้งานไม่ได้ จากการโจมตีรุนแรงมาแล้ว
- ในอดีตก็เคย โจมตี Regiontransservice ของรัสเซีย ได้สำเร็จ จนทำให้บริการทั้งหมดหยุดชะงัก
1 ความคิดเห็น
ความเห็นจาก Hacker News
ฉันดูแลแล็บเล็ก ๆ ที่บ้าน มีบริการอยู่ราว 30 ตัว
วันหนึ่งตอนเปลี่ยนดิสก์หลัก ฉันเลยใช้แบ็กอัปสร้างทุกอย่างขึ้นใหม่ตั้งแต่ต้น และกลับมาใช้งานได้ภายในหนึ่งชั่วโมง
แต่หลังจากนั้นก็ต้องใช้เวลาอีกเป็นสัปดาห์คอยแก้ตรงนั้นทีตรงนี้ที รวมถึงส่วนที่จำไม่ได้แล้วว่าตั้งค่าแบบนั้นไปทำไม
นี่เป็นแล็บแบบง่าย ๆ ที่ใช้ Docker และมีคนดูแลแค่คนเดียว แถมฉันก็ทำงานสาย IT ด้วย
แต่การกู้คืนอินฟราทั้งหมดจากศูนย์ที่มีคนหลายคนช่วยกันดูแลมาหลายปีนั้น เป็นงานมหาศาลจริง ๆ
ฉันเคยไปช่วยกู้ระบบให้โรงพยาบาลแถวบ้านแบบอาสาสมัครตอนโดน ransomware และเจ้าหน้าที่ IT สองคนนั้นไม่รู้เลยว่าควรทำอย่างไร ขณะที่การสนับสนุนอย่างเป็นทางการก็ต่ำกว่าที่คาดมาก
ฉันยังเคยช่วยเหตุ ransomware ของบริษัทใหญ่ด้วย และสิ่งที่หนักมากคือการพยายามนึกให้ได้ว่าทำไมระบบถึงถูกตั้งไว้แบบนั้น
ถึงจะบอกว่ามีเอกสารและมีการทดสอบ แต่พอเจอสถานการณ์จริงก็รู้เลยว่าความเป็นจริงโหดแค่ไหน
บ้านเราเคยโดนตำรวจบุกค้นแล้วขนเดสก์ท็อป แล็ปท็อป NAS ฮาร์ดไดรฟ์ และอุปกรณ์รวมมูลค่าราว 10,000 ดอลลาร์ไป
เพราะงานก่อนหน้าฉันเคยรับผิดชอบเรื่องแบ็กอัปกับแผนกู้คืนจากภัยพิบัติ เลยเตรียมตัวไว้แล้ว
ภายในวันสองวันก็เอาส่วนใหญ่กลับมาได้ ข้อมูลหายไปประมาณสองวัน ซึ่งโชคดีที่เป็นของใช้ในบ้านเลยไม่ถึงขั้นร้ายแรง
หลังจากเหตุการณ์นี้ฉันก็ปรับปรุงเชิงโครงสร้างหลายอย่าง ทำให้ถ้าเกิดอีกความเสียหายจะน้อยลง
(แล้วอีก 8 เดือนต่อมาตำรวจก็สรุปว่าฉันไม่ผิดและบอกให้มารับอุปกรณ์คืน แต่ลูก ๆ ก็มีบาดแผลทางใจไปแล้ว)
นี่แหละคือเหตุผลที่การทำเอกสารสำคัญมาก และในระดับ software architecture ก็เหมือนกัน
ผ่านไปไม่กี่เดือนก็ลืมได้ง่าย ๆ แล้วว่าทำไมถึงเลือกแบบนั้น
เช่น "ทำไมถึงเลือก Kysely เป็น ORM/SQL tool", "ทำไมใช้ Deno/Bun", "ทำไมโครงสร้างโฟลเดอร์เป็นแบบแยกตามฟีเจอร์", "ทำไมต้อง fork ไลบรารี และจะดูแลมันอย่างไร", "ทำไมเลือก AWS/GCP/Azure/Docker", "ทำไมเลือก Kubernetes distribution นี้", "ทำไมเริ่มโปรเจกต์นี้ขึ้นมา/เป้าหมายคืออะไร" เป็นต้น
เพราะแบบนั้นฉันเลยสร้างส่วน # Decisions ไว้ใน README.md เพื่อจดไว้
มันช่วยให้ฉันเลิกคอยสงสัยการตัดสินใจของตัวเองแล้วไล่เปิดเอกสารไม่รู้จบเสียที
เมนเฟรมยุค 90 เสถียรมากและมีความซ้ำซ้อนที่ดีมาก จนบางเครื่องไม่ต้องรีบูตเป็นสิบปีก็มี และอัปเกรดแบบไม่ต้องหยุดแม้กระทั่งระดับเคอร์เนลก็ทำได้
แต่มีบริษัทหนึ่งไฟดับ แล้วเครื่องปั่นไฟสำรองก็ล้มเหลว พอไฟกลับมาใช้ได้จริง ๆ กลับต้องใช้เวลาหลายเดือนกว่าจะรู้ว่าเครื่องนั้นเคยทำอะไรอยู่ และต้องเริ่มมันอย่างไร
หลังจากนั้นบริษัทส่วนใหญ่ก็เริ่มรีบูตเมนเฟรมโดยตั้งใจทุก 6 เดือนเพื่อทดสอบการเริ่มระบบใหม่
ในแนวปฏิบัติ IT สมัยใหม่ แทบไม่ได้คำนึงถึงการกู้คืนจากภัยพิบัติเลย
ต่อให้องค์กรทำแบ็กอัปอย่างเข้มงวด ก็ยังไม่ค่อยมีใครทดสอบการกู้คืนจริง
เพราะคนไม่พอ ทุกคนเลยเอาแต่รีบประกอบอะไรขึ้นมาให้ใช้ได้
การออกแบบอินฟราให้สร้างใหม่ได้ง่าย ต้องใช้แรงมากกว่าการติดตั้งเฉย ๆ ราวสองเท่า
อยากรู้เรื่องที่ไปช่วยโรงพยาบาลจาก ransomware แบบอาสาสมัคร
ในวงการ healthcare IT ปกติการให้สิทธิ์เข้าถึงเข้มงวดมาก แต่ก่อนถ้าไม่มีการอบรม PHI หรือไม่มีการตรวจประวัติ ก็มักเข้าไม่ถึงระบบ เลยอยากรู้ว่าเพราะเป็นเหตุฉุกเฉินถึงมีขั้นตอน onboard ชั่วคราวแบบเร่งด่วน หรือว่าเป็นการไปช่วยผ่านคนรู้จักในโรงพยาบาล
ฉันทำงานอยู่ที่บริษัทเยอรมันแห่งหนึ่ง
ฝ่ายวางแผนการผลิตกำลังทำงานจากแผนที่พิมพ์จาก Excel ล่วงหน้าไว้ 3 เดือน
การย้ายระบบ ERP ล้มเหลว และไม่มีใครรู้จะแก้อย่างไร
ฝ่ายวางแผนการผลิตปิดเรื่องนี้ไว้และไม่บอกฝ่ายวิศวกรรมด้วย
สภาพนี้น่าจะอยู่ต่อไปอีกหลายปี เป็นระบบที่ทำให้คอนซัลแทนต์มีงานกินยาว
มันพิสูจน์ว่า IT infrastructure ไม่ได้จำเป็นต่อการผลิตเสมอไป จะมีก็ดี ไม่มีก็ยังพอไปได้
ช่วงปลายยุค 90 ถึงต้นยุค 2000 กระทรวงกลาโหมเดนมาร์กพยายามนำระบบจัดซื้อใหม่ชื่อ DeMars ที่สร้างบน SAP มาใช้
เพื่อนของฉันที่ทำงานจัดซื้อ ตอนใกล้เปลี่ยนไปใช้ DeMars ได้สั่งของในความรับผิดชอบของตัวเองไว้เป็นจำนวนมหาศาล จนเคยถูกเรียกไปถามในข้อหาฉ้อโกงด้วย
เพราะเขาไม่ไว้ใจ DeMars มาก และคิดว่าต้องมีสต็อกสำรองไว้
แล้วพอ DeMars เริ่มใช้งานจริง งานจัดซื้อก็แทบหยุดไปหนึ่งปีเต็ม
สุดท้ายสินค้าที่เพื่อนฉันดูแลอยู่คือกลุ่มเดียวที่ยังมีสต็อกพอใช้ตลอดช่วงเปลี่ยนระบบใหม่
ฉันเคยทำงานเป็นนักพัฒนา firmware ที่บริษัทผู้ผลิตแห่งหนึ่งช่วงปลายยุค 90
ตอนนั้นยังเป็นยุคที่ทุกอย่างบันทึกลงกระดาษ
บริษัทเพิ่งติดตั้ง ERP บน Oracle สำเร็จ ทุกคนกำลังดีใจ แต่หกเดือนต่อมามีคนขับรถยกไปชนผนังห้องเครื่อง ทำให้ UPS ไฟไหม้ และแร็กอุปกรณ์สามแร็ก รวมทั้งเซิร์ฟเวอร์ Oracle ก็ไหม้หมด
เพราะไม่มีใครเชื่อใจระบบเต็มร้อย ทุกคนเลยยังจดทุกอย่างลงกระดาษอยู่ และจนถึงตอนฉันลาออกอีก 6 ปีต่อมา งานก็ยังดำเนินด้วยกระดาษบวก Excel report
สรุปแล้ววิธีแบบใช้กระดาษพิสูจน์ตัวเองว่าทนรถยกได้ดีกว่า
Excel เป็นสิ่งที่พนักงานออฟฟิศจำนวนมากเข้าใจและแก้ไขได้ด้วยสัญชาตญาณ
ถ้า IT infrastructure ส่วนใหญ่มีความเข้าถึงง่ายแบบนี้มากขึ้น ก็น่าจะใช้งานได้จริงมากกว่าเดิมเยอะ
ในอีกด้านหนึ่ง ถ้า IT automation ฝังแน่นในกระบวนการผลิตไปหมดแล้ว และไม่มีคนที่ยังคุ้นกับวิธีการแบบ manual เดิมเหลืออยู่ การถอยกลับไปทำแบบมืออาจยากมาก
แม้มันจะขึ้นอยู่กับความซับซ้อนของคำสั่งซื้อ/เวิร์กโฟลว์ด้วยก็ตาม
ถ้าไม่มีซอฟต์แวร์ โดรนก็ไร้ประโยชน์
ถ้าจำรายการชิ้นส่วนได้ก็คงพอประกอบ quadcopter สำหรับบังคับมือได้ แต่การผลิตชิ้นส่วนด้วย 3D printing การบินที่เสถียร การบินอัตโนมัติ การสอดแนม และการใช้งานขั้นสูงอื่น ๆ จะทำไม่ได้เลย
แม้แต่การควบคุมระยะไกลก็น่าจะลำบาก
สงครามไซเบอร์ในยูเครนกำลังไปถึงจุดสูงสุดใหม่ และมันเกินกว่าการโจมตีไซเบอร์ธรรมดาแล้ว
อย่างโรงงานผลิตโดรนของรัสเซียที่โดนโจมตีครั้งนี้ โดรนคือหนึ่งในสิ่งสำคัญที่เปลี่ยนโฉมสงครามนี้
โดรนสร้างนวัตกรรมทั้งด้านการลาดตระเวน การรบกวน และการสกัดกระสุน
มันสร้างความเสียหายได้มากเมื่อเทียบกับวัสดุที่ใช้ และด้วยความก้าวหน้าของเทคโนโลยีการรู้จำภาพ บางลำยังทำงานได้แม้ถูกกวนสัญญาณ
เหมือนโลกจริงกำลังกลายเป็นหนังสายลับ
มันแสดงให้เห็นว่ายูเครนเก่งมากในสงครามแบบอสมมาตร
ทั้งการทำลายเครื่องบินทิ้งระเบิดระยะไกลและการทำให้ฐานผลิตโดรนเป็นอัมพาต กำลังสั่นคลอนกำลังรบหลักของรัสเซีย
ไม่รู้ว่าสงครามจะจบอย่างไร แต่ชัดเจนว่าการต่อต้านของยูเครนจะยังดำเนินต่อไป
ในนวนิยาย Ministry of the Future มีภาพอนาคตที่โดรนพัฒนาไปไกลจนสงครามแบบดั้งเดิมหมดความหมาย เพราะไม่มีใครปลอดภัยอีกต่อไป
แม้แต่กลุ่มเล็ก ๆ ก็สามารถลอบสังหารใครก็ได้จากที่ไหนก็ได้บนโลก
ไอเดียน่าสนใจ แต่เรื่องเล่าไม่ค่อยแข็งแรง เลยไม่ค่อยอยากแนะนำตัวหนังสือเท่าไร
เรื่อง "โดรนที่ยังทำงานได้แม้ถูกรบกวนสัญญาณอิเล็กทรอนิกส์" ตอนนี้มีโดรนที่ควบคุมผ่านสายใยแก้วนำแสงโดยไม่ใช้คลื่นวิทยุแล้ว ซึ่งยิ่งน่ากลัวเข้าไปอีก
การที่โดรนมีบทบาทสำคัญในสงครามครั้งนี้ จะใช้ได้กับสงครามอื่นในอนาคตแค่ไหนยังต้องดูกันต่อ
สถานการณ์เฉพาะหน้าที่รัสเซียยอมรับความสูญเสียชีวิตจำนวนมากเพื่อคืบหน้าไปทีละน้อย กำลังทำให้ FPV drone มีคุณค่ามากเป็นพิเศษ
ประเทศส่วนใหญ่คงไม่ยอมรับความสูญเสียแบบนั้น จึงไม่น่าใช่ว่านี่จะกลายเป็นมาตรฐานของสงคราม
โดรนเจ็ตราคาถูกที่บินได้ไกลอาจมีบทบาทสำคัญมากกว่าเสียอีก
ข้อมูลในบทความนี้มีการคาดเดาปะปนอยู่มาก
เราได้ยินแค่เรื่องจากฝั่งเดียว และอาจถูกขยายเกินจริงเพราะมีคุณค่าทางโฆษณาชวนเชื่อ
ปกติระบบควบคุมเวอร์ชันย่อมมีอยู่ และนักพัฒนาแต่ละคนก็มักจะมีสำเนาโค้ดกับไฟล์ CAD อยู่ในเครื่องตัวเอง
อีเมลกับไฟล์เอกสารออฟฟิศอาจสูญหายจริง แต่ก็อาจไม่ถึงขั้นเป็นความเสียหายร้ายแรง
เว็บไซต์ก็ยังทำงานอยู่ตามปกติ
บริษัทที่โดนโจมตีครั้งนี้ก็ไม่ใช่ชื่อที่ดังมากในชุมชนโดรน จึงไม่น่าใช่ระดับที่การผลิตโมเดลใหญ่ ๆ หยุดชะงัก
พวกเขาคงไม่ได้ไม่รู้เรื่องพื้นฐานอย่าง version control และสไตล์ของคอมเมนต์นั้นก็ชวนให้รู้สึกเหมือน ChatGPT เขียนด้วย
ฉันทำงานอยู่ที่บริษัทขนาดกลางแห่งหนึ่งในสวิตเซอร์แลนด์
บริษัทกำลังพัฒนา ERP ของตัวเองอยู่ และ stack นั้นคือฝันร้ายชัด ๆ
พวกเราเรียกมันกันเองว่า ‘security through chaos’
ต่อให้ผู้โจมตีเจาะเข้ามาได้ ก็คงหาทางออกไม่เจอ
ต่อให้โค้ดพังไป 90% บริการก็ไม่สะเทือน เพราะ 95% เป็นโค้ดไร้ประโยชน์อยู่แล้ว
ฉันเคยพัฒนา MRP system สำหรับองค์กรขนาดใหญ่เอง เลยอยากรู้ว่าทางนี้จะลงเอยอย่างไร
ปกติฉันจะเพิ่มชั้นยืนยันกุญแจด้วย OTP-hash ทับแนวทาง security/disaster recovery ที่แนะนำอยู่แล้ว
เดิมก็คิดว่าตัวเองเอาจัดเหมือนกัน แต่ระบบนี้ให้ความรู้สึกเหมือนแผนเอาตัวรอดในวันสิ้นโลกเลย
มันให้ความรู้สึกเหมือนความทนทานที่ถือกำเนิดขึ้นจากวิวัฒนาการ
ตลกดีที่มันเหมือนกำแพง ICE ในโลกจริง
มันทั้งน่ากลัวและชวนทึ่งในเวลาเดียวกัน
บริษัทส่วนใหญ่ไม่ได้เตรียมรับมืออย่างชัดเจนกับสถานการณ์ที่คลังข้อมูลแทบทั้งหมดในบริษัทถูกลบเกลี้ยง และต้อง deploy ใหม่จากศูนย์
ถ้าคุณไม่เคยกู้กลับจากศูนย์จริง ๆ มาก่อน ก็มีโอกาสสูงมากว่าจะมีวงจรพึ่งพากันเองอยู่ใน dependency ของการ deploy
อย่างตอน deploy config pusher ด้วย Jenkins/Puppet/Ansible สุดท้ายก็มักเกิดจุดที่ Jenkins เองไปพึ่ง config pusher เข้า ทำให้ไม่สามารถตั้งทุกอย่างเรียงทีละขั้นได้อีก และต้องย้อนตามทุกการเปลี่ยนแปลงตั้งแต่อดีต
ในโลก IT แทบทุกส่วนมี circular dependency อยู่แล้ว
SSO กลายเป็น dependency ของแทบทุกระบบ และภายใน SSO เองก็เกิดความวนกันระหว่างเครือข่ายกับระบบจัดการต่าง ๆ
การบูตจากศูนย์ใหม่ทั้งหมดจึงยากและกินเวลามากเสมอ
ถ้าไม่สร้างอินฟราสองชุดที่แยกจากกันอย่างสมบูรณ์ ก็แทบเป็นไปไม่ได้เลยที่จะแก้ปัญหานี้แบบสมบูรณ์
บริษัทหนึ่งที่ฉันรู้จักก็เจอแบบนี้เมื่อปีที่แล้ว
storage cluster หลักที่ทุกอย่างพึ่งพาอยู่ตายลงหมด
สุดท้ายต้องใช้โน้ตบุ๊กของฝั่ง Dev ในการ deploy ทุกอย่างกลับขึ้นมาใหม่
black start (การกู้คืนหลังล้างทุกอย่างหมด) เป็นโจทย์ที่ยากมาก
แม้แต่ Facebook ก็เคยต้องใช้สว่านเจาะล็อกประตูดาต้าเซ็นเตอร์เพื่อเข้าไปกู้ระบบด้วยตัวเอง
สงสัยว่าในสถานการณ์แบบนี้จะกู้กลับมาได้อย่างไร
ถ้ายังมีเอกสารแบบกระดาษอยู่ จะใช้มัน bootstrap ระบบได้ไหม หรือควรสมมติว่ามันหายไปด้วยทั้งหมด
วงการก่อสร้างก็มีปัญหาคล้ายกัน
ผลิตภัณฑ์มีอายุใช้งาน 50 ปีขึ้นไป บางครั้งเป็นร้อยปี แต่ไฟล์แบบที่ทำไว้เมื่อ 30 ปีก่อน มักเปิดไม่ได้แล้วเพราะปัญหาความเข้ากันได้ของฟอร์แมต
มีการพูดเรื่อง digitization มาหลายสิบปี แต่สุดท้ายแบบ 2D เก่า ๆ (หรือทุกวันนี้คือ PDF ที่ถูกเรียกว่า ‘กระดาษดิจิทัล’) อาจเป็นสิ่งที่ช่วยอนาคตได้
การใช้กระดาษจริงกำลังลดลงเรื่อย ๆ แต่เพราะปัญหาความเข้ากันได้ของไฟล์ สุดท้ายกระดาษอาจกลับมามีประโยชน์ก็ได้
ในพาดหัวบทความ ผู้โจมตีถูกเรียกว่า ‘cyber activist’ แต่ในเนื้อความกลับเรียกว่า ‘cyber criminal’
มันทำให้นึกถึงพวกโจรสลัดกึ่งทางการในยุคเรือใบอย่าง privateer หรือ letter of marque ที่เคลื่อนไหวอยู่ในพื้นที่สีเทา
ในแนวคิดสงครามยุคที่ 4 ก็พูดถึงการเลือนรางของเส้นแบ่งระหว่างพลเรือนกับทหาร
กติกาการสู้รบกำลังคลุมเครือขึ้นเรื่อย ๆ
รัสเซียกำลังใช้โดรนฆ่าพลเรือนทุกวัน
นี่ไม่ใช่พื้นที่สีเทาแบบ hybrid war อะไรที่กำกวม แค่เป็นประชาชนที่พยายามไม่ให้เพื่อนบ้านตัวเองถูกโดรนคร่าชีวิตเท่านั้น
ดูเหมือนจะเป็นปัญหาเรื่องการแปล
เว็บไซต์นั้นออกแนวสนับสนุนยูเครนชัดเจน เลยอาจไม่อยากใช้คำที่ทำให้แฮ็กเกอร์ดูแย่ และใช้คำว่า ‘cyber criminal’ ในความหมายใกล้ ๆ กับ ‘แฮ็กเกอร์’ เฉย ๆ
ตามความเป็นจริง ดูสมเหตุสมผลที่สุดที่จะมองว่าเป็นการปฏิบัติการที่จัดตั้งอย่างเป็นระบบโดยกองทัพยูเครน
เพราะงั้นจะมองว่าเป็นอาชญากรก็คงไม่ถูกนัก
คล้าย ๆ Robin Hood
สำหรับบางคนคือฮีโร่ สำหรับบางคนคืออาชญากร
น่าจะเป็นเพราะบทความนี้เอาหลายข่าวมาปะรวมกัน เลยทำให้คำศัพท์ปนกันไป
ถ้ามีคำเฉพาะไว้เรียกคนที่อยู่คนละฝ่ายกันในสงครามไซเบอร์ก็คงดี
คำว่า “cyber activist” ฟังเหมือนผู้ประท้วงออนไลน์ธรรมดา เลยอยากให้มีคำอย่าง “cyber soldier” หรือ “network militia” มากกว่าคำเชย ๆ แบบในหนัง
ฉันขำอยู่คนเดียวที่วันที่ในรูปประกอบบทความห่างจากวันเริ่ม Unix epoch แค่วันเดียว
เว็บไซต์นี้มีความแปลกมาก
รัฐบาลรัสเซียบล็อกมันจนขึ้น TLS error และถึงจะเลี่ยงผ่านไปได้ก็ยังเจอหน้า "blocked" ของ Cloudflare ต้องใช้ VPN ถึงจะเปิดต้นฉบับบทความภาษารัสเซียได้
หน้าที่ลิงก์ไปเป็นภาษาอังกฤษก็จริง แต่สำหรับคนในรัสเซีย เวอร์ชันภาษารัสเซียของเว็บไซต์นี้อาจไม่ใช่เป้าหมายก็ได้
ในรัสเซียผู้คนอ่อนไหวเรื่องภาษา แต่ในยูเครนก็ยังมีการใช้ภาษารัสเซียกันมาก และมีการตีพิมพ์บทความภาษารัสเซียจริง
อยากแนะนำให้ใช้เว็บ archive อย่าง archive.today และ archive.org (Internet Archive) ด้วยเสมอ
มีคนเก็บ ลิงก์ archive ไว้เมื่อไม่นานนี้แล้ว
นี่อาจไม่ใช่ปัญหาของเว็บไซต์นั้นเอง แต่อาจเป็นผลจากการบล็อกของรัฐบาล หรือปัญหาฝั่ง CloudFlare
Cloudflare อาจบล็อกเพราะต้นตอของ TLS error นั้นก็ได้
สงสัยว่าทั้งสองฝ่ายกังวลเรื่อง firmware ของโดรนกันบ้างไหม
การแอบฝัง firmware ที่ถูกดัดแปลงลงไปในโดรนของฝ่ายตรงข้าม ดูมีคุณค่าทางยุทธศาสตร์มาก
น่าสนใจ แต่ความเสี่ยงสูงมาก (โดนจับได้ง่ายและอาจทำให้ปฏิบัติการทั้งชุดใช้การไม่ได้)
สุดท้ายแล้ววิธีที่แข็งกร้าวตรงไปตรงมามักจะสมเหตุสมผลกว่า
ปกติโดรนมักแฟลช firmware กันก่อนปฏิบัติภารกิจไม่นาน
ในทางปฏิบัติ การทำให้โดรนมีพฤติกรรมผิดปกติแบบแนบเนียน เช่น โจมตีฐานตัวเองตอนปล่อยขึ้น หรือเปิดให้ควบคุมจากระยะไกล น่าจะมีประสิทธิภาพมากกว่าการปิดโรงงานไปเลยด้วยซ้ำ
กลยุทธ์ที่น่าสนใจอย่างหนึ่งคือมีข่าวว่าบางครั้งมีการฝังไวรัสลงในการ์ด SD ของโดรน เพื่อให้ถ้าโดรนตกในเขตศัตรูแล้วฝ่ายนั้นเอาการ์ดไปเสียบคอมพิวเตอร์ เครื่องนั้นก็จะติดเชื้อ
“นักเคลื่อนไหวไซเบอร์ชาวยูเครนร่วมมือกับหน่วยข่าวกรองทางทหาร…”
หมายความว่าแค่ได้รับสัญญาณจากหน่วยข่าวกรองต่างชาติ จึงไม่ใช่สงครามไซเบอร์โดยตรง
ต่อความเห็นที่ว่า “แค่ได้รับสัญญาณจากหน่วยข่าวกรองต่างชาติ จึงไม่ใช่สงครามไซเบอร์โดยตรง”
หน่วยข่าวกรองรัสเซียโจมตีประเทศ NATO โดยตรงมานานแล้ว แทบไม่มีพื้นที่ให้แก้ตัวเลย
เพราะยูเครนกับรัสเซียทำสงครามกันมาหลายปีแล้ว สถานการณ์นี้จึงไม่จำเป็นต้องมี deniability แบบพอฟังขึ้นแต่อย่างใด
สงสัยว่าหน่วยข่าวกรองต่างชาติหมายถึงใคร และจริง ๆ แล้วทั่วโลกก็มีการโจมตีกันอยู่ตลอดเวลา อย่ามองโลกแบบไร้เดียงสาเลย
มีคนชี้ว่าบทความไม่ได้พูดถึง “หน่วยข่าวกรองต่างชาติ”
ระบุชัดว่าเป็นหน่วยข่าวกรองทางทหารของยูเครน