হ্যাকিং প্রতিরোধ, ফরেনসিক, নিরীক্ষণ এবং পাল্টা ব্যবস্থা


11

সম্প্রতি (তবে এটি একটি পুনরাবৃত্ত প্রশ্ন) আমরা হ্যাকিং এবং সুরক্ষা সম্পর্কে 3 টি আকর্ষণীয় থ্রেড দেখেছি:

আমি কীভাবে আপোষযুক্ত সার্ভারটি ব্যবহার করব?
কীভাবে একটি হ্যাক করা সার্ভার হ্যাক হয়েছিল তা
ফাইল অনুমতি সম্পর্কিত প্রশ্ন

শেষটি সরাসরি সম্পর্কিত নয়, তবে এটি ওয়েব সার্ভার প্রশাসনের সাথে গণ্ডগোল করা কতটা সহজ তা হাইলাইট করে।

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

এটি কেবল সার্ভার এবং কোড সুরক্ষার বিষয় নয় অডিটিং, লগিং এবং পাল্টা পদক্ষেপগুলিরও।

আপনার কি কোনও ভাল অনুশীলনের তালিকা রয়েছে বা আপনি কি সফ্টওয়্যার বা বিশেষজ্ঞদের উপর নির্ভর করতে পছন্দ করেন যা আপনার ওয়েব সার্ভার (গুলি) বা অবিচ্ছিন্ন কিছু অবিরত বিশ্লেষণ করে?

যদি হ্যাঁ, আপনি কি আপনার তালিকা এবং আপনার ধারণা / মতামত ভাগ করতে পারেন?

হালনাগাদ

আমি বেশ কয়েকটি ভাল এবং আকর্ষণীয় প্রতিক্রিয়া পেয়েছি।

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

এমনকি যদি সবাই ভাল এবং সঠিক উত্তর দেয় তবে এই মুহূর্তে আমি রবার্টের একজনকে সবচেয়ে বেশি পছন্দ করি কারণ এটি সবচেয়ে সাধারণ, পরিষ্কার এবং সংক্ষিপ্ত এবং সিসাদমিন ১১৩৩ এর মধ্যে একটি এটি সবচেয়ে সম্পূর্ণ এবং নির্ভুল।

তবে কেউ ব্যবহারকারীর দৃষ্টিভঙ্গি এবং উপলব্ধি বিবেচনা করে না, আমি মনে করি এটিই প্রথম বিবেচনা করা উচিত।

ব্যবহারকারীরা যখন আমার হ্যাক করা সাইটটি পরিদর্শন করবে তখন কী ভাববে, যদি সেগুলি সম্পর্কে আপনার বুদ্ধিমান ডেটা থাকে more ডেটা কোথায় স্টক করবেন তা কেবল নয়, তবে ক্ষুব্ধ ব্যবহারকারীদের কীভাবে শান্ত করবেন calm

ডেটা, মিডিয়া, কর্তৃপক্ষ এবং প্রতিযোগীদের কী হবে?


3
দিয়ে শুরু করুন security.stackexchange.com । যদিও এখানে ইতিমধ্যে কিছু ভাল উত্তর রয়েছে ....
অ্যাভিডি

ভাল যুক্তি! আমি জানতাম না সেখানে একটি আছে, আমি ভেবেছিলাম প্রতিটি তালিকা স্ট্যাকের ওয়েবসাইটের পুরো পাতায় রয়েছে list
tmow

আমার মনে হয় বিটা সাইটগুলি পূর্ণাঙ্গ সাইটগুলিতে প্রদর্শিত হবে না। এবং, পূর্ণাঙ্গ সাইটগুলি বিটা
পাদচরণগুলিতে নেই

উত্তর:


11

