คู่มือการติดตั้ง Immutable Storage สำหรับ Backup เพื่อป้องกัน Ransomware บน Ubuntu

*ลิงก์ถาวรแนะนำ (Slug):* /setup-immutable-storage-backup-ubuntu-ransomware/ *หมวดหมู่หลัก:* Security & DevSecOps

—

# คู่มือติดตั้ง Immutable Storage สำหรับ Backup ป้องกัน Ransomware บน Ubuntu แบบละเอียด (Enterprise Guide)

เพราะเป้าหมายแรกของ Ransomware ยุคนี้ไม่ใช่เครื่องเซิร์ฟเวอร์จริง แต่เป็น “ไฟล์สำรองข้อมูล (Backup)” ของคุณต่างหาก!

—

สวัสดีเพื่อน ๆ พี่ ๆ สายวิศวกรระบบและ DevSecOps ทุกคนครับ จากประสบการณ์กว่า 20 ปีในการออกแบบระบบไอทีและกู้คืนระบบจากการโดน Ransomware โจมตีในโลกไอทีระดับองค์กร สิ่งหนึ่งที่ผมพูดได้เต็มปากเลยก็คือ “อย่าเพิ่งมั่นใจในระบบสำรองข้อมูลของคุณจนกว่าคุณจะทำให้มันเป็น Immutable”

ในอดีต เวลาแฮกเกอร์โจมตีระบบเป้าหมาย พวกเขาจะเริ่มเข้ารหัสเซิร์ฟเวอร์ใช้งานหลัก (Production) แล้วปล่อยให้เหยื่อกู้ข้อมูลคืนจากไฟล์ Backup แต่ในปัจจุบัน แฮกเกอร์ฉลาดขึ้นมากครับ สิ่งแรกที่พวกเขาจะทำทันทีที่เจาะระบบหลังบ้านเข้ามาได้คือ “ตามล่าหาที่เก็บข้อมูลสำรองข้อมูล ดักลบ หรือเข้ารหัสตัวไฟล์ Backup ทิ้งให้เกลี้ยงก่อน” เพื่อปิดประตูตายในการกู้คืนระบบ บังคับให้เราไม่มีทางเลือกนอกจากต้องจ่ายเงินค่าไถ่เท่านั้น

วันนี้ผมจะพาทุกคนมาทำแล็บเชิงลึก ตั้งค่า Immutable Storage (พื้นที่สำรองข้อมูลที่ห้ามแก้ไข/ห้ามลบ) โดยใช้ระบบปฏิบัติการ Ubuntu Server เป็นฐานรองรับ เพื่อใช้เป็นเกราะป้องกัน Ransomware ด่านสุดท้ายของบริษัทกันครับ

—

🧭 กลยุทธ์การสำรองข้อมูลยุคใหม่: กฎ 3-2-1-1-0

ก่อนจะไปทำแล็บเทคนิคัล เรามาปรับความเข้าใจเชิงกลยุทธ์ร่วมกันก่อนครับ ในอดีตเราอาจจะเคยได้ยินกฎการสำรองข้อมูลคลาสสิกอย่าง 3-2-1 Rule (ข้อมูล 3 ชุด, เก็บในสื่อ 2 ประเภท, อยู่ต่างสถานที่ 1 แห่ง) แต่ในยุคที่ Ransomware ระบาดหนัก กฎข้อนี้ได้รับการอัปเกรดเป็น 3-2-1-1-0 Rule ดังนี้ครับ:

3 (Copies): มีข้อมูลเก็บไว้อย่างน้อย 3 ชุด (Production 1 ชุด และ Backup อีก 2 ชุด)
2 (Media): เก็บไฟล์สำรองข้อมูลไว้ในสื่ออุปกรณ์ที่แตกต่างกัน 2 ประเภท (เช่น Local Disk, NAS, หรือ Tape)
1 (Offsite): ต้องส่งข้อมูลอย่างน้อย 1 ชุดออกไปเก็บนอกออฟฟิศ หรือคนละสาขา (Offsite Backup)
1 (Immutable / Offline): เก็บข้อมูลอย่างน้อย 1 ชุดให้อยู่ในโหมด Immutable (แก้ไขไม่ได้) หรืออยู่ในโหมด Offline (Air-Gapped) ที่ไม่มีเน็ตเวิร์กเชื่อมต่อถึง
0 (Errors): ต้องมีการทดสอบดึงข้อมูลกู้คืน (Restore Test) อัตโนมัติอยู่เสมอ เพื่อให้มั่นใจว่าเมื่อเกิดภัยพิบัติ ข้อมูลต้องนำกลับมาใช้งานได้จริงโดยปราศจากข้อผิดพลาด 0%

—

