બચાવ માટે DDoS: અમે કેવી રીતે તણાવ અને લોડ પરીક્ષણો કરીએ છીએ

Variti બૉટો અને DDoS હુમલાઓ સામે રક્ષણ વિકસાવે છે, અને તણાવ અને લોડ પરીક્ષણ પણ કરે છે. HighLoad++ 2018 કોન્ફરન્સમાં અમે વિવિધ પ્રકારના હુમલાઓથી સંસાધનોને કેવી રીતે સુરક્ષિત કરવું તે વિશે વાત કરી. ટૂંકમાં: સિસ્ટમના ભાગોને અલગ કરો, ક્લાઉડ સેવાઓ અને CDN નો ઉપયોગ કરો અને નિયમિતપણે અપડેટ કરો. પરંતુ તમે હજી પણ વિશિષ્ટ કંપનીઓ વિના સુરક્ષાને હેન્ડલ કરી શકશો નહીં :)

ટેક્સ્ટ વાંચતા પહેલા, તમે ટૂંકા અમૂર્ત વાંચી શકો છો કોન્ફરન્સ વેબસાઇટ પર.
અને જો તમને વાંચવું ગમતું નથી અથવા ફક્ત વિડિઓ જોવાની ઇચ્છા છે, તો અમારા અહેવાલનું રેકોર્ડિંગ નીચે સ્પોઇલર હેઠળ છે.

રિપોર્ટનું વિડિયો રેકોર્ડિંગ

ઘણી કંપનીઓ પહેલેથી જ જાણે છે કે લોડ ટેસ્ટિંગ કેવી રીતે કરવું, પરંતુ તમામ સ્ટ્રેસ ટેસ્ટિંગ કરતી નથી. અમારા કેટલાક ગ્રાહકો માને છે કે તેમની સાઇટ અભેદ્ય છે કારણ કે તેમની પાસે હાઇલોડ સિસ્ટમ છે અને તે હુમલાઓથી સારી રીતે રક્ષણ આપે છે. અમે બતાવીએ છીએ કે આ સંપૂર્ણ રીતે સાચું નથી.
અલબત્ત, પરીક્ષણો હાથ ધરતા પહેલા, અમે ગ્રાહક પાસેથી પરવાનગી મેળવીએ છીએ, હસ્તાક્ષરિત અને સ્ટેમ્પ લગાવીએ છીએ અને અમારી મદદથી DDoS હુમલો કોઈપણ પર કરી શકાતો નથી. ગ્રાહક દ્વારા પસંદ કરેલા સમયે પરીક્ષણ હાથ ધરવામાં આવે છે, જ્યારે તેના સંસાધન પર ટ્રાફિક ન્યૂનતમ હોય છે, અને ઍક્સેસ સમસ્યાઓ ક્લાયંટને અસર કરશે નહીં. વધુમાં, પરીક્ષણ પ્રક્રિયા દરમિયાન હંમેશા કંઈક ખોટું થઈ શકે છે, તેથી અમે ગ્રાહક સાથે સતત સંપર્ક કરીએ છીએ. આ તમને માત્ર પ્રાપ્ત પરિણામોની જાણ કરવા માટે જ નહીં, પણ પરીક્ષણ દરમિયાન કંઈક બદલવાની પણ મંજૂરી આપે છે. પરીક્ષણ પૂર્ણ થયા પછી, અમે હંમેશા એક રિપોર્ટ બનાવીએ છીએ જેમાં અમે જોવા મળેલી કોઈપણ ખામીઓ દર્શાવીએ છીએ અને સાઇટની નબળાઈઓને દૂર કરવા માટે ભલામણો આપીએ છીએ.

અમે કેવી રીતે કામ કરી રહ્યા છીએ

પરીક્ષણ કરતી વખતે, અમે બોટનેટનું અનુકરણ કરીએ છીએ. અમે અમારા નેટવર્ક્સ પર સ્થિત ન હોય તેવા ક્લાયન્ટ્સ સાથે કામ કરતા હોવાથી, મર્યાદા અથવા સુરક્ષાને કારણે પરીક્ષણ પ્રથમ મિનિટમાં સમાપ્ત ન થાય તેની ખાતરી કરવા માટે, અમે એક IP થી નહીં, પરંતુ અમારા પોતાના સબનેટથી લોડ સપ્લાય કરીએ છીએ. ઉપરાંત, નોંધપાત્ર લોડ બનાવવા માટે, અમારી પાસે અમારું પોતાનું એકદમ શક્તિશાળી ટેસ્ટ સર્વર છે.

અનુમાન કરે છે

વધુ પડતો અર્થ સારો નથી
ઓછા ભારથી આપણે સંસાધનને નિષ્ફળતામાં લાવી શકીએ, તેટલું સારું. જો તમે પ્રતિ સેકન્ડ એક વિનંતી પર અથવા તો પ્રતિ મિનિટ એક વિનંતી પર સાઇટને કાર્ય કરવાનું બંધ કરી શકો છો, તો તે સરસ છે. કારણ કે અર્થના કાયદા અનુસાર, વપરાશકર્તાઓ અથવા હુમલાખોરો આકસ્મિક રીતે આ ચોક્કસ નબળાઈમાં આવી જશે.

