RUK-COM / DDOS PROTECTION

ป้องกัน DDoS
ให้ลูกค้ายังใช้งานได้

Ruk-Com ดูแลการป้องกัน DDoS ตั้งแต่ Network ไปจนถึง Web และ API ด้วย VACUUM Scrubbing และ Policy สำหรับ L3–L7 ช่วยกรอง Attack Traffic ก่อนถึงระบบของคุณ พร้อมทีม Network และ Security คอยดูแล

ปรึกษาทีมเรื่อง DDoS ↗ดู Traffic Flow ↓
L3 · L4 · L7Reflection / AmplificationManaged policy
VACUUM / SCRUBBING CAPACITY
950Gbps

DDoS Scrubbing
กรอง Attack Traffic ก่อนถึง Server

InternetAllowed + Attack
VACUUMตรวจและกรอง
WorkloadTraffic ที่อนุญาต

950 Gbps คือ Scrubbing Capacity ไม่ใช่ Bandwidth ต่อ Server หรือต่อลูกค้า

PROTECT THE PATH

กรอง DDoS ก่อน
ที่ Uplink จะเต็ม

ถ้า DDoS ทำให้ Uplink เต็ม ลูกค้าก็เข้าใช้งานไม่ได้ แม้ Server ยังทำงานปกติ เราจึงวาง Scrubbing ไว้ก่อนถึง Uplink เพื่อกรอง Attack Traffic แล้วส่งต่อ Traffic ที่ผ่านการตรวจไปยัง Server

PROTECTION OVERVIEW

Traffic ผ่านอะไรบ้าง ก่อนถึง Server

ภาพอธิบายระบบ
ผู้ใช้งานจริงUpstream ScrubbingProtected LinkWorkload
Attack TrafficVACUUM ScrubbingDrop / Rate Control
Scrubbing Eventsทีม Network & Securityปรับ Policy

เส้น Response แสดงการตอบกลับจาก Server ไปยังผู้ใช้ ส่วน Routing จริงขึ้นอยู่กับการติดตั้ง

Allowed inputAttack / DropClean deliveryResponseTelemetryPolicy / Challenge

VACUUM ตรวจ Traffic ขาเข้า แล้ว Drop หรือจำกัด Attack Traffic ตาม Policy ส่วน Traffic ที่ผ่านการตรวจจะส่งต่อไปยัง Server ทีม Network และ Security ใช้ข้อมูลเหตุการณ์เพื่อติดตามผลและปรับ Rule

Diagram จำลองการทำงานของระบบ ตำแหน่งอุปกรณ์และ Routing จริงขึ้นอยู่กับการติดตั้ง

ภาพจำลองการทำงาน ไม่ได้ส่ง Traffic หรือสร้างการโจมตีจริง

ทีมจะตรวจทั้ง Scrubbing, Uplink และ Server เพื่อหาจุดคอขวด พร้อมวาง Routing และ Bandwidth ให้เหมาะกับปริมาณใช้งานจริงของคุณ

VACUUM / REFLECTION & AMPLIFICATION

Amplification Attack
ส่ง Request น้อย แต่โจมตีได้หนัก

ผู้โจมตีปลอม Source IP เป็น IP ของเหยื่อ แล้วส่ง Request ไปยังบริการภายนอก เช่น DNS หรือ NTP บริการเหล่านี้จึงส่ง Response กลับไปหาเหยื่อแทน หาก Response ใหญ่กว่า Request และมาจากหลายแหล่งพร้อมกัน ก็อาจทำให้ Uplink เต็มได้

VACUUM ตรวจจับรูปแบบของ Reflected Traffic และกรองตาม Policy ก่อนถึง Uplink ของคุณ ทีมจะปรับ Rule ให้ตรงกับการโจมตีและ Protocol ที่ระบบใช้งาน

01
ปลอม Source IP

ใช้ IP ของเหยื่อเป็น Source IP ใน Request

