டொமைன் கடத்தல் உண்மையில் எப்படி நடக்கிறது: ஐந்து தாக்குதல் வழிகளும் அபாயத்தைக் குறைக்கும் கட்டுப்பாடுகளும்

"டொமைன் கடத்தல்" என்பது கேட்பதற்கு பரபரப்பாகத் தோன்றும் சொற்றொடர்களில் ஒன்று; ஆனால் அது எப்படி நிகழ்கிறது என்பதைப் பொறுத்து அதன் பொருள் மிகவும் மாறுபடும். ஒரு ரெஜிஸ்ட்ரார் கணக்கு ஃபிஷிங் (Phishing) மின்னஞ்சல் மூலம் கைப்பற்றப்படுவது ஒரு கடத்தல். பெயர் சேவையகம் (NS பதிவு) ஒரு டொமைன் பெயர் முறைமை (DNS) வழங்குநரிடம் யாருக்கும் தெரியாமல் மாற்றப்படுவதும் ஒரு கடத்தல். காலாவதியான டொமைனை வேறொருவர் பதிவுசெய்து, அதன் போக்கை மாற்றுவதையும் ஒருவகையில் கடத்தல் எனலாம்.

ஒவ்வொரு சந்தர்ப்பத்திலும் விளைவு ஒன்றே: உங்கள் பெயர் எங்கு சுட்டிக்காட்ட வேண்டும் என்பதை இப்போது வேறொருவர் உலகுக்குச் சொல்கிறார். மின்னஞ்சல், பணம் செலுத்துதல், உள்நுழைவு ஓட்டங்கள், SaaS ஒருங்கிணைப்புகள் அனைத்தும் இணையப் போக்குவரத்தைத் தாக்குநரிடம் அனுப்பத் தொடங்குகின்றன. மீட்புக்கு பெரும்பாலும் பல நாட்களும், சில நேரங்களில் பல வாரங்களும் ஆகும். டொமைன் வேறொரு ரெஜிஸ்ட்ராருக்கு மாற்றப்பட்டிருந்தால், ICANN-ன் பரிமாற்றத் தகராறு தீர்வுக் கொள்கை (TDRP) பொருந்தக்கூடும்; மற்ற சந்தர்ப்பங்களில் ரெஜிஸ்ட்ரார் அல்லது பதிவக நிறுவனம் (Registry) வழியாக மேல்முறையீடு, தளத்தின் கணக்கு மீட்பு நடவடிக்கை அல்லது நீதிமன்ற ஆணை தேவைப்படும். இப்படிப்பட்ட நிலை உருவாகாமல் தடுப்பதே மிக வேகமான தீர்வு.

மீண்டும் மீண்டும் காணப்படும் ஐந்து தாக்குதல் வழிகள், பாதுகாப்பவரின் பார்வையில் அவை எப்படி இருக்கும், அவற்றைத் தடுக்கவோ, கட்டுப்படுத்தவோ, கண்டறியவோ உதவும் பாதுகாப்புகள் ஆகியவற்றை இக்கட்டுரை விளக்குகிறது.

1. ரெஜிஸ்ட்ராரின் ஆதரவுக் குழுவுக்கு எதிரான சமூகப் பொறியியல்

பிரபலமான பல கடத்தல்களுக்கு ஒரு தொழில்நுட்பச் சுரண்டல் தேவைப்படவில்லை. ஒரு தொலைபேசி அழைப்போ ஆதரவுக் கோரிக்கையோதான் பயன்படுத்தப்பட்டுள்ளது.

வழக்கமான முறை இதுதான்: இலக்கைப் பற்றிய WHOIS (மற்றும் RDAP) வரலாறு, LinkedIn, கசிந்த கடவுச்சொல் தொகுப்புகள், சமூக ஊடகம் போன்ற போதுமான தகவல்களைத் தாக்குநர் சேகரிக்கிறார். பின்னர் உரிமையாளரைப் போல நடித்து ரெஜிஸ்ட்ராரின் ஆதரவுக் குழுவை அழைக்கிறார் அல்லது மின்னஞ்சல் அனுப்புகிறார். கடவுச்சொல் மீட்டமைப்பு, மின்னஞ்சல் மாற்றம் அல்லது பரிமாற்றத்திற்கான அனுமதிக் குறியீடு (EPP Code, Transfer Code) ஆகியவற்றைக் கேட்கிறார். தாக்குநர் ஏற்கெனவே தயாராகியுள்ள சரிபார்ப்புப் பட்டியலை மட்டுமே ஆதரவு முகவர் பின்பற்றினால், கணக்கு கைமாறிவிடும்.

