วิธีตั้งค่า SSH Hardening บน VPS ให้ปลอดภัย

ทำไม SSH จึงเป็นสิ่งแรกที่ต้องทำ Hardening

SSH คือช่องทางในการควบคุม server ของคุณ ซึ่งเปรียบเสมือนกุญแจที่ผู้โจมตีทุกคนพยายามทดสอบเป็นอันดับแรก เมื่อ VPS ออนไลน์ ระบบจะเริ่มมีการสแกนเพื่อสุ่ม username และ password ผ่าน port 22 ทันที คุณสามารถตรวจสอบเหตุการณ์นี้ได้จาก log ภายในเวลาเพียงไม่กี่นาที การทำ Hardening SSH คือการกำจัดสิ่งที่ผู้โจมตีสามารถสุ่มได้ เช่น การปิดการเข้าสู่ระบบด้วย password และการปิดการเข้าสู่ระบบด้วย root เพื่ออนุญาตให้ใช้เฉพาะ cryptographic keys เท่านั้น เมื่อดำเนินการแล้ว การสุ่มรหัสผ่านจะไม่มีวันสำเร็จ เพราะไม่มี password ให้ค้นหา

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

Step 1: ตรวจสอบการทำงานของการยืนยันตัวตนด้วย key ก่อน

การยืนยันตัวตนด้วย key จะใช้ key pair แทนการใช้ password โดยประกอบด้วย private key ซึ่งเก็บไว้ในเครื่องของคุณ และ public key ที่ต้องนำไปวางไว้บน server ระบบจะตรวจสอบว่าคุณมี private key โดยที่ key ดังกล่าวไม่ต้องออกจากเครื่องของคุณ ก่อนที่จะปิดการใช้งาน password คุณต้องยืนยันว่า key ใช้งานได้ เพื่อป้องกันปัญหาการถูกล็อกออกจากระบบ

หากคุณยังไม่มี key ให้สร้าง key ใหม่บนเครื่องของคุณ:

ssh-keygen -t ed25519

คัดลอก public key ไปยัง server:

ssh-copy-id user@your-server

จากนั้นเปิด SSH session ใหม่ หากระบบอนุญาตให้เข้าใช้งานได้โดยไม่ต้องถาม password แสดงว่า key ใช้งานได้และคุณสามารถปิดการใช้งาน password ได้อย่างปลอดภัย หากคุณเพิ่งเริ่มใช้งาน key หรือใช้งานคอมพิวเตอร์หลายเครื่อง พื้นฐานการจัดการ SSH key จะอธิบายรายละเอียดทั้งหมด ทั้งเรื่องการใช้หนึ่ง key ต่อหนึ่งอุปกรณ์, การตั้งค่า permission ที่ sshd กำหนด และวิธีการยกเลิกการใช้งาน key เมื่อคอมพิวเตอร์โน้ตบุ๊กสูญหาย

Step 2: Harden sshd with a drop-in file

ห้ามแก้ไขไฟล์ /etc/ssh/sshd_config โดยตรง Ubuntu 24.04 จะอ่าน drop-in files จาก /etc/ssh/sshd_config.d/ การใช้ไฟล์ขนาดเล็กในตำแหน่งดังกล่าวมีความเป็นระเบียบมากกว่า ไฟล์จะไม่ถูกเขียนทับเมื่อมีการอัปเกรด package และสามารถลบออกได้ง่ายหากเกิดปัญหา ชื่อไฟล์มีความสำคัญ เนื่องจาก sshd จะใช้ค่าแรกที่อ่านได้สำหรับแต่ละการตั้งค่า และ Ubuntu cloud images จะมีไฟล์ 50-cloud-init.conf ที่มีค่า PasswordAuthentication yes อยู่ใน directory นี้ ให้ตั้งชื่อไฟล์ของคุณเป็น 00- เพื่อให้ไฟล์ถูกจัดลำดับไว้ก่อนไฟล์ดังกล่าวและมีผลบังคับใช้ ส่วนไฟล์ 99- จะถูกละเลยโดยไม่มีการแจ้งเตือน ให้สร้างไฟล์ดังนี้:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

ใส่เนื้อหาต่อไปนี้ลงในไฟล์:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