02
Reflector ส่ง Response กลับ

Response ที่ใหญ่กว่าถูกส่งไปยัง IP ของเหยื่อ

03
VACUUM กรอง Attack Traffic

Drop Packet ที่ตรวจพบว่าเป็น Attack ก่อนถึง Uplink

DNS

DNS Resolver ที่ถูกใช้ส่ง Response ไปหาเหยื่อ

NTP

NTP Server ที่เปิดให้ใช้คำสั่งซึ่งตอบกลับข้อมูลขนาดใหญ่

SSDP

บริการ Discovery ที่เปิดสู่ Internet

CLDAP

Directory Service ที่ตอบ Request ผ่าน UDP

memcached

Cache Server ที่เปิด UDP ให้เข้าถึงจาก Internet

Protocol เหล่านี้อาจถูกใช้เป็น Reflector ได้ ขนาดของ Response ขึ้นอยู่กับ Request และการตั้งค่าของแต่ละระบบ

EXPLORE THE MITIGATION

ดูวิธีรับมือ DDoS
แต่ละรูปแบบ

เลือกประเภทการโจมตีเพื่อดูว่า Attack ถูกตรวจและหยุดที่จุดไหน และ Traffic ปกติเดินทางไปถึง Server อย่างไร

ATTACK SCENARIO

Request เล็ก แต่ Response ใหญ่

ภาพอธิบายระบบ
ผู้ใช้งานจริงUpstream ScrubbingProtected LinkWorkload
คำขอปลอม Source IPExternal ReflectorsVACUUM ScrubbingDrop
Scrubbing Eventsทีม Network & Securityปรับ Policy

เส้น Response แสดงการตอบกลับจาก Server ไปยังผู้ใช้ ส่วน Routing จริงขึ้นอยู่กับการติดตั้ง

Allowed inputAttack / DropClean deliveryResponseTelemetryPolicy / Challenge

ผู้โจมตีปลอม IP ของเหยื่อใน Request แล้วส่งไปยัง External Reflector เมื่อ Reflector ส่ง Response กลับมาหาเหยื่อ VACUUM จะตรวจและ Drop Attack Traffic ตาม Policy ก่อนถึง Uplink

ขนาด Packet ในภาพใช้ประกอบคำอธิบาย ไม่ใช่อัตรา Amplification จริงของแต่ละ Protocol

ภาพจำลองการทำงาน ไม่ได้ส่ง Traffic หรือสร้างการโจมตีจริง

Scrubbing ต่างจาก Blackhole อย่างไร?

Scrubbing กรอง Attack Traffic แล้วส่งต่อ Traffic ที่ผ่านการตรวจ ส่วน Blackhole จะ Drop Traffic ทั้งหมดที่ส่งไปยัง IP เป้าหมาย รวมถึง Traffic ของลูกค้าจริงด้วย

MORE THAN A BANDWIDTH NUMBER

DDoS ไม่ได้วัด
แค่ Gbps

บาง Attack ทำให้ Bandwidth เต็ม บาง Attack ส่ง Packet หรือเปิด Connection จำนวนมากจนระบบรับไม่ไหว ทีมจึงดูทั้ง bps, pps, cps และ rps เพื่อเลือกวิธีป้องกันให้ตรงกับปัญหา

bps

Bits per second

ปริมาณข้อมูลที่วิ่งผ่าน Network ต่อวินาที ใช้ดูว่า Attack กิน Bandwidth มากแค่ไหน

pps

Packets per second

จำนวน Packet ต่อวินาที Packet เล็กจำนวนมากก็ทำให้อุปกรณ์ Network ทำงานหนักได้ แม้ Bandwidth ยังไม่เต็ม

cps

Connections per second

จำนวน Connection ใหม่ต่อวินาที ใช้ดูร่วมกับ Session ที่เปิดค้างและจำนวนที่ Server รองรับ

