ගලවා ගැනීමට DDoS: අපි ආතතිය සහ බර පරීක්ෂණ පවත්වන ආකාරය

Variti bots සහ DDoS ප්‍රහාර වලින් ආරක්ෂාව වර්ධනය කරන අතර ආතතිය සහ බර පරීක්ෂා කිරීමද සිදු කරයි. HighLoad++ 2018 සම්මන්ත්‍රණයේදී අපි විවිධ ආකාරයේ ප්‍රහාරවලින් සම්පත් සුරක්ෂිත කරගන්නා ආකාරය ගැන කතා කළෙමු. කෙටියෙන් කිවහොත්: පද්ධතියේ කොටස් හුදකලා කරන්න, වලාකුළු සේවා සහ CDN භාවිතා කරන්න, සහ නිතිපතා යාවත්කාලීන කරන්න. නමුත් ඔබට තවමත් විශේෂිත සමාගම් නොමැතිව ආරක්ෂාව හැසිරවීමට නොහැකි වනු ඇත :)

පාඨය කියවීමට පෙර, ඔබට කෙටි සාරාංශ කියවිය හැකිය සම්මන්ත්රණ වෙබ් අඩවියේ.
තවද ඔබ වීඩියෝව කියවීමට අකමැති නම් හෝ නැරඹීමට අවශ්‍ය නම්, අපගේ වාර්තාවේ පටිගත කිරීම ස්පොයිලර් යටතේ පහත දැක්වේ.

වාර්තාවේ වීඩියෝ පටිගත කිරීම

බොහෝ සමාගම් දැනටමත් load testing කරන්නේ කෙසේදැයි දනී, නමුත් සියල්ලෝම Stress testing කරන්නේ නැත. අපගේ සමහර ගනුදෙනුකරුවන් සිතන්නේ ඔවුන් සතුව හයිලෝඩ් පද්ධතියක් ඇති නිසාත්, එය ප්‍රහාරවලින් හොඳින් ආරක්ෂා වන නිසාත් ඔවුන්ගේ වෙබ් අඩවිය අනාරක්ෂිත බවයි. මෙය සම්පූර්ණයෙන්ම සත්‍ය නොවන බව අපි පෙන්වමු.
ඇත්ත වශයෙන්ම, පරීක්ෂණ පැවැත්වීමට පෙර, අපි පාරිභෝගිකයාගෙන් අවසර ලබාගෙන, අත්සන් කර මුද්රා තබා, අපගේ සහාය ඇතිව DDoS ප්රහාරයක් කිසිවෙකුට සිදු කළ නොහැක. පාරිභෝගිකයා විසින් තෝරා ගන්නා ලද වේලාවක පරීක්ෂා කිරීම සිදු කරනු ලැබේ, ඔහුගේ සම්පත වෙත ගමනාගමනය අවම වන අතර, ප්‍රවේශ ගැටළු සේවාදායකයින්ට බලපාන්නේ නැත. ඊට අමතරව, පරීක්ෂණ ක්‍රියාවලියේදී සෑම විටම යමක් වැරදී යා හැකි බැවින්, අපට පාරිභෝගිකයා සමඟ නිරන්තර සම්බන්ධතා ඇත. මෙය ඔබට අත්පත් කරගත් ප්රතිඵල වාර්තා කිරීමට පමණක් නොව, පරීක්ෂණය අතරතුර යමක් වෙනස් කිරීමටද ඉඩ සලසයි. පරීක්ෂණය අවසන් වූ පසු, අපි සෑම විටම වාර්තාවක් සකස් කරන අතර එහිදී අපි අනාවරණය කරගත් අඩුපාඩු පෙන්වා දෙන අතර වෙබ් අඩවියේ දුර්වලතා ඉවත් කිරීම සඳහා නිර්දේශ ලබා දෙන්නෙමු.

අපි වැඩ කරන ආකාරය

පරීක්ෂා කිරීමේදී, අපි බොට්නෙට් එකක් අනුකරණය කරමු. අපගේ ජාලවල නොමැති සේවාදායකයින් සමඟ අපි වැඩ කරන බැවින්, සීමාවන් හෝ ආරක්ෂාව අවුලුවාලීම හේතුවෙන් පරීක්ෂණය පළමු මිනිත්තුවේදී අවසන් නොවන බව සහතික කිරීම සඳහා, අපි භාරය සපයන්නේ එක් IP එකකින් නොව අපගේම උප ජාලයෙනි. තවද, සැලකිය යුතු බරක් නිර්මාණය කිරීම සඳහා, අපට අපගේම තරමක් බලවත් පරීක්ෂණ සේවාදායකයක් ඇත.

උපකල්පනය කරයි

ඕනෑවට වඩා හොඳයි කියන්නේ නැහැ
අපට සම්පතක් අසාර්ථක වීමට ගෙන යා හැකි බර අඩු වන තරමට වඩා හොඳය. ඔබට තත්පරයකට එක් ඉල්ලීමක් මත හෝ විනාඩියකට එක් ඉල්ලීමක් මත වෙබ් අඩවිය ක්‍රියා කිරීම නැවැත්විය හැකි නම්, එය විශිෂ්ටයි. මක්නිසාද යත් පහත් නීතියට අනුව, භාවිතා කරන්නන් හෝ පහර දෙන්නන් අහම්බෙන් මෙම විශේෂිත අවදානමට වැටෙනු ඇත.