🖥️ 1. รายละเอียดการออกแบบสเปกเครื่องเสมือน (VM Spec Detail)

ในหัวข้อนี้ เราจะทำการสร้างเครื่องสำรองข้อมูลแบบ Immutable ขึ้นมาในรูปของ Hardened Repository (มักใช้งานคู่กับโปรแกรมสำรองข้อมูลระดับองค์กรอย่าง Veeam Backup & Replication หรือทูลสแกนอย่าง Restic/Kopia) โดยผมขอแนะนำรายละเอียดสเปกสำหรับจำลองทำงานบนเครื่อง VMware ESXi หรือ Proxmox VE ดังนี้ครับ:

⚙️ VM Specs (แนะนำสำหรับองค์กรขนาดกลาง)

vCPU: 4 vCPUs (หากระบบมี VM ที่ต้องสแกนสำรองเยอะ แนะนำให้ใช้สถาปัตยกรรมแบบ CPU Cores แท้ เพื่อความเร็วในการรวบรวมไฟล์)
RAM: 8 GB ถึง 16 GB (หากระบบสำรองข้อมูลต้องประมวลผลการคำนวณ Hash หรือรันการกู้คืนระบบแบบทันที Instant Recovery แนะนำให้จัด RAM 16GB ขึ้นไปครับ)
Storage Controller: แนะนำให้ตั้งค่าใช้ LSI Logic SAS หรือ VMware Paravirtual (PVSCSI) เพื่อประสิทธิภาพการส่งข้อมูลสูงสุด
Network Adapter: VMXNET3 ทำการระบุใช้เน็ตเวิร์กการ์ดขนาด 10 Gbps แยกวงเฉพาะ (Dedicated Backup LAN) ออกจากวงไอทีทั่วไป

💾 การวางโครงสร้างดิสก์ (Disk Configuration)

การกำหนดพาร์ทิชันดิสก์ถือเป็นหัวใจสำคัญครับ เพื่อให้ระบบ Immutable ทำงานได้เต็มประสิทธิภาพ แนะนำให้แยกดิสก์ออกเป็น 2 ลูกชัดเจน: 1. Disk 1 (System Disk): ขนาด 50 GB – 100 GB (ใช้สำหรับติดตั้ง OS Ubuntu Server) 2. Disk 2 (Backup Repository Storage): ขนาดใหญ่ตามปริมาณข้อมูลของลูกค้า (เช่น 2TB – 10TB) โดยตอนฟอร์แมตดิสก์ลูกนี้ ต้องเลือกใช้ระบบไฟล์ XFS เท่านั้น * *เหตุผล:* ระบบไฟล์ XFS รองรับฟังก์ชัน Block Cloning (Reflinks) ซึ่งช่วยให้ระบบสำรองข้อมูลสามารถทำฟูลแบ็กอัป (Synthetic Full Backup) ได้เร็วขึ้นเป็น 10 เท่า และประหยัดพื้นที่ดิสก์ได้มหาศาลโดยไม่มีการคัดลอกบล็อกข้อมูลซ้ำซ้อน

—

🔌 2. Use Case: การสำรองข้อมูล VMs จาก VMware ESXi

สถาปัตยกรรมระบบการกู้คืนความปลอดภัยและจัดเก็บไฟล์แบ็กอัปที่ปลอดภัยสูงสุด ควรมีหน้าตาดังนี้ครับ:

[ VMware ESXi Hosts ] (Production)
         │
         ▼ (สำรองผ่าน vStorage API)
[ Veeam Backup Server ] (เครื่องควบคุม - ห้ามเก็บไฟล์สำรองที่เครื่องนี้)
         │
         ▼ (ส่งทราฟฟิกตรงผ่านพอร์ตเฉพาะ)
[ Hardened Linux Repository ] (เครื่อง Ubuntu Server - ตัวเก็บ Immutable Storage)

🔒 กติกาเหล็กด้านความปลอดภัย (Hardening Rule):

1. เครื่อง Linux Repository (Ubuntu) ต้องแยกตัวออกจาก Active Directory Domain เสมอ (ห้าม Join Domain) เพื่อป้องกันกรณีที่โดเมนโดนยึดแล้วแฮกเกอร์ใช้สิทธิ์ Domain Admin มารีเซ็ตรหัสผ่านเครื่องแบ็กอัป 2. หลังการตั้งค่าติดตั้งเสร็จสิ้น ต้องปิดบริการ SSH (Secure Shell) ทิ้งถาวร เพื่อปิดกั้นการเข้ามาระดมโจมตีทางพอร์ต 22 3. ใช้กลไกการยืนยันตัวตนแบบใช้คีย์ครั้งเดียวผ่านทาง API แทนการเก็บรหัสผ่านถาวรไว้ที่ตัวโปรแกรมจัดการ

