Self-Hosted Service บน Home Lab จัดการอย่างไรให้ปลอดภัย

ช่วงหลัง ๆ กระแสการทำ Home Lab ฮิตขึ้นมาก ๆ ในประเทศไทยเรา มีคนถามเข้ามาเยอะมากว่า แล้วเราจะจัดการอย่างไรให้ระบบของเราปลอดภัยมากที่สุด วันนี้เราจะมารวบรวมวิธีคิดการวางสถาปัตยกรรมแบบ Defense-in-Depth สำหรับงาน Self-Hosting ง่าย ๆ กัน

Alternatives & Mitigations

ถ้าเราบอกว่า การจัดการให้ปลอดภัยที่สุดคือการไม่มี Services ที่ Expose ออกไปเลยละ มันจะดูกำปั้นทุบดินมาก ๆ แต่มันก็เป็นแบบนั้นจริง ๆ การไม่มีเลย ย่อมปลอดภัยมากกว่า

เราสามารถใช้ทางเลือกอื่น ๆ เพื่อทำให้ Service เรายังสามารถให้บริการได้ เช่น การใช้ Public Cloud เช่าแล้วติดตั้ง Software ที่ต้องการไปเลย หรือกระทั่งการซื้อ SasS Cloud มาใช้เลย เช่น อยากได้ Storage ก็ไปพวก Google Drive, Dropbox หรือ OneDrive ไปเลยมากกว่าที่จะเอาเครื่องมาตั้งเอง

หรือถ้าบอกว่า Services ทั้งหมดของเราไม่สามารถ On Cloud ได้ เราอาจจะเอาบางส่วนที่มีความเสี่ยงสูงขึ้น Cloud ไป แล้วเอาส่วนที่เหลือทำงานเป็น On-Premise ก็ได้เหมือนกัน ถือว่าเป็นการลดความเสี่ยงได้พอสมควร

หรือเราอาจจะพิจารณาการใช้ Self-Hosted VPN Service หมายความว่า เราแค่ Expose VPN Services ออกไป ที่มันต้องอาศัยการทำ Authentication ก่อนเข้าใช้งาน หากผ่านเข้าไปได้ มันจะเป็นเหมือนการสร้างอุโมงจากเครื่องที่อยู่ด้านนอกของ Home Network เข้าไปใน Home Network ของเราแบบปลอดภัย เพื่อความปลอดภัยมากขึ้น เรายังสามารถ Isolate Network ได้อีกว่า หาก VPN เข้ามา เราจะให้มันเข้าถึง Service หรือส่วนใดส่วนหนึ่งของ Network ได้ เสมือนว่า เรามีบ้านทั้งหลัง แต่ทางแขกเข้า จะไม่สามารถเดินเข้าบ้านได้โดยตรง ก็จะสามารถช่วยทำให้เราลดความเสี่ยงได้บางส่วนอีกเหมือนกัน

แต่ต้องยอมรับว่า ข้อเสียหลัก ๆ ของการใช้ VPN Service เลยคือ เราจะต้องต่อ VPN เข้ามาทุกครั้งที่จะใช้งาน Service ที่อยู่ด้านใน ดังนั้น Client หรือเครื่องลูกที่จะต่อเข้ามาจำเป็นต้องมีการติดตั้ง VPN Client และตั้งค่าเพื่อให้สามารถเชื่อมต่อเข้ามา ยังไม่นับว่า การให้ VPN มันกิน CPU หนักมาก ๆ เพราะข้อมูลที่วิ่งเข้ามันต้องผ่านการเข้าและถอดรหัสหนักมาก ๆ การให้บริการพร้อม ๆ กันสเกลใหญ่ ๆ จะต้องใช้อุปกรณ์ขนาดใหญ่มาก ๆ เช่น เอา VPN Service ไว้ใน Router จะต้องไปดูว่ามันสามารถรองรับ Concurrent ได้เท่าไหร่ หรือถ้าเราใช้เยอะจริง อาจจะต้องมี Dedicated System มารองรับเลย ก็ดูเป็นเคส ๆ ไป