સંપૂર્ણ નિષ્ફળતા કરતાં આંશિક નિષ્ફળતા વધુ સારી છે
અમે હંમેશા સિસ્ટમને વિજાતીય બનાવવાની સલાહ આપીએ છીએ. તદુપરાંત, તેમને ભૌતિક સ્તરે અલગ કરવા યોગ્ય છે, અને માત્ર કન્ટેનરાઇઝેશન દ્વારા જ નહીં. ભૌતિક વિભાજનના કિસ્સામાં, જો સાઇટ પર કંઈક નિષ્ફળ જાય તો પણ, ત્યાં એક ઉચ્ચ સંભાવના છે કે તે સંપૂર્ણપણે કામ કરવાનું બંધ કરશે નહીં, અને વપરાશકર્તાઓને કાર્યક્ષમતાના ઓછામાં ઓછા ભાગની ઍક્સેસ ચાલુ રહેશે.

સારી આર્કિટેક્ચર ટકાઉપણું માટેનો આધાર છે
સંસાધનની ખામી સહનશીલતા અને હુમલાઓ અને ભારનો સામનો કરવાની તેની ક્ષમતા ડિઝાઇનના તબક્કે, હકીકતમાં, નોટબુકમાં પ્રથમ ફ્લોચાર્ટ દોરવાના તબક્કે મૂકવી જોઈએ. કારણ કે જો જીવલેણ ભૂલો થાય છે, તો ભવિષ્યમાં તેને સુધારવી શક્ય છે, પરંતુ તે ખૂબ મુશ્કેલ છે.

માત્ર કોડ જ સારો હોવો જોઈએ નહીં, પણ રૂપરેખા પણ હોવી જોઈએ
ઘણા લોકો માને છે કે સારી ડેવલપમેન્ટ ટીમ એ ખામી-સહિષ્ણુ સેવાની ગેરંટી છે. એક સારી ડેવલપમેન્ટ ટીમ ખરેખર જરૂરી છે, પરંતુ સારા ઓપરેશન્સ, સારા DevOps પણ હોવા જોઈએ. એટલે કે, અમને એવા નિષ્ણાતોની જરૂર છે જેઓ Linux અને નેટવર્કને યોગ્ય રીતે ગોઠવશે, nginx માં યોગ્ય રીતે રૂપરેખાઓ લખશે, મર્યાદાઓ સેટ કરશે વગેરે. નહિંતર, સંસાધન ફક્ત પરીક્ષણમાં જ સારી રીતે કાર્ય કરશે, અને અમુક સમયે ઉત્પાદનમાં બધું તૂટી જશે.

ભાર અને તણાવ પરીક્ષણ વચ્ચે તફાવત
લોડ પરીક્ષણ તમને સિસ્ટમની કામગીરીની મર્યાદાઓને ઓળખવા માટે પરવાનગી આપે છે. તાણ પરીક્ષણનો હેતુ સિસ્ટમમાં નબળાઈઓ શોધવાનો છે અને તેનો ઉપયોગ આ સિસ્ટમને તોડવા અને ચોક્કસ ભાગોની નિષ્ફળતાની પ્રક્રિયામાં તે કેવી રીતે વર્તશે ​​તે જોવા માટે થાય છે. આ કિસ્સામાં, તણાવ પરીક્ષણ શરૂ થાય તે પહેલાં લોડની પ્રકૃતિ સામાન્ય રીતે ગ્રાહક માટે અજાણ રહે છે.

L7 હુમલાના વિશિષ્ટ લક્ષણો

અમે સામાન્ય રીતે L7 અને L3 અને 4 સ્તરો પર લોડના પ્રકારોને લોડમાં વિભાજીત કરીએ છીએ. L7 એ એપ્લીકેશન લેવલ પર લોડ છે, મોટાભાગે તેનો અર્થ ફક્ત HTTP જ થાય છે, પરંતુ અમારો મતલબ TCP પ્રોટોકોલ સ્તરે કોઈપણ લોડ છે.
L7 હુમલામાં અમુક વિશિષ્ટ લક્ષણો હોય છે. સૌ પ્રથમ, તેઓ સીધા જ એપ્લિકેશન પર આવે છે, એટલે કે, તે અસંભવિત છે કે તેઓ નેટવર્ક માધ્યમ દ્વારા પ્રતિબિંબિત થાય. આવા હુમલાઓ તર્કનો ઉપયોગ કરે છે, અને તેના કારણે, તેઓ CPU, મેમરી, ડિસ્ક, ડેટાબેઝ અને અન્ય સંસાધનોનો ખૂબ જ અસરકારક રીતે અને ઓછા ટ્રાફિક સાથે ઉપયોગ કરે છે.

HTTP પૂર

કોઈપણ હુમલાના કિસ્સામાં, લોડને હેન્ડલ કરવા કરતાં બનાવવાનું સરળ છે, અને L7 ના કિસ્સામાં આ પણ સાચું છે. હુમલાના ટ્રાફિકને કાયદેસરના ટ્રાફિકથી અલગ પાડવું હંમેશાં સરળ હોતું નથી, અને મોટેભાગે આ આવર્તન દ્વારા કરી શકાય છે, પરંતુ જો બધું યોગ્ય રીતે આયોજન કરવામાં આવ્યું હોય, તો પછી હુમલો ક્યાં છે અને કાયદેસર વિનંતીઓ ક્યાં છે તે લોગમાંથી સમજવું અશક્ય છે.
પ્રથમ ઉદાહરણ તરીકે, HTTP ફ્લડ એટેકનો વિચાર કરો. ગ્રાફ બતાવે છે કે આવા હુમલા સામાન્ય રીતે ખૂબ જ શક્તિશાળી હોય છે; નીચેના ઉદાહરણમાં, વિનંતીઓની ટોચની સંખ્યા 600 હજાર પ્રતિ મિનિટને વટાવી ગઈ છે.

