29.08.2011, 21:24 UTC+2

Sie sind nicht angemeldet.

Sicherheitsaspekte für check_by_ssh

Andurin

Super Moderator

Beiträge: 4 393

1

25.04.2006, 10:33

Sicherheitsaspekte für check_by_ssh

Hallo Leute,

so langsam aber sicher komme ich auch in die Verlegenheit dass ich auf Remote Systemen lokale Plugins ausführen muss.

Nun stehe ich wie viele auch vor der kleinen Glaubenskrise zwischen: NRPE, check_by_ssh, cronjobs+nsca.

Soll nun aber keine Pro/Contra Diskussion werden.

Vielmehr interessiert mich eure Handhabe mit check_by_ssh.

Gehen wir mal davon aus, dass mein Public Key, starke Verschlüsselung etc, soweit fertig ist und auf 150 Systemen einkehrt, so dass ich diese per check_by_ssh anfahren kann.

Das ganze lauffähig zu kriegen ist kein Problem aber was ist mit folgendem Problem:

Da der private Key für den nagios User lesbar sein muss ist er auch potentiel gefährde.

Der Nagios User ist zwar ein recht unpriviligierter User aber durch einen ssh private Key der Möglichkeit zum Zugriff auf 150 Systeme wird er ja fast schon gefährlich.

Den SSH Key wiederum mit einem Passwort zu versehen bringt an Nagios stelle ja recht wenig, da dass Passwort wiederum irgendwo in Klartext hinterlegt werden müsste.

Mich würde eure Meinung und ggf. auch vorhandene Lösungen zu dem Thema interessieren.

MfG
Hendrik
Wenn Sie das hier lesen, bin ich schon nicht mehr da... schön war die Ära, toll die Zeiten, super die Kontakte aber für den Moment bin ich raus.

pitchfork

Super Moderator

Beiträge: 15 032

Wohnort: Kassel

Beruf: Sysadmin SAP / Linux / AIX

Anzahl Nagios-Server: 2

Hobbys: Motorrad fahren, wenns die Zeit erlaubt :-)

Nagios-Version(en): 3.2.1

Icinga-Version(en): ---

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 310

Anzahl Services: 4500

Betriebssystem(e): Debian 5.0 Lenny

Plugin-Version(en): 1.4.x

NagVis-Version: 1.4.1

NDO-Version: ---

IDO-Version: ---

Perfparse-Version: ---

Sonstige Addon's: SNMPTT, NagTrap, NagVis 1.4.5, check_mk, PNP-0.6.x. Thruk

2

25.04.2006, 10:43

generell musst du dafür sorgen das der nagios User auf dem Nagios Server nicht missbraucht wird.

Weiterhin kannst du für check_by_ssh einen anderen Key verwenden als der User in seinem Home Verzeichnis hat.

Also kann der nagios User nur vom nagios Host aus arbeiten.

Jörg
PNP Developer.
PNP 0.6.14 ist online !
Fragen zu PNP mit Angabe der verwendeten PNP Version werden bevorzugt beantwortet.
OMD - Open Monitoring Distribution

lausser

Profi

Beiträge: 1 299

Geschlecht: Männlich

Wohnort: München

Beruf: Informatiker

Anzahl Nagios-Server: 1

Nagios-Version(en): 3.2.0

Verteiltes Monitoring: Ja

Redundantes Monitoring: Ja

Anzahl-Hosts: 2000

Anzahl Services: 30000

Betriebssystem(e): Linux/SLES11, CentOS5.5

Plugin-Version(en): 1.4.14

NDO-Version: 1.4b7

Sonstige Addon's: PNP,mod_gearman,OMD

3

25.04.2006, 11:41

Wenn die Zahl der Plugins halbwegs überschaubar bleibt, könntest du für jedes einen eigenen Key erzeugen und die Plugins als forced commands in der authorized_keys eintragen.
Also in etwa so:

Auf dem Nagiosserver:
ssh-keygen -f check_procs.key ....
ssh-keygen -f check_swap.key ....
....
dann bekommst du ein Schlüsselpaar für jedes Plugin, z.b. check_load.key + check_load.key.pub,...

authorized_keys auf den Nagios-Clients:
command="/usr/local/nagios/libexec/check_procs $SSH_ORIGINAL_COMMAND" ssh-rsa AAAA...pubkey von check_procs.key.....
command="/usr/local/nagios/libexec/check_swap $SSH_ORIGINAL_COMMAND" ssh-rsa AABA...pubkey von check_swap.key......

