આ લેખ "તમારા નેટવર્ક ઇન્ફ્રાસ્ટ્રક્ચર પર નિયંત્રણ કેવી રીતે લેવું" શ્રેણીમાં ચોથો છે. શ્રેણીના તમામ લેખોની સામગ્રી અને લિંક્સ મળી શકે છે અહીં.

В પ્રથમ ભાગ આ પ્રકરણમાં, અમે ડેટા સેન્ટર સેગમેન્ટમાં નેટવર્ક સુરક્ષાના કેટલાક પાસાઓ પર ધ્યાન આપ્યું. આ ભાગ "ઇન્ટરનેટ એક્સેસ" સેગમેન્ટને સમર્પિત કરવામાં આવશે.

ઇન્ટરનેટનો ઉપયોગ

સુરક્ષાનો વિષય નિઃશંકપણે ડેટા નેટવર્કની દુનિયામાં સૌથી જટિલ વિષયોમાંનો એક છે. અગાઉના કેસોની જેમ, ઊંડાણ અને સંપૂર્ણતાનો દાવો કર્યા વિના, હું અહીં એકદમ સરળ વિચારણા કરીશ, પરંતુ, મારા મતે, મહત્વપૂર્ણ પ્રશ્નો, જેના જવાબો, મને આશા છે કે, તમારા નેટવર્કની સુરક્ષાનું સ્તર વધારવામાં મદદ કરશે.

આ સેગમેન્ટનું ઑડિટ કરતી વખતે, નીચેના પાસાઓ પર ધ્યાન આપો:

• ડિઝાઇન
• BGP સેટિંગ્સ
• DOS/DDOS સુરક્ષા
• ફાયરવોલ પર ટ્રાફિક ફિલ્ટરિંગ

ડિઝાઇન

એન્ટરપ્રાઇઝ નેટવર્ક માટે આ સેગમેન્ટની ડિઝાઇનના ઉદાહરણ તરીકે, હું ભલામણ કરીશ નેતૃત્વ અંદર સિસ્કો થી સેફ મોડલ્સ.

અલબત્ત, કદાચ અન્ય વિક્રેતાઓનો ઉકેલ તમને વધુ આકર્ષક લાગશે (જુઓ. ગાર્ટનર ચતુર્થાંશ 2018), પરંતુ તમને આ ડિઝાઇનને વિગતવાર અનુસરવા માટે પ્રોત્સાહિત કર્યા વિના, મને હજી પણ તેની પાછળના સિદ્ધાંતો અને વિચારોને સમજવામાં ઉપયોગી લાગે છે.

નોંધ

SAFE માં, "રિમોટ એક્સેસ" સેગમેન્ટ "ઇન્ટરનેટ એક્સેસ" સેગમેન્ટનો ભાગ છે. પરંતુ લેખોની આ શ્રેણીમાં આપણે તેને અલગથી ધ્યાનમાં લઈશું.

એન્ટરપ્રાઇઝ નેટવર્ક માટે આ સેગમેન્ટમાં સાધનોનો પ્રમાણભૂત સમૂહ છે

• સરહદ રાઉટર્સ
• ફાયરવોલ

નોંધ 1

લેખોની આ શ્રેણીમાં, જ્યારે હું ફાયરવોલ વિશે વાત કરું છું, ત્યારે મારો અર્થ છે NGFW.

નોંધ 2

હું L2/L1 કનેક્ટિવિટી સુનિશ્ચિત કરવા માટે જરૂરી વિવિધ પ્રકારના L2/L3 અથવા ઓવરલે L1 પર L2 સોલ્યુશન્સનો વિચાર છોડી દઉં છું અને મારી જાતને માત્ર L3 સ્તર અને તેનાથી ઉપરની સમસ્યાઓ સુધી મર્યાદિત રાખું છું. આંશિક રીતે, પ્રકરણમાં L1/L2 મુદ્દાઓની ચર્ચા કરવામાં આવી હતી.સફાઈ અને દસ્તાવેજીકરણ".

જો તમને આ સેગમેન્ટમાં ફાયરવોલ ન મળી હોય, તો તમારે તારણો પર ઉતાવળ કરવી જોઈએ નહીં.

