Fórum Root.cz
Hlavní témata => Server => Téma založeno: Pavko 19. 12. 2017, 23:53:54
-
Dobrý den, mám v plánu napsat vlastní utility na statistiku linuxových serverů - chtěl bych na serverech automatizovaně získávat informace typu obsazení místa na discích, monitoring SMART, obsazení paměti, apod. Tyto získané údaje bych chtěl sbírat do jedné centrální databáze na dedikovaném stroji. Řeším problém, jak předávat data mezi serverem sbírajícím data a jednotlivými servery - ssh bez hesla se mi moc používat nechce, sshpass z důvodu bezpečnosti také ne. Doporučili byste mi nějaké relativně bezpečné řešení, ideálně s minimalizací zásahů při změnách skriptů na jednotlivých serverech? Vše by mělo běžet automatizovaně, pro jednotlivé distribuce bych si skripty vychytal. Děkuji, Pavko.
-
SSH s klicem.
-
SSH má určitou režii při navazování spojení, ale jinak je to dobrá volba. Jak často se budou data předávat? Jak často by se to muselo připojovat?
Jinak akorát uděláš na všech strojích neprivilegovaného uživatele, který může jen posbírat naměřené hodnoty, nebo je naopak někam zapsat, podle toho, jakým směrem to chceš posílat, a přidáš mu SSH klíče druhé strany do .ssh/authorized_keys. A tyhle klíče budou bez hesla.
-
ssh multiplexing řeší režii navazovaného spojení.
Každopádně nevím proč tazatel vymýšlí kolo, zabbix, icinga, netdata, nagios a spousty dalších řešení již tohle dělají, podporují šifrovaná přes ssh, push/pull režimy, stačí si vybrat podle potřeb.
-
Do .ssh/authorized_keys se dá umístit příkaz, který se má po přihlášení provést. Tímto způsobem je možné bezpečně použít i rootovský účet.
-
z mnoha stroju bych to posilal na jeden s ssh serverem. na strojich pak staci klient ssh a prihlasovani na centralni stroj klicem,
-
SSH s klíčem, nebo odesílat do webové služby (přes TLS) to je také celkem jednoduché a efektivní.
-
Dobrý den, mám v plánu napsat vlastní utility na statistiku linuxových serverů - chtěl bych na serverech automatizovaně získávat informace typu obsazení místa na discích, monitoring SMART, obsazení paměti, apod. Tyto získané údaje bych chtěl sbírat do jedné centrální databáze na dedikovaném stroji. Řeším problém, jak předávat data mezi serverem sbírajícím data a jednotlivými servery - ssh bez hesla se mi moc používat nechce, sshpass z důvodu bezpečnosti také ne. Doporučili byste mi nějaké relativně bezpečné řešení, ideálně s minimalizací zásahů při změnách skriptů na jednotlivých serverech? Vše by mělo běžet automatizovaně, pro jednotlivé distribuce bych si skripty vychytal. Děkuji, Pavko.
Na tento účel se nejvíc hodí SNMPv3, je to standard pro předávání těchto informací a je i šifrovaný. Podle mě není potřeba znovu vynalézat kolo, když je technologie funkční a hotová.
-
1. dělat něco, co je hotové je minimálně ztráta času, obvykle dost velká chyba
2. myslím že je lepší model data sbírat na každém serveru a odesílat pryč, než z jednoho místa data periodicky číst - takové řešení je obvykle lehké, spolehlivé a bezpečné ( neotevíráte na serveru další port s potencionálně nebezpečnou službou ). Osobně mám pro tento způsob sběru dat dlouhodobé zkušenosti s collectd ( super nástroj, jen jsem v některých starších verzích narážel na memoryleak, ale to už je snad definitivně minulost ) nebo telegraf ( relativně mladá věc, sbírá data velmi rychle, napsané v go )
3. pokud byste chtěl přeci jen model pull a nikoliv push, tak zvažte zda to nespojit s nějakým monitorovacím nástrojem - pokud mít na serveru nějakého agenta na tyhle věci, tak ať je jeden.
-
Pokuď vím, tak NRPE pro Nagios podporuje SSL a blokaci podle IP, podle mě v interní síti dostatečně bezpečné.
Jinak já jsem přítelem monitorovat jen to, co opravdu budu řešit. Tj. pokud servery běžně běží na 100% občas a je to standard, tak si nenastavím monitoring CPU a alerty, které mi budou chodit 10x denně.
Ve většině firem kde jsem dělal, tak admini vždy chtěli monitorovat každé prdnutí (já byl vždy proti), a když to konečně nastavili, tak ráno přišli do práce, z telefonu vymazali 100SMS s alertama a šli si dát kafe, pozor takovýto monitoring je na dvě věci.
-
Spravil by som to tak, že sa dáta POST-om odošlú cez HTTPS, z nodu, ktorý dáta nazbieral. V prípade nedostupnosti centrálneho servera by som dávku uložil lokálne a pri najbližšom posielaní ju pripojil k novej dávke. Ak je potrebné vylúčiť podvrhnutie dát, pre HTTPS existujú aj klientské certifikáty.
-
Děkuji za odpovědi. K řešení ssh s klíčem (neprivilegovaný uživatel) - některé příkazy potřebují práva roota. Posbíraná data nechci dávat do Nagiosu, ale historicky i uchovávat, to Nagios umí? SNMPv3 umí spustit libovolný příkaz? Děkuji, Pavko.
-
Děkuji za odpovědi. K řešení ssh s klíčem (neprivilegovaný uživatel) - některé příkazy potřebují práva roota.
Rikal jste, ze ta data chcete jen stahnout, takze jsem cekal, ze vam je pod tim rootem pripravi nejaky skript na vzdalenem serveru a vy to pak stahnete pres nejake scp nebo rsync. BTW, tomu neprivilegovanemu uzivateli muzete nastavit jako shell treba /bin/false, aby vam tam nikdo nelezl, kdyby ukradl klice. Tusim, ze scp by s tim melo chodit, jestli i rsync se uz nepamatuju.
-
Děkuji za odpovědi. K řešení ssh s klíčem (neprivilegovaný uživatel) - některé příkazy potřebují práva roota. Posbíraná data nechci dávat do Nagiosu, ale historicky i uchovávat, to Nagios umí? SNMPv3 umí spustit libovolný příkaz? Děkuji, Pavko.
Ano, snmpd umí spustit příkaz a poslat jeho návrat.
http://net-snmp.sourceforge.net/wiki/index.php/Tut:Extending_snmpd_using_shell_scripts
-
Rikal jste, ze ta data chcete jen stahnout, takze jsem cekal, ze vam je pod tim rootem pripravi nejaky skript na vzdalenem serveru a vy to pak stahnete pres nejake scp nebo rsync. BTW, tomu neprivilegovanemu uzivateli muzete nastavit jako shell treba /bin/false, aby vam tam nikdo nelezl, kdyby ukradl klice. Tusim, ze scp by s tim melo chodit, jestli i rsync se uz nepamatuju.
Pokud /bin/false není v /etc/shells, neproběhne ani scp či rsync. Jako lepší řešení mi přijde rsssh, tedy restricted secure shell, tam se dá pak povolit, že projde např. pouze rsync či scp, ale nic dalšího.
-
K řešení ssh s klíčem (neprivilegovaný uživatel) - některé příkazy potřebují práva roota.
Klíčem se můžete přihlásit i na roota. A jak už pal Franta, ke konkrétnímu klíči můžete nastavit příkaz, který se po přihlášení tím klíčem spustí. Takže můžete nastavit, aby se s příslušným klíčem spustil jenom skript, který posbírá potřebná data, a nic jiného s tím klíčem nepůjde udělat. Bezpečnější by ale bylo dělat to opačně, tj. na počítači posbírat data a pak je odeslat někam ven.
-
Klíčem se můžete přihlásit i na roota.
Jo, pokud chcete mit v SSH povoleno prihlasovani na roota, coz je ponekud v rozporu z predchozimi doporucenimi pouzit neprivilegovaneho uzivatele. Mozna, ze kdyz to beha v LAN, tak by se to dalo skousnout, ale pres Internet bych to nechtel.
-
SW ktery hledate se jmenuje Zabbix.
Sber dat na jednotlivych serverech bud pomoci Zabbix agenta s SSL konektivitou. - ten primo podporuje metriky typu CPU load, diskspace.
Podporuje i discovery mount pointu.
A pokud Zabbix agent je nepruchozi, Zabbix server dovede monitorovat i agentless pres SSH ci SNMPv3, JMX, IPMI.
-
SW ktery hledate se jmenuje Zabbix.
Sber dat na jednotlivych serverech bud pomoci Zabbix agenta s SSL konektivitou. - ten primo podporuje metriky typu CPU load, diskspace.
Podporuje i discovery mount pointu.
A pokud Zabbix agent je nepruchozi, Zabbix server dovede monitorovat i agentless pres SSH ci SNMPv3, JMX, IPMI.
Apropos, osobne doporucuju tuto Zabbix konfiguraci:
- nechat Puppet rozinstalovat Zabbix agenty a jejich custom skripty a nakonfigurovat je, at se hlasi na centralni Zabbix server via SSL
- na Zabbix serveru nakonfigurovat autodiscovery, ktere automaticky zalozi host pro nove prihlaseny Zabbix agent
- na zaklade typu serveru (predpokladam, ze mate urcite skupiny podobnych serveru - zjisteno via Zabbix sever) automaticky aplikovat monitorovaci template
Pak si este nastavit notifikaci na unsupported metriky a hotovo.
Tenhle system bude fungovat plne automaticky
-
Jo, pokud chcete mit v SSH povoleno prihlasovani na roota, coz je ponekud v rozporu z predchozimi doporucenimi pouzit neprivilegovaneho uzivatele.
Ano, vždyť jsem to také psal – lepší je údaje sbírat lokálně (to může dělat root, když je potřeba) a pak je pomocí neprivilegovaného účtu poslat na sběrný server. Tohle byla jen poznámka, že pokud to chce dělat tím svým způsobem, nic nebrání tomu přihlašovat se na roota s klíčem (naopak bych se na roota nepřihlašoval heslem). Navíc je možné s konkrétním klíčem svázat konkrétní příkaz, takže se dá docela dobře zabezpečit, co může vlastník toho klíče dělat (je to takové sudo, které má mnohem méně nečekaných vedlejších efektů).
Mozna, ze kdyz to beha v LAN, tak by se to dalo skousnout, ale pres Internet bych to nechtel.
Na přihlašování pod rootem není nic divného nebo nebezpečného. Nebezpečné je přihlašování slabým heslem, ale na to existuje jednoduchý lék – přihlašování heslem úplně zakázat.
-
Na přihlašování pod rootem není nic divného nebo nebezpečného. Nebezpečné je přihlašování slabým heslem, ale na to existuje jednoduchý lék – přihlašování heslem úplně zakázat.
Jo, za predpokladu, ze v autentikaci SSH neni nejaka dosud neznama chyba. Krome toho neni tak spatne, kdyz se kazdy prihlasi na svuj neprivilegovany ucet a pak da su, aby v logu bylo videt, kdo tam v kterou dobu lezl. Kdyz se neco posere a nekdo pak jede pres pul zemekoule zmacknout tlacitko reset, tak se aspon vi, koho za to nakopat.
-
Krome toho neni tak spatne, kdyz se kazdy prihlasi na svuj neprivilegovany ucet a pak da su, aby v logu bylo videt, kdo tam v kterou dobu lezl.
sshd loguje, který klíč byl použit pro přihlášení.
-
sshd loguje, který klíč byl použit pro přihlášení.
Ano, pokud pouzijete zminene klice a ne uzivatele s heslem. To pak vite starou belu. Navic musite klice dukladne evidovat, abyste vedel, koho servat.
-
Děkuji všem za názory. Líbí se mi možnost přihlašování klíčem s omezením příkazu - nicméně se mi moc nelíbí případná změna skriptu, ale to by asi šlo naskriptovat z centrálního serveru také, ne? SNMPv3 se mi také líbí, ale potřebuji detailnější výstup, nejen hodnoty. Myslím, že by se data sbírala 1x za den, vyzkouším a dám vědět, Pavko.
-
Děkuji všem za názory. Líbí se mi možnost přihlašování klíčem s omezením příkazu - nicméně se mi moc nelíbí případná změna skriptu, ale to by asi šlo naskriptovat z centrálního serveru také, ne? SNMPv3 se mi také líbí, ale potřebuji detailnější výstup, nejen hodnoty. Myslím, že by se data sbírala 1x za den, vyzkouším a dám vědět, Pavko.
OMG, nez zacnes znovuvynalezat kolo, podivej se, co je to Zabbix a Puppet.
Zrovna sber metrik skriptem pres SSH je dira jak prase. Protoze pres to SSH spustis i cokoliv jineho.
Zabbix agent umi to samy, je na sber metrik delany.
A ani neni potreba Zabbix server, Zabbix agent se da doptavat JSON callem a pak to strkat spanembohem do zadele.
-
Jo, za predpokladu, ze v autentikaci SSH neni nejaka dosud neznama chyba.
Což ale platí i o používání su nebo sudo. A obecně zabezpečit počítač proti lokálnímu útočníkovi je řádově složitější, než zabezpečit ho proti vzdálenému útočníkovi.
Krome toho neni tak spatne, kdyz se kazdy prihlasi na svuj neprivilegovany ucet a pak da su, aby v logu bylo videt, kdo tam v kterou dobu lezl. Kdyz se neco posere a nekdo pak jede pres pul zemekoule zmacknout tlacitko reset, tak se aspon vi, koho za to nakopat.
Stejně tak je v logu vidět, kterým klíčem se někdo přihlásil. Použití su nepřináší v tomhle případě žádnou přidanou hodnotu.
Ano, pokud pouzijete zminene klice a ne uzivatele s heslem.
To je podle mne základní bezpečnostní požadavek. Nechápu, že někdo komplikuje přihlašování su a řeší evidenci konkrétního přihlášeného uživatele, a přitom nechá uživatele přihlašovat se heslem.
Navic musite klice dukladne evidovat
Stejně důkladně, jako evidujete přihlašovací jména.
-
OMG, nez zacnes znovuvynalezat kolo, podivej se, co je to Zabbix a Puppet.
OMG, zkus se zamyslet nad tim, ze by treba tazatel chtel vytvorit vlastni reseni... at jiz proto ze to chce mit plne pod kontrolou, nebo proto aby se tim neco naucil...
-
OMG, nez zacnes znovuvynalezat kolo, podivej se, co je to Zabbix a Puppet.
OMG, zkus se zamyslet nad tim, ze by treba tazatel chtel vytvorit vlastni reseni... at jiz proto ze to chce mit plne pod kontrolou, nebo proto aby se tim neco naucil...
Tak to je hezky, ale kdyz ani netusi, ze takove nastroje existuji, jak funguji push/pull metody apod., tak tezko bude jeho vysledek pouzitelny.
-
OMG, nez zacnes znovuvynalezat kolo, podivej se, co je to Zabbix a Puppet.
OMG, zkus se zamyslet nad tim, ze by treba tazatel chtel vytvorit vlastni reseni... at jiz proto ze to chce mit plne pod kontrolou, nebo proto aby se tim neco naucil...
Ja tam ctu to NIH.
Pokud to bere jako treningovou zalezitost, tak by to mozna mohl zduraznit. Protoze reseni cviceni a reseni realneho problemu jsou v tomhle pripade dost ruzne veci.
-
Jedná se o řešení reálného problému. Na vlastním řešení netrvám, jen mám rád jednoduché věci, ty fungují spolehlivě. Zkusím ten Zabbix/Puppet, ale není mi jasné, jak dostanu ta data do databáze.