วิธีรับมือเมื่อได้รับอีเมลแจ้งเตือนการละเมิดนโยบาย VPS

ข้อร้องเรียนเรื่องการละเมิดนโยบาย VPS คืออะไร

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

ประกาศดังกล่าวไม่ใช่หลักฐานว่าคุณจงใจกระทำการใดๆ IP address เป็นเพียงตัวระบุเดียวที่ผู้รายงานมี แอปพลิเคชันที่ถูกบุกรุกและส่งสแปมในเวลา 03:00 น. จะสร้างรายงานฉบับเดียวกับที่มีคนส่งสแปมในเวลา 03:00 น. นี่คือเหตุผลว่าทำไมการตอบกลับจึงเป็นส่วนที่สำคัญที่สุด คุณกำลังถูกถามว่าแหล่งที่มาคืออะไรและคุณได้แก้ไขสิ่งใดไปแล้วบ้าง

ใครเป็นผู้ส่งรายงาน และรายงานมาถึงโฮสต์ของคุณได้อย่างไร

บล็อก IP สาธารณะทุกบล็อกจะถูกลงทะเบียนไว้กับหน่วยงานทะเบียนอินเทอร์เน็ตประจำภูมิภาค (RIR) ได้แก่ RIPE NCC, ARIN, APNIC, LACNIC หรือ AFRINIC การลงทะเบียนแต่ละรายการจะเผยแพร่ข้อมูลติดต่อสำหรับแจ้งเหตุละเมิด (abuse contact) ซึ่งเป็นจุดที่รายงานจะถูกส่งไป คุณสามารถอ่านบันทึกข้อมูลชุดเดียวกับที่ผู้รายงานอ่านได้:

whois 203.0.113.10 | grep -iE 'netname|descr|abuse'

บันทึกของ RIPE จะมีออบเจกต์ประเภท abuse-c: ซึ่งบรรจุบรรทัด abuse-mailbox: ไว้ ส่วนบันทึกของ ARIN จะมี OrgAbuseEmail: ไม่ว่าที่อยู่อีเมลใดที่ถูกเผยแพร่ไว้ ณ ที่นั้นจะเป็นผู้รับเรื่องร้องเรียน นี่คือเหตุผลว่าทำไมรายงานเกี่ยวกับเซิร์ฟเวอร์ของคุณจึงส่งมาถึงโฮสต์ของคุณแทนที่จะส่งมายังกล่องจดหมายของคุณโดยตรง

ฝ่ายที่ยื่นรายงานมักจะเป็นเครื่องจักร โดยมี 4 ประเภทที่ครอบคลุมเกือบทุกกรณีที่คุณจะพบ:

• เครื่องมือสแกนอัตโนมัติและ honeypot: เครื่องจักรจะบันทึกความพยายามเชื่อมต่อจาก IP ของคุณและยื่นรายงานพร้อมแนบตัวอย่าง log มาด้วย
• Feedback loops (FBL) ที่ดำเนินการโดยผู้ให้บริการกล่องจดหมาย: เมื่อผู้รับกดปุ่มทำเครื่องหมายว่าเป็นขยะ (junk) สำเนาของข้อความนั้นจะถูกส่งกลับมาในรูปแบบ ARF (abuse reporting format) ซึ่งเป็นรูปแบบอีเมลที่มีโครงสร้างสำหรับให้เครื่องจักรประมวลผล
• ตัวแทนด้านลิขสิทธิ์: ทำหน้าที่เฝ้าดูเครือข่าย torrent หรือรวบรวมข้อมูลจาก URL สาธารณะ จากนั้นจะส่งประกาศ DMCA (digital millennium copyright act) โดยระบุชื่อไฟล์, IP ของคุณ และเวลาที่เกิดเหตุในรูปแบบ UTC
• ผู้ดูแล blocklist และวิศวกรเครือข่าย: ซึ่งจะส่งอีเมลสั้นๆ พร้อมระบุบรรทัดที่พบการกระทำผิดจาก log ของพวกเขาเอง

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