සම්පූර්ණ අසාර්ථකත්වයට වඩා අර්ධ අසාර්ථකත්වය හොඳය
අපි සෑම විටම පද්ධති විෂමජාතීය කිරීමට උපදෙස් දෙන්නෙමු. එපමණක් නොව, බහාලුම්කරණයෙන් පමණක් නොව භෞතික මට්ටමින් ඒවා වෙන් කිරීම වටී. භෞතික වෙන්වීමේදී, වෙබ් අඩවියේ යමක් අසමත් වුවද, එය සම්පූර්ණයෙන්ම වැඩ කිරීම නතර නොකරනු ඇති බවට ඉහළ සම්භාවිතාවක් ඇති අතර, පරිශීලකයින්ට අවම වශයෙන් ක්රියාකාරිත්වයේ කොටසක් වෙත ප්රවේශය දිගටම පවතිනු ඇත.

යහපත් ගෘහ නිර්මාණ ශිල්පය තිරසාරභාවය සඳහා පදනම වේ
සම්පතක වැරදි ඉවසීම සහ ප්‍රහාර සහ බරට ඔරොත්තු දීමේ හැකියාව සැලසුම් කිරීමේ අදියරේදී, ඇත්ත වශයෙන්ම, සටහන් පොතක පළමු ගැලීම් සටහන් ඇඳීමේ අදියරේදී තැබිය යුතුය. මක්නිසාද යත් මාරාන්තික දෝෂ රිංගා ඇත්නම්, අනාගතයේදී ඒවා නිවැරදි කිරීමට හැකි නමුත් එය ඉතා අපහසුය.

කේතය පමණක් නොව, වින්යාසය ද හොඳ විය යුතුය
බොහෝ අය සිතන්නේ හොඳ සංවර්ධන කණ්ඩායමක් වැරදි ඉවසන සේවාවක් සහතික කිරීමක් බවයි. හොඳ සංවර්ධන කණ්ඩායමක් ඇත්ත වශයෙන්ම අවශ්‍ය වේ, නමුත් හොඳ මෙහෙයුම්, හොඳ DevOps ද තිබිය යුතුය. එනම්, අපට ලිනක්ස් සහ ජාලය නිවැරදිව වින්‍යාස කරන, nginx හි වින්‍යාස නිවැරදිව ලියන්න, සීමාවන් සකසන විශේෂඥයින් අවශ්‍ය වේ. එසේ නොමැති නම්, සම්පත හොඳින් ක්‍රියා කරන්නේ පරීක්ෂා කිරීමේදී පමණක් වන අතර, යම් අවස්ථාවක දී සෑම දෙයක්ම නිෂ්පාදනයේ බිඳී යනු ඇත.

බර සහ ආතති පරීක්ෂාව අතර වෙනස්කම්
බර පරීක්ෂාව මඟින් පද්ධතියේ ක්රියාකාරිත්වයේ සීමාවන් හඳුනා ගැනීමට ඔබට ඉඩ සලසයි. ආතති පරීක්ෂණය පද්ධතියක දුර්වලතා සොයා ගැනීම අරමුණු කර ගෙන ඇති අතර මෙම පද්ධතිය බිඳ දැමීමට සහ ඇතැම් කොටස්වල අසාර්ථක වීමේ ක්රියාවලියේදී එය හැසිරෙන්නේ කෙසේදැයි බැලීමට භාවිතා කරයි. මෙම අවස්ථාවෙහිදී, ආතති පරීක්ෂාව ආරම්භ කිරීමට පෙර භාරයේ ස්වභාවය පාරිභෝගිකයා නොදැන සිටියි.

L7 ප්‍රහාරවල සුවිශේෂී ලක්ෂණ

අපි සාමාන්‍යයෙන් L7 සහ L3&4 මට්ටම් වල loads වර්ග load වලට බෙදනවා. L7 යනු යෙදුම් මට්ටමේ බරකි, බොහෝ විට එයින් අදහස් වන්නේ HTTP පමණි, නමුත් අපි අදහස් කරන්නේ TCP ප්‍රොටෝකෝල මට්ටමේ ඕනෑම බරක්.
L7 ප්‍රහාරවලට යම් සුවිශේෂී ලක්ෂණ ඇත. පළමුවෙන්ම, ඒවා කෙලින්ම යෙදුමට පැමිණේ, එනම්, ඒවා ජාල මාධ්‍ය හරහා පිළිබිඹු වනු ඇතැයි සිතිය නොහැක. එවැනි පහරදීම් තර්කනය භාවිතා කරන අතර, මේ නිසා, ඔවුන් CPU, මතකය, තැටිය, දත්ත සමුදාය සහ අනෙකුත් සම්පත් ඉතා කාර්යක්ෂමව සහ අඩු තදබදයක් සහිතව පරිභෝජනය කරයි.