แต่ละบรรทัดคือการปิดช่องโหว่ PasswordAuthentication no คือส่วนที่สำคัญที่สุด เพราะเมื่อปิดการใช้ password การโจมตีแบบ brute-force จะไม่สามารถทำอะไรได้เลย KbdInteractiveAuthentication no จะปิดช่องทางการเข้าถึงด้วย password อีกช่องทางหนึ่ง PermitRootLogin no หมายความว่าผู้โจมตีต้องทราบ username และต้องมี key ของคุณเท่านั้น ไม่สามารถมุ่งเป้าไปที่บัญชี root ซึ่งมีอยู่ในทุกเครื่องได้

Step 3: ทดสอบการตั้งค่า และทำการ reload

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

sudo sshd -t

หากไม่มีข้อความใดปรากฏขึ้น แสดงว่าการตั้งค่าถูกต้อง ให้ทำการ reload SSH:

sudo systemctl reload ssh

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

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

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

Step 4: พอร์ตที่ไม่เป็นมาตรฐาน (Optional)

การเปลี่ยนพอร์ต SSH จาก 22 เป็น 2222 ไม่ได้ช่วยเพิ่มความปลอดภัยอย่างแท้จริง เนื่องจากผู้โจมตีที่ตั้งใจจะโจมตีจะทำการสแกนทุกพอร์ต การเปลี่ยนพอร์ตช่วยลดปริมาณ log ที่ไม่จำเป็น เนื่องจากเครื่องมือสแกนอัตโนมัติส่วนใหญ่จะทดสอบเฉพาะพอร์ต 22 หากต้องการเปลี่ยน ให้เพิ่ม Port 2222 ลงใน drop-in file โดยต้องอนุญาตพอร์ตใหม่ใน firewall ก่อน จากนั้นให้รัน sudo systemctl daemon-reload && sudo systemctl restart ssh.socket และเชื่อมต่อด้วย ssh -p 2222 สำหรับ Ubuntu 24.04 ssh.socket เป็นผู้ดูแลพอร์ตที่รอรับการเชื่อมต่อ ดังนั้นการใช้ reload ssh แบบปกติจะทำให้ sshd ยังคงอยู่ที่พอร์ต 22 การ restart socket จะเป็นการทำให้ระบบรับทราบพอร์ตใหม่ ให้ถือว่าการทำเช่นนี้คือการจัดระเบียบระบบ ไม่ใช่การป้องกัน

Step 5: การเพิ่มชั้นการป้องกันเพิ่มเติม

การใช้ SSH keys ที่มีความปลอดภัยสูงคือพื้นฐานสำคัญ และมีอีกสองชั้นการป้องกันที่ทำงานต่อจากนั้น

Fail2ban จะตรวจสอบ logs และทำการ ban address ที่พยายาม login ล้มเหลวซ้ำๆ ซึ่งช่วยลดสัญญาณรบกวนจาก scanner และกำจัดผู้บุกรุกออกไปได้รวดเร็วขึ้น ระบบนี้ทำงานร่วมกับการใช้ key-only auth ได้เป็นอย่างดี: ดูรายละเอียดที่ Fail2ban on Ubuntu to stop SSH attacks

วิธีที่มีประสิทธิภาพยิ่งกว่าคือการปิดการใช้งาน SSH บน public internet โดยสิ้นเชิง หากคุณ put SSH behind a WireGuard VPN และตั้งค่า firewall ให้อนุญาตเฉพาะ port 22 ผ่านทาง tunnel เท่านั้น ผู้ใช้งานที่อยู่นอก VPN จะไม่สามารถเข้าถึง SSH ได้เลย ซึ่งจะทำให้การโจมตีแบบ brute-force เป็นไปไม่ได้ แทนที่จะเป็นเพียงแค่ทำได้ยากขึ้น ทั้งหมดนี้ตั้งอยู่บนสมมติฐานว่ามีการตั้งค่า firewall แบบ default-deny ไว้ ซึ่งสามารถดูได้ที่ UFW set up on the VPS

SSH เป็นเพียงส่วนหนึ่งของรายการตรวจสอบที่ใหญ่กว่า: the first 10 minutes on a new VPS จะเรียงลำดับขั้นตอนต่างๆ และ automatic security updates on Ubuntu จะช่วยให้ระบบได้รับการติดตั้ง patch อย่างต่อเนื่องหลังจากนั้น

FAQ

วิธีปิดการเข้าสู่ระบบด้วยรหัสผ่านสำหรับ SSH บน Ubuntu 24.04