ચાલો માં જેવું જ કરીએ અગાઉનો ભાગચાલો પ્રશ્ન સાથે પ્રારંભ કરીએ: શું તમારા કિસ્સામાં આ સેગમેન્ટમાં ફાયરવોલનો ઉપયોગ કરવો જરૂરી છે?

હું કહી શકું છું કે ફાયરવોલનો ઉપયોગ કરવા અને જટિલ ટ્રાફિક ફિલ્ટરિંગ એલ્ગોરિધમ્સ લાગુ કરવા માટે આ સૌથી ન્યાયી સ્થળ લાગે છે. IN ભાગ 1 અમે 4 પરિબળોનો ઉલ્લેખ કર્યો છે જે ડેટા સેન્ટર સેગમેન્ટમાં ફાયરવોલના ઉપયોગમાં દખલ કરી શકે છે. પરંતુ અહીં તેઓ હવે એટલા નોંધપાત્ર નથી.

ઉદાહરણ 1 વિલંબ

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

ઉદાહરણ 2 ઉત્પાદકતા

કેટલાક કિસ્સાઓમાં આ પરિબળ હજુ પણ નોંધપાત્ર હોઈ શકે છે. તેથી, તમારે ફાયરવોલને બાયપાસ કરવા માટે કેટલાક ટ્રાફિક (ઉદાહરણ તરીકે, લોડ બેલેન્સરથી ટ્રાફિક)ને મંજૂરી આપવી પડી શકે છે.

ઉદાહરણ 3 વિશ્વસનીયતા

આ પરિબળને હજી પણ ધ્યાનમાં લેવાની જરૂર છે, પરંતુ તેમ છતાં, ઇન્ટરનેટની અવિશ્વસનીયતાને જોતાં, આ સેગમેન્ટ માટે તેનું મહત્વ ડેટા સેન્ટર જેટલું નોંધપાત્ર નથી.

તેથી, ચાલો ધારીએ કે તમારી સેવા http/https (ટૂંકા સત્રો સાથે) ની ટોચ પર રહે છે. આ કિસ્સામાં, તમે બે સ્વતંત્ર બોક્સ (HA વિના) નો ઉપયોગ કરી શકો છો અને જો તેમાંથી એક સાથે રૂટીંગ સમસ્યા હોય, તો તમામ ટ્રાફિકને બીજામાં સ્થાનાંતરિત કરો.

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

તેથી, મોટે ભાગે માત્ર ભાવ તે પરિબળ હોઈ શકે છે જે તમને આ સેગમેન્ટમાં ફાયરવોલનો ઉપયોગ છોડી દેવા માટે દબાણ કરશે.

મહત્વપૂર્ણ!

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

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

ઉદાહરણ:

જો તમે CDN નેટવર્ક સાથે સામગ્રી પ્રદાતા છો (જુઓ, ઉદાહરણ તરીકે, લેખોની શ્રેણી), તો પછી તમે ટ્રાફિકને રૂટીંગ અને ફિલ્ટર કરવા માટે અલગ-અલગ ઉપકરણોનો ઉપયોગ કરીને ડઝનેક અથવા તો હાજરીના સેંકડો પોઈન્ટ પર ઈન્ફ્રાસ્ટ્રક્ચર બનાવવા માંગતા નથી. તે ખર્ચાળ હશે, અને તે ફક્ત બિનજરૂરી હોઈ શકે છે.

BGP માટે તમારી પાસે સમર્પિત રાઉટર હોવું જરૂરી નથી, તમે ઓપન-સોર્સ ટૂલ્સનો ઉપયોગ કરી શકો છો જેમ કે ક્વાગ્ગા. તેથી કદાચ તમારે ફક્ત સર્વર અથવા ઘણા સર્વર્સ, એક સ્વીચ અને BGPની જરૂર છે.

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

