Language: th

ความปลอดภัย VPS ตั้งแต่เริ่มต้น: คีย์ SSH ไฟร์วอลล์ และ Fail2ban

ไม่ควรถือว่า VPS ใหม่ปลอดภัยทันทีหลังติดตั้ง Ubuntu ก่อนตั้งค่าการเข้าถึง เซิร์ฟเวอร์ก็มองเห็นได้จากเครื่องสแกนแล้ว: พวกมันจะลองรหัสผ่าน SSH ค้นหาแผงควบคุมที่เปิดเผย และตรวจสอบช่องโหว่ที่พบบ่อย ในคู่มือนี้เราจะครอบคลุมขั้นตอนพื้นฐานในการทำให้ VPS ปลอดภัยตั้งแต่เริ่มต้น ได้แก่ การสร้างผู้ใช้แยกต่างหาก การตั้งค่าการยืนยันตัวตนด้วยคีย์ SSH การจำกัดพอร์ตเครือข่ายด้วย UFW และการเพิ่ม Fail2ban ทุกขั้นตอนใช้ได้กับ Ubuntu 22.04 และ 24.04 เมื่อเรียกใช้คำสั่งด้วยผู้ใช้ที่มีสิทธิ์ sudo

ก่อนเริ่ม: ทำรายการพอร์ต

อย่าเปิดพอร์ต “เผื่อไว้ก่อน” เซิร์ฟเวอร์เว็บทั่วไปต้องใช้:

• 22/tcp — SSH; ควรจำกัดตาม IP หรือย้ายไปพอร์ตอื่นเป็นมาตรการเสริมเท่านั้น
• 80/tcp — HTTP; โดยปกติใช้เปลี่ยนเส้นทางไป HTTPS และตรวจสอบใบรับรอง
• 443/tcp — HTTPS

พอร์ตแอปพลิเคชัน เช่น 3000, 8080 หรือ 9000 ไม่ควรเข้าถึงได้จากอินเทอร์เน็ต หากมี Nginx หรือ Caddy อยู่ด้านหน้า ให้ผูกแอปพลิเคชันกับ 127.0.0.1 หรืออนุญาตพอร์ตเฉพาะบนเครือข่ายภายใน ก่อนอื่นตรวจสอบว่ามีสิ่งใดกำลังรับฟังอยู่บนเซิร์ฟเวอร์:

sudo ss -tulpn

หลังติดตั้ง Docker ให้ตรวจสอบกฎ iptables แยกต่างหาก: การเผยแพร่ -p 3000:3000 อาจเปิดพอร์ตนอกเหนือจากที่คาดไว้ สำหรับบริการสาธารณะ การใช้พร็อกซี HTTPS และซ่อนพอร์ตภายในปลอดภัยกว่า

ขั้นตอนที่ 1 อัปเดตระบบและสร้างผู้ดูแลระบบ

เชื่อมต่อ VPS ด้วยข้อมูลเข้าสู่ระบบที่ได้รับ แล้วติดตั้งอัปเดต:

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y ufw fail2ban unattended-upgrades

สร้างผู้ใช้ส่วนตัว แทนที่ alex ด้วยชื่อของคุณ:

sudo adduser alex
sudo usermod -aG sudo alex

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

ขั้นตอนที่ 2 สร้างคีย์ SSH และติดตั้งบนเซิร์ฟเวอร์

บนคอมพิวเตอร์ Linux, macOS หรือ Windows PowerShell ให้เรียกใช้:

ssh-keygen -t ed25519 -C "alex@my-computer"

กด Enter เพื่อบันทึกคีย์ในไฟล์เริ่มต้น แล้วตั้ง passphrase อย่าส่งคีย์ส่วนตัวในแชต ใส่ไว้ในรีโพซิทอรี หรือคัดลอกไปยัง VPS ควรถ่ายโอนเฉพาะไฟล์ที่มีนามสกุล .pub ไปยังเซิร์ฟเวอร์:

ssh-copy-id alex@SERVER_IP

หากไม่มี ssh-copy-id ให้แสดงคีย์สาธารณะด้วย Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub ใน PowerShell แล้วเพิ่มคีย์นั้นลงในเซิร์ฟเวอร์:

sudo install -d -m 700 -o alex -g alex /home/alex/.ssh
sudo nano /home/alex/.ssh/authorized_keys
sudo chown alex:alex /home/alex/.ssh/authorized_keys
sudo chmod 600 /home/alex/.ssh/authorized_keys

วางคีย์ในบรรทัดเดียว แล้วทดสอบการเข้าสู่ระบบก่อนปิดการใช้รหัสผ่าน:

ssh alex@SERVER_IP
sudo whoami

ผลลัพธ์ที่คาดหวังจากคำสั่งสุดท้ายคือ root หากไคลเอนต์ SSH ค้นหาคีย์ไม่พบ ให้ระบุคีย์โดยตรง: ssh -i ~/.ssh/id_ed25519 alex@SERVER_IP