HTTP ફ્લડ એ લોડ બનાવવાની સૌથી સરળ રીત છે. સામાન્ય રીતે, તે અમુક પ્રકારનું લોડ પરીક્ષણ સાધન લે છે, જેમ કે ApacheBench, અને વિનંતી અને લક્ષ્ય સેટ કરે છે. આવા સરળ અભિગમ સાથે, સર્વર કેશીંગમાં દોડવાની ઉચ્ચ સંભાવના છે, પરંતુ તેને બાયપાસ કરવું સરળ છે. ઉદાહરણ તરીકે, વિનંતિમાં રેન્ડમ સ્ટ્રિંગ્સ ઉમેરવાથી, જે સર્વરને સતત તાજું પૃષ્ઠ સર્વ કરવા માટે દબાણ કરશે.
ઉપરાંત, લોડ બનાવવાની પ્રક્રિયામાં વપરાશકર્તા-એજન્ટ વિશે ભૂલશો નહીં. લોકપ્રિય પરીક્ષણ સાધનોના ઘણા વપરાશકર્તા-એજન્ટ્સ સિસ્ટમ સંચાલકો દ્વારા ફિલ્ટર કરવામાં આવે છે, અને આ કિસ્સામાં લોડ ફક્ત બેકએન્ડ સુધી પહોંચી શકશે નહીં. તમે વિનંતીમાં બ્રાઉઝરમાંથી વધુ કે ઓછા માન્ય હેડર દાખલ કરીને પરિણામમાં નોંધપાત્ર સુધારો કરી શકો છો.
HTTP ફ્લડ હુમલા જેટલા સરળ છે, તેમની ખામીઓ પણ છે. સૌ પ્રથમ, લોડ બનાવવા માટે મોટી માત્રામાં પાવરની જરૂર પડે છે. બીજું, આવા હુમલાઓ શોધવા માટે ખૂબ જ સરળ છે, ખાસ કરીને જો તેઓ એક સરનામાંથી આવે છે. પરિણામે, વિનંતીઓ તરત જ સિસ્ટમ સંચાલકો દ્વારા અથવા તો પ્રદાતા સ્તરે ફિલ્ટર થવાનું શરૂ થાય છે.

શું શોધવું

કાર્યક્ષમતા ગુમાવ્યા વિના પ્રતિ સેકન્ડ વિનંતીઓની સંખ્યા ઘટાડવા માટે, તમારે થોડી કલ્પના બતાવવાની અને સાઇટનું અન્વેષણ કરવાની જરૂર છે. આમ, તમે ફક્ત ચેનલ અથવા સર્વર જ નહીં, પણ એપ્લિકેશનના વ્યક્તિગત ભાગોને પણ લોડ કરી શકો છો, ઉદાહરણ તરીકે, ડેટાબેસેસ અથવા ફાઇલ સિસ્ટમ્સ. તમે સાઇટ પર તે સ્થાનો પણ શોધી શકો છો જે મોટી ગણતરીઓ કરે છે: કેલ્ક્યુલેટર, ઉત્પાદન પસંદગી પૃષ્ઠો, વગેરે. છેવટે, તે ઘણીવાર બને છે કે સાઇટમાં અમુક પ્રકારની PHP સ્ક્રિપ્ટ હોય છે જે લાખો હજાર લીટીઓનું પૃષ્ઠ બનાવે છે. આવી સ્ક્રિપ્ટ સર્વરને નોંધપાત્ર રીતે લોડ કરે છે અને હુમલા માટે લક્ષ્ય બની શકે છે.

ક્યાં જોઈએ છે