ถ้าเราจบแบบนี้เลย มันก็ไม่น่าจะเป็นบทความเรื่องนี้ได้แล้วละ งั้นเราไปดูกันต่อว่า ถ้าเราต้องการทำ Self-Hosted จริง ๆ เราควรจะ Harden แต่ละส่วนตั้งแต่ Foundation ขึ้นไปถึงด้านบนอย่างไรบ้าง ทีละ Layer

The Foundation: Hardware & Hypervisor

ส่วนแรกที่เป็นพื้นสำคัญของระบบคือ Hardware และ Hypervisor หากเราใช้งาน VM เป็นส่วนที่หลายคนมักจะไม่ได้ให้ความสำคัญ เน้นการใช้ Software Stack ให้ใช้งานได้ง่ายที่สุด คุ้นเคยเป็นหลักซะมากกว่า แต่เชื่อเถอะว่า ส่วนนี้เป็นรากฐานที่สำคัญมาก ๆ ที่ถ้าทำมาดี ๆ มันช่วยเราลด Resource ในการ MA ได้มหาศาลมาก ๆ

อย่างแรกที่สำคัญมาก ๆ คือ การ Update กลุ่ม Firmware และ Microcode ในเครื่องของเราด้วย เหตุที่ย้ำเป็นเรื่องแรก เพราะเป็นเรื่องที่คนทั่ว ๆ ไปมักจะละเลยมาก ๆ บางคนใช้เครื่องคอมมา 5 ปีแล้ว แต่ยังไม่เคย Update Firmware, Microcode และ UEFI ใด ๆ ทั้งสิ้นเลย แต่สำหรับงานแบบนี้ บอกเลยว่า เป็นส่วนที่สำคัญละเลยไม่ได้เลย โดยเฉพาะถ้าเราไปซื้อ Enterprise Server มือสองที่มี IPMI ติดมาด้วยนี่ยิ่งสำคัญเลย

คำถามในส่วนนี้ ที่เราได้มาบ่อย ๆ คือ เราควรจะติดตั้งเครื่องแบบ Bare Metal หรือใช้งาน Hypervisor ต่าง ๆ ไป ส่วนตัวเราแนะนำว่า ถ้าเป็น Home Lab ที่เราต้องมี Service รันอยู่หลายตัว และแต่ละตัวไม่ได้ให้บริการในสเกลใหญ่ ใช้กันอยู่ 4-10 คน พร้อม ๆ กันเราคิดว่า การใช้งาน VM บน Type 1 Hypervisor ก็เป็นตัวเลือกที่ไม่เลว ยัด Service หลายตัวเข้าไปใจเครื่องเดียว เพราะมันช่วยลด Overhead เอา Resources ไปทำอย่างอื่น และ Attack Surface ที่เกิดจาก Host OS ถ้าเรารัน Hypervisor Type 2

ตัวอย่างเช่น Proxmox VE เป็นตัวเลือกที่ค่อนข้างแนะนำ เพราะพื้นฐานมันมาจาก Debian ที่คิดว่าคนใช้ Linux ต้องเคยผ่านมือมาแน่ ๆ และ มี Community สำหรับช่วย Support ค่อนข้างแน่น และ Active มาก ๆ เลยเป็นตัวเลือกที่ดีมาก ๆ หรือถ้าอยากได้ Vanilla มาก ๆ ไป KVM ได้เลย แต่อาจจะติดตั้ง Management Tools เพิ่มเข้าไปช่วยได้ ส่วน ESXi กับ Hyper-V ผ่านไป เราว่าไม่เหมาะกับ Home Lab เท่าไหร่ ใหญ่ไปเยอะ