เหตุใดการแจ้งเตือนจึงมีกำหนดเวลา

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

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

Outbound spam: ทำไม VPS ของฉันถึงส่งอีเมลที่ฉันไม่ได้เป็นคนส่ง

รายงานระบุว่า IP ของคุณส่งอีเมลไปยัง spam trap หรือผู้รับทำเครื่องหมายอีเมลของคุณว่าเป็นขยะ แหล่งที่มา 4 แห่งมักเป็นสาเหตุของกรณีส่วนใหญ่ ได้แก่ เว็บแอปพลิเคชันที่มีแบบฟอร์มส่งอีเมลแต่ไม่มีการจำกัดอัตรา (rate limit), ข้อมูลรับรอง SMTP ที่รั่วไหลและถูกผู้อื่นนำไปใช้, เมลเซิร์ฟเวอร์ที่ทำหน้าที่ relay ให้กับโฮสต์ที่ไม่ควรได้รับอนุญาต และการเข้าสู่ระบบที่ถูกขโมยในแอปพลิเคชันจดหมายข่าว ให้เริ่มตรวจสอบจากคิว (queue) เนื่องจากผู้ส่งที่ถูกบุกรุกมักจะปรากฏให้เห็นในนั้น:

sudo postqueue -p | tail -n 20
sudo postqueue -p | grep -c '^[0-9A-F]'

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

sudo grep -o 'sasl_username=[^ ]*' /var/log/mail.log | sort | uniq -c | sort -rn | head

บัญชีที่มีจำนวนการส่งสูงกว่าบัญชีอื่นอย่างผิดปกติคือบัญชีที่ข้อมูลรั่วไหล หาก /var/log/mail.log ไม่มีอยู่ แสดงว่าระบบไม่ได้ติดตั้ง rsyslog และบรรทัดเดียวกันจะอยู่ใน journal แทน: sudo journalctl -t postfix --since '2 days ago'

หากไม่มีการยืนยันตัวตน ผู้ส่งคือกระบวนการภายในเครื่อง (local process) ให้ตรวจสอบกฎการ relay และการเชื่อมต่อที่เปิดอยู่:

sudo postconf -n | grep -E 'mynetworks|inet_interfaces|relay'
sudo ss -tnp state established '( dport = :25 )'

Postfix บน Debian หรือ Ubuntu ที่ตั้งค่าตามมาตรฐานจะไม่ทำหน้าที่ relay ให้กับคนแปลกหน้า ระบบจะกลายเป็น open relay เมื่อ mynetworks ถูกแก้ไขด้วยตนเองให้ครอบคลุมทั้ง subnet ของโฮสติ้ง เนื่องจากผู้เช่ารายอื่นทั้งหมดใน subnet นั้นจะได้รับความไว้วางใจให้ส่งอีเมลผ่านคุณ การเชื่อมต่อใดๆ ไปยังพอร์ต 25 ที่เป็นของกระบวนการที่ไม่ใช่เมลเซิร์ฟเวอร์ของคุณ คือสคริปต์ที่กำลังส่งอีเมลด้วยตัวเอง ซึ่งเป็นสิ่งที่แอปพลิเคชัน PHP ที่ถูกบุกรุกมักจะทำ

หยุดการส่งอีเมลก่อนที่คุณจะเริ่มการตรวจสอบ และเก็บหลักฐานไว้:

sudo systemctl stop postfix
sudo tar czf /root/mailqueue.tgz -C /var/spool postfix

sudo postsuper -d ALL จะล้างคิวและทำลายบันทึกสิ่งที่ถูกส่งไป ดังนั้นให้คัดลอกข้อมูลไว้ก่อน จากนั้นให้หมุนเวียน (rotate) ข้อมูลรับรองทั้งหมดที่แอปพลิเคชันถืออยู่ อัปเดตแอปพลิเคชัน และค้นหาสิ่งที่ผู้บุกรุกทิ้งไว้ เหตุการณ์สแปมและการถูกบุกรุกมักเป็นเหตุการณ์เดียวกัน ดังนั้นให้ดำเนินการตาม ขั้นตอนการกู้คืนสำหรับ VPS ที่ถูกแฮ็ก แทนที่จะเพียงแค่ล้างคิวเท่านั้น

