sudo দিয়ে চালালে পোর্ট স্ক্যান কেন বদলে যায়

Nmap সবসময় ঠিক সেই প্যাকেট পাঠায় না যা আপনি ভেবেছেন আপনি চেয়েছেন। raw সকেট না থাকলে এটি ডিফল্ট SYN স্ক্যানের জায়গায় TCP connect স্ক্যান বসায়, তাই আপনার সাধারণ ব্যবহারকারী হিসেবে চালানো এবং sudo-তে চালানো একই পোর্ট সম্পর্কে আলাদা প্রশ্নের উত্তর দিতে পারে। ফলাফলগুলো অনুমতি-সমস্যার মতো দেখায়, অথচ সাধারণত সেগুলো একটি পদ্ধতি-পরিবর্তন। পদ্ধতিটা স্পষ্ট করা ছাড়া দুটি চালনাকে আদৌ তুলনা করার উপায় নেই।

দুটি প্রোব, একটি পোর্ট, আলাদা কোড-পথ

SYN স্ক্যান নিজেই TCP হেডার তৈরি করে, raw সকেট থেকে পাঠায়, আর কার্নেলের TCP স্ট্যাক কোনো সম্পূর্ণ সংযোগ নথিভুক্ত করার আগেই নেটওয়ার্ক থেকে উত্তর পড়ে। connect স্ক্যান অপারেটিং সিস্টেমকে একটি সাধারণ সকেট খুলতে বলে এবং connect() যা ফেরত দেয় তা জানায়। দুটোই একটি পোর্টকে খোলা বলতে পারে, কিন্তু কেবল একটি অর্ধ-খোলা প্রচেষ্টা রেখে যায় এবং কেবল একটি পাঠানো প্রক্রিয়ার সাথে যুক্ত সকেট-স্তরের নীতির অধীন।

raw পথের জন্য CAP_NET_RAW দরকার, তাই সেই ক্ষমতা না থাকলে ডিফল্ট স্ক্যান নিঃশব্দে দুর্বল হয়ে পড়ে। Nmap-এর নিজস্ব স্ক্যান-কৌশল রেফারেন্স এই প্রতিস্থাপন নথিভুক্ত করে: connect স্ক্যান হলো বিকল্প, কারণ এর কোনো বিশেষ অনুমতি লাগে না। বেশিরভাগ চালনায় কোনো সতর্কবার্তা ছাড়াই এই বদল ঘটে, আর ঠিক সেজন্যই এটি ভুল পড়া এত সহজ। বিকল্পটা আছে জেনে গেলে “root হিসেবে খোলা, ব্যবহারকারী হিসেবে বন্ধ” আর অনুমতি-বাগের মতো শোনায় না, বরং দুটি আলাদা মাপের মতো শোনায়।

স্ক্যানে sudo আসলে কী বদলায়

অনুমতি বাড়ালে raw সকেটের পথ ফিরে আসে, আর তা রায়ের চেয়ে বেশি কিছু বদলায়। উৎস পোর্ট নির্বাচন, প্যাকেটের সময়, পুনঃপ্রেরণের আচরণ এবং ফিল্টার করা উত্তর কীভাবে শ্রেণীবদ্ধ হয়, সবই আসে ভিন্ন কোড থেকে। SYN-এর হার সীমিত করে এমন মধ্যস্থ ডিভাইস গন্তব্য হোস্ট অভিন্ন হলেও দুটি চালনাকে অসমভাবে দেখে।

গন্তব্যের দিকের লগিংও আলাদা হয়। সম্পূর্ণ হ্যান্ডশেক সার্ভিস এবং যেকোনো সকেট হিসাবের কাছে দৃশ্যমান, কিন্তু রিসেট হওয়া অর্ধ-খোলা প্রোব সাধারণত দৃশ্যমান নয়। আপনি যদি এমন হোস্টের বিরুদ্ধে চালনা তুলনা করেন যার লগও আপনি পড়েন, তবে যে পার্থক্য দেখেন তার একটি অংশ হলো পর্যবেক্ষণ নিজেই।