ภายใน Hypervisor ต้องมีมาตรการป้องกันไม่ต่างกัน อย่างแรกคือ การปกป้อง Host OS หรือส่วนของ Hypervisor เช่น การย้าย Management ของ Proxmox เข้าไปใน Managed VLAN และเปิดการใช้งาน 2FA เสมอ อีกเรื่องที่คิดว่าคนละเลยมากคือ Resource Allocation ที่มักจะให้เยอะไปก่อน เพราะขี้เกียจปิดเครื่องแล้วค่อยมาขยายในอนาคต แต่การทำแบบนั้น เป็นอะไรที่น่ากลัวมาก ๆ เพราะหาก VM นั้นโดนโจมตี แปลงร่างให้กลายเป็น Zombie มันจะเป็นเครื่องพลังสูงที่พร้อมตบเรื่องที่เหลือให้ราบได้เลยละ

การอุดรอยรั่วในระดับ Hardware และ Hypervisor อาจจะดูเป็นเรื่องที่ไกลตัวและน่าเบื่อ แต่มันคือ "ปราการด่านสุดท้าย" (หรือด่านแรกสุด ถ้านับจากล่างขึ้นบน) ที่จะรับประกันว่า Service ต่างๆ ที่คุณ Host ไว้ จะทำงานอยู่บนสภาพแวดล้อมที่เชื่อถือได้ (Trusted Environment) อย่างแท้จริง

OS Security & Hardening

ขยับขึ้นมาในระดับ OS กันบ้าง เป็นอีกส่วนที่สำคัญมาก ๆ เพราะเป็นตัวกลางคอยจัดการเรียก System Call, Networking และ File System หากเกิด Worst Case คือ โดยยึดระบบไปเท่ากับว่า ทุกอย่างที่รันอยู่ในนั้น ก็จะตกเป็นอันตรายทันที

จุดเริ่มต้นแรกที่สำคัญคือ การเลือก OS แนะนำว่าควรจะเป็นรุ่น LTS (Long-Term Support) และยังไม่พ้นสถานะ EOL เพื่อให้มั่นใจว่า เราจะได้รับ Security Patch อย่างต่อเนื่อง และการเลือกใช้ Linux Distribution ที่เน้นความเสถียร และ Security อย่าง Debian, Ubuntu LTS หรือแม้แต่ Project อย่าง Rocky ก็เป็นอีกทางเลือกนึงสำหรับสาย Self-Hosting ได้เหมือนกัน

อย่างถัดไปคือ PoLP (Principle of Least Privillage) อย่าให้ขาด เพราะหลาย ๆ ครั้งเราเจอว่า ก็ Service มันรันในบ้าน เราก็สร้าง User ที่เป็น Root ทำได้ทุกอย่างตัวเดียวพอแล้ว ไม่ต้องมานั่งจัดการ Permission แหละ แต่ถ้าเกิดโดนโจมตีเข้ามาได้ เท่ากับว่า เขาไม่ต้องพึ่ง Attack Chain เพื่อทำ Privillage Escalation เลย เพราะเขาได้มาแต่แรกแล้ว พร้อมทะลวงทุกอย่างที่ขวางหน้า

อย่างถัดไปคือ การทำ Patch Management อย่างเป็นระบบ เรารู้ ทุกคนรู้ โลกรู้ว่า การ Update Security Patch อย่างสม่ำเสมอ สามารถช่วยลดความเสี่ยงในการโจมตีสำเร็จได้สูงมาก ๆ แต่การจะต้องเข้าไปนั่งสั่ง Update ด้วยตัวเองอาจจะเป็นเรื่องที่น่าปวดหัวไปวักหน่อย การตั้งค่า Unattened-Upgrades เพื่อให้ระบบทำการติดตั้ง Security Patch เองเป็นอีกตัวเลือกที่ไม่เลวเลย

5 วิธีการทำให้ SSH ของคุณ ”แข็ง(แกร่ง) อึด ทน”

SSH น่าจะเป็น Protocol ที่หลาย ๆ คนใช้ในการเข้าถึง Shell ของเครื่องปลายทาง สำหรับควบคุมการทำงานของเครื่องคอมพิวเตอร์ต่าง ๆ แต่มันไม่น่าจะดีเท่าไหร่ หาก SSH Server ไม่แข็งแกร่งมากเพียงพอ วันนี้เราจะมาแนะนำ 5 วิธีการที่จะช่วยลด Attack Surface ของ SSH Server ในเครื่องของเรากัน