તમારી પાસે સંપૂર્ણ સુરક્ષા (ફાયરવૉલ્સ, તમારા ઇન્ટરનેટ પ્રદાતાઓ દ્વારા પ્રદાન કરવામાં આવતી DDOS સુરક્ષા સેવાઓ) અને માત્ર L2 સ્વીચો અને સર્વર્સ સાથેની હાજરીના ડઝનેક અથવા સેંકડો "સરળ" બિંદુઓ ધરાવતા ઘણા ડેટા કેન્દ્રો હોઈ શકે છે.

પરંતુ આ કિસ્સામાં રક્ષણ વિશે શું?

ચાલો જોઈએ, ઉદાહરણ તરીકે, તાજેતરમાં લોકપ્રિય DNS એમ્પ્લીફિકેશન DDOS હુમલો. તેનો ખતરો એ હકીકતમાં રહેલો છે કે મોટી માત્રામાં ટ્રાફિક જનરેટ થાય છે, જે તમારા તમામ અપલિંકના 100%ને ફક્ત "ક્લોગ" કરે છે.

અમારી ડિઝાઇનના કિસ્સામાં અમારી પાસે શું છે.

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

અને આ ઉદાહરણ માટે વધુ એક નાની નોંધ. જો તમે IXs દ્વારા પૂરતો ટ્રાફિક મોકલો છો, તો આ આવા હુમલાઓ પ્રત્યેની તમારી નબળાઈને પણ ઘટાડે છે

BGP ની સ્થાપના

અહીં બે વિષયો છે.

• કનેક્ટિવિટી
• BGP ની સ્થાપના

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

ઉદાહરણ 1

જો તમે એક્સચેન્જ છો, અને તમારા ક્લાયંટ માટે મિલિસેકન્ડથી ઓછા સમયના અંતરાલ મહત્વપૂર્ણ છે, તો પછી, અલબત્ત, કોઈપણ પ્રકારના ઈન્ટરનેટ વિશે કોઈ વાત કરી શકાતી નથી.

ઉદાહરણ 2

જો તમે ગેમિંગ કંપની છો અને દસ મિલિસેકન્ડ્સ તમારા માટે મહત્વપૂર્ણ છે, તો, અલબત્ત, તમારા માટે કનેક્ટિવિટી ખૂબ જ મહત્વપૂર્ણ છે.

ઉદાહરણ 3

તમારે એ પણ સમજવાની જરૂર છે કે, TCP પ્રોટોકોલના ગુણધર્મોને લીધે, એક TCP સત્રમાં ડેટા ટ્રાન્સફર રેટ પણ RTT (રાઉન્ડ ટ્રિપ ટાઈમ) પર આધાર રાખે છે. સામગ્રી વિતરણ સર્વર્સને આ સામગ્રીના ગ્રાહકની નજીક ખસેડીને આ સમસ્યાને ઉકેલવા માટે CDN નેટવર્ક્સ પણ બનાવવામાં આવી રહ્યા છે.

કનેક્ટિવિટીનો અભ્યાસ એ પોતાની રીતે એક રસપ્રદ વિષય છે, તેના પોતાના લેખ અથવા લેખોની શ્રેણીને લાયક છે, અને ઇન્ટરનેટ કેવી રીતે કાર્ય કરે છે તેની સારી સમજની જરૂર છે.

ઉપયોગી સંસાધનો:

ripe.net
bgp.he.net

ઉદાહરણ:

હું માત્ર એક નાનું ઉદાહરણ આપીશ.

ચાલો ધારીએ કે તમારું ડેટા સેન્ટર મોસ્કોમાં આવેલું છે, અને તમારી પાસે એક જ અપલિંક છે - Rostelecom (AS12389). આ કિસ્સામાં (સિંગલ હોમ્ડ) તમને BGP ની જરૂર નથી, અને તમે મોટે ભાગે જાહેર સરનામાં તરીકે Rostelecom ના એડ્રેસ પૂલનો ઉપયોગ કરો છો.

ચાલો ધારીએ કે તમે ચોક્કસ સેવા પ્રદાન કરો છો, અને તમારી પાસે યુક્રેનના ગ્રાહકોની પૂરતી સંખ્યા છે, અને તેઓ લાંબા વિલંબ વિશે ફરિયાદ કરે છે. તમારા સંશોધન દરમિયાન, તમને જાણવા મળ્યું કે તેમાંના કેટલાકના IP એડ્રેસ 37.52.0.0/21 ગ્રીડમાં છે.

