ให้คะแนน จำกัด * un * - การร้องขอที่ตรวจสอบสิทธิ์

11

สมมติว่าเรามี load balancer ที่ จำกัด อัตรา การ จำกัด อัตราดูเหมือนตรงไปตรงมามากสำหรับผู้ใช้ที่เข้าสู่ระบบ - เพียงแค่ดูที่ JWT และอาจใช้ร้านค้าในหน่วยความจำเพื่อดูจำนวนคำขอใน 10 วินาทีสุดท้ายสำหรับผู้ใช้นั้น

อย่างไรก็ตามสิ่งที่เกี่ยวกับผู้ใช้ที่ไม่ได้เข้าสู่ระบบ (ไม่ได้ตรวจสอบ) เราไม่ทราบแน่ชัดว่าพวกเขาหรือใครมาจากที่ใดดังนั้นจึงไม่สามารถ จำกัด อัตราคำขอเหล่านั้นหรือ ..

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

ฉันเดา / หวังว่าอาจมีกลไกในตัวสำหรับการ จำกัด อัตราคำขอที่ไม่ได้รับอนุญาตบนแพลตฟอร์มโฮสติ้งโปรดแจ้งให้เราทราบ

load-balancing nginx rate-limiting

2

หน้านี้ไม่กล่าวถึงผู้ใช้ที่เข้าสู่ระบบ ในความเป็นจริงเทคนิคที่อธิบายไว้มีการอ้างถึงเป็นการบรรเทาการโจมตีด้วยเดรัจฉาน - พลังในรหัสผ่านซึ่งหมายถึงผู้ใช้ที่ไม่ได้เข้าสู่ระบบ

— Robert Harvey

1

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

— Bart van Ingen Schenau

1

คำถามนี้อาจเหมาะกว่าสำหรับsecurity.stackexchange.comแต่ฉันไม่ได้บอกว่ามันเป็นนอกหัวข้อ

— Peeyush Kushwaha

@BartvanIngenSchenau ถูกทุกข้อ?

ทำไมคุณควรมีขีด จำกัด อัตราต่างกันสองข้อ คุณขาย "แผน" ประเภทใดที่มีข้อ จำกัด / คุณสมบัติแตกต่างกันหรือไม่?

— Laiv

9

อย่างไรก็ตามสิ่งที่เกี่ยวกับผู้ใช้ที่ไม่ได้เข้าสู่ระบบ (ไม่ได้ตรวจสอบ) เราไม่ทราบแน่ชัดว่าพวกเขาหรือใครมาจากที่ใดดังนั้นจึงไม่สามารถ จำกัด อัตราคำขอเหล่านั้นหรือ ..

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

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

— โกหกไรอัน
แหล่งที่มา

ฉันไม่เห็นวิธี "หลักฐานการทำงาน" ที่สามารถป้องกันการโจมตีจาก DOS ได้อย่างไร ลูกค้าสามารถเพิกเฉยต่อความท้าทายและส่งคำขอถึงความล้มเหลว มีกระบวนการที่ 3 ในการจัดการกับความท้าทายหรือไม่?

— Laiv

4

@Laiv POW สามารถออกและตรวจสอบกระจายได้อย่างน่าเชื่อถือโดยไม่ต้องเชื่อมต่อกับฐานข้อมูลกลางซึ่งเป็นที่ที่แผนการ จำกัด อัตราอื่น ๆ ส่วนใหญ่ล้มเหลว มันเพิ่มค่าใช้จ่ายของการโจมตีสำหรับผู้โจมตีเนื่องจากการขยายการป้องกันของคุณและการเพิ่มปัจจัยการโหลดนั้นมีราคาถูกสำหรับคุณและผู้ใช้ที่ถูกกฎหมายมากกว่าการลดขนาดการโจมตีของผู้โจมตี มันสร้างความไม่ประหยัดทางเศรษฐกิจในการโจมตีระบบเนื่องจากยังไม่รวมอุปกรณ์ที่มีกำลังไฟต่ำ (เช่นเครื่องพิมพ์ที่ถูกบุกรุก IOT และเราเตอร์) ที่ถูกบุกรุกเพื่อใช้เป็นแพลตฟอร์มการโจมตีที่มีประสิทธิภาพ

— โกหกไรอัน

6

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

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

นอกจากนี้ตามกฎทั่วไปคุณไม่ควรสันนิษฐานว่าการโจมตีนั้นไม่ได้มาจากผู้ใช้ที่ได้รับการรับรองความถูกต้องอย่างน้อยก็สำหรับสิ่งที่เกี่ยวข้องกับการโจมตีของ DOS รหัสผ่านที่ไม่รัดกุมช่วยให้ใครบางคนสามารถเข้าใจตัวตนของผู้ใช้เก่าได้ง่าย ดังนั้นหากคุณสามารถทำการตรวจสอบดังกล่าวได้ผู้ใช้ (คน) ของคุณไม่ควรต้องดำเนินการตามคำขอในอัตราดังกล่าวโดยไม่ต้องทนใช้เพียงเพราะคุณมีผู้ใช้หลายคน

— นีล
แหล่งที่มา

