ज्या दिवशी आम्ही आमची साइनअप पाइपलाइन सुधारली
आमचे साइनअपचे आकडे दर आठवड्याला वाढत होते. टीममध्ये उत्साह होता. पण डेटा काहीतरी चुकीचा वाटत होता. वापरकर्ते कधीच परत येत नव्हते. ईमेल पत्ते विचित्र दिसत होते. आमचा ॲक्टिव्हेशन रेट (activation rate) कमी झाला होता.
मी डेटा तपासला. मला त्यात वाढ दिसली नाही. मला फक्त गोंधळ (noise) दिसला.
समस्या
मी आयपी (IP) पत्त्यानुसार साइनअप गटबद्ध करण्यासाठी एक क्वेरी (query) चालवली. एकाच आयपी पत्त्यावरून २४ तासांत शेकडो खाती नोंदवली गेली होती. त्यासाठी एकाच 'ब्राउझर फिंगरप्रिंट'चा वापर केला जात होता. एक स्क्रिप्ट आमच्या 'रजिस्टर एंडपॉइंट'वर (register endpoint) वार करत होती. त्यासाठी तात्पुरते (throwaway) ईमेल डोमेन वापरले जात होते. तो एक बॉट (bot) होता, माणूस नाही.
आमची साइनअप पाइपलाइन पूर्णपणे उघडी होती.
उपाय
आम्ही एका स्प्रिंटमध्ये (sprint) संरक्षणाचे तीन स्तर तयार केले.
स्तर १: थ्रॉटलिंग (Throttling)
आम्ही दोन प्रकारचे रेट लिमिटिंग (rate limiting) वापरले.
- प्रति-आयपी थ्रॉटलिंग (Per-IP throttling): आम्ही एका ठराविक वेळेत एका आयपीवरून होणारे साइनअप प्रयत्न मर्यादित करतो.
- प्रति-डोमेन थ्रॉटलिंग (Per-domain throttling): आम्ही एकाच ईमेल डोमेनवरून होणारे साइनअप एका लांब वेळेच्या मर्यादेत नियंत्रित करतो. यामुळे एकाच डोमेनचा वापर करून वेगवेगळ्या आयपीवरून येणारे बॉट्स थांबवता येतात.
स्तर २: ब्लॉकलिस्ट (Blocklists)
- ब्लॉक केलेले ईमेल डोमेन: आम्ही तात्पुरत्या (disposable) ईमेल डोमेनचा वापर करून केलेली कोणतीही नोंदणी नाकारतो.
- ब्लॉक केलेले युजर एजंट्स (User agents): आम्ही नॉन-ब्राउझर टूल्सकडून येणाऱ्या विनंत्या (requests) नाकारतो. आम्ही हल्लेखोराला कोणतीही माहिती देत नाही.
स्तर ३: आयपी ब्लॉकलिस्ट (IP Blocklist)
काही आयपी सतत त्रास देतात. ते आमच्या सिस्टमच्या अनेक भागांचा गैरवापर करतात. आम्ही एक 'हार्ड ब्लॉकलिस्ट' वापरतो. या आयपीवरून येणाऱ्या प्रत्येक विनंतीला नाकारले जाते. मिडिलवेअर (middleware) त्यांना त्वरित थांबवते.
निकाल
उपाय करण्यापूर्वी:
- एका आयपीने एका दिवसात शेकडो खाती तयार केली होती.
- बहुतेक साइनअप्स तात्पुरत्या डोमेनवरून झाले होते.
- बनावट खात्यांमुळे आमचा ॲक्टिव्हेशन रेट कमी झाला होता.
- आम