VPS ถูกแฮ็กต้องทำอย่างไร? วิธีรับมือที่ถูกต้องและปลอดภัย

ห้ามทำความสะอาด VPS ที่ถูกแฮ็ก

หาก VPS ของคุณถูกแฮ็ก การตัดสินใจที่สำคัญที่สุดจะเกิดขึ้นก่อนที่คุณจะรันคำสั่งใดๆ ห้ามพยายามทำความสะอาดเครื่อง ให้แยกเครื่องออกจากเครือข่ายผ่านผู้ให้บริการ ทำ snapshot ของดิสก์ไว้เป็นหลักฐาน เปลี่ยนข้อมูลรับรอง (credential) ทุกอย่างที่เคยเก็บไว้ในเครื่องนั้น จากนั้นให้สร้างเซิร์ฟเวอร์ใหม่ขึ้นมาแทนโดยใช้แหล่งข้อมูลที่คุณเชื่อถือได้

คุณไม่สามารถพิสูจน์ได้ว่า rootkit ถูกกำจัดออกไปแล้ว เพราะเครื่องมือที่จะใช้พิสูจน์คือเครื่องมือที่ผู้โจมตีควบคุมอยู่

นั่นคือเหตุผลทั้งหมด นี่คือกลไกที่อยู่เบื้องหลัง ผู้โจมตีที่เข้าถึงระดับ root สามารถแทนที่ ps เพื่อให้ process ID หนึ่งไม่ปรากฏในผลลัพธ์ที่แสดงออกมาได้ เพียงบรรทัดเดียวใน /etc/ld.so.preload ก็สามารถโหลดโค้ดของผู้โจมตีเข้าไปในทุกโปรแกรมที่เชื่อมโยงแบบไดนามิก (dynamically linked) บนเครื่องได้ ส่งผลให้ ls, ss และ find ต่างก็รายงานข้อมูลเท็จอย่างสอดคล้องกัน โมดูลเคอร์เนลที่โหลดได้ (loadable kernel module) สามารถซ่อนไฟล์ไว้ใต้ระดับ system call ทำให้แม้แต่ไฟล์ binary ที่เพิ่งดาวน์โหลดมาใหม่ก็ยังมองเห็นดิสก์ที่ดูสะอาดปกติ คุณลบโปรแกรมขุดเหรียญออก กราฟการใช้งาน CPU ตกลง และเซิร์ฟเวอร์ก็เงียบลง แต่ความเงียบนั้นก็คือลักษณะของ backdoor ที่ยังทำงานอยู่เช่นกัน

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

ยืนยันว่ามีการบุกรุกเกิดขึ้นจริง

เซิร์ฟเวอร์จำนวนมากที่ถูกรายงานว่าถูกแฮ็กนั้นแท้จริงแล้วไม่ได้ถูกแฮ็ก การพยายามล็อกอิน SSH ที่ล้มเหลวนับพันครั้งต่อวันถือเป็นสัญญาณรบกวนพื้นฐานของอินเทอร์เน็ต เนื่องจากทุกหมายเลข IPv4 สาธารณะจะถูกสแกนอย่างต่อเนื่อง ผลลัพธ์จาก lastb ที่เต็มไปด้วยความพยายามแบบ root และ admin หมายความว่าเครื่องมือสแกนพบพอร์ตของคุณแล้ว แต่นั่นไม่ได้หมายความว่ามีใครสามารถเข้าสู่ระบบได้

สัญญาณเหล่านี้ต่างหากที่บ่งบอกถึงปัญหา:

• การล็อกอินที่สำเร็จซึ่งคุณไม่ได้เป็นผู้ดำเนินการ เช่น Accepted password for root from 203.0.113.7
• คีย์ใน authorized_keys ที่คุณไม่ได้เพิ่มเข้าไป
• ประกาศแจ้งเตือนการละเมิดจากผู้ให้บริการโฮสต์ของคุณเกี่ยวกับทราฟฟิกที่ออกจากเซิร์ฟเวอร์
• กระบวนการทำงานที่ใช้ CPU 100% โดยมีชื่อที่คัดลอกมาจาก kernel thread โปรแกรมขุดเหรียญที่ถูกติดตั้งผ่าน Redis และ Docker socket ที่เปิดเผย มักถูกรายงานภายใต้ชื่ออย่างเช่น kdevtmpfsi และ kinsing
• การเชื่อมต่อขาออกไปยังที่อยู่ซึ่งไม่มีบริการใดของคุณใช้งาน

การปลอมตัวเป็น kernel thread มีวิธีทดสอบอย่างรวดเร็ว kernel thread จริงจะแสดงผลภายในวงเล็บเหลี่ยมและไม่มีไฟล์ปฏิบัติการเบื้องหลัง ดังนั้น sudo ls -l /proc/<pid>/exe จะล้มเหลวสำหรับกระบวนการเหล่านี้พร้อมข้อความ No such file or directory หากกระบวนการที่แสดงชื่อเป็น [kworker/0:2] มีลิงก์ exe ชี้ไปยังตำแหน่งภายใต้ /tmp แสดงว่านั่นเป็นโปรแกรมของผู้ใช้ทั่วไปที่ใช้ชื่อเลียนแบบ kernel

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

ตัดการเชื่อมต่อเครือข่ายที่ระดับผู้ให้บริการ ไม่ใช่จากภายในเซิร์ฟเวอร์