ArnondoraArnon Puitrakul

สุดท้ายคือ SSH Hardening เพราะบอกเลยว่า SSH เป็น Service ในฝันของเหล่า Botnet เลย สุ่ม ๆ หรือลองจิ้ม ๆ สักหน่อย เผื่อได้ขึ้นมา ก็คือ อร่อยเลยละ เราเคยเขียนเรื่องของ SSH Hardening ไว้ในลิงค์ด้านบนแล้วกลับไปอ่านกันได้

Container Security & Lifecycle Management

ตั้งแต่ Concept ของ Containerisation เข้ามา โลกของการติดตั้ง Service ใช้งานมันง่ายขึ้นกว่าเดิมมาก ๆ แค่ Pull แล้ว Run ก็เสร็จแล้ว แต่การทำแบบไม่ตรวจสอบที่มานี่แหละ คือ ความเสี่ยงมหาศาล

อย่างแรกที่สามารถลดความเสี่ยงได้คือ การ Update Container Engine เช่น Docker และ Podman อย่างสม่ำเสมอ เพราะในประวัติศาสตร์ที่ผ่านมามันเคยมีช่องโหว่อย่าง Container Breakout ที่ทำให้ Attacker หลุดออกจาก Container เข้าควบคุม Host ได้เฉยเลย

อย่างที่ 2 คือ การทำ Automated Update เราสามารถใช้เครื่องมืออย่าง watchtower เพื่อ Monitor และ Update Container แบบอัตโนมัติ ทำให้สามารถช่วยจัดการกับช่องโหว่ที่ค้นพบและมีการ Patch แล้วได้รวดเร็วขึ้น แต่ ๆๆๆๆๆ ควรจะตั้ง Scope ของการทำงานให้ดี อย่าให้มัน Update Major Version ที่อาจจะมี Breaking Change ไม่งั้น Upgrade ขึ้นไปแล้วเสี่ยงแตกมาก ๆ

และสุดท้ายคือ Image Security ตั้งแต่การตรวจสอบความน่าเชื่อถือของ Image ที่เรานำมาใช้งาน แนะนำให้เป็น Official Source หรือ Community ที่มีการจัดการช่องโหว่ และดูแลอย่างสม่ำเสมอ เลี่ยงการใช้ Image จาก Unverified Source

หากเป็นไปได้ การใช้ Image ที่สร้างจาก Alpine Linux ก็เป็นตัวเลือกที่ไม่เลวมาก ๆ เพราะตัวมันเล็กมากหลักไม่กี่ MB เท่านั้น เลือกติดตั้ง Package เท่าที่จำเป็นเท่านั้น นั่นหมายถึงการลด Attack Surface ที่อาจจะถูกใช้เป็นเครื่องมือในการเข้าโจมตี หรือควบคุมระบบของเราได้ และท้ายสุด การทำ Image Tag Pinning และ Digest ช่วยให้เราจัดการกับ Image ได้ง่ายขึ้นกว่าเดิมมาก ๆ

Internal Network Architecture

ขยับขึ้นมา คือเรื่องของการจัดการ Network ส่วนนี้เราขอพูดถึงแค่การจัดการ Internal Network ก่อน

Network ปกติของบ้านทั่วไป มันไม่เหมือนระบบของ Business/Enterprise ที่ทำ Network Segmentation เพื่อจัดการกับความยุ่งยากของระบบที่ซับซ้อน แยกออกไป แต่สำหรับ Home Lab ที่มี Self-Host Services เราก็แนะนำให้ Segment ระบบเช่นเดียวกัน

เหตุผลไม่ได้เพราะต้องการจัดการความยุ่งยาก แต่ลดความเสี่ยงที่หากระบบใดระบบหนึ่งถูกยึดครอง หรือโจมตี มันจะสามารถทำ Lateral Movement เข้าไปโจมตีเครื่องอื่น ๆ ในเครือข่ายได้ทันที ดังนั้น การจัดการสร้าง Network Segmentation จึงเป็นเหมือนการแบ่งห้องตาม Function การทำงานให้เป็นสัดส่วนมากขึ้น

