Variti போட்கள் மற்றும் DDoS தாக்குதல்களுக்கு எதிராக பாதுகாப்பை உருவாக்குகிறது, மேலும் மன அழுத்தம் மற்றும் சுமை சோதனைகளையும் நடத்துகிறது. HighLoad++ 2018 மாநாட்டில் பல்வேறு வகையான தாக்குதல்களிலிருந்து வளங்களை எவ்வாறு பாதுகாப்பது என்பது பற்றி பேசினோம். சுருக்கமாக: கணினியின் பகுதிகளை தனிமைப்படுத்தவும், கிளவுட் சேவைகள் மற்றும் CDNகளைப் பயன்படுத்தவும் மற்றும் தொடர்ந்து புதுப்பிக்கவும். ஆனால் சிறப்பு நிறுவனங்கள் இல்லாமல் நீங்கள் இன்னும் பாதுகாப்பைக் கையாள முடியாது :)
உரையைப் படிப்பதற்கு முன், நீங்கள் சுருக்கமான சுருக்கங்களைப் படிக்கலாம் .
நீங்கள் வீடியோவைப் படிக்க விரும்பவில்லை அல்லது பார்க்க விரும்பினால், எங்கள் அறிக்கையின் பதிவு கீழே ஸ்பாய்லரின் கீழ் உள்ளது.
அறிக்கையின் வீடியோ பதிவு
பல நிறுவனங்களுக்கு ஏற்கனவே சுமை சோதனை செய்வது எப்படி என்று தெரியும், ஆனால் அனைத்தும் ஸ்ட்ரெஸ் டெஸ்டிங் செய்வதில்லை. எங்கள் வாடிக்கையாளர்களில் சிலர் தங்கள் தளம் பாதிப்பில்லாதது என்று நினைக்கிறார்கள், ஏனெனில் அவர்களிடம் ஹைலோட் சிஸ்டம் உள்ளது, மேலும் இது தாக்குதல்களிலிருந்து நன்கு பாதுகாக்கிறது. இது முற்றிலும் உண்மையல்ல என்பதை நாங்கள் காட்டுகிறோம்.
நிச்சயமாக, சோதனைகளை நடத்துவதற்கு முன், நாங்கள் வாடிக்கையாளரிடமிருந்து அனுமதியைப் பெறுகிறோம், கையொப்பமிட்டு முத்திரையிடுகிறோம், மேலும் எங்கள் உதவியுடன் DDoS தாக்குதலை யாரும் மேற்கொள்ள முடியாது. வாடிக்கையாளரால் தேர்ந்தெடுக்கப்பட்ட நேரத்தில் சோதனை மேற்கொள்ளப்படுகிறது, அவருடைய ஆதாரத்திற்கான போக்குவரத்து குறைவாக இருக்கும் போது, அணுகல் சிக்கல்கள் வாடிக்கையாளர்களைப் பாதிக்காது. கூடுதலாக, சோதனைச் செயல்பாட்டின் போது ஏதேனும் தவறு நேரலாம் என்பதால், வாடிக்கையாளருடன் நாங்கள் தொடர்ந்து தொடர்பு கொள்கிறோம். இது அடையப்பட்ட முடிவுகளைப் புகாரளிக்க மட்டுமல்லாமல், சோதனையின் போது ஏதாவது மாற்றவும் உங்களை அனுமதிக்கிறது. சோதனை முடிந்ததும், நாங்கள் எப்போதும் ஒரு அறிக்கையை உருவாக்குகிறோம், அதில் கண்டறியப்பட்ட குறைபாடுகளை நாங்கள் சுட்டிக்காட்டுகிறோம் மற்றும் தளத்தின் பலவீனங்களை நீக்குவதற்கான பரிந்துரைகளை வழங்குகிறோம்.
நாங்கள் எப்படி வேலை செய்கிறோம்
சோதனை செய்யும் போது, நாம் ஒரு போட்நெட்டைப் பின்பற்றுகிறோம். எங்கள் நெட்வொர்க்குகளில் இல்லாத வாடிக்கையாளர்களுடன் நாங்கள் பணிபுரிவதால், வரம்புகள் அல்லது பாதுகாப்பு தூண்டப்படுவதால் சோதனை முதல் நிமிடத்தில் முடிவடையாது என்பதை உறுதிசெய்ய, நாங்கள் சுமைகளை ஒரு ஐபியிலிருந்து அல்ல, ஆனால் எங்கள் சொந்த சப்நெட்டிலிருந்து வழங்குகிறோம். கூடுதலாக, குறிப்பிடத்தக்க சுமைகளை உருவாக்க, எங்களிடம் மிகவும் சக்திவாய்ந்த சோதனை சேவையகம் உள்ளது.
போஸ்டுலேட்ஸ்
அதிகமாக இருந்தால் நல்லது என்று அர்த்தமில்லை
குறைந்த சுமை ஒரு வளத்தை தோல்விக்கு கொண்டு வர முடியுமா, சிறந்தது. ஒரு வினாடிக்கு ஒரு கோரிக்கை அல்லது ஒரு நிமிடத்திற்கு ஒரு கோரிக்கையின் மூலம் தளம் செயல்படுவதை நிறுத்தினால், அது மிகவும் நல்லது. ஏனென்றால், சராசரியின் சட்டத்தின்படி, பயனர்கள் அல்லது தாக்குபவர்கள் தற்செயலாக இந்தக் குறிப்பிட்ட பாதிப்பில் விழுவார்கள்.
முழுமையான தோல்வியை விட பகுதி தோல்வி சிறந்தது
அமைப்புகளை பன்முகத்தன்மை கொண்டதாக மாற்ற நாங்கள் எப்போதும் அறிவுறுத்துகிறோம். மேலும், அவற்றை உடல் மட்டத்தில் பிரிப்பது மதிப்பு, மற்றும் கொள்கலன் மூலம் மட்டுமல்ல. உடல் பிரிப்பு விஷயத்தில், தளத்தில் ஏதாவது தோல்வியுற்றாலும், அது முழுமையாக வேலை செய்வதை நிறுத்தாது, மேலும் பயனர்கள் செயல்பாட்டின் ஒரு பகுதியையாவது தொடர்ந்து அணுகலாம்.
நல்ல கட்டிடக்கலை நிலைத்தன்மைக்கு அடிப்படையாகும்
ஒரு வளத்தின் தவறு சகிப்புத்தன்மை மற்றும் தாக்குதல்கள் மற்றும் சுமைகளைத் தாங்கும் திறன் ஆகியவை வடிவமைப்பு கட்டத்தில், உண்மையில், ஒரு நோட்புக்கில் முதல் பாய்வு விளக்கப்படங்களை வரையும் கட்டத்தில் அமைக்கப்பட வேண்டும். ஏனென்றால், அபாயகரமான பிழைகள் ஊடுருவினால், எதிர்காலத்தில் அவற்றை சரிசெய்வது சாத்தியம், ஆனால் அது மிகவும் கடினம்.
குறியீடு மட்டும் நன்றாக இருக்க வேண்டும், ஆனால் கட்டமைப்பும் இருக்க வேண்டும்
ஒரு நல்ல மேம்பாட்டுக் குழு தவறு-சகிப்புத்தன்மை கொண்ட சேவைக்கு உத்தரவாதம் என்று பலர் நினைக்கிறார்கள். ஒரு நல்ல மேம்பாட்டுக் குழு உண்மையில் அவசியம், ஆனால் நல்ல செயல்பாடுகள், நல்ல DevOps இருக்க வேண்டும். அதாவது, லினக்ஸ் மற்றும் நெட்வொர்க்கை சரியாக உள்ளமைக்கும், nginx இல் உள்ளமைவுகளை சரியாக எழுதும், வரம்புகளை அமைக்கும் வல்லுநர்கள் எங்களுக்குத் தேவை. இல்லையெனில், வளமானது சோதனையில் மட்டுமே நன்றாக வேலை செய்யும், மேலும் ஒரு கட்டத்தில் உற்பத்தியில் எல்லாம் உடைந்து விடும்.
சுமை மற்றும் அழுத்த சோதனைக்கு இடையிலான வேறுபாடுகள்
கணினி செயல்பாட்டின் வரம்புகளை அடையாளம் காண சுமை சோதனை உங்களை அனுமதிக்கிறது. மன அழுத்த சோதனை என்பது ஒரு அமைப்பில் உள்ள பலவீனங்களைக் கண்டறிவதை நோக்கமாகக் கொண்டது மற்றும் இந்த அமைப்பை உடைத்து, சில பகுதிகளின் தோல்வியின் செயல்பாட்டில் அது எவ்வாறு செயல்படும் என்பதைப் பார்க்கப் பயன்படுகிறது. இந்த நிலையில், அழுத்தப் பரிசோதனை தொடங்கும் முன், சுமையின் தன்மை பொதுவாக வாடிக்கையாளருக்குத் தெரியாது.
L7 தாக்குதல்களின் தனித்துவமான அம்சங்கள்
நாம் வழக்கமாக L7 மற்றும் L3&4 நிலைகளில் சுமை வகைகளை சுமைகளாகப் பிரிக்கிறோம். L7 என்பது பயன்பாட்டு மட்டத்தில் ஒரு சுமை, பெரும்பாலும் இது HTTP மட்டுமே என்று பொருள், ஆனால் TCP நெறிமுறை மட்டத்தில் எந்த சுமையையும் குறிக்கிறோம்.
L7 தாக்குதல்கள் சில தனித்துவமான அம்சங்களைக் கொண்டுள்ளன. முதலாவதாக, அவை நேரடியாக பயன்பாட்டிற்கு வருகின்றன, அதாவது அவை பிணைய வழிகளில் பிரதிபலிக்கும் சாத்தியம் இல்லை. இத்தகைய தாக்குதல்கள் தர்க்கத்தைப் பயன்படுத்துகின்றன, இதன் காரணமாக, அவை CPU, நினைவகம், வட்டு, தரவுத்தளம் மற்றும் பிற வளங்களை மிகவும் திறமையாகவும், குறைந்த போக்குவரத்துடன் பயன்படுத்துகின்றன.
HTTP வெள்ளம்
எந்தவொரு தாக்குதலின் போதும், சுமை கையாளுவதை விட உருவாக்க எளிதானது, மேலும் L7 விஷயத்தில் இதுவும் உண்மை. தாக்குதல் போக்குவரத்தை முறையான போக்குவரத்திலிருந்து வேறுபடுத்துவது எப்போதுமே எளிதானது அல்ல, பெரும்பாலும் இது அதிர்வெண் மூலம் செய்யப்படலாம், ஆனால் எல்லாவற்றையும் சரியாகத் திட்டமிடினால், தாக்குதல் எங்கே, முறையான கோரிக்கைகள் எங்கே என்பதை பதிவுகளிலிருந்து புரிந்து கொள்ள முடியாது.
முதல் உதாரணமாக, HTTP வெள்ளத் தாக்குதலைக் கவனியுங்கள். இத்தகைய தாக்குதல்கள் பொதுவாக மிகவும் சக்திவாய்ந்தவை என்பதை வரைபடம் காட்டுகிறது; கீழேயுள்ள எடுத்துக்காட்டில், கோரிக்கைகளின் உச்ச எண்ணிக்கை நிமிடத்திற்கு 600 ஆயிரத்தை தாண்டியது.
HTTP வெள்ளம் என்பது சுமைகளை உருவாக்குவதற்கான எளிதான வழியாகும். பொதுவாக, இது ApacheBench போன்ற சில வகையான சுமை சோதனைக் கருவியை எடுத்து, கோரிக்கை மற்றும் இலக்கை அமைக்கிறது. அத்தகைய எளிய அணுகுமுறையுடன், சர்வர் கேச்சிங்கில் இயங்குவதற்கான அதிக நிகழ்தகவு உள்ளது, ஆனால் அதைத் தவிர்ப்பது எளிது. எடுத்துக்காட்டாக, கோரிக்கையில் சீரற்ற சரங்களைச் சேர்ப்பது, இது ஒரு புதிய பக்கத்தை தொடர்ந்து வழங்குவதற்கு சேவையகத்தை கட்டாயப்படுத்தும்.
மேலும், ஒரு சுமை உருவாக்கும் செயல்பாட்டில் பயனர் முகவரைப் பற்றி மறந்துவிடாதீர்கள். பிரபலமான சோதனைக் கருவிகளின் பல பயனர் முகவர்கள் கணினி நிர்வாகிகளால் வடிகட்டப்படுகின்றன, மேலும் இந்த விஷயத்தில் சுமை பின்தளத்தை அடையாமல் போகலாம். கோரிக்கையில் உலாவியில் இருந்து அதிகமாகவோ அல்லது குறைவாகவோ செல்லுபடியாகும் தலைப்பைச் செருகுவதன் மூலம் முடிவை கணிசமாக மேம்படுத்தலாம்.
எச்.டி.டி.பி வெள்ளத் தாக்குதல்கள் எவ்வளவு எளிமையானவையோ, அவை அவற்றின் குறைபாடுகளையும் கொண்டுள்ளன. முதலாவதாக, சுமைகளை உருவாக்க அதிக அளவு சக்தி தேவைப்படுகிறது. இரண்டாவதாக, இத்தகைய தாக்குதல்களை கண்டறிவது மிகவும் எளிதானது, குறிப்பாக அவை ஒரு முகவரியிலிருந்து வந்தால். இதன் விளைவாக, கோரிக்கைகள் உடனடியாக கணினி நிர்வாகிகளால் அல்லது வழங்குநர் மட்டத்தில் வடிகட்டத் தொடங்குகின்றன.
எதைத் தேடுவது
செயல்திறனை இழக்காமல் வினாடிக்கு கோரிக்கைகளின் எண்ணிக்கையை குறைக்க, நீங்கள் கொஞ்சம் கற்பனை காட்ட வேண்டும் மற்றும் தளத்தை ஆராய வேண்டும். எனவே, நீங்கள் சேனல் அல்லது சேவையகத்தை மட்டுமல்ல, பயன்பாட்டின் தனிப்பட்ட பகுதிகளையும் ஏற்றலாம், எடுத்துக்காட்டாக, தரவுத்தளங்கள் அல்லது கோப்பு முறைமைகள். தளத்தில் பெரிய கணக்கீடுகளைச் செய்யும் இடங்களையும் நீங்கள் தேடலாம்: கால்குலேட்டர்கள், தயாரிப்புத் தேர்வுப் பக்கங்கள் போன்றவை. இறுதியாக, தளத்தில் சில வகையான PHP ஸ்கிரிப்ட் உள்ளது, அது பல லட்சம் வரிகளின் பக்கத்தை உருவாக்குகிறது. அத்தகைய ஸ்கிரிப்ட் சேவையகத்தை கணிசமாக ஏற்றுகிறது மற்றும் தாக்குதலுக்கு இலக்காகலாம்.
எங்கே பார்ப்பது
சோதனைக்கு முன் ஒரு ஆதாரத்தை ஸ்கேன் செய்யும்போது, முதலில் அந்த தளத்தையே பார்க்கிறோம். அனைத்து வகையான உள்ளீட்டு புலங்கள், கனமான கோப்புகள் - பொதுவாக, வளத்திற்கான சிக்கல்களை உருவாக்கி அதன் செயல்பாட்டை மெதுவாக்கும் அனைத்தையும் நாங்கள் தேடுகிறோம். Google Chrome மற்றும் Firefox இல் உள்ள சாதாரண மேம்பாட்டுக் கருவிகள் இங்கே உதவுகின்றன, பக்க மறுமொழி நேரத்தைக் காட்டுகிறது.
துணை டொமைன்களையும் ஸ்கேன் செய்கிறோம். எடுத்துக்காட்டாக, ஒரு குறிப்பிட்ட ஆன்லைன் ஸ்டோர், abc.com உள்ளது, மேலும் அதில் admin.abc.com என்ற துணை டொமைன் உள்ளது. பெரும்பாலும், இது அங்கீகாரத்துடன் கூடிய நிர்வாகக் குழுவாகும், ஆனால் நீங்கள் அதில் ஒரு சுமை வைத்தால், அது முக்கிய ஆதாரத்தில் சிக்கல்களை உருவாக்கலாம்.
தளத்தில் api.abc.com துணை டொமைன் இருக்கலாம். பெரும்பாலும், இது மொபைல் பயன்பாடுகளுக்கான ஆதாரமாகும். பயன்பாட்டை App Store அல்லது Google Play இல் காணலாம், ஒரு சிறப்பு அணுகல் புள்ளியை நிறுவவும், API ஐ பிரித்து சோதனை கணக்குகளை பதிவு செய்யவும். பிரச்சனை என்னவென்றால், அங்கீகாரத்தால் பாதுகாக்கப்படும் எதுவும் சேவை மறுப்புத் தாக்குதல்களில் இருந்து விடுபடும் என்று மக்கள் அடிக்கடி நினைக்கிறார்கள். கூறப்படும், அங்கீகாரம் சிறந்த CAPTCHA, ஆனால் அது இல்லை. 10-20 சோதனைக் கணக்குகளை உருவாக்குவது எளிது, ஆனால் அவற்றை உருவாக்குவதன் மூலம் சிக்கலான மற்றும் மறைக்கப்படாத செயல்பாட்டிற்கான அணுகலைப் பெறுகிறோம்.
இயற்கையாகவே, நாம் வரலாற்றைப் பார்க்கிறோம், robots.txt மற்றும் WebArchive, ViewDNS, மற்றும் வளத்தின் பழைய பதிப்புகளைத் தேடுகிறோம். சில நேரங்களில் டெவலப்பர்கள் mail2.yandex.net ஐ உருவாக்கியுள்ளனர், ஆனால் பழைய பதிப்பான mail.yandex.net உள்ளது. இந்த mail.yandex.net இனி ஆதரிக்கப்படாது, மேம்பாட்டு ஆதாரங்கள் இதற்கு ஒதுக்கப்படவில்லை, ஆனால் அது தரவுத்தளத்தைத் தொடர்ந்து பயன்படுத்துகிறது. அதன்படி, பழைய பதிப்பைப் பயன்படுத்தி, பின்தளத்தின் வளங்களையும், தளவமைப்பின் பின்னால் உள்ள அனைத்தையும் நீங்கள் திறம்பட பயன்படுத்தலாம். நிச்சயமாக, இது எப்போதும் நடக்காது, ஆனால் நாம் இன்னும் அடிக்கடி இதை சந்திக்கிறோம்.
இயற்கையாகவே, அனைத்து கோரிக்கை அளவுருக்கள் மற்றும் குக்கீ கட்டமைப்பை நாங்கள் பகுப்பாய்வு செய்கிறோம். நீங்கள் ஒரு குக்கீயின் உள்ளே ஒரு JSON வரிசையில் சில மதிப்பைச் செலுத்தலாம், நிறைய கூடுகளை உருவாக்கலாம் மற்றும் ஆதாரத்தை நியாயமற்ற முறையில் நீண்ட நேரம் வேலை செய்ய முடியும்.
தேடல் சுமை
ஒரு தளத்தை ஆராயும்போது முதலில் நினைவுக்கு வருவது தரவுத்தளத்தை ஏற்றுவதுதான், ஏனென்றால் கிட்டத்தட்ட அனைவருக்கும் ஒரு தேடல் உள்ளது, மேலும் கிட்டத்தட்ட அனைவருக்கும், துரதிர்ஷ்டவசமாக, அது மோசமாக பாதுகாக்கப்படுகிறது. சில காரணங்களால், டெவலப்பர்கள் தேடலில் போதுமான கவனம் செலுத்துவதில்லை. ஆனால் இங்கே ஒரு பரிந்துரை உள்ளது - ஒரே மாதிரியான கோரிக்கைகளை நீங்கள் செய்யக்கூடாது, ஏனென்றால் HTTP வெள்ளம் போன்ற கேச்சிங்கை நீங்கள் சந்திக்கலாம்.
தரவுத்தளத்தில் சீரற்ற வினவல்களை உருவாக்குவதும் எப்போதும் பயனுள்ளதாக இருக்காது. தேடலுடன் தொடர்புடைய முக்கிய வார்த்தைகளின் பட்டியலை உருவாக்குவது மிகவும் நல்லது. ஆன்லைன் ஸ்டோரின் உதாரணத்திற்கு நாங்கள் திரும்பினால்: தளம் கார் டயர்களை விற்கிறது மற்றும் டயர்களின் ஆரம், காரின் வகை மற்றும் பிற அளவுருக்களை அமைக்க உங்களை அனுமதிக்கிறது என்று வைத்துக்கொள்வோம். அதன்படி, தொடர்புடைய சொற்களின் சேர்க்கைகள் தரவுத்தளத்தை மிகவும் சிக்கலான நிலைமைகளில் வேலை செய்ய கட்டாயப்படுத்தும்.
கூடுதலாக, பேஜினேஷனைப் பயன்படுத்துவது மதிப்புக்குரியது: தேடல் முடிவுகளின் இறுதிப் பக்கத்தை முதல் பக்கத்தை விட தேடலுக்குத் திருப்புவது மிகவும் கடினம். அதாவது, பேஜினேஷனின் உதவியுடன் நீங்கள் சுமைகளை சற்று பன்முகப்படுத்தலாம்.
கீழே உள்ள எடுத்துக்காட்டு தேடல் சுமையைக் காட்டுகிறது. வினாடிக்கு பத்து கோரிக்கைகள் என்ற வேகத்தில் சோதனையின் முதல் வினாடியிலிருந்து, தளம் செயலிழந்து, பதிலளிக்கவில்லை என்பதைக் காணலாம்.
தேடல் இல்லை என்றால்?
தேடல் இல்லை என்றால், பாதிக்கப்படக்கூடிய பிற உள்ளீட்டு புலங்கள் தளத்தில் இல்லை என்று அர்த்தம் இல்லை. இந்த புலம் அங்கீகாரமாக இருக்கலாம். இப்போதெல்லாம், டெவலப்பர்கள் ரெயின்போ டேபிள் தாக்குதலில் இருந்து உள்நுழைவு தரவுத்தளத்தைப் பாதுகாக்க சிக்கலான ஹாஷ்களை உருவாக்க விரும்புகிறார்கள். இது நல்லது, ஆனால் இதுபோன்ற ஹாஷ்கள் நிறைய CPU ஆதாரங்களை பயன்படுத்துகின்றன. தவறான அங்கீகாரங்களின் ஒரு பெரிய ஓட்டம் செயலி தோல்விக்கு வழிவகுக்கிறது, இதன் விளைவாக, தளம் வேலை செய்வதை நிறுத்துகிறது.
கருத்துகள் மற்றும் கருத்துகளுக்கான அனைத்து வகையான படிவங்களும் தளத்தில் இருப்பது மிகப் பெரிய நூல்களை அங்கு அனுப்ப அல்லது ஒரு பெரிய வெள்ளத்தை உருவாக்க ஒரு காரணமாகும். சில நேரங்களில் தளங்கள் இணைக்கப்பட்ட கோப்புகளை ஏற்றுக்கொள்கின்றன, gzip வடிவம் உட்பட. இந்த வழக்கில், நாங்கள் 1TB கோப்பை எடுத்து, அதை gzip ஐப் பயன்படுத்தி பல பைட்டுகள் அல்லது கிலோபைட்டுகளுக்கு சுருக்கி தளத்திற்கு அனுப்புவோம். பின்னர் அது அன்சிப் செய்யப்பட்டு மிகவும் சுவாரஸ்யமான விளைவு பெறப்படுகிறது.
மீதமுள்ள API
ரெஸ்ட் ஏபிஐ போன்ற பிரபலமான சேவைகளில் கொஞ்சம் கவனம் செலுத்த விரும்புகிறேன். ரெஸ்ட் API ஐப் பாதுகாப்பது வழக்கமான இணையதளத்தை விட மிகவும் கடினம். பாஸ்வேர்ட் ப்ரூட் ஃபோர்ஸ் மற்றும் பிற சட்டவிரோத செயல்களுக்கு எதிரான அற்பமான பாதுகாப்பு முறைகள் கூட ரெஸ்ட் ஏபிஐக்கு வேலை செய்யாது.
ரெஸ்ட் ஏபிஐ உடைப்பது மிகவும் எளிதானது, ஏனெனில் இது நேரடியாக தரவுத்தளத்தை அணுகுகிறது. அதே நேரத்தில், அத்தகைய சேவையின் தோல்வி வணிகத்திற்கு மிகவும் கடுமையான விளைவுகளை ஏற்படுத்துகிறது. உண்மை என்னவென்றால், ரெஸ்ட் ஏபிஐ பொதுவாக பிரதான வலைத்தளத்திற்கு மட்டுமல்ல, மொபைல் பயன்பாடு மற்றும் சில உள் வணிக ஆதாரங்களுக்கும் பயன்படுத்தப்படுகிறது. இவை அனைத்தும் வீழ்ச்சியடைந்தால், ஒரு எளிய வலைத்தள தோல்வியை விட விளைவு மிகவும் வலுவானது.
கனமான உள்ளடக்கத்தை ஏற்றுகிறது
சிக்கலான செயல்பாடு இல்லாத சில சாதாரண ஒற்றைப் பக்க பயன்பாடு, இறங்கும் பக்கம் அல்லது வணிக அட்டை இணையதளத்தைச் சோதிக்க நாங்கள் முன்வந்தால், நாங்கள் கனமான உள்ளடக்கத்தைத் தேடுகிறோம். எடுத்துக்காட்டாக, சர்வர் அனுப்பும் பெரிய படங்கள், பைனரி கோப்புகள், pdf ஆவணங்கள் - இவை அனைத்தையும் பதிவிறக்கம் செய்ய முயற்சிக்கிறோம். இத்தகைய சோதனைகள் கோப்பு முறைமையை நன்றாக ஏற்றி, சேனல்களை அடைத்து, அதனால் பயனுள்ளதாக இருக்கும். அதாவது, நீங்கள் சேவையகத்தை கீழே வைக்காவிட்டாலும், குறைந்த வேகத்தில் ஒரு பெரிய கோப்பை பதிவிறக்கம் செய்தால், நீங்கள் இலக்கு சேவையகத்தின் சேனலை வெறுமனே அடைத்துவிடுவீர்கள், பின்னர் சேவை மறுப்பு ஏற்படும்.
அத்தகைய சோதனையின் எடுத்துக்காட்டு, 30 RPS வேகத்தில் தளம் பதிலளிப்பதை நிறுத்தியது அல்லது 500 வது சர்வர் பிழைகளை உருவாக்கியது.
சேவையகங்களை அமைப்பது பற்றி மறந்துவிடாதீர்கள். ஒரு நபர் ஒரு மெய்நிகர் இயந்திரத்தை வாங்கி, அங்கு அப்பாச்சியை நிறுவி, முன்னிருப்பாக அனைத்தையும் உள்ளமைத்து, ஒரு PHP பயன்பாட்டை நிறுவியிருப்பதை நீங்கள் அடிக்கடி காணலாம் மற்றும் கீழே நீங்கள் முடிவைக் காணலாம்.
இங்கே சுமை ரூட்டிற்குச் சென்று 10 RPS ஆக மட்டுமே இருந்தது. நாங்கள் 5 நிமிடங்கள் காத்திருந்தோம், சர்வர் செயலிழந்தது. அவர் ஏன் விழுந்தார் என்பது முழுமையாகத் தெரியவில்லை என்பது உண்மைதான், ஆனால் அவருக்கு நினைவாற்றல் அதிகமாக இருந்தது, எனவே பதிலளிப்பதை நிறுத்திவிட்டார் என்று ஒரு அனுமானம் உள்ளது.
அலை அடிப்படையிலானது
கடந்த ஓரிரு ஆண்டுகளில், அலை தாக்குதல்கள் மிகவும் பிரபலமாகிவிட்டன. பல நிறுவனங்கள் DDoS பாதுகாப்பிற்காக சில வன்பொருள்களை வாங்குவதால், தாக்குதலை வடிகட்டத் தொடங்க புள்ளிவிவரங்களைக் குவிப்பதற்கு ஒரு குறிப்பிட்ட அளவு நேரம் தேவைப்படுகிறது. அதாவது, அவர்கள் முதல் 30-40 வினாடிகளில் தாக்குதலை வடிகட்ட மாட்டார்கள், ஏனென்றால் அவை தரவுகளை குவித்து கற்றுக்கொள்கின்றன. அதன்படி, இந்த 30-40 வினாடிகளில் நீங்கள் தளத்தில் நிறைய தொடங்கலாம், எல்லா கோரிக்கைகளும் அழிக்கப்படும் வரை ஆதாரம் நீண்ட நேரம் இருக்கும்.
கீழே உள்ள தாக்குதலின் விஷயத்தில், 10 நிமிட இடைவெளி இருந்தது, அதன் பிறகு தாக்குதலின் புதிய, மாற்றியமைக்கப்பட்ட பகுதி வந்தது.
அதாவது, பாதுகாப்பு கற்றுக்கொண்டது, வடிகட்டத் தொடங்கியது, ஆனால் தாக்குதலின் புதிய, முற்றிலும் மாறுபட்ட பகுதி வந்தது, மேலும் பாதுகாப்பு மீண்டும் கற்கத் தொடங்கியது. உண்மையில், வடிகட்டுதல் வேலை செய்வதை நிறுத்துகிறது, பாதுகாப்பு பயனற்றதாகிவிடும், மேலும் தளம் கிடைக்கவில்லை.
அலை தாக்குதல்கள் உச்சத்தில் மிக உயர்ந்த மதிப்புகளால் வகைப்படுத்தப்படுகின்றன, இது எல் 7 விஷயத்தில் வினாடிக்கு ஒரு லட்சம் அல்லது ஒரு மில்லியன் கோரிக்கைகளை அடையலாம். நாம் எல் 3 & 4 பற்றி பேசினால், நூற்றுக்கணக்கான ஜிகாபிட் போக்குவரத்து இருக்கலாம் அல்லது அதன்படி, நூற்றுக்கணக்கான எம்பிபிஎஸ், நீங்கள் பாக்கெட்டுகளில் எண்ணினால்.
இத்தகைய தாக்குதல்களின் சிக்கல் ஒத்திசைவு ஆகும். தாக்குதல்கள் ஒரு பாட்நெட்டிலிருந்து வருகின்றன, மேலும் மிகப் பெரிய ஒரு முறை ஸ்பைக்கை உருவாக்க அதிக அளவு ஒத்திசைவு தேவைப்படுகிறது. இந்த ஒருங்கிணைப்பு எப்போதும் செயல்படாது: சில நேரங்களில் வெளியீடு ஒருவித பரவளைய உச்சம், இது பரிதாபகரமானதாக தோன்றுகிறது.
HTTP மட்டும் அல்ல
L7 இல் HTTP ஐத் தவிர, பிற நெறிமுறைகளைப் பயன்படுத்த விரும்புகிறோம். ஒரு விதியாக, ஒரு வழக்கமான வலைத்தளம், குறிப்பாக வழக்கமான ஹோஸ்டிங், அஞ்சல் நெறிமுறைகள் மற்றும் MySQL ஒட்டிக்கொண்டிருக்கும். அஞ்சல் நெறிமுறைகள் தரவுத்தளங்களை விட குறைவான சுமைக்கு உட்பட்டவை, ஆனால் அவை மிகவும் திறமையாக ஏற்றப்பட்டு, சர்வரில் அதிக சுமை கொண்ட CPU உடன் முடிவடையும்.
2016 SSH பாதிப்பைப் பயன்படுத்தி நாங்கள் மிகவும் வெற்றியடைந்தோம். இப்போது இந்த பாதிப்பு கிட்டத்தட்ட அனைவருக்கும் சரி செய்யப்பட்டுள்ளது, ஆனால் SSH க்கு சுமை சமர்ப்பிக்க முடியாது என்று இது அர்த்தப்படுத்துவதில்லை. முடியும். ஒரு பெரிய அளவிலான அங்கீகாரங்கள் உள்ளன, SSH ஆனது சர்வரில் உள்ள CPU முழுவதையும் சாப்பிடுகிறது, பின்னர் ஒரு நொடிக்கு ஒன்று அல்லது இரண்டு கோரிக்கைகளில் இருந்து வலைத்தளம் சரிந்துவிடும். அதன்படி, பதிவுகளின் அடிப்படையில் இந்த ஒன்று அல்லது இரண்டு கோரிக்கைகளை முறையான சுமையிலிருந்து வேறுபடுத்த முடியாது.
சேவையகங்களில் நாம் திறக்கும் பல இணைப்புகளும் தொடர்புடையதாகவே இருக்கும். முன்னதாக, அப்பாச்சி இதில் குற்றவாளியாக இருந்தார், இப்போது nginx உண்மையில் இதில் குற்றவாளி, ஏனெனில் இது பெரும்பாலும் இயல்புநிலையாக கட்டமைக்கப்படுகிறது. nginxஐத் திறந்து வைத்திருக்கக்கூடிய இணைப்புகளின் எண்ணிக்கை குறைவாக உள்ளது, எனவே இந்த எண்ணிக்கையிலான இணைப்புகளைத் திறக்கிறோம், nginx இனி புதிய இணைப்பை ஏற்காது, இதன் விளைவாக தளம் இயங்காது.
எங்கள் சோதனைக் கிளஸ்டரில் SSL ஹேண்ட்ஷேக்கைத் தாக்கும் அளவுக்கு CPU உள்ளது. கொள்கையளவில், நடைமுறையில் காண்பிக்கிறபடி, போட்நெட்கள் சில நேரங்களில் இதைச் செய்ய விரும்புகின்றன. ஒருபுறம், நீங்கள் SSL இல்லாமல் செய்ய முடியாது என்பது தெளிவாகிறது, ஏனெனில் Google முடிவுகள், தரவரிசை, பாதுகாப்பு. மறுபுறம், SSL துரதிர்ஷ்டவசமாக CPU சிக்கலைக் கொண்டுள்ளது.
L3&4
L3&4 நிலைகளில் தாக்குதலைப் பற்றி பேசும்போது, பொதுவாக இணைப்பு மட்டத்தில் தாக்குதல் பற்றி பேசுகிறோம். இது ஒரு SYN-வெள்ளத் தாக்குதலாக இல்லாவிட்டால், அத்தகைய சுமை எப்போதும் முறையான ஒன்றிலிருந்து வேறுபடுத்தப்படும். பாதுகாப்பு கருவிகளுக்கான SYN-வெள்ளத் தாக்குதல்களில் உள்ள சிக்கல் அவற்றின் பெரிய அளவு. அதிகபட்ச L3&4 மதிப்பு 1,5-2 Tbit/s ஆகும். ஆரக்கிள் மற்றும் கூகுள் உள்ளிட்ட பெரிய நிறுவனங்களுக்கு கூட இதுபோன்ற போக்குவரத்தை செயலாக்குவது மிகவும் கடினம்.
SYN மற்றும் SYN-ACK ஆகியவை இணைப்பை நிறுவும் போது பயன்படுத்தப்படும் பாக்கெட்டுகள். எனவே, SYN-வெள்ளத்தை முறையான சுமையிலிருந்து வேறுபடுத்துவது கடினம்: இது ஒரு இணைப்பை ஏற்படுத்த வந்த SYN தானா அல்லது வெள்ளத்தின் ஒரு பகுதியா என்பது தெளிவாகத் தெரியவில்லை.
UDP-வெள்ளம்
பொதுவாக, தாக்குபவர்களிடம் நம்மிடம் உள்ள திறன்கள் இல்லை, எனவே தாக்குதல்களை ஒழுங்கமைக்க பெருக்கத்தைப் பயன்படுத்தலாம். அதாவது, தாக்குபவர் இணையத்தை ஸ்கேன் செய்து, பாதிக்கப்படக்கூடிய அல்லது தவறாக உள்ளமைக்கப்பட்ட சேவையகங்களைக் கண்டறிகிறார், எடுத்துக்காட்டாக, ஒரு SYN பாக்கெட்டுக்கு பதிலளிக்கும் விதமாக, மூன்று SYN-ACKகள் மூலம் பதிலளிக்கவும். இலக்கு சேவையகத்தின் முகவரியில் இருந்து மூல முகவரியை ஏமாற்றுவதன் மூலம், ஒரு பாக்கெட்டில் மூன்று மடங்கு சக்தியை அதிகரிக்கவும், பாதிக்கப்பட்டவருக்கு போக்குவரத்தை திருப்பி விடவும் முடியும்.
பெருக்கங்களில் உள்ள சிக்கல் என்னவென்றால், அவற்றைக் கண்டறிவது கடினம். சமீபத்திய எடுத்துக்காட்டுகளில், பாதிக்கப்படக்கூடிய மெம்கேச் செய்யப்பட்ட பரபரப்பான வழக்கு அடங்கும். கூடுதலாக, இப்போது நிறைய ஐஓடி சாதனங்கள், ஐபி கேமராக்கள் உள்ளன, அவை பெரும்பாலும் இயல்பாகவே கட்டமைக்கப்படுகின்றன, மேலும் முன்னிருப்பாக அவை தவறாக உள்ளமைக்கப்படுகின்றன, அதனால்தான் தாக்குபவர்கள் பெரும்பாலும் இதுபோன்ற சாதனங்கள் மூலம் தாக்குதல்களைச் செய்கிறார்கள்.
கடினமான SYN-வெள்ளம்
SYN-வெள்ளம் என்பது டெவலப்பரின் பார்வையில் மிகவும் சுவாரஸ்யமான தாக்குதலாகும். சிக்கல் என்னவென்றால், கணினி நிர்வாகிகள் பாதுகாப்பிற்காக ஐபி தடுப்பை அடிக்கடி பயன்படுத்துகின்றனர். மேலும், ஐபி தடுப்பது ஸ்கிரிப்ட்களைப் பயன்படுத்தி செயல்படும் கணினி நிர்வாகிகளை மட்டுமல்ல, துரதிர்ஷ்டவசமாக, நிறைய பணத்திற்கு வாங்கப்பட்ட சில பாதுகாப்பு அமைப்புகளையும் பாதிக்கிறது.
இந்த முறை ஒரு பேரழிவாக மாறும், ஏனெனில் தாக்குபவர்கள் ஐபி முகவரிகளை மாற்றினால், நிறுவனம் அதன் சொந்த சப்நெட்டைத் தடுக்கும். ஃபயர்வால் அதன் சொந்த கிளஸ்டரைத் தடுக்கும்போது, வெளியீடு வெளிப்புற தொடர்புகளில் தோல்வியடையும் மற்றும் ஆதாரம் தோல்வியடையும்.
மேலும், உங்கள் சொந்த நெட்வொர்க்கைத் தடுப்பது கடினம் அல்ல. கிளையண்டின் அலுவலகத்தில் வைஃபை நெட்வொர்க் இருந்தால், அல்லது பல்வேறு கண்காணிப்பு அமைப்புகளைப் பயன்படுத்தி வளங்களின் செயல்திறன் அளவிடப்பட்டால், இந்த கண்காணிப்பு அமைப்பின் ஐபி முகவரியை அல்லது கிளையண்டின் அலுவலக வைஃபையை எடுத்து அதை ஆதாரமாகப் பயன்படுத்துவோம். முடிவில், ஆதாரம் இருப்பது போல் தெரிகிறது, ஆனால் இலக்கு ஐபி முகவரிகள் தடுக்கப்பட்டுள்ளன. இதனால், நிறுவனத்தின் புதிய தயாரிப்பு வழங்கப்படும் ஹைலோட் மாநாட்டின் வைஃபை நெட்வொர்க் தடுக்கப்படலாம், மேலும் இது சில வணிக மற்றும் பொருளாதார செலவுகளை ஏற்படுத்துகிறது.
சோதனையின் போது, எந்த வெளிப்புற ஆதாரங்களுடனும் memcached மூலம் பெருக்கத்தைப் பயன்படுத்த முடியாது, ஏனெனில் அனுமதிக்கப்பட்ட IP முகவரிகளுக்கு மட்டுமே போக்குவரத்தை அனுப்ப ஒப்பந்தங்கள் உள்ளன. அதன்படி, இரண்டு அல்லது மூன்று SYN-ACKகளுடன் ஒரு SYN ஐ அனுப்ப கணினி பதிலளிக்கும் போது, SYN மற்றும் SYN-ACK மூலம் பெருக்கத்தைப் பயன்படுத்துகிறோம், மேலும் வெளியீட்டில் தாக்குதல் இரண்டு அல்லது மூன்று மடங்கு பெருக்கப்படும்.
கருவிகள்
L7 பணிச்சுமைக்கு நாம் பயன்படுத்தும் முக்கிய கருவிகளில் ஒன்று Yandex-tank ஆகும். குறிப்பாக, ஒரு பாண்டம் துப்பாக்கியாகப் பயன்படுத்தப்படுகிறது, மேலும் தோட்டாக்களை உருவாக்குவதற்கும் முடிவுகளை பகுப்பாய்வு செய்வதற்கும் பல ஸ்கிரிப்டுகள் உள்ளன.
Tcpdump பிணைய போக்குவரத்தை பகுப்பாய்வு செய்ய பயன்படுத்தப்படுகிறது, மேலும் Nmap சேவையகத்தை பகுப்பாய்வு செய்ய பயன்படுத்தப்படுகிறது. L3&4 மட்டத்தில் சுமைகளை உருவாக்க, OpenSSL மற்றும் DPDK நூலகத்துடன் எங்கள் சொந்த மேஜிக் கொஞ்சம் பயன்படுத்தப்படுகிறது. டிபிடிகே என்பது இன்டெல்லின் நூலகமாகும், இது லினக்ஸ் அடுக்கைத் தவிர்த்து பிணைய இடைமுகத்துடன் பணிபுரிய உங்களை அனுமதிக்கிறது, இதன் மூலம் செயல்திறனை அதிகரிக்கிறது. இயற்கையாகவே, DPDK ஐ L3&4 மட்டத்தில் மட்டுமல்ல, L7 அளவிலும் பயன்படுத்துகிறோம், ஏனெனில் இது ஒரு இயந்திரத்திலிருந்து வினாடிக்கு பல மில்லியன் கோரிக்கைகள் வரம்பிற்குள் மிக அதிக சுமை ஓட்டத்தை உருவாக்க அனுமதிக்கிறது.
குறிப்பிட்ட சோதனைகளுக்கு நாங்கள் எழுதும் குறிப்பிட்ட டிராஃபிக் ஜெனரேட்டர்கள் மற்றும் சிறப்புக் கருவிகளையும் பயன்படுத்துகிறோம். SSH இன் கீழ் உள்ள பாதிப்பை நாம் நினைவு கூர்ந்தால், மேலே உள்ள தொகுப்பைப் பயன்படுத்த முடியாது. நாங்கள் அஞ்சல் நெறிமுறையைத் தாக்கினால், நாங்கள் அஞ்சல் பயன்பாடுகளை எடுத்துக்கொள்வோம் அல்லது அவற்றில் ஸ்கிரிப்ட்களை எழுதுவோம்.
கண்டுபிடிப்புகள்
ஒரு முடிவாக நான் சொல்ல விரும்புகிறேன்:
- கிளாசிக் சுமை சோதனைக்கு கூடுதலாக, அழுத்த சோதனை நடத்த வேண்டியது அவசியம். பங்குதாரரின் துணை ஒப்பந்ததாரர் சுமை சோதனையை மட்டுமே செய்ததற்கான உண்மையான உதாரணம் எங்களிடம் உள்ளது. வளமானது சாதாரண சுமைகளைத் தாங்கும் என்பதை இது காட்டியது. ஆனால் பின்னர் ஒரு அசாதாரண சுமை தோன்றியது, தள பார்வையாளர்கள் வளத்தை கொஞ்சம் வித்தியாசமாகப் பயன்படுத்தத் தொடங்கினர், இதன் விளைவாக துணை ஒப்பந்தக்காரர் கீழே கிடந்தார். எனவே, நீங்கள் ஏற்கனவே DDoS தாக்குதல்களிலிருந்து பாதுகாக்கப்பட்டிருந்தாலும் பாதிப்புகளைத் தேடுவது மதிப்பு.
- கணினியின் சில பகுதிகளை மற்றவர்களிடமிருந்து தனிமைப்படுத்துவது அவசியம். உங்களிடம் ஒரு தேடல் இருந்தால், நீங்கள் அதை தனி இயந்திரங்களுக்கு நகர்த்த வேண்டும், அதாவது டோக்கருக்கு கூட இல்லை. ஏனெனில் தேடுதல் அல்லது அங்கீகாரம் தோல்வியடைந்தால், குறைந்தபட்சம் ஏதாவது தொடர்ந்து வேலை செய்யும். ஆன்லைன் ஸ்டோரைப் பொறுத்தவரை, பயனர்கள் பட்டியலில் தயாரிப்புகளைக் கண்டறிவார்கள், ஒருங்கிணைப்பாளரிடமிருந்து செல்வார்கள், அவர்கள் ஏற்கனவே அங்கீகரிக்கப்பட்டிருந்தால் வாங்குவார்கள் அல்லது OAuth2 வழியாக அங்கீகரிப்பார்கள்.
- அனைத்து வகையான கிளவுட் சேவைகளையும் புறக்கணிக்காதீர்கள்.
- நெட்வொர்க் தாமதங்களை மேம்படுத்துவதற்கு மட்டும் CDN ஐப் பயன்படுத்தவும், ஆனால் சேனல் சோர்வு மற்றும் நிலையான போக்குவரத்தில் வெள்ளம் ஏற்படுவதற்கான தாக்குதல்களுக்கு எதிரான பாதுகாப்பு வழிமுறையாகவும் பயன்படுத்தவும்.
- சிறப்பு பாதுகாப்பு சேவைகளைப் பயன்படுத்துவது அவசியம். சேனல் மட்டத்தில் L3&4 தாக்குதல்களிலிருந்து உங்களைப் பாதுகாத்துக் கொள்ள முடியாது, ஏனெனில் உங்களிடம் போதுமான சேனல் இல்லை. நீங்கள் L7 தாக்குதல்களை எதிர்த்துப் போராட வாய்ப்பில்லை, ஏனெனில் அவை மிகப் பெரியதாக இருக்கலாம். கூடுதலாக, சிறிய தாக்குதல்களுக்கான தேடல் இன்னும் சிறப்பு சேவைகள், சிறப்பு வழிமுறைகளின் தனிச்சிறப்பு.
- தொடர்ந்து புதுப்பிக்கவும். இது கர்னலுக்கு மட்டுமல்ல, SSH டெமானுக்கும் பொருந்தும், குறிப்பாக நீங்கள் அவற்றை வெளியில் திறந்திருந்தால். கொள்கையளவில், அனைத்தும் புதுப்பிக்கப்பட வேண்டும், ஏனென்றால் நீங்கள் சில பாதிப்புகளை நீங்களே கண்காணிக்க முடியாது.
ஆதாரம்: www.habr.com