การแยกเซิร์ฟเวอร์ออกจากเครือข่ายเป็นขั้นตอนแรกที่สำคัญที่สุด เพราะทุกขั้นตอนหลังจากนี้จะสูญเปล่าหากยังมีผู้อื่นเข้าถึง shell ของคุณได้ การอ่าน log, การเปลี่ยน key และการกู้คืนข้อมูลจะไม่มีประโยชน์เลยหากผู้โจมตียังคงเฝ้าดูอยู่

ให้ดำเนินการผ่านแผงควบคุมของผู้ให้บริการ (provider control panel) โดยใช้ firewall เครือข่ายที่ทำงานอยู่นอกระบบปฏิบัติการของคุณ ให้ปฏิเสธการเชื่อมต่อทั้งขาเข้าและขาออก และใช้ web console เป็นช่องทางเดียวในการเข้าถึง กฎที่กำหนดไว้ในระดับนี้จะยังคงมีผลไม่ว่าจะเกิดอะไรขึ้นกับดิสก์ก็ตาม

มีเหตุผลสองประการที่ไม่ควรทำสิ่งนี้จากภายในเซิร์ฟเวอร์ ประการแรก firewall ที่คุณกำหนดค่าภายใน kernel ที่ถูกบุกรุกจะถูกบังคับใช้โดย kernel นั้นเอง ซึ่ง root สามารถล้างค่า nftables ได้ง่ายพอๆ กับที่คุณเขียนมันขึ้นมา ประการที่สอง การใช้ sudo ip link set enp1s0 down ผ่าน SSH จะตัดเซสชันของคุณก่อน ซึ่งจะทำให้คุณถูกล็อกออกจากเครื่องในขณะที่กำลังตรวจสอบอยู่

ให้บล็อกทั้งขาออกและขาเข้า เพราะ reverse shell จะเชื่อมต่อออกจากเครื่องของคุณไปยังผู้โจมตี ดังนั้นการบล็อกเฉพาะขาเข้าจะทำให้การเชื่อมต่อที่สร้างไว้แล้วยังคงทำงานได้ตามปกติ หากผู้ให้บริการของคุณมีให้กำหนดเฉพาะกฎขาเข้า ตัวเลือกที่เหลือคือการถอด network interface ออกหรือปิดการทำงานของ instance นั้น

อย่าเพิ่ง reboot ให้ตรวจสอบก่อนว่า /var/log/journal มีอยู่หรือไม่ หากไดเรกทอรีดังกล่าวไม่มีอยู่ แสดงว่า journald กำลังเขียนข้อมูลลงใน /run/log/journal ซึ่งอยู่ในหน่วยความจำ ดังนั้นการ reboot จะทำให้บันทึกการบุกรุกสูญหายไป นอกจากนี้ กระบวนการที่กำลังทำงานอยู่จะหายไปเมื่อ reboot ซึ่ง command line ของกระบวนการเหล่านั้นมักเป็นหลักฐานที่ชัดเจนที่สุดที่คุณจะได้รับ

ทำ Snapshot ของดิสก์ก่อนดำเนินการใดๆ

ในบริบทนี้ Snapshot และ Backup มีหน้าที่ต่างกัน Snapshot ที่คุณทำในตอนนี้คือสำเนาของดิสก์ที่ถูกบุกรุก ซึ่งใช้เป็นหลักฐานและเป็นสิ่งเดียวที่ช่วยให้คุณย้อนกลับได้หากเผลอเขียนทับข้อมูลบางอย่างไป ส่วน Backup ชุดเก่าของคุณคือช่องทางสำหรับการกู้คืนระบบ หากแผงควบคุมของผู้ให้บริการใช้คำสองคำนี้อย่างไม่เคร่งครัด โปรดอ่าน ความแตกต่างระหว่าง VPS snapshots กับการทำ backup จริง ก่อน เนื่องจากกฎการเก็บรักษาและพฤติกรรมการกู้คืนนั้นไม่เหมือนกัน

ให้ทำ Snapshot จากแผงควบคุมของผู้ให้บริการก่อนที่คุณจะล็อกอินเข้าสู่ระบบอีกครั้ง Snapshot แบบสด (live snapshot) จะมีความสอดคล้องในระดับ crash consistent คือบันทึกสถานะดิสก์ ณ ขณะนั้นไว้เหมือนกับการดึงปลั๊กไฟออก ซึ่งเพียงพอสำหรับการใช้เป็นหลักฐาน ให้ตั้งชื่อ Snapshot เพื่อไม่ให้ใครเผลอกู้คืนโดยไม่ได้ตั้งใจ การตั้งชื่อที่ตรงไปตรงมาอย่าง COMPROMISED-do-not-restore-2026-08-12 ถือเป็นระดับความชัดเจนที่เหมาะสม ให้เก็บ Snapshot นี้ไว้จนกว่าการตรวจสอบจะเสร็จสิ้นและตั๋วแจ้งปัญหาการละเมิด (abuse ticket) กับผู้ให้บริการของคุณจะถูกปิดลง

วิธีเข้าถึงระบบเมื่อ SSH ใช้งานไม่ได้

มีสองแนวทางซึ่งทำได้ผ่านแผงควบคุมของผู้ให้บริการ (provider panel) เว็บคอนโซล (VNC หรือ serial) จะเชื่อมต่อกับเครื่องเสมือนกับว่าคุณได้เสียบคีย์บอร์ดเข้ากับเครื่องโดยตรง วิธีนี้ใช้งานได้แม้ในกรณีที่ sshd หยุดทำงาน, ไฟร์วอลล์ตั้งค่าผิดพลาด หรือผู้บุกรุกเปลี่ยนพอร์ต SSH การเข้าถึงนี้ต้องใช้รหัสผ่านท้องถิ่น ดังนั้นหากเซิร์ฟเวอร์ของคุณอนุญาตเฉพาะการใช้คีย์ (key-only) คุณอาจต้องรีเซ็ตรหัสผ่าน root ก่อนจึงจะใช้งานคอนโซลได้

