By Arnon Puitrakul - 28 กรกฎาคม 2021
ตอนที่แล้วเรามาเล่าเรื่องของ MQTT ที่มันเป็นเทคโนโลยีที่ช่วยทำให้อุปกรณ์สามารถคุยกันเองได้ เหมาะกับอุปกรณ์ขนาดเล็ก ใช้พลังงานต่ำ แต่พอมันถูกใช้เยอะ ๆ ก็แน่นอนละว่า ย่อมเป็นเหยื่อในการโจมตีได้เช่นกัน วันนี้มาเป็นตอนต่อละกัน ว่าถ้าเรามี MQTT Broker แล้วเราจะทำยังไงให้ Server ของเราปลอดภัย ในแต่ละระดับของระบบเลย
ปล. เราจะมาเล่าแค่ไอเดียเท่านั้น ส่วนการ Implement แนะนำให้ไปดู Document ของ MQTT Broker แต่ละตัวเด้อ
ชั้นแรกสุด ล่างสุดเลย คือตัว MQTT Broker เอง ซึ่งเป็นที่ ๆ ส่วนต่าง ๆ จะเชื่อมต่อเข้ามา ในส่วนนี้ เรามองว่าสิ่งที่สำคัญที่สุดคือ การทำ Access Control ระดับ Application ว่าใครจะเข้าได้ หรือไม่ได้บ้าง ซึ่งจำเป็นต้องทำสิ่งที่เรียกว่า Authentication และ Authorisation
โดยปกติแล้ว เวลาเราลงพวก MQTT Broker ค่าเริ่มต้น จะอนุญาติให้เราต่อเข้าไปได้ตรง ๆ เลย ซึ่งแน่นอนว่า แบบนั้นมันไม่น่ารัก ไม่ปลอดภัยเลย ดังนั้น เราจำเป็นที่จะต้องเปลี่ยนสิ่งนี้ด้วย ซึ่งเราอาจจะใช้ได้อยู่ 3 วิธีด้วยกันคือ การกำหนด Authentication Credential อย่าง Username และ Password เพื่อเข้าถึง MQTT Broker, การใช้ X509 Client Certificate และการเชื่อมต่อผ่าน SSL
นอกจากนั้น เราอาจจะควบคุมการเข้าถึงได้ด้วย ว่าให้อุปกรณ์ไหนเข้าถึง Broker ได้บ้าง หรืออาจจะเพิ่มระดับเข้าไปอีกว่า ให้แต่ละเครื่องเข้าถึง Topic ไหนได้บ้าง ผ่านการทำสิ่งที่เรียกว่า Access Control List (ACL) ได้เช่นกัน
ย้อนกลับไปบทความตอนที่แล้ว ตอนที่เราเขียน Publisher ตอนนั้นเราจำเป็นที่จะต้องสั่งให้มัน Sleep 1 วินาที เพื่อให้มันรอสักวินาทีนึงแล้วค่อยส่งค่าใหม่ สาเหตุที่ต้องทำแบบนี้เพราะ เราไม่อยากให้ Traffic มันไป Flood ที่ MQTT Broker จนมันล่มไป แต่อันนั้นมันเป็นวิธีการแก้ปัญหาที่ปลายทางอยู่ดี การแก้ปัญหาที่ต้นทางคือ การ Throttle เราอาจจะกำหนดไปเลยว่า ให้ข้อมูลส่งเข้ามาที่เท่าไหร่ อาจจะกำหนดทั้งระดับ Global ของ Server และ กำหนดในแต่ละ Client เลยก็ได้ ก็จะเป็นการป้องกันในเรื่องของการโดน Flood ไป
นอกจากการ Flood ด้วย Traffic จำนวนเยอะ ๆ แล้ว มันยังสามารถที่จะ Flood ด้วยการยิง Packet ใหญ่ ๆ เข้ามาก็ได้เหมือนกัน โดยมาตฐานแล้ว MQTT อนุญาติให้เราส่งข้อมูลใหญ่สุดที่ 260 MB ใหญ่แบบจุก ๆ ไปเลย แต่ในความเป็นจริง ส่วนใหญ่แล้วเราก็ใช้ในการส่งค่าตัวเลขเพียงไม่กี่หลักเท่านั้น ทำให้จริง ๆ เราใช้กันอยู่หลักไม่กี่ Byte เท่านั้น ดังนั้น การเข้าไปกำหนด Max Message Size ก็เป็นอีกวิธีที่จะช่วยป้องกันการโดน Flood ด้วย Traffic ขนาดใหญ่ได้ด้วย
ยกขึ้นมาหน่อย ในระดับของ Server กันบ้าง ถ้าในระบบใหญ่ ๆ อาจจะใช้ Server ใหญ่ ๆ จริง ๆ หรืออย่างในบ้านก็อาจจะเป็น Raspberry Pi สักตัวอะไรแบบนั้น แต่พื้นฐานเดียวกัน โดยส่วนใหญ่แล้วพวกนี้จะทำงานบน Linux ซะเยอะ เราขอพูดถึงตรงนี้ละกันนะ โดยที่ Goal ของส่วนนี้คือ การทำให้ Server ของเราปลอดภัย ไม่โดนเข้าถึงโดยไม่ได้รับอนุญาติ
อย่างแรก คือ การจัดการเรื่องการ Remote ก่อนเลย อันนี้โดนกันรัว ๆ มาแล้ว นี่ก็โดนเองมาแล้วเหมือนกัน อย่างการ SSH เข้าไปใน Server โดยปกติแล้วเราจะใช้ Username และ Password ในการเข้าใช้ แต่เราแนะนำให้ไปเปลี่ยนเป็น SSH Key ดีกว่า ส่วนนึงคือสะดวก อีกส่วนมัน Brute Force ได้ยากกว่า (ไม่ใช่ทำไม่ได้นะ มันทำได้แต่ใช้เวลา) นอกจากนั้น ยังมีความเสี่ยงในเรื่องของการเข้าถึง Root ด้วย ซึ่งเป็นโคตร User หัวโจ๊กในเครื่อง เราไม่ควรให้ใครเข้าถึง โดยเฉพาะการเข้าถึงผ่าน Remote ถ้าเข้ามาได้คือแตกเลยนะ ทำอะไรก็ได้ ไม่ต้องทำ Privilege Escalation แล้วนะ คืออยู่สูงสุดอยู่แล้ว ดังนั้น เราควรที่จะปิด ไม่ให้ User Root SSH เข้ามาในระบบได้ก็จะปลอดภัยขึ้นเยอะ
และเรื่องสุดท้ายคือ อย่าลืม Update ระบบให้ใหม่เสมอ เราเข้าใจแหละบางที อะไรที่มันใช้ได้อยู่แล้ว อย่าไปยุ่งกับมันเดี๋ยวแตก แต่ในโลกของคอมพิวเตอร์มันไม่ใช่ไง อยู่เฉย ๆ นี่แหละ ยิ่งอยู่นาน โอกาสแตกมันก็จะเยอะขึ้นเรื่อย ๆ ถ้าเราไม่ Update ระบบของเราให้ใหม่อยู่เสมอ เพราะบางที ใน Software ที่เราใช้ หรืออาจจะใน MQTT Broker เอง มีพวก Bug ร้ายแรงที่อาจจะใช้เป็นช่องโหว่ในการโจมตีได้ ดังนั้น เราควรจะ Update ระบบของเราให้ใหม่อยู่เสมอ
จริง ๆ แล้ว มันยังมีอีกหลายส่วนเลย ที่จะทำให้ระบบของเราปลอดภัยขึ้น เช่นการใช้ SELinux หรือจะเป็นการตั้งค่า UFW เพื่อ Filter การเชื่อมต่อที่ไม่พึ่งประสงค์ออกไป ส่วนนี้จริง ๆ แล้วสามารถไปหาอ่านได้ในหัวข้อพวก Securing Linux
และส่วนที่ใหญ่ที่สุดคือระบบ Infra ของเรา โดยส่วนใหญ่แล้วในระบบขนาดใหญ่ ก็น่าจะมี Firewall เพื่อที่จะ Filter Traffic บางอย่างออกไปอยู่แล้ว หรืออาจจะมีพวก IPS/IDS อลังการ ๆ เลยคือใช้พวก Deep Packet Inspection (DPI) ก็ถือว่าเป็นเรื่องดีเลยละ แต่สำหรับระบบที่เล็กลงมาหน่อย จนไปถึงสเกลของการใช้งานในบ้านเลย เราคิดว่าที่ Router น่าจะมีพวก NAT Firewall บ้างแหละ เรารู้ว่า MQTT ทำงานบน Port 1883 และ 8883 เราก็อาจจะ Block Port ทั้งหมด และ เปิดเฉพาะอันที่เราใช้ ก็จะทำให้เราปลอดภัยขึ้นมาก
หรือจริง ๆ เผลอ ๆ เราสามารถแยก Network ออกมาผ่านพวก การใช้ VLAN เลยก็ได้ เพื่อทำให้ส่วนอื่น ๆ มองไม่เห็น MQTT Broker และ MQTT Broker มองไม่เห็นส่วนอื่น ๆ ของ Network เช่นกัน ก่อนหน้านี้ที่บ้านเราก็ใช้ IoT เยอะมาก ๆ และมีการส่งข้อมูลออกไปเยอะเวอร์เลยละ เราก็กังวลพอตัวเหมือนกัน เราเลยแยก VLAN ออกมาเป็น 2 ส่วนเลยคือ ส่วนที่เป็น IoT และส่วนที่เราใช้งาน ซึ่งก่อนหน้านี้เราใช้พวก Smart Home Device ที่มันต่อออก Internet อยู่แล้ว มันก็ไม่มีปัญหาอะไรที่มันจะอยู่คนละ VLAN กัน ก็อ้อมออก Internet แล้วกลับมาอีกทางละกันนะ ลดความกังวลได้เยอะ
MQTT ถูกเอามาใช้อย่างแพร่หลายมาก ๆ แต่เรื่องของ Security บนระบบพวกนี้ เป็นเรื่องที่หลาย ๆ คนอาจจะไม่ได้ให้ความสำคัญเท่าไหร่ โดยเฉพาะพวก Smart Home ที่เราเล่นมาเยอะมาก ๆ เรายังไม่ค่อยเจอเจ้าที่ให้ความสำคัญกับ Security และ Privacy จัด ๆ เลย การเอา วิธีที่เราเอามาแนะนำในวันนี้ก็จะเป็นเพียงการป้องกันเบื้องต้นละกัน ส่วนถ้าอยากอ่านเพิ่มเติม สามารถไปหาอ่านรวม ๆ ในเรื่องของพวก IoT Security ได้ โดยเฉพาะคนที่ทำ Smart Home เราแนะนำว่า ถ้าจะจริง ๆ จัง ๆ นอกจากเรื่องอุปกรณ์แล้ว ควรศึกษาเรื่องของ Security และ Privacy ของมันด้วย เพื่อป้องกันอันตรายต่าง ๆ ที่อาจจะตามมาทั้งทาง Logical และ Physical ของระบบและคนในบ้าน
หลังจากเมื่อหลายอาทิตย์ก่อน Apple ออก Mac รัว ๆ ตั้งแต่ Mac Mini, iMac และ Macbook Pro ที่ใช้ M4 กันไปแล้ว มีหลายคนถามเราเข้ามาว่า เราควรจะเลือก M4 ตัวไหนดีถึงจะเหมาะกับเรา...
จากตอนก่อน เราเล่าเรื่องการ Host Website จากบ้านของเราอย่างปลอดภัยด้วย Cloudflare Tunnel ไปแล้ว แต่ Product ด้าน Zero-Trust ของนางยังไม่หมด วันนี้เราจะมาเล่าอีกหนึ่งขาที่จะช่วยปกป้อง Infrastructure และ Application ต่าง ๆ ของเราด้วย Cloudflare Access กัน...
ทุกคนเคยได้ยินคำว่า Mainframe Computer กันมั้ย เคยสงสัยกันมั้ยว่า มันต่างจากเครื่องคอมพิวเตอร์ที่เราใช้งานกันทั่ว ๆ ไปอย่างไรละ และ Mainframe ยังจำเป็นอยู่มั้ย มันได้ตายจากโลกนี้ไปหรือยัง วันนี้เรามาหาคำตอบไปด้วยกันเลย...
เคยมั้ยเวลา Deploy โปรแกรมสักตัว เราจะต้องมานั่ง Provision Infrastructure ไหนจะ VM และ Settings อื่น ๆ อีกมากมาย มันจะดีกว่ามั้ยถ้าเรามีเครื่องมือบางอย่างที่จะ Automate งานที่น่าเบื่อเหล่านี้ออกไป และลดความผิดพลาดที่อาจจะเกิดขึ้น วันนี้เราจะพาทุกคนมาทำความรู้จักกับ Infrastructure as Code กัน...