( YleGreg | 2020. 02. 17., h – 12:19 )

Ezt én is így gondolom, hogy több részre szedem a történetet.

Az első az architektúra, hogy milyen gépből (zabbix-proxy, zabbix-server) hány darabot és hova teszek, valamint mi lesz az adatcserék útja.

A második a mit mérünk, vagyis hogy a végén mi jelenjen meg a szerver gépen amikor megtámadom a böngészővel, valamint, hogy milyen küszöbértékek legyenek a riasztásoknál.

A harmadik pedig, hogy a második pont adatait milyen módszerrel szerzem meg, agent, SNMP, script kimenet, stb.

 

A harmadik ponttal kapcsolatban csak elképzeléseim vannak, nagyon nem görcsölök rajta, mert tudom, hogy kivitelezhető, ennyi jelenleg elég. Majd ha odaérek, akkor megírom a scriptet, vagy beállítom az agentet.

A második pontnál kicsiben kezdünk, egészen konkrétan annyi fog érdekelni egy gépről, (IP címről), hogy UP vagy DOWN, és majd innen megyünk tovább.

(Kis kitérő: A jelenlegi monitor rendszer is így fejlődött, hogy bekonfiguráltuk azt ami józan számítás szerint gondot okozhat (DISK, MEM, CPU megfutás illetve elfogyás, meg néhány service figyelés (syslog-ng, ntpd, sshd, stb.) és örültünk. Amikor aztán jött valami gebasz, akkor utána elmerengtünk rajta, hogy ezt hogy lehetett volna kivédeni, és utána megírtam például a file változás figyelő (spanyolviasz díjas) alkalmazásomat (pár sor bash kód, haha) ami kiabálni kezd, ha valami paraszt belemódosít például az sshd_config -ba. Így legközelebb felkészülve érkezünk. Most is hasonlót tervezek, nem akarom én felrakni az összes létező szenzort és applikációs siránkozást figyelő plugint, mert minek. Ahogy mondtad, a zajban elvész a tényleg fontos kiabálás. A Zabbix felületén azt akarom látni, amibe hajlamos belehalni a gép. A többit gereblyézze az, akinek van rá ideje. )

 

Most az első ponton rugózok, keresem a legkevesebb munkával előállítható legjobb topológiát, hogy lehetőleg ne kelljen semmit újracsinálnom. Nem szeretnék zsákutcába jutni.