HTTP ගංවතුර

ඕනෑම ප්‍රහාරයකදී, භාරය හැසිරවීමට වඩා නිර්මාණය කිරීම පහසු වන අතර L7 සම්බන්ධයෙන්ද මෙය සත්‍ය වේ. ප්‍රහාරක ගමනාගමනය නීත්‍යානුකූල ගමනාගමනයෙන් වෙන්කර හඳුනා ගැනීම සැමවිටම පහසු නොවන අතර බොහෝ විට මෙය සංඛ්‍යාතය අනුව කළ හැකිය, නමුත් සියල්ල නිවැරදිව සැලසුම් කර ඇත්නම්, ප්‍රහාරය කොතැනද සහ නීත්‍යානුකූල ඉල්ලීම් කොතැනද යන්න ලඝු-සටහන් වලින් තේරුම් ගත නොහැක.
පළමු උදාහරණයක් ලෙස, HTTP ගංවතුර ප්‍රහාරයක් සලකා බලන්න. එවැනි ප්‍රහාර සාමාන්‍යයෙන් ඉතා බලවත් බව ප්‍රස්ථාරයෙන් පෙන්වයි; පහත උදාහරණයේ උපරිම ඉල්ලීම් සංඛ්‍යාව විනාඩියකට 600 ඉක්මවා ඇත.

HTTP ගංවතුර යනු බර සෑදීමට පහසුම ක්‍රමයයි. සාමාන්‍යයෙන්, එය ApacheBench වැනි යම් බරක් පරීක්ෂා කිරීමේ මෙවලමක් ගන්නා අතර ඉල්ලීමක් සහ ඉලක්කයක් සකසයි. එවැනි සරල ප්‍රවේශයක් සමඟ, සේවාදායක හැඹිලියට ධාවනය වීමේ ඉහළ සම්භාවිතාවක් ඇත, නමුත් එය මඟ හැරීම පහසුය. උදාහරණයක් ලෙස, ඉල්ලීමට අහඹු තන්තු එකතු කිරීම, එය නැවුම් පිටුවකට නිරන්තරයෙන් සේවය කිරීමට සේවාදායකයට බල කරයි.
එසේම, බරක් නිර්මාණය කිරීමේ ක්රියාවලියේදී පරිශීලක නියෝජිතයා ගැන අමතක නොකරන්න. ජනප්‍රිය පරීක්ෂණ මෙවලම්වල බොහෝ පරිශීලක-නියෝජිතයන් පද්ධති පරිපාලකයින් විසින් පෙරහන් කරනු ලබන අතර, මෙම අවස්ථාවේ දී භාරය හුදෙක් පසුපෙළ වෙත ළඟා නොවිය හැකිය. බ්‍රවුසරයෙන් වැඩි හෝ අඩු වලංගු ශීර්ෂයක් ඉල්ලීමට ඇතුළත් කිරීමෙන් ඔබට ප්‍රතිඵලය සැලකිය යුතු ලෙස වැඩිදියුණු කළ හැක.
HTTP ගංවතුර ප්‍රහාර සරල වන තරමටම, ඒවායේ අඩුපාඩුද ඇත. පළමුව, බර නිර්මාණය කිරීම සඳහා විශාල බලයක් අවශ්ය වේ. දෙවනුව, එවැනි ප්‍රහාර හඳුනා ගැනීම ඉතා පහසුය, විශේෂයෙන් ඒවා එක් ලිපිනයකින් පැමිණේ නම්. එහි ප්‍රතිඵලයක් වශයෙන්, ඉල්ලීම් වහාම පද්ධති පරිපාලකයින් විසින් හෝ සපයන්නන්ගේ මට්ටමින් පෙරීමට පටන් ගනී.

සෙවිය යුතු දේ

කාර්යක්ෂමතාව අහිමි නොවී තත්පරයකට ඉල්ලීම් සංඛ්යාව අඩු කිරීම සඳහා, ඔබ කුඩා පරිකල්පනය පෙන්වීමට සහ වෙබ් අඩවිය ගවේෂණය කිරීමට අවශ්ය වේ. මේ අනුව, ඔබට නාලිකාව හෝ සේවාදායකය පමණක් නොව, යෙදුමේ තනි කොටස්, උදාහරණයක් ලෙස, දත්ත සමුදායන් හෝ ගොනු පද්ධති පූරණය කළ හැකිය. විශාල ගණනය කිරීම් සිදු කරන වෙබ් අඩවියේ ස්ථාන සඳහාද ඔබට සෙවිය හැකිය: කැල්කියුලේටර, නිෂ්පාදන තේරීම් පිටු, ආදිය. අවසාන වශයෙන්, බොහෝ විට සිදුවන්නේ වෙබ් අඩවියේ පේළි ලක්ෂ ගණනක පිටුවක් ජනනය කරන යම් ආකාරයක PHP ස්ක්‍රිප්ට් එකක් තිබීමයි. එවැනි ස්ක්‍රිප්ට් එකක් සේවාදායකයා සැලකිය යුතු ලෙස පටවන අතර ප්‍රහාරයක් සඳහා ඉලක්කයක් විය හැකිය.

