অ্যাক্টিভ রিকনেসান্স ও DNS এনুমারেশন
এই পাঠে যা শিখবেন
- প্যাসিভ থেকে অ্যাক্টিভ রিকনেসান্সে রূপান্তরের ঠিক কোথায় ও কেন গুরুত্বপূর্ণ
- DNS এনুমারেশন ও সাবডোমেইন ডিসকভারি কীভাবে কাজ করে
- Zone transfer অ্যাটাক কী এবং কেন একটি মিসকনফিগারেশন এত ক্ষতিকর হতে পারে
- একটি সঠিকভাবে হার্ডেনড DNS সার্ভার এই অ্যাটাক কীভাবে প্রতিরোধ করে
১ · অ্যাক্টিভ রিকনেসান্স — যখন ইন্টারঅ্যাকশন শুরু হয়
অ্যাক্টিভ রিকনেসান্সActive Reconnaissanceটার্গেট ইনফ্রাস্ট্রাকচারের সাথে সরাসরি ইন্টারঅ্যাক্ট করে তথ্য সংগ্রহ করা (যেমন DNS কোয়েরি, ping) — টার্গেটের সিস্টেমে সরাসরি request পৌঁছায় বলে এটি ডিটেক্ট করা সম্ভব। L10-এর প্যাসিভ রিকনেসান্স থেকে একটি গুণগত পরিবর্তন — এখন টার্গেটের ইনফ্রাস্ট্রাকচারে সরাসরি request পাঠানো হচ্ছে (একটি DNS কোয়েরি, একটি ping)। যেহেতু এই request টার্গেটের সিস্টেমে পৌঁছায় ও লগ হতে পারে, এই পর্যায়টি ডিটেক্টেবল — এবং এখান থেকেই লিখিত অনুমতির (L01) প্রশ্নটি সত্যিকার অর্থে সক্রিয় হয়ে ওঠে।
২ · DNS এনুমারেশন — সাবডোমেইন খুঁজে বের করা
একটি কোম্পানির প্রধান ওয়েবসাইট (example.com) ছাড়াও প্রায়ই আরও অনেক সাবডোমেইন থাকে যা কোম্পানি
নিজেও ভুলে গেছে — dev.example.com, staging.example.com, বা এমনকি একটি ভুলে-যাওয়া
old-admin.example.com। DNS এনুমারেশন এই সাবডোমেইনগুলো পদ্ধতিগতভাবে খুঁজে বের করার
কৌশল — একজন ডিফেন্ডারের জন্য এটি গুরুত্বপূর্ণ কারণ প্রায়ই সবচেয়ে দুর্বল entry point হয় সেই "ভুলে-যাওয়া"
সাবডোমেইনগুলো, প্রধান ওয়েবসাইট নয়।
৩ · Zone Transfer — একটি মিসকনফিগারেশন যা পুরো জোন ফাঁস করে দেয়
DNS সার্ভারগুলো সাধারণত একটি primary ও এক বা একাধিক secondary সার্ভার নিয়ে কাজ করে, এবং secondary সার্ভারগুলো primary থেকে পুরো জোন ফাইল (একটি ডোমেইনের সব রেকর্ডের সম্পূর্ণ তালিকা) সিঙ্ক করে নেয় — এই সিঙ্ক প্রক্রিয়াটিই zone transferZone Transferএকটি DNS সার্ভার থেকে অন্য একটি (সাধারণত secondary) সার্ভারে সম্পূর্ণ জোন ফাইল (একটি ডোমেইনের সব রেকর্ড) কপি করার প্রক্রিয়া।। সমস্যা হয় তখন, যখন একটি DNS সার্ভার ভুলভাবে কনফিগার করা থাকে — অর্থাৎ এটি যেকোনো অনুরোধকারীকে (শুধু অনুমোদিত secondary সার্ভার নয়) একটি zone transfer request-এর জবাবে পুরো জোন ফাইল পাঠিয়ে দেয়। এর মানে একজন আক্রমণকারী এক request-এই কোম্পানির প্রতিটি সাবডোমেইন, প্রতিটি অভ্যন্তরীণ hostname একবারেই পেয়ে যেতে পারে।
একটি সঠিকভাবে কনফিগার করা DNS সার্ভার শুধুমাত্র তার নিজস্ব, পূর্ব-নির্ধারিত অনুমোদিত secondary সার্ভারের তালিকার (allowlist) IP থেকে আসা zone transfer request গ্রহণ করে — অন্য যেকোনো IP থেকে আসা একই request সরাসরি প্রত্যাখ্যাত হওয়া উচিত। এই একটি সাধারণ চেক-ই একটি প্রতিষ্ঠানের পুরো অভ্যন্তরীণ DNS কাঠামো ফাঁস হওয়া ঠেকিয়ে দিতে পারে।
৪ · সিমুলেশন — সঠিক বনাম মিসকনফিগার করা DNS সার্ভার
নিচের কোড সেলে আমরা একটি DNS জোনকে একটি ইন-মেমরি dict হিসেবে সিমুলেট করছি এবং একটি
attempt_zone_transfer() ফাংশন লিখছি যা allowed_ips-এর বিরুদ্ধে requester-এর IP
যাচাই করে। প্রথমে দেখব একটি সঠিকভাবে হার্ডেনড সার্ভার কীভাবে একজন অনুমতিহীন requester-কে প্রত্যাখ্যান করে,
তারপর একটি মিসকনফিগার করা সার্ভার (খালি allowed_ips-এর কারণে চেক বাইপাস হয়ে যাওয়া) কীভাবে
সবকিছু ফাঁস করে দেয়।
# সিমুলেটেড DNS জোন — ইন-মেমরি dict, বাস্তব DNS সার্ভার নয়
dns_zone = {
"www.example-corp.com": "203.0.113.10",
"mail.example-corp.com": "203.0.113.11",
"dev.example-corp.com": "203.0.113.55", # ভুলে-যাওয়া dev সার্ভার
"old-admin.example-corp.com": "203.0.113.99", # ভুলে-যাওয়া admin প্যানেল
}
def attempt_zone_transfer(zone, allowed_ips, requester_ip):
"""
সঠিকভাবে কনফিগার করা DNS সার্ভারের আচরণ:
শুধুমাত্র allowed_ips তালিকায় থাকা requester-কেই পুরো জোন দেওয়া হয়।
"""
if requester_ip in allowed_ips:
return dict(zone) # অনুমোদিত secondary সার্ভার — পুরো জোন সিঙ্ক করা হচ্ছে
return None # অনুমোদিত নয় — প্রত্যাখ্যাত
# --- দৃশ্য ১: সঠিকভাবে হার্ডেনড সার্ভার ---
trusted_secondaries = ["198.51.100.20"] # শুধু বৈধ secondary DNS সার্ভারের IP
result = attempt_zone_transfer(dns_zone, trusted_secondaries, requester_ip="45.33.12.7")
print("দৃশ্য ১ — অনুমোদনহীন IP থেকে zone transfer অনুরোধ:")
print(" ফলাফল:", "প্রত্যাখ্যাত (None)" if result is None else result)
result_ok = attempt_zone_transfer(dns_zone, trusted_secondaries, requester_ip="198.51.100.20")
print("\nদৃশ্য ১ — বৈধ secondary সার্ভার থেকে অনুরোধ:")
print(" ফলাফল:", "গৃহীত, জোন সিঙ্ক হয়েছে" if result_ok else "প্রত্যাখ্যাত")
# --- দৃশ্য ২: মিসকনফিগার করা সার্ভার — allowed_ips খালি রাখা হয়েছে ---
misconfigured_allowed_ips = [] # কেউ কখনো এটি সঠিকভাবে সেট করেনি — সাধারণ বাস্তব ভুল
def attempt_zone_transfer_misconfigured(zone, allowed_ips, requester_ip):
"""মিসকনফিগারেশন সিমুলেশন: খালি তালিকা ভুলবশত 'সব অনুমোদিত' হিসেবে ট্রিট হচ্ছে।"""
if not allowed_ips or requester_ip in allowed_ips:
return dict(zone)
return None
leak = attempt_zone_transfer_misconfigured(dns_zone, misconfigured_allowed_ips, requester_ip="45.33.12.7")
print("\nদৃশ্য ২ — একই অনুমোদনহীন IP, কিন্তু সার্ভার মিসকনফিগার করা:")
print(" ফলাফল:", leak)
দৃশ্য ২-তে old-admin.example-corp.com-এর মতো একটি ভুলে-যাওয়া সাবডোমেইনও পুরো জোন ফাইলের সাথে
ফাঁস হয়ে যায় — একটি ছোট্ট কোডিং ভুল (if not allowed_ips লজিক ভুলবশত একটি "সবার জন্য খোলা"
অবস্থা তৈরি করে) কীভাবে একটি সম্পূর্ণ অবকাঠামোর মানচিত্র ফাঁস করে দিতে পারে, তার একটি বাস্তব-সদৃশ উদাহরণ।
এই কারণেই DNS হার্ডেনিং চেকলিস্টে "zone transfer শুধুমাত্র নির্দিষ্ট secondary IP-তে সীমাবদ্ধ" — একটি
আবশ্যক আইটেম হিসেবে থাকে।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ একটি DNS কোয়েরি কেন "অ্যাক্টিভ" রিকনেসান্স হিসেবে গণ্য হয়, অথচ একটি WHOIS লুকআপ (L10) "প্যাসিভ" হিসেবে গণ্য হয়?
একটি DNS কোয়েরি সরাসরি টার্গেট প্রতিষ্ঠানের নিজস্ব DNS সার্ভারে request পাঠায় — সেই সার্ভারের লগে এই request রেকর্ড হতে পারে। একটি WHOIS লুকআপ একটি সম্পূর্ণ ভিন্ন, তৃতীয়-পক্ষের রেজিস্ট্রি সার্ভারে যায় — টার্গেট প্রতিষ্ঠানের নিজস্ব কোনো সিস্টেমেই request পৌঁছায় না। এই পার্থক্যটাই — "কার সিস্টেমে request যাচ্ছে" — প্যাসিভ ও অ্যাক্টিভের মধ্যে সীমারেখা টানে।
প্র ০২ একটি zone transfer লিক কেন শুধু "কিছু ঠিকানা জানা যাওয়া"-র চেয়ে বেশি বিপজ্জনক?
একটি zone transfer একবারে পুরো অভ্যন্তরীণ DNS কাঠামো প্রকাশ করে দেয় — শুধু প্রধান ওয়েবসাইট নয়, বরং সব ভুলে-যাওয়া dev/staging/admin সাবডোমেইন, অভ্যন্তরীণ সার্ভিসের hostname, এমনকি কখনো কখনো অভ্যন্তরীণ IP রেঞ্জের ইঙ্গিতও। এটি একজন আক্রমণকারীকে একটি সম্পূর্ণ "মানচিত্র" এক request-এই দিয়ে দেয়, যা অন্যথায় শত শত পৃথক সাবডোমেইন-অনুমান কোয়েরির মাধ্যমে ধীরে ধীরে (এবং বেশি ডিটেক্টেবলভাবে) সংগ্রহ করতে হতো।
প্র ০৩
উপরের কোড সেলে attempt_zone_transfer_misconfigured-এর if not allowed_ips or requester_ip in allowed_ips লাইনটির ঠিক কোন অংশটি বাস্তব দুনিয়ায় একটি সাধারণ প্রোগ্রামিং ভুল?
not allowed_ips অংশটি সমস্যাজনক — এটি বলছে "যদি allowed_ips তালিকা খালি হয়, তাহলে অনুমতি
দাও" (True হয়ে যায় যখন তালিকা খালি)। বাস্তবে ডেভেলপাররা প্রায়ই এমন একটি ডিফল্ট-খোলা আচরণ লিখে ফেলেন
ভেবে "খালি তালিকা মানে কোনো সীমাবদ্ধতা নেই", যখন প্রকৃতপক্ষে খালি তালিকার সঠিক অর্থ হওয়া উচিত ছিল
"কাউকেই অনুমতি নেই" — এই একটি উল্টো-অনুমান-ই একটি বাস্তব, ব্যাপকভাবে-ঘটা মিসকনফিগারেশন প্যাটার্ন
(ties to L23-এর সিকিউরিটি মিসকনফিগারেশন)।
অনুশীলন
-
চিন্তা করুন: কেন একজন ডিফেন্ডার নিয়মিতভাবে নিজের প্রতিষ্ঠানের সাবডোমেইন তালিকা নিজেই এনুমারেট করে দেখা উচিত, শুধু অ্যাটাকারদের অপেক্ষা করার বদলে?
এই অনুশীলনকে বলা হয় "attack surface management" — একজন ডিফেন্ডার যদি নিজেই প্রথমে নিজের ভুলে-যাওয়া সাবডোমেইনগুলো খুঁজে বের করেন, তাহলে তিনি সেগুলো সময়মতো বন্ধ/সুরক্ষিত করতে পারেন, আক্রমণকারী খুঁজে পাওয়ার আগেই। এটি একটি proactive প্রতিরক্ষা কৌশল — অপেক্ষা করার বদলে নিজের দুর্বলতা নিজে আগে খুঁজে বের করা।
-
পরীক্ষা করুন: উপরের কোড সেলে
trusted_secondaries-এ requester-এর IP ("45.33.12.7") যোগ করে আবারattempt_zone_transferচালান — ফলাফল কীভাবে বদলায় লক্ষ্য করুন।একবার
"45.33.12.7"trusted_secondariesতালিকায় যোগ হয়ে গেলে, একইrequester_ip-এর জন্যattempt_zone_transferএখন পুরো জোন ফেরত দেবে (আগে যা প্রত্যাখ্যাত হয়েছিল) — এটি স্পষ্টভাবে দেখায় ফলাফলটি সম্পূর্ণভাবে allowlist-এর বিষয়বস্তুর উপর নির্ভরশীল, requester-এর IP নিজে "ভালো" বা "খারাপ" নয়।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৬০টি পাঠ পরবর্তী পাঠ — পোর্ট স্ক্যানিং ও Nmap কনসেপ্ট — শীঘ্রই যুক্ত হবে।
- Discrete Mathematics কোর্স সহায়ক কোর্স RSA এনক্রিপশন ও নাম্বার থিওরির গণিত শিখতে দেখুন — M7 ক্রিপ্টোগ্রাফি মডিউলের ভিত্তি।
- System Design & Software Architecture কোর্স সঙ্গী কোর্স এনক্রিপশন, অথেন্টিকেশন ও লগিং কীভাবে বড় সিস্টেমে প্রয়োগ হয় তা শিখতে দেখুন।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design ও Cybersecurity — সব এক জায়গায়।