วิธีตั้งค่าความปลอดภัย VPS เบื้องต้นภายใน 10 นาที

10 นาทีแรกเป็นตัวกำหนดความปลอดภัยของเซิร์ฟเวอร์

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

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

นาทีที่ 1: อัปเดตทุกอย่าง

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

apt update && apt upgrade -y

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

นาทีที่ 2: สร้างผู้ใช้ทั่วไปที่มีสิทธิ์ sudo

อย่าทำงานด้วยบัญชี root ต่อไป ให้สร้างผู้ใช้สำหรับตัวคุณเองและกำหนดสิทธิ์ sudo ให้:

adduser matt
usermod -aG sudo matt

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

นาทีที่ 4: การตั้งค่า SSH keys

รหัสผ่านสามารถถูกเดาได้ แต่กุญแจ (keys) ไม่สามารถถูกเดาได้ หากคุณยังไม่มีกุญแจบนแล็ปท็อปของคุณ ให้สร้างขึ้นมาใหม่ดังนี้:

ssh-keygen -t ed25519

จากนั้นคัดลอกส่วนที่เป็น public key ไปยังเซิร์ฟเวอร์:

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id จำเป็นต้องเปิดใช้งานการล็อกอินด้วยรหัสผ่านสำหรับผู้ใช้ใหม่ หากปิดใช้งานอยู่ ให้คัดลอก ~/.ssh/authorized_keys ของ root ไปยัง /home/matt/.ssh/authorized_keys (ซึ่งเป็นของ matt) หรือคัดลอก public key ของคุณไปวางในไฟล์ดังกล่าวด้วยตนเอง

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

ให้ล็อกเอาต์แล้วล็อกอินใหม่ในฐานะ matt โดยใช้กุญแจ และตรวจสอบว่าใช้งานได้จริงก่อนที่จะดำเนินการขั้นตอนถัดไป การปิดกั้น SSH ก่อนที่คุณจะสามารถล็อกอินด้วยกุญแจได้ คือสาเหตุที่ทำให้ผู้ใช้งานล็อกตัวเองออกจากระบบ หากการล็อกอินนั้นแสดงข้อความ Permission denied (publickey) ให้แก้ไขให้เรียบร้อยในตอนนี้ แทนที่จะกลับไปใช้รหัสผ่าน เนื่องจากข้อความดังกล่าวครอบคลุมถึง ข้อผิดพลาด 5 รูปแบบ และผลลัพธ์จาก ssh -v จะระบุว่าคุณกำลังประสบกับปัญหาใดในบรรดาข้อผิดพลาดเหล่านั้น

นาทีที่ 6: ปิดการล็อกอินด้วย root และรหัสผ่าน

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

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

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

จากนั้นโหลด SSH ใหม่:

sudo systemctl restart ssh

ตรวจสอบการตั้งค่าที่ sshd ใช้งานจริง เพื่อให้แน่ใจว่าไม่มีไฟล์ drop-in อื่นมาแทนที่การตั้งค่าของคุณ:

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

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

นาทีที่ 8: เปิดใช้งานไฟร์วอลล์

ตั้งค่าเริ่มต้นให้ปฏิเสธการเชื่อมต่อขาเข้าทั้งหมด (Default-deny) แล้วจึงอนุญาตเฉพาะสิ่งที่จำเป็นเท่านั้น ต้องอนุญาต SSH ก่อนที่จะเปิดใช้งานไฟร์วอลล์ มิฉะนั้นคุณจะตัดการเชื่อมต่อของตนเอง:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

เพิ่มกฎ allow สำหรับบริการที่คุณใช้งานจริง เช่น 80/tcp และ 443/tcp สำหรับเว็บไซต์ หากเซสชัน SSH ใหม่ไม่สามารถเชื่อมต่อได้หลังจากขั้นตอนนี้ ให้อ่านข้อความแสดงข้อผิดพลาดก่อนที่จะแก้ไขสิ่งใด เพราะ การปฏิเสธการเชื่อมต่อหมายความว่า sshd ตอบรับแล้ว แต่การหมดเวลา (timeout) มักหมายความว่าไฟร์วอลล์บล็อกแพ็กเก็ตไว้ ตรวจสอบให้แน่ใจว่าครอบคลุมทั้ง IPv4 และ IPv6 เนื่องจากไฟร์วอลล์ที่กรองเฉพาะ IPv4 จะทำให้ ฝั่ง IPv6 เปิดกว้างอยู่ คำแนะนำฉบับเต็มอยู่ใน พื้นฐานไฟร์วอลล์บน VPS คำสั่ง ufw เหล่านี้ใช้สำหรับ Ubuntu หรือ Debian หากใช้ Rocky หรือ AlmaLinux เป้าหมายการตั้งค่าแบบ default-deny จะเหมือนกัน แต่เครื่องมือที่ใช้คือ firewalld ดังนั้นให้ทำตาม ขั้นตอนสำหรับ firewalld ในบทความนี้ แทน

นาทีที่ 10: ชะลอการสแกนด้วย Fail2ban

สุดท้าย ให้เพิ่ม Fail2ban เพื่อขับไล่ที่อยู่ IP ที่พยายามโจมตีพอร์ตของคุณอย่างต่อเนื่อง:

sudo apt install -y fail2ban

บน Ubuntu 24.04 การติดตั้งมาตรฐานจะปกป้อง SSH ตั้งแต่การบูตครั้งแรก ในเมื่อคุณกำหนดให้ต้องใช้คีย์อยู่แล้ว สิ่งนี้จึงเป็นมาตรการสำรองที่ช่วยลดสัญญาณรบกวนใน log และบล็อกผู้ที่กระทำผิดซ้ำ แทนที่จะเป็นแนวป้องกันหลักของคุณ