જ્યારે અમે પરીક્ષણ કરતા પહેલા કોઈ સંસાધનને સ્કેન કરીએ છીએ, ત્યારે અમે સૌ પ્રથમ, અલબત્ત, સાઇટ પર જ જોઈએ છીએ. અમે તમામ પ્રકારના ઇનપુટ ફીલ્ડ્સ, ભારે ફાઇલો શોધી રહ્યા છીએ - સામાન્ય રીતે, દરેક વસ્તુ જે સંસાધન માટે સમસ્યાઓ ઊભી કરી શકે છે અને તેની કામગીરીને ધીમું કરી શકે છે. ગૂગલ ક્રોમ અને ફાયરફોક્સમાં મામૂલી વિકાસ સાધનો અહીં મદદ કરે છે, પૃષ્ઠ પ્રતિસાદનો સમય દર્શાવે છે.
અમે સબડોમેન્સ પણ સ્કેન કરીએ છીએ. ઉદાહરણ તરીકે, ત્યાં ચોક્કસ ઓનલાઈન સ્ટોર છે, abc.com, અને તેમાં સબડોમેઈન admin.abc.com છે. મોટે ભાગે, આ અધિકૃતતા સાથે એડમિન પેનલ છે, પરંતુ જો તમે તેના પર ભાર મૂકે છે, તો તે મુખ્ય સંસાધન માટે સમસ્યાઓ ઊભી કરી શકે છે.
સાઇટમાં સબડોમેન api.abc.com હોઈ શકે છે. મોટે ભાગે, આ મોબાઇલ એપ્લિકેશન્સ માટેનું સંસાધન છે. એપ્લિકેશન એપ સ્ટોર અથવા ગૂગલ પ્લેમાં મળી શકે છે, એક વિશિષ્ટ એક્સેસ પોઈન્ટ ઇન્સ્ટોલ કરો, API ને ડિસેક્ટ કરો અને ટેસ્ટ એકાઉન્ટ્સ રજીસ્ટર કરો. સમસ્યા એ છે કે લોકો વારંવાર વિચારે છે કે જે કંઈપણ અધિકૃતતા દ્વારા સુરક્ષિત છે તે સેવા હુમલાઓને નકારવા માટે પ્રતિરક્ષા છે. માનવામાં આવે છે કે, અધિકૃતતા એ શ્રેષ્ઠ કેપ્ચા છે, પરંતુ તે નથી. 10-20 ટેસ્ટ એકાઉન્ટ્સ બનાવવાનું સરળ છે, પરંતુ તેમને બનાવીને, અમે જટિલ અને અસ્પષ્ટ કાર્યક્ષમતાની ઍક્સેસ મેળવીએ છીએ.
સ્વાભાવિક રીતે, આપણે ઇતિહાસ જોઈએ છીએ, robots.txt અને WebArchive, ViewDNS પર, અને સંસાધનના જૂના સંસ્કરણો જોઈએ છીએ. કેટલીકવાર એવું બને છે કે વિકાસકર્તાઓએ mail2.yandex.net ને રોલઆઉટ કર્યું છે, પરંતુ જૂનું સંસ્કરણ, mail.yandex.net, બાકી છે. આ mail.yandex.net હવે સમર્થિત નથી, વિકાસ સંસાધનો તેને ફાળવવામાં આવતા નથી, પરંતુ તે ડેટાબેઝનો ઉપયોગ કરવાનું ચાલુ રાખે છે. તદનુસાર, જૂના સંસ્કરણનો ઉપયોગ કરીને, તમે બેકએન્ડના સંસાધનો અને લેઆઉટ પાછળની દરેક વસ્તુનો અસરકારક રીતે ઉપયોગ કરી શકો છો. અલબત્ત, આ હંમેશા થતું નથી, પરંતુ આપણે હજી પણ ઘણી વાર આનો સામનો કરીએ છીએ.
સ્વાભાવિક રીતે, અમે તમામ વિનંતી પરિમાણો અને કૂકી સ્ટ્રક્ચરનું વિશ્લેષણ કરીએ છીએ. તમે, કહો, કૂકીની અંદર JSON એરેમાં અમુક મૂલ્ય ડમ્પ કરી શકો છો, ઘણાં બધાં માળખાં બનાવી શકો છો અને સંસાધનને ગેરવાજબી રીતે લાંબા સમય સુધી કામ કરી શકો છો.

શોધ લોડ

કોઈ સાઇટ પર સંશોધન કરતી વખતે ધ્યાનમાં આવતી પ્રથમ વસ્તુ એ છે કે ડેટાબેઝ લોડ કરવો, કારણ કે લગભગ દરેકની શોધ છે, અને લગભગ દરેક માટે, કમનસીબે, તે નબળી રીતે સુરક્ષિત છે. કેટલાક કારણોસર, વિકાસકર્તાઓ શોધ પર પૂરતું ધ્યાન આપતા નથી. પરંતુ અહીં એક ભલામણ છે - તમારે સમાન પ્રકારની વિનંતીઓ કરવી જોઈએ નહીં, કારણ કે તમને કેશીંગનો સામનો કરવો પડી શકે છે, જેમ કે HTTP ફ્લડના કિસ્સામાં છે.
ડેટાબેઝમાં રેન્ડમ ક્વેરી કરવી પણ હંમેશા અસરકારક હોતી નથી. શોધ સાથે સંબંધિત કીવર્ડ્સની સૂચિ બનાવવાનું વધુ સારું છે. જો આપણે ઓનલાઈન સ્ટોરના ઉદાહરણ પર પાછા ફરીએ: ચાલો કહીએ કે સાઇટ કારના ટાયર વેચે છે અને તમને ટાયરની ત્રિજ્યા, કારનો પ્રકાર અને અન્ય પરિમાણો સેટ કરવાની મંજૂરી આપે છે. તદનુસાર, સંબંધિત શબ્દોના સંયોજનો ડેટાબેઝને વધુ જટિલ પરિસ્થિતિઓમાં કામ કરવા દબાણ કરશે.
વધુમાં, તે પૃષ્ઠ ક્રમાંકનનો ઉપયોગ કરવા યોગ્ય છે: શોધ માટે પ્રથમ કરતાં શોધ પરિણામોના અંતિમ પૃષ્ઠને પરત કરવું વધુ મુશ્કેલ છે. એટલે કે, પૃષ્ઠ ક્રમાંકનની મદદથી તમે લોડને સહેજ વૈવિધ્યીકરણ કરી શકો છો.
નીચેનું ઉદાહરણ શોધ લોડ બતાવે છે. તે જોઈ શકાય છે કે પરીક્ષણની પ્રથમ સેકન્ડથી પ્રતિ સેકન્ડ દસ વિનંતીઓની ઝડપે, સાઇટ નીચે ગઈ અને પ્રતિસાદ આપ્યો ન હતો.