—

🛠️ 3. ขั้นตอนการติดตั้งและตั้งค่าบน Ubuntu Server (Step-by-Step)

มาลงมือรันคำสั่งจริงบนระบบปฏิบัติการ Ubuntu Server (แนะนำเวอร์ชัน 24.04 LTS หรือ 22.04 LTS) กันครับ:

ขั้นตอนที่ 1: การเตรียมระบบไฟล์ XFS

หลังติดตั้ง OS เรียบร้อยแล้ว ให้ตรวจสอบดิสก์ลูกที่สอง (เช่น /dev/sdb) และสั่งฟอร์แมตเพื่อสร้างพาร์ทิชันดิสก์ที่รองรับ Block Cloning:

# ตรวจสอบชื่ออุปกรณ์ดิสก์ lsblk

# ฟอร์แมตดิสก์ /dev/sdb เป็นระบบไฟล์ XFS โดยระบุ reflink=1 เพื่อรองรับ Block Cloning sudo mkfs.xfs -b size=4096 -m reflink=1,crc=1 /dev/sdb

จากนั้น ทำการสร้างโฟลเดอร์สำหรับ Mount และตั้งค่าให้ระบบสแกนดิสก์รันอัตโนมัติเมื่อเปิดเครื่องใหม่:

# สร้างไดเรกทอรีสำหรับเก็บไฟล์แบ็กอัป sudo mkdir -p /mnt/backup-storage # ค้นหาค่า UUID ของดิสก์ /dev/sdb sudo blkid /dev/sdb # เพิ่มคำสั่งการ Mount เข้าไปในไฟล์ /etc/fstab (นำ UUID ที่ได้มาวางแทนที่ด้านล่าง) # UUID=xxxx-xxxx-xxxx /mnt/backup-storage xfs defaults,noatime,nofail 0 0 sudo nano /etc/fstab

# สั่ง Mount ดิสก์ทั้งหมดตามค่าใน fstab sudo mount -a

—

ขั้นตอนที่ 2: ตั้งค่ายูสเซอร์เฉพาะสำหรับเขียนไฟล์สำรองข้อมูล (Non-Root User)

เพื่อไม่ใช้สิทธิ์ Root ของระบบในการเขียนไฟล์ลงในไดเรกทอรีแบ็กอัป ให้เราสร้างบัญชีผู้ใช้งานใหม่ชื่อว่า veeamuser (หรือชื่ออื่นตามสะดวก) และจำกัดสิทธิ์ความปลอดภัย:

# สร้างกลุ่มผู้ใช้และบัญชี veeamuser sudo groupadd veeamgroup sudo useradd -m -g veeamgroup -s /bin/bash veeamuser # ตั้งรหัสผ่านที่เดายากและรักษารหัสผ่านนี้ไว้เป็นความลับระดับสูง sudo passwd veeamuser

# กำหนดสิทธิ์ให้ veeamuser เป็นเจ้าของโฟลเดอร์เก็บไฟล์แบ็กอัป sudo chown -R veeamuser:veeamgroup /mnt/backup-storage sudo chmod 700 /mnt/backup-storage

—

ขั้นตอนที่ 3: เปิดโหมดล็อกข้อมูลแก้ไขไม่ได้ (Configuring Immutability)

หากพี่วิทย์รันระบบสำรองข้อมูลด้วย Veeam ตัวโปรแกรมจะส่ง Agent เข้ามาตั้งค่าสิทธิ์ให้เองโดยการใช้ API คีย์ครั้งเดียว แต่ถ้าพี่วิทย์ต้องการทำระบบแบบบ้าน ๆ ด้วยสคริปต์สำรองข้อมูลทั่วไป (เช่น เขียนสคริปต์ Backup ฐานข้อมูล SQLite หรือไฟล์ระบบแล้วอยากล็อกไม่ให้ใครลบ) เราสามารถสั่งล็อกข้อมูลผ่านคำสั่ง chattr (Change Attribute) ของระบบปฏิบัติการลินุกซ์ได้โดยตรงดังนี้ครับ:

# ขั้นตอนทดสอบเขียนไฟล์แบ็กอัปจำลอง echo "ไฟล์ข้อมูลสำรองความปลอดภัยองค์กร" > /mnt/backup-storage/test_backup.tar.gz

# สั่งตั้งค่าสถานะ "Immutable (ห้ามลบ/ห้ามเขียนทับ)" ให้แก่ไฟล์นี้ sudo chattr +i /mnt/backup-storage/test_backup.tar.gz

เมื่อใช้คำสั่ง +i แล้ว ลองมาจำลองเป็นแฮกเกอร์ที่ได้สิทธิ์ระดับสูงสุด (Root) แล้วพยายามลบไฟล์นี้ดูครับ:

