NAV-ref Home

Tilstede:

• Peder Smart Sefland, HiVolda
• Rune Kittelsen, UiA
• Ingeborg Hellemo, UiT
• Nils-Arild Grav, NTNU
• Sigurd Refvik, UiO

• Hanne Moa, Sikt
• Johanna England, Sikt
• Simon Oliver Tveit, Sikt
• Ilona Podliashanyk, Sikt
• Morten Brekkevold, Sikt

Forfall:

• Vidar Faltinsen, Sikt

Møtet blir avholdt som videokonferanse vha. Zoom, fra kl. 09:00 til 12:00.

Morten ønsker velkommen på vegne av Sikt.

• Releases siden sist møte:
  • NAV 5.7.0
  • NAV 5.7.1
  • NAV 5.8.0
  • NAV 5.8.1
  • NAV 5.8.2
  • NAV 5.8.3
• 5.7 ble i hovedsak gjennomgått sist.
• Hovednyheter i 5.8:
  • SNMPv3-støtte i alt utenom traps (enkel demo?)
  • PoE-støtte for Juniper og Cisco i PortAdmin (enkel demo?)
• Det er også gjort en del arbeid for å komme videre med JWT som alternativ løsning for API-tokens i NAV, men dette var ikke ferdig i tide til 5.8.
• Det er gjennomført en penetrasjonstest av NAV

• Fremdeles gjenstår en del teknisk gjeld vi må hanskes med for å få NAV kompatibel først med Python 3.11, og senere 3.12.
  • 3.11 er viktig for at vi skal få verktøykassene opp på nyeste Debian stable (Bookworm)
  • Vi forsøker også å få bukt med JavaScript-delen av NAV, som er strukturert på litt gammeldags og tungvindt vis (i JS-verdenen har det jo vært en rivende utvikling i flere år).
• En del av det vi hadde begynt på før 5.7 ble satt på vent ifm. at SNMPv3 ble opp-prioritert av CNaaS. Dette vil vi fortsette på i neste sprint over jul, som refresh-knapp i ipdevinfo

Runde rundt “bordet”. UiT har meldt inn ett innspill i forkant:

Ønske om ny funksjonalitet: Søk på serienummer i søkefeltet

Vi velger neste møtedato, ca. 5. mars.

Morten ønsket velkommen på vegne av Sikt.

Status for utvikling den siste tiden ble presentert.

SNNMPv3 seilte opp som høyeste prioritet etter at CNaaS-tjenesten har blitt solgt inn til kunder som har strenge sikkerhetskrav til kommunikasjon på nett (i.e. mangel på SNMPv3 er en “dealbreaker”).

SNMPv3 management profiles ble kort demonstrert, og det ble understreket at støtten fremdeles ikke gjelder SNMP traps.

Dette ble kort vist fram for en Juniper produksjonsswitch i Sikt. UiA har testet NAV 5.8 den siste uken og har litt problemer med å få dette til å virke for Cisco-switcher.

• AKSJON: Rune skal melde tilbake hvilke Cisco-PoE-switcher han har som ikke fungerer i PortAdmin, så vi vet hva vi skal teste for.

HiVolda ba om en redegjørelse for hva både de ferdige og de uferdige JWT-endringene innebærer.

JWT (JSON Web Tokens) er kort forklart gjennomsiktige tokens brukt til autentisering mot API-er. I motsetning til NAVs nåværende ugjennomsiktige tokens (en random hex-streng som NAV må ta vare på som et slags “passord”), fungerer JWT-tokens som lesbare krav om API-tilganger, men som må være signert av en nøkkel som API-et stoler på. Det fins en rekke standardiserte “krav” i et JWT-token som sier noe om gyldighetstiden for tokenet, og for hvilken tjeneste det er utstedt for, og bør et API ta hensyn til.

De endringene som tidligere er gjennomført er at NAV kan konfigureres til å slippe inn klienter i API-et dersom de presenterer gyldige JWT-tokens (hvor gyldighetstiden ikke er gått ut), signert av en kilde som man har konfigurert NAV til å stole på.

