இந்தக் கட்டுரை "உங்கள் நெட்வொர்க் உள்கட்டமைப்பை எவ்வாறு கட்டுப்படுத்துவது" என்ற தொடரின் நான்காவது கட்டுரையாகும். தொடரில் உள்ள அனைத்து கட்டுரைகளின் உள்ளடக்கங்கள் மற்றும் இணைப்புகளைக் காணலாம் .
В இந்த அத்தியாயத்தில், டேட்டா சென்டர் பிரிவில் நெட்வொர்க் பாதுகாப்பின் சில அம்சங்களைப் பார்த்தோம். இந்த பகுதி "இணைய அணுகல்" பிரிவுக்கு அர்ப்பணிக்கப்படும்.

இணைய அணுகல்
பாதுகாப்பு என்ற தலைப்பு சந்தேகத்திற்கு இடமின்றி தரவு நெட்வொர்க்குகளின் உலகில் மிகவும் சிக்கலான தலைப்புகளில் ஒன்றாகும். முந்தைய நிகழ்வுகளைப் போலவே, ஆழத்தையும் முழுமையையும் கோராமல், நான் இங்கே மிகவும் எளிமையானதாகக் கருதுகிறேன், ஆனால், என் கருத்துப்படி, முக்கியமான கேள்விகள், அதற்கான பதில்கள், உங்கள் நெட்வொர்க்கின் பாதுகாப்பின் அளவை உயர்த்த உதவும் என்று நம்புகிறேன்.
இந்த பிரிவை தணிக்கை செய்யும் போது, பின்வரும் அம்சங்களுக்கு கவனம் செலுத்துங்கள்:
- வடிவமைப்பு
- BGP அமைப்புகள்
- DOS/DDOS பாதுகாப்பு
- ஃபயர்வாலில் போக்குவரத்து வடிகட்டுதல்
வடிவமைப்பு
ஒரு நிறுவன நெட்வொர்க்கிற்கான இந்த பிரிவின் வடிவமைப்பிற்கு உதாரணமாக, நான் பரிந்துரைக்கிறேன் உள்ளே சிஸ்கோ இருந்து .
நிச்சயமாக, மற்ற விற்பனையாளர்களின் தீர்வு உங்களுக்கு மிகவும் கவர்ச்சிகரமானதாகத் தோன்றும் (பார்க்க. ), ஆனால் இந்த வடிவமைப்பை விரிவாகப் பின்பற்ற உங்களை ஊக்குவிக்காமல், அதன் பின்னணியில் உள்ள கொள்கைகள் மற்றும் யோசனைகளைப் புரிந்துகொள்வது எனக்கு இன்னும் பயனுள்ளதாக இருக்கிறது.
கருத்து
SAFE இல், "Remote Access" பிரிவு "Internet Access" பிரிவின் ஒரு பகுதியாகும். ஆனால் இந்தக் கட்டுரைத் தொடரில் தனித்தனியாகக் கருதுவோம்.
நிறுவன நெட்வொர்க்கிற்கான இந்த பிரிவில் உள்ள நிலையான உபகரணங்களின் தொகுப்பு
- எல்லை திசைவிகள்
- ஃபயர்வால்கள்
குறிப்பு 1
இந்தக் கட்டுரைத் தொடரில், ஃபயர்வால்களைப் பற்றி நான் பேசும்போது, அதாவது .
குறிப்பு 2
L2/L1 இணைப்பை உறுதி செய்வதற்குத் தேவையான பல்வேறு வகையான L2/L3 அல்லது L1 தீர்வுகளுக்கு மேல் L2 ஐக் கருத்தில் கொள்வதை நான் தவிர்க்கிறேன் மற்றும் L3 நிலை மற்றும் அதற்கு மேல் உள்ள சிக்கல்களுக்கு மட்டுமே என்னை வரம்பிடுகிறேன். பகுதியளவில், L1/L2 சிக்கல்கள் அத்தியாயத்தில் விவாதிக்கப்பட்டன.".
இந்த பிரிவில் நீங்கள் ஃபயர்வாலைக் கண்டுபிடிக்கவில்லை என்றால், நீங்கள் முடிவுகளுக்கு விரைந்து செல்லக்கூடாது.
உள்ளதைப் போலவே செய்வோம் கேள்வியுடன் ஆரம்பிக்கலாம்: உங்கள் விஷயத்தில் இந்த பிரிவில் ஃபயர்வாலைப் பயன்படுத்துவது அவசியமா?
ஃபயர்வால்களைப் பயன்படுத்துவதற்கும் சிக்கலான ட்ராஃபிக் வடிகட்டுதல் அல்காரிதம்களைப் பயன்படுத்துவதற்கும் இது மிகவும் நியாயமான இடம் என்று என்னால் சொல்ல முடியும். IN தரவு மையப் பிரிவில் ஃபயர்வால்களைப் பயன்படுத்துவதைத் தடுக்கக்கூடிய 4 காரணிகளைக் குறிப்பிட்டுள்ளோம். ஆனால் இங்கே அவை அவ்வளவு முக்கியத்துவம் வாய்ந்தவை அல்ல.
உதாரணம் 1. தாமதம்
இணையத்தைப் பொறுத்த வரையில், சுமார் 1 மில்லி விநாடிகள் கூட தாமதம் என்று பேசுவதில் அர்த்தமில்லை. எனவே, இந்த பிரிவில் தாமதமானது ஃபயர்வாலின் பயன்பாட்டைக் கட்டுப்படுத்தும் காரணியாக இருக்க முடியாது.
உதாரணம் 2. உற்பத்தித்
சில சந்தர்ப்பங்களில் இந்த காரணி இன்னும் குறிப்பிடத்தக்கதாக இருக்கலாம். எனவே, ஃபயர்வாலைப் புறக்கணிக்க நீங்கள் சில போக்குவரத்தை (உதாரணமாக, சுமை பேலன்ஸர்களிடமிருந்து வரும் போக்குவரத்து) அனுமதிக்க வேண்டும்.
உதாரணம் 3. நம்பகத்தன்மை
இந்த காரணி இன்னும் கணக்கில் எடுத்துக்கொள்ளப்பட வேண்டும், ஆனால் இன்னும், இணையத்தின் நம்பகத்தன்மையின்மை காரணமாக, இந்த பிரிவுக்கான அதன் முக்கியத்துவம் தரவு மையத்தைப் போல குறிப்பிடத்தக்கதாக இல்லை.
எனவே, உங்கள் சேவை http/https (குறுகிய அமர்வுகளுடன்) மேல் இருக்கும் என்று வைத்துக்கொள்வோம். இந்த வழக்கில், நீங்கள் இரண்டு சுயாதீன பெட்டிகளைப் பயன்படுத்தலாம் (HA இல்லாமல்) மற்றும் அவற்றில் ஒன்றில் ரூட்டிங் சிக்கல் இருந்தால், எல்லா போக்குவரத்தையும் இரண்டாவது இடத்திற்கு மாற்றவும்.
அல்லது நீங்கள் ஃபயர்வால்களை வெளிப்படையான பயன்முறையில் பயன்படுத்தலாம் மற்றும் அவை தோல்வியுற்றால், சிக்கலைத் தீர்க்கும் போது ஃபயர்வாலைப் புறக்கணிக்க போக்குவரத்தை அனுமதிக்கவும்.
எனவே, பெரும்பாலும் வெறும் விலை இந்த பிரிவில் ஃபயர்வால்களைப் பயன்படுத்துவதை கைவிடும்படி உங்களை கட்டாயப்படுத்தும் காரணியாக இருக்கலாம்.
முக்கியம்!
இந்த ஃபயர்வாலை டேட்டா சென்டர் ஃபயர்வாலுடன் இணைக்க ஒரு ஆசை உள்ளது (இந்தப் பிரிவுகளுக்கு ஒரு ஃபயர்வாலைப் பயன்படுத்தவும்). தீர்வு, கொள்கையளவில், சாத்தியமானது, ஆனால் நீங்கள் அதை புரிந்து கொள்ள வேண்டும் இணைய அணுகல் ஃபயர்வால் உண்மையில் உங்கள் பாதுகாப்பில் முன்னணியில் உள்ளது மற்றும் தீங்கிழைக்கும் போக்குவரத்தில் சிலவற்றையாவது "எடுக்கிறது", நிச்சயமாக, இந்த ஃபயர்வால் முடக்கப்படும் அபாயத்தை நீங்கள் கணக்கில் எடுத்துக்கொள்ள வேண்டும். அதாவது, இந்த இரண்டு பிரிவுகளிலும் ஒரே சாதனங்களைப் பயன்படுத்துவதன் மூலம், உங்கள் தரவு மையப் பிரிவின் கிடைக்கும் தன்மையைக் கணிசமாகக் குறைப்பீர்கள்.
எப்போதும் போல, நிறுவனம் வழங்கும் சேவையைப் பொறுத்து, இந்த பிரிவின் வடிவமைப்பு பெரிதும் மாறுபடும் என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும். எப்போதும் போல, உங்கள் தேவைகளைப் பொறுத்து வெவ்வேறு அணுகுமுறைகளை நீங்கள் தேர்வு செய்யலாம்.
உதாரணமாக
நீங்கள் CDN நெட்வொர்க்குடன் உள்ளடக்க வழங்குநராக இருந்தால் (உதாரணமாக, பார்க்கவும், ), பின்னர் நீங்கள் டசின் முழுவதும் உள்கட்டமைப்பை உருவாக்க விரும்பாமல் இருக்கலாம் அல்லது போக்குவரத்தை திசைதிருப்புவதற்கும் வடிகட்டுவதற்கும் தனித்தனி சாதனங்களைப் பயன்படுத்தி நூற்றுக்கணக்கான இருப்புப் புள்ளிகளைக் கூட உருவாக்க விரும்பவில்லை. இது விலை உயர்ந்ததாக இருக்கும், அது வெறுமனே தேவையற்றதாக இருக்கலாம்.
BGPக்கு நீங்கள் பிரத்யேக ரவுட்டர்களை வைத்திருக்க வேண்டிய அவசியமில்லை, நீங்கள் திறந்த மூலக் கருவிகளைப் பயன்படுத்தலாம் . ஒருவேளை உங்களுக்கு தேவையானது சர்வர் அல்லது பல சர்வர்கள், ஒரு சுவிட்ச் மற்றும் பிஜிபி.
இந்த வழக்கில், உங்கள் சேவையகம் அல்லது பல சேவையகங்கள் CDN சேவையகம் மட்டுமல்ல, ஒரு திசைவியின் பாத்திரத்தையும் வகிக்க முடியும். நிச்சயமாக, இன்னும் நிறைய விவரங்கள் உள்ளன (எப்படி சமநிலையை உறுதிப்படுத்துவது போன்றவை), ஆனால் இது செய்யக்கூடியது, மேலும் இது எங்கள் கூட்டாளர்களில் ஒருவருக்கு நாங்கள் வெற்றிகரமாகப் பயன்படுத்திய அணுகுமுறையாகும்.
முழுப் பாதுகாப்புடன் (ஃபயர்வால்கள், உங்கள் இணைய வழங்குநர்களால் வழங்கப்படும் DDOS பாதுகாப்புச் சேவைகள்) மற்றும் டஜன் கணக்கான அல்லது நூற்றுக்கணக்கான "எளிமைப்படுத்தப்பட்ட" புள்ளிகள் மட்டுமே L2 சுவிட்சுகள் மற்றும் சர்வர்களுடன் நீங்கள் பல தரவு மையங்களை வைத்திருக்க முடியும்.
ஆனால் இந்த வழக்கில் பாதுகாப்பு பற்றி என்ன?
உதாரணமாக, சமீபத்தில் பிரபலமானதைப் பார்ப்போம் . அதன் ஆபத்து என்னவென்றால், அதிக அளவு போக்குவரத்து உருவாக்கப்படுகிறது, இது உங்கள் எல்லா இணைப்புகளிலும் 100% "அடைக்கிறது".
எங்கள் வடிவமைப்பின் விஷயத்தில் எங்களிடம் என்ன இருக்கிறது.
- நீங்கள் AnyCast ஐப் பயன்படுத்தினால், நீங்கள் இருக்கும் இடங்களுக்கு இடையில் போக்குவரத்து விநியோகிக்கப்படும். உங்கள் மொத்த அலைவரிசை டெராபிட்களாக இருந்தால், இதுவே உண்மையில் (இருப்பினும், சமீபத்தில் டெராபிட்களின் வரிசையில் தீங்கிழைக்கும் போக்குவரத்துடன் பல தாக்குதல்கள் நடந்துள்ளன) "நிரம்பி வழியும்" அப்லிங்க்களிலிருந்து உங்களைப் பாதுகாக்கிறது.
- எவ்வாறாயினும், சில இணைப்புகள் அடைபட்டால், இந்த தளத்தை சேவையிலிருந்து அகற்றினால் போதும் (முன்னொட்டை விளம்பரப்படுத்துவதை நிறுத்துங்கள்)
- உங்கள் "முழு" (மற்றும், அதன்படி, பாதுகாக்கப்பட்ட) தரவு மையங்களிலிருந்து அனுப்பப்படும் போக்குவரத்தின் பங்கையும் நீங்கள் அதிகரிக்கலாம், இதனால் பாதுகாப்பற்ற இடங்களிலிருந்து தீங்கிழைக்கும் போக்குவரத்தின் குறிப்பிடத்தக்க பகுதியை அகற்றலாம்
இந்த உதாரணத்திற்கு மேலும் ஒரு சிறிய குறிப்பு. நீங்கள் IXகள் மூலம் போதுமான டிராஃபிக்கை அனுப்பினால், இது போன்ற தாக்குதல்களுக்கு உங்கள் பாதிப்பையும் குறைக்கிறது
BGP ஐ அமைத்தல்
இங்கு இரண்டு தலைப்புகள் உள்ளன.
- இணைப்பு
- BGP ஐ அமைத்தல்
இன் இணைப்பு பற்றி நாங்கள் ஏற்கனவே கொஞ்சம் பேசினோம் . உங்கள் வாடிக்கையாளர்களுக்கான போக்குவரத்து உகந்த பாதையைப் பின்பற்றுவதை உறுதி செய்வதே முக்கிய விஷயம். உகந்தது என்பது எப்பொழுதும் தாமதத்தைப் பற்றியது அல்ல என்றாலும், குறைந்த தாமதம் பொதுவாக உகந்ததன் முக்கிய குறிகாட்டியாகும். சில நிறுவனங்களுக்கு இது மிகவும் முக்கியமானது, மற்றவர்களுக்கு இது குறைவாக உள்ளது. இது அனைத்தும் நீங்கள் வழங்கும் சேவையைப் பொறுத்தது.
உதாரணமாக 1
நீங்கள் ஒரு பரிமாற்றமாக இருந்தால், மற்றும் மில்லி விநாடிகளுக்கு குறைவான நேர இடைவெளிகள் உங்கள் வாடிக்கையாளர்களுக்கு முக்கியமானதாக இருந்தால், நிச்சயமாக, எந்த வகையான இணையத்தைப் பற்றியும் பேச முடியாது.
உதாரணமாக 2
நீங்கள் ஒரு கேமிங் நிறுவனம் மற்றும் பத்து மில்லி விநாடிகள் உங்களுக்கு முக்கியமானதாக இருந்தால், நிச்சயமாக, இணைப்பு உங்களுக்கு மிகவும் முக்கியமானது.
உதாரணமாக 3
TCP நெறிமுறையின் பண்புகள் காரணமாக, ஒரு TCP அமர்வுக்குள் தரவு பரிமாற்ற வீதம் RTT (சுற்றுப் பயண நேரம்) சார்ந்துள்ளது என்பதையும் நீங்கள் புரிந்து கொள்ள வேண்டும். உள்ளடக்க விநியோக சேவையகங்களை இந்த உள்ளடக்கத்தின் நுகர்வோருக்கு நெருக்கமாக நகர்த்துவதன் மூலம் இந்த சிக்கலை தீர்க்க CDN நெட்வொர்க்குகளும் உருவாக்கப்படுகின்றன.
இணைப்பு பற்றிய ஆய்வு என்பது அதன் சொந்த கட்டுரை அல்லது தொடர் கட்டுரைகளுக்கு தகுதியான ஒரு சுவாரஸ்யமான தலைப்பாகும், மேலும் இணையம் எவ்வாறு "செயல்படுகிறது" என்பதைப் பற்றிய நல்ல புரிதல் தேவைப்படுகிறது.
பயனுள்ள ஆதாரங்கள்:
உதாரணமாக
ஒரே ஒரு சிறிய உதாரணம் தருகிறேன்.
உங்கள் தரவு மையம் மாஸ்கோவில் அமைந்துள்ளது என்று வைத்துக்கொள்வோம், மேலும் உங்களிடம் ஒரே ஒரு அப்லிங்க் உள்ளது - Rostelecom (AS12389). இந்த வழக்கில் (ஒற்றை வீட்டில்) உங்களுக்கு BGP தேவையில்லை, மேலும் நீங்கள் Rostelecom இலிருந்து முகவரிக் குளத்தை பொது முகவரிகளாகப் பயன்படுத்தலாம்.
நீங்கள் ஒரு குறிப்பிட்ட சேவையை வழங்குகிறீர்கள் என்று வைத்துக்கொள்வோம், மேலும் உக்ரைனில் இருந்து உங்களிடம் போதுமான எண்ணிக்கையிலான வாடிக்கையாளர்கள் உள்ளனர், மேலும் அவர்கள் நீண்ட தாமதங்கள் குறித்து புகார் கூறுகிறார்கள். உங்கள் ஆராய்ச்சியின் போது, அவற்றில் சிலவற்றின் ஐபி முகவரிகள் 37.52.0.0/21 கட்டத்தில் இருப்பதைக் கண்டுபிடித்தீர்கள்.
டிரேசரூட்டை இயக்குவதன் மூலம், போக்குவரத்து AS1299 (டெலியா) வழியாகச் செல்வதைக் கண்டீர்கள், மேலும் பிங்கை இயக்குவதன் மூலம் சராசரியாக 70 - 80 மில்லி விநாடிகள் RTTயைப் பெற்றீர்கள். இதையும் நீங்கள் பார்க்கலாம் .
Whois பயன்பாட்டைப் பயன்படுத்தி (ripe.net அல்லது உள்ளூர் பயன்பாட்டில்), 37.52.0.0/21 தொகுதி AS6849 (Ukrtelecom) க்கு சொந்தமானது என்பதை நீங்கள் எளிதாக தீர்மானிக்கலாம்.
அடுத்து, செல்வதன் மூலம் AS6849 க்கு AS12389 உடன் எந்தத் தொடர்பும் இல்லை என்பதை நீங்கள் காண்கிறீர்கள் (அவர்கள் வாடிக்கையாளர்களோ அல்லது ஒன்றுக்கொன்று இணைப்புகளோ இல்லை, அல்லது அவர்கள் பியரிங் கொண்டிருக்கவில்லை). ஆனால் நீங்கள் பார்த்தால் AS6849 க்கு, நீங்கள் AS29226 (Mastertel) மற்றும் AS31133 (Megafon) ஆகியவற்றைக் காண்பீர்கள்.
இந்த வழங்குநர்களின் கண்ணாடியை நீங்கள் கண்டறிந்ததும், பாதை மற்றும் RTT ஆகியவற்றை ஒப்பிடலாம். எடுத்துக்காட்டாக, Mastertel RTT க்கு சுமார் 30 மில்லி விநாடிகள் இருக்கும்.
எனவே, உங்கள் சேவைக்கு 80 மற்றும் 30 மில்லி விநாடிகளுக்கு இடையிலான வேறுபாடு குறிப்பிடத்தக்கதாக இருந்தால், ஒருவேளை நீங்கள் இணைப்பு பற்றி யோசிக்க வேண்டும், உங்கள் AS எண், உங்கள் முகவரிக் குழுவை RIPE இலிருந்து பெற்று கூடுதல் இணைப்புகளை இணைக்கவும் மற்றும்/அல்லது IX களில் இருப்பதற்கான புள்ளிகளை உருவாக்கவும்.
நீங்கள் BGPஐப் பயன்படுத்தும்போது, இணைப்பை மேம்படுத்துவதற்கான வாய்ப்பு உங்களுக்குக் கிடைப்பது மட்டுமல்லாமல், உங்கள் இணைய இணைப்பைத் தேவையில்லாமல் பராமரிக்கவும்.
BGP ஐ உள்ளமைப்பதற்கான பரிந்துரைகளைக் கொண்டுள்ளது. இந்த பரிந்துரைகள் வழங்குநர்களின் "சிறந்த நடைமுறையின்" அடிப்படையில் உருவாக்கப்பட்டிருந்தாலும், இன்னும் (உங்கள் BGP அமைப்புகள் மிகவும் அடிப்படையாக இல்லை என்றால்) அவை சந்தேகத்திற்கு இடமின்றி பயனுள்ளதாக இருக்கும் மற்றும் உண்மையில் நாம் விவாதித்த கடினப்படுத்துதலின் ஒரு பகுதியாக இருக்க வேண்டும். .
DOS/DDOS பாதுகாப்பு
இப்போது DOS/DDOS தாக்குதல்கள் பல நிறுவனங்களுக்கு அன்றாட உண்மையாகிவிட்டது. உண்மையில், நீங்கள் ஏதாவது ஒரு வடிவத்தில் அடிக்கடி தாக்கப்படுகிறீர்கள். இதை நீங்கள் இன்னும் கவனிக்கவில்லை என்றால், உங்களுக்கு எதிராக இலக்குத் தாக்குதல் இன்னும் ஏற்பாடு செய்யப்படவில்லை, மேலும் நீங்கள் பயன்படுத்தும் பாதுகாப்புக் கருவிகள், ஒருவேளை உங்களுக்குத் தெரியாமல் (இயக்க முறைமைகளின் பல்வேறு உள்ளமைக்கப்பட்ட பாதுகாப்புகள்) போதுமானது. உங்களுக்கும் உங்கள் வாடிக்கையாளர்களுக்கும் வழங்கப்பட்ட சேவையின் சீரழிவு குறைக்கப்படுவதை உறுதிசெய்யவும்.
இணைய ஆதாரங்கள் உள்ளன, அவை உபகரண பதிவுகளின் அடிப்படையில், உண்மையான நேரத்தில் அழகான தாக்குதல் வரைபடங்களை வரைகின்றன.
அவற்றுக்கான இணைப்புகளை நீங்கள் காணலாம்.
எனக்கு பிடித்தது செக்பாயிண்டிலிருந்து.
DDOS/DOS க்கு எதிரான பாதுகாப்பு பொதுவாக அடுக்குகளாக இருக்கும். ஏன் என்பதைப் புரிந்து கொள்ள, என்ன வகையான DOS/DDOS தாக்குதல்கள் உள்ளன என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும் (எடுத்துக்காட்டாக, பார்க்கவும், அல்லது )
அதாவது, எங்களிடம் மூன்று வகையான தாக்குதல்கள் உள்ளன:
- அளவீட்டு தாக்குதல்கள்
- நெறிமுறை தாக்குதல்கள்
- பயன்பாடு தாக்குதல்கள்
எடுத்துக்காட்டாக, ஃபயர்வால்களைப் பயன்படுத்தி கடைசி இரண்டு வகையான தாக்குதல்களில் இருந்து உங்களைப் பாதுகாத்துக் கொள்ள முடிந்தால், உங்கள் அப்லிங்க்களை "அதிகப்படுத்துவதை" இலக்காகக் கொண்ட தாக்குதல்களிலிருந்து உங்களைப் பாதுகாத்துக் கொள்ள முடியாது (நிச்சயமாக, இணைய சேனல்களின் உங்கள் மொத்த திறன் டெராபிட்களில் கணக்கிடப்படாவிட்டால், அல்லது இன்னும் சிறப்பாக, பத்து டெராபிட்டில்).
எனவே, பாதுகாப்பின் முதல் வரிசையானது "வால்யூமெட்ரிக்" தாக்குதல்களுக்கு எதிரான பாதுகாப்பாகும், மேலும் உங்கள் வழங்குநர் அல்லது வழங்குநர்கள் இந்த பாதுகாப்பை உங்களுக்கு வழங்க வேண்டும். இதை நீங்கள் இன்னும் உணரவில்லை என்றால், நீங்கள் இப்போது அதிர்ஷ்டசாலி.
உதாரணமாக
உங்களிடம் பல இணைப்புகள் உள்ளன என்று வைத்துக் கொள்வோம், ஆனால் வழங்குநர்களில் ஒருவர் மட்டுமே இந்த பாதுகாப்பை உங்களுக்கு வழங்க முடியும். ஆனால் எல்லா போக்குவரமும் ஒரு வழங்குநரின் மூலம் சென்றால், நாம் சற்று முன்பு சுருக்கமாக விவாதித்த இணைப்பு பற்றி என்ன?
இந்த வழக்கில், தாக்குதலின் போது நீங்கள் ஓரளவு இணைப்பை தியாகம் செய்ய வேண்டும். ஆனாலும்
- இது தாக்குதலின் காலத்திற்கு மட்டுமே. தாக்குதல் ஏற்பட்டால், நீங்கள் கைமுறையாகவோ அல்லது தானாகவோ 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