කොහෙද බලන්න

පරීක්ෂා කිරීමට පෙර අපි සම්පතක් පරිලෝකනය කරන විට, අපි මුලින්ම බලන්නේ, ඇත්ත වශයෙන්ම, වෙබ් අඩවියම ය. අපි සියලු වර්ගවල ආදාන ක්ෂේත්ර, බර ගොනු සොයමින් සිටිමු - සාමාන්යයෙන්, සම්පත සඳහා ගැටළු ඇති කළ හැකි සහ එහි ක්රියාකාරිත්වය මන්දගාමී විය හැකි සෑම දෙයක්ම. ගූගල් ක්‍රෝම් සහ ෆයර්ෆොක්ස් හි බානල් සංවර්ධන මෙවලම් මෙහි උදවු කරයි, පිටු ප්‍රතිචාර වේලාවන් පෙන්වයි.
අපි උප ඩොමේන් ද පරිලෝකනය කරමු. උදාහරණයක් ලෙස, යම් අන්තර්ජාල වෙළඳසැලක් ඇත, 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 භාවිතයෙන් බයිට් හෝ කිලෝබයිට් කිහිපයකට සම්පීඩනය කර එය වෙබ් අඩවියට යවන්නෙමු. එවිට එය unzip කර ඉතා රසවත් බලපෑමක් ලබා ගනී.

විවේක API

Rest API වැනි ජනප්‍රිය සේවාවන් කෙරෙහි මඳක් අවධානය යොමු කිරීමට මම කැමැත්තෙමි. Rest API සුරක්ෂිත කිරීම සාමාන්‍ය වෙබ් අඩවියකට වඩා ඉතා අපහසුය. මුරපද තිරිසන් බලයෙන් සහ වෙනත් නීති විරෝධී ක්‍රියාකාරකම් වලින් ආරක්ෂා කිරීමේ සුළු ක්‍රම පවා Rest API සඳහා ක්‍රියා නොකරයි.
Rest API එක කෙලින්ම database එකට ප්‍රවේශ වෙන නිසා කඩන්න ලේසියි. ඒ අතරම, එවැනි සේවාවක් අසාර්ථක වීම ව්යාපාරයට බෙහෙවින් බරපතල ප්රතිවිපාක ඇති කරයි. කාරණය නම්, Rest API සාමාන්‍යයෙන් ප්‍රධාන වෙබ් අඩවිය සඳහා පමණක් නොව, ජංගම යෙදුම සහ සමහර අභ්‍යන්තර ව්‍යාපාරික සම්පත් සඳහාද භාවිතා වේ. මේ සියල්ල පහත වැටෙන්නේ නම්, සරල වෙබ් අඩවියක් අසාර්ථක වූ විට එහි බලපෑම වඩා ශක්තිමත් වේ.

බර අන්තර්ගතය පූරණය වේ

සංකීර්ණ ක්‍රියාකාරීත්වයක් නොමැති සාමාන්‍ය තනි පිටු යෙදුමක්, ගොඩබෑමේ පිටුවක් හෝ ව්‍යාපාරික කාඩ්පත් වෙබ් අඩවියක් පරීක්ෂා කිරීමට අපට ඉදිරිපත් වන්නේ නම්, අපි බර අන්තර්ගතයක් සොයමු. උදාහරණයක් ලෙස, සේවාදායකය යවන විශාල පින්තූර, ද්විමය ගොනු, pdf ලේඛන - අපි මේ සියල්ල බාගත කිරීමට උත්සාහ කරමු. එවැනි පරීක්ෂණ ගොනු පද්ධතිය හොඳින් පටවන අතර නාලිකා අවහිර කරයි, එබැවින් ඵලදායී වේ. එනම්, ඔබ සේවාදායකය නොතබන නමුත්, අඩු වේගයකින් විශාල ගොනුවක් බාගත කිරීම, ඔබ හුදෙක් ඉලක්ක සේවාදායකයේ නාලිකාව අවහිර වන අතර පසුව සේවා ප්රතික්ෂේප කිරීමක් සිදුවනු ඇත.
එවැනි පරීක්ෂණයක උදාහරණයක් පෙන්නුම් කරන්නේ 30 RPS වේගයකින් වෙබ් අඩවිය ප්‍රතිචාර දැක්වීම නැවැත්වූ බව හෝ 500 වැනි සේවාදායක දෝෂ නිපදවන බවයි.

සේවාදායකයන් සැකසීම ගැන අමතක නොකරන්න. බොහෝ විට පුද්ගලයෙකු අතථ්‍ය යන්ත්‍රයක් මිල දී ගෙන, එහි Apache ස්ථාපනය කර, පෙරනිමියෙන් සියල්ල වින්‍යාස කර, PHP යෙදුමක් ස්ථාපනය කර ඇති බව ඔබට දැක ගත හැකිය, සහ පහත ප්‍රති result ලය ඔබට දැක ගත හැකිය.