Det som jobbes med, men som ikke er ute i en NAV-release enda er muligheten til at NAV kan utstede og signere sine egne JWT-tokens, slik at vi på lengre sikt kan fjerne den gamle token-løsningen helt, uten å gjøre NAV avhengig av en tredjepart for token-utstedelse.

Vi har forbedret dokumentasjonen og integrasjonen rundt “ekstern” integrasjon av Feide, dvs. autentisering/autorisasjon vha. moduler i webserveren (Apache), fremfor at NAV forestår selve innloggingsbiten. De to aktuelle modulene som dokumenteres med howto-guides er mod_auth_openidc og mod_mellon.

Det understrekes dog at ved slike “eksterne” løsninger blir NAVs egen innloggingsmekanisme koblet ut. UiT kommenterer at dette er en “showstopper” for å ta dette i bruk, da det innebærer at man ikke har en “bakvei” inn i NAV dersom koblingen til Feide skulle falle ut.

Sikt understreker at vi på lenger sikt vil jobbe for at NAVs brukermodell integreres bedre med Djangos brukermodell, slik at vi kan være i stand til å ta i bruk alle godt utprøvde og populære tredjeparts-bibliotekene for å integrere forskjellige former for autentisering i en Django-applikasjon, inkludert SAML. På denne måten kan NAV fortsatt tilby lokal login.

Det er gjennomført en penetrasjonstest av NAV av sikkerhetsfolk i Sikt, blant annet med bakgrunn i sikkerhetskrav fra nye CNaaS-kunder.

Penetrasjonstesten har påvist en del problemer som bør rettes opp, men rapporten forelå først i går ettermiddag, så den vil måtte gjennomgås og prioriterte oppgaver settes opp først på nyåret, da resten av 2023 består for en stor del av reiseaktivitet og ferieavvikling i teamet.

Vi vil fortsette å jobbe med å tilpasse NAV til å fungere godt med f.eks. nyere versjoner av Python. Vi trenger å komme oss opp på Python 3.11 og senere 3.12, og vil droppe støtten for 3.7 så snart vi får oppgradert verktøykassene fra Debian 10 (Buster) til Debian 11 (Bullseye) og senere Debian 12 (Bookworm).

Dessuten er det en gjentagende problem at NAV henger ganske langt bak i tid når det gjelder måten tredjeparts JavaScript-biblioteker blir håndtert i webgrensesnittet, der NAV bundler en rekke gamle versjoner av JS-biblioteker med potensielle sårbarheter i seg. Her jobbes i kulissene for å få modernisert NAVs modell.

Vi har enda ikke begynt med Cable test from NAV #1508, men utviklerne fikk etterspurt hvor funksjonaliteten antas å høre hjemme i NAV, og det ble raskt konsensus om at PortAdmin bør være riktig sted.

Formodentlig vil neste sprint fokusere først og fremst på retting av potensielle funn fra penetrasjonstesten, men også på å ferdigstille de features som allerede er under utvikling. Vi ser derfor ikke noe stort behov for feedback til utviklingen på nåværende tidspunkt.

Runde rundt bordet. Vi starter med UiT, som har kommet med ett skriftlig innspill i forkant av møtet.

• Ønsker seg “serienummersøk” fra NAVbar.
  • Først og fremst som oppslag på IP devices, men som utviklerne påpeker er det mer enn “bokser” som har serienummer i NAV-databasen, det også underkomponenter av bokser, eller komponenter som ikke lenger er i bruk som NAV tilfeldigvis har historikk på.
  • NAV har et slags “plugin”-system for “søkemotorer” som svarer på søk i NAVbar. Dette kan være en glimrende anledning å dokumentere denne løsningen slik at andre er i stand til å utvide NAV på dette punktet.
  • Opprettet #2860
• UiT venter ellers mest på ting som står på lista fra før.