rps

HTTP requests per second

จำนวน HTTP Request ต่อวินาที ต้องดูด้วยว่าแต่ละ Endpoint ใช้ CPU, Memory หรือ Database มากแค่ไหน

950 Gbps เป็นค่า Scrubbing Capacity ส่วน pps, cps, rps และ Bandwidth สำหรับระบบของคุณต้องประเมินแยกกัน

L3–L7 / LAYERED BY DESIGN

ป้องกันทั้ง Network
Connection และ Application

แต่ละ Layer ต้องใช้วิธีตรวจต่างกัน Network Scrubbing ช่วยกรอง Packet และ Flood ส่วนการป้องกัน L7 จะดู HTTP Request เพิ่มเติม เพื่อให้เลือก Rule ได้ตรงกับ Web, API หรือบริการที่คุณเปิดใช้งาน

01L3 / VOLUME

กรอง Flood ก่อน Uplink เต็ม

UDP/ICMP Flood และ Reflected Traffic อาจใช้ Bandwidth จนลูกค้าเข้าไม่ถึงระบบ การทำ Upstream Scrubbing ช่วยกรอง Attack ก่อนถึง Uplink ของ Server

Source / Destination · Protocol · Traffic pattern
CONTROL PATH

Volumetric → Upstream Scrubbing → Drop / Clean delivery

การโจมตีหนึ่งรูปแบบอาจกระทบหลาย Layer ต้องดูพฤติกรรม Traffic ร่วมกับ Protocol
02L4 / CONNECTION

รับมือ SYN Flood และ Connection ล้น

SYN Flood และ UDP Flood อาจทำให้ระบบเสียทรัพยากรไปกับ Packet หรือ Connection ที่ผิดปกติ ทีมจะเลือกใช้ State Check, Rate Limit และ Allowlist ตามระบบที่ติดตั้ง

Protocol / State · Port · Connection rate
CONTROL PATH

TCP / UDP → Protocol inspection → Allow / Drop / Rate control

ทดสอบ Rule กับบริการจริง เช่น Game หรือ VPN โดยใช้การตรวจ Protocol และ Session สำหรับ TCP/UDP
03L7 / APPLICATION

ลด HTTP Flood ที่ทำให้ Web ช้า

HTTP Flood และ Slow HTTP ทำให้ Web Server หรือ Application ทำงานหนัก การตรวจ HTTPS ต้องผ่าน TLS Termination ที่เจ้าของระบบอนุญาตก่อน จึงจะดู Request และเลือก Rule ให้เหมาะกับแต่ละ Endpoint ได้

Path / Method · Request rate · Application context
CONTROL PATH

HTTPS → Network filtering → TLS → HTTP policy → Application

ใช้ Browser Challenge เฉพาะ Browser ที่รองรับ ส่วน API ใช้ Rate Limit, Authentication และ WAF Rule ที่เหมาะสม
เสริมการป้องกัน Web ด้วย Managed WAF

ให้ทีมช่วยดูแล WAF Rule ควบคู่กับ DDoS Protection เพื่อกรอง Request ที่พยายามโจมตีช่องโหว่ของ Web และลด False Positive

Managed WAF ↗
OPERATIONS / FROM SIGNAL TO ACTION

มีทีมช่วยวางแผน
และดูแลเมื่อถูกโจมตี

ทีม Ruk-Com เริ่มจากทำความเข้าใจ Traffic ปกติของคุณ วาง Rule ร่วมกัน และติดตามผลเมื่อเกิด Attack หลังปรับ Policy จะตรวจต่อว่าลูกค้ายังเข้าใช้งานได้และ Server ทำงานเป็นอย่างไร

01

ตรวจ Traffic ปกติ

เก็บข้อมูล IP, Port, Protocol, Peak Traffic และบริการสำคัญ

02

วาง Policy ร่วมกัน

