څنګه د وسیلې لاګونه په خوندي ډول لیرې راټولونکي ته واستوو

وسیله کولی شي لاګونه صادر کړي، راټولونکی د انټرنېټ بل لوري ته ناست دی، او لومړنی پوښتنه چې هرڅوک یې کوي دا ده چې کوم تونل جوړ کړو۔ دا چوکاټ له غلط ځایه پیلېږي۔ لېږد هغه بڼه ټاکي چې وسیله یې تولیدولی شي، هغه تصدیق چې راټولونکی به یې ومني، او هغه څه چې «تحویل شو» باید معنا ولري کله چې اړیکه پرې شي۔ هغه درې ځوابونه ولیکئ، او لېږد معمولاً پخپله خپل ځان غوره کوي۔

له هغه څه پیل وکړئ چې وسیله یې صادرولی شي

په عمل کې یوازې درې بڼې شته۔ د 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 کې یې ووایاست او هر ګام ته یو مسوول ورکړئ۔