หลัก ๆ เรา จะทำงานอยู่บน L2 และ L3 เป็นหลัก ตั้งแต่การ Segment ด้วย VLAN และ Subnetting อาจจะแบ่งเป็น 4 ส่วนด้วยกันคือ

1. Management VLAN สำหรับอุปกรณ์โครงสร้างพื้นฐานเช่น Switch, Hypervisor และ IPMI
2. Trusted VLAN สำหรับอุปกรณ์ส่วนตัวที่ต้องการความปลอดภัยสูง
3. IoT VLAN สำหรับอุปกรณ์ IoT ที่มักจะมีระบบ Security ต่ำ หรือเสี่ยงต่อการล้วงข้อมูลกลับไปที่แดนแพนด้า
4. DMZ/Public Service สำหรับรัน Self-Hosted Services ที่ต้อง Expose ออก Internet โดยเฉพาะ

แต่การแบ่ง VLAN จะไม่มีผลอะไรเลย หากเราไม่มีการตั้งกฏที่เข้มงวด ควรใช้หลักการ Deny by Default ไปก่อนแล้วค่อยเปิดเฉพาะช่องทางที่เราต้องการ เช่น การอนุญาติให้ Trusted VLAN เข้าไปจัดการ Public Services VLAN ได้ แต่จะไม่อนุญาติให้ Public Service ขยับเข้ามาในวง Trust หรือการจำกัดให้ Public Server สามารถเข้าถึง Gateway และ Port ที่จำเป็นเท่านั้น

External Network & Threat Mitigation

พูดถึงฝั่งนอกบ้านกันบ้าง คือ เมื่อเราต้องเปิดประตูบ้านให้โลกภายนอกเข้ามา เราจำเป็นต้องมี รปภ มาคอยสกรีน Traffic ก่อนถึง Server จริงของเรา

วิธีการที่เราแนะนำมาก ๆ คือ การใช้ Proxy Server เข้ามาช่วย ตัวที่นิยมมาก ๆ หนีไม่พ้น Cloudflare แน่นอน คิดภาพง่าย ๆ ว่ามันคือการทำ Reverse Proxy ในระดับ Global มันสามารถช่วยเราซ่อน IP Address จริง ๆ ของ Server เราไม่ให้ถูกค้นเจอได้ง่าย นอกจากนั้นยังได้ประโยชน์จาก WAF ที่ติดมาด้วย คอย Block Traffic ที่น่าสงสัยอย่าง SQL Injection หรือ XSS ได้

IP Ranges

This page is intended to be the definitive source of Cloudflare’s current IP ranges.

Cloudflare Color Logo

จากนั้น เราจะต้อง Secure การเชื่อมต่อระหว่าง เรากับ Cloudflare วิธีการที่ง่ายที่สุด เราคิดว่า คือการทำ IP Whitelisting คือการตั้งกฏที่ Gateway ของเราเลยว่า ให้รับ Traffic Port 443 จาก IP Range ของ Cloudflare เท่านั้น วิธีการนี้จะช่วยป้องกันไม่ให้ผู้โจมตีรู้ IP จริง พยายามยิงเข้ามาในเครื่องโดยไม่ผ่าน Cloudflare ซึ่งเราสามารถตั้งค่า Whitelist ได้จาก List ที่ Cloudflare ให้มาได้เลย

และสุดท้าย ถ้าเกิดเรารู้ว่า เราจะต้องให้บริการแค่ในพื้นที่ใดพื้นที่หนึ่งในโลกเท่านั้น การใช้งาน Geo-Blocking Service สามารถช่วยปิดกั้น Traffic จากประเทศที่ไม่เกี่ยวข้อง สามารถช่วยลด Attack Attempt จาก Botnet ทั่วโลกได้มหาศาล

ID Access Management & Internal Reserver Proxy

