การจัดการบัญชีโซเชียลมีเดียหลายบัญชีผ่านพร็อกซี

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

เหตุใดลายเซ็น IP ที่ใช้ร่วมกันจึงกระตุ้นการเชื่อมโยงบัญชี

ทุกคำขอ HTTP จะมี IP ต้นทางกำกับไว้ แพลตฟอร์มจะบันทึก IP นี้ควบคู่กับ ID บัญชี คุกกี้เซสชัน และลายนิ้วมืออุปกรณ์ เมื่อบัญชีที่สองยืนยันตัวตนจาก IP เดียวกัน แพลตฟอร์มจะดำเนินการเชื่อมโยง IP ข้ามบัญชี ซึ่งไม่ใช่แค่การจับคู่สตริงธรรมดา — พวกเขาใช้การจัดกลุ่มซับเน็ต (/24 สำหรับ IPv4) การทับซ้อนของ ASN และความใกล้ชิดทางเวลา หากบัญชีสองบัญชีปรากฏจาก 203.0.113.0/24 เดียวกันภายในช่วง 24 ชั่วโมง คะแนนความเสี่ยงจะพุ่งสูงขึ้น IP ดาต้าเซ็นเตอร์เป็นอันตรายเป็นพิเศษ: 80% ของช่วง IP ดาต้าเซ็นเตอร์ถูกแจ้งธงภายใน 24 ชั่วโมงหลังการใช้งานครั้งแรกโดยทีมปราบปรามโซเชียลมีเดีย ตามข้อมูลจากฐานข้อมูลคุณภาพ IP เช่น ipqualityscore.com IP ที่อยู่อาศัยจากกลุ่ม ISP ดีกว่าเล็กน้อย แต่ก็ยังถูกจัดกลุ่มตาม ASN — บัญชีสองบัญชีที่ใช้ IP ต่างกันจาก ISP เดียวกันในเมืองเดียวกันก็ยังคงใช้คำนำหน้า BGP ร่วมกัน ซึ่งแพลตฟอร์มถือว่าเป็นจุดเชื่อมโยงที่อ่อน

โปรไฟล์การตรวจจับบนมือถือ ที่อยู่อาศัย และดาต้าเซ็นเตอร์

IP มือถือมาจากช่วง Carrier-Grade NAT (CGNAT) (RFC 6598) IP มือถือเดียวสามารถให้บริการผู้ใช้หลายพันคน — แพลตฟอร์มรู้เรื่องนี้และถือว่าการทับซ้อนของ IP มือถือเป็นสัญญาณรบกวน แต่นั่นไม่ได้ทำให้พร็อกซีมือถือปลอดภัย ผู้ให้บริการอย่าง T-Mobile หรือ Vodafone กำหนด IP จาก ASN ที่รู้จักกันดี และแพลตฟอร์มมีตารางชื่อเสียงต่อผู้ให้บริการ หากคุณกำหนดเส้นทางบัญชีทั้งหมดผ่านผู้ให้บริการมือถือรายเดียวกัน คุณยังคงใช้สัญญาณ ASN ร่วมกัน พร็อกซีที่อยู่อาศัยจาก ISP (Comcast, Deutsche Telekom) ให้ความเป็นนิรนามต่อ IP ที่ดีกว่า แต่กลุ่ม IP ของพวกเขามักถูกนำกลับมาใช้ใหม่เร็ว — IP พร็อกซีที่ใช้กับบัญชีหนึ่งวันนี้อาจถูกกำหนดให้กับผู้ใช้อื่นในวันพรุ่งนี้ ทำให้เซสชันขาดความต่อเนื่อง พร็อกซีดาต้าเซ็นเตอร์แย่ที่สุด: ราคาถูก เร็ว และถูกแจ้งธงทันที แพลตฟอร์มดำเนินการค้นหา whois และตรวจสอบระเบียน PTR; การย้อนกลับ DNS ที่ชี้ไปยัง server.provider.com คือธงแดงทันที สำหรับการตั้งค่าหลายบัญชีในระดับโปรดักชัน ให้ใช้พร็อกซีที่อยู่อาศัยหรือมือถือที่มี IP เฉพาะซึ่งไม่ถูกนำกลับมาใช้ข้ามบัญชี

เซสชันคงที่ต่อบัญชี — ความคงอยู่ของ IP เป็นสิ่งที่ไม่อาจต่อรองได้

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