# ทดสอบสั่งลบไฟล์ด้วยสิทธิ์สูงสุดของระบบ
sudo rm -f /mnt/backup-storage/test_backup.tar.gz

*ผลลัพธ์ที่ได้จากหน้าจอจะฟ้องข้อความกลับมาว่า:* ❌ rm: cannot remove '/mnt/backup-storage/test_backup.tar.gz': Operation not permitted (แม้กระทั่งยูสเซอร์ Root ก็สั่งลบไฟล์นี้ไม่ได้ตราบใดที่ยังมีแฟลกล็อกแอตทริบิวต์อยู่อย่างปลอดภัย!)

หากเมื่อครบกำหนดระยะเวลาเก็บข้อมูล (เช่น ผ่านไป 30 วัน) และต้องการทำลายไฟล์ทิ้งเพื่อเคลียร์พื้นที่ สามารถสั่งปลดล็อกได้โดยการรัน:

# ปลดล็อกสถานะเพื่อลบไฟล์
sudo chattr -i /mnt/backup-storage/test_backup.tar.gz
sudo rm -f /mnt/backup-storage/test_backup.tar.gz

—

🔒 4. การปิดประตูความปลอดภัยขั้นสุด (Hardening OS Level)

หลังจากเชื่อมต่อระบบสำรองข้อมูลเข้ากับซอฟต์แวร์เสร็จสิ้นแล้ว ให้ทำตามขั้นตอนการ Hardening เหล่านี้เพื่อความมั่นคงปลอดภัยขั้นสุดของลินุกซ์เซิร์ฟเวอร์ครับ:

1. จำกัดการใช้งานสิทธิ์แอดมิน (Disable Sudo Access)

หากพี่วิทย์แอดเพิ่มยูสเซอร์ veeamuser เข้าไปในกลุ่ม sudoer ชั่วคราวตอนแรกรันติดตั้ง หลังติดตั้งเสร็จสมบูรณ์แล้ว ให้ถอดสิทธิ์ sudo ของยูสเซอร์นี้ทิ้งทันที เพื่อความปลอดภัยไม่ให้แฮกเกอร์นำยูสเซอร์แบ็กอัปไปอัปเกรดสิทธิ์ตัวเองเป็น root:

sudo gpasswd -d veeamuser sudo

2. ปิดบริการ SSH ทันที (Stop & Disable SSH)

นี่คือไม้ตายในการสกัดแฮกเกอร์จากการรีโมตเข้ามาโจมตีพอร์ต SSH ของลินุกซ์แบ็กอัป:

# สั่งหยุดบริการ SSH และสั่งไม่ให้เปิดใหม่เมื่อเครื่องคอมพิวเตอร์รีบูต
sudo systemctl stop ssh
sudo systemctl disable ssh

หากในอนาคตพี่วิทย์จำเป็นต้องรีโมตเข้าไปบำรุงรักษาระบบ (Maintenance) ให้ต่อจอตรงเข้าเครื่องเซิร์ฟเวอร์ (Console) หรือเชื่อมต่อผ่าน KVM สั่งเปิดใช้ชั่วคราวด้วยคำสั่ง: sudo systemctl start ssh เมื่อทำงานบำรุงรักษาอุดรอยรั่วเสร็จสิ้นแล้วก็สั่งปิดทิ้งทันทีเช่นเดิมครับ

—

📝 บทสรุปแนวคิดความปลอดภัย (Security Takeaway)

การทำ Immutable Storage ป้องกัน Ransomware บน Ubuntu ไม่ได้อาศัยเครื่องมือราคาหลักล้านบาท แต่อาศัย “วินัยและการออกแบบสถาปัตยกรรมระบบความมั่นคงปลอดภัยที่ดี” ครับ การแยกเครื่องเก็บแบ็กอัปออกจากระบบเครือข่ายเดิม การปิดพอร์ตบริการที่ไม่ใช้งาน และการเปิดคุณสมบัติเขียนทับไม่ได้ (WORM) ในระดับระบบไฟล์ จะช่วยเป็นปราการด่านสุดท้ายที่จะช่วยกู้ชีวิตและปกป้องระบบไอทีของบริษัทในวันที่เกิดวิกฤต Ransomware โจมตีได้อย่างแท้จริงครับ

*หากเพื่อน ๆ พี่ ๆ สนใจการตั้งค่าแล็บความปลอดภัย ระบบ Infrastructure หรือ SOC และ AI อื่น ๆ ฝากกดติดตามข้อมูลการแบ่งปันความรู้ดี ๆ ได้ที่ช่อง InfraDiary หรือทางเว็บบล็อกหลักนี้ได้เลยนะครับ!*

🏷️ Tags:

← กลับไปหน้ารวมบทความ