શોધ ન હોય તો?

જો ત્યાં કોઈ શોધ નથી, તો તેનો અર્થ એ નથી કે સાઇટમાં અન્ય સંવેદનશીલ ઇનપુટ ફીલ્ડ્સ શામેલ નથી. આ ક્ષેત્ર અધિકૃતતા હોઈ શકે છે. આજકાલ, ડેવલપર્સ લોગિન ડેટાબેઝને રેઈન્બો ટેબલ એટેકથી બચાવવા માટે જટિલ હેશ બનાવવાનું પસંદ કરે છે. આ સારું છે, પરંતુ આવા હેશ ઘણા બધા CPU સંસાધનોનો ઉપયોગ કરે છે. ખોટા અધિકૃતતાઓનો મોટો પ્રવાહ પ્રોસેસરની નિષ્ફળતા તરફ દોરી જાય છે, અને પરિણામે, સાઇટ કામ કરવાનું બંધ કરે છે.
ટિપ્પણીઓ અને પ્રતિસાદ માટે તમામ પ્રકારના સ્વરૂપોની સાઇટ પર હાજરી એ ત્યાં ખૂબ મોટા ગ્રંથો મોકલવાનું અથવા ફક્ત એક વિશાળ પૂરનું કારણ છે. કેટલીકવાર સાઇટ્સ gzip ફોર્મેટ સહિત જોડાયેલ ફાઇલોને સ્વીકારે છે. આ કિસ્સામાં, અમે 1TB ફાઇલ લઈએ છીએ, તેને gzip નો ઉપયોગ કરીને કેટલાક બાઇટ્સ અથવા કિલોબાઇટ્સમાં સંકુચિત કરીએ છીએ અને તેને સાઇટ પર મોકલીએ છીએ. પછી તેને અનઝિપ કરવામાં આવે છે અને ખૂબ જ રસપ્રદ અસર પ્રાપ્ત થાય છે.

રેસ્ટ API

હું રેસ્ટ API જેવી લોકપ્રિય સેવાઓ પર થોડું ધ્યાન આપવા માંગુ છું. રેસ્ટ API ને સુરક્ષિત કરવું એ નિયમિત વેબસાઇટ કરતાં વધુ મુશ્કેલ છે. પાસવર્ડ બ્રુટ ફોર્સ અને અન્ય ગેરકાયદેસર પ્રવૃત્તિ સામે રક્ષણની તુચ્છ પદ્ધતિઓ પણ બાકીના API માટે કામ કરતી નથી.
બાકીના API ને તોડવું ખૂબ જ સરળ છે કારણ કે તે સીધા ડેટાબેઝને ઍક્સેસ કરે છે. તે જ સમયે, આવી સેવાની નિષ્ફળતા વ્યવસાય માટે ખૂબ ગંભીર પરિણામોનો સમાવેશ કરે છે. હકીકત એ છે કે બાકીના API નો ઉપયોગ સામાન્ય રીતે ફક્ત મુખ્ય વેબસાઇટ માટે જ નહીં, પણ મોબાઇલ એપ્લિકેશન અને કેટલાક આંતરિક વ્યવસાય સંસાધનો માટે પણ થાય છે. અને જો આ બધું પડે છે, તો અસર સરળ વેબસાઇટ નિષ્ફળતાના કિસ્સામાં કરતાં ઘણી મજબૂત છે.

ભારે સામગ્રી લોડ કરી રહ્યું છે

જો અમને કેટલીક સામાન્ય સિંગલ-પેજ એપ્લિકેશન, લેન્ડિંગ પેજ અથવા બિઝનેસ કાર્ડ વેબસાઇટ કે જેમાં જટિલ કાર્યક્ષમતા નથી, ચકાસવાની ઓફર કરવામાં આવે છે, તો અમે ભારે સામગ્રી શોધીએ છીએ. ઉદાહરણ તરીકે, સર્વર મોકલે છે તે મોટી છબીઓ, બાઈનરી ફાઇલો, પીડીએફ દસ્તાવેજીકરણ - અમે આ બધું ડાઉનલોડ કરવાનો પ્રયાસ કરીએ છીએ. આવા પરીક્ષણો ફાઇલ સિસ્ટમને સારી રીતે લોડ કરે છે અને ચેનલોને બંધ કરે છે, અને તેથી અસરકારક છે. એટલે કે, જો તમે સર્વર ડાઉન ન કરો તો પણ, ઓછી ઝડપે મોટી ફાઇલ ડાઉનલોડ કરીને, તમે ફક્ત લક્ષ્ય સર્વરની ચેનલને ક્લોગ કરશો અને પછી સેવાનો ઇનકાર થશે.
આવા પરીક્ષણનું ઉદાહરણ બતાવે છે કે 30 RPS ની ઝડપે સાઇટે પ્રતિસાદ આપવાનું બંધ કર્યું અથવા 500મી સર્વર ભૂલો ઉત્પન્ન કરી.

સર્વર્સ સેટ કરવા વિશે ભૂલશો નહીં. તમે ઘણીવાર શોધી શકો છો કે કોઈ વ્યક્તિએ વર્ચ્યુઅલ મશીન ખરીદ્યું છે, ત્યાં અપાચે ઇન્સ્ટોલ કર્યું છે, ડિફૉલ્ટ રૂપે બધું ગોઠવ્યું છે, PHP એપ્લિકેશન ઇન્સ્ટોલ કરી છે અને નીચે તમે પરિણામ જોઈ શકો છો.