แม้เราจะมี Cloudflare เป็น Frontline อยู่แล้ว แต่เมื่อ Packet วิ่งจาก Cloudflare เข้ามาใน Network ของเราแล้ว มันยังต้องมีตัวกลางที่คอยกระจาย Traffic ไปยัง Service ต่าง ๆ ให้ถูกต้อง และปลอดภัย ซึ่งนี่คือหน้าที่ของ Internal Reverse Proxy และ Authentication Middleware

Reverse Proxy ทำหน้าที่เหมือน ประชาสัมพันธ์หน้าตึกเรา คอยรับ Traffic จากข้างนอกเข้ามา และบอกทางไปยังชั้นที่ถูกต้องในตึกของเรา เช่นการใช้ Nginx และ Traefik เป็นต้น อีกอย่างที่คนละเลยมาก ๆ คือ แม้จะเป็นการเชื่อมต่อภายในบ้านของเราเอง ยังไง เราก็ควรคุยกันด้วย HTTPS เสมอ ปลอดภัยไว้ก่อนดีกว่า

อีกส่วนที่เราพึ่งหยิบมาใช้ไม่กี่ปีคือ Authentication Middleware คือแทนที่เราจะให้คนเดินเข้าตึกผ่านประชาสัมพันธ์ทันที เราจะตั้งเครื่องสแกนบัตรเข้าออกไว้ด้านหน้า ในเชิง Network คือ เมื่อมี Request วิ่งเข้ามาที่ Reserve Proxy มันจะยังไม่ส่ง Request นั้นไปที่ Service Container ทันที แต่จะส่งไปถาม Autentication Middleware อย่าง Authelia และ Authentik ก่อน

หากผู้ใช้ยังไม่ได้ยืนยันตัวตน มันจะ Redirect เข้าไปหา Login Portal และบังคับให้ทำ Authentication ตามวิธีการที่ตั้งไว้ทันที เมื่อผ่านแล้วมันจะยัด Session Cookie แล้ว Reverse Proxy ถึงจะอนุญาติให้ Traffic นั้นสามารถผ่านเข้าไปใน Service Container ได้

Access | Zero Trust Network Access (ZTNA) solution

Cloudflare Access is a fast, reliable Zero Trust Network Access solution that secures employees and contractors. Simplify ZTNA with Cloudflare.

Cloudflare Color Logo

อย่างเว็บ Arnondora เราก็ไม่ได้ตั้ง Service ของ Authentik นะ แต่เราใช้ Zero-Trust Authentication ที่เป็นบริการของ Cloudflare ทำงานอยู่บน Cloud โดยไม่ต้องตั้ง Service ขึ้นมาเองเลย พวกนี้เราสามารถให้มันเชื่อมต่อกับ IDP ขององค์กรตัวเอง หรือจะใช้ Public IDP อย่าง Github ก็ได้เหมือนกัน

สรุป

การทำ Self-Host มันไม่ใช่การรัน docker compose up -d แล้วจบ แต่มันคือการวางสถาปัตยกรรมแบบ Defense-in-Depth ที่มีระบบป้องกันทับซ้อนกันหลาย ๆ ชั้น หากชั้นใดชั้นหนึ่งเกิดแตก ชั้นต่อไปมันยังสามารถพอจะช่วยปกป้อง ชะลอ หรือกระทั่งหยุดยั้งความเสี่ยหายได้ ท้ายที่สุดแล้ว หากรู้สึกว่าการ Expose Service ออก Internet มีต้นทุนในการดูแลรักษาที่สูงเกินไป หรือยังไม่พร้อมรับความเสี่ยง เราว่าการใช้ Alternative อย่าง Tailscale หรือ WireGuard VPN น่าจะยังคงเป็น Best Practice ที่ดีสำหรับคนที่ใช้งานคนเดียวหรือกลุ่มปิดเล็ก ๆ และท้ายสุดเราอยากบอกว่า เรื่องของ Security มันไม่ใช่แค่เรื่องของการทำแล้วจบไป แต่มันคือกระบวนการที่ต้องอาศัยการหมั่นตรวจสอบและ Update อย่างสม่ำเสมอ จบสวยปะ คิดนานมากนะ !