ลำดับที่เหมาะสำหรับเตรียมฝั่งเซิร์ฟเวอร์ของ Proxy IP ที่ตั้งเอง: ตรวจสอบการเข้าถึง SSH ก่อน เปลี่ยนพอร์ตและใช้การยืนยันตัวตนด้วยกุญแจ ทำ hardening ขั้นพื้นฐาน ติดตั้งบริการ proxy และเปิดพอร์ต แล้วจึงเชื่อมต่อและตรวจสอบจาก client
เมื่อซื้อ cloud server มาใช้เป็น proxy ปัญหามักไม่ได้อยู่ที่การเชื่อมต่อพื้นฐาน แต่เกิดจากลำดับการเตรียมฝั่งเซิร์ฟเวอร์มากกว่า หากทำตามลำดับที่ถูกต้อง client มักเชื่อมต่อได้ตั้งแต่ครั้งแรก แต่ถ้าลำดับสับสนก็ต้องกลับไปแก้ configuration ใน terminal ซ้ำ ๆ
บทความนี้พูดเฉพาะฝั่งเซิร์ฟเวอร์ ตั้งแต่การ login ครั้งแรก การจำกัดทางเข้า การทำให้ proxy service ทำงาน การเปิดพอร์ต การเชื่อมต่อจาก client ไปจนถึงการไล่ตรวจทีละชั้นเมื่อเชื่อมต่อไม่ได้
Login ครั้งแรก ให้ตรวจสอบทางเข้าก่อน
หลังจากสร้าง instance แล้ว ให้ login ผ่าน web terminal ใน console ของผู้ให้บริการก่อน อย่าเพิ่งพึ่งเครื่องมือ local ตั้งแต่เริ่มต้น ขั้นตอนนี้มีไว้เพียงเพื่อยืนยันว่าเครื่องทำงานและ network เข้าถึงได้
เมื่อเข้าแล้ว ให้เปลี่ยนเป็น root โดยรัน sudo -i แล้วกด Enter หาก prompt เปลี่ยนจาก $ เป็น # แสดงว่ายกระดับสิทธิ์สำเร็จ ขั้นตอนต่อไปให้ทำด้วยสิทธิ์นี้
จดข้อมูลไว้สี่อย่าง ได้แก่ public IP, username สำหรับ login (ค่าเริ่มต้นบน Linux คือ root), password และ SSH port (ค่าเริ่มต้น 22) ฝั่ง client ต้องใช้ครบทั้งสี่ค่า หากขาดอย่างใดอย่างหนึ่งก็เชื่อมต่อไม่ได้
เปลี่ยนพอร์ตเริ่มต้น แล้วค่อยเปลี่ยนเป็นการ login ด้วยกุญแจ
พอร์ต 22 ถูกสแกนไม่รู้กี่ครั้งต่อวัน และการลอง credential แบบอัตโนมัติเป็นเรื่องปกติ การเปลี่ยนพอร์ตไม่ได้ทำให้เซิร์ฟเวอร์แข็งแรงขึ้นโดยตรง แต่ช่วยกรอง automated noise ส่วนใหญ่ได้
แก้ไขที่ /etc/ssh/sshd_config เปิดด้วย vi กด i เพื่อเข้าโหมดแก้ไข เปลี่ยนบรรทัด PermitRootLogin และ PasswordAuthentication เป็น yes จากนั้นกด Esc แล้วพิมพ์ :wq เพื่อบันทึกและออก หากผู้ให้บริการรองรับการ login ด้วยกุญแจ วิธีที่รัดกุมกว่าคือใส่ public key จากเครื่อง local ลงใน authorized_keys ของเซิร์ฟเวอร์ แล้วเปลี่ยน PasswordAuthentication เป็น no เพื่อให้รับเฉพาะกุญแจ
อย่าปิด session ปัจจุบันทันทีหลังแก้ configuration ให้เปิด terminal อีกหน้าต่างก่อน แล้วลอง login หนึ่งครั้งด้วยพอร์ตใหม่และวิธีใหม่ ยืนยันว่าเข้าได้ แล้วจึงปิดหน้าต่างเดิม ไม่เช่นนั้นหากตั้งค่าผิดอาจล็อกตัวเองออกจากเซิร์ฟเวอร์และต้องกลับไปกู้ผ่าน console ของผู้ให้บริการ
SSH port อยู่ที่บรรทัด Port หลังจากแก้แล้วให้ restart บริการ SSH เพื่อให้ configuration มีผล บนระบบ Debian และ Ubuntu สามารถรัน /etc/init.d/ssh restart ได้
ทำ hardening ขั้นพื้นฐานให้เสร็จตั้งแต่วันแรก
นอกจากเปลี่ยนพอร์ตและใช้กุญแจแล้ว มีอีกสองเรื่องเล็ก ๆ ที่ควรทำให้เสร็จในวันแรก เรื่องแรกคือกำหนด password แบบสุ่มที่ยาวพอให้ root ด้วย passwd root และอย่าใช้ชุดที่เดาง่าย เรื่องที่สองคือปิด service และ port ที่ไม่จำเป็น ยิ่งมีสิ่งที่ทำงานบนเครื่องน้อย attack surface ก็ยิ่งเล็ก และ system firewall ควรอนุญาตเฉพาะพอร์ตที่จำเป็นจริง ๆ
หากเซิร์ฟเวอร์นี้จะใช้งานระยะยาวจากต้นทางคงที่เพียงไม่กี่แห่ง ให้จำกัด source address ใน security group ให้เหลือเฉพาะจุดเหล่านั้น ซึ่งปลอดภัยกว่าการเปิดให้ทั้ง Internet มาก
ติดตั้ง proxy service และตั้งค่าการยืนยันตัวตน
เมื่อเตรียมฝั่งเซิร์ฟเวอร์เสร็จแล้ว ค่อยจัดการตัว proxy เอง
ทางหนึ่งคือใช้ SSH tunnel โดยตรง ไม่ต้องติดตั้งอะไรเพิ่มบนเซิร์ฟเวอร์ client ใช้บริการ SSH ที่มีอยู่ในระบบสำหรับ forwarding และใช้ credential ชุดเดียวกับเซิร์ฟเวอร์ วิธีนี้สะดวก แต่ประสิทธิภาพระดับทั่วไปและจะเริ่มหนักเมื่อมี connection พร้อมกันมาก จึงเหมาะกับการใช้ชั่วคราวหรือมี account ไม่มาก
อีกทางคือ ติดตั้ง proxy service โดยเฉพาะบนเซิร์ฟเวอร์ โดยทั่วไปใช้คำสั่งติดตั้งเพียงคำสั่งเดียว แล้วตั้งค่าวิธี authentication และ listening port เอง หลังติดตั้งอย่าลืมเปิด auto-start ตอนบูต ไม่เช่นนั้นพอเซิร์ฟเวอร์ restart ครั้งเดียว proxy ก็หยุดตามไปด้วย
Authentication แบ่งเป็นสามระดับที่ปลอดภัยขึ้นตามลำดับ: username กับ password ง่ายที่สุด แต่ถ้ารั่วก็แทบเท่ากับยก proxy ให้คนอื่น; password ร่วมกับ allowlist ของ source IP มักพอสำหรับงานทั่วไป; การยืนยันด้วย key หรือ certificate แข็งแรงที่สุด แม้ตั้งค่ายุ่งยากขึ้นเล็กน้อยแต่คุ้มค่าสำหรับ account ที่ใช้งานระยะยาว
ต้องเปิดพอร์ตแยกกันสองจุด
นี่คือจุดที่พลาดกันบ่อยที่สุด Listening port ของ proxy service ต้องถูกอนุญาตทั้งใน system firewall และ security group ของผู้ให้บริการ ทั้งสองจุดทำงานแยกจากกัน เปิดเพียงจุดเดียวก็ยังเชื่อมต่อไม่ได้
อีกตำแหน่งที่มักถูกมองข้ามคือ listening address ของ service บาง service ผูกไว้กับ 127.0.0.1 เท่านั้นเป็นค่าเริ่มต้น หากทดสอบบนเซิร์ฟเวอร์เองแล้วผ่าน แต่จากภายนอกเข้าไม่ได้ ก็มักเป็นสาเหตุนี้ ให้เปลี่ยน listening address เป็น private address ของเซิร์ฟเวอร์หรือ 0.0.0.0
เชื่อมต่อจาก local client
สร้าง environment ใหม่ในเครื่องมือจัดการ environment แล้วเลือกชนิด proxy ตามที่ใช้งานจริง หากใช้ SSH tunnel ให้ใส่ public IP ของเซิร์ฟเวอร์เป็น address ใส่ SSH port เป็น port และใช้ username กับ password ของเซิร์ฟเวอร์ จากนั้นรัน connection test
Test ผ่านหมายความเพียงว่าเส้นทางเชื่อมต่อทำงาน ให้เปิด environment แล้วตรวจเพิ่มอีกสามอย่าง: exit IP ต้องเป็น public IP ของเซิร์ฟเวอร์; DNS ต้องวิ่งผ่าน proxy ด้วย เพราะหากยัง resolve DNS แบบ local ข้อมูลภูมิภาคที่เปิดเผยอาจไม่ตรงกับ exit IP; และ time zone กับ language ต้องสอดคล้องกับภูมิภาคของทางออก เมื่อทั้งสามข้อผ่านจึงถือว่า environment พร้อมใช้งาน
เมื่อจำนวน account เพิ่มขึ้น ให้กำหนดความสัมพันธ์ระหว่าง environment กับทางออกให้คงที่ เพื่อไม่ให้หลาย account ใช้ environment เดียวกัน เครื่องมืออย่าง PurpleMark สามารถผูกทางออกแยกให้แต่ละ account ได้ ซึ่งเสถียรกว่าการดูแลตาราง mapping ด้วยมือ
ถ้าเชื่อมต่อไม่ได้ ให้ตรวจจากข้างนอกเข้าไปข้างใน
เริ่มจากชั้นนอกสุดก่อน: security group อนุญาตแล้วหรือยัง? system firewall อนุญาตแล้วหรือยัง? ยืนยันสองจุดนี้ก่อนค่อยตรวจลึกลงไป
ต่อไปดูที่ service เอง: process ยังทำงานอยู่หรือไม่ โดยเฉพาะหลังจาก server restart? listening address ผูกไว้เฉพาะ local หรือไม่?
จากนั้นดูชั้น authentication: username หรือ password ผิดหรือไม่? permission ของ key file เปิดกว้างเกินไปหรือไม่? หาก permission ไม่ถูกต้อง SSHD จะปฏิเสธ key ทันที สุดท้ายจึงค่อยตรวจฝั่ง client ว่าใส่ public IP หรือเผลอใส่ private IP จุดนี้สับสนกันได้ง่ายมาก
ถ้าตรวจตามลำดับนี้ โดยทั่วไปสองถึงสามรอบก็ระบุได้ว่าปัญหาอยู่ที่ชั้นไหน แทนที่จะติดตั้ง service ใหม่ซ้ำ ๆ
สรุป
การเตรียมฝั่งเซิร์ฟเวอร์ใช้เวลาไม่ถึงครึ่งชั่วโมง แต่เป็นตัวกำหนดว่าในอีกหลายเดือนข้างหน้าจะดูแลเครื่องนี้ง่ายเพียงใด จำกัดทางเข้า เปิดพอร์ตให้ถูกต้อง และตั้งค่า authentication ให้ชัดเจน จากนั้นก็เหลือเพียงงานบำรุงรักษาตามปกติ