මෙහි බර මූලයට ගොස් RPS 10 ක් පමණි. අපි විනාඩි 5 ක් බලා සිටි අතර සේවාදායකය බිඳ වැටුණි. ඔහු වැටුණේ ඇයිද යන්න සම්පූර්ණයෙන්ම නොදන්නා බව සත්‍යයකි, නමුත් ඔහුට මතකය ඕනෑවට වඩා තිබූ බවත් ඒ නිසා ප්‍රතිචාර දැක්වීම නැවැත්වූ බවට උපකල්පනයක් තිබේ.

තරංග පදනම් වූ

පසුගිය වසර දෙක තුළ තරංග ප්‍රහාර ඉතා ජනප්‍රිය විය. මෙයට හේතුව බොහෝ සංවිධාන DDoS ආරක්ෂාව සඳහා ඇතැම් දෘඩාංග මිලදී ගැනීමයි, ප්‍රහාරය පෙරීම ආරම්භ කිරීම සඳහා සංඛ්‍යාලේඛන රැස් කිරීමට යම් කාලයක් අවශ්‍ය වේ. එනම්, ඔවුන් පළමු තත්පර 30-40 තුළ ප්‍රහාරය පෙරන්නේ නැත, මන්ද ඔවුන් දත්ත රැස් කර ඉගෙන ගන්නා බැවිනි. ඒ අනුව, මෙම තත්පර 30-40 තුළ ඔබට වෙබ් අඩවියේ බොහෝ දේ දියත් කළ හැකි අතර, සියලු ඉල්ලීම් නිෂ්කාශනය වන තුරු සම්පත දිගු කාලයක් පවතිනු ඇත.
පහත ප්‍රහාරයේ දී, මිනිත්තු 10 ක පරතරයක් ඇති අතර, ඉන් පසුව ප්‍රහාරයේ නව, වෙනස් කරන ලද කොටසක් පැමිණියේය.

එනම්, ආරක්ෂකයා ඉගෙන ගත්තේය, පෙරීමට පටන් ගත්තේය, නමුත් ප්‍රහාරයේ නව, සම්පූර්ණයෙන්ම වෙනස් කොටසක් පැමිණ, ආරක්ෂකයා නැවත ඉගෙන ගැනීමට පටන් ගත්තේය. ඇත්ත වශයෙන්ම, පෙරීම වැඩ කිරීම නතර කරයි, ආරක්ෂාව අකාර්යක්ෂම වේ, සහ වෙබ් අඩවිය ලබා ගත නොහැක.
තරංග ප්‍රහාර උච්චයේ ඉතා ඉහළ අගයන් මගින් සංලක්ෂිත වේ, එය L7 සම්බන්ධයෙන් තත්පරයකට ඉල්ලීම් ලක්ෂයක් හෝ මිලියනයකට ළඟා විය හැකිය. අපි L3 සහ 4 ගැන කතා කරන්නේ නම්, ඔබ පැකට් වල ගණන් කළහොත් ගිගාබිට් සිය ගණනක් තදබදයක් හෝ, ඒ අනුව, mpps සිය ගණනක් තිබිය හැකිය.
එවැනි ප්රහාරවල ගැටළුව සමමුහුර්තකරණයයි. ප්‍රහාර පැමිණෙන්නේ බොට්නෙට් එකකින් වන අතර ඉතා විශාල එක් වරක් ස්පයික් සෑදීමට ඉහළ සමමුහුර්ත කිරීමක් අවශ්‍ය වේ. මෙම සම්බන්ධීකරණය සැමවිටම ක්‍රියාත්මක නොවේ: සමහර විට ප්‍රතිදානය යම් ආකාරයක පරාවලයික උච්චයක් වන අතර එය තරමක් කණගාටුදායක ලෙස පෙනේ.

HTTP පමණක් නොවේ