અહીં ભાર રૂટ પર ગયો અને માત્ર 10 આરપીએસ જેટલો હતો. અમે 5 મિનિટ રાહ જોઈ અને સર્વર ક્રેશ થઈ ગયું. તે સાચું છે કે તે શા માટે પડ્યો તે સંપૂર્ણ રીતે જાણી શકાયું નથી, પરંતુ એક ધારણા છે કે તેની પાસે ખૂબ જ યાદશક્તિ હતી અને તેથી તેણે જવાબ આપવાનું બંધ કર્યું.

તરંગ આધારિત

છેલ્લા એક-બે વર્ષમાં, તરંગોના હુમલા ખૂબ લોકપ્રિય બન્યા છે. આ એ હકીકતને કારણે છે કે ઘણી સંસ્થાઓ DDoS સુરક્ષા માટે હાર્ડવેરના ચોક્કસ ટુકડાઓ ખરીદે છે, જેને હુમલાને ફિલ્ટર કરવાનું શરૂ કરવા માટે આંકડા એકઠા કરવા માટે ચોક્કસ સમયની જરૂર પડે છે. એટલે કે, તેઓ પ્રથમ 30-40 સેકંડમાં હુમલાને ફિલ્ટર કરતા નથી, કારણ કે તેઓ ડેટા એકઠા કરે છે અને શીખે છે. તદનુસાર, આ 30-40 સેકંડમાં તમે સાઇટ પર એટલું બધું લોન્ચ કરી શકો છો કે જ્યાં સુધી બધી વિનંતીઓ સાફ ન થાય ત્યાં સુધી સંસાધન લાંબા સમય સુધી પડેલું રહેશે.
નીચેના હુમલાના કિસ્સામાં, 10 મિનિટનો અંતરાલ હતો, જેના પછી હુમલાનો નવો, સંશોધિત ભાગ આવ્યો.

એટલે કે, સંરક્ષણ શીખ્યા, ફિલ્ટર કરવાનું શરૂ કર્યું, પરંતુ હુમલાનો એક નવો, સંપૂર્ણપણે અલગ ભાગ આવ્યો, અને સંરક્ષણ ફરીથી શીખવાનું શરૂ કર્યું. હકીકતમાં, ફિલ્ટરિંગ કામ કરવાનું બંધ કરે છે, સુરક્ષા બિનઅસરકારક બની જાય છે, અને સાઇટ અનુપલબ્ધ છે.
તરંગોના હુમલાઓ ટોચ પર ખૂબ ઊંચા મૂલ્યો દ્વારા વર્ગીકૃત કરવામાં આવે છે, તે L7 ના કિસ્સામાં, પ્રતિ સેકન્ડ એક લાખ અથવા એક મિલિયન વિનંતીઓ સુધી પહોંચી શકે છે. જો આપણે L3 અને 4 વિશે વાત કરીએ, તો સેંકડો ગીગાબિટ ટ્રાફિક હોઈ શકે છે, અથવા, તે મુજબ, સેંકડો mpps, જો તમે પેકેટમાં ગણો છો.
આવા હુમલાઓની સમસ્યા સુમેળ છે. હુમલાઓ બોટનેટમાંથી આવે છે અને ખૂબ મોટી વન-ટાઇમ સ્પાઇક બનાવવા માટે ઉચ્ચ ડિગ્રી સિંક્રનાઇઝેશનની જરૂર પડે છે. અને આ સંકલન હંમેશા કામ કરતું નથી: કેટલીકવાર આઉટપુટ અમુક પ્રકારની પેરાબોલિક પીક હોય છે, જે તેના બદલે દયનીય લાગે છે.

એકલા 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 હતું. Oracle અને Google સહિત મોટી કંપનીઓ માટે પણ આ પ્રકારના ટ્રાફિકની પ્રક્રિયા કરવી ખૂબ જ મુશ્કેલ છે.
SYN અને SYN-ACK એ પેકેટો છે જેનો ઉપયોગ કનેક્શન સ્થાપિત કરતી વખતે થાય છે. તેથી, SYN- પૂરને કાયદેસરના ભારથી અલગ પાડવું મુશ્કેલ છે: તે સ્પષ્ટ નથી કે આ એક SYN છે જે જોડાણ સ્થાપિત કરવા માટે આવ્યું છે અથવા પૂરનો ભાગ છે.

UDP-પૂર

સામાન્ય રીતે, હુમલાખોરો પાસે આપણી પાસે હોય તેવી ક્ષમતાઓ હોતી નથી, તેથી એમ્પ્લીફિકેશનનો ઉપયોગ હુમલાઓનું આયોજન કરવા માટે થઈ શકે છે. એટલે કે, હુમલાખોર ઈન્ટરનેટ સ્કેન કરે છે અને ક્યાં તો સંવેદનશીલ અથવા ખોટી રીતે ગોઠવેલ સર્વર્સ શોધે છે જે, ઉદાહરણ તરીકે, એક SYN પેકેટના પ્રતિભાવમાં, ત્રણ SYN-ACK સાથે પ્રતિસાદ આપે છે. લક્ષ્ય સર્વરના સરનામાંમાંથી સ્રોત સરનામાંને સ્પુફ કરીને, એક પેકેટ વડે ત્રણ વખત પાવર વધારવો અને પીડિતને ટ્રાફિક રીડાયરેક્ટ કરવું શક્ય છે.