โหมดกู้คืน (Rescue mode) เป็นทางเลือกที่ดีกว่า ระบบจะบูตเข้าสู่ระบบปฏิบัติการขนาดเล็ก (live system) โดยที่ดิสก์ของคุณจะถูกเชื่อมต่อไว้แต่ไม่ได้ถูกรันขึ้นมา ทำให้คำสั่งที่คุณใช้มีความน่าเชื่อถือ เนื่องจาก kernel และไฟล์ไบนารีที่อาจถูกบุกรุกจะไม่ถูกเรียกใช้งาน ให้ทำการ mount ดิสก์ในโหมดอ่านอย่างเดียว (read-only)

lsblk -f
sudo mkdir -p /mnt/victim
sudo mount -o ro /dev/vda1 /mnt/victim

หาก lsblk แสดงผลเป็น LVM (logical volume manager) แทนที่จะเป็นพาร์ทิชันปกติ ให้เปิดใช้งานด้วย sudo vgchange -ay ก่อน จากนั้นจึง mount อุปกรณ์ที่ปรากฏภายใต้ /dev/mapper/

ห้ามใช้ chroot เข้าไปในดิสก์ที่ mount ไว้เพื่อตรวจสอบไฟล์ การทำ chroot จะเป็นการรันไฟล์ไบนารีของผู้บุกรุกด้วยสิทธิ์ของคุณ ซึ่งจะทำให้เหตุผลทั้งหมดที่คุณเลือกบูตเข้าโหมดกู้คืนนั้นสูญเปล่า

รวบรวมหลักฐานที่ยังเชื่อถือได้

ให้รันคำสั่งเหล่านี้จากโหมด rescue โดย mount ดิสก์แบบอ่านอย่างเดียว (read-only) ไว้ที่ /mnt/victim เริ่มต้นด้วยข้อมูลการล็อกอิน เนื่องจากข้อมูลเหล่านี้ระบุช่วงเวลาที่เกิดการบุกรุก และการตรวจสอบส่วนอื่นจะง่ายขึ้นเมื่อคุณทราบกรอบเวลาที่ชัดเจนแล้ว

sudo grep -aE 'Accepted (password|publickey)' /mnt/victim/var/log/auth.log
sudo last -f /mnt/victim/var/log/wtmp
sudo lastb -f /mnt/victim/var/log/btmp
sudo journalctl -D /mnt/victim/var/log/journal -u ssh --since "2026-07-01"

การที่ /var/log/auth.log หายไปไม่ได้หมายความว่าน่าสงสัยเสมอไป อิมเมจ Ubuntu รุ่นปัจจุบันบางตัวไม่มี rsyslog ติดตั้งมาให้ ทำให้ sshd บันทึก log ลงใน journal เท่านั้น ซึ่งเป็นสิ่งที่บรรทัด journalctl -D อ่านค่า สิ่งที่ควรสังเกตคือช่องว่างใน log ที่ควรจะต่อเนื่องกัน หรือไฟล์ log ที่ถูกตัดให้เหลือขนาด 0 ไบต์ การลบ log ทิ้งเป็นเรื่องที่พบได้บ่อยและมักทำอย่างไม่ระมัดระวัง

ลำดับถัดไปคือบัญชีผู้ใช้และคีย์ต่างๆ

sudo find /mnt/victim/root /mnt/victim/home -name 'authorized_keys*' -exec ls -l {} +
sudo awk -F: '$3 == 0 {print $1}' /mnt/victim/etc/passwd
sudo lsattr /mnt/victim/root/.ssh/authorized_keys

บรรทัด awk จะแสดงบัญชีผู้ใช้ทั้งหมดที่มี user ID เป็น 0 หากผลลัพธ์แสดงค่าอื่นที่ไม่ใช่ root นั่นหมายถึงมีบัญชี root บัญชีที่สอง รูปแบบ find ถูกกำหนดมาเพื่อจับคู่กับ authorized_keys2 ด้วย เนื่องจาก OpenSSH อ่านไฟล์ทั้งสองชื่อเป็นค่าเริ่มต้น และไฟล์ที่สองมักถูกมองข้ามได้ง่าย หาก lsattr แสดงค่า i ในรายการ attribute แสดงว่าไฟล์นั้นถูกตั้งค่าเป็น immutable ผู้บุกรุกมักตั้งค่า flag นี้เพื่อให้ความพยายามในการลบไฟล์คีย์ของพวกเขาพบกับข้อผิดพลาด Operation not permitted และทำให้ผู้ดูแลระบบที่เหนื่อยล้าเข้าใจผิดว่าการแก้ไขไฟล์สำเร็จแล้ว

การคงอยู่ของมัลแวร์ (persistence) มักซ่อนตัวอยู่ในจุดเล็กๆ ไม่กี่แห่ง ดังนั้นควรตรวจสอบให้ครบทุกจุด

