ব্রুট-ফোর্স ব্যবহারকারীর নাম ট্র্যাক করার সর্বোত্তম উপায় / ব্যর্থ ব্যবহারকারীর নাম প্রচেষ্টা AD


9

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

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

আমার প্রশ্ন: 1) কোনও কেন্দ্রীয় স্থানে এই ব্যর্থ ইউজারনেম অনুরোধগুলিতে লগ করার জন্য অ্যাক্টিভ ডিরেক্টরি পাওয়ার কোনও উপায় আছে যাতে আমরা সেগুলিতে স্পাইকটি লক্ষ্য করতে পারি?

2) যদি তা না হয় তবে ভবিষ্যতে এই ধরণের আক্রমণকে সক্রিয়ভাবে নিরীক্ষণ এবং সক্রিয় করার জন্য সর্বোত্তম উপায়টি (আশা করি খুব বেশি নতুন সরঞ্জাম কিনে না দিয়ে))

আপনার সাহায্যের জন্য ধন্যবাদ.

উত্তর:


11

দুর্দান্ত প্রশ্ন।

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

(জীবনের জন্য নীল দল!)

আমার প্রশ্ন: 1) কোনও কেন্দ্রীয় স্থানে এই ব্যর্থ ইউজারনেম অনুরোধগুলিতে লগ করার জন্য অ্যাক্টিভ ডিরেক্টরি পাওয়ার কোনও উপায় আছে যাতে আমরা সেগুলিতে স্পাইকটি লক্ষ্য করতে পারি?

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

স্পষ্টতই ব্যর্থতাগুলি কেবল অ্যাপলিকেশন ইনস্টল হওয়া সার্ভারের স্থানীয় ইভেন্ট লগে প্রদর্শিত হয়েছিল।

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

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

এখন, আপনার পরবর্তী প্রশ্নে:

2) যদি তা না হয় তবে ভবিষ্যতে এই ধরণের আক্রমণকে সক্রিয়ভাবে নিরীক্ষণ এবং সক্রিয় করার জন্য সর্বোত্তম উপায়টি (আশা করি খুব বেশি নতুন সরঞ্জাম কিনে না দিয়ে))

দু'টো জিনিস।

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

(দুঃখিত, সেই ধরণের 'খুব বেশি নতুন জিনিস কিনে না দিয়ে' ক্লজটি আপনার কাছে পড়ে))

আর একটি জিনিস যা আপনাকে সহায়তা করতে পারে তা হ'ল রেজিস্ট্রি প্রবেশ:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

LogLevel = 1

নথিভুক্ত এখানে

আপনি যদি এই রেজিস্ট্রি এন্ট্রি সক্ষম করেন তবে আপনার নিরাপত্তা ইভেন্টের লগের কার্বেরোস ত্রুটি সম্পর্কিত ইভেন্টগুলিতে প্লাবিত হওয়া উচিত যা উল্লেখ করে যে কার্বেরোস প্রাক-প্রমাণীকরণের প্রয়োজন। এই জাতীয় ঘটনার উদাহরণ:

A Kerberos Error Message was received:
 on logon session DOMAIN\serviceaccount
 Client Time: 
 Server Time: 12:44:21.0000 10/9/2012 Z
 Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED
 Extended Error: 
 Client Realm: 
 Client Name: 
 Server Realm: DOMAIN
 Server Name: krbtgt/DOMAIN
 Target Name: krbtgt/DOMAIN@DOMAIN
 Error Text: 
 File: e
 Line: 9fe
 Error Data is in record data.

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

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

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


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

0

এটি একটি আকর্ষণীয় প্রশ্ন যা আমি সঠিক উত্তর শুনতে পছন্দ করি। আমি এমন কিছু তথ্য পেয়েছি যা ডগের পক্ষে সহায়ক হতে পারে তবে আমি মনে করি এটি কিছুটা অপ্রতুল হতে পারে। অন্য কেউ সম্ভবত একটি বর্ধিত উত্তর প্রদান করতে পারেন:

সার্ভারে আপনার লগইন করুন যা আপনি চালনা করতে চান -> আরএসওপি.এমএসসি -> কম্পিউটার কনফিগারেশন -> উইন্ডোজ সেটিংস -> সুরক্ষা সেটিংস -> স্থানীয় নীতি -> নিরীক্ষা নীতি -> "নিরীক্ষণ অ্যাকাউন্ট লগনের ইভেন্টগুলি" এবং " নিরীক্ষণ লগনের ইভেন্টগুলি "

"অ্যাকাউন্ট লগনের ইভেন্টগুলি" এর ব্যাখ্যাটি পড়ে:

অডিট অ্যাকাউন্ট লগনের ইভেন্টগুলি

এই সুরক্ষা সেটিংটি নির্ধারণ করে যে এই কম্পিউটারটি কোনও অ্যাকাউন্টের শংসাপত্রগুলি বৈধ করে প্রতিবার ওএস অডিট করে।

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

যদি এই নীতি সেটিংটি সংজ্ঞায়িত করা হয় তবে প্রশাসক কেবলমাত্র সাফল্য, কেবলমাত্র ব্যর্থতা, উভয় সাফল্য এবং ব্যর্থতা অডিট করতে হবে বা এই ইভেন্টগুলি মোটেও নিরীক্ষণ করবেন না (যেমন সফলতা বা ব্যর্থতা নয়) তা নির্দিষ্ট করতে পারে।

"লগন ইভেন্টগুলি" এর ব্যাখ্যাটি পড়ে:

নিরীক্ষণ লগনের ইভেন্টগুলি

এই সুরক্ষা সেটিংটি নির্ধারণ করে যে কোনও ব্যবহারকারী এই কম্পিউটারে লগ-ইন করতে বা লগ-ইন করার চেষ্টা করছে এমন প্রতিটি ক্ষেত্রেই ওএস অডিট করে।

লগ-অফ ইভেন্টগুলি তৈরি করা হয় যখনই ব্যবহারকারীর অ্যাকাউন্টের লগন সেশনটি শেষ হয়। যদি এই নীতি সেটিংটি সংজ্ঞায়িত করা হয় তবে প্রশাসক কেবলমাত্র সাফল্য, কেবলমাত্র ব্যর্থতা, উভয় সাফল্য এবং ব্যর্থতা অডিট করতে হবে বা এই ইভেন্টগুলি মোটেও নিরীক্ষণ করবেন না (যেমন সফলতা বা ব্যর্থতা নয়) তা নির্দিষ্ট করতে পারে।

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

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


1
আমি এমএসএফটি বা নীস্ট বেসলাইনগুলির পরামর্শ দেব, ডিআইএসএ হোস্টকে সত্তা হিসাবে সুরক্ষিত করার পরিবর্তে পরিবেশ সম্পর্কে অনুমান করে। হ্যাঁ যথাযথ নিরীক্ষণ প্রয়োজন। আমি অ্যাক্টিভ ডিরেক্টরি হোয়াইট পেপার সুরক্ষিত করার জন্য সেরা অনুশীলনগুলিও পড়তাম।
জিম বি

দুর্দান্ত পয়েন্ট, জিম বি! আমি সেই দিকটি বিবেচনা করি নি।
সওতা
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.