กำหนด Threshold, Allowlist, ผู้อนุมัติ และช่องทางประสานงาน

03

วิเคราะห์และรับมือ Attack

ตรวจรูปแบบ Attack และจุดคอขวด แล้วเลือก Rule ที่ระบบรองรับ

04

เช็กว่าลูกค้าใช้งานได้

ตรวจการเข้าใช้งาน Error, Latency และ Load ของ Server หลังปรับ Rule

05

สรุปและปรับแผน

สรุปเหตุการณ์ มาตรการ ผลกระทบ และงานที่ต้องติดตาม

EVIDENCE THAT HELPS DECISIONS

รายงานว่าเจออะไร และแก้ไขอย่างไร

  • ช่วงเวลาที่เกิดเหตุและประเภท Attack ที่ตรวจพบ
  • Peak bps / pps และ Connection / HTTP rate ที่เกี่ยวข้อง
  • Rule ที่ปรับ พร้อมผลที่ตรวจพบหลังใช้งาน

ทีมจะตกลงรายละเอียดรายงานและระดับการดูแลกับคุณก่อนเริ่มบริการ

BUILT AROUND YOUR WORKLOAD

เลือกการป้องกันให้ตรงกับระบบของคุณ

Web, API, Game Server และระบบองค์กรมี Traffic ต่างกัน ทีมจะดูว่าระบบของคุณใช้งานอย่างไร ก่อนเลือก Rule และกำหนดข้อยกเว้นที่จำเป็น

Web & E-commerce

แยก HTTP Flood ออกจากช่วง Campaign และตรวจผลต่อ Checkout / Login

Managed WAF ↗

API & Business Platforms

ตรวจ Client, Authentication และ Endpoint ที่ใช้ทรัพยากรสูง โดยไม่บังคับ CAPTCHA กับ API

Cloud IaaS ↗

TCP / UDP Services

ปรับ Rule ให้ตรงกับ Port, Protocol และ Session ของ Game Server หรือ VPN

Cloud IaaS ↗

Enterprise Infrastructure

ประเมิน IP, Uplink, เส้นทางเข้าออก และการประสานกับ Network / SOC ขององค์กร

Colocation ↗
DESIGN THE RIGHT PROTECTION

คุยกับทีม Network
เพื่อวางแผนป้องกัน DDoS

ส่งผังระบบและข้อมูล Traffic มาให้ทีมช่วยดู Uplink, Routing และบริการที่ต้องป้องกัน เราจะเสนอแนวทาง L3–L7 พร้อมขอบเขตการดูแลที่เหมาะกับระบบของคุณ

ปรึกษาทีมผ่าน LINE ↗

ทีมจะแจ้งขอบเขตบริการ ราคา และเงื่อนไขให้ทราบก่อนเริ่มใช้งาน

ข้อมูลที่ช่วยให้ประเมินได้ตรงจุด

01
Public IP & Routing

IP/Prefix, ผู้ให้บริการเดิม และเส้นทางเข้าออกที่ใช้จริง

02
Traffic & Workload

Port/Protocol, Bandwidth ปกติ/Peak และบริการที่สำคัญ

03
HTTP & TLS

Domain, TLS Termination และข้อจำกัดของ Web/API Client

04
Incident & Operations

ประวัติ Attack, ผู้ประสานงาน, Change Window และแนวทาง Rollback

Ruk-Com Agent

ทุกบริการ มี Agent ช่วยดูแล

ดูแลร่วมกับทีมผู้เชี่ยวชาญ ทั้ง Technology และ Cyber Security ตั้งแต่ติดตามระบบ วิเคราะห์ความผิดปกติ ไปจนถึงช่วยวางแผนและประสานการแก้ไข

Technology · ประสิทธิภาพ ความจุ และการทำงานของระบบ

Cyber Security · ความเสี่ยง ช่องโหว่ และการเฝ้าระวังภัย