ฉันคิดว่าคุณสามารถใช้ที่อยู่ IP และตั้งค่าขีด จำกัด อัตราสูงสำหรับแต่ละรายการได้ ฉันเดาว่าการโจมตี DoS ที่จัดการอย่างดีสามารถใช้ที่อยู่ IP หลายพันรายการได้หรือไม่ อาจจะมากกว่านี้? idk ... ฉันทราบว่าสามารถใช้ที่อยู่ IP เดียวกันนี้ได้สำหรับลูกค้าหลายราย แต่ฉันอยากจะบอกว่ามีความเป็นไปได้สูงที่จะเป็นผู้ใช้เดียวกันใช่ไหม

— Alexander Mills

@AlexanderMills สมมติว่าคุณตัดสินใจว่า algoritihm จะตรวจสอบคำขอหลายรายการจากที่อยู่ IP เดียวกัน แม้ว่าจะมีหลายพันรายการ แต่ก็จะมีการทำซ้ำมากกว่า 1,000 คำขอ เซิร์ฟเวอร์ของคุณบันทึกคำขอแรกจากที่อยู่ IP ที่กำหนดและน้ำท่วมเริ่มต้นขึ้น .. เซิร์ฟเวอร์ของคุณถูก backlogged แล้วพร้อมกับคำขอ .. คุณไม่สามารถดำเนินการตามคำขอได้มากพอที่จะได้รับการทำซ้ำครั้งที่สองจาก IP เดียวกัน (ซึ่งอาจเป็นคำขอที่ถูกต้อง ยังไงซะ). มันจะป้องกันการโจมตี DoS ที่ใช้ IP เดียวกันเท่านั้น ดีกว่าที่จะใช้ทั้งถ้ามีอะไร : P

— Neil

0

หนึ่งในข้อเสนอหลักของ Cloudflareคือการป้องกันการโจมตี Denial of Service โดยการจัดหาพรอกซีอัจฉริยะสำหรับ API / เว็บเซิร์ฟเวอร์ของคุณ บริการพื้นฐานฟรี; พวกเขาทำเงินจากบริการอื่น ๆ ที่เกี่ยวข้องเช่นบริการ CDN และการทำโหลดบาลานซ์ พวกเขายังให้บริการการจำกัด อัตราที่ซับซ้อนและควบคุมได้มากขึ้นซึ่งปัจจุบันอยู่ที่ 0.05 เหรียญสหรัฐต่อคำขอ 10k ที่ดี (ไม่มีค่าใช้จ่ายสำหรับคำขอที่ถูกปฏิเสธ) แต่คุณต้องอัปเกรดเป็นแผนชำระเงินเพื่อรับกฎระดับโลกมากกว่าหนึ่งกฎ

คุณสามารถใช้บริการของ Cloudflare กับ AWS หรือแพลตฟอร์มอื่น ๆ ตราบใดที่คุณมีการควบคุมเซิร์ฟเวอร์ชื่อโดเมนของคุณ (ในคุณสามารถเปลี่ยนเซิร์ฟเวอร์ชื่อที่ลงทะเบียนสำหรับโดเมนของคุณ)

คุณสามารถระบุอัตรา จำกัด ที่แยกต่างหากสำหรับผู้ใช้ที่ไม่ระบุชื่อและที่ลงชื่อเข้าใช้โดยกำหนดผู้ใช้ที่ลงชื่อเข้าใช้ไปยัง URL อื่น ตัวอย่างเช่นคุณอาจนำหน้าเส้นทาง URL ที่ไม่ระบุชื่อทั้งหมดด้วย '/ u' เพื่อสร้างจุดสิ้นสุดที่ต้องใช้การรับรองความถูกต้องและมีอัตรา จำกัด ที่แตกต่างกัน

โปรดทราบว่าการ จำกัด อัตราของ Cloudflare (เช่นการ จำกัด อัตราเชิงพาณิชย์สำหรับผู้ใช้ที่ไม่ระบุตัวตนที่ฉันทราบ) กำหนดลูกค้าด้วยที่อยู่ IP สิ่งนี้อาจทำให้เกิดปัญหากับคนที่ใช้ VPN เชิงพาณิชย์หรือ Tor เนื่องจากมีแนวโน้มที่จะซ่อนลูกค้าจำนวนมากที่อยู่เบื้องหลัง 1 ที่อยู่ IP เพื่อเพิ่มความเป็นส่วนตัว

— โปรเก่า
แหล่งที่มา

0

ใน AWS มีการให้บริการที่เกี่ยวข้องAWS โล่และ AWS WAF พวกเขามีวัตถุประสงค์หลักเพื่อป้องกันการโจมตี DDoS แต่ยังให้การสนับสนุนการ จำกัด อัตราตามที่อยู่ IP

ใน WAF แนวคิดที่เรียกว่าอัตราตามกฎ การป้องกันการพยายามลงชื่อเข้าใช้แบบ brute-force นั้นเป็นกรณีการใช้งานในการประกาศดั้งเดิม :

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

ผู้ให้บริการคลาวด์อื่นควรมีข้อเสนอที่คล้ายกัน นี่คือการเปรียบเทียบตาราง: Google Cloud เกราะกับ AWS WAF กับ Cloudflare WAF

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

โปรดทราบว่าการ จำกัด อัตราตาม IP เป็นแนวคิดที่ค่อนข้างง่าย แต่ไม่สมบูรณ์:

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

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

— Philipp Claßen
แหล่งที่มา