એમ્પ્લીફિકેશનની સમસ્યા એ છે કે તે શોધવાનું મુશ્કેલ છે. તાજેતરના ઉદાહરણોમાં સંવેદનશીલ મેમકેશ્ડના સનસનાટીભર્યા કેસનો સમાવેશ થાય છે. ઉપરાંત, હવે ઘણા બધા IoT ઉપકરણો, IP કેમેરા છે, જે મોટે ભાગે ડિફોલ્ટ રૂપે ગોઠવેલા હોય છે, અને મૂળભૂત રીતે તેઓ ખોટી રીતે ગોઠવેલા હોય છે, તેથી જ હુમલાખોરો મોટાભાગે આવા ઉપકરણો દ્વારા હુમલાઓ કરે છે.

મુશ્કેલ SYN- પૂર

વિકાસકર્તાના દૃષ્ટિકોણથી SYN- પૂર એ કદાચ સૌથી રસપ્રદ પ્રકારનો હુમલો છે. સમસ્યા એ છે કે સિસ્ટમ એડમિનિસ્ટ્રેટરો ઘણીવાર સુરક્ષા માટે IP બ્લોકિંગનો ઉપયોગ કરે છે. તદુપરાંત, આઇપી બ્લોકીંગ માત્ર સિસ્ટમ એડમિનિસ્ટ્રેટર્સને અસર કરે છે જેઓ સ્ક્રિપ્ટનો ઉપયોગ કરીને કાર્ય કરે છે, પરંતુ કમનસીબે, કેટલીક સુરક્ષા સિસ્ટમોને પણ અસર કરે છે જે ઘણા પૈસા માટે ખરીદવામાં આવે છે.
આ પદ્ધતિ આપત્તિમાં ફેરવાઈ શકે છે, કારણ કે જો હુમલાખોરો IP સરનામાંને બદલે છે, તો કંપની તેના પોતાના સબનેટને અવરોધિત કરશે. જ્યારે ફાયરવોલ તેના પોતાના ક્લસ્ટરને અવરોધિત કરે છે, ત્યારે આઉટપુટ બાહ્ય ક્રિયાપ્રતિક્રિયાઓને નિષ્ફળ કરશે અને સંસાધન નિષ્ફળ જશે.
તદુપરાંત, તમારા પોતાના નેટવર્કને અવરોધિત કરવું મુશ્કેલ નથી. જો ક્લાયંટની ઑફિસ પાસે Wi-Fi નેટવર્ક છે, અથવા જો વિવિધ મોનિટરિંગ સિસ્ટમ્સનો ઉપયોગ કરીને સંસાધનોનું પ્રદર્શન માપવામાં આવે છે, તો અમે આ મોનિટરિંગ સિસ્ટમ અથવા ક્લાયંટની ઑફિસ Wi-Fiનું IP સરનામું લઈએ છીએ અને તેનો સ્ત્રોત તરીકે ઉપયોગ કરીએ છીએ. અંતે, સંસાધન ઉપલબ્ધ હોય તેવું લાગે છે, પરંતુ લક્ષ્ય IP સરનામાઓ અવરોધિત છે. આમ, હાઈલોડ કોન્ફરન્સનું Wi-Fi નેટવર્ક, જ્યાં કંપનીની નવી પ્રોડક્ટ રજૂ કરવામાં આવી રહી છે, તે બ્લોક થઈ શકે છે, અને આમાં ચોક્કસ વ્યવસાય અને આર્થિક ખર્ચનો સમાવેશ થાય છે.
પરીક્ષણ દરમિયાન, અમે કોઈપણ બાહ્ય સંસાધનો સાથે memcached દ્વારા એમ્પ્લીફિકેશનનો ઉપયોગ કરી શકતા નથી, કારણ કે ત્યાં માત્ર માન્ય IP સરનામાઓ પર ટ્રાફિક મોકલવા માટેના કરારો છે. તદનુસાર, અમે SYN અને SYN-ACK દ્વારા એમ્પ્લીફિકેશનનો ઉપયોગ કરીએ છીએ, જ્યારે સિસ્ટમ બે અથવા ત્રણ SYN-ACK સાથે એક SYN મોકલવા માટે પ્રતિસાદ આપે છે, અને આઉટપુટ પર હુમલો બે અથવા ત્રણ વખત ગુણાકાર થાય છે.

સાધનો