Mist, jetzt wird's doch irgendwie eklig:
In den checkcommands muss bei jedem check_by_ssh der entspr. private key dabeistehen.
define command {
command_name check_by_ssh
command_line $USER1$/check_by_ssh -H $HOSTADDRESS$ -t $ARG1$ -i $ARG2$ -C '$ARG3$' -a '$ARG4'
}

und in den Services auch
define service {
service_description check_swap
host_name itdbs08.muc
check_command check_by_ssh!10!check_swap.key!check_swap!-w 15% -c 8%
}

Ist alles recht aufwendig, aber so kannst du schon mal die rumfliegenden Schlüssel an ganz bestimmte Kommandos binden und den Zugang zur Shell verhindern.
Eventuell kannst du auch auf der Clientseite einen Wrapper schreiben, der Pluginnamen entgegennimmt und diese nur dann ausführt, wenn sie im libexec von Nagios liegen. Der Wrapper wäre auch als forced command in den authorized_keys und du kämst mitnur einem einem einzigen Schlüssel aus.

Andurin

Super Moderator

Beiträge: 4 393

4

25.04.2006, 12:55

@Jörg: Hatte das heute mit unserer Security Abteilung mal durchgesprochen. Die haben da, zu recht, ihre Bauchschmerzen bei. Jeder Angreifer der in Besitz des private Keys kommt kann auf alle anderen Systeme zugreifen.

: SCHEIßE! Das ist "gaskrankes" Denken funzt aber einwandfrei. :baby:

Danke schonmal dafür was aber nicht bedeuten soll, dass ich keine weiteren Gedanken mehr zu dem Thema haben möchte ?(
Wenn Sie das hier lesen, bin ich schon nicht mehr da... schön war die Ära, toll die Zeiten, super die Kontakte aber für den Moment bin ich raus.

netzwerk-ag-scj

Anfänger

Beiträge: 2

Anzahl Nagios-Server: 2

Nagios-Version(en): 3

Verteiltes Monitoring: Nein

Redundantes Monitoring: Ja

Anzahl-Hosts: 15

Anzahl Services: 50

Betriebssystem(e): Gentoo Linux

Plugin-Version(en): Nagios-Plugins 1.4.12, NDO 1.4

5

14.09.2008, 16:54

Ich weiss, das Thema ist schon was her...

Da aber NRPE bei uns im Netz ein wenig spinnt, erwäge ich auf ssh umzusteigen - zumal ich proprietäre Protokolle hasse und da Vermeidungsgtendenzen habe.

Mir gefällt das PubKey-Problem auch nicht besonders, auch wenn es leicht einzurichten ist.

Da wir aber ohnehin bald für AAA einen Radius-Server aufsetzen werden müssen, habe ich mich gefragt, ob es nicht intelligenter als mit PubKey-Verfahren geht.
Und siehe da: Kerberos 5 oder Radius wären ja tatsächlich potentiell genau das was man haben will.

Frage: hat damit jemand Erfahrung? Für mich sieht Kerberos extrem aufwändig aus, aber auch Radius ist nicht unbedingt ohne. Einfach nur Meinungen sind natürlich uach willkommen ;)

Gruß, NetzwerkAG

LaMi

Geek

Beiträge: 3 577

Geburtstag: 22.09.

Geschlecht: Männlich

Wohnort: München

Beruf: Berater / Entwickler

Anzahl Nagios-Server: x

Nagios-Version(en): 3.2.x

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: x

Anzahl Services: x

Betriebssystem(e): SLES,CentOS,Debian

Plugin-Version(en): x

NagVis-Version: Git

NDO-Version: -

IDO-Version: -

Perfparse-Version: -

Sonstige Addon's: PNP, Check_MK, Livestatus, Multisite

6

14.09.2008, 17:33

N'abend,
ich habe vor einiger Zeit mal meine bescheidene Meinung zu dem Thema niedergeschrieben: http://www.vertical-visions.de/2007/07/2…le-beschranken/

Man sollte sich wohl nocht etwas mehr arbeit machen und das Bash Script sicherer gestaltet oder gleich was kleines binäres schreiben.

Vielleicht hilft es dir ja weiter ...

Grüße,
Lars

netzwerk-ag-scj

Anfänger