sudo ls -lt /mnt/victim/etc/systemd/system
sudo ls -l /mnt/victim/etc/cron.d /mnt/victim/var/spool/cron/crontabs
sudo cat /mnt/victim/etc/ld.so.preload
sudo grep -rnE 'curl|wget|base64|/dev/tcp' /mnt/victim/etc/update-motd.d /mnt/victim/etc/rc.local /mnt/victim/root/.bashrc /mnt/victim/root/.profile

/etc/ld.so.preload ไม่มีอยู่บนระบบ Ubuntu หรือ Debian ปกติ ดังนั้น No such file or directory จึงเป็นผลลัพธ์ที่ปกติ และเนื้อหาใดๆ ที่พบในนั้นควรได้รับความสนใจจากคุณ ไฟล์ล็อกอินที่ส่งผลลัพธ์ของ base64 -d เข้าสู่ shell ก็เป็นกรณีเดียวกัน การตั้งค่าที่ถูกต้องตามกฎหมายไม่จำเป็นต้องซ่อนข้อความของตัวเอง

ให้สร้างไทม์ไลน์จากเวลาที่มีการเปลี่ยนแปลง (change time) แทนเวลาที่มีการแก้ไข (modification time)

sudo find /mnt/victim -xdev -newerct '2026-08-01' -type f -printf '%TF %TT %p\n' | sort

touch สามารถตั้งค่าเวลาแก้ไข (mtime) เป็นค่าใดก็ได้ที่ผู้บุกรุกต้องการ ดังนั้น mtime จึงเชื่อถือไม่ได้ เวลาที่มีการเปลี่ยนแปลง (ctime) จะอัปเดตเมื่อมีการเปลี่ยนแปลงใดๆ กับ inode และ touch ไม่สามารถย้อนเวลา ctime กลับไปได้ ดังนั้น -newerct จึงให้รายการที่สะท้อนความเป็นจริงมากกว่าว่ามีไฟล์ใดถูกเขียนลงไปเมื่อเร็วๆ นี้ อย่างไรก็ตาม นี่ไม่ใช่หลักฐานที่สมบูรณ์ เพราะ root สามารถปรับนาฬิกาของระบบหรือเขียนข้อมูลลงบน block device โดยตรงได้

ความสมบูรณ์ของแพ็กเกจสามารถตรวจสอบได้ด้วยหนึ่งคำสั่งและหนึ่งข้อควรระวัง บนระบบที่กำลังทำงานอยู่ sudo dpkg --verify จะแสดงบรรทัดสำหรับไฟล์แพ็กเกจทุกไฟล์ที่ checksum ไม่ตรงกัน โดยมีเครื่องหมาย 5 ในคอลัมน์ checksum และ sudo debsums -ac จะทำหน้าที่เดียวกันรวมถึงไฟล์ config เมื่อติดตั้งแพ็กเกจ debsums แล้ว ให้ตีความผลลัพธ์ในทิศทางเดียวเท่านั้น คือถ้า /usr/sbin/sshd เปลี่ยนแปลงไป นั่นคือหลักฐานจริง แต่ถ้าผลลัพธ์ระบุว่าสะอาดก็ไม่ได้พิสูจน์อะไร เพราะบัญชี root ที่สามารถแทนที่ไฟล์ binary ได้ ก็สามารถเขียนทับรายการ checksum ภายใต้ /var/lib/dpkg/info/ ได้เช่นกัน เครื่องมือสแกน rootkit เช่น rkhunter และ chkrootkit ก็ใช้กฎเดียวกัน คือการพบสิ่งผิดปกติถือเป็นข้อมูล แต่การสแกนแล้วไม่พบอะไรไม่ได้หมายความว่าระบบปลอดภัย

ให้คัดลอกข้อมูลที่คุณรวบรวมได้ออกจากเครื่องก่อนที่จะดำเนินการใดๆ ที่อาจทำลายหลักฐาน

sudo tar --ignore-failed-read -C /mnt/victim -czf /root/evidence-2026-08-12.tgz \
  var/log etc root/.ssh root/.bash_history home
sha256sum /root/evidence-2026-08-12.tgz

จดค่า hash นั้นไว้ภายนอกเซิร์ฟเวอร์ หากเรื่องนี้กลายเป็นการเรียกร้องค่าประกันหรือรายงานต่อเจ้าหน้าที่ตำรวจ การสามารถพิสูจน์ได้ว่าไฟล์ที่เก็บถาวร (archive) ไม่ได้ถูกเปลี่ยนแปลงตั้งแต่รวบรวมมา คือความแตกต่างระหว่างการมีหลักฐานกับการมีเพียงโฟลเดอร์ไฟล์ทั่วไป การลบไฟล์โดยไม่ตั้งใจระหว่างการสืบสวนเป็นเรื่องปกติ และการมี snapshot ร่วมกับไฟล์ที่เก็บถาวรนี้จะช่วยให้คุณกู้คืนสถานการณ์ได้ การแก้ไขข้อผิดพลาดจากการใช้ rm หลังจากนั้นทำได้ยากกว่าที่หลายคนคาดคิด ดังที่อธิบายไว้ใน การกู้คืนไฟล์ที่ถูกลบด้วย rm -rf

ค้นหาช่องทางที่ผู้บุกเข้ามาใช้

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

การล็อกอิน SSH ด้วยรหัสผ่าน บรรทัด Accepted password for root จากที่อยู่ IP ที่คุณไม่รู้จักคือคำตอบในตัวมันเอง ให้ตรวจสอบ PasswordAuthentication ใน /etc/ssh/sshd_config และในทุกไฟล์ภายใต้ /etc/ssh/sshd_config.d/ โดย sshd จะใช้ค่าแรกที่พบสำหรับคีย์เวิร์ดนั้นๆ และบรรทัด Include จะอยู่ด้านบนสุดของไฟล์หลักใน Ubuntu ดังนั้นไฟล์คอนฟิกที่ถูกวางเพิ่มเข้ามาจะมีความสำคัญเหนือกว่าการตั้งค่าที่คุณแก้ไขไว้ในส่วนล่างของไฟล์

