ทำให้ VPS ปลอดภัย: ตั้งค่า Firewall, SSH Key และสิ่งที่ต้องทำหลัง Deploy

ทำไม Security ของ VPS จึงสำคัญมาก?

VPS ของคุณเชื่อมต่ออินเทอร์เน็ตโดยตรง มี IP Public และเปิด Port ต่าง ๆ ไว้ บอท scan หา VPS ที่ไม่ได้ป้องกันตลอด 24 ชั่วโมง หากคุณ Deploy VPS ใหม่แล้วทิ้งไว้โดยไม่ตั้งค่า Security มีโอกาสสูงมากที่จะถูก brute-force หรือถูก exploit ภายในไม่กี่ชั่วโมง

ข่าวดีคือการตั้งค่าเบื้องต้นไม่ซับซ้อน บทความนี้รวม Checklist ที่สำคัญที่สุดสำหรับผู้ใช้ VPS ทุกคน

1. เปลี่ยน SSH Port จาก 22

Port 22 คือ Port เริ่มต้นของ SSH และเป็นเป้าหมายแรกที่บอทจะ scan หา การเปลี่ยนเป็น Port ที่ไม่ค่อยใช้ เช่น 2222 หรือ 54321 ช่วยลด brute-force attempts ได้อย่างมีนัยสำคัญ

อย่าลืมเปิด Port ใหม่บน Firewall ก่อน แล้วค่อยปิด Port 22 เพื่อไม่ให้ตัวเองล็อคออกจากเซิร์ฟเวอร์

2. ปิด Root Login และสร้าง Sudo User

การ Login ด้วย root โดยตรงเป็นความเสี่ยงสูง ให้สร้าง user ใหม่พร้อม sudo privilege แทน:

จากนั้นแก้ไข sshd_config เพื่อปิด Root Login:

3. ตั้งค่า SSH Key Authentication

SSH Key แข็งแกร่งกว่า Password มาก เพราะต้องมีทั้ง Private Key และ Passphrase จึงจะ Login ได้ สร้าง SSH Key บนเครื่องของคุณ:

จากนั้น Copy Public Key ไปยัง VPS:

เมื่อทดสอบว่า Login ด้วย Key สำเร็จแล้ว ให้ปิด Password Login ใน sshd_config:

4. ติดตั้งและตั้งค่า UFW Firewall

UFW (Uncomplicated Firewall) เป็น Firewall ที่ใช้งานง่ายบน Ubuntu เปิดเฉพาะ Port ที่จำเป็น:

5. อัปเดตระบบสม่ำเสมอ

ช่องโหว่ส่วนใหญ่ถูก Patch ใน Update ใหม่แล้ว การไม่อัปเดตคือการทิ้งประตูเปิดไว้:

6. ติดตั้ง Fail2ban

Fail2ban จะ Ban IP ที่พยายาม Login ผิดหลายครั้งโดยอัตโนมัติ ช่วยป้องกัน Brute-force Attack:

7. Backup สม่ำเสมอ

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

ตั้งค่า SSH ให้ปลอดภัยแบบครบวงจร (key-only, ปิด root login, เปลี่ยน port)

หัวข้อก่อนหน้าได้พูดถึง SSH แยกเป็นส่วน ๆ แล้ว แต่ในทางปฏิบัติเราควรตั้งค่าทุกอย่างพร้อมกันในไฟล์ /etc/ssh/sshd_config เพราะ SSH คือประตูหลักของเซิร์ฟเวอร์ ถ้าด่านนี้แข็งแกร่ง โอกาสที่ผู้บุกรุกจะเข้ามาได้ก็ลดลงอย่างมาก หลักการคือ ใช้ key เท่านั้น (ปิด password ทั้งหมด) ปิดการ login ด้วย root โดยตรง และย้าย port ออกจาก 22 เพื่อลด noise จากบอท scan

