Төхөөрөмжийн логыг алсын цуглуулагч руу аюулгүйгээр хэрхэн илгээх вэ

Төхөөрөмж лог гаргаж чадна, цуглуулагч интернетийн нөгөө талд суудаг, бүгдийн эхэлж асуудаг асуулт нь аль туннель барих вэ гэдэг. Энэ хүрээ буруу газраас эхэлдэг. Дамжуулалтыг төхөөрөмжийн үүсгэж чадах формат, цуглуулагчийн хүлээн авах баталгаажуулалт, холбоос тасрах үед «хүргэгдсэн» гэдэг нь юу гэсэн үг байх ёстой вэ гэдэг нь тодорхойлно. Тэдгээр гурван хариултыг бичиж аваарай, дамжуулалт ихэвчлэн өөрөө сонгогдоно.

Төхөөрөмжийн гаргаж чадах зүйлээс эхэл

Практикт зөвхөн гурван хэлбэр байдаг. 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 дээр хэлж, үсрэлт бүрт хариуцагч өг.