บริการที่เปิดเผยสู่สาธารณะโดยไม่มีการยืนยันตัวตน เช่น Redis บนพอร์ต 6379, Docker API บนพอร์ต 2375 หรือฐานข้อมูลที่ผูกไว้กับ 0.0.0.0 แทนที่จะเป็น 127.0.0.1 Docker มักเป็นสิ่งที่ทำให้ประหลาดใจได้บ่อยที่สุด การเผยแพร่พอร์ตของคอนเทนเนอร์จะแทรกกฎ DNAT (destination network address translation) ซึ่งจะถูกประเมินก่อน chain ของ ufw ดังนั้น ufw status อาจรายงานว่าพอร์ตถูกบล็อกแล้ว แต่คอนเทนเนอร์ที่อยู่เบื้องหลังกลับตอบสนองต่ออินเทอร์เน็ตทั้งหมด ให้ทำความเข้าใจเรื่องนี้ก่อนเริ่มสร้างเซิร์ฟเวอร์ใหม่: เหตุใดพอร์ตที่เผยแพร่โดย Docker จึงข้ามการทำงานของ ufw จะครอบคลุมถึงลำดับของกฎและการแก้ไข

เว็บแอปพลิเคชันที่ไม่ได้แพตช์ ให้ค้นหา log การเข้าถึงของเว็บเซิร์ฟเวอร์ในช่วงเวลาที่น่าสงสัยที่สุดของคุณ เพื่อหาการทำ POST ไปยัง path สำหรับอัปโหลดหรือ path ของผู้ดูแลระบบ จากนั้นให้ตรวจสอบไฟล์ภายใต้ web root ที่มีเวลาการแก้ไขตรงกัน ไฟล์ PHP ที่แปลกปลอมในไดเรกทอรีอัปโหลดคือผลลัพธ์ที่พบได้บ่อยที่สุด

ข้อมูลประจำตัวที่รั่วไหล เช่น คีย์ที่ถูก commit ลงใน repository, โทเค็นที่ถูกวางในแชท หรือไฟล์ .env ที่ถูกเสิร์ฟเป็นไฟล์สแตติกโดยเว็บเซิร์ฟเวอร์ที่ตั้งค่าผิดพลาด ระบบอัตโนมัติทำให้เกิดข้อผิดพลาดนี้ได้ง่าย ซึ่งเป็นเหตุผลว่าทำไมจึงควร เก็บความลับให้ห่างจาก AI agents และไฟล์คอนฟิกของพวกมัน

หากคุณไม่สามารถระบุช่องทางได้หลังจากตรวจสอบทั้งหมดนี้แล้ว ให้สันนิษฐานว่าข้อมูลประจำตัวรั่วไหล และถือว่าความลับทุกอย่างที่เครื่องนั้นเคยเก็บไว้เป็นข้อมูลสาธารณะทั้งหมด

หมุนเวียนข้อมูลรับรองทั้งหมดที่เครื่องอาจเข้าถึงได้

ให้ทำการหมุนเวียนข้อมูลรับรองหลังจากตัดการเชื่อมต่อเครือข่ายแล้วเท่านั้น ห้ามทำก่อนหน้านั้นเด็ดขาด การหมุนเวียนข้อมูลในขณะที่ผู้โจมตียังคงมีการเชื่อมต่ออยู่จะเป็นการส่งมอบความลับชุดใหม่ให้แก่ผู้โจมตีโดยตรง

• SSH private key ทุกชุดที่จัดเก็บไว้บนเซิร์ฟเวอร์ รวมถึงบัญชีอื่น ๆ ทั้งหมดที่เชื่อถือ public key ชุดเดียวกัน
• กุญแจใดก็ตามที่คุณส่งผ่านเข้าไปในเครื่องด้วย ssh -A การทำ Agent forwarding จะทิ้ง socket ไว้ที่ /tmp ซึ่งผู้ใช้ระดับ root บนเครื่องนั้นสามารถใช้เพื่อยืนยันตัวตนในฐานะคุณได้ทุกที่ที่กุญแจของคุณได้รับการยอมรับ ตราบเท่าที่ session ของคุณยังคงเปิดอยู่
• API token ในไฟล์ .env, ในบรรทัด Environment= ของ systemd, ในการตั้งค่า CI และในข้อมูลรับรองของผู้ให้บริการ
• รหัสผ่านฐานข้อมูล และบัญชีแอปพลิเคชันที่ใช้งานรหัสผ่านเหล่านั้น
• TLS (transport layer security) private key ที่เซิร์ฟเวอร์ถือครองอยู่ ให้ทำการออกใบรับรองใหม่และเพิกถอนใบรับรองเดิม
• รหัสผ่านบัญชีโฮสติ้งของคุณ พร้อมเปิดใช้งานการยืนยันตัวตนแบบสองชั้น (two-factor authentication) เนื่องจากแผงควบคุมดังกล่าวสามารถสร้างใหม่ ทำ snapshot และเข้าถึง console ของเซิร์ฟเวอร์ทุกเครื่องที่คุณเป็นเจ้าของได้ จึงถือเป็นขอบเขตความปลอดภัยที่แท้จริง
• รหัสผ่านใดก็ตามที่ถูกพิมพ์ลงใน shell session บนโฮสต์นั้นในขณะที่ถูกบุกรุก เนื่องจาก root สามารถบันทึก terminal session ในขณะที่กำลังใช้งานได้