Beiträge: 2

Anzahl Nagios-Server: 2

Nagios-Version(en): 3

Verteiltes Monitoring: Nein

Redundantes Monitoring: Ja

Anzahl-Hosts: 15

Anzahl Services: 50

Betriebssystem(e): Gentoo Linux

Plugin-Version(en): Nagios-Plugins 1.4.12, NDO 1.4

7

14.09.2008, 18:17

Das man den entsprechenden User, etc auf die Befehle beschränkt dürfte wohl klar sein... (Ich hielt das jetzt mal für selbstverständlich.) Es ging mir auch eher darum die Problematik mit den private-Keys zu umgehen, denn der muss unverschlüsselt für den nagios-Host-user zugänglich sein - ohne das kann die Kommunikation nicht funktionieren.

LaMi

Geek

Beiträge: 3 577

Geburtstag: 22.09.

Geschlecht: Männlich

Wohnort: München

Beruf: Berater / Entwickler

Anzahl Nagios-Server: x

Nagios-Version(en): 3.2.x

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: x

Anzahl Services: x

Betriebssystem(e): SLES,CentOS,Debian

Plugin-Version(en): x

NagVis-Version: Git

NDO-Version: -

IDO-Version: -

Perfparse-Version: -

Sonstige Addon's: PNP, Check_MK, Livestatus, Multisite

8

14.09.2008, 19:03

Hupsala ... von 2006 *hust* ... ich bin in meinem Post eher auf den Ursprungs-Post eingegangen.
Wäre evtl. sinnvoller gewesen ein neues Thema auf zu machen, da dein Post nicht mehr viel mit der Ursprünglichen Fragestellung zu tun hat. Nu auch egal ;-) So sind die Spezis wenigstens gleich aufgescheucht, dass es in dem Thread was neues gibt ;-)

Zu deiner Frage: Technisch sollte das kein Problem sein. Um die Installation und Konfiguration von Kerberos und Konsorten würde ich mir keine großen Sorgen machen. Das sollte zu schaffen sein.

Das Problem ist eher, dass der Authentifizierungs-Overhead für die einzelnen Checks möglichst gering bleiben sollte. Man nehme mal an, dass auf einem Host 20 Services laufen, die im 2 Minuten Intervall abgefragt werden. Ein Check selbst braucht im Normal-Zustand vielleicht nicht mehr als 1-2 Sekunden. Die Authentifizierung kommt dann bei jedem Check oben drauf. Da könnte schon einiges an Overhead zusammenkommen.

Man könnte natürlich z.B. via check_multi dagegen steuern und die Anzahl der einzelnen Services reduzieren. Das geht aber auch nicht bedingungslos.

Auch hier kann man wohl keine Pauschal-Aussagen treffen. Vielleicht lohnt es sich ja mal eine kleine Testumgebung aufzubauen.

Grüße,
Lars

contact_name

Profi

Beiträge: 704

Geschlecht: Männlich

Wohnort: DMZ

Anzahl Nagios-Server: 2

Nagios-Version(en): 3.2.x

Verteiltes Monitoring: Ja

Redundantes Monitoring: Nein

Anzahl-Hosts: 700

Anzahl Services: 5100

Betriebssystem(e): SLES10

Plugin-Version(en): 1.4.x

NagVis-Version: 1.4

NDO-Version: 1.4

Sonstige Addon's: NagiosGrapher, Business Process AddOns, netMySLA

9

15.09.2008, 17:03

Meiner Meinung nach ist check_by_ssh so ziemlich das sicherste, was man bekommen kann:
- kryptografische Authentifizierung, Absicherung gegen Verfälschung und Integrität wird durch SSH abgesichert
- der User nagios auf dem Nagios-Server ist ein unprivilegierter User
- der User nagios auf den zu überwachenden Rechnern ist ebenfalls ein unprivilegierter User
- auf den SSH-Dienst haben rund um den Erdball eine Menge Sicherheitsspezialisten ein großes Auge. Nebenbei kommt OpenSSH auch noch vom OpenBSD-Team.

Man muss eigentlich nur dafür sorgen, dass Sicherheitslücken in den Rechnern für lokale Rechte-Eskalation regelmäßig gestopft werden, dann ist man imho im sicheren Fahrwasser.