ટ્રેસરાઉટ ચલાવીને, તમે જોયું કે ટ્રાફિક AS1299 (Telia) પરથી પસાર થઈ રહ્યો છે, અને પિંગ ચલાવીને, તમને સરેરાશ RTT 70 - 80 મિલિસેકન્ડ્સ મળ્યો. તમે આ પર પણ જોઈ શકો છો લુકિંગ ગ્લાસ રોસ્ટેલિકોમ.

whois ઉપયોગિતા (ripe.net અથવા સ્થાનિક ઉપયોગિતા પર) નો ઉપયોગ કરીને, તમે સરળતાથી નક્કી કરી શકો છો કે બ્લોક 37.52.0.0/21 AS6849 (Ukrtelecom) નો છે.

આગળ, પર જઈને bgp.he.net તમે જુઓ છો કે AS6849 નો AS12389 સાથે કોઈ સંબંધ નથી (તેઓ ન તો ક્લાયન્ટ છે કે ન તો એકબીજા સાથે અપલિંક છે, ન તો તેમની પાસે પીઅરિંગ છે). પરંતુ જો તમે જુઓ સાથીઓની યાદી AS6849 માટે, તમે જોશો, ઉદાહરણ તરીકે, AS29226 (Mastertel) અને AS31133 (મેગાફોન).

એકવાર તમને આ પ્રદાતાઓના લુકિંગ ગ્લાસ મળી જાય, પછી તમે પાથ અને RTTની તુલના કરી શકો છો. ઉદાહરણ તરીકે, Mastertel RTT માટે લગભગ 30 મિલિસેકન્ડ્સ હશે.

તેથી, જો તમારી સેવા માટે 80 અને 30 મિલિસેકન્ડ વચ્ચેનો તફાવત નોંધપાત્ર છે, તો કદાચ તમારે કનેક્ટિવિટી વિશે વિચારવું પડશે, તમારો AS નંબર, RIPE માંથી તમારો એડ્રેસ પૂલ મેળવો અને વધારાની અપલિંક કનેક્ટ કરો અને/અથવા IXs પર હાજરીના બિંદુઓ બનાવો.

જ્યારે તમે BGP નો ઉપયોગ કરો છો, ત્યારે તમારી પાસે માત્ર કનેક્ટિવિટી સુધારવાની તક જ નથી, પરંતુ તમે તમારા ઇન્ટરનેટ કનેક્શનને પણ બિનજરૂરી રીતે જાળવી રાખો છો.

આ દસ્તાવેજ BGP રૂપરેખાંકિત કરવા માટેની ભલામણો ધરાવે છે. હકીકત એ છે કે આ ભલામણો પ્રદાતાઓની "શ્રેષ્ઠ પ્રેક્ટિસ" ના આધારે વિકસાવવામાં આવી હોવા છતાં, તેમ છતાં (જો તમારી BGP સેટિંગ્સ તદ્દન મૂળભૂત ન હોય તો) તે નિઃશંકપણે ઉપયોગી છે અને વાસ્તવમાં અમે જેમાં ચર્ચા કરી છે તે સખ્તાઇનો ભાગ હોવો જોઈએ. પ્રથમ ભાગ.

DOS/DDOS સુરક્ષા

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

એવા ઈન્ટરનેટ સંસાધનો છે જે સાધનોના લોગના આધારે, વાસ્તવિક સમયમાં સુંદર હુમલાના નકશા દોરે છે.

તે તમે તેમની લિંક્સ શોધી શકો છો.

મારો પ્રિય નકશો ચેકપોઇન્ટ પરથી.

DDOS/DOS સામે રક્ષણ સામાન્ય રીતે સ્તરીય હોય છે. શા માટે, તમારે સમજવાની જરૂર છે કે કયા પ્રકારના DOS/DDOS હુમલાઓ અસ્તિત્વમાં છે (જુઓ, ઉદાહરણ તરીકે, અહીં અથવા અહીં)