หากรหัสผ่านบนเครื่องนั้นถูกนำไปใช้ที่อื่นด้วย ให้เปลี่ยนรหัสผ่านในที่เหล่านั้นทั้งหมด การใช้รหัสผ่านซ้ำเป็นสาเหตุที่ทำให้ VPS ที่ถูกบุกรุกเพียงเครื่องเดียวกลายเป็นบัญชีอีเมลที่ถูกบุกรุกได้

รายการตรวจสอบสำหรับการสร้างระบบใหม่

1. สร้างเซิร์ฟเวอร์ใหม่จากอิมเมจมาตรฐานของ distribution ห้ามใช้ snapshot จากเครื่องที่ถูกบุกรุก และห้ามกู้คืนจากไฟล์ระบบ root ทั้งหมด
2. ติดตั้งแพ็กเกจจาก repository ของ distribution เท่านั้น ห้ามคัดลอกไฟล์ binary จากดิสก์เก่ามาใช้
3. กู้คืนเฉพาะข้อมูลจากข้อมูลสำรองที่มีวันที่ก่อนหน้าหลักฐานชิ้นแรกสุดในไทม์ไลน์ของคุณเท่านั้น เช่น ข้อมูลดัมพ์ของฐานข้อมูล, ไฟล์ที่อัปโหลด และสถานะของแอปพลิเคชัน โดยให้ทิ้ง /etc, /usr และไฟล์ unit เก่าไว้ที่เดิม
4. ป้อนข้อมูลลับที่เปลี่ยนใหม่ด้วยตนเอง ห้ามคัดลอกไฟล์ .env เก่ามาใช้งาน
5. ตรวจสอบเนื้อหาเว็บที่กู้คืนมาเพื่อหาไฟล์ที่ถูกเพิ่มเข้ามาในช่วงเวลาที่เกิดการบุกรุก ก่อนที่จะเปิดใช้งานเนื้อหาเหล่านั้นอีกครั้ง
6. ปรับแต่งความปลอดภัยก่อนเปิดใช้งานจริง: ใช้เฉพาะ SSH key, ใช้บัญชีผู้ใช้ทั่วไปที่ไม่ใช่ root, ตั้งค่า firewall แบบ default-deny สำหรับขาเข้า และห้ามเปิดเผยบริการใดๆ ออกสู่สาธารณะเกินความจำเป็น ให้ดำเนินการตาม สิบนาทีแรกบน VPS ใหม่, จากนั้น ปรับแต่ง SSH ให้ปลอดภัยอย่างเหมาะสม, และเพิ่ม fail2ban บน Ubuntu 24.04 เพื่อลดการพยายามล็อกอินที่ไม่พึงประสงค์ กำหนดให้แต่ละบริการ มีบัญชีผู้ใช้ที่มีสิทธิ์น้อยที่สุดของตนเอง เพื่อป้องกันไม่ให้การบุกรุกครั้งต่อไปกลายเป็นการเข้าถึงระดับ root
7. ปิดเซิร์ฟเวอร์เก่าและเก็บ snapshot ไว้จนกว่าการสอบสวนและตั๋วแจ้งเหตุการละเมิดทั้งหมดจะถูกปิดลง
8. แก้ไขระบบสำรองข้อมูล หากขั้นตอนที่ 3 เป็นเพียงการคาดเดา บทเรียนที่แท้จริงคือประวัติการสำรองข้อมูลของคุณสั้นเกินกว่าจะย้อนกลับไปก่อนช่วงเวลาที่ถูกบุกรุก การสำรองข้อมูลแบบมีเวอร์ชันและเก็บไว้นอกเซิร์ฟเวอร์พร้อมระยะเวลาการเก็บรักษาที่ยาวนานจะช่วยให้คุณมีจุดกู้คืนที่สะอาดในครั้งถัดไป: การสำรองข้อมูลด้วย restic บน VPS ช่วยให้คุณทำได้ทั้งสองอย่าง

หากคุณไม่สามารถระบุวันที่เกิดการบุกรุกได้ คุณจะไม่สามารถเลือกข้อมูลสำรองที่ปลอดภัยได้ ในกรณีนี้ให้กู้คืนเฉพาะข้อมูลที่คุณสามารถตรวจสอบด้วยตาเปล่าได้เท่านั้น เช่น ไฟล์ SQL dump ที่คุณอ่านได้ หรือไดเรกทอรีของรูปภาพที่คุณสามารถแสดงรายการไฟล์ได้ ให้ถือว่าทุกสิ่งที่สามารถรันเป็นโปรแกรมได้นั้นมีความเสี่ยง และให้ติดตั้งใหม่จาก repository เท่านั้น

ความหมายของประกาศการละเมิดจากผู้ให้บริการโฮสต์ของคุณ

คนส่วนใหญ่ทราบว่าเซิร์ฟเวอร์ของตนถูกบุกรุกจากผู้ให้บริการ ไม่ใช่จากการตรวจสอบด้วยตนเอง ผู้ให้บริการจะตรวจพบทราฟฟิกขาออก เช่น การทำ SSH brute force ไปยังเครือข่ายอื่น, การส่งสแปมผ่านพอร์ต 25 หรือการมีส่วนร่วมในการทำ reflection attack โดยปกติแล้วตั๋วแจ้งเตือนจะระบุเวลา, พอร์ต และตัวอย่างของทราฟฟิก พร้อมกับกำหนดเวลาแก้ไขที่นับเป็นชั่วโมง