การสแกนพอร์ตและการโจมตีแบบ brute force: ลักษณะของคอนเทนเนอร์ที่ถูกบุกรุก

รายงานฉบับนี้แสดงบรรทัดจาก log ของผู้ดูแลระบบรายอื่น ซึ่งมีลักษณะดังนี้:

sshd[2841]: Invalid user admin from 203.0.113.10 port 51992

สาเหตุส่วนใหญ่มักเกิดจากบริการที่คุณเข้าใจว่าถูก firewall ป้องกันไว้แล้ว โดย Docker เป็นตัวการที่พบบ่อย การเผยแพร่พอร์ตด้วย -p 6379:6379 จะเขียนกฎลงใน chain DOCKER-USER และ nat ซึ่งกฎเหล่านี้จะถูกประมวลผลก่อนกฎของ ufw ดังนั้น ufw deny 6379 จึงไม่สามารถบล็อกการเชื่อมต่อได้ และฐานข้อมูลจะตอบสนองต่ออินเทอร์เน็ตทั้งหมด

sudo ss -ltnp
sudo iptables -S DOCKER-USER
docker ps

บริการใดก็ตามใน ss -ltnp ที่ผูกกับ 0.0.0.0 หรือ [::] จะเปิดรับการเชื่อมต่อบนที่อยู่สาธารณะ ให้เปลี่ยนไปเผยแพร่ที่ loopback address แทนด้วย -p 127.0.0.1:6379:6379 ในกรณีที่ต้องการให้เฉพาะโฮสต์เข้าถึงได้เท่านั้น ส่วนตำแหน่งที่ควรติดตั้งฐานข้อมูลนั้นเป็นการตัดสินใจแยกต่างหาก ซึ่งเนื้อหาเรื่อง การรันฐานข้อมูลใน Docker หรือบนโฮสต์ ได้ครอบคลุมข้อดีข้อเสียในส่วนนี้ไว้แล้ว

หากต้องการตรวจสอบว่าเซิร์ฟเวอร์ของคุณกำลังทำการสแกนอยู่หรือไม่:

sudo ss -tnp state syn-sent

การมีการเชื่อมต่อแบบ half-open จำนวนมากไปยังปลายทางที่แตกต่างกันหลายแห่ง คือสัญญาณว่ากำลังมีการสแกนขาออกเกิดขึ้น หาก log ของ kernel เต็มไปด้วย nf_conntrack: table full, dropping packet ก็แสดงถึงสิ่งเดียวกันในอีกมุมหนึ่ง นั่นคือมีบางอย่างกำลังเปิดการเชื่อมต่อจำนวนมากเกินกว่าที่เซิร์ฟเวอร์นี้ควรจะเป็น

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

ประกาศเรื่องลิขสิทธิ์: ไฟล์ที่ถูกตรวจพบจริงคือไฟล์ใด

ประกาศ DMCA จะระบุ URL หรือ info hash ของ torrent, IP ของคุณ และเวลาในรูปแบบ UTC สาเหตุหลักที่พบบ่อยเกือบทั้งหมดมี 2 ประการ คือ ไดเรกทอรีที่เว็บเซิร์ฟเวอร์เปิดให้เข้าถึงสาธารณะซึ่งมีไฟล์สื่ออยู่ภายใน และโปรแกรม torrent client ที่ยังคงทำหน้าที่ seeding หลังจากดาวน์โหลดเสร็จสิ้น

ให้ตรวจสอบเวลาในประกาศเทียบกับ access log โดยรูปแบบ log แบบ combined ของ nginx จะเก็บสถานะไว้ในฟิลด์ที่ 9 และ path ของคำขอไว้ในฟิลด์ที่ 7:

sudo grep '14/Aug/2026:03' /var/log/nginx/access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head

ก่อนจะสรุปว่าไม่มีการให้บริการไฟล์ดังกล่าว ให้ตรวจสอบเวลาของระบบก่อน ประกาศจะใช้เวลา UTC แต่ log ของคุณใช้เขตเวลาของเซิร์ฟเวอร์ ดังนั้นความคลาดเคลื่อนเพียงไม่กี่ชั่วโมงอาจทำให้คุณค้นหาในช่วงเวลาที่ผิดและได้ผลลัพธ์ที่เป็นเท็จ (false negative):

timedatectl
sudo timedatectl set-timezone UTC

จากนั้นให้แก้ไขที่ต้นเหตุ โดยการลบหรือจำกัดสิทธิ์การเข้าถึงไฟล์ ปิดการแสดงรายการไฟล์ในไดเรกทอรีด้วยคำสั่ง autoindex off; ในบล็อก location ของ nginx และตั้งค่าให้ torrent client เชื่อมต่อเฉพาะกับอินเทอร์เฟซที่ไม่ใช่เครือข่ายสาธารณะ จากนั้นให้ตอบกลับโดยระบุชื่อไฟล์ การเปลี่ยนแปลงที่ทำ และเวลาที่ดำเนินการ หากคุณเชื่อว่าข้อกล่าวหานั้นไม่ถูกต้อง นี่เป็นประเด็นทางกฎหมายระหว่างคุณกับผู้ส่งประกาศ ซึ่งในประกาศจะระบุวิธีโต้แย้งไว้ ผู้ให้บริการโฮสติ้งของคุณไม่ใช่ฝ่ายตัดสินข้อพิพาทนี้ ดังนั้นการเปิดตั๋วเพื่อโต้เถียงเรื่องความถูกต้องของข้อกล่าวหาจึงไม่ก่อให้เกิดผลใดๆ

รายการ Blocklist: เหตุใดอีเมลขาออกของฉันจึงหยุดทำงาน

ปัญหานี้มักเกิดขึ้นโดยที่คุณไม่ได้รับอีเมลแจ้งเตือนใดๆ เลย อีเมลขาออกจะถูกปฏิเสธโดยตรง และข้อความตีกลับ (bounce) จะระบุสาเหตุไว้ดังนี้:

554 5.7.1 Service unavailable; Client host [203.0.113.10] blocked using zen.spamhaus.org

ตรวจสอบรายการที่ถูกบล็อกโดยการสลับลำดับตัวเลข 4 ชุดของ IP (reverse) แล้วสอบถามไปยังโซนของรายการนั้น:

dig +short 10.113.0.203.zen.spamhaus.org

หากได้รับคำตอบว่างเปล่า หมายความว่า IP ของคุณไม่ได้อยู่ในรายการนั้น หากได้รับคำตอบเป็น 127.0.0.x หมายความว่าคุณติดรายการดังกล่าว โดยตัวเลขชุดสุดท้ายจะระบุว่าตรงกับ sublist ใด หากได้รับคำตอบในช่วง 127.255.255.x หมายความว่าคำขอถูกปฏิเสธแทนที่จะได้รับคำตอบ ซึ่งมักเกิดจากการส่งคำขอผ่าน public resolver ขนาดใหญ่ที่บริการฟรีเหล่านี้ไม่รองรับ ให้ลองรันคำสั่งใหม่อีกครั้งจาก resolver ของเซิร์ฟเวอร์เองเพื่อให้ได้ผลลัพธ์ที่ถูกต้อง