Ich bin aber sowieso der Meinung, dass der Nagios-Server in einem active-check Modell eigentlich immer ein großes security-Problem ist und man lieber zusehen sollte, dass Angreifer gar nicht erst diesen kompromittieren, statt zu versuchen, die ganzen Monitoring-Zugriffsrechte, die man gezwungenermaßen braucht, mühevoll wieder einzuschränken.

Vor DoS schützt das natürlich alles nicht... Aber davon sind SNMP, NRPE, passive checks usw. auch betroffen...


Aber davon mal abgesehen, der imho größte Vorteil von check_by_ssh: man muss in der Regel keinen weiteren Dienst evaluieren, ausrollen, pflegen, administrieren, da bei vielen bzw. den meisten Unix-Büchsen eh schon ein sshd läuft. Ein snmpd, nrped usw. müsste man erst mal so weit durch das Management und die IT-Sicherheitsverantwortlichen durchdiskutieren und danach auch maintainen. Beim sshd macht dass der Admin quasi automatisch mit, da es ohne SSH eh' kaum geht.

firephaser

Fortgeschrittener

Beiträge: 219

Geburtstag: 27.06.

Geschlecht: Männlich

Wohnort: Hannover

Beruf: Systemingenieur

Anzahl Nagios-Server: 5

Hobbys: Hat man diese noch neben der Arbeit :-)

Nagios-Version(en): 3.06

Verteiltes Monitoring: Ja

Redundantes Monitoring: Ja

Anzahl-Hosts: >500

Anzahl Services: >3000

Betriebssystem(e): OpenSuse10.2

Plugin-Version(en): nagios-plugins-1.4.11

NagVis-Version: 1.5.5

NDO-Version: letzte

Sonstige Addon's: NagiosQL 3.0.4 , PNP 0.6.10, SNMPTT, SNMPTRAP, Business Prozess, Nagtrap, check_mk 1.1.9i2, Autoresponder 1.0 Beta

10

16.09.2008, 07:20

Hallo,

diese Frage hat sich bei uns auch am Anfang gestellt, aber wir haben dann nicht versucht die Überprüfung durch check_by_ssh zu ändern, sondern den Nagsiosserver selber.

1. Nagiosserver steht mit einem Interface in einem abgeschirmten Netzwerk auf dem nur per HTTP zugegriffen werden kann und hört nicht auf SSH
2. Der Server hat ein zusätzliches Interface in einem weiteren Netzwerk, über dem die SSH-Checks vorgenommen werden.
3. Auf dem Nagiosserver kann man zur administration nur von einem Rechner aus zugreifen.

Gruß

ThorstenT

Anfänger

Beiträge: 10

Geschlecht: Männlich

Wohnort: Karlsruhe

Beruf: Sysadmin

Anzahl Nagios-Server: 7

Nagios-Version(en): 3

Verteiltes Monitoring: Ja

Redundantes Monitoring: Ja

Anzahl-Hosts: ~1200

Anzahl Services: ~4000

Betriebssystem(e): Debian GNU/Linux

Plugin-Version(en): 1.4.11 mit Patches

Sonstige Addon's: PNP

11

16.09.2008, 14:29

Wir hatten check_by_ssh mal am Laufen, aber der Overhead steht meines Erachtens in keinem Aufwand zum Nutzen. Wir haben uns inzwischen mit einer Mischung aus check_nrpe und der Netzkatze geholfen.

NRPE laeuft bei uns unter xinetd als eigener, unprivilegierter Nutzer. Das Ganze mit anonymous SSL ist schon relativ sicher. Wenn man keine Command Arguments zulaesst, kann ein MITM nicht allzuviel Bloedsinn anstellen, selbst wenn er per Impersonifikations-Angriff zum Nagios-Server wird. Fuer sensible Checks ist das IMHO absolut ausreichend.

Viele Daten sind aber auch schlicht nicht schuetzenswert (z.B. Release-Staende). Die werden per xinetd und "/bin/sh cat bla/blub" im Klartext auf einem Port ausgegeben (auch nur vom Monitoring-Netz aus erreichbar). nc auf den Port und man hat das Ergebnis. Billiger gehts nicht und 20000 Sockets gegen 20000 SSH-Sessions sind schon ein kleiner Unterschied.

