কীভাবে যন্ত্রের লগ দূরবর্তী সংগ্রাহকে নিরাপদে পাঠাবেন

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

যন্ত্রটি যা নির্গত করতে পারে তা দিয়ে শুরু করুন

বাস্তবে কেবল তিনটি রূপ আছে। UDP বা TCP-এর উপর পৃথক syslog ঘটনা, পণ্যের ভেতরে তৈরি প্রমাণীকৃত HTTPS আপলোড, অথবা ডিস্কে লেখা সম্পূর্ণ ফাইল যা সরাতে হবে। যে ফায়ারওয়াল কেবল UDP syslog পাঠাতে পারে সে টানেল যোগ করার কারণে TLS পাঠক হয়ে উঠবে না; সে এখনও অ-স্বীকৃত ডেটাগ্রাম পাঠাবে, এখন এনক্রিপ্টেড খামের ভেতরে।

তাই প্রথমে প্রেরকটির তালিকা করুন: প্রোটোকল, TLS সমর্থন ও কোন TLS লাইব্রেরি, এটি সংগ্রাহকের সার্টিফিকেট যাচাই করতে পারে কি না, ক্লায়েন্ট সার্টিফিকেট উপস্থাপন করতে পারে কি না, এবং প্রেরণের বাফার রিবুটে টিকে থাকে কি না। যন্ত্রটি যা করতে পারে না তা পথের অন্য কিছুকে করতে হবে, আর সেই অন্য কিছুটি আপনার নকশার অংশ হয়ে যায়।

TLS syslog: দুই প্রান্তই যখন এটি বলে তখন সবচেয়ে ছোট পথ

যদি যন্ত্রটি TLS-এর উপর syslog সমর্থন করে এবং সংগ্রাহক তা সমাপ্ত করে, তবে সেটিই ব্যবহার করুন এবং থামুন। অ্যাপ্লিকেশন প্রোটোকল নিজেকে রক্ষা করে, সংগ্রাহক প্রেরককে প্রমাণীকৃত করে, এবং এমন কোনো অতিরিক্ত ধাপ নেই যার প্রাপ্যতা এখন আপনার। ফাঁদটি হলো “TLS syslog” বিস্তৃত বাস্তবায়নকে অন্তর্ভুক্ত করে, এবং বর্তমান নিরাপদ syslog নির্দেশনা পুরোনো টিউটোরিয়ালের সাইফার তালিকা ছাড়িয়ে গেছে, আর এভাবেই একটি কাজ করা ফরোয়ার্ডার লাইব্রেরি আপগ্রেডের পরে ভাঙা হয়ে যায়।

rsyslog-এ পরিবহন মডিউলের নামই বলে দেয় আপনি কোন যুগে আছেন: lmnsd_gtls GnuTLS মোড়ে, আর lmnsd_ossl OpenSSL মোড়ে এবং বর্তমান 8.x প্যাকেজগুলো এটিই দেয়। সার্টিফিকেট যাচাইসহ একটি ফরোয়ার্ড অ্যাকশন মোটামুটি এমন দেখায়, এবং সঠিক প্যারামিটারের নাম আপনার ইনস্টল করা সংস্করণের সঙ্গে মিলিয়ে দেখা উচিত:

action(type="omfwd" target="collector.example" port="6514" protocol="tcp"
       StreamDriver.Name="ossl" StreamDriver.Mode="1" StreamDriver.AuthMode="x509/name"
       StreamDriver.CAFile="/etc/pki/ca.pem"
       queue.type="LinkedList" queue.filename="fwdq" queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on" action.resumeRetryCount="-1")

প্রেরকটি ঠিক করার আগে প্রান্তবিন্দু যাচাই করুন। openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error হয় বৈধ শৃঙ্খলসহ হ্যান্ডশেক সম্পন্ন করে, নয়তো ঠিক কোন যাচাই ব্যর্থ হয়েছে তা বলে দেয়। যন্ত্রটি থেকেই পরীক্ষা করুন, ল্যাপটপ থেকে নয়, কারণ যন্ত্রের ট্রাস্ট স্টোরই গুরুত্বপূর্ণ।

SFTP: ফাইলের জন্য ভালো, প্রবাহের জন্য ভুল

ফাইলভিত্তিক ডেলিভারি এমন যন্ত্রের জন্য উপযুক্ত যা ঘোরানো লগ লেখে আর কিছু নয়। SSH-ভিত্তিক স্থানান্তর আপনাকে হোস্ট কী, প্রতি-অ্যাকাউন্ট কী এবং একটি ফাইলসিস্টেম দেয় যা আপনি অডিট করতে পারেন, যা TLS একেবারেই করতে না পারা যন্ত্রের জন্য যুক্তিসঙ্গত বিশ্বাসের কাহিনি। ঘটনা-প্রবাহের জন্য এটি দুর্বল পছন্দ, যেখানে “ফাইলটি প্রতি ঘণ্টায় লেখা হয়” মানে একটি বিভ্রাট আপনার চলতি ঘণ্টার লেজ কেড়ে নেয়।

হোস্ট যাচাই চালু রাখুন। প্রম্পট এড়াতে এটি বন্ধ করা একটি ব্যাচ আহ্বান পরিবহনের একমাত্র প্রমাণীকরণকেই নষ্ট করে:

sftp -b /etc/logship/batch -o BatchMode=yes -o StrictHostKeyChecking=yes      -o IdentitiesOnly=yes -i /etc/logship/id_ed25519 [email protected]

প্রস্তুতির সময় অ্যাকাউন্টের known_hosts-এ হোস্ট কী পিন করুন, অ্যাকাউন্টটিকে লক্ষ্য ডিরেক্টরিতে সীমিত করুন, এবং chroot-সহ internal-sftp সাবসিস্টেম পছন্দ করুন। পুনঃপ্রেরণের কাহিনিও পরিকল্পনা করুন: আংশিক ব্যর্থতার পরে কোনো ফাইল আবার পাঠানো হলে সংগ্রাহককে অবশ্যই নতুন ফাইল থেকে নকল আলাদা করতে হবে, সাধারণত আগমনের সময় দিয়ে নয়, নাম ও চেকসাম দিয়ে।

যখন স্থানীয় গেটওয়ে বা টানেলই সৎ উত্তর

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

রুট করা সাইট বা যন্ত্র টানেল সবচেয়ে ভারী বিকল্প এবং সঠিকটি যখন সংগ্রাহককে একটি ব্যক্তিগত ঠিকানা ধরে রাখতে হয় এবং কেবল লগ নয়, একাধিক সেবা বহন করতে হয়। এটি ঠিকানা পরিকল্পনা, অ্যাক্সেস নিয়ম, প্রত্যাবর্তন পথ এবং টানেল প্রান্তবিন্দুর জীবনচক্র নিয়ে আসে। এটি ভেতরের প্রোটোকলও উন্নত করে না: IPsec টানেলের ভেতরে UDP syslog এখনও ডেলিভারি স্বীকৃতি ছাড়া ডেটাগ্রাম সেবা।

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

পাঠানোর আগে ডেলিভারি চুক্তি লিখুন

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

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

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