function acct_request() {
  local account_id="$1"
  local proxy_ip="$2"
  local proxy_port="$3"
  local ua=$(shuf -n1 /path/to/user_agents.txt)
  curl --proxy "socks5://$proxy_ip:$proxy_port" \
       --proxy-user "user:pass" \
       -H "User-Agent: $ua" \
       --cookie "session_$account_id=..." \
       --cookie-jar "/tmp/cookies_$account_id.txt" \
       "https://platform.com/api/endpoint"
}

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

การแยกลายนิ้วมือเบราว์เซอร์ควบคู่กับการแยกพร็อกซี

IP เป็นเพียงมิติเดียว แพลตฟอร์มยังรวบรวมลายนิ้วมือ Canvas, WebGL Renderer, แบบอักษรที่ติดตั้ง, เขตเวลา และ navigator.hardwareConcurrency บัญชีสองบัญชีที่ใช้ลายนิ้วมือเบราว์เซอร์เดียวกันแต่ IP ต่างกันจะถูกเชื่อมโยงด้วยความมั่นใจสูง — ลายนิ้วมือมักจะคงที่กว่า IP คุณต้องแยกลายนิ้วมือต่อบัญชี ใช้โปรไฟล์เบราว์เซอร์แยก (Chrome --user-data-dir) หรือเบราว์เซอร์ไร้หัวพร้อมไลบรารีสุ่มลายนิ้วมือ เช่น puppeteer-extra-plugin-stealth ถึงอย่างนั้นก็ยังมีช่องโหว่เล็กน้อย: แฟล็ก navigator.webdriver, การมีอยู่ของ chrome.runtime และการรั่วไหลของ IP ท้องถิ่นผ่าน WebRTC ปิดการใช้งาน WebRTC ในเบราว์เซอร์หรือกำหนดเส้นทางผ่านพร็อกซีเดียวกัน ข้อผิดพลาดทั่วไปคือการใช้พร็อกซีที่อยู่อาศัยแต่เปิด WebRTC ทิ้งไว้ — เบราว์เซอร์จะรั่วไหล IP จริงผ่านคำขอ STUN ทำให้พร็อกซีไร้ผลทันที

ความเสี่ยงแบบลูกโซ่ของการระงับบัญชีจำนวนมาก

เมื่อบัญชีหนึ่งถูกแจ้งธงว่าเป็นสแปม ละเมิดนโยบาย หรือมีพฤติกรรมอัตโนมัติ แพลตฟอร์มจะไม่หยุดแค่บัญชีนั้น พวกเขาจะสแกนย้อนหลัง: บัญชีทั้งหมดที่เคยใช้ IP เดียวกัน ลายนิ้วมือเบราว์เซอร์เดียวกัน หรือแม้แต่รูปแบบการเข้าสู่ระบบเดียวกัน (เช่น กิจกรรมในช่วงเวลาเดียวกันของวัน) จะถูกจัดคิวเพื่อตรวจสอบ นี่คือการระงับบัญชีแบบลูกโซ่ IP พร็อกซีเดียวที่ถูกบุกรุกสามารถทำให้บัญชี 50 บัญชีล่มได้หากคุณใช้มันซ้ำ ยิ่งไปกว่านั้น แพลตฟอร์มแบ่งปันข้อมูลภัยคุกคาม — Facebook ThreatExchange ของ Meta และ reCAPTCHA Enterprise ของ Google แลกเปลี่ยนแฮชของ IP และลายนิ้วมือซึ่งกันและกัน IP ที่ถูกแจ้งธงบน Instagram สามารถกระตุ้นการระงับบน WhatsApp หรือ Facebook การป้องกันเพียงอย่างเดียวคือการแยกอย่างเข้มงวด: หนึ่ง IP หนึ่งลายนิ้วมือ หนึ่งบัญชี ไม่มีโครงสร้างพื้นฐานที่ใช้ร่วมกัน ใช้เครื่องเสมือนหรือคอนเทนเนอร์ Docker แยกกัน พร้อมการกำหนดค่าพร็อกซีและลายนิ้วมือต่อคอนเทนเนอร์ ตรวจสอบกลุ่มพร็อกซีของคุณทุกสัปดาห์เพื่อดูการขึ้นบัญชีดำ IP โดยใช้เครื่องมืออย่าง API virustotal หรือ ip-api.com — หาก IP ปรากฏในฐานข้อมูลการละเมิดใดๆ ให้เลิกใช้ทันทีและย้ายบัญชีไปยัง IP ใหม่ ต้นทุนของการระงับแบบลูกโซ่ครั้งเดียวสูงกว่าต้นทุนในการดูแลทรัพยากรพร็อกซีเฉพาะต่อบัญชีหลายเท่า