ফোকাস করার জন্য দুটি বড় ক্ষেত্র রয়েছে:

  1. এটি প্রবেশ করা কঠিন করে তোলে।
  2. কেউ অতীত পয়েন্ট 1 এ আসার ঘটনাটি শান্তভাবে এবং দক্ষতার সাথে পরিচালনা করার জন্য নীতি ও পদ্ধতি তৈরি করা।

এটি প্রবেশ করা কঠিন করে তোলে

এটি একটি খুব জটিল বিষয় এবং এটির অনেকাংশে সত্যতার পরে ডাব্লুটিএফ ঘটেছিল তা খুঁজে পাওয়ার জন্য আপনার কাছে পর্যাপ্ত তথ্য রয়েছে তা নিশ্চিত করার দিকে মনোনিবেশ করে। বিমূর্ত বুলেট সরলতার জন্য:

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

কেউ gettingুকে পড়ার ঘটনাটি শান্তভাবে এবং দক্ষতার সাথে পরিচালনা করার জন্য নীতি ও পদ্ধতি তৈরি করা

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

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

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

যে কোনও ঘটনার প্রতিক্রিয়া পরিকল্পনার কিছু উপাদান:

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

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

আমি আরও লক্ষ করি যে এই ধরণের ঘটনাগুলি সামগ্রিক দুর্যোগ প্রতিক্রিয়া পরিকল্পনায় সন্ধান করা দরকার। একটি আপস খুব সম্ভবত 'হারানো হার্ডওয়্যার' প্রতিক্রিয়া নীতি ট্রিগার করতে এবং 'ডেটা হ্রাস' প্রতিক্রিয়া ট্রিগার করতে পারে likely আপনার পরিষেবা পুনরুদ্ধারের সময়গুলি জানার পরে পরিষেবা পুনরুদ্ধারের প্রয়োজনীয়তার আগে প্রকৃত আপোস করা সিস্টেমটি (আইনগত প্রমাণ না রাখলে) overালার জন্য সুরক্ষা প্রতিক্রিয়া দল কতক্ষণ অপেক্ষা করতে পারে তার প্রত্যাশা সেট করতে সহায়তা করে।


আমি আপনার উত্তরটি বেছে নিয়েছি কারণ এটি সর্বাধিক সম্পূর্ণ, এবং এটি হ'ল সংস্থাগুলি, আমরা যেমন কাজ করি তার মতো তারা ব্যবহার করে এবং ধারাবাহিকভাবে উন্নতি করে, তবে আমি অবাক হই যে কীভাবে সাধারণ ওয়েবমাস্টারদেরও সহজতর করা যায়, যেমন সমাধান সমাধান করতে হবে, বিপুল পরিমাণ অর্থ ব্যতীত আরও অনেক কিছু।
4:11

আপনার এবং রবার্ট উত্তরের মধ্যে এখনও নিশ্চিত নন।
tmow

এটি একটি দুর্দান্ত উত্তর, আশা করি আমি কেবল +1 এর পরিবর্তে +2 করতে পারতাম
রব মোয়ার

7

সঠিক হেল্পডেস্ক পদ্ধতিগুলি কীভাবে সহায়তা করতে পারে

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

প্রথমত, যোগাযোগ গুরুত্বপূর্ণ ; ব্যবহারকারীরা ব্যবসায়ের ব্যাহত সম্পর্কে ক্ষুব্ধ হবেন এবং কোনও অনুপ্রবেশের অংশ হিসাবে সংঘটিত হতে পারে এমন কোনও তথ্য লঙ্ঘনের পরিমাণ / পরিণতি সম্পর্কেও উদ্বিগ্ন হতে পারেন। এই লোকদের অবহিত করা তাদের ক্রোধ এবং উদ্বেগ পরিচালনা করতে সহায়তা করবে, উভয় দিক থেকে যে জ্ঞান ভাগ করে নেওয়া ভাল, এবং সম্ভবত কিছুটা কম স্পষ্ট দৃষ্টিভঙ্গি থেকে যে তাদের একটি কথা শুনতে হবে এটি হ'ল আপনি নিয়ন্ত্রণ করছেন পরিস্থিতি.

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

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

