Sicherheitsaspekte für check_by_ssh

Super Moderator

Tuesday, April 25th 2006, 10:33am

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.

Go to the top of the page

pitchfork

Super Moderator

Posts: 13,323

Birthday: Jun 13th 1971 (39)

Gender: male

Location: Kassel

Occupation: Sysadmin SAP / Linux / AIX

Number of Nagios server: 2

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

Nagios Versions: 3.2.1

Icinga-Version(en): ---

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 310

Number of services: 4500

OS: Debian 5.0 Lenny

Plugin Versions: 1.4.x

NagVis Version: 1.4.1

NDO Version: ---

IDO-Version: ---

Perfparse Version: ---

Other Addons: SNMPTT, NagTrap, NagVis 1.4.5, check_mk, PNP-0.6.x. Thruk

2

Tuesday, April 25th 2006, 10:43am

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.6 ist online !
Fragen zu PNP mit Angabe der verwendeten PNP Version werden bevorzugt beantwortet.

Go to the top of the page

lausser

Professional

Posts: 1,216

Gender: male

Location: München

Occupation: Informatiker

Number of Nagios server: 1

Nagios Versions: 3.2.0

Distributed monitoring: Nein

Redundant monitoring: Ja

Number of hosts: 204

Number of services: 3855

OS: Linux/SLES10, CentOS5.2

Plugin Versions: 1.4.14

NDO Version: 1.4b7

Other Addons: PNP

3

Tuesday, April 25th 2006, 11:41am

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.

Go to the top of the page

Andurin

Super Moderator

Posts: 4,393

4

Tuesday, April 25th 2006, 12:55pm

@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.

@lausser: 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.

Go to the top of the page

netzwerk-ag-scj

Beginner

Posts: 2

Number of Nagios server: 2

Nagios Versions: 3

Distributed monitoring: Nein

Redundant monitoring: Ja

Number of hosts: 15

Number of services: 50

OS: Gentoo Linux

Plugin Versions: Nagios-Plugins 1.4.12, NDO 1.4

5

Sunday, September 14th 2008, 4:54pm

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

Go to the top of the page

LaMi

Geek

Posts: 3,189

Birthday: Sep 22nd

Gender: male

Location: München

Occupation: Systemadministrator

Number of Nagios server: 1

Nagios Versions: 3.2

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 500

Number of services: 2300

OS: SLES10/64

Plugin Versions: 1.4.8

NagVis Version: Trunk

NDO Version: -

Perfparse Version: -

Other Addons: PNP (SVN), SNMPTT, SYSLOG-NG

6

Sunday, September 14th 2008, 5:33pm

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

NagVis: [ Sourceforge.net | NagVis.org |

]
LarsMichelsen.com about Nagios

/(bb|[^b]{2})/

Go to the top of the page

netzwerk-ag-scj

Beginner

Posts: 2

Number of Nagios server: 2

Nagios Versions: 3

Distributed monitoring: Nein

Redundant monitoring: Ja

Number of hosts: 15

Number of services: 50

OS: Gentoo Linux

Plugin Versions: Nagios-Plugins 1.4.12, NDO 1.4

7

Sunday, September 14th 2008, 6:17pm

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.

Go to the top of the page

LaMi

Geek

Posts: 3,189

Birthday: Sep 22nd

Gender: male

Location: München

Occupation: Systemadministrator

Number of Nagios server: 1

Nagios Versions: 3.2

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 500

Number of services: 2300

OS: SLES10/64

Plugin Versions: 1.4.8

NagVis Version: Trunk

NDO Version: -

Perfparse Version: -

Other Addons: PNP (SVN), SNMPTT, SYSLOG-NG

8

Sunday, September 14th 2008, 7:03pm

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

NagVis: [ Sourceforge.net | NagVis.org |

]
LarsMichelsen.com about Nagios

/(bb|[^b]{2})/

Go to the top of the page

contact_name

Professional

Posts: 704

Gender: male

Location: DMZ

Number of Nagios server: 2

Nagios Versions: 3.2.x

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: 700

Number of services: 5100

OS: SLES10

Plugin Versions: 1.4.x

NagVis Version: 1.4

NDO Version: 1.4

Other Addons: NagiosGrapher, Business Process AddOns, netMySLA

9

Monday, September 15th 2008, 5:03pm

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.

Go to the top of the page

firephaser

Intermediate

Posts: 214

Birthday: Jun 27th

Gender: male

Location: Hannover

Occupation: Systemingenieur

Number of Nagios server: 5

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

Nagios Versions: 3.06

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: >500

Number of services: >3000

OS: OpenSuse10.2

Plugin Versions: nagios-plugins-1.4.11

NagVis Version: 1.3

NDO Version: letzte

Other Addons: NagiosQL 3.0.2 , PNP 0.6.5, SNMPTT, SNMPTRAP, Business Prozess, Nagtrap, check_mk 1.1.7i3

10

Tuesday, September 16th 2008, 7:20am

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ß

Go to the top of the page

ThorstenT

Beginner

Posts: 10

Gender: male

Location: Karlsruhe

Occupation: Sysadmin

Number of Nagios server: 7

Nagios Versions: 3

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: ~1200

Number of services: ~4000

OS: Debian GNU/Linux

Plugin Versions: 1.4.11 mit Patches

Other Addons: PNP

11

Tuesday, September 16th 2008, 2:29pm

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

Go to the top of the page

crush

Intermediate

Posts: 190

Gender: male

Occupation: ChefChoch-Engineer

Number of Nagios server: ~5

Nagios Versions: 3.x, icinga

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: ~200

Number of services: ~2000

OS: Ubuntu 9.04 LTS / Debian Stable

Plugin Versions: up to date

NagVis Version: up to date

NDO Version: up to date

Other Addons: snmptt, nagtrap, nconf

12

Friday, November 21st 2008, 11:41am

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 has attached the following file:

validate_ssh.zip (1.15 kB - 228 times downloaded - Last download: Aug 30th 2010, 11:12pm)

Go to the top of the page

dan_bsz

Beginner

Posts: 5

Location: Konstanz

Number of Nagios server: 2

Nagios Versions: 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: NA

Number of services: NA

OS: Solaris 10, Debian Lenny

Plugin Versions: 1.4.13

NagVis Version: 1.3.2

NDO Version: 1.4b7-altinity

Other Addons: PNP

13

Thursday, January 21st 2010, 3:47pm

@crush:

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

This post has been edited 1 times, last edit by "dan_bsz" (Jan 21st 2010, 4:29pm)