รายการตรวจสอบของคุณ

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

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

เมื่อติดตั้งสิ่งจำเป็นพื้นฐานเรียบร้อยแล้ว การอัปเดตความปลอดภัยอัตโนมัติบน Ubuntu จะช่วยให้เซิร์ฟเวอร์เป็นเวอร์ชันล่าสุดอยู่เสมอโดยที่คุณไม่ต้องล็อกอินเข้ามาเอง จากนั้นบริการทุกอย่างที่คุณติดตั้งเพิ่มเติมจะต้องผ่านการตรวจสอบความปลอดภัยของตนเอง และจุดอ่อนจะเปลี่ยนไป: หากคุณโฮสต์ password vault ด้วยตนเอง เซิร์ฟเวอร์จะไม่เก็บข้อมูลที่เป็นข้อความธรรมดา (plaintext) ดังนั้น ความเสี่ยงที่แท้จริงของ Vaultwarden จึงอยู่ที่ admin token และไฟล์สำรองข้อมูลเท่านั้น

FAQ

ฉันควรทำสิ่งใดเป็นอันดับแรกบน VPS เครื่องใหม่?

อัปเดตระบบด้วย apt update && apt upgrade -y จากนั้นสร้างผู้ใช้ทั่วไปที่มีสิทธิ์ sudo และหยุดใช้งานในฐานะ root หลังจากนั้นให้ตั้งค่า SSH keys, ปิดการล็อกอินด้วย root และการยืนยันตัวตนด้วยรหัสผ่าน, เปิดใช้งาน firewall แบบ default-deny และติดตั้ง Fail2ban การทำตามลำดับนี้ช่วยให้แต่ละขั้นตอนมีความปลอดภัยโดยไม่ทำให้คุณถูกล็อกออกจากระบบ

ฉันจะหลีกเลี่ยงการถูกล็อกออกจากระบบขณะปรับแต่งความปลอดภัย SSH ได้อย่างไร?

ตั้งค่าและทดสอบการล็อกอินด้วย SSH key ให้เรียบร้อยก่อนที่คุณจะปิดการใช้งานรหัสผ่านหรือ root ให้ล็อกเอาต์และล็อกอินกลับเข้ามาใหม่ด้วย key เพื่อยืนยันว่าใช้งานได้จริง แล้วจึงค่อยปิด PasswordAuthentication และ PermitRootLogin เมื่อคุณเปิดใช้งาน firewall ให้ยอมรับการเชื่อมต่อที่พอร์ต 22 ก่อนที่จะรัน ufw enable หากคุณถูกล็อกออกจากระบบจริงๆ คุณสามารถใช้ web console ของผู้ให้บริการเพื่อเข้าถึงเซิร์ฟเวอร์ได้โดยไม่ต้องผ่าน SSH

ฉันจำเป็นต้องทำทุกขั้นตอนเหล่านี้บนเซิร์ฟเวอร์ขนาดเล็กจริงๆ หรือ?

จำเป็น เพราะระบบสแกนอัตโนมัติไม่สนใจว่าเซิร์ฟเวอร์ของคุณจะมีขนาดเท่าใด พวกมันจะพยายามสแกนทุก public IP ในลักษณะเดียวกัน ขั้นตอนทั้งหมดนี้ใช้เวลาประมาณสิบนาทีและช่วยปิดช่องทางที่ง่ายที่สุด: ไม่มีการล็อกอินด้วย root, ไม่มีการเดารหัสผ่าน, ไม่มีการเปิดพอร์ตที่คุณไม่ได้ตั้งใจ และมีการแพตช์บั๊กที่ทราบกันดีโดยอัตโนมัติ

ขั้นตอนใดสำคัญที่สุดเพียงขั้นตอนเดียว?

การใช้ SSH ที่อนุญาตเฉพาะ key และปิดการล็อกอินด้วย root การโจมตี VPS เครื่องใหม่ส่วนใหญ่เป็นการเดารหัสผ่านอัตโนมัติที่พุ่งเป้าไปยัง root การปิดทั้งสองอย่างนี้จะทำให้การโจมตีประเภทดังกล่าวทั้งหมดเป็นไปไม่ได้ ส่วน firewall และ Fail2ban จะทำหน้าที่จำกัดสิ่งที่เปิดเผยอยู่และชะลอการโจมตีที่อาจหลงเหลืออยู่

ฉันจะยืนยันได้อย่างไรว่าเซิร์ฟเวอร์ถูกล็อกดาวน์อย่างแน่นหนาแล้ว?

ตรวจสอบสามสิ่งด้วยตนเองก่อนที่คุณจะวางใจ รัน sudo ss -tlnp และยืนยันว่ามีเพียงพอร์ตที่คุณตั้งใจจะเปิดเท่านั้นที่กำลังฟังอยู่บน public address โดยไม่มีบริการ 0.0.0.0 หรือ [::] ที่คุณอาจลืมทิ้งไว้ รัน sudo ufw status verbose และยืนยันว่านโยบายขาเข้าเริ่มต้นคือ deny และมีกฎทั้งแบบปกติและ (v6) อยู่ครบถ้วน และควรเปิด SSH session ที่สองทิ้งไว้เสมอในขณะที่คุณปิด session แรก เพื่อป้องกันไม่ให้ความผิดพลาดในการตั้งค่า SSH ทำให้คุณถูกล็อกออกจากเซิร์ฟเวอร์ หากทั้งสามส่วนถูกต้อง แสดงว่าการตั้งค่าพื้นฐานเสร็จสมบูรณ์แล้ว