L7 හි HTTP වලට අමතරව, අපි වෙනත් ප්‍රොටෝකෝල භාවිතා කිරීමට කැමතියි. රීතියක් ලෙස, සාමාන්‍ය වෙබ් අඩවියක්, විශේෂයෙන් සාමාන්‍ය සත්කාරකයක්, තැපැල් ප්‍රොටෝකෝල සහ MySQL කැපී පෙනේ. තැපැල් ප්‍රොටෝකෝල දත්ත සමුදායන්ට වඩා අඩු බරකට යටත් වේ, නමුත් ඒවා ඉතා කාර්යක්ෂමව පූරණය කළ හැකි අතර සේවාදායකයේ අධික ලෙස පටවන ලද CPU සමඟ අවසන් වේ.
2016 SSH අනාරක්ෂිත බව සමඟ අපි යථාර්ථවාදීව සාර්ථකත්වයක් අත්කර ගත්තෙමු. දැන් මෙම අවදානම සෑම කෙනෙකුටම පාහේ සවි කර ඇත, නමුත් මෙයින් අදහස් කරන්නේ බර SSH වෙත ඉදිරිපත් කළ නොහැකි බවයි. පුළුවන්. සරලව විශාල අවසර ප්‍රමාණයක් ඇත, SSH සේවාදායකයේ සම්පූර්ණ CPU එක පාහේ අනුභව කරයි, එවිට වෙබ් අඩවිය තත්පරයකට ඉල්ලීම් එකකින් හෝ දෙකකින් බිඳ වැටේ. ඒ අනුව, ලඝු-සටහන් මත පදනම් වූ මෙම ඉල්ලීම් එකක් හෝ දෙකක් නීත්‍යානුකූල පැටවීමකින් වෙන්කර හඳුනාගත නොහැක.
අපි සේවාදායකයන් තුළ විවෘත කරන බොහෝ සම්බන්ධතා ද අදාළ වේ. මීට පෙර, Apache මෙයට වැරදිකරු විය, දැන් nginx මෙයට වැරදිකරු වේ, මන්ද එය බොහෝ විට පෙරනිමියෙන් වින්‍යාස කර ඇත. nginx හට විවෘතව තබාගත හැකි සම්බන්ධතා සංඛ්‍යාව සීමිතය, එබැවින් අපි මෙම සම්බන්ධතා ගණන විවෘත කරමු, nginx තවදුරටත් නව සම්බන්ධතාවයක් පිළිගන්නේ නැත, එහි ප්‍රතිඵලයක් ලෙස වෙබ් අඩවිය ක්‍රියා නොකරයි.
අපගේ පරීක්ෂණ පොකුරේ SSL අතට අත දීම සඳහා ප්‍රමාණවත් CPU ඇත. ප්‍රතිපත්තිමය වශයෙන්, ප්‍රායෝගිකව පෙන්නුම් කරන පරිදි, බොට්නෙට් සමහර විට මෙය කිරීමට ද කැමතියි. එක් අතකින්, ඔබට SSL නොමැතිව කළ නොහැකි බව පැහැදිලිය, මන්ද ගූගල් ප්රතිඵල, ශ්රේණිගත කිරීම, ආරක්ෂාව. අනෙක් අතට, SSL හි අවාසනාවන්ත ලෙස CPU ගැටළුවක් ඇත.

L3&4

අපි L3&4 මට්ටම් වල ප්‍රහාරයක් ගැන කතා කරන විට, අපි සාමාන්‍යයෙන් කතා කරන්නේ සබැඳි මට්ටමේ ප්‍රහාරයක් ගැන ය. SYN-ගංවතුර ප්‍රහාරයක් නොවේ නම්, එවැනි බරක් සෑම විටම පාහේ නීත්‍යානුකූල එකකින් වෙන්කර හඳුනාගත හැකිය. ආරක්ෂක මෙවලම් සඳහා SYN-ගංවතුර ප්‍රහාරවල ගැටලුව වන්නේ ඒවායේ විශාල පරිමාවයි. උපරිම L3&4 අගය 1,5-2 Tbit/s විය. Oracle සහ Google ඇතුළු විශාල සමාගම් සඳහා පවා මෙවැනි තදබදයක් සැකසීම ඉතා අපහසුය.
SYN සහ SYN-ACK යනු සම්බන්ධතාවයක් ස්ථාපනය කිරීමේදී භාවිතා කරන පැකට් වේ. එබැවින්, SYN-ගංවතුර නීත්‍යානුකූල බරකින් වෙන්කර හඳුනා ගැනීම දුෂ්කර ය: මෙය සම්බන්ධතාවයක් ඇති කිරීමට පැමිණි SYN එකක්ද, නැතහොත් ගංවතුරක කොටසක්ද යන්න පැහැදිලි නැත.

UDP-ගංවතුර

සාමාන්‍යයෙන්, ප්‍රහාරකයන්ට අප සතුව ඇති හැකියාවන් නොමැත, එබැවින් ප්‍රහාර සංවිධානය කිරීමට විස්තාරණය භාවිතා කළ හැක. එනම්, ප්‍රහාරකයා අන්තර්ජාලය පරිලෝකනය කර අවදානමට ලක්විය හැකි හෝ වැරදි ලෙස වින්‍යාස කර ඇති සේවාදායකයන් සොයා ගනී, උදාහරණයක් ලෙස, එක් SYN පැකට්ටුවකට ප්‍රතිචාර වශයෙන්, SYN-ACK තුනකින් ප්‍රතිචාර දක්වයි. ඉලක්ක සේවාදායකයේ ලිපිනයෙන් මූලාශ්‍ර ලිපිනය වංචා කිරීමෙන්, තනි පැකට්ටුවකින් තුන් වතාවක් බලය වැඩි කර වින්දිතයා වෙත ගමනාගමනය හරවා යැවිය හැකිය.

ඇම්ප්ලිෆිකේෂන් වල ඇති ගැටළුව නම් ඒවා හඳුනා ගැනීමට අපහසු වීමයි. මෑත උදාහරණ වලට අවදානමට ලක්විය හැකි memcached හි සංවේදී අවස්ථාව ඇතුළත් වේ. ඊට අමතරව, දැන් IoT උපාංග, IP කැමරා විශාල ප්‍රමාණයක් ඇති අතර ඒවා බොහෝ දුරට පෙරනිමියෙන් වින්‍යාස කර ඇති අතර පෙරනිමියෙන් ඒවා වැරදි ලෙස වින්‍යාස කර ඇත, එබැවින් ප්‍රහාරකයන් බොහෝ විට එවැනි උපාංග හරහා ප්‍රහාර එල්ල කරයි.