คุณควรตอบกลับตั๋วแจ้งเตือนนั้น แม้ว่าคำตอบของคุณจะเป็นเพียงการแจ้งว่าเซิร์ฟเวอร์ถูกแยกออกจากเครือข่ายและกำลังดำเนินการสร้างใหม่ก็ตาม ผู้ให้บริการจะทำการ null-route หรือระงับการใช้งานเซิร์ฟเวอร์หากไม่มีการตอบกลับตั๋ว ซึ่งจะทำให้เหตุการณ์ความปลอดภัยของคุณกลายเป็นปัญหาการหยุดชะงักของบริการ จากนั้นให้ขอข้อมูล log ดิบที่อยู่เบื้องหลังรายงานดังกล่าว เนื่องจากข้อมูลเวลาเหล่านั้นถูกบันทึกไว้นอกเครื่องของคุณ จึงเป็นส่วนหนึ่งของลำดับเหตุการณ์ที่ผู้บุกรุกไม่สามารถแก้ไขได้ และมักจะระบุช่วงเวลาการบุกรุกได้แม่นยำกว่าข้อมูลใดๆ บนดิสก์

เซิร์ฟเวอร์ของลูกค้าที่ถูกบุกรุกเป็นงานปกติของผู้ให้บริการ และการจัดการเหตุการณ์อย่างถูกต้องจะไม่ส่งผลเสียต่อตัวคุณ คำถามในวงกว้างเกี่ยวกับ ความปลอดภัยของ VPS hosting ส่วนใหญ่ขึ้นอยู่กับการตั้งค่าของลูกค้า ซึ่งเป็นส่วนที่คุณกำลังจะได้เริ่มต้นทำใหม่ทั้งหมดตั้งแต่ต้น

เมื่อใดที่ควรเรียกผู้เชี่ยวชาญ

• เซิร์ฟเวอร์เก็บข้อมูลส่วนบุคคลของผู้อื่น ภายใต้กฎหมาย GDPR (General Data Protection Regulation) การรั่วไหลของข้อมูลส่วนบุคคลจะต้องรายงานต่อหน่วยงานกำกับดูแลโดยไม่ชักช้า และต้องรายงานภายใน 72 ชั่วโมงนับตั้งแต่ทราบเหตุหากสามารถทำได้ การตัดสินว่าระยะเวลาดังกล่าวเริ่มต้นขึ้นแล้วหรือไม่เป็นงานด้านกฎหมาย ไม่ใช่งานของผู้ดูแลระบบ
• ข้อมูลบัตรชำระเงินอยู่ในขอบเขตที่ได้รับผลกระทบ ผู้ให้บริการบัตรกำหนดให้ต้องมีผู้ตรวจสอบทางนิติวิทยาศาสตร์ที่ได้รับการรับรอง และการที่คุณเข้าไปตรวจสอบด้วยตนเองอาจทำให้หลักฐานเสียหายได้
• มีการเรียกค่าไถ่ หรือข้อมูลของคุณถูกเข้ารหัส
• เครื่องดังกล่าวสามารถเข้าถึงเครื่องอื่นได้ เช่น เครือข่ายภายใน, hypervisor หรือ CI runner ที่เก็บข้อมูลรับรองสำหรับการใช้งานจริง โฮสต์ที่ถูกบุกรุกหนึ่งเครื่องในกลุ่มถือเป็นเหตุการณ์ที่กระทบทั้งกลุ่มจนกว่าจะพิสูจน์ได้ว่าเป็นอย่างอื่น
• คุณจำเป็นต้องใช้หลักฐานเพื่อการเคลมประกันหรือการดำเนินคดีตามกฎหมาย ให้หยุดที่การทำ snapshot ทำสำเนาภาพดิสก์ (disk image) ทั้งหมด และบันทึกว่าใครเป็นผู้จัดการและจัดการเมื่อใด

สำหรับ VPS เครื่องเดียวที่รันบริการของคุณเองและไม่มีข้อมูลของผู้อื่นอยู่บนนั้น ขั้นตอนข้างต้นคือทั้งหมดที่ต้องทำ ให้ทำการแยกเครื่องออกจากเครือข่ายที่ผู้ให้บริการ ทำ snapshot เพื่อเก็บหลักฐาน รวบรวมข้อมูลที่ยังเชื่อถือได้ เปลี่ยนข้อมูลรับรองทั้งหมด และสร้างระบบขึ้นใหม่ให้สะอาด

FAQ

ฉันสามารถทำความสะอาด VPS ที่ถูกแฮ็กแทนการติดตั้งใหม่ได้หรือไม่?

ไม่สามารถทำได้อย่างมั่นใจ เพราะคุณกำลังให้ระบบที่ถูกบุกรุกเป็นผู้รายงานสถานะของตัวเอง ps ที่ถูกแทนที่สามารถซ่อนกระบวนการทำงานได้ บรรทัดใน /etc/ld.so.preload สามารถแทรกโค้ดลงในเครื่องมือแบบ dynamically linked ทุกตัวที่คุณเรียกใช้ และ kernel module สามารถซ่อนไฟล์จากทุกโปรแกรมได้ในคราวเดียว คุณสามารถพบสิ่งที่ผิดปกติได้ ดังนั้นหากพบหลักฐานถือว่ามีนัยสำคัญ แต่คุณไม่สามารถพิสูจน์ได้ว่าไม่มีสิ่งผิดปกติ ดังนั้นผลลัพธ์ที่ว่า "สะอาด" จึงเชื่อถือไม่ได้ การทำความสะอาดจะสมเหตุสมผลก็ต่อเมื่อเซิร์ฟเวอร์ไม่มีข้อมูลที่คุณให้ความสำคัญ และคุณยอมรับความเสี่ยงว่ามันอาจถูกบุกรุกอีกครั้ง

