উচ্চ বন্দর নম্বর ব্যবহার করা নিরাপদ? (পুনরায়: ওয়েব পরিষেবাগুলিকে অস্পষ্ট করে)


9

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

একটি আপস হিসাবে, খুব বড় পোর্ট সংখ্যা ব্যবহার করা ভাল কি? (যেমন 65531 অবধি পাঁচ অঙ্ক)

আমি পড়েছি যে পোর্ট স্ক্যানাররা সাধারণত প্রথম 10,000 পোর্ট স্ক্যান করে তাই খুব বেশি বন্দর নম্বর ব্যবহার করা কিছুটা সুরক্ষিত।

এটা কি সত্য?

ওয়েব সার্ভারগুলি সুরক্ষার জন্য আরও ভাল উপায় আছে? (যেমন অ্যাপ্লিকেশনগুলির জন্য ওয়েব গুইস)


এটি সত্য নয়. ব্রডব্যান্ড অ্যাক্সেস সহ আধুনিক (এমনকি ডেস্কটপ) মাল্টি-কোর সিপিইউ মেশিনগুলি সেকেন্ডে সমস্ত 65535 পোর্ট স্ক্যান করতে পারে। এমনকি যদি আক্রমণকারী কোনও ডিএস গেটগুলি বানিয়ে ফেলার জন্য তাদের দুই সেকেন্ডের মধ্যে স্থান দেওয়ার সিদ্ধান্ত নিয়েছে, তবে কে যত্নশীল, আপনি কি আপনার সিস্টেমটিকে এক দিনেরও বেশি সময় রেখে দিচ্ছেন, তাই না? একটি পুরানো ম্যাক্সিম হ'ল অন্যরা যেমন নীচে বলেছেন যে "অস্পষ্টতার মাধ্যমে সুরক্ষা" ডিজিটাল বিশ্বে মূলত অকেজো।
মিসানফোর্ড

উত্তর:


9

আমি পড়েছি যে পোর্ট স্ক্যানাররা সাধারণত প্রথম 10,000 পোর্ট স্ক্যান করে তাই খুব বেশি বন্দর নম্বর ব্যবহার করা কিছুটা সুরক্ষিত।

অনেকে এটি বিশ্বাস করে। আমি না।

সম্ভবত এটি কিছুটা বেশি সুরক্ষিত তবে বেশি নয়। নিম্ন সংখ্যাযুক্ত বন্দরগুলি আরও সাধারণ, তাই কিছু স্ক্যানার সেখানে প্রথমে দেখবে।

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

কিছু স্ক্যানার এই বিশ্বাসকে কাজে লাগায় এবং শীর্ষে থেকে শুরু করে তাদের তালিকার নীচে কাজ করে। অন্যান্য স্ক্যানগুলি পুরো পরিসীমা জুড়ে এলোমেলো বন্দরগুলি বেছে নেবে, সুতরাং সমস্ত বন্দরগুলিতে স্ক্যান হওয়ার সমান সুযোগ রয়েছে।

এগিয়ে যান এবং এনএমএএপি ব্যবহার করে নিজেই এটি পরীক্ষা করুন । ১-১০,০০০ পোর্টগুলির বিপরীতে একটি এনএমএপ স্ক্যান চালান এবং এইচটিটিপি সার্ভারের সন্ধান করুন এবং এটি এমন স্ক্যানের সাথে তুলনা করুন যা সমস্ত 1-65, এক্সএক্সএক্স পোর্টগুলির বিরুদ্ধে স্ক্যান করে। আপনি দেখতে পাবেন যে পার্থক্যটি সাধারণত 3-10 মিনিটের হয়। যদি আমি নেসাসের মতো কিছু ব্যবহার করে বিশদ স্ক্যান করি তবে পার্থক্যটি কখনও কখনও 20-60 মিনিটের মধ্যে হয়।

একটি ভাল ক্র্যাকার হ'ল রোগী ক্র্যাকার। তারা অপেক্ষা করবে।


1
ধরে নিই যে অন্যান্য সমস্ত প্রাসঙ্গিক সুরক্ষা ব্যবস্থা কার্যকর করা হয়েছে, এটি কি পোর্ট সংখ্যাকে অস্পষ্ট করে দেওয়া ভাল বা খারাপ হতে পারে? আমার চিন্তাভাবনাটি হ'ল যদি সার্ভারটি নির্দিষ্টভাবে লক্ষ্যবস্তু না করা হয় তবে এটি কিছুটা ভাল হবে।
wag2639

2
+1 "একটি ভাল ক্র্যাকার হ'ল রোগী ক্র্যাকার They তারা অপেক্ষা করবে" "
মিশনফোর্ড

@ wag2639 আপনি কোনও পরিষেবার পোর্ট নম্বর পরিবর্তন করে সত্যই কিছু করছেন না তবে একটি স্ক্রিপ্ট-কিডিকে কিছুটা ভাল স্ক্রিপ্ট সন্ধান করতে পারেন। আইপিগুলির একটি ব্লক ওয়ার ডায়ালিং এবং প্রতিটি একক বন্দর পোর্টস্ক্যানিং তুচ্ছ।
মিসানফোর্ড

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