ตัวอย่างการตั้งค่าที่แนะนำสำหรับ Ubuntu บน AsiaGB VPS — แก้ไฟล์ด้วย nano /etc/ssh/sshd_config แล้วปรับค่าให้ตรงตามนี้:

# /etc/ssh/sshd_config — ค่าที่แนะนำ
Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers yourusername
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

หลังแก้ไฟล์เสร็จ ให้ตรวจ syntax และ restart service โดยที่ยัง ห้ามปิด session เดิม จนกว่าจะทดสอบ login ผ่าน session ใหม่ได้สำเร็จ:

sshd -t                      # ตรวจ syntax ก่อน restart
systemctl restart ssh        # หรือ systemctl restart sshd
# เปิด terminal ใหม่แล้วลอง: ssh -p 2222 yourusername@YOUR_VPS_IP

การใช้ MaxAuthTries 3 และ LoginGraceTime 30 ช่วยให้ผู้โจมตีมีเวลาและจำนวนครั้งจำกัดในแต่ละการเชื่อมต่อ ส่วน AllowUsers เป็น whitelist ที่ดี — มีเฉพาะ user ที่ระบุไว้เท่านั้นที่ login ผ่าน SSH ได้ แม้บอทจะเดา username อื่นถูกก็ไม่มีทางเข้ามา

Firewall + Fail2Ban + อัปเดตระบบสม่ำเสมอ (สามชั้นที่ต้องทำงานพร้อมกัน)

การป้องกันที่ดีไม่ได้พึ่งมาตรการเดียว แต่ทำงานเป็นชั้น (defense in depth) สามชั้นพื้นฐานที่ทุก VPS ควรมีคือ Firewall ที่ปิด port ทั้งหมดยกเว้นที่จำเป็น, Fail2Ban ที่แบน IP ที่พยายาม brute-force และระบบอัปเดตอัตโนมัติที่อุดช่องโหว่ก่อนถูก exploit

เริ่มจาก UFW โดยตั้ง policy ปฏิเสธทุก incoming เป็นค่าเริ่มต้น แล้วเปิดเฉพาะ port ที่ใช้จริง:

ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp        # SSH port ใหม่
ufw allow 80/tcp          # HTTP
ufw allow 443/tcp         # HTTPS
ufw limit 2222/tcp        # จำกัด rate การเชื่อมต่อ SSH (กัน brute-force)
ufw enable
ufw status verbose        # ตรวจสอบ rule ทั้งหมด

ต่อด้วย Fail2Ban ซึ่งควรตั้งค่า jail สำหรับ SSH ให้ตรงกับ port ที่เปลี่ยนไป สร้างไฟล์ /etc/fail2ban/jail.local (ห้ามแก้ jail.conf ตรง ๆ เพราะจะถูก overwrite ตอนอัปเดต):

# /etc/fail2ban/jail.local
[sshd]
enabled  = true
port     = 2222
maxretry = 3
findtime = 600
bantime  = 3600
backend  = systemd

ค่านี้หมายความว่า ถ้ามี IP เดียวพยายาม login ผิด 3 ครั้งภายใน 10 นาที (findtime = 600) จะถูกแบน 1 ชั่วโมง (bantime = 3600) จากนั้น restart service ด้วย systemctl restart fail2ban และตรวจสถานะการแบนได้ด้วย fail2ban-client status sshd

ชั้นสุดท้ายคือการอัปเดต — ช่องโหว่ส่วนใหญ่ถูก patch ไปแล้วใน update ใหม่ ตั้งค่า unattended-upgrades ให้ติดตั้ง security update อัตโนมัติ:

apt update && apt upgrade -y
apt install unattended-upgrades -y
dpkg-reconfigure --priority=low unattended-upgrades   # เปิดใช้งาน

หลักการ Least Privilege และปิด Service ที่ไม่ใช้

