Түзмөктүн журналдарын алыскы жыйноочуга коопсуз жөнөтүү жолу

Түзмөк журналдарды чыгара алат, жыйноочу интернеттин экинчи тарабында отурат, жана баары биринчи сураган суроо — кайсы туннелди куруу керек. Бул алкак туура эмес жерден башталат. Транспортту түзмөк чыгара алган формат, жыйноочу кабыл ала турган аутентификация жана байланыш үзүлгөндө «жеткирилди» эмнени билдириши керектиги аныктайт. Ушул үч жоопту жазып коюңуз, жана транспорт адатта өзү тандалат.

Түзмөк чыгара алган нерседен баштаңыз

Иш жүзүндө үч форма гана бар. 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-та айтыңыз жана ар бир секирикке жооптуу дайындаңыз.