L7 વર્કલોડ માટે અમે જે મુખ્ય સાધનોનો ઉપયોગ કરીએ છીએ તેમાંથી એક છે Yandex-tank. ખાસ કરીને, ફેન્ટમનો ઉપયોગ બંદૂક તરીકે થાય છે, ઉપરાંત કારતુસ બનાવવા અને પરિણામોનું વિશ્લેષણ કરવા માટે ઘણી સ્ક્રિપ્ટો છે.
Tcpdump નો ઉપયોગ નેટવર્ક ટ્રાફિકનું વિશ્લેષણ કરવા માટે થાય છે, અને Nmap નો ઉપયોગ સર્વરનું વિશ્લેષણ કરવા માટે થાય છે. L3&4 સ્તર પર લોડ બનાવવા માટે, OpenSSL અને DPDK લાઇબ્રેરી સાથેના આપણા પોતાના જાદુનો ઉપયોગ કરવામાં આવે છે. DPDK એ ઇન્ટેલની લાઇબ્રેરી છે જે તમને Linux સ્ટેકને બાયપાસ કરીને નેટવર્ક ઇન્ટરફેસ સાથે કામ કરવાની મંજૂરી આપે છે, જેનાથી કાર્યક્ષમતા વધે છે. સ્વાભાવિક રીતે, અમે DPDK નો ઉપયોગ માત્ર L3 અને 4 સ્તર પર જ નહીં, પણ L7 સ્તર પર પણ કરીએ છીએ, કારણ કે તે અમને એક મશીનથી પ્રતિ સેકન્ડમાં ઘણી મિલિયન વિનંતીઓની શ્રેણીમાં, ખૂબ જ ઊંચા લોડ ફ્લો બનાવવાની મંજૂરી આપે છે.
અમે અમુક ટ્રાફિક જનરેટર અને વિશિષ્ટ સાધનોનો પણ ઉપયોગ કરીએ છીએ જે અમે ચોક્કસ પરીક્ષણો માટે લખીએ છીએ. જો આપણે SSH હેઠળની નબળાઈને યાદ કરીએ, તો ઉપરોક્ત સમૂહનો ઉપયોગ કરી શકાતો નથી. જો આપણે મેઈલ પ્રોટોકોલ પર હુમલો કરીએ છીએ, તો અમે મેઈલ યુટિલિટી લઈએ છીએ અથવા તેના પર સ્ક્રિપ્ટ લખીએ છીએ.

તારણો

નિષ્કર્ષ તરીકે હું કહેવા માંગુ છું:

• ક્લાસિક લોડ પરીક્ષણ ઉપરાંત, તણાવ પરીક્ષણ હાથ ધરવા જરૂરી છે. અમારી પાસે એક વાસ્તવિક ઉદાહરણ છે જ્યાં ભાગીદારના પેટા કોન્ટ્રાક્ટરે માત્ર લોડ પરીક્ષણ કર્યું હતું. તે દર્શાવે છે કે સંસાધન સામાન્ય ભારનો સામનો કરી શકે છે. પરંતુ પછી એક અસામાન્ય લોડ દેખાયો, સાઇટ મુલાકાતીઓએ સંસાધનનો ઉપયોગ થોડો અલગ રીતે કરવાનું શરૂ કર્યું, અને પરિણામે પેટા કોન્ટ્રાક્ટર નીચે પડ્યો. આમ, જો તમે પહેલાથી જ DDoS હુમલાઓથી સુરક્ષિત હોવ તો પણ નબળાઈઓ શોધવા યોગ્ય છે.
• સિસ્ટમના કેટલાક ભાગોને અન્યથી અલગ કરવા જરૂરી છે. જો તમારી પાસે શોધ હોય, તો તમારે તેને અલગ મશીનોમાં ખસેડવાની જરૂર છે, એટલે કે, ડોકરમાં પણ નહીં. કારણ કે જો શોધ અથવા અધિકૃતતા નિષ્ફળ જાય, તો ઓછામાં ઓછું કંઈક કામ કરવાનું ચાલુ રાખશે. ઑનલાઇન સ્ટોરના કિસ્સામાં, વપરાશકર્તાઓ સૂચિમાં ઉત્પાદનો શોધવાનું ચાલુ રાખશે, એગ્રીગેટરમાંથી જશે, જો તેઓ પહેલેથી જ અધિકૃત છે તો ખરીદશે અથવા OAuth2 દ્વારા અધિકૃત કરશે.
• તમામ પ્રકારની ક્લાઉડ સેવાઓની અવગણના કરશો નહીં.
• CDN નો ઉપયોગ ફક્ત નેટવર્ક વિલંબને ઑપ્ટિમાઇઝ કરવા માટે જ નહીં, પણ ચેનલના થાક પરના હુમલાઓ સામે રક્ષણના સાધન તરીકે અને ફક્ત સ્થિર ટ્રાફિકમાં પૂર આવવાથી પણ કરો.
• વિશિષ્ટ સુરક્ષા સેવાઓનો ઉપયોગ કરવો જરૂરી છે. તમે ચેનલ સ્તરે L3 અને 4 હુમલાઓથી તમારી જાતને સુરક્ષિત કરી શકતા નથી, કારણ કે તમારી પાસે પૂરતી ચેનલ નથી. તમે L7 હુમલાઓ સામે લડવાની પણ શક્યતા નથી, કારણ કે તે ખૂબ મોટા હોઈ શકે છે. ઉપરાંત, નાના હુમલાઓની શોધ હજુ પણ વિશેષ સેવાઓ, વિશેષ અલ્ગોરિધમનો વિશેષાધિકાર છે.
• નિયમિતપણે અપડેટ કરો. આ માત્ર કર્નલને જ લાગુ પડતું નથી, પણ SSH ડિમનને પણ લાગુ પડે છે, ખાસ કરીને જો તમારી પાસે તે બહારથી ખુલ્લું હોય. સૈદ્ધાંતિક રીતે, દરેક વસ્તુને અપડેટ કરવાની જરૂર છે, કારણ કે તમે તમારા પોતાના પર અમુક નબળાઈઓને ટ્રૅક કરી શકશો તેવી શક્યતા નથી.

સોર્સ: www.habr.com