উইন্ডোজ সার্ভারে 4625 ইভেন্ট আইডির উত্স কীভাবে পাবেন


8

আমার ইভেন্ট লগতে ইভেন্ট আইডি 4625 এবং লগন টাইপ 3 সহ আমার অনেক নিরীক্ষণ ব্যর্থতা রয়েছে।

এই সমস্যাটি কি আমার সার্ভার (অভ্যন্তরীণ পরিষেবা বা অ্যাপ্লিকেশন) গঠন করে? নাকি এই হিংস্র বাহিনীর আক্রমণ? অবশেষে আমি কীভাবে এই লগইনগুলির উত্স খুঁজে পেতে এবং সমস্যার সমাধান করতে পারি?

এটি সাধারণ ট্যাবে বিশদ তথ্য:

An account failed to log on.

Subject:
    Security ID:        NULL SID
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0

Logon Type:         3

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:       aaman
    Account Domain:     

Failure Information:
    Failure Reason:     Unknown user name or bad password.
    Status:         0xC000006D
    Sub Status:     0xC0000064

Process Information:
    Caller Process ID:  0x0
    Caller Process Name:    -

Network Information:
    Workstation Name:   test2
    Source Network Address: -
    Source Port:        -

Detailed Authentication Information:
    Logon Process:      NtLmSsp 
    Authentication Package: NTLM
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

**And this is detailed information in Detail Tab:**

+ System 

  - Provider 

   [ Name]  Microsoft-Windows-Security-Auditing 
   [ Guid]  {54849625-5478-4994-A5BA-3E3B0328C30D} 

   EventID 4625 

   Version 0 

   Level 0 

   Task 12544 

   Opcode 0 

   Keywords 0x8010000000000000 

  - TimeCreated 

   [ SystemTime]  2015-05-09T06:57:00.043746400Z 

   EventRecordID 2366430 

   Correlation 

  - Execution 

   [ ProcessID]  696 
   [ ThreadID]  716 

   Channel Security 

   Computer WIN-24E2M40BR7H 

   Security 


- EventData 

  SubjectUserSid S-1-0-0 
  SubjectUserName - 
  SubjectDomainName - 
  SubjectLogonId 0x0 
  TargetUserSid S-1-0-0 
  TargetUserName aaman 
  TargetDomainName  
  Status 0xc000006d 
  FailureReason %%2313 
  SubStatus 0xc0000064 
  LogonType 3 
  LogonProcessName NtLmSsp  
  AuthenticationPackageName NTLM 
  WorkstationName test2 
  TransmittedServices - 
  LmPackageName - 
  KeyLength 0 
  ProcessId 0x0 
  ProcessName - 
  IpAddress - 
  IpPort - 

উত্তর:


3

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

আমি নিশ্চিত যে এটি নেটওয়ার্ক স্তরের প্রমাণীকরণ ছাড়াই ইন্টারনেটের মাধ্যমে আরডিপি সংযোগ থেকে আসছিল।


আমি তুমি থাকলে আমি এত শান্ত থাকতাম না। এই হ্যাক প্রচেষ্টা।
ইন্টারফেস অজানা

3

কাজের সমাধানটি আমি এখানে পেয়েছি: https://github.com / ডিজিটালরুবি / আইপিবান

উইন্ডোজ সার্ভার ২০০৮ বা সমমানের জন্য আপনার এনটিএলএম লগইন অক্ষম করা উচিত এবং কেবল এনটিএলএম 2 লগইনকে অনুমতি দেওয়া উচিত। উইন্ডোজ সার্ভার ২০০৮ এ, এনটিএলএম লগইনগুলির আইপি ঠিকানা পাওয়ার কোনও উপায় নেই। সেকপল -> স্থানীয় নীতিগুলি -> সুরক্ষা বিকল্পগুলি -> নেটওয়ার্ক সুরক্ষা এনটিএলএম আগত এনটিএলএম ট্র্যাফিককে সীমাবদ্ধ করে -> সমস্ত অ্যাকাউন্ট অস্বীকার করে।

আরইউ সংস্করণে: Локальная политика безопасности -> еые политики -> Параметры безопасности -> Сетевая безопасность: T এনটিএলএম: входящий трафик এনটিএলএম -> Запретить все учетные записи


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

1

এগুলি হ্যাক আক্রমণ। আক্রমণকারীদের লক্ষ্য আপনার সার্ভারের অ্যাকাউন্টগুলি / পাসওয়ার্ডগুলিকে জোর করে চাপিয়ে দেওয়া।

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

ধারণাটি সহজ: আইডিএস সন্দেহজনক লগন ব্যর্থতার ইভেন্টগুলির জন্য আপনার সার্ভারের সুরক্ষা লগটি পর্যবেক্ষণ করে। তারপরে এটি আইপি অ্যাড্রেসটি লক করে (এস), চেষ্টাটি এসেছে। নরম-লক করা আইপি থেকে প্রচেষ্টা অব্যাহত থাকলে আপনি একটি হার্ড লকটিও কনফিগার করতে পারেন।


0

যখন এমনটি ঘটেছিল তখন কি কোনও ডোমেন কন্ট্রোলার বন্ধ হয়ে যায়? এটি এই নিবন্ধে বর্ণিত দৃশ্যের সাথে উল্লেখযোগ্যভাবে অনুরূপ দেখাচ্ছে:

https://support.microsoft.com/en-us/kb/2683606

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

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


0

এই ইভেন্টটি সাধারণত একটি বাসি লুকানো শংসাপত্রের কারণে ঘটে। ত্রুটি প্রদান করে সিস্টেম থেকে এটি ব্যবহার করে দেখুন:

কমান্ড প্রম্পট রান psexec -i -s -d cmd.exe
থেকে : নতুন সিএমডি উইন্ডো রান থেকে: rundll32 keymgr.dll,KRShowKeyMgr

সঞ্চিত ব্যবহারকারীর নাম এবং পাসওয়ার্ডের তালিকায় উপস্থিত যে কোনও আইটেম সরান। কম্পিউটার পুনরায় চালু করুন।


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