Wenn man check_by_ssh verwenden und 20 verschiedene Keys mit verschiedenen forced commands vermeiden will, kann man auch seine eigene restricted Shell schreiben. Dann reicht ein forced command mit einem Key:
Mit der Serveroption AcceptEnv kann man remote gesetzte Umgebungsvariablen zulassen. Ein C-Wrapper um eine beliebige Shell koennte eine bestimmte Umgebungsvarible auslesen und eine entsprechendes Plugin ausfuehren und das Ergebnis zurueckliefern. Damit hat man den Mechanismus von NRPE fast nachgebaut.

Wenn man auf SSH besteht, sollte man uebrigens bedenken, dass man paranoiderweise seine zentrale known_hosts von Hand pflegen muss. Bei unknown host key Meldungen blind auf Speichern klicken, fuehrt die gesamte Authentifizierung von SSH ad absurdum. Das gilt natuerlich auch ausserhalb von check_by_ssh...

My 2ct,
Thorsten


PS: Man sollte die Daten der Postings ab und zu mal ansehen... Man ignoriere meine Ausfuehrungen hinsichtlich Relevanz zum Thema :)

crush

Fortgeschrittener

Beiträge: 210

Geschlecht: Männlich

Beruf: ChefChoch-Engineer

Anzahl Nagios-Server: ~5

Nagios-Version(en): 3.x, icinga

Verteiltes Monitoring: Ja

Redundantes Monitoring: Nein

Anzahl-Hosts: ~200

Anzahl Services: ~2000

Betriebssystem(e): Ubuntu 9.04 LTS / Debian Stable

Plugin-Version(en): up to date

NagVis-Version: up to date

NDO-Version: up to date

Sonstige Addon's: snmptt, nagtrap, nconf

12

21.11.2008, 11:41

Der Thread ist uralt ich weis, aber das Thema passt...

Ich habe das Script von Lars ein wenig aufpoliert. Eine Mischung aus Sicherheit und etwas flexibilität :-)

Was haltet ihr davon?

Bei Bedarf und zur genaueren Erläuterung würde ich das ganze ins wiki packen.
»crush« hat folgende Datei angehängt:
  • validate_ssh.zip (1,15 kB - 280 mal heruntergeladen - zuletzt: 04.08.2011, 21:01)

dan_bsz

Anfänger

Beiträge: 5

Wohnort: Konstanz

Anzahl Nagios-Server: 2

Nagios-Version(en): 3.0.6

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: NA

Anzahl Services: NA

Betriebssystem(e): Solaris 10, Debian Lenny

Plugin-Version(en): 1.4.13

NagVis-Version: 1.3.2

NDO-Version: 1.4b7-altinity

Sonstige Addon's: PNP

13

21.01.2010, 15:47

:

kann es sein dass deine Variante des Scripts keine checks ausführen lässt, welche selbst nur als skripte (bash, perl, etc.) vorliegen und "verbotene" Zeichen verwenden?

EDIT:

konkret geht es darum dieses script ausführen zu können:
http://jucr.opensolaris.org/files/720/53…ck_solaris_swap

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »dan_bsz« (21.01.2010, 16:29)

crush

Fortgeschrittener

Beiträge: 210

Geschlecht: Männlich

Beruf: ChefChoch-Engineer

Anzahl Nagios-Server: ~5

Nagios-Version(en): 3.x, icinga

Verteiltes Monitoring: Ja

Redundantes Monitoring: Nein

Anzahl-Hosts: ~200

Anzahl Services: ~2000

Betriebssystem(e): Ubuntu 9.04 LTS / Debian Stable

Plugin-Version(en): up to date

NagVis-Version: up to date

NDO-Version: up to date

Sonstige Addon's: snmptt, nagtrap, nconf

14

21.01.2010, 17:43

Das thema war ja schon alt, und nun mein script auch :-p

k.a. bennene es mal check_solaris_swap nach check_swap um !?

dan_bsz

Anfänger

Beiträge: 5

Wohnort: Konstanz

Anzahl Nagios-Server: 2

Nagios-Version(en): 3.0.6

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: NA

Anzahl Services: NA

Betriebssystem(e): Solaris 10, Debian Lenny

Plugin-Version(en): 1.4.13

NagVis-Version: 1.3.2

NDO-Version: 1.4b7-altinity

Sonstige Addon's: PNP

15

09.02.2010, 16:43

das wars.

Quellcode

 
1

reg="^check_[0-9a-z%\/[:space:]:]{2,32}$"


der Befehl darf mit check_ anfangen, aber danach darf kein _ wieder auftauchen. Daher hatte es nicht geklappt.