آلے کے لاگز کو دور دراز جمع کنندہ تک محفوظ طریقے سے کیسے بھیجیں

آلہ لاگز خارج کر سکتا ہے، جمع کنندہ انٹرنیٹ کے دوسری طرف بیٹھا ہے، اور ہر کوئی پہلا سوال یہی پوچھتا ہے کہ کون سی سرنگ بنائی جائے۔ یہ ڈھانچہ غلط جگہ سے شروع ہوتا ہے۔ نقل و حمل کا تعین وہ فارمیٹ کرتا ہے جو آلہ بنا سکتا ہے، وہ تصدیق جسے جمع کنندہ قبول کرے گا، اور یہ کہ رابطہ ٹوٹنے پر ”پہنچا دیا“ کا کیا مطلب ہونا چاہیے۔ وہ تین جوابات لکھ لیں، اور نقل و حمل عموماً خود کو منتخب کر لیتی ہے۔

آلہ جو خارج کر سکتا ہے وہیں سے شروع کریں

عملاً صرف تین شکلیں ہیں۔ 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 میں یہ کہیں اور ہر قدم کو ایک مالک دیں۔