• Ifm. søke-ønsket som UiT flagger, nevner HiVolda at de ønsker å teste AI-teknologi som gjør det mulig å bruke “menneskelig lesbare forespørsler” til å søke opp og trekke mening ut av SQL-databaser uten å være SQL-ekspert. De ønsker å ta en kopi av sin NAV-database til å eksperimentere med dette på egen maskinvare, og vil ta kontakt for å få hjelp til dataeksport ved behov.

• Ingen spesielle ønsker å trekke frem.
• Kommenterer bare at SNMPv3 kom i grevens tid - de fikk behov for det akkurat da det kom, og har allerede begynt å teste det ut.

• Ønsker å rapportere en mulig irriterende feil vedrørende sortering av porter i port-fanen i ipdevinfo.
  • Dette ser ut til å gjelde for det meste på Cisco, hvor det blir en litt ulogisk sortering når man sorterer på navn.
    • UiT observerer det samme.
  • AKSJON: UiO og UiT skal sende inn konkrete eksempler på bokser der port-sorteringen blir ulogisk, sammen med detaljert forklaring på hva som vil regnes som logisk.
  • AKSJON: Utviklerteamet skal undersøke hvordan koden som sorterer porter i ipdevinfo faktisk er lagt opp.

• Forslag om å legge til MAC-adresse i ipdevinfo.
  • Mer spesifikt er det ønskelig at feltet som viser IP-adressen til en boks samtidig viser den MAC-adressen NAV kjenner for denne IP-adressen ut i fra innsamlede ARP-data.
  • Dette burde være et veldig enkelt tillegg.
  • AKSJON: Utviklerteamet registrerer et issue i trackeren og melder tilbake.
    • Show device MAC address next to IP address in ipdevinfo #3222

• Ønsker en opsjon for å frata brukere muligheten til å endre VLAN med PortAdmin på spesifikke bokser.
  • NTNU er i en lang overgangsfase fra gammelt til nytt nettverk.
  • De nye delene av nettverket styres av Cisco DNA Center, som skal være autoritativ for port-config.
  • MEN, det er veldig nyttig å la lokalt IT-ansvarlige sette egne portbeskrivelser, samtidig som det er tungvindt eller umulig å la lokalt IT-ansvarlige slippe inn i DNA center for å gjøre denne ene operasjonen.
  • NTNU ønsker derfor mulighet til å markere noen bokser som del av det nye nettverket (altså styrt av DNA center), og bruke dette til å få PortAdmin til å nekte VLAN-endringer (men ikke description-endringer) på dette utstyret.
  • AKSJON: Utviklerteamet oppretter et issue i GitHub-trackeren.

• Ønsker et grensesnitt for å registrere infrastruktur-utstyr som skal slippe på nett vha. MAB (MAC Authentication Bypass).
  • Ettersom NTNUs nett i stadig større grad er på vei på SDN, må alle klienter som ønsker å komme på nett være i stand til å autentisere seg.
  • Noe utstyr (eks trådløse aksesspunkter) autentiserer seg basert på automatisk gjenkjenning (vha Profilering i DNA Center)
  • Men, det fins store mengder infrastruktur-utstyr som ikke kan autentisere seg med 802.1X (brukernavn og passord). Dette utstyret kan være labutstyr, IoT-enheter eller store mengder A/V-utstyr som lokalt IT-ansvarlige setter opp.
    • Slikt utstyr må registreres i ISE (Cisco Identity Services Engine) for å bli gjenstand for MAB og dermed slippe inn på nettverket uten andre former for autentisering.
  • NTNU ser derfor for seg et grensesnitt som kan la NAV-brukere registrere slikt utstyr mot ISEs API-er, ettersom “vanlige” brukere ikke slippes inn i ISE.
  • Ser for seg at alle NAV-brukere skal få lov til å legge inn og fjerne utstyr her. Ikke sikkert ISE kan registrere informasjon om hvilke brukere som har lagt inn hva, og det er dumt med dobbel bokføring i NAV, slik at det er et potensiale her for at brukere ved uhell kan fjerne utstyr som andre har lagt inn. Derfor viktig med audit-logging av en slik funksjon.
  • UiA kommenterer at de bruker FreeRADIUS til noe lignende, men har et litt annet publikum for et slikt verktøy: Alle som har Feide-bruker på UiA skal være i stand til å registrere sine egne IoT-dingser i et system som sørger for at utstyret blir lagt inn i FreeRADIUS som godkjent. Dingser som er lagt inn vil ha forskjellig utløpstid (basert på om du er student eller ansatt) før de må fornyes.
    • UiA har i flere rundt forsøkt å ferdigstille et grensesnitt for dette vha. studentprosjekter o.l., men det er fremdeles ikke helt ferdigstilt.
  • UiO har noe lignende i form av noen kommandolinjeprogrammer som kan brukes til å registrere slik utstyr i DNS, og så vil DNS-innholdet senere bli eksportert til Cisco ISE.
  • AKSJON: Utviklerteamet registrerer et issue i GitHub-trackeren.