ฉันควรปิดเซิร์ฟเวอร์ที่ถูกบุกรุกหรือปล่อยให้ทำงานต่อไป?

ให้ตัดการเชื่อมต่อเครือข่ายที่ระดับผู้ให้บริการก่อน จากนั้นปล่อยให้เครื่องทำงานต่อไปนานพอที่จะทำ snapshot และตรวจสอบกระบวนการที่กำลังทำงานอยู่ การปิดเครื่องจะทำลายรายการกระบวนการทำงานและลบ journal ทิ้งทั้งหมดหาก /var/log/journal ไม่มีอยู่จริง เนื่องจาก journald จะเขียนข้อมูลลงในหน่วยความจำภายใต้ /run อย่างไรก็ตาม ให้ปิดเครื่องทันทีหากเซิร์ฟเวอร์กำลังโจมตีเครือข่ายอื่นอยู่และคุณไม่มีวิธีบล็อก traffic ขาออก การหยุดความเสียหายมีความสำคัญเหนือกว่าการเก็บหลักฐาน

ฉันจะทราบได้อย่างไรว่าผู้โจมตีเข้ามาเมื่อใด?

ให้ค้นหาบรรทัด Accepted password หรือ Accepted publickey แรกสุดที่คุณไม่สามารถอธิบายได้ใน /var/log/auth.log หรือใน journal จากนั้นตรวจสอบเปรียบเทียบกับรายการเวลาที่มีการเปลี่ยนแปลงไฟล์ด้วย find / -xdev -newerct 'YYYY-MM-DD' -type f เนื่องจาก ctime ปลอมแปลงได้ยากกว่า mtime แล้วนำทั้งสองอย่างไปเปรียบเทียบกับ timestamp ใน abuse ticket จากผู้ให้บริการของคุณ ซึ่งถูกบันทึกไว้นอกเครื่องและไม่สามารถแก้ไขได้ ให้เลือก backup ที่เก่ากว่าวันที่แรกสุดจากทั้งสามแหล่งนั้น หากไม่มีข้อมูลใดตรงกัน ให้สันนิษฐานว่าการบุกรุกเกิดขึ้นก่อนประวัติการ backup ของคุณ และให้กู้คืนเฉพาะข้อมูลที่คุณสามารถตรวจสอบได้เท่านั้น

backup ของฉันปลอดภัยที่จะกู้คืนหลังจากถูกบุกรุกหรือไม่?

โดยปกติแล้วข้อมูลจะปลอดภัยหากผ่านการตรวจสอบ แต่ไฟล์ระบบจะไม่ปลอดภัย backup ที่ทำหลังจากมีการบุกรุกจะมี backdoor ติดมาด้วย ดังนั้นการกู้คืน root filesystem ทั้งหมดจะเป็นการนำผู้โจมตีกลับเข้ามาด้วยเช่นกัน ให้ตรวจสอบที่เก็บ backup ด้วย หากข้อมูลรับรอง (credentials) สำหรับ backup ถูกเก็บไว้บนเซิร์ฟเวอร์ที่ถูกบุกรุก ประวัติการ backup อาจถูกลบหรือแก้ไขไปแล้ว ซึ่งเป็นเหตุผลที่ควรใช้ backup แบบ append-only หรือแบบดึงข้อมูล (pull-based) ให้กู้คืนเฉพาะข้อมูลแอปพลิเคชัน แล้วติดตั้งซอฟต์แวร์ใหม่จาก repository ของ distribution

ฉันต้องแจ้งใครหรือไม่หาก VPS ของฉันถูกบุกรุก?

ต้องตอบกลับ abuse notice ของผู้ให้บริการโฮสต์เสมอ นอกเหนือจากนั้นขึ้นอยู่กับว่าข้อมูลของใครอยู่บนเครื่อง ข้อมูลส่วนบุคคลของผู้อื่นอาจทำให้เกิดหน้าที่ตามกฎหมายในการรายงาน เช่น การแจ้งเตือนภายใน 72 ชั่วโมงต่อหน่วยงานกำกับดูแลตาม GDPR หากมีการเก็บข้อมูลรับรองของผู้ใช้ไว้บนเซิร์ฟเวอร์ ให้แจ้งผู้ใช้เหล่านั้นเพื่อให้พวกเขาสามารถเปลี่ยนรหัสผ่านในที่อื่นได้ หากกุญแจ (keys) บนเครื่องได้รับอนุญาตให้เข้าถึงระบบของบุคคลที่สาม เช่น code host หรือบัญชีคลาวด์ ให้แจ้งผู้ให้บริการเหล่านั้นเพื่อให้พวกเขาสามารถตรวจสอบการใช้งานในทางที่ผิดได้ เซิร์ฟเวอร์ส่วนตัวที่ไม่มีข้อมูลของผู้อื่นไม่มีภาระผูกพันใดๆ นอกเหนือจากการตอบกลับ abuse ticket