sikkerhet.tex

\chapter{Sikkerhet}\label{chap:sikkerhet}
Informasjon som brukes av overvåkningsserveren til å avgjøre tilstanden til en enhet eller tjeneste kommer fra eksterne kilder. Plugin-er vil ha eksekveringstillatelse på eksterne enheter, og SNMP trap-meldinger sender informasjon via en port på overvåkningsserveren. Fokus for prosjektet har vært implementasjon, men det er tatt noen sikkerhetsvurderinger underveis. Ulike sikkerhetsrisikoer og hvilke implikasjoner dette har for imlementasjonen vil bli gått gjennom i dette kapittelet.
\clearpage

\section{Plugin-er}
Flere plugin-er har blitt installert i etterkant av Icinga, og dette utgjør en viss sikkerhetsrisiko. Flere plugin-er har et omfang på 1000 - 5000 linjer og det er en tidkrevende prosess å kvalitetsikre alle. De sjekkene som eksekveres på andre enheter, og ikke på selve Icinga-serveren, er plugin-er som kommer med nagios-plugins og NSclient++. Disse blir brukt av et stort antall organisasjoner og andre. Gruppen har også fulgt med på fora og i kommentarfelt for de ulike plugin-ene for å kunne være trygge på de plugin-ene som kjører på hver enkelt host. 

De plugin-ene som sjekker en tjeneste eller henter ut informasjon som check\_dns, og check\_dhcp har i utgangspunktet ingen mulighet for å kjøre direkte på en host. Disse kan utføre ondsinnede handlinger på selve Icinga-serveren. Alle plugin-er som er tatt i bruk kommer enten i fra monitor-exchange.org, op5, opsview, eller nagios-exchange.

\section{Nettverk}
Icinga-serveren står i et adskilt VLAN. Ved hjelp av pakkefiltrering sperres innkommende trafikk fra andre nettverk. Icinga-serveren må kontakte andre servere den skal overvåke og kommunikasjon som er initiert av Icinga tillates i brannmuren. 

Utstyr som skal sende SNMP-traps til Icinga må få åpnet tilgang i brannmurene som krysses på ruten. Kommunikasjonen fra Icinga-serveren og ut til andre servere rutes gjennom VLAN, som ikke inneholder kommunikasjon fra periferiutstyr. For at denne kommunikasjonen skal kunne sniffes må disse nettverkene være kompromittert.

\subsubsection{SNMP}
I implementasjonen er det benyttet SNMP v2c for alt utstyr som støtter det. I noen få tilfeller har bare v1 vært støttet. Både v1 og v2c benytter autentisering basert på en klar tekststring kalt ``community string''. Det er heller ingen integritetssjekk som verifiserer at kommandoen som ble sendt er den samme som kom fram. Dette er viktigere dersom en sender ``write-kommandoer'', men i dette prosjektet benyttes bare ``read'' for å hente ut informasjon.

I SNMP v3 er det mange muligheter for økt sikkerhet:
\begin{itemize*}
	\item Konfidensialitet. Kryptering. DES
	\item Integritet. Hashing med MD5 eller SHA
	\item Autentisering. Det kan settes rettigheter for spesifikke OID-er for definerte brukere
\end{itemize*}
Overgang til SNMPv3 vil medføre en konfigurasjonsendring på alle enheter som skal overvåkes. En vil også måtte bytte ut eller endre en del plugin-er da disse benytter SNMPv2 eller v1.
\subsubsection{NRPE}
For kryptering og gjenkjenning av hosts har NRPE implementert OpenSSL med en anonymous Diffie-Hellmann. Plugin-en bruker h-filen dh.h til å generere base-nummer og prim-nummer for diffie-hellmann nøkkelutveksling. Disse blir satt statisk ved kompilering av kildekoden, noe som vil si at det er likt for alle debian-pakkene. Etter autentisering av host og Icinga-serveren brukes AES 256 bit for kryptering av trafikk\cite{nrpessl}.