การถอดชื่อออกจากรายการ (delisting) ต้องดำเนินการผ่านเว็บไซต์ของผู้ให้บริการรายการนั้น ไม่ใช่ผ่านผู้ให้บริการโฮสต์ของคุณ และการถอดชื่อจะคงอยู่ได้ก็ต่อเมื่อแก้ไขต้นตอของปัญหาแล้วเท่านั้น เพราะระบบดักจับที่ขึ้นบัญชีคุณไว้จะนำคุณกลับเข้าสู่รายการอีกครั้งหากพบข้อความที่เข้าข่ายเดิม มีอีกสองปัจจัยที่กำหนดว่าอีเมลจะส่งออกได้หรือไม่หลังจากนั้น คือ PTR record หรือชื่อ reverse DNS ของ IP ซึ่งควบคุมโดยผู้ให้บริการโฮสต์ของคุณ ดังนั้นควรขอให้พวกเขาตั้งค่า PTR ให้ชี้กลับมาที่ IP เดิม และใช้ชื่อนั้นเป็น HELO ของคุณ นอกจากนี้ IP ที่นำกลับมาใช้ใหม่จากผู้เช่ารายก่อนหน้าอาจมีประวัติที่คุณไม่ได้เป็นผู้ก่อ ซึ่งควรสอบถามผู้ให้บริการก่อนที่คุณจะเสียเวลาแก้ไข DNS เป็นสัปดาห์ สำหรับการตั้งค่า SPF (sender policy framework) และ DKIM (domainkeys identified mail) ให้ถูกต้อง รวมถึงนโยบาย DMARC ที่เชื่อมโยงทั้งสองอย่างเข้าด้วยกัน สามารถดูรายละเอียดทั้งหมดได้ใน คู่มือการรันเซิร์ฟเวอร์อีเมลด้วยตนเองโดยใช้ Mailcow

โครงสร้างพื้นฐานสำหรับการส่งต่อข้อมูล (Relay) ที่ต้องรับมือกับอีเมลร้องเรียนการละเมิดเป็นเรื่องปกติ

หากคุณใช้งาน Tor exit node, บริการ VPN สาธารณะ หรือพร็อกซีสำหรับผู้อื่น การได้รับข้อร้องเรียนเกี่ยวกับทราฟฟิกที่คุณไม่ได้เป็นผู้สร้างขึ้นถือเป็นต้นทุนการดำเนินงานตามปกติ สิ่งสำคัญคือการทำให้ระบบของคุณดูเหมือนเป็น relay อย่างชัดเจน แทนที่จะดูเหมือนเซิร์ฟเวอร์ที่ถูกบุกรุก ให้ตั้งค่า reverse DNS เป็นชื่อที่สื่อความหมาย เปิดหน้าเพจแจ้งเตือนสั้นๆ บนพอร์ต 80 เพื่ออธิบายว่าที่อยู่นี้คืออะไร ตอบกลับอีเมลร้องเรียนการละเมิดอย่างรวดเร็วด้วยคำอธิบายเดียวกัน และใช้ทุกนโยบายที่ซอฟต์แวร์รองรับเพื่อปิดกั้นพอร์ตที่สร้างรายงานเข้ามามากที่สุด ควรใช้งานบน IP address ของตนเอง และถ้าเป็นไปได้ควรแยก instance ออกมาต่างหาก เพื่อไม่ให้การ null route ที่ IP นั้นส่งผลกระทบต่อแอปพลิเคชันเว็บของคุณ ให้สอบถามผู้ให้บริการโฮสต์ก่อนเริ่มใช้งาน เนื่องจากสิ่งที่อนุญาตจะแตกต่างกันไปตามแต่ละบริษัทและบางครั้งขึ้นอยู่กับบล็อกของ IP ซึ่งเป็นคำถามที่ควรปรึกษาผู้ให้บริการโดยตรงมากกว่าการตั้งกระทู้ในฟอรัม การใช้งาน Tor exit node บน VPS จะอธิบายรายละเอียดเกี่ยวกับนโยบายการออก (exit policy) และหน้าเพจแจ้งเตือนไว้อย่างครบถ้วน

วิธีตอบกลับเพื่อให้ปิดตั๋วได้