એટલે કે, અમારી પાસે ત્રણ પ્રકારના હુમલા છે:

• વોલ્યુમેટ્રિક હુમલા
• પ્રોટોકોલ હુમલા
• એપ્લિકેશન હુમલા

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

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

ઉદાહરણ:

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

આ કિસ્સામાં, તમારે હુમલા દરમિયાન આંશિક રીતે કનેક્ટિવિટીનું બલિદાન આપવું પડશે. પણ

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

તમે તમારા ભાગીદારોને "પ્રોટોકોલ હુમલા" અને "એપ્લિકેશન હુમલાઓ" થી રક્ષણ પણ સોંપી શકો છો.
અહીં અહીં તમે સારો અભ્યાસ વાંચી શકો છો (સ્થાનાંતરણ). સાચું, લેખ બે વર્ષ જૂનો છે, પરંતુ તે તમને DDOS હુમલાઓથી કેવી રીતે સુરક્ષિત કરી શકે તેના અભિગમોનો ખ્યાલ આપશે.

સૈદ્ધાંતિક રીતે, તમે તમારી જાતને આ સુધી મર્યાદિત કરી શકો છો, તમારા રક્ષણને સંપૂર્ણપણે આઉટસોર્સ કરી શકો છો. આ નિર્ણયના ફાયદા છે, પરંતુ એક સ્પષ્ટ ગેરલાભ પણ છે. હકીકત એ છે કે અમે વ્યવસાયના અસ્તિત્વ વિશે (ફરીથી, તમારી કંપની શું કરે છે તેના આધારે) વાત કરી શકીએ છીએ. અને તૃતીય પક્ષોને આવી વસ્તુઓ પર વિશ્વાસ કરો...

તેથી, ચાલો જોઈએ કે સંરક્ષણની બીજી અને ત્રીજી લાઇન કેવી રીતે ગોઠવવી (પ્રદાતા તરફથી સુરક્ષાના વધારા તરીકે).

તેથી, સંરક્ષણની બીજી લાઇન તમારા નેટવર્કના પ્રવેશદ્વાર પર ફિલ્ટરિંગ અને ટ્રાફિક લિમિટર્સ (પોલીસર્સ) છે.

ઉદાહરણ 1

ચાલો માની લઈએ કે તમે પ્રદાતાઓમાંના એકની મદદથી DDOS સામે છત્ર સાથે તમારી જાતને આવરી લીધી છે. ચાલો ધારીએ કે આ પ્રદાતા તેના નેટવર્કની ધાર પર ટ્રાફિક અને ફિલ્ટર્સને ફિલ્ટર કરવા માટે આર્બરનો ઉપયોગ કરે છે.

આર્બર "પ્રક્રિયા" કરી શકે છે તે બેન્ડવિડ્થ મર્યાદિત છે, અને પ્રદાતા, અલબત્ત, ફિલ્ટરિંગ સાધનો દ્વારા આ સેવાનો ઓર્ડર આપતા તેના તમામ ભાગીદારોના ટ્રાફિકને સતત પસાર કરી શકતા નથી. તેથી, સામાન્ય સ્થિતિમાં, ટ્રાફિક ફિલ્ટર થતો નથી.

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

ઉદાહરણ 2

અસામાન્ય રીતે મોટી સંખ્યામાં SYN પેકેટો માત્ર SYN પૂરના હુમલાનું પરિણામ હોઈ શકે નહીં. ચાલો ધારીએ કે તમે એવી સેવા પ્રદાન કરો છો જેમાં તમે એક સાથે લગભગ 100 હજાર TCP કનેક્શન્સ (એક ડેટા સેન્ટરમાં) ધરાવી શકો છો.

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

જો, ઉદાહરણ તરીકે, તમારે આ સત્રોની ટોચ પર ssl/tls હેન્ડશેક ચલાવવાનું હોય, જેમાં પ્રમાણપત્રોની આપ-લેનો સમાવેશ થાય છે, તો તમારા લોડ બેલેન્સર માટે સંસાધનોને ઘટાડવાના દૃષ્ટિકોણથી, આ સરળ કરતાં વધુ મજબૂત "DDOS" હશે. SYN પૂર. એવું લાગે છે કે બેલેન્સર્સે આવી ઘટનાઓને સંભાળવી જોઈએ, પરંતુ... કમનસીબે, આપણે આવી સમસ્યાનો સામનો કરી રહ્યા છીએ.