NRPE blir som nevnt tidligere i \ref{sec:nrpe} brukt for å eksekvere kommandoer på eksterne maskiner, og kan være en angrepsvektor både fra overvåkningsserveren og via andre enheter til de den er installert på. Den eksterne maksinen som NRPE blir installert på vil åpne opp for sikkerhetsrisikoer, men det er fortsatt tilpasninger som kan gjøres for å unngå tilgang for uvedkommende og utførelse av ondsinnede handlinger. I konfigurasjonen må en definere hvilke hosts som skal kunne kommunisere med serveren, en må da vite hvilke IP-er som er definert i denne listen. Her vil overvåkningsserveren  i de fleste tilfeller være en definert IP, og da kan det spoofes om denne er kjent for en angriper. En kan også via konfigurasjonen endre porten eksterne enheter skal lytte på. Standardisert port kan finnes i dokumentasjonen så denne bør endres for å skjule tjenestenavn ved portscanning.

Videre utvidelse av implementasjonen av NRPE vil være å ta i bruk forhåndssignerte sertifikater 
som NSClient++ støtter, det vil da føre til en sikrere nøkkelutveksling enn dagens som bare baseres på et prim- og basenummer som er definert ved kompilering.

I konfigurasjonen for NRPE på Linux-servere brukes direktivet ``dont\_blame\_nrpe=1''. Uten dette vil det ikke tillates å sende argumenter til sjekker som skal kjøres.
\subsubsection{NSClient++}
For Windows som bruker NSClient++ kan det settes opp passord som i tillegg kreves for kommunikasjon, dette legger enda et lag med sikkerthet.
Direktivet ``allow\_nasty\_meta\_chars'' er satt i konfigurasjonen for å kunne benytte  WMI-spørringer som parameter til check\_nrpe. Direktivet gjør at spørringene ikke blir regnet som skadelige når NSclient++ mottar de. Dette er fordi en del karakterer vanligvis ville blitt escapet.

I konfigurasjonesfilen for NSClient++ defineres serveradressen slik at kun Icinga-serveren har tilgang til å koble til via NRPE. Dersom denne settes opp til å inkludere et subnett eller inneholder feil adresse vil det være mulig for andre enheter enn Icinga-serveren å koble seg til NRPE-agenten.

\section{Brukerkontoer}
En brukerkonto ble opprettet i Active Directory for Icinga. Denne benyttes ved tilkobling mot domenet på flere områder:
\begin{itemize*}
	\item Sjekk av LDAP.
	\item Synkronisering av kontakter.
	\item Tilkobling mot MSSQL database.
	\item Tilkobling til VMware (Read-only i Virtual Center).
\end{itemize*}
For MSSQL må det også settes tilganger for brukeren. Denne har minimale rettigheter slik at den kun kan lese administrative tabeller. 

I MySQL kreves det en bruker i en database på hver server. Disse brukerne får også minimale rettigheter, og har kun tilgang til å lese databasen ``INFORMATION\_SCHEMA''. 

For hver Oracle instanse kreves en egen bruker som har tilgang til se logger, statistikk og status for instansenen. Det lages en bruker med tilgang til å gjøre ``SELECT''-spørringer på tabellene.
Alle brukeropprettingene blitt gjennomgått med databaseansvarlige ved IKT-avdelingen. 

Brukeren som brukes for XenServer har rollen Pool Admin, da IKT-avdelingen bruker en versjon som ikke har funksjonen ``Role Base Access Control''. 
\subsection{LDAP}
LDAP benyttes ved synkronisering av kontakter og kan benyttes til innlogging i Icinga Web og Icinga Classic, som beskrevet i \ref{sec:ldapauth}. LDAP over SSL kan benyttes for å kryptere denne kommunikasjonen. Da må dette konfigureres og et sertifikat installeres på Icinga-serveren.