ขั้นตอนที่ 3 ปิดการเข้าสู่ระบบของ root และการยืนยันตัวตนด้วยรหัสผ่าน

สำรองไฟล์ตั้งค่า SSH:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

ตรวจสอบว่าไฟล์มีพารามิเตอร์ต่อไปนี้:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
MaxAuthTries 3

ใน Ubuntu การตั้งค่าอาจอยู่ใน /etc/ssh/sshd_config.d/*.conf ดังนั้นให้ตรวจสอบการตั้งค่าที่มีผลจริง:

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries'

หาก sshd -t รายงานข้อผิดพลาด อย่ารีสตาร์ตบริการจนกว่าจะแก้ไวยากรณ์เสร็จ เมื่อการตรวจสอบผ่านแล้ว ให้ใช้การตั้งค่า:

sudo systemctl reload ssh

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

ขั้นตอนที่ 4 ตั้งค่า UFW โดยไม่บล็อก SSH

UFW เป็นตัวห่อหุ้มกฎเครือข่ายของ Linux ที่ใช้งานสะดวก ตั้งค่าเริ่มต้นที่ปลอดภัยก่อน แล้วจึงอนุญาต SSH และพอร์ตเว็บ:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

ยืนยันการเปิดใช้งานหลังเพิ่มกฎ SSH แล้วเท่านั้น ตรวจสอบผลลัพธ์:

sudo ufw status verbose
sudo ufw status numbered

สำหรับ IP สำนักงานถาวร คุณสามารถจำกัด SSH ให้ใช้ได้เฉพาะที่อยู่นั้น:

sudo ufw delete allow 22/tcp
sudo ufw allow from YOUR.PUBLIC.IP to any port 22 proto tcp comment 'SSH office'

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

วิธีเปิดพอร์ตแอปพลิเคชันชั่วคราว

หากต้องตรวจสอบบริการโดยตรง ให้สร้างกฎที่จำกัดแหล่งที่มา:

sudo ufw allow from YOUR.PUBLIC.IP to any port 8080 proto tcp

หลังทดสอบแล้ว ให้ลบกฎโดยใช้หมายเลขที่แสดงด้วย ufw status numbered:

sudo ufw delete RULE_NUMBER

อย่าใช้ sudo ufw allow 1:65535/tcp: กฎดังกล่าวทำให้ไฟร์วอลล์เป็นเพียงพิธีการ

ขั้นตอนที่ 5 เปิดใช้ Fail2ban สำหรับ SSH

Fail2ban วิเคราะห์ล็อกและเพิ่มกฎบล็อกชั่วคราวหลังพยายามเข้าสู่ระบบไม่สำเร็จหลายครั้ง มันไม่แทนที่คีย์ SSH หรือไฟร์วอลล์ แต่ช่วยลดเสียงรบกวนจากการโจมตีแบบ brute force อัตโนมัติ

สร้างการตั้งค่าเฉพาะเครื่อง เพื่อไม่ให้การอัปเดตแพ็กเกจเขียนทับค่าของคุณ:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

ตั้งค่าที่เหมาะสมในส่วน [DEFAULT]:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd
banaction = ufw

[sshd]
enabled = true
port = 22

เริ่มบริการและตรวจสอบ jail:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

ในเอาต์พุต sshd ให้ตรวจสอบจำนวนครั้งที่ล้มเหลวและที่อยู่ที่ถูกบล็อก อย่าเพิ่ม IP ของตนเองลงในรายการแบน สำหรับข้อยกเว้นถาวร ให้ใช้ ignoreip = 127.0.0.1/8 YOUR.PUBLIC.IP ใน [DEFAULT]

ขั้นตอนที่ 6 เปิดใช้งานการอัปเดตอัตโนมัติ

การอัปเดตอัตโนมัติมีประโยชน์สำหรับแพ็กเกจความปลอดภัย แต่ยังต้องจัดการการรีบูตเคอร์เนล:

sudo dpkg-reconfigure -plow unattended-upgrades
sudo systemctl status unattended-upgrades

สัปดาห์ละครั้ง ให้ตรวจสอบว่าจำเป็นต้องรีบูตหรือไม่:

test -f /var/run/reboot-required && echo 'Требуется перезапуск'

ก่อนรีบูตด้วยตนเอง ตรวจสอบให้แน่ใจว่ามีคีย์ที่ใช้งานได้และเข้าถึงคอนโซล VPS ได้ หลังรีบูต ให้ตรวจสอบบริการแอปพลิเคชัน, Nginx, UFW และ Fail2ban

ขั้นตอนที่ 7 ตรวจสอบผลลัพธ์จากภายนอก

ตรวจสอบการป้องกันจากคอมพิวเตอร์อีกเครื่อง ไม่ใช่เพียงอ่านการตั้งค่า:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no alex@SERVER_IP

คำสั่งควรจบลงด้วยการปฏิเสธ ทดสอบการเข้าสู่ระบบด้วยคีย์ที่ใช้งานได้แยกต่างหาก:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 alex@SERVER_IP

บน VPS ให้ตรวจสอบที่อยู่ที่กำลังรับฟังและกฎ:

sudo ss -lntup
sudo ufw status numbered
sudo fail2ban-client status sshd

พอร์ตแอปพลิเคชันควรรับฟังบน 127.0.0.1 หากไม่ได้ตั้งใจให้เข้าถึงโดยตรง จากโฮสต์ภายนอก คุณสามารถใช้ nmap SERVER_IP ได้ แต่ให้สแกนเฉพาะเซิร์ฟเวอร์ของคุณเอง: การตรวจสอบโครงสร้างพื้นฐานของผู้อื่นโดยไม่ได้รับอนุญาตอาจขัดต่อกฎหมายและกฎของผู้ให้บริการ

การสำรองข้อมูลและการกู้คืน

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

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

วิธีเลือก VPS สำหรับโครงการที่ปลอดภัย

ความปลอดภัยเริ่มจากการควบคุมโครงสร้างพื้นฐาน บน VPS คุณเลือกเองได้ทั้งระบบปฏิบัติการ กฎไฟร์วอลล์ วิธีเข้าถึง การสำรองข้อมูล และตำแหน่งวางบริการ สำหรับเว็บไซต์หรือ API ขนาดเล็ก เครือข่ายที่เสถียร พื้นที่ SSD และคอนโซลกู้คืนสำคัญกว่าจำนวนคอร์เสมือนที่มากเกินจำเป็น

เมื่อเปิดตัวโครงการบน VPS ที่ tropic.host ให้กำหนดจุดทางเข้าสาธารณะไว้ล่วงหน้า: ในกรณีส่วนใหญ่ SSH, HTTP และ HTTPS ก็เพียงพอ เก็บฐานข้อมูลและแผงควบคุมไว้ในเครือข่ายภายใน เมื่อโครงการเติบโต การแยก VPS สำหรับแอปพลิเคชัน ฐานข้อมูล และการมอนิเตอร์จะช่วยแยกขอบเขตความเสียหาย

ข้อผิดพลาดที่พบบ่อย

• ปิดรหัสผ่านก่อนทดสอบการเข้าสู่ระบบด้วยคีย์ เปิดเซสชันปัจจุบันไว้และทดสอบการเข้าสู่ระบบใหม่แยกต่างหาก
• ปล่อย 22/tcp เปิดให้คนทั้งโลก เมื่อสามารถอนุญาตเฉพาะที่อยู่ที่เชื่อถือได้
• เผยแพร่พอร์ต Docker โดยตรง ตรวจสอบกฎ Docker และ UFW ก่อน
• ติดตั้ง Fail2ban แล้วไม่ตรวจสอบล็อกอีกเลย ตรวจสอบ journalctl -u ssh และสถานะ jail หลังการเปลี่ยนแปลง

บทสรุป

การป้องกัน VPS ขั้นพื้นฐานใช้เวลาไม่มาก หากทำตามลำดับที่ถูกต้อง: สร้างผู้ใช้แยก ติดตั้งคีย์ SSH ตรวจสอบการเข้าถึง ปิดการเข้าสู่ระบบของ root และรหัสผ่าน เปิด UFW ตั้งค่า Fail2ban และเปิดใช้การอัปเดตอัตโนมัติ จากนั้นเพิ่มการสำรองข้อมูล ล็อก และการมอนิเตอร์จากภายนอก

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

FAQ

จำเป็นต้องเปลี่ยนพอร์ต SSH เริ่มต้นหรือไม่?

ไม่จำเป็น การย้ายพอร์ตช่วยลดเสียงรบกวนอัตโนมัติ แต่ไม่แทนที่คีย์ การปิดรหัสผ่าน UFW หรือ Fail2ban หากเปลี่ยนพอร์ต ให้ปรับกฎไฟร์วอลล์และพารามิเตอร์ port ใน jail ของ Fail2ban

ควรทำอย่างไรหากเข้าใช้งานไม่ได้หลังตั้งค่า UFW?

ใช้คอนโซลเว็บหรือคอนโซลกู้คืนของผู้ให้บริการ แล้วตรวจสอบกฎ SSH และการตั้งค่า sshd อย่าปิดเซสชันเดิมที่ยังใช้งานได้จนกว่าจะยืนยันการเข้าสู่ระบบใหม่

Fail2ban เพียงพอสำหรับปกป้อง SSH หรือไม่?

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

อนุญาต SSH จาก IP เดียวได้หรือไม่?

ได้ หากที่อยู่นั้นเป็นแบบถาวร: เพิ่มกฎ UFW allow from สำหรับ IP นั้น เตรียมการเข้าถึงคอนโซลของผู้ให้บริการหรือทางสำรองอื่นไว้ล่วงหน้า เพราะการเชื่อมต่อจะถูกบล็อกเมื่อ IP เปลี่ยน

ควรตรวจสอบความปลอดภัย VPS บ่อยแค่ไหน?

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