અને, અલબત્ત, ધાર રાઉટર પરનો પોલીસ આ કિસ્સામાં પણ તમારા સાધનોને બચાવશે.

DDOS/DOS સામે સુરક્ષાનું ત્રીજું સ્તર એ તમારી ફાયરવોલ સેટિંગ્સ છે.

અહીં તમે બીજા અને ત્રીજા પ્રકારના બંને હુમલાઓને રોકી શકો છો. સામાન્ય રીતે, ફાયરવોલ સુધી પહોંચે છે તે બધું અહીં ફિલ્ટર કરી શકાય છે.

ટિપ

ફાયરવોલને શક્ય તેટલું ઓછું કામ આપવાનો પ્રયાસ કરો, સંરક્ષણની પ્રથમ બે લાઇન પર શક્ય તેટલું ફિલ્ટર કરો. અને તેથી જ.

શું તમારી સાથે ક્યારેય એવું બન્યું છે કે અકસ્માતે, ચેક કરવા માટે ટ્રાફિક જનરેટ કરતી વખતે, ઉદાહરણ તરીકે, તમારા સર્વરની ઑપરેટિંગ સિસ્ટમ DDOS હુમલાઓ માટે કેટલી પ્રતિરોધક છે, તમે તમારી ફાયરવૉલને "મારી નાખ્યું", તેને 100 ટકા પર લોડ કરી, ટ્રાફિક સામાન્ય તીવ્રતા સાથે ? જો નહિં, તો કદાચ તે ફક્ત એટલા માટે છે કારણ કે તમે પ્રયાસ કર્યો નથી?

સામાન્ય રીતે, ફાયરવોલ, જેમ મેં કહ્યું, એક જટિલ વસ્તુ છે, અને તે જાણીતી નબળાઈઓ અને ચકાસાયેલ ઉકેલો સાથે સારી રીતે કાર્ય કરે છે, પરંતુ જો તમે કંઈક અસામાન્ય, માત્ર કેટલાક કચરો અથવા ખોટા હેડરો સાથેના પેકેટો મોકલો છો, તો પછી તમે કેટલાક સાથે છો, સાથે નહીં. આવી નાની સંભાવના (મારા અનુભવના આધારે), તમે ટોપ-એન્ડ સાધનોને પણ મૂર્ખ બનાવી શકો છો. તેથી, સ્ટેજ 2 પર, નિયમિત ACL નો ઉપયોગ કરીને (L3/L4 સ્તરે), ફક્ત તમારા નેટવર્કમાં ટ્રાફિકને મંજૂરી આપો જે ત્યાં દાખલ થવો જોઈએ.

ફાયરવોલ પર ટ્રાફિકને ફિલ્ટર કરવું

ચાલો ફાયરવોલ વિશે વાતચીત ચાલુ રાખીએ. તમારે એ સમજવાની જરૂર છે કે DOS/DDOS હુમલા એ માત્ર એક પ્રકારનો સાયબર હુમલો છે.

DOS/DDOS સુરક્ષા ઉપરાંત, અમારી પાસે નીચેની સુવિધાઓની સૂચિ જેવું કંઈક પણ હોઈ શકે છે:

• એપ્લિકેશન ફાયરવોલિંગ
• જોખમ નિવારણ (એન્ટીવાયરસ, એન્ટી સ્પાયવેર અને નબળાઈ)
• URL ફિલ્ટરિંગ
• ડેટા ફિલ્ટરિંગ (સામગ્રી ફિલ્ટરિંગ)
• ફાઈલ બ્લોકીંગ (ફાઈલ પ્રકારો બ્લોકીંગ)

આ સૂચિમાંથી તમને શું જોઈએ છે તે નક્કી કરવાનું તમારા પર છે.

ચાલુ રહી શકાય

સોર્સ: www.habr.com