Trond H. Amundsen Gruppe for serverdrift, USIT, UiO Linux ved UiO Trond H. Amundsen Gruppe for serverdrift, USIT, UiO

Dagens tema Litt historikk og tall Konsepter rundt stabil drift Konfigurasjonsstyring & orkestrering Sikkerhetstiltak i åpne nettverk Programvare Håndtering av avvik, vanlige problemer og utfordringer Skyen: UH-IaaS

Linux-historien ved UiO 1990-tallet UNIX: Ultrix, IRIX, HP-UX, AIX, OSF1, SunOS/Solaris Linux var et leketøy 2000-tallet Linux tar mer og mer over for gammel UNIX Standardisering 2010-tallet Virtualisering (VmWare) Automatisering

Tall OS-versjoner: RHEL5: 49 RHEL6: 1228 RHEL7: 1443 Fedora: 105 Server og desktop: Desktop: 1263 Server: 1562 Virtuelle: 1355

???????

Stabil drift Kontinuerlig eller periodisk endring? Endre hele tiden? eller Samle endringer og gjøre kvartalsvis? Endringsråd? Kontinerlig endring har klare fordeler: Enkelt å se hvilken endring som har medført feil Brukere slipper å vente på endringen Man blir ferdig med oppgaven og kan fokusere på neste ting

Stabil drift Provisjonering skal kun gjøres via sentral løsning for dette Selvbetjening Bruker PXE og Red Hat/Fedora kickstart Automatisk innmelding i diverse systemer, f.eks. for konfigurasjonsstyring Maskinen kommer opp ferdig konfigurert og klar til bruk

Stabil drift Tilgangskontroll Den som trenger det, får tilgang Gi de ansatte anledning til å vokse med ansvaret “Hvis du ikke gjør feil, jobber du ikke” Felles punkt for tilgang til maskinene (jump-host) med 2-faktor autentisering Logging Tilgang som administrator bør ikke være anonym Felles loggmottak Kan se hvem som har gjort hva, og når

Stabil drift Overvåkning Hovedsakelig for servere Viktige tjenester bør overvåkes Basisovervåkning (disk, minne, CPU etc.) Tildele ansvar for overvåkning av tjenesten til tjenesteeier (selvbetjening) Patching Så ofte som mulig (daglig) Endring som bør gjøres kontinuerlig

Stabil drift Automatisk innsamling av data Alltid ha oversikt OS-type, versjoner, patch-nivå m.m. Søkbart via RESTful API Kan brukes til å generere faste rapporter Brukes til å automatisere beslutninger, f.eks. hvordan en server eller tjeneste skal overvåkes

Oppsummert Oversikt ved Innsamling av nøkkeldata fra maskinene Sentralt loggmottak Overvåkning Grafing av statistiske data Kontroll ved Sentral provisjonering (installasjon) Sentral konfigurasjonsstyring Sentral løsning for orkestrering

???????

Konfigurasjonsstyring Definere en ønsket tilstand, verktøyet skal da sørge for at maskinen oppnår dette CFEngine, Puppet, Chef Kjører periodisk (hvert 5.minutt, hver time e.l.) Oppnå konvergens => Unngå divergens Koden i sentralt Git-repository, med automatisk testing (Jenkins) og manuell godkjenning for prod- setting Konfigurasjon basert på roller Sentral kontroll med rolletildeling

files: redhat:: "/etc/shadow" perms => mog("0600","root","root");

Orkestrering Gjøre noe med et sett av maskiner, med en gang Ansible Automatisere rutiner rundt oppsett av tjenester, omstart av maskiner og tjenester, osv. Fire and forget Man kan si at en SSH-løkke er enkel form for orkestrering

for host in foo bar baz; do ssh $host 'chmod 0600 /etc/shadow; chown root:root /etc/shadow' done

--- - hosts: lvs_test_hosts tasks: - name: Fix /etc/shadow file: path: /etc/shadow owner: root group: root mode: 0600

???????

Sikkerhet Et universitet må i utgangspunktet ha et åpent nettverk Forventes av studenter og forskere Vi må sikre maskinene så godt som mulig

Security Enhanced Linux (SELinux) Bruker Red Hat sin “targeted”-policy Endel tjenester er underlagt et ekstra lag med policy- regler En handling (f.eks. lese en fil, åpne en port) blir kun tillatt dersom policy for tjenesten tillater det Kommer før vanlige UNIX-rettigheter Godt forsvar mot sikkerhetshull (zero-day) Er komplekst, kan være vanskelig å feilsøke

Lokal brannvegg Brannvegg er i utgangspunktet konfigurert svært strengt Godt nok for de fleste OK for systemeier å endre som man ønsker

Sentral brannvegg Svært åpen, noen få porter er sperret Server-nett har standardiserte kategorier åpent for verden åpent for UH-sektoren, resten sperret åpent for UiO, resten sperret osv.

Secure Shell (SSH) Vår viktigste protokoll for fjerninnlogging Nøkkelbasert autentisering i tillegg til passord Vi har full kontroll med konfigurasjonen Vi har kontroll på viktige nøkkelpar Tillater kun innlogging som root dersom henvendelsen kommer fra UiO-nett Unngår 100000-vis av bruteforce-angrep i døgnet

Autentisering Sentral kontroll over autentisering Egenutviklet applikasjon for brukerdata, oppretting m.m., som eksporterer til LDAP, AD osv. Bruker LDAP til autentisering, med SSSD som cachende mellomlag

Patching Patching blir automatisk satt opp til å skje en gang i døgnet Vi er nesten alltid i forkant når et sikkerhetshull blir kjent Krever ikke reboot Bruker OS-ets mekanisme for dette (yum/dnf)

???????

Programvare Tillater installasjon av programvare fra endel kjente kilder Red Hat / Fedora EPEL (extra packages for RHEL) RPMFusion (Fedora) andre Installasjon fra kilder som ikke er godkjent kan svekke stabilitet og sikkerhet

Vitenskapelig programvare Vi tilbyr noe lisensbelagt programvare via en egenutviklet løsning Matlab, Maple, Mathematica m.m. Sentral lisenstjener Annen programvare er tilgjengelig via de godkjente pakkebrønnene Brukere kan installere programvare selv, dersom det ikke kreves admin-tilgang Noen brukere har admin-tilgang

Vanlige problemer og utfordringer Typiske tilfeller: Kan ikke ha oppdateringer av spesifikk programvare Må kjøre spesifikk Linux-distribusjon, dvs. ikke RHEL eller Fedora Må ha spesielle åpninger i nettet Kan ikke kjøre med SELinux påskrudd

Vanlige problemer og utfordringer Vi prøver alltid å få det til, helst automatisert Færrest mulig avvik Involvere sikkerhetsgruppa om nødvendig Mulige løsninger: Sette maskinen på lukket nettverk Tilby alternative løsninger (skyen? Docker?) Vi har en egen gruppe som tilbyr avansert brukerstøtte til forskere med spesielle behov Ikke slingringsmonn ihht. norsk lov, f.eks. behandling av sensitive data

Kontrollert kaos

???????

UH-IaaS

Logical architecture

Infrastructure as a Service

BGO OSL

414 prosjekter 353 brukere 459 kjørende instanser * status.uh-iaas.no

www.uh-iaas.no