উভয় চালনায় পদ্ধতি স্থির রাখুন

উভয় আহ্বানে একই কৌশল জোর করে বসান, তাহলে তুলনাটা অর্থ বহন করতে শুরু করে। -sT ফ্ল্যাগ স্পষ্টভাবে connect স্ক্যান চায়, -Pn হোস্ট আবিষ্কার বাদ দেয়, -n নাম সমাধান বাদ দেয়, এবং একটি -p পোর্ট-তালিকার পার্থক্য বাদ দেয়।

nmap -sT -Pn -n -p 8443 198.51.100.77
sudo nmap -sT -Pn -n -p 8443 198.51.100.77

ঠিকানাটি আর পোর্টটি এমন হোস্ট দিয়ে বদলান যেটি পরীক্ষা করার অনুমতি আপনার আছে; উপরের ডকুমেন্টেশন-রেঞ্জটি একটি নমুনা, লক্ষ্য নয়। দুটি চালনা এখন মিলে গেলে মূল পার্থক্যটি স্ক্যান-পদ্ধতি থেকেই এসেছিল। তবুও না মিললে অন্য কিছু ট্রাফিক শ্রেণীবদ্ধ করছে, আর পরের অংশটাই খোঁজার জায়গা।

অ্যাকাউন্ট প্রসঙ্গ কেবল একটি অনুমতি-ফ্ল্যাগ নয়

একটি VPN স্থাপনা প্যাকেটগুলো UID দিয়ে, cgroup দিয়ে, বা সকেট খোলা প্রক্রিয়ার সাথে যুক্ত নিয়ম দিয়ে শ্রেণীবদ্ধ করতে পারে। তখন root ট্রাফিক আর ব্যবহারকারীর ট্রাফিক আলাদা রাউটিং টেবিল দিয়ে বেরোয় বা আলাদা নিয়ম-সমষ্টিতে পড়ে, আর স্ক্যান-পদ্ধতির কোনো শৃঙ্খলা তাদের মিলিয়ে দিতে পারে না।

সুবিধাটি নয়, নীতিটি দেখুন। Linux-এ nftables এটি meta skuid দিয়ে প্রকাশ করে আর iptables প্রকাশ করে মালিক-মিল দিয়ে, এবং যেকোনোটি একটি UID-কে টানেল দিয়ে পাঠাতে পারে যখন অন্যটি ভৌত ডিফল্ট রুট ব্যবহার চালিয়ে যায়।

sudo nft list ruleset | grep -n skuid
sudo iptables-save | grep -n uid-owner
ip rule show
ip route get 198.51.100.77

ফলাফল তুলনা করার আগে প্রোবটি নিশ্চিত করুন

সিদ্ধান্তে পৌঁছানোর আগে প্রমাণ করুন কোন প্রোবটি চলেছিল। Nmap নিজের আউটপুটে কৌশলটির নাম বলে, আর --reason প্রতিটি অবস্থার পেছনের প্রমাণ যোগ করে, আর সেই অংশটিই বলে দেয় হ্যান্ডশেক সত্যিই সম্পূর্ণ হয়েছিল কি না।

nmap --reason -sT -Pn -n -p 8443 198.51.100.77
sudo nmap --reason -sS -Pn -n -p 8443 198.51.100.77
getcap "$(command -v nmap)"
capsh --print | grep -i net_raw

ভিন্ন কারণে একই অবস্থা জানানো দুটি চালনা পরস্পরবিরোধী নয়, আর একই কারণে ভিন্ন অবস্থা জানানো দুটি চালনা স্ক্যানের দিকে নয়, রাউটিং বা নীতির দিকে ইঙ্গিত করে। গন্তব্য, পোর্ট, নেমস্পেস আর সময় অভিন্ন রাখুন, তারপর একবারে একটি চলক বদলান। সার্ভিসটি root হিসেবে চালানো নীতি-অমিলের সমাধান নয়; সমাধান হলো সেবার মালিকের মাধ্যমে অভীষ্ট নীতিটি প্রকাশ করা।