স্থাপনার মানগুলি কীভাবে সহায়তা করতে পারে

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

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

এটি বিভিন্ন উপায়ে সহায়তা করে:

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

1
+1 টি। হ্যাঁ, এটি সঠিক, তবে তারপরে, যদি সমস্ত কিছু ঘটে থাকে তবে এর অর্থ হ'ল আপনার টেম্পলেটটি আপনি যা ভাবেন ঠিক ততটা নিরাপদ নয়, সুতরাং আপনি এটি কোনও নতুন ওয়েবসাইট স্থাপন করতে ব্যবহার করতে পারবেন না। আপনার কোনও অস্থায়ী সমস্যা সম্পর্কে গ্রাহকদের অবহিত করার জন্য কমপক্ষে একটি রক্ষণাবেক্ষণ পৃষ্ঠা প্রয়োজন এবং এটি অন্য কোথাও হোস্ট করার জন্য আরও ভাল (অন্য কোনও সার্ভার, অন্য আইপি, এবং পুরানো থেকে পুনর্নির্দেশ)। আমি মনে করি আমাদের সর্বদা সবচেয়ে খারাপ পরিস্থিতি বিবেচনা করা উচিত।
tmow

2
@ টমো - আপনি ঠিক বলেছেন তবে টেমপ্লেট আপনাকে একটি সিস্টেম আপনার "পরিচিত" কনফিগারেশনে দ্রুত পুনরুদ্ধার করতে দেয়, যা আপনাকে আবার সার্ভার স্থাপনের আগে সংশোধন করতে হবে। আমি প্রতিবিম্বিত করতে উত্তরটি সংশোধন করব কারণ এটির উল্লেখ করা উচিত ছিল, আপনি একেবারে ঠিক সেখানে।
রব মোয়ার

1
ধন্যবাদ। ব্যবহারকারীর দৃষ্টিভঙ্গি এবং উপলব্ধি ভুলবেন না।
tmow

@tmow ব্যবহারকারীদের সম্পর্কে কিছুটা যুক্ত করেছে এবং সেগুলি শেষ করতে সহায়তা করার জন্য সহায়তা ডেস্ক রাখে।
রব মোয়ার

4

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


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

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

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

4

আপনি যা চান তা 3 টি প্রাথমিক অঞ্চলে পড়তে পারে:

  1. স্ট্যান্ডার্ড সিস্টেম কনফিগারেশন
  2. সিস্টেম / অ্যাপ্লিকেশন পর্যবেক্ষণ
  3. ঘটনার প্রতিক্রিয়া

আপনার যদি কোনও তথ্য (আশ্বাস | সুরক্ষা) কর্মী উপলব্ধ থাকে তবে অবশ্যই তাদের সাথে কথা বলা উচিত। যদিও ঘটনামূলক প্রতিক্রিয়া প্রায়শই উক্ত অফিসের একমাত্র পরিধি, বাকিগুলি সমস্ত ক্ষতিগ্রস্থ পক্ষ জুড়ে একটি যৌথ বিকাশের প্রচেষ্টা হওয়া উচিত।

স্ব-পাম্পিংয়ের ঝুঁকিতে, সম্পর্কিত প্রশ্নের এই উত্তরটি আপনার জন্য প্রচুর দরকারী সংস্থান সূচীকরণ করতে পারে: একটি এলএএমপি সার্ভার সুরক্ষিত করার টিপস।

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

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

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


আমি প্রায় সবকিছুর সাথে একমত হই তবে এটি মূলত মাঝারি এবং বড় সংস্থাগুলির ক্ষেত্রে প্রযোজ্য। ছোট আকারের সংস্থাগুলির এ জাতীয় ব্যয়বহুল কাঠামো প্রয়োজন হবে না বা চাইবে না।
tmow


2

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


2

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

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide

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