การเข้าถึงข้อมูล การลงมือแก้ไข และระดับการดูแล เป็นไปตามสิทธิ์และขอบเขตบริการที่ตกลงกับทีม

รู้จัก Ruk-Com Agent
BEFORE YOU START

คำถามที่พบบ่อย

950 Gbps หมายถึง Server ได้ Bandwidth 950 Gbps หรือไม่?
ไม่ใช่ครับ 950 Gbps คือ Scrubbing Capacity สำหรับกรอง Traffic ของบริการ ส่วน Bandwidth ที่ Server ของคุณได้รับเป็นไปตามแพ็กเกจและรูปแบบเชื่อมต่อที่ตกลงกับทีม
VACUUM ช่วยรับมือ Amplification อย่างไร?
VACUUM ตรวจ Reflected Traffic ที่ถูกส่งมายัง IP ของคุณ แล้ว Drop หรือจำกัด Traffic ที่ตรงกับ Attack Policy ก่อนถึง Uplink ส่วน Traffic ที่ผ่านการตรวจจะส่งต่อไปยังระบบ
มี Firewall บน Server แล้ว ยังจำเป็นหรือไม่?
ยังควรใช้ร่วมกันครับ Firewall บน Server ตรวจ Traffic ที่มาถึงเครื่องแล้ว แต่ถ้า Attack ทำให้ Uplink เต็ม ลูกค้าอาจเข้าไม่ถึง Server ตั้งแต่แรก Upstream Scrubbing จึงช่วยกรอง Attack ก่อนถึงจุดนั้น
L3/L4 Scrubbing อ่าน HTTPS ที่เข้ารหัสได้หรือไม่?
อ่าน HTTP Payload ที่ยังเข้ารหัสไม่ได้ครับ หากต้องการตรวจ Request ที่ Layer 7 ต้องมี Proxy หรือ WAF ที่รองรับ พร้อมทำ TLS Termination ในจุดที่เจ้าของระบบอนุญาต
Browser Challenge ใช้กับ API และ TCP/UDP ได้หรือไม่?
Browser Challenge ใช้กับ Browser ที่รองรับเท่านั้น สำหรับ API ควรใช้ Rate Limit และ Authentication ส่วน TCP/UDP เช่น Game หรือ VPN ต้องตรวจด้วย Rule ด้าน Protocol และ Session
ระหว่างการโจมตีจะไม่มีผลกระทบเลยหรือไม่?
ยังมีโอกาสได้รับผลกระทบครับ ขึ้นอยู่กับขนาดและรูปแบบ Attack รวมถึง Uplink, Routing และกำลังของ Server ทีมจะประเมินจุดคอขวด วาง Policy และติดตามการใช้งานจริง เพื่อลดผลกระทบต่อบริการ
เริ่มบริการและขอราคาอย่างไร?
ส่ง Public IP, Protocol, ข้อมูล Traffic และประวัติ Attack ให้ทีม Ruk-Com ได้เลย ทีมจะช่วยประเมินรูปแบบเชื่อมต่อ การป้องกัน L7 ที่จำเป็น และเสนอราคาให้คุณพิจารณาก่อนเริ่มบริการ
CAPACITY + CONTROL + CARE

ให้ทีม Ruk-Com
ช่วยดูแล DDoS Protection

VACUUM Scrubbing 950 Gbps พร้อมวางแผนป้องกัน L3–L7 ให้เหมาะกับ Network, Server และ Application ของคุณ

คุยกับทีม Ruk-Com ↗ดูการเฝ้าระวังกับ SOC Center ↗

แหล่งอ้างอิงหลักการทางเทคนิค: DDoS mitigation · Reflection / amplification · Application-layer DDoS

เอกสารประกอบคำอธิบายทางเทคนิค ไม่ได้ระบุว่า Ruk-Com ใช้ผลิตภัณฑ์หรือเป็น Partner ของผู้จัดทำเอกสาร