หลักการ "สิทธิ์น้อยที่สุดเท่าที่จำเป็น" (least privilege) คือหัวใจของการทำเซิร์ฟเวอร์ให้ปลอดภัย ทุก service ทุก user และทุก port ที่เปิดอยู่คือ "พื้นที่โจมตี" (attack surface) เพิ่มขึ้นหนึ่งจุด ยิ่งเปิดน้อย โอกาสถูกเจาะก็ยิ่งน้อย

เริ่มจากสำรวจว่ามี service อะไรกำลังฟัง port อยู่บ้าง แล้วปิดตัวที่ไม่ได้ใช้:

ss -tulpn                          # ดู service ที่กำลังฟัง port อยู่
systemctl list-units --type=service --state=running
systemctl disable --now SERVICE    # ปิด service ที่ไม่ใช้ (เช่น cups, avahi-daemon)

แนวทางปฏิบัติด้าน least privilege ที่ควรทำ:

• ใช้งานด้วย sudo user เสมอ ไม่ทำงานเป็น root ตลอดเวลา — ใช้ sudo เฉพาะคำสั่งที่ต้องการสิทธิ์เท่านั้น
• ให้สิทธิ์ไฟล์เท่าที่จำเป็น — เว็บไซต์ใช้ chmod 644 สำหรับไฟล์ และ 755 สำหรับโฟลเดอร์ ไม่ใช้ 777 เด็ดขาด
• แต่ละ application รันด้วย user เฉพาะของตัวเอง (เช่น www-data สำหรับเว็บ) ไม่ใช้ root รัน service
• ถอนการติดตั้ง package ที่ไม่ใช้ด้วย apt purge เพื่อลดช่องโหว่ที่อาจมากับ software ที่ลืมไป
• ปิด port ที่ไม่ได้ใช้บน firewall — database (3306, 5432) ไม่ควรเปิดออกสู่ public ให้ bind กับ 127.0.0.1 เท่านั้น

การ bind database ไว้ที่ localhost เป็นจุดที่หลายคนพลาด — ถ้า MySQL หรือ PostgreSQL เปิด port ออก internet โดยตรง บอทจะ scan เจอและพยายาม brute-force ทันที ตรวจสอบค่า bind-address = 127.0.0.1 ในไฟล์ config ของ database เสมอ

Monitoring และ Backup คือส่วนหนึ่งของ Security

หลายคนคิดว่า security จบที่ firewall กับ SSH key แต่ความจริงคือการ มองเห็น (monitoring) และ กู้คืนได้ (backup) คือสองเสาหลักที่ทำให้ระบบทนทานต่อเหตุการณ์จริง ถ้าถูกเจาะแต่ไม่รู้ตัว ความเสียหายจะลุกลาม และถ้าไม่มี backup เมื่อข้อมูลเสียหายก็จบเกม

สำหรับ monitoring เริ่มจากเครื่องมือพื้นฐานที่ติดมากับระบบ และตรวจ log สม่ำเสมอ:

journalctl -u ssh --since "1 hour ago"   # ดู log การเข้า SSH
last -20                                   # ดูประวัติการ login ล่าสุด
grep "Failed password" /var/log/auth.log   # หาความพยายาม login ที่ล้มเหลว
apt install auditd -y                       # ติดตั้ง audit framework

สิ่งที่ควรเฝ้าดูเป็นประจำ ได้แก่ การ login ที่ผิดปกติ (เวลาแปลก ๆ หรือ IP ต่างประเทศ), การใช้ CPU/RAM/disk ที่พุ่งสูงผิดปกติ (อาจเป็นสัญญาณของ cryptominer ที่แอบติดตั้ง), และไฟล์ใน /etc หรือ web root ที่ถูกแก้ไขโดยไม่ทราบสาเหตุ

