Cara mengirim log perangkat ke kolektor jarak jauh dengan aman

Perangkat dapat memancarkan log, kolektor berada di sisi lain internet, dan pertanyaan pertama yang semua orang ajukan adalah terowongan mana yang harus dibangun. Kerangka itu mulai dari tempat yang salah. Yang menentukan transportasi adalah format yang dapat dihasilkan perangkat, autentikasi yang akan diterima kolektor, dan arti “terkirim” ketika tautan putus. Tuliskan ketiga jawaban itu, dan transportasi biasanya memilih dirinya sendiri.

Mulailah dari yang bisa dipancarkan perangkat

Dalam praktik hanya ada tiga bentuk. Peristiwa syslog individual melalui UDP atau TCP, unggahan HTTPS terautentikasi yang tertanam di produk, atau berkas lengkap yang ditulis ke disk dan harus dipindahkan. Firewall yang hanya dapat mengirim syslog UDP tidak akan menjadi pengirim TLS karena Anda menambahkan terowongan; ia tetap mengirim datagram tanpa konfirmasi, kini di dalam amplop terenkripsi.

Jadi inventarisasikan dulu pengirim: protokol, dukungan TLS dan pustaka TLS mana, apakah dapat memvalidasi sertifikat kolektor, apakah dapat menyajikan sertifikat klien, dan apakah buffer kirim bertahan dari reboot. Apa pun yang tidak dapat dilakukan perangkat harus dilakukan sesuatu lain di jalur, dan sesuatu lain itu menjadi bagian dari desain Anda.

TLS syslog: jalur terpendek ketika kedua ujung berbicara

Jika perangkat mendukung syslog melalui TLS dan kolektor menutupnya, gunakan itu dan berhenti. Protokol aplikasi melindungi dirinya sendiri, kolektor mengautentikasi pengirim, dan tidak ada lompatan tambahan yang ketersediaannya kini Anda miliki. Jebakannya adalah “TLS syslog” mencakup beragam implementasi, dan pedoman syslog aman saat ini telah bergerak melampaui daftar sandi di tutorial lama, dan itulah sebabnya penerus yang berfungsi menjadi rusak setelah peningkatan pustaka.

Di rsyslog, nama modul transportasi saja sudah menunjukkan era Anda: lmnsd_gtls membungkus GnuTLS, sedangkan lmnsd_ossl membungkus OpenSSL dan itulah yang dikirim paket 8.x saat ini. Aksi penerusan dengan validasi sertifikat kira-kira terlihat seperti ini, dan nama parameter yang tepat perlu diperiksa terhadap versi terpasang Anda:

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")

Verifikasi titik akhir sebelum men-debug pengirim. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error entah menyelesaikan jabat tangan dengan rantai valid atau memberi tahu persis pemeriksaan mana yang gagal. Uji dari perangkat, bukan dari laptop Anda, karena penyimpanan kepercayaan perangkatlah yang penting.

SFTP: baik untuk berkas, salah untuk aliran

Pengiriman berbasis berkas cocok untuk perangkat yang menulis log berotasi dan tidak melakukan hal lain. Transfer berbasis SSH memberi Anda kunci host, kunci per akun, dan sistem berkas yang dapat diaudit, yang merupakan kisah kepercayaan wajar bagi perangkat yang sama sekali tidak bisa TLS. Ini pilihan buruk untuk aliran peristiwa, di mana “berkas ditulis setiap jam” berarti gangguan membuat Anda kehilangan ekor jam berjalan.

Biarkan verifikasi host menyala. Pemanggilan batch yang mematikannya untuk menghindari prompt meruntuhkan satu-satunya autentikasi yang dimiliki transportasi:

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

Sematkan kunci host di known_hosts akun selama penyediaan, batasi akun ke direktori tujuan, dan utamakan subsistem internal-sftp dengan chroot. Rencanakan juga kisah pengiriman ulang: jika berkas dikirim ulang setelah kegagalan sebagian, kolektor harus membedakan duplikat dari berkas baru, biasanya berdasarkan nama plus checksum, bukan waktu kedatangan.

Ketika gateway lokal atau terowongan adalah jawaban jujur

Sebagian perangkat hanya dapat berbicara format yang tidak ingin diekspos siapa pun. Dalam hal itu, kolektor berwenang di jaringan perangkat sendiri menerima format asli dan meneruskannya melalui TLS. Itu desain yang sah, tetapi tepatlah tentang apa yang dibelinya: enkripsi yang dimulai di gateway tidak melindungi segmen antara perangkat dan gateway secara surut, jadi lompatan itu tetap memerlukan batas kepercayaan dan kontrol aksesnya sendiri.

Terowongan situs atau perangkat terrutekan adalah opsi terberat dan yang tepat ketika kolektor harus mempertahankan alamat pribadi dan membawa beberapa layanan, bukan hanya log. Ia membawa perencanaan alamat, aturan akses, jalur balik, dan siklus hidup titik akhir terowongan. Ia juga tidak memperbaiki protokol dalam: syslog UDP di dalam terowongan IPsec tetap layanan datagram tanpa pengakuan pengiriman.

Apa pun yang Anda pilih, jaga otorisasi kolektor lebih sempit daripada transportasi. Identitas terowongan milik suatu titik akhir, dan tidak mengatakan apa pun tentang perangkat hilir mana yang menghasilkan bidang nama host tertentu dalam pesan.

Tuliskan kontrak pengiriman sebelum Anda mengirim

Enkripsi, autentikasi, dan retensi menjawab pertanyaan berbeda, dan antrean bukan kebijakan retensi. Sebelum log pertama meninggalkan perangkat, putuskan apa arti pengakuan sebenarnya pada kolektor ini: diterima di kabel, diterima untuk diproses, atau ditulis secara tahan lama ke penyimpanan. Itu tiga jaminan berbeda dan hanya yang terakhir bertahan dari restart kolektor.

Lalu jawab pertanyaan operasional secara tertulis. Di mana peristiwa yang belum terkirim menunggu, dan apakah buffer itu bertahan dari pemadaman listrik? Apa yang terjadi saat penuh, dan siapa yang diberi tahu? Bagaimana percobaan ulang dibatasi, dan bagaimana duplikat diidentifikasi? Bidang mana yang membuktikan identitas pengirim, mengingat lompatan penerusan dapat menulis ulang nama host?

Jaga desain cukup kecil untuk dijelaskan dalam satu paragraf: transportasi terkecil yang didukung yang membawa peristiwa yang diperlukan, ditambah pernyataan eksplisit tentang jaminan yang tidak diberikannya. Jika jawabannya membutuhkan dua lompatan, katakan itu di runbook dan beri setiap lompatan seorang pemilik.