สร้าง drop-in file ไว้ที่ /etc/ssh/sshd_config.d/00-hardening.conf (การใช้ prefix 00 จะทำให้ไฟล์ถูกจัดลำดับก่อน 50-cloud-init.conf ซึ่งปกติค่า PasswordAuthentication yes จะถูกนำมาใช้ เนื่องจาก sshd จะเลือกใช้ค่าแรกที่อ่านพบ) โดยให้มีเนื้อหาคือ PasswordAuthentication no และ KbdInteractiveAuthentication no จากนั้นรัน sudo sshd -t เพื่อตรวจสอบความถูกต้อง แล้วจึงรัน sudo systemctl reload ssh ควรทดสอบการเข้าสู่ระบบด้วย key ใน session ใหม่ก่อนเริ่มใช้งานจริง การแก้ไขผ่าน drop-in แทนการแก้ไข sshd_config จะช่วยให้การตั้งค่าไม่หายไปเมื่อมีการอัปเกรด package และสามารถยกเลิกการตั้งค่าได้ง่าย

ควรปิดการเข้าสู่ระบบ root ผ่าน SSH หรือไม่?

ควรปิด โดยตั้งค่า PermitRootLogin no เพื่อป้องกันไม่ให้ผู้อื่นเข้าสู่ระบบด้วยสิทธิ์ root โดยตรง ให้เข้าสู่ระบบด้วย user ปกติของคุณแล้วใช้ sudo สำหรับงานระดับ admin เนื่องจาก root มีอยู่ในทุกเครื่อง Linux การเปิดให้เข้าถึงได้จึงเป็นการบอก username ที่แน่นอนแก่ผู้โจมตี การปิดการเข้าถึงนี้จะบังคับให้ผู้โจมตีต้องทราบชื่อ account ของคุณและต้องมี key ของคุณด้วย

การเปลี่ยน SSH port ช่วยให้เซิร์ฟเวอร์ปลอดภัยขึ้นหรือไม่?

ไม่ช่วยอย่างมีนัยสำคัญ การเปลี่ยนจาก port 22 ช่วยซ่อนคุณจาก scanner ที่สแกนเฉพาะ port 22 ซึ่งช่วยลดปริมาณ log ที่ไม่จำเป็น แต่ผู้โจมตีตัวจริงจะสแกนทุก port และตรวจพบอยู่ดี การใช้ key-only authentication คือสิ่งที่ป้องกันการบุกรุกได้อย่างแท้จริง หากคุณเปลี่ยน port ให้เปิด port ใหม่ใน firewall ก่อน แล้วจึงรัน sudo systemctl daemon-reload && sudo systemctl restart ssh.socket สำหรับ Ubuntu 24.04 เนื่องจาก socket เป็นผู้ดูแล listener การสั่ง reload แบบปกติจะทำให้ sshd ยังคงทำงานบน port 22

จำเป็นต้องใช้ Fail2ban หรือไม่หากใช้ SSH keys แล้ว?

เป็นทางเลือกที่สามารถใช้ได้แต่ไม่บังคับ เมื่อใช้ key-only authentication การสุ่มรหัสผ่านจะไม่สามารถทำสำเร็จ ดังนั้น Fail2ban จึงไม่ใช่ตัวหลักในการป้องกันผู้โจมตี แต่จะช่วยจำกัดจำนวนครั้งที่เกิดความล้มเหลวซ้ำๆ จาก address เดียวกัน ซึ่งช่วยลด noise จาก scanner ใน log และตัดการเชื่อมต่อของผู้ที่พยายามบุกรุกซ้ำๆ ได้เร็วขึ้น อย่างไรก็ตาม การโจมตีแบบช้าๆ และกระจายตัว (distributed attack) จะยังคงไม่ถูกแบนเนื่องจากไม่ถึงเกณฑ์ที่กำหนด แนะนำให้รัน Fail2ban ควบคู่ไปกับ key auth และหากเป็นไปได้ควรใช้งาน SSH ผ่าน VPN

จะกู้คืนระบบอย่างไรหากถูกล็อกไม่ให้เข้า SSH?

ให้ใช้ web console ของผู้ให้บริการ ซึ่งเป็นการเชื่อมต่อเซิร์ฟเวอร์ผ่าน serial หรือ VNC ที่ไม่ผ่าน SSH จากช่องทางนั้นคุณสามารถเข้าสู่ระบบเพื่อแก้ไขไฟล์ drop-in sshd และสั่ง reload service ได้ นี่คือเหตุผลที่ต้องทดสอบ SSH config ใหม่ใน terminal ที่สองก่อนปิด session แรก และเป็นเหตุผลที่ควรตรวจสอบให้แน่ใจว่า key authentication ใช้งานได้แล้วก่อนจะปิดการใช้งานรหัสผ่าน