• เผยแพร่ช่องทางติดต่อที่คนอ่านได้จริง RFC 2142 กำหนดให้ abuse@ และ postmaster@ บนโดเมนของคุณเป็นที่อยู่ที่ผู้รายงานจะลองติดต่อเป็นอันดับแรก ควรโฮสต์กล่องจดหมายนั้นไว้ที่อื่นที่ไม่ใช่เซิร์ฟเวอร์ที่กำลังดูแลอยู่ เพราะหากอินสแตนซ์ถูกระงับการใช้งาน คุณจะไม่สามารถรับการแจ้งเตือนที่ระบุว่าเซิร์ฟเวอร์ของคุณถูกระงับได้
• เก็บรักษา log ให้นานพอที่จะตอบคำถามได้ รายงานเกี่ยวกับ traffic เมื่อ 12 วันก่อนจะไม่สามารถตอบได้หาก log ถูกหมุนเวียน (rotate) ไปหลังจาก 7 วัน ให้ตรวจสอบ journalctl --disk-usage ตั้งค่า MaxRetentionSec=90d ใน /etc/systemd/journald.conf แล้วรัน sudo systemctl restart systemd-journald ส่วน log ของเว็บและเมลจะหมุนเวียนตามกำหนดการของตัวเองภายใต้ /etc/logrotate.d/
• ตั้งค่าเซิร์ฟเวอร์ให้เป็นเวลา UTC เพื่อให้ timestamp ในรายงานตรงกับ timestamp ใน log ของคุณโดยไม่ต้องคำนวณเวลาชดเชย
• แยกสิ่งที่อาจก่อให้เกิดข้อร้องเรียนออกจากสิ่งที่สำคัญและสูญเสียไม่ได้ เช่น ใช้ที่อยู่เมลหนึ่งสำหรับงานหนึ่ง แอปพลิเคชันเว็บอีกที่หนึ่ง และบริการ relay บนอินสแตนซ์แยกต่างหาก การดำเนินการใดๆ ต่อ IP หนึ่งหมายถึงการดำเนินการต่อทุกบริการที่อยู่เบื้องหลัง IP นั้น
• ตอบกลับภายในกรอบเวลาที่กำหนดแม้การตรวจสอบจะยังไม่เสร็จสิ้น การตอบกลับเบื้องต้นพร้อมระบุเวลาที่จะดำเนินการต่อถือเป็นการตอบกลับที่สมบูรณ์สำหรับการโต้ตอบรอบแรก

การตอบกลับครั้งแรกที่ช่วยปิดตั๋วส่วนใหญ่ได้คือการตอบที่สั้นและตรงประเด็น:

Received, thank you. Confirmed at 09:14 UTC.
Source: a contact form in our web app that allowed unauthenticated sending.
Action: form disabled, Postfix stopped, all SMTP credentials rotated 09:31 UTC.
Evidence: mail queue and logs preserved for 90 days if you need them.
Next: patched app redeployed by 18:00 UTC today. I will confirm here.

ระบุสิ่งที่คุณทราบ และระบุสิ่งที่คุณยังตรวจสอบไม่เสร็จสิ้น การนิ่งเฉยถูกตีความว่าเซิร์ฟเวอร์ไม่มีการดูแลรักษา และกระบวนการยกระดับปัญหา (escalation path) จะถูกนำมาใช้กับเซิร์ฟเวอร์ที่ไม่มีการดูแลรักษา ส่วนงานเหล่านี้จะเป็นหน้าที่ของคุณหรือไม่นั้นขึ้นอยู่กับผลิตภัณฑ์ที่คุณซื้อ ซึ่งเป็นความแตกต่างในทางปฏิบัติ ระหว่างการโฮสต์ VPS แบบ managed และ unmanaged สำหรับแผนแบบ unmanaged ผู้เช่าคือทีมรักษาความปลอดภัยของตนเอง

ลักษณะของเหตุการณ์เมื่อทุกอย่างดำเนินไปได้ด้วยดี