දුෂ්කර SYN-ගංවතුර

SYN-ගංවතුර බොහෝ විට සංවර්ධකයෙකුගේ දෘෂ්ටි කෝණයෙන් වඩාත්ම සිත්ගන්නා ප්‍රහාරය විය හැකිය. ගැටළුව වන්නේ පද්ධති පරිපාලකයින් බොහෝ විට ආරක්ෂාව සඳහා IP අවහිර කිරීම භාවිතා කිරීමයි. එපමණක් නොව, IP අවහිර කිරීම ස්ක්‍රිප්ට් භාවිතයෙන් ක්‍රියා කරන පද්ධති පරිපාලකයින්ට පමණක් නොව, අවාසනාවකට මෙන්, විශාල මුදලකට මිලදී ගන්නා සමහර ආරක්ෂක පද්ධතිවලට ද බලපායි.
මෙම ක්‍රමය ව්‍යසනයක් බවට පත්විය හැකිය, මන්ද ප්‍රහාරකයන් IP ලිපින ප්‍රතිස්ථාපනය කරන්නේ නම්, සමාගම තමන්ගේම උප ජාලය අවහිර කරනු ඇත. ෆයර්වෝල් තමන්ගේම පොකුරක් අවහිර කරන විට, ප්රතිදානය බාහිර අන්තර්ක්රියා අසාර්ථක වන අතර සම්පත අසාර්ථක වනු ඇත.
එපමණක්ද නොව, ඔබේම ජාලය අවහිර කිරීම අපහසු නැත. සේවාදායකයාගේ කාර්යාලයට Wi-Fi ජාලයක් තිබේ නම්, හෝ විවිධ අධීක්ෂණ පද්ධති භාවිතයෙන් සම්පත් වල ක්‍රියාකාරිත්වය මනිනු ලබන්නේ නම්, අපි මෙම අධීක්ෂණ පද්ධතියේ IP ලිපිනය හෝ සේවාලාභියාගේ කාර්යාල Wi-Fi වෙත ගෙන එය මූලාශ්‍රයක් ලෙස භාවිතා කරමු. අවසානයේදී, සම්පත පවතින බව පෙනේ, නමුත් ඉලක්කගත IP ලිපින අවහිර කර ඇත. මේ අනුව, සමාගමේ නව නිෂ්පාදනය ඉදිරිපත් කරන HighLoad සම්මන්ත්‍රණයේ Wi-Fi ජාලය අවහිර විය හැකි අතර, මෙය යම් ව්‍යාපාරික සහ ආර්ථික පිරිවැයක් දරයි.
පරීක්ෂා කිරීමේදී, අවසර දී ඇති IP ලිපින වෙත පමණක් ගමනාගමනය යැවීමට ගිවිසුම් ඇති බැවින්, අපට කිසිදු බාහිර සම්පත් සමඟ memcached හරහා විස්තාරණය භාවිතා කළ නොහැක. ඒ අනුව, අපි SYN සහ SYN-ACK හරහා විස්තාරණය භාවිතා කරමු, පද්ධතිය SYN-ACK දෙකක් හෝ තුනක් සමඟ SYN යැවීමට ප්‍රතිචාර දක්වන විට සහ ප්‍රතිදානයේදී ප්‍රහාරය දෙගුණයකින් හෝ තුන් ගුණයකින් ගුණ කරයි.

මෙවලම්

L7 කාර්ය භාරය සඳහා අප භාවිතා කරන ප්‍රධාන මෙවලමක් වන්නේ Yandex-tank වේ. විශේෂයෙන්ම, ෆැන්ටම් තුවක්කුවක් ලෙස භාවිතා කරයි, තවද කාට්රිජ් ජනනය කිරීම සඳහා සහ ප්රතිඵල විශ්ලේෂණය කිරීම සඳහා ස්ක්රිප්ට් කිහිපයක් තිබේ.
ජාල ගමනාගමනය විශ්ලේෂණය කිරීමට Tcpdump භාවිතා කරන අතර සේවාදායකය විශ්ලේෂණය කිරීමට Nmap භාවිතා කරයි. L3 සහ 4 මට්ටමින් භාරය සෑදීම සඳහා, OpenSSL සහ DPDK පුස්තකාලය සමඟ අපගේම මැජික් කිහිපයක් භාවිතා කරනු ලැබේ. DPDK යනු ඉන්ටෙල් වෙතින් වන පුස්තකාලයක් වන අතර එමඟින් ඔබට ලිනක්ස් තොගය මගහැර ජාල අතුරුමුහුණත සමඟ වැඩ කිරීමට ඉඩ සලසයි, එමඟින් කාර්යක්ෂමතාව වැඩි කරයි. ස්වාභාවිකවම, අපි DPDK භාවිතා කරන්නේ L3 සහ 4 මට්ටමේ පමණක් නොව, L7 මට්ටමින්ද, එය අපට එක් යන්ත්‍රයකින් තත්පරයකට මිලියන ගණනක ඉල්ලීම් පරාසයක් තුළ ඉතා ඉහළ බර ප්‍රවාහයක් නිර්මාණය කිරීමට ඉඩ සලසයි.
අපි නිශ්චිත පරීක්ෂණ සඳහා ලියන ඇතැම් රථවාහන ජනක යන්ත්‍ර සහ විශේෂ මෙවලම් ද භාවිතා කරමු. SSH යටතේ ඇති දුර්වලතාවය අපි සිහිපත් කරන්නේ නම්, ඉහත කට්ටලය ප්‍රයෝජනයට ගත නොහැක. අපි තැපැල් ප්‍රොටෝකෝලයට පහර දුන්නොත්, අපි තැපැල් උපයෝගිතා ගන්නවා හෝ ඒවා මත ස්ක්‍රිප්ට් ලියන්නෙමු.