ด้าน backup ให้ทำตามกฎ 3-2-1 คือ มีสำเนาข้อมูล 3 ชุด เก็บบน media 2 ประเภท และอย่างน้อย 1 ชุดอยู่นอกเซิร์ฟเวอร์ (offsite) ที่สำคัญคือ ทดสอบ restore เป็นระยะ — backup ที่กู้คืนไม่ได้คือ backup ที่ไม่มีอยู่จริง อ่านแนวทางครบถ้วนได้ที่ คู่มือ Backup VPS ของเรา

Checklist สรุป

1. เปลี่ยน SSH Port จาก 22
2. ปิด Root Login, สร้าง Sudo User
3. ใช้ SSH Key Authentication, ปิด Password Login
4. ตั้งค่า UFW Firewall + เปิดเฉพาะ port ที่จำเป็น
5. อัปเดต Package สม่ำเสมอ (unattended-upgrades)
6. ติดตั้งและตั้งค่า Fail2ban jail ให้ตรง port
7. ใช้หลัก least privilege + ปิด service ที่ไม่ใช้
8. bind database ไว้ที่ 127.0.0.1 เท่านั้น
9. ตั้ง monitoring + ตรวจ log สม่ำเสมอ
10. Backup ตามกฎ 3-2-1 และทดสอบ restore

คำถามที่พบบ่อย (FAQ)

การเปลี่ยน SSH port ช่วยเรื่องความปลอดภัยจริงไหม?

การเปลี่ยน port จาก 22 ไม่ใช่มาตรการความปลอดภัยที่แท้จริง (security through obscurity) แต่ช่วยลด noise จากบอทที่ scan port 22 อัตโนมัติได้อย่างมาก ทำให้ log สะอาดขึ้นและ Fail2Ban ทำงานเบาลง อย่างไรก็ตามมันเป็นเพียงชั้นเสริม — สิ่งที่ป้องกันจริงคือการใช้ SSH key, ปิด password login และปิด root login ควรทำทั้งหมดร่วมกัน

ถ้าตั้งค่าผิดจน login เข้า VPS ไม่ได้ ต้องทำอย่างไร?

วิธีกันไว้ดีที่สุดคือเปิด session SSH เดิมค้างไว้เสมอระหว่างแก้ค่า ถ้าล็อกตัวเองออกจริง ๆ AsiaGB VPS มี Console / VNC access ผ่านหน้า control panel ที่ให้คุณเข้าถึงเซิร์ฟเวอร์ได้โดยตรงโดยไม่ผ่าน SSH คุณสามารถ login ผ่าน console แล้วแก้ไฟล์ sshd_config หรือ rule ของ firewall กลับได้

จำเป็นต้องใช้ Fail2Ban ไหม ถ้าใช้ SSH key อยู่แล้ว?

แนะนำให้ใช้ทั้งคู่ การใช้ SSH key อย่างเดียวป้องกันการเดารหัสผ่านได้ก็จริง แต่ Fail2Ban ยังช่วยลดภาระเซิร์ฟเวอร์จากการเชื่อมต่อที่ไม่พึงประสงค์ และครอบคลุม service อื่น ๆ ได้ด้วย (เช่น web login, mail) นอกจากนี้ยังป้องกัน DoS ระดับเบาจากการ flood การเชื่อมต่อ การมีหลายชั้นย่อมปลอดภัยกว่าชั้นเดียวเสมอ

ควร backup VPS บ่อยแค่ไหน?

ขึ้นอยู่กับว่าข้อมูลเปลี่ยนแปลงเร็วแค่ไหน เว็บไซต์ที่มีคำสั่งซื้อหรือฐานข้อมูลที่อัปเดตตลอดควร backup รายวัน (หรือถี่กว่านั้นสำหรับ database) ส่วนเว็บ static ที่ไม่ค่อยเปลี่ยนอาจ backup รายสัปดาห์ก็พอ สิ่งสำคัญกว่าความถี่คือเก็บ backup ไว้นอกเซิร์ฟเวอร์ (offsite) และทดสอบ restore เป็นระยะ เพื่อให้แน่ใจว่ากู้คืนได้จริงเมื่อต้องใช้