ข้อร้องเรียนเรื่องการละเมิดเป็นปัญหาด้านการกำหนดเส้นทาง (routing) ก่อนที่จะเป็นปัญหาในด้านอื่น รายงานเกี่ยวกับที่อยู่ IP จะถูกส่งไปยังผู้รับผิดชอบที่อยู่นั้น และจะถูกส่งต่อไปยังผู้ที่สามารถแก้ไขปัญหาได้ สิ่งที่คุณควบคุมได้คือที่อยู่อีเมลสำหรับติดต่อ, ระยะเวลาการเก็บรักษา log, การแบ่งบริการของคุณออกตาม IP ต่างๆ และความรวดเร็วในการตอบกลับ หากคุณจัดการสิ่งเหล่านี้ได้ถูกต้อง ข้อร้องเรียนส่วนใหญ่จะจบลงหลังจากการโต้ตอบเพียงครั้งเดียว นิสัยเหล่านี้ยังช่วยตอบคำถามในภาพรวมที่ว่า VPS hosting ปลอดภัยหรือไม่ เพราะเซิร์ฟเวอร์ที่ไม่มีใครคอยเฝ้าดูคือเซิร์ฟเวอร์ที่จะไปปรากฏอยู่ใน log ของผู้อื่นในท้ายที่สุด

FAQ

การได้รับแจ้งเรื่องการละเมิดหมายความว่า VPS ของฉันถูกแฮ็กหรือไม่?

ไม่จำเป็นเสมอไป แต่เป็นสิ่งแรกที่ต้องตรวจสอบให้แน่ชัด รายงานดังกล่าวพิสูจน์เพียงว่ามีทราฟฟิกออกจาก IP ของคุณเท่านั้น การส่งสแปมหรือการสแกนพอร์ตจากภายนอกมักเกิดจากแอปพลิเคชันหรือคอนเทนเนอร์ที่ถูกบุกรุกมากกว่าเกิดจากตัวเจ้าของบัญชีเอง ดังนั้นควรตรวจสอบคิวอีเมลด้วย sudo postqueue -p และตรวจสอบซ็อกเก็ตที่กำลังฟังอยู่ด้วย sudo ss -ltnp ก่อนดำเนินการอื่นใด ส่วนประกาศเรื่องลิขสิทธิ์และบัญชีดำ (blocklist) มีลักษณะที่แตกต่างออกไป โดยมักจะชี้ไปที่สิ่งที่รันอยู่บนเซิร์ฟเวอร์ของคุณโดยเจตนา

ฉันมีเวลาเท่าไรในการตอบกลับประกาศเรื่องการละเมิด?

ระยะเวลาจะระบุไว้ในประกาศที่คุณได้รับ ซึ่งจะแตกต่างกันไปตามผู้ให้บริการและประเภทของปัญหา รายงานเรื่องลิขสิทธิ์และกับดักสแปม (spam-trap) มักจะมีกำหนดเวลาที่สั้นที่สุด ให้ถือว่าระยะเวลาที่ระบุนั้นเป็นเรื่องจริง และควรส่งข้อความตอบกลับสั้นๆ เพื่อยืนยันว่าได้รับทราบแล้วก่อนที่เวลาจะหมดลง แม้ว่าคุณจะยังอยู่ในระหว่างการสืบหาต้นตอของปัญหาอยู่ก็ตาม สิ่งที่สำคัญสำหรับเจ้าหน้าที่ที่ดูแลตั๋วของคุณคือการทราบว่ามีคนกำลังจัดการปัญหานี้อยู่และทราฟฟิกที่เป็นปัญหาได้หยุดลงแล้ว

IP ของฉันติดอยู่ในบัญชีดำ (blocklist) ผู้ให้บริการของฉันสามารถนำออกให้ได้หรือไม่?

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

ฉันจำเป็นต้องบอกผู้ให้บริการหรือไม่ว่าเกิดอะไรขึ้นจริงๆ?

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

ฉันสามารถเพิกเฉยต่อรายงานอัตโนมัติจากเครื่องมือสแกนได้หรือไม่?

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