සොයා ගැනීම්

අවසාන වශයෙන් මම මෙසේ කියන්නට කැමැත්තෙමි.

• සම්භාව්ය බර පරීක්ෂාවට අමතරව, ආතති පරීක්ෂාව සිදු කිරීම අවශ්ය වේ. හවුල්කරුවෙකුගේ උප කොන්ත්‍රාත්කරු බර පරීක්ෂා කිරීම පමණක් සිදු කළ සැබෑ උදාහරණයක් අපට තිබේ. සම්පත් සාමාන්ය බරට ඔරොත්තු දිය හැකි බව පෙන්නුම් කළේය. නමුත් පසුව අසාමාන්‍ය බරක් දිස් වූ අතර, අඩවි නරඹන්නන් සම්පත ටිකක් වෙනස් ලෙස භාවිතා කිරීමට පටන් ගත් අතර එහි ප්‍රති result ලයක් ලෙස උප කොන්ත්‍රාත්කරු බිම වැතිර සිටියේය. මේ අනුව, ඔබ දැනටමත් DDoS ප්‍රහාරවලින් ආරක්ෂා වී සිටියත්, දුර්වලතා සෙවීම වටී.
• පද්ධතියේ සමහර කොටස් අනෙක් අයගෙන් හුදකලා කිරීම අවශ්ය වේ. ඔබට සෙවීමක් තිබේ නම්, ඔබ එය වෙනම යන්ත්‍ර වෙත ගෙන යා යුතුය, එනම් ඩොකර් වෙතවත් නොවේ. මන්ද සෙවීම හෝ අවසරය අසාර්ථක වුවහොත්, අවම වශයෙන් යමක් දිගටම ක්‍රියාත්මක වනු ඇත. ඔන්ලයින් වෙළඳසැලක නම්, පරිශීලකයින් නාමාවලියෙහි නිෂ්පාදන සොයා ගැනීම, එකතු කරන්නා වෙතින් යාම, ඔවුන් දැනටමත් අවසර දී ඇත්නම් මිල දී ගැනීම හෝ OAuth2 හරහා අවසර දෙනු ඇත.
• සියලු වර්ගවල වලාකුළු සේවා නොසලකා හරින්න එපා.
• CDN ජාල ප්‍රමාදයන් ප්‍රශස්ත කිරීමට පමණක් නොව, නාලිකා වෙහෙසට සහ ස්ථිතික ගමනාගමනයට ගලා ඒම මත ප්‍රහාරවලින් ආරක්ෂා වීමේ මාධ්‍යයක් ලෙසද භාවිතා කරන්න.
• විශේෂිත ආරක්ෂණ සේවාවන් භාවිතා කිරීම අවශ්ය වේ. ඔබට බොහෝ දුරට ප්‍රමාණවත් නාලිකාවක් නොමැති නිසා, ඔබට නාලිකා මට්ටමින් L3 සහ 4 ප්‍රහාරවලින් ආරක්ෂා විය නොහැක. L7 ප්‍රහාර ඉතා විශාල විය හැකි බැවින් ඔබට ඒවාට එරෙහිව සටන් කිරීමටද අපහසුය. Plus, කුඩා ප්රහාර සඳහා සෙවීම තවමත් විශේෂ සේවා, විශේෂ ඇල්ගොරිතමවල පරමාධිපත්යය වේ.
• නිතිපතා යාවත්කාලීන කරන්න. මෙය කර්නලයට පමණක් නොව, SSH ඩීමන් සඳහාද අදාළ වේ, විශේෂයෙන් ඔබ ඒවා පිටතින් විවෘත කර ඇත්නම්. ප්‍රතිපත්තිමය වශයෙන්, සෑම දෙයක්ම යාවත්කාලීන කළ යුතුය, මන්ද ඔබට ඔබ විසින්ම ඇතැම් දුර්වලතා නිරීක්ෂණය කිරීමට නොහැකි වනු ඇත.

මූලාශ්රය: www.habr.com