3

বিজোড় পোর্ট নম্বর ব্যবহার করা কোনও সুরক্ষা নয় যতক্ষণ না আপনি এই সত্যটি মজবুত করেন যে এটি আপনাকে আপনার অ্যাপ্লিকেশনটি একটি অ-রুট ব্যবহারকারী হিসাবে চালানোর অনুমতি দিচ্ছে।

এই ধরণের জিনিসটিকে অস্পষ্টতার দ্বারা সুরক্ষা হিসাবে বিবেচনা করা যেতে পারে তবে এটি আসলে সুরক্ষা নয়।


তখন কি পূর্ণ বিকাশিত ভিপিএন ব্যবহারের কোনও বিকল্প আছে? সম্ভবত অতিরিক্ত লগইন / পাসওয়ার্ড সুরক্ষা আছে এমন কোনও ধরণের বিপরীত ওয়েব প্রক্সি রয়েছে? (স্কুইড এটি করে না)
সোফাকং

@ সোফাকং: আপনি স্টানেল: স্টানেল.আর.এস
ম্যাক্সওয়েল

3

আপনি যদি উভয় প্রান্তে লিনাক্স ব্যবহার করে থাকেন তবে আপনি একটি এসএসএস টানেলও ব্যবহার করতে পারেন:

ssh -f -N -L 9090:localhost:9090 user@remote-host

উদাহরণস্বরূপ, আমি দূরবর্তী হোস্টে 9090 পোর্টটি আমার স্থানীয় বন্দরে 9090 এর জন্য ফরোয়ার্ড করতে cherokee-adminব্যবহার করি এবং অন্যান্য ওয়েব জিইউআইয়ের জন্য আমি একই ধরণের সেটআপ ব্যবহার করি। অ্যাপ্লিকেশনগুলিকে অ্যাপ্লিকেশনটি কনফিগারেশনে নির্দিষ্ট করে যে তারা কেবল লোকালহোস্টে চালিত করে, এইভাবে সুরক্ষা দিতে পারে 127.0.0.1। এইভাবে তারা বাইরে থেকে পৌঁছনীয় নয়, তবে আপনি তাদের সাথে ফরোয়ার্ড করতে পারেন ssh। পরীক্ষা করে দেখুন man sshআরও বিকল্প পোর্ট ফরওয়ার্ড ব্যবহার করার জন্য (তত্সহ এক্স, যা সম্পূর্ণরূপে অন্যভাবে আপনার সমস্যা সমাধানের পারে।)

এটি আপনার সেটআপের উপর নির্ভর করে অতিরিক্ত সফ্টওয়্যার ইনস্টল / কনফিগার না করে আপনার লক্ষ্য অর্জনের উপযুক্ত উপায় হতে পারে।


1

যদি আপনার ফায়ারওয়াল এটির অনুমতি দেয় তবে আপনি প্রথমে ফায়ারওয়াল স্তরে প্রমাণীকরণ করতে পারবেন, যদি আপনার পাসওয়ার্ডগুলির জটিলতা ভালভাবে বিবেচনা করা হয়, তবে এটি উন্মুক্ত পরিষেবাদির সুরক্ষা কার্যকর করতে হবে। উদাহরণস্বরূপ স্টানেল এবং মিউচুয়াল লেখার ব্যবহার করে আপনি এসএসএল টানেলিং ব্যবহার করতে পারেন ।

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


আমি pfsense ব্যবহার করছি এবং আমার কিছু ওয়েব পরিষেবাদিতে বিল্ট-ইন এসএসএল (এইচটিটিপিএস) সমর্থন রয়েছে। এখনও স্ট্যান্ডেল ব্যবহার করা ভাল? "ফায়ারওয়ালের প্রমাণীকরণ" স্তরে টানেল ব্যবহার করা হচ্ছে?
সোফাকং

1
আপনি কীভাবে "ফায়ারওয়ালে প্রমাণীকরণ" করবেন?
wag2639

আমি জানি না যে পিফসেনসের সেই কার্যকারিতা রয়েছে কিনা তবে জুনিপার্স রাউটারগুলিতে আপনি স্থানীয় ব্যবহারকারীরা (এমনকি রেডিয়াস) এইচটিটিপি অনুবাদকৃত ট্র্যাফিকের অ্যাক্সেস দিতে পারেন। স্ট্যানেল সম্পর্কিত আপনি শংসাপত্রগুলির সাথে মিউচুয়াল লেখাগুলি ব্যবহার করতে পারেন, স্ট্রানাল এইচটিটিপি ট্রাফিককে এসএসএল দিয়ে সজ্জিত করবে এবং প্রমাণীকরণ হ্যান্ডেল করবে।
ম্যাক্সওয়েল
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.