• Har fått tilbakemelding fra brukere om irriterende feil i Status-widget: Alarmer for porter har en popup med port-informasjon som i noen nettlesere aldri forsvinner igjen - man må lukke hele nettleser-fanen for å bli kvitt det.
  • Nils-Arild selv klarer ikke å gjenskape dette i sin nettleser (Chrome 119). (Bruker som har meldt problemet har Chrome v.119.0.6045.160 64bit)
  • Ingeborg opplever det samme i Firefox 117.0.0.1 på FreeBSD.
  • Sigurd kjører også Chrome og hos han fungerer det tilsynelatende også fint.
  • AKSJON: Dette minner om noe som har vært rapportert før, for lenge siden. Utviklerteamet sjekker om det fins en issue fra før, og lager evt. en ny hvis det lar seg gjenskape på noe vis.

Det oppsto spontant en diskusjon blant alle om innsynsrettigheter i NAV. Dette har vært diskutert flere ganger før uten at det har fått noen helt konkrete følger: Authorization based on users organizational affiliation (#1046)

HiVolda forsøkte å legge til noen NAV-brukere og ga de medlemskap i en organisasjonsenhet, og trodde med dette at de kunne begrense vedkommendes innsyn til å bare gjelde utstyr knyttet til denne organisasjonen. Dette er ikke tilfelle.

Generelt kan organisasjonenheter i NAV knyttes til følgende dataelementer:

• IP Device (Netbox)
• User
• VLAN

I tillegg er organisasjoner hierarkiske i NAV, noe som kan forstås som at brukere f.eks. har implisitt medlemskap i alle underorganisasjoner.

Hvordan kan man begrense brukeres innsyn basert på dette? Forslag:

• ipdevinfo kan vise bare bokser som er registrert på en organisasjon som brukeren er medlem av.
• IP-søk i machinetracker kan bare vise IP-adresser på VLAN som tilhører en organisasjon brukeren er medlem av.

Ubesvarte spørsmål:

• Hvordan begrenser man innsyn i API-et?
• Hvordan begrenser man MAC-søk i Machine Tracker?
• Hvordan kan man begrense Report-søk? Dette er trolig veldig vanskelig, da rapportgeneratoren er dum. Den bare viser resultatet av SQL-spørringer, men har ingen formening om hva disse dataene den viser betyr, eller hvordan de skal tolkes. Må vi da sperre alle sammen ute fra report-verktøyet?
• Kan/ønsker man å begrense innsyn i hvilke subnett som fins i det hele tatt? IPAM og Prefix Matrix?
• Hva med begrensning på hva man kan sette opp varsling på? Her har allerede Alert Profiles et eget system for å pålegge begrensninger, og dette er uavhengig av organisasjonstilhørighet - men settes på gruppenivå.

• AKSJON: Punktene fra denne diskusjonen bør registreres som kommentarer på #1046 i GitHub.

Neste møtedato ble satt til 5. mars, klokken 9-12, hovedsakelig som videomøte.