இந்த வழிக்கு ரெஜிஸ்ட்ராரின் நிரலில் உள்ள பலவீனம் தேவையில்லை; செயல்முறையில் ஈடுபடும் மனிதரையே இது பயன்படுத்திக்கொள்கிறது.

இதைத் தடுப்பவை:

• ரெஜிஸ்ட்ரார் தரப்பில் கடுமையான விதி: உரிமை மாற்றங்களுக்கு நோட்டரி சான்றுள்ள ஆவணம் அல்லது பதிவாளர் ஏற்கெனவே பயன்படுத்திவரும் தொடர்பு வழியில் பல-காரணி சரிபார்ப்பு ஆகியவற்றில் ஒன்று கட்டாயம்.
• Registry Lock (பதிவக பூட்டு): இது ரெஜிஸ்ட்ரார் பூட்டிலிருந்து வேறுபட்டது. நேரடித் தொடர்பல்லாத தனி வழியில் உறுதிப்படுத்தாமல், பரிமாற்றம் அல்லது தொடர்பு விவர மாற்றத்தைப் பதிவக இயக்குநரே மறுப்பார். இது .com, .net மற்றும் பல ccTLD-களில் கிடைக்கிறது.
• நீங்கள் உண்மையில் எந்த ரெஜிஸ்ட்ராரைப் பயன்படுத்துகிறீர்கள் என்பதைச் சரிபார்த்து, மற்ற கணக்குகளை அகற்றுதல். 2007-இல் தொடங்கிய பிராண்டுகளுக்கு பலவீனமான நற்சான்றுகளுடன் மூன்று அல்லது நான்கு ரெஜிஸ்ட்ரார்களில் பழைய கணக்குகள் இன்னும் இருக்கக்கூடும்.

2. ரெஜிஸ்ட்ரார் கணக்கு ஊடுருவல் (நற்சான்று வழி)

இது சமூகப் பொறியியலின் தொழில்நுட்ப உறவினரைப் போன்றது. தாக்குநர் ரெஜிஸ்ட்ரார் கணக்கின் நற்சான்றுகளை ஃபிஷிங் மூலம் திருடுகிறார் அல்லது credential-stuffing தரவுக் கசிவில் அவற்றைக் கண்டுபிடித்து நேரடியாக உள்நுழைகிறார். அங்கிருந்து டொமைனின் பூட்டைத் திறந்து, தொடர்பு மின்னஞ்சலை மாற்றி, பரிமாற்றத்தைக் கோருகிறார்.

இதைத் தடுப்பவை:

• ரெஜிஸ்ட்ரார் கணக்கில் ஃபிஷிங்கை எதிர்க்கும் 2FA. Authenticator செயலி வழியான TOTP, கடவுச்சொல் மட்டும் பயன்படுத்துவதைவிட வலிமையானது; WebAuthn/FIDO2 பயன்படுத்தும் வன்பொருள் சாவிகள் பரவலாகக் கிடைக்கும் தேர்வுகளில் மிகவும் வலிமையானவை. SMS அடிப்படையிலான 2FA, SIM swapping தாக்குதலுக்கு இன்னும் ஆளாகக்கூடும். கிடைக்குமிடங்களில் ஃபிஷிங்கை எதிர்க்கும் MFA-ஐப் பயன்படுத்துமாறு அமெரிக்க அரசின் CISA வழிகாட்டுதல் பரிந்துரைக்கிறது.
• கணக்கு அளவிலான பூட்டுகளுடன் ஒவ்வொரு டொமைனுக்கும் தனிப் பூட்டையும் ஆதரிக்கும் ரெஜிஸ்ட்ரார். இதனால் ஒரே கணக்கு ஊடுருவப்பட்டாலும் அனைத்தையும் ஒரே நேரத்தில் திறக்க முடியாது.
• தொடர்பு விவரம், பெயர் சேவையகம், பரிமாற்றக் கோரிக்கை ஆகிய மாற்றங்களுக்கான தணிக்கைப் பதிவும் எச்சரிக்கைகளும். முதலில் அந்த எச்சரிக்கைகளை முடக்கவே தாக்குநர் முயல்வார்; அவரால் கட்டுப்படுத்த முடியாத தொடர்பு வழிக்கு எச்சரிக்கை சென்றால், நீங்கள் செயல்பட சிறிது நேரம் கிடைக்கும்.

3. DNS வழங்குநர் கைப்பற்றல்

ரெஜிஸ்ட்ரார் கணக்கு பாதுகாப்பாகப் பூட்டப்பட்டிருந்தாலும், ரெஜிஸ்ட்ரார் வெளியிடும் பெயர் சேவையகங்கள் தனிக் கணக்கைக் கொண்ட DNS வழங்குநரைச் சுட்டிக்காட்டக்கூடும்—Cloudflare, Route 53, NS1, DNSimple அல்லது நீங்கள் இயக்கும் BIND சேவையகம் போன்றவை. அந்த DNS கணக்குக்குள் தாக்குநர் நுழைந்தால், ரெஜிஸ்ட்ராரைத் தொடவேண்டியதில்லை. A, MX, TXT பதிவுகளை மாற்றி எழுதினாலே போதும்; போக்குவரத்து அவரைப் பின்தொடரும்.

பிராண்டுகள் ரெஜிஸ்ட்ரார் பாதுகாப்பில் முதலீடு செய்தாலும், DNS வழங்குநரை பலவீனமான கட்டுப்பாடுகளைக் கொண்ட "உள்கட்டமைப்பு" எனக் கருதுவதால், தாக்குநர்களுக்கு இது பெரும்பாலும் எளிதான வழியாக அமைகிறது.

இதைத் தடுப்பவை:

• ரெஜிஸ்ட்ரார் கணக்குக்குப் பயன்படுத்தும் அதே கடுமையான 2FA-ஐ DNS வழங்குநர் கணக்கிலும் பயன்படுத்துதல். இரண்டையும் ஒரே அளவு முக்கியமானதாகக் கருதுங்கள். உண்மையில் அவை அப்படித்தான்.
• மண்டல அளவில் கையொப்பமிடப்பட்ட DNSSEC (டொமைன் பெயர் அமைப்பு பாதுகாப்பு நீட்டிப்புகள்). DNSSEC, DNS வழங்குநர் கணக்கு ஊடுருவலைத் தடுக்காது: வழங்குநர் வழியாக தாக்குநரால் பதிவுகளை வெளியிட முடிந்து, மண்டலத்தின் செயலில் உள்ள சாவிகளால் வழங்குநர் அவற்றுக்குக் கையொப்பமிட்டால், சரிபார்க்கும் ரிசால்வர்கள் அந்தப் பதில்களை உண்மையானவை என ஏற்றுக்கொள்வார்கள். சரியான DS பதிவுகளை மேல்நிலை மண்டலம் வெளியிடுவதாகக் கொண்டால், வழித்தடத்தில் இடைமறித்துத் தரவை மாற்றுதல், cache poisoning, கையொப்பமிடப்படாத அல்லது தவறாகக் கையொப்பமிடப்பட்ட போலிப் பதில்கள் ஆகியவற்றையே DNSSEC தடுக்கும். நெறிமுறை விவரங்களுக்கு RFC 4033-4035-ஐப் பார்க்கவும்.
• தனி கணக்குகளும் நற்சான்றுகளும் கொண்ட பல DNS வழங்குநர்கள், பல-கையொப்ப DNSSEC உடன். இது சேவை கிடைப்புத் தன்மைக்கும் வழங்குநர் தனிமைப்படுத்தலுக்கும் உதவுகிறது; ஆனால் ஒவ்வொரு வழங்குநரும் உத்தேசிக்கப்பட்ட மண்டலத் தரவை வழங்கி, DNSKEY/DS தொகுப்புகள் சரியாக ஒருங்கிணைக்கப்பட்டிருந்தால்தான் இது செயல்படும். ஊடுருவப்படாத வழங்குநரை ரிசால்வர்கள் தாமாகவே தேர்ந்தெடுக்கும் மாயமான மாற்று வழி இதுவல்ல.

4. பழைய delegation-களும் தொங்கும் பதிவுகளும் வழியான பெயர் சேவையகக் கடத்தல்

இது இன்னும் நுட்பமான மாறுபாடு: டொமைனில் எந்தப் பிரச்சினையும் இல்லை; ஆனால் ஒரு துணை-டொமைன், அதன் அசல் உரிமையாளரின் கட்டுப்பாட்டில் இப்போது இல்லாத மூன்றாம் தரப்புச் சேவையை CNAME அல்லது NS பதிவு வழியாகச் சுட்டிக்காட்டுகிறது. மூன்றாம் தரப்பில் அந்த வளத்தைத் தாக்குநர் பதிவுசெய்து, இப்போது துணை-டொமைனுக்கான பதில்களை வழங்குகிறார்.

எடுத்துக்காட்டுகள்:

• நிறுத்தப்பட்ட பழைய Heroku, S3 அல்லது Azure வளத்துக்குச் சுட்டிக்காட்டும் துணை-டொமைன் CNAME. அந்த வளத்தின் பெயரைத் தாக்குநர் மீண்டும் கைப்பற்றி, செல்லுபடியாகும் TLS சான்றிதழையும் பெறுகிறார்.
• நீக்கப்பட்ட DNS வழங்குநர் கணக்கைச் சுட்டிக்காட்டும் delegated NS பதிவு. அதே host வடிவத்தைப் பயன்படுத்தி தாக்குநர் புதிய கணக்கை உருவாக்கி, துணை-டொமைனுக்குத் தாம் விரும்பும் எந்தப் பதிவையும் வழங்குகிறார்.

இவை அனைத்தும் தொங்கும் DNS என்ற பொதுப் பெயரில் வகைப்படுத்தப்படுகின்றன. அடிப்படை வளம் அகற்றப்பட்ட பிறகும் கைவிடப்பட்ட மூன்றாம் தரப்பு mappings செயல்பாட்டில் நீடிக்கக்கூடும்; எனவே பெரிதாகவும் சரியாகப் பட்டியலிடப்படாமலும் உள்ள துணை-டொமைன் தொகுப்புகளில் அபாயம் அதிகரிக்கிறது.

இதைத் தடுப்பவை:

• உங்களுக்குச் சொந்தமான ஒவ்வொரு மண்டலத்திலும் உள்ள எல்லா NS, CNAME, ALIAS பதிவுகளின் முழுமையான பட்டியல், ஒவ்வொரு பதிவுக்கும் பொறுப்பாளர் குறிப்பிடப்பட்டிருக்க வேண்டும்.
• தானியங்கி dangling-DNS scanners: அட்டவணைப்படி ஒவ்வொரு பதிவையும் மீண்டும் resolve செய்து, இனி பதிலளிக்காத மூன்றாம் தரப்புச் சேவைகளைச் சுட்டிக்காட்டுபவற்றைக் குறிக்க வேண்டும். GitHub வலைப்பதிவு மற்றும் Detectify Labs ஆகியவை இந்தத் தாக்குதல் வகையைப் பற்றிய நீண்டகால விளக்கங்களை வெளியிட்டுள்ளன.
• அடிப்படைச் சேவையை நிறுத்தும் அதே நாளில் அதன் பதிவுகளையும் நீக்குதல்.

5. காலாவதியான டொமைனை மீண்டும் பதிவு செய்தல்

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

இது பாதுகாப்புச் சம்பவத்தைவிடச் செயல்பாட்டுத் தோல்வியைப் போலத் தோன்றலாம். ஆனால் அதன் தாக்கம் ஒன்றே—இப்போது வேறொருவர் பெயரைக் கட்டுப்படுத்துகிறார்; பல ஆண்டுகளாகக் கட்டியெழுப்பப்பட்ட நம்பிக்கைச் சமிக்ஞைகள் (SPF, DKIM, OAuth callback-கள், கடவுச்சொல் மீட்டமைப்பு மின்னஞ்சல்கள், பணம் செலுத்தும் ஒருங்கிணைப்புகள்) அனைத்தும் அறிமுகமற்ற ஒருவரிடம் செல்லத் தொடங்குகின்றன. முந்தைய உரிமையாளர் OAuth token-களின் iss claim ஆகவோ, பரிவர்த்தனை மின்னஞ்சலின் அனுப்புநராகவோ பயன்படுத்தியிருந்த காரணத்திற்காகவே தாக்குநர்கள் காலாவதியான டொமைன்களை வாங்கியதாகப் பொதுவெளியில் ஆவணப்படுத்தப்பட்ட சம்பவங்கள் பல உள்ளன.

இதைத் தடுப்பவை:

• அங்கீகாரம், பணம் செலுத்துதல் அல்லது production போக்குவரத்துடன் தொடர்புடைய எந்த டொமைனுக்கும் பல ஆண்டுப் புதுப்பித்தல் (5-10 ஆண்டுகள்). செலவு மிகச் சிறியது; கிடைக்கும் பாதுகாப்பு குறிப்பிடத்தக்கது.
• கண்காணிக்கப்படும் பணம் செலுத்தல் மற்றும் தோல்வி எச்சரிக்கைகளுடன் தானியங்கிப் புதுப்பித்தல். அட்டைகள் காலாவதியாகலாம்; பணம் செலுத்தும் முயற்சிகள் தோல்வியடையலாம். எனவே தோல்விக்கான தொடர்பு வழியை ஒரு குழு கவனித்தால் மட்டுமே தானியங்கிப் புதுப்பித்தல் பயனுள்ளதாக இருக்கும்.
• 90, 60, 30, 7 நாட்களுக்கு முன் நினைவூட்டல்கள், நிறுவனத்தைவிட்டு விலகக்கூடிய தனிநபரின் inbox-க்கு அல்லாமல், குழுவின் முகவரிக்குச் செல்ல வேண்டும்.

நல்ல பாதுகாப்பு எப்படி இருக்கும்

எல்லாக் கட்டுப்பாடுகளையும் ஒன்றிணைத்தால், முக்கியமான எந்த டொமைனுக்கும் அடிப்படைப் பாதுகாப்பு இப்படி இருக்கும்:

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

Namefi நிலையை எப்படி மாற்றுகிறது

மேலுள்ள பெரும்பாலான கட்டுப்பாடுகள் ஒரு ரெஜிஸ்ட்ரார், ஒரு DNS வழங்குநர் அல்லது ஒரு workflow கருவியின் அம்சங்களாக உள்ளன; தொடர்புடைய கணக்குகளில் மிகவும் பலவீனமான கணக்கையே மொத்தப் பாதுகாப்பு சார்ந்திருக்கும். பாரம்பரிய DNS டொமைன் பதிவுக்கு இணையான கட்டுப்பாட்டு அடுக்காக ஆன்-செயின் டோக்கனை Namefi சேர்க்கிறது. இரண்டு-அடுக்கு மாதிரி விளக்குவது போல, ரெஜிஸ்ட்ரார் மற்றும் பதிவக அடுக்குகள் DNS பெயரைத் தொடர்ந்து இயக்கும் நிலையில், ஆதரிக்கப்படும் உரிமை மற்றும் பரிமாற்ற நடவடிக்கைகளுக்கான கட்டுப்பாட்டுப் புள்ளியாக NFT மாறலாம்.

செயல்முறைக்கு உண்மையிலேயே wallet authorization தேவைப்படும் இடங்களில், இது ரெஜிஸ்ட்ரார் dashboard நற்சான்றுத் திருட்டு அல்லது ஆதரவு வழியாகச் செய்யப்படும் மாற்றங்களின் அபாயத்தைக் குறைக்கக்கூடும். ஆனால் இது சமூகப் பொறியியலை இயலாததாக்குவதோ வழி 1-ஐ முற்றிலும் நீக்குவதோ இல்லை: டொமைன் இன்னும் ரெஜிஸ்ட்ரார் மற்றும் பதிவகச் செயல்முறைகளைச் சார்ந்துள்ளது; wallet தனக்கென key-management மற்றும் recovery அபாயங்களை அறிமுகப்படுத்துகிறது; DNS வழங்குநர் கணக்குகள் தனித் தாக்குதல் பரப்புகளாகவே நீடிக்கின்றன. DNSSEC, புதுப்பித்தல் கட்டுப்பாடுகள், கணக்குப் பாதுகாப்பு, சம்பவ மீட்பு ஆகியவை இன்னும் அவசியம்.

ஆதாரங்களும் கூடுதல் வாசிப்பும்

• ICANN — பரிமாற்றத் தகராறு தீர்வுக் கொள்கையின் வரம்பு.
• IETF — DNSSEC RFC-கள் 4033/4034/4035 மற்றும் பல-கையொப்ப DNSSEC RFC 8901.
• CISA — பல-காரணி அங்கீகார வழிகாட்டுதல்.
• Detectify Labs — தீங்கிழைக்கும் துணை-டொமைன் கைப்பற்றல் குறித்த விளக்கம்.
• Verisign — .com/.net-க்கான Registry lock.