NetBIOS, en introduksjon til SMB og CIFS.

Et kompendium beregnet på elever ved Oslo By Steinerskole, datalinjen.

(Kilder: www.samba.org, www.ibm.com, RFC 1001 og RFC 1002.)

Hva er NetBIOS?

La oss begynne med å gå litt tilbake i tid, tilbake til 1984. Dette året skrev IBM et enkelt API (Application Programming Interface) til bruk på sine datamaskiner som var i nettverk. Formålet var å lave et grunnleggende system for programmer til å kunne kontakte andre maskiner og dele data over nettverk. Dette API kalte IBM Network Basic Input / Output System, NetBIOS.

På mange måter er NetBIOS en videreføring eller utvidelse av standard BIOS kall. Selv om dette ikke er så vanlig lengre, var eldre operativsystem ofte avhengige av å bruke BIOS (sende kall til BIOS) blandt annet til filsystemdrivere. BIOS inneholder lavnivå-kode som filsystemdrivere benyttet seg av. Dette var uheldig fordi BIOS kall bare kan foretas i unprotected mode . Derfor måtte CPU tas ut av protected mode og settes til unprotected mode, foreta BIOS kall, settes tilbake til protected mode og fortsette de vanlige prosessene. Dette var tidkrevende og moderne operativsystemer bruker ikke BIOS kall lenger. Allikevel er NetBIOS basert på disse funksjonene. På samme måte som BIOS kan brukes til å kontakte et filsystem kan NetBIOS brukes til å kontakte et filsystem på en annen maskin. NetBIOS brukes bare innen et LAN. På denne tiden var det IBM Token Ring og IBM PC nettverk som ble brukt. Det var jo IBM som holdt på med dette... Det var behov for en transportprotokoll for disse NetBIOS kallene, de måtte jo ha en måte å vite hvilken maskin de skulle henvende seg til (navneløsing) og en måte å frakte signalene gjennom kabelen (transport).

I 1985 lavet IBM en slik protokoll, beregnet på NetBIOS. Den ble kalt NetBIOS Extended User Interface, NetBEUI. Protokollen var designet slik at den kunne tackle maskinnavn på opptil 15 bokstaver, det var et krav at navnet var unikt på nettverket, og kunne brukes på LAN med inntil 255 noder. I 1985 var det et ganske generøst antall!

NetBEUI protokollen ble svært populær blandt utviklere av nettverksapplikasjoner, særlig for Windows. Etterhvert ble det utviklet systemer for å frakte NetBIOS kall over Novells protokoll IPX/SPX (Internet Packet eXchange / Sequential Packet eXchenge) og utbredelsen av NetBIOS kall økte. Allikevel var det et skjær i sjøen. Internet begynte å bli mer og mer interessant og der ble det brukt en helt annen protokoll, nemlig TCP/IP (Transmission Control Protocol / Internet Protocol) og UDP/IP (User Datagram Protocol / Internet Protocol). Det ble derfor nødvendig å utvikle systemer for å bruke disse som bæreprotokoller for NetBIOS kall også.

Som man sikkert vet bruker TCP/IP og UDP/IP tall for å adressere maskiner (f.eks. 192.168.54.32), men NetBIOS bruker bare navn. Da disse systemene skulle “smeltes sammen” var dette et alvorlig problem. I 1987 ble dette løst ved at IETF (The Internet Engineering Task Force) sendte ut RFC (Request For Comment) nr. 1001 og 1002 som beskrev en måte å standardisere dette. Disse dokumentene regulerer fremdeles alt som skjer i et NetBIOS basert nettverk, både i Windows og Samba .

Denne standarden har senere fått navnet NetBIOS over TCP/IP eller bare NBT. Du vil også komme til å finne forkortelsen NetBT, spesielt i Microsofts dokumentasjon.

NBT standarden (RFC 1001/1002) beskriver tre grunnleggende tjenester på nettverket:

• En navnetjeneste

• To kommunikasjonstjenester:

• Datagram

• Sesjon

Navnetjenesten løser problemet ovenfor med kobling mellom navn og IP adresse. Dette foregår på mange måter slik som en DNS server løser navn og IP adresser på Internet. Både datagramtjenesten og sesjonstjenesten er sekundære kommunikasjonsprotokoller som brukes for å frakte data frem og tilbake mellom NetBIOS maskiner i et LAN.

Hvem heter hva? Navneregistrering.

I NetBIOS verdenen er det slik at når en datamaskin starter og kobler seg til nettverket vil den kreve å få ha et navn. Dette navnet må ikke være i bruk fra før, ellers blir det umulig å kommunisere med den og med navnebroren. Ingen ville vite hvor de skulle sende datapakkene. Det må derfor laves et system slik at dette ikke skjer. Det er to måter å gjøre dette på:

• Bruk en NBNS (NetBIOS Name Server) som holder orden på hvilke navn som er i bruk.

• La maskinene forsvare seg hvis noen forsøker å bruke et navn som alt er i bruk.

La oss se på metodene:

Illustrasjon 1-1 Navneregistrering med broadcast vs. NBNS

Som vi ser får maskinene i begge tilfelle anledning til å registrere seg på nettverket med et navn, så sant det ikke er i bruk fra før. Som tidligere nevnt er dette ikke bestandig nok, vi må kanskje ha en resolusjon av navn mot IP adresse også. Igjen er det to metoder man kan benytte i NBT miljø:

• La maskinene svare med sin egen IP adresse når de hører et broadcast for NetBIOS navnet.

• La en NBNS holde styr på hvem som har hvilken IP.

La oss se på metodene:

Illustrasjon 1-2. Løsing av NetBIOS navn til IP med broadcast vs. NBNS.

Som du kanskje forstår allerede er det en stor fordel å ha en NBNS i nettverket. For å forklare det litt nøyere skal vi se på hva som egentlig skjer i broadcastmetoden .

Når en klient booter vil den sende ut en broadcastmelding (en melding som går til alle noder på nettverket) med et navn den ønsker å registrere. Hvis ingen protesterer vil den beholde dette navnet og bruke det. Hvis det nå viser seg at en annen maskin har dette navnet fra før, vil denne sende en melding tilbake til den nye maskinen på nettverket med beskjed om at navnet er i bruk og at den nye maskinen derfor ikke kan ha det. Dette kalles å forsvare navnet (hostname) sitt. Dette systemet virker greit, men det genererer mye nettverkstrafikk for noe såpass enkelt som navneregistrering.

Med NBNS er det mer eller mindre det samme som skjer, men all kommunikasjon foregår (bare) mellom den nye klienten og NBNS. Det går ikke ut noen broadcastpakker. Klienten henvender seg direkte til NBNS og NBNS vil alltid gi et svar, enten navnet er tatt eller ikke. Er det tatt får klienten beskjed om å velge et annet navn. Denne typen kommunikasjon kaller vi point-to-point kommunikasjon. Dette er spesielt viktig dersom du har et nettverk med mer enn et subnet. Rutere vil vanligvis ikke frakte broadcastpakker mellom subnet, og du får kanskje ikke kontakt med NBNS. Da får maskinen ikke logget på nettverket. Man kan tenke seg at maskinen vil bruke den andre metoden dersom den ikke får kontakt med nettverket via den første, og det gjør de av og til. Vi skal se på det senere.

Det samme skjer når navn skal løses til IP adresse. Dersom det er en NBNS vil alle klienter alltid spørre den om IP som tilhører navnet til en annen klient som den ønsker å utveksle data med. Hadde det ikke vært en NBNS i nettverket ville all navneløsing blitt gjort med broadcast. Dette ville skape mye og unødvendig trafikk i nettverket. Avhengig av hvilken type nettverk det er snakk om, og hvor stort det er, kan det bli mye overhead.

Man kan godt anføre at dette ikke er viktig i små nettverk, spesielt i hjemmenettverk med bare noen få raske maskiner og høy båndbredde. Allikevel er det lurt å unngå broadcastpakker i så stor grad som mulig. Det er i det minste en god vane. Dessuten vil nettverket være forberedt for fremtidig vekst, uten at du behøver å legge om noe. I alle litt større nettverk er det absolutt å anbefale at man gjør dette.

De forskjellige nodetypene:

Hvordan kan man vite om den maskinen vi starter om morgenen vil registrere seg via broadcast eller via NBNS? Alle maskiner tilhører en “klasse” av NBT maskiner. Vi har fire klasser, eller typer. Det er: b-node, p-node, m-node og h-node. Disse oppfører seg forskjellig. Vi skal se på forskjellene i denne tabellen:

Dersom du har en Windowsklient vil den sannsynligvis være en h-node (hybrid node). De tre første typene er de eneste du vil finne i RFC 1001/1002. H-noder kom senere, de ble faktisk oppfunnet av Microsoft og var på mange måter en forbedring med hensyn til redundans i nettverket. For å se hvilken type node din (Windows)maskin er åpner du et ledetekstvindu og skriver: ipconfig /all. Dersom du bruker Win9x skriver du winipcfg. Let efter linjen som begynner med: node type:.

Hva kan man hete?

NetBIOS navn er ganske forskjellig fra DNS hostname, som du sikkert kjenner godt til. For det første: NetBIOS navn er flate . Det er altså ikke et hierarkisk navnesystem slik som DNSnavn er. For eksempel er poppe.nu er DNS navn i to nivåer, og www.poppe.nu er et DNS navn i tre nivåer. På samme måte er www.oslo.kommune.no et DNS navn i 4 nivåer. Et NetBIOS navn er en unik tekststreng som for eksempel “rudolf” eller “printserver”. For det andre er NetBIOS navn begrenset til 15 tegn. Det kan bestå av a-z, A-Z, 0-9 og følgende spesialtegn:

! @ # $ % ^ & ( ) - ' { } . ~

Det er også, på mange systemer, tillatt å bruke æøåÆØÅ, men det kan være en god idè å la vare dersom du vil ha flere forskjellige operativsystemer i nettverket ditt. De behandler ofte dette litt forkjært. Som du ser er det også lov å bruke punktum, men igjen er det ikke en god idè. Det er grunn til å tro at det ikke vil være støtte for punktum i NetBIOS navn i fremtidige versjoner av NBT.

Det er ikke tilfeldig at et lovlig DNS navn (så sant det er 15 tegn eller færre) også er et lovlig NetBIOS navn. Det er faktisk slik at det ukvalifiserte DNS navnet til en node blir brukt som NetBIOS navn. Det ukvalifiserte DNS navnet er den delen av et DNS navn som står til venstre for det første punktumet. Eksempel: printserver er det ukvalifiserte DNS navnet for printserver.oslo.kommune.no . Navnet er ukvalifisert fordi det ikke sier noe om domenetilhørighet. I dette tilfellet ville gjerne NetBIOS navnet vært printserver fulgt av 4 blanke tegn (mellomromstegn). NetBIOS forlanger at navnet er 15 tegn og dersom det ikke er det, fylles det opp med blanktegn (ASCII 32). Det er ikke uvanlig å skrive NetBIOS navn med store bokstaver.

Ressursnavn og typer:

Med NetBIOS forteller ikke en datamaskin bare hva den heter, den forteller også hvilke typer ressurser den har. Dette gjør den ved å legge til en byte til på slutten av NetBIOS navnet. Denne byte nr. 16 forteller hvilken ressurstype maskinen er, og dersom den har flere oppgaver (de fleste maskiner har det) vil den registrere navnet sitt flere ganger, en gang for hver type, med disse forskjellige ressurstypesuffixene.

Illustrasjon 1-3. NetBIOS navnets oppbygning.

Det er vanlig å angi denne siste byten, ressurstypen i < “tags” >,
f.eks. <20> efter NetBIOS navnet. Tallet i <> er hexadesimalt, selv om dette ikke er spesielt angitt. Det er alltid hexadesimalt. Vi skriver f.eks:

RUDOLF<00>

Hvis du vil se hvilke tjenester en maskin har registrert seg med kan du bruke kommandoen nbtstat i et ledetekstvindu. Her er det som kommer opp på min maskin:

C:\>nbtstat -a putte

LAN:

Node-IP-adresse: [192.168.0.1] Område-ID: []

Navnetabell for ekstern maskin for NetBIOS

Navn Type Status

----------------------------------------------

PUTTE <00> UNIQUE Registrert

3ETAGE <00> GROUP Registrert

PUTTE <03> UNIQUE Registrert

INet~Services <1C> GROUP Registrert

IS~PUTTE......<00> UNIQUE Registrert

PUTTE <20> UNIQUE Registrert

3ETAGE <1E> GROUP Registrert

HPOPPE <03> UNIQUE Registrert

MAC-adresse = 00-48-54-53-88-85

Som du ser er NetBIOS navnet putte. Det er registrert tre ganger som <00>, <03> og <20>.

Hva betyr så dette? Det betyr at den har registrert et navn, at den kan ta imot beskjeder via Windows Messenger (det er “net send” tjenesten vi snakker om her) og at den er en fil og/eller printserver.

Vi ser på en oversikt over noen vanlige NetBIOS ressurstyper, først de som bare kan finnes én gang pr. Hostnavn, altså de unike. De som er listet som UNIQUE.

Det er flere, tilsammen er det 36, men dette er nok de vanligste å støte på av de unike navnene.

La oss også se på noen av de som ikke er unike, altså navn som flere maskiner kan ha. Et eksempel vil være navnet på domenet den tilhører, det deles med de andre i domenet eller arbeidsgruppen hvis det er et P2P nettverk.

Den siste raden i tabellen inneholder: <01><02>_ _MSBROWSE_<02>. Denne er litt spesiell og den brukes til å annonsere hele gruppen til andre master browsere.

Ikke ta det tungt om du ikke husker alle disse ressurstypene med en gang. Noen har du bruk for, andre ikke. De du trenger kommer fort. Det som er viktig å huske er logikken i hvordan dette foregår og hvorfor navnet på en maskin blir registrert flere ganger.

ScopeID:

I de riktig gamle, mørke dager, langt tilbake i tid, før grupper i NetBIOS fantes, var det en mekanisme som ble lagt til NetBIOS for å kunne skille maskiner fra hverandre. Man la til noe som kalles en ScopeID i SMB (Server Message Blocks) pakkene. Tanken var at man kunne få noen maskiner til å fremstå som om de var i en tilhørighet med hverandre ved at de hadde samme ScopeID. Dette brukes ikke i vanlige sammenhenger, men på grunn av bakoverkompatibilitet er det fremdeles mulig å sette ScopeID. Ikke gjør det, du vil kunne få en del problemer. Bruk vanlige grupper isteden, det er meget bedre, enklere og mer oversiktlig.

Sesjoner og datagrammer:

La oss se litt nærmere på hvordan NetBIOS egentlig lar datamaskiner dele data. NBTs oppgave er å sørge for forbindelse eller oppkobling mellom to maskiner slik at kommandoer kan gis fra den ene til den andre. Det gjør NBT ved hjelp av to tjenester: sesjonstjenesten (session service) og datagramtjenesten (datagram service) . For å forstå hvordan NetBIOS virker er det nødvendig å forstå disse to tjenestene. Det gir deg også en sjanse til å feilsøke et NetBIOS problem.

Datagramtjenesten har ingen form for stabil oppkobling til andre datamaskiner. Datapakker (datagrammer) blir bare sendt som broadcastpakker, uten at det tas hensyn til hvilken rekkefølge de kommer frem i, eller om de i det hele tatt kommer frem for den saks skyld. Dette ligner til forveksling på UDP. Man kan også finne en analogi i postverket. Der et brev er adressert til en bestemt mottager, er datagrammene mer som massekorsbånd. Reklamesendinger som deles ut i et distrikt og ingen oppdager om en enkelt mottager ikke fikk siste nytt fra REMA1000. Datagrammer er raske, de krever lite overhead og prosesseringen er enkel og lite ressurskrevende. Imidlertid er det dårlig sikkerhet, vi vet ikke om de kommer frem. Disse pakkene brukes derfor til å sende triviell informasjon, ting som ikke er så viktig.

Datagrammer bruker noe man kaller primitiver eller vi kunne kalle det tilstander .

Sesjonstjenesten (session service) er mer kompleks. Sesjoner er en kommunikasjonsform som, i alle fall teoretisk, kan oppdage problemer og feil i oppkoblingen og datastrømmen mellom to maskiner. Man kan tenke på sesjoner som telefonsamtaler. De er direkte mellom to entiteter og det oppdages fort om den ene parten faller ut. Man ringer opp, begge parter vet hvem den andre er, man har sagt hallo og presentert seg. Sesjonstjenesten bruker også primitiver , selv om det er litt flere:

Sesjoner er ryggraden i ressursdeling i et NBT nettverk. De brukes til å opprette stabile koblinger mellom klientcomputere og delte mapper eller delte printere på servere. Klienten “ringer opp” serveren og begynner å fortelle hvilke filer den ønsker å åpne, hvilke data den ønsker å utveksle også videre. Slike oppkoblinger kan vare lenge, ofte flere timer eller dagevis for den saks skyld. Dersom det skjer en feil i dataoverføringen vil transportprotokollen (TCP) be avsender om å sende på nytt inntil alle datapakker er kommer frem hele og uskadet.

La oss se på SMB protokollen:

Vi skal se på noen tekniske detaljer, på det grunnleggende nivået, og undersøke litt hvilke mekanismer som brukes i SMB (Server Message Block). Det er vel ikke egentlig helt nødvendig å kjenne alle disse elementene i detalj, men det er klart at dersom du har en forståelse for hvordan ting og tang virker på et grunnleggende nivå, vil det bli mye lettere å finne feil og å forstå hva som går galt når de mer komplekse sidene ved saken ikke fungerer som de skal.

På høyt nivå er SMB protokollen egentlig meget enkel. Den inneholder alle kommandoer du trenger for å foreta vanlige fil eller printeroperasjoner på en lokal disk eller printer. Det inkluderer:

• Åpne og lukke filer.

• Lave nye, eller slette gamle mapper.

• Lese og skrive filer.

• Søke efter filer.

• Legge til og fjerne filer i printspool-køen.

Alle disse operasjonene / kommandoene kan “pakkes inn” i en SMB pakke og sendes til og fra serveren. (Husk at enhver maskin som deler en ressurs er en server).
Selve navnet Server Message Block kommer egentlig fra DOS tiden, men disse datapakkene er modifisert til å kunne gå over nettverk, ikke bare lokalt.

SMB format:

Det er ikke uvanlig å karakterisere SMB protokollen som en “spørsmål – svar” protokoll (request-response). Dette betyr at klienter sender forespørsler til serveren som sender svar tilbake. Bare unntaksvis vil en server sende en melding til en klient, hvor meldingen IKKE er svar på en forespørsel fra klienten.
En SMB pakke er ikke så veldig kompleks. La oss se på den interne strukturen (oppbyggingen) av en SMB pakke. Den består av to deler:

• En “header” som har en fast størrelse og et fast format

• En “command string” (kommandostreng, dvs. en tekststreng med instruksjonsord). Denne kan variere mye i lengde, det kommer helt an på hvilke kommandoer eller instruksjoner som skal sendes.

Vi skal ikke gå i detalj om dette i denne omgang, men hvis du vil se hvordan disse delene er bygget opp så gå til: http://www.snia.org/tech_activities/CIFS.

Variasjoner over SMB protokollen:

NetBIOS er blitt endret og utvidet med nye og forbedrede kommandoer en rekke ganger. Det er, i alle fall i teorien, slik at alle nye variasjoner er bakoverkompatible. Dette betyr at det er mulig å ha flere NBT klienter i et nettverk og la dem kjøre forskjellige versjoner av protokollen. De fleste Windowsklienter støtter ca. 6 versjoner av SMB.

Vi setter raskt opp en oversikt over de forskjellige versjonene av SMB:

Samba er et system som settes opp på UNIX og GNU/Linux for å få til NBT mellom *NIX og Windows. Samba bruker altså NT LM 0.12.
CIFS er det samme som NT LM 0.12, men med noen små modifikasjoner.

SMB / CIFS klienter og servere:

Som tidligere nevnt er SMB / CIFS en klient / tjener (client / server) protokoll. I sin mest grunnleggende form betyr det at klienten sender en kommando, eller forespørsel til serveren, og tjeneren sender svar tilbake. Disse rollene kan fort snus, noen ganger under selve SMB / CIFS sesjonen.
La oss se på et eksempel:

Illustrasjon 1-4, deling av ressurser i NBT miljø.

Her ser vi to maskiner, Maya og Tolltec som begge bruker SMB. Maya deler ut en skriver på nettverket og Tolltec deler ut filer. Dette betyr at Maya er klient når den henter filer fra Tolltec, og den er server når den kjører printjobber for Tolltec.
Dette betyr at:

• En server er en maskin som deler ut en ressurs.

• En klient er en som ønsker å bruke denne ressursen.

• Alle maskiner i et nettverk kan være både server og klient, eller ingen av delene.

Alle versjoner av Microsoft Windows (f.o.m. 3.11) har SMB tjener og klient bygget inn i operativsystemet. De vil hele tiden være server, klient eller hverken eller, avhengig av hva som foregår i nettverket og på den lokale maskinen.
Når det gjelder *NIX så er det ikke vanlig at de støtter SMB. Imidlertid finnes det en gruppe programmer (et system) som kalles SAMBA. Dette er hovedsaklig en server-service som er beregnet på *NIX maskiner slik at de kan oppføre seg som Windows-servere i et NBT miljø. Man kan også sette opp Samba slik at *NIX klienten oppfører seg som en vanlig Windowsklient i nettverket. Samba er på ingen måte helt ferdig utviklet, men fra og med Samba 3.0 er støtten dramatisk forbedret. For nærmere informasjon om SMB / CIFS i hetrogene (blandede) nettverk bør du se på Sambadokumentasjonen på www.samba.org.

Vi ser på en enkel SMB oppkobling:

Det er tre trinn som må gjennomføres for at en klient kan koble seg til en delt ressurs på en server:

1. Etablere en NetBIOS sesjon.

2. Bestemme protokolltype.

3. Sette parametre for oppkoblingen og koble til ressursen i «tre-format» hierarkisk oppsett.

Vi skal se nærmere på alle tre trinn.

Etablering av NetBIOS sesjon:

Når en bruker ønsker å koble seg til en delt ressurs, eller sende en utskriftsjobb til en nettverksprinter så er det NetBIOS som tar seg av oppkoblingen på sesjonsnivå. Resultatet er en toveis kanal (bidirectional channel) mellom klienten og serveren. Det kreves bare to meldinger for å opprette kanalen mellom klient og server. Hvis vi ønsker å se innholdet i disse datapakkene kan vi bruke en Linuxmaskin med programmet tcpdump. Da slipper vi å bruke lisenskrevende, proprietær programvare. Her er utskrift fra en tcpdump:

     >>> NBT Packet
NBT Session Request
Flags=0x81000044
Destination=RUDOLF       NameType=0x20 (Server)
Source=ELEV4             NameType=0x00 (Workstation)

Derefter svarer serveren og gir tillatelse til at det opprettes en kanal:

>>> NBT Packet
NBT Session Granted
Flags=0x82000000

Nå er det opprettet en kanal mellom server og klient.

Bestemme protokolltype:

Det neste som skjer er at klienten sender en beskjed til serveren om at det må bli enighet om hvilken SMB protokoll som skal benyttes. Klienten må også finne ut hvilken tre-identifikator den skal bruke. En tre-identifikator (TID) er et nummer som identifiserer koblingen mellom klienten og den delte ressursen på serveren. Det kan jo være flere oppkoblinger samtidig. I og med at klienten ikke vet hvilken TID som skal brukes settes den til null, inntil et bedre tall kan bestemmes.

Kommandoen i denne pakken er: SMBnegprot (SMB negotiate protocol), altså en forespørsel om å bestemme hvilken protokolltype som skal benyttes hele resten av sesjonen. Legg merke til at klienten sender beskjed til serveren og gir serveren en liste over hvilke «sprog» den kan snakke, det er ikke motsatt. Vi ser på pakkeinnholdet:

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=154

SMB PACKET: SMBnegprot (REQUEST)
SMB Command   =  0x72
Error class   =  0x0
Error code    =  0
Flags1        =  0x0
Flags2        =  0x0
Tree ID       =  0
Proc ID       =  5315
UID           =  0
MID           =  257
Word Count    =  0
Dialect=PC NETWORK PROGRAM 1.0
Dialect=MICROSOFT NETWORKS 3.0
Dialect=DOS LM1.2X002
Dialect=DOS LANMAN2.1
Dialect=Windows for Workgroups 3.1a
Dialect=NT LM 0.12

Serveren svarer på SMBnegprot kommandoen ved å sende et svar med hvilken av disse «dialektene» som den vil bruke, ved å liste den varianten den foretrekker som alternativ 0. Den kan også sende svaret 0xFF, noe som betyr at ingen av «dialektene» er akseptable. Her er svaret fra serveren:

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=84

SMB PACKET: SMBnegprot (REPLY)
SMB Command   =  0x72
Error class   =  0x0
Error code    =  0
Flags1        =  0x80
Flags2        =  0x1
Tree ID       =  0
Proc ID       =  5315
UID           =  0
MID           =  257
Word Count    =  17
NT1 Protocol
DialectIndex=5
[...]

I dette eksempelet har serveren svart DialectIndex=5. Dette betyr at NT LM 0.12 er den SMB protokollvarianten som vil bli brukt i resten av sesjonen.

Sette parametre for oppkoblingen:

Det neste som skjer nå er at det må bestemmes både sesjons og log-in parametre. Til dette brukes kommandoen: SMBsesssetupX (ja, det er tre s'er fordi det står for SMB session setup). Disse paramtrene inneholder følgende:

• Konto- (bruker-) navn og passord (hvis det eksisterer).

• Navn på arbeidsgruppen eller domenet (domener behandles på samme måte som arbeidsgruppe. Det er uvesentlig for SMB protokollen on det er sentral styring av logon, eller om det er lokalt på maskinene, det eneste som kreves er at det er en autentisering).

• Maksimal mengde data som kan overføres.

• Antall forespørsler (request) som kan stå i kø på èn gang.

Vi ser på innholdet i disse pakkene også:

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=150

SMB PACKET: SMBsesssetupX (REQUEST)
SMB Command   =  0x73
Error class   =  0x0
Error code    =  0
Flags1        =  0x10
Flags2        =  0x0
Tree ID       =  0
Proc ID       =  5315
UID           =  1
MID           =  257
Word Count    =  13
Com2=0x75
Res1=0x0
Off2=120
MaxBuffer=2920
MaxMpx=50
VcNumber=0
SessionKey=0x1380
CaseInsensitivePasswordLength=24
CaseSensitivePasswordLength=0
Res=0x0
Capabilities=0x1
Pass1&Pass2&Account&Domain&OS&LanMan=  
  HPOPPE HemmeligPassOrd Windows 2000 Windows 2000

SMB PACKET: SMBtconX (REQUEST) (CHAINED)
smbvwv[]=
Com2=0xFF
Off2=0
Flags=0x2
PassLen=1
Passwd&Path&Device=
smb_bcc=23
smb_buf[]=\\RUDOLF\STAB\HPOPPE

I dette eksempelet vil SMBsesssetupX kommandoen tillate at det kan sendes enda en kommando i den samme pakken (bestemmes av at det står X på slutten av kommandoen), dette kalles «piggy-backing». Det betyr at når det sendes en kommando kan det følge med en til på lasset. Dette er praktisk og øker hastigheten fordi serveren ikke alltid trenger å vente på en ny kommando fra klienten. Vi ser også at den hexadesimale verdien for denne kommandoen (som er i feltet com2) er 0x75. Det er en tallverdi som tilsvarer kommandoen SMBtconX (SMB tree connect and X). Denne kommandoen vil lete efter navnet på den delte ressursen i smb_buf bufferen. I dette eksempelet inneholder smb_buf strengen: \\RUDOLF\STAB\HPOPPE som er det fullstendige pathname (stinavn) til en delt ressurs.
Legg merke til at TID (TreeIDentifier) fremdeles er 0. Det siste som skjer er at serveren sender et svar tilbake til klienten med en TID. Så snart det er gjort er klienten autentisert og klar til å benytte seg av den delte ressursen.

Vi ser på innholdet i pakken:

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=85

SMB PACKET: SMBsesssetupX (REPLY)
SMB Command   =  0x73
Error class   =  0x0
Error code    =  0
Flags1        =  0x80
Flags2        =  0x1
Tree ID       =  1
Proc ID       =  5315
UID           =  100
MID           =  257
Word Count    =  3
Com2=0x75
Off2=68
Action=0x1
[000] Unix Samba 2.2.6
[010] PRINTSERVER

SMB PACKET: SMBtconX (REPLY) (CHAINED)
smbvwv[]=
Com2=0xFF
Off2=0
smbbuf[]=
ServiceType=A:

Legg merke til parameteren ServiceType. Den har verdien «A», og det betyr at denne ressursen er en fildelingstjeneste (en filserver).
Det er flere service typer :

• «A» er en delt disk eller fil.

• «LPT1» er en spoolertjeneste (printserver).

• «COMM» står for en direkte koblet printer eller et delt modem (seriell kobling).

• «IPC» betyr Named Pipes. Named Pipes er en protokoll og den brukes for eksempel av Windowsmaskiner når de logger på nettverket og skal autentiseres av en domenekontroller.

Når klienten nå har fått en TID, kan den bruke denne som om det var en lokal disk. Den kan åpne filer, lese og skrive til dem, slette filer, opprette nye filer, søke efter filnavn etc.

Windows arbeidsgrupper og domener:

Det vi har sett på foreløbig ville være nok til å få dette til å virke, dersom du ikke har noe mer avansert enn DOS klienter i nettverket. Vi tar utgangspunkt i at vi ønsker å bruke klienter som er litt mer avanserte enn DOS, så vi skal se litt på hva Microsoft (Veslebløyt) har gjort for å forbedre situasjonen for mer avanserte klienter, nemlig introduksjonen av Windows for Workgroups (WFW) og Windows Domains.

Windows workgroups:

Dette er omtrent som det vi allerede har gått gjennom, men det er et par småting å ta hensyn til.

Browsing:

Browsing er prosessen med å finne andre maskiner som har delte ressurser i et Windowsnettverk. Legg merke til at browsing i denne sammenhengen ikke har noe som helst å gjøre med Internet og World Wide Web å gjøre, bortsett fra at det er en navnelikhet i «network browsing» og «Internet browsing». Browsing i denne sammenhengen foregår ikke ved hjelp av Internet Explorer eller en annen web browser (det kan gjøres av dette programmet også, men det er en annen sak).
På den annen side er det faktisk en likhet mellom disse to typene browsing, nemlig det at det gjelder å «finne ut hva som er der ute» og at «det som er der ute» kan endres uten forvarsel.

Før browsing kom, måtte brukerne vite hvor ressursen (den delte mappen) fantes og koble seg opp ved å skrive inn en UNC (Universal Naming Convention) som så (for eksempel) slik ut:

\\rudolf\elev_felles

Browsing er mye greiere. Det gir oss muligheten til å klikke på ikonet for Network Neighborhood (Mine nettverkssteder) og bruke et grafisk grensesnitt (GUI) for å lete efter ressurser på Windowsklienten.

Det er to grunnleggende måter å browse i et Windowsnettverk:

• Browse en liste av datamaskiner og delte ressurser

• Browse innholdet av en delt ressurs på en bestemt server

La oss se nærmere på den første. På alle LAN (eller et subnet) er det en maskin som har ansvar for å vedlikeholde og hele tiden oppdatere en oversikt / liste over hvilke delte ressurser som er tilgjengelige på nettverket. Denne computeren kalles Local Master Browser, og listen som den holder oppdatert kalles browse list. Denne listen hjelper til å redusere nettverkstraffikken ved at maskinene ikke trenger å skaffe seg oversikt over hva som finnes. Det er ikke nødvendig for alle maskiner å spørre alle andre maskiner hva som er tilgjengelig hele tiden, de henvender seg isteden til Master Browser og får en oppdatert liste derfra.

I den andre typen browsing er det nødvendig for klienten å koble seg til serveren som har den delte mappen. Innholdet av en delt mappe kan ikke leses fra browse list. Det er kun en oversikt over hvilke mapper som er delt på hvilken computer, ikke innholdet i dem. For å se innholdet kan man dobbeltklikke på mappen, eller maskinen. Hvis du forsøker dette vil du se at serveren svarer ved å gi deg en liste over hva den har å tilby.

Alle maskiner i et Windowsnettverk må fortelle master browser hva de har tilgjengelig av delte ressurser efter at de har registrert seg på nettverket med et NetBIOS navn. I teorien skal en server også si ifra til master browser når den forlater nettverket (dvs. blir skrudd av), men det forutsetter at maskinen får skru seg av på en ordentlig måte, ikke ved at strømmen plutselig går. Det er lokal Master Browser som har ansvaret for å holde orden på dette.

Advarsel:

Network Neighborhood kan oppføre seg ganske underlig av og til. Det er rett og slett ikke helt til å stole på. Noen ganger viser det maskiner som er skrudd av, eller har crashet, noen ganger kan det være maskiner i nettverket som ikke vises fordi Master Browser ikke har oppdaget dem. Data som vises i Network Neighborhood kan være gammelt, eller ikke helt «up to date». For å si det på en annen måte, du kan egentlig ikke være sikker på at listen er korrekt og den eneste måten å forsikre seg om at en ressurs virkelig er tilgjengelig er å koble seg til den.

Egentlig kan enhver Windowsmaskin i et nettverk bli nettverkets Master Browser. Det kan gjelde WfW, NT, 2000 eller XP. Den lokale Master Browser kan ha en eller flere backup browsere i nettverket. Disse kan ta over jobben dersom Master Browser ikke er tilgjengelig. Den kan ha crashet eller blitt skrudd av. For å få til en viss flyt i browsingen i et slikt tilfelle vil backup browsere jevnlig synkronisere sine browse lists med Master Browser.

Antall backup browsere i et Windowsnettverk bestemmes slik:

• Hvis det er inntil 32 Windows NT/2000/XP eller inntil 16 Windows 9x/Me vil det allokeres en backup browser.

• Hvis antall Windows NT/2000/XP er mellom 33 og 64 eller antall Windows 9x/Me er mellom 17 og 32 vil Master Browser allokere to backup browsere.

• For hver gang antallet Windows NT/2000/XP øker med 32, eller antall
  Windows 9x/Me øker med 16 vil det allokeres ytterligere en backup browser.

Det er ingen fast grense for hvor mange backup browsere som kan allokeres av Master Browser.

Browser elections (valg av Master Browser):

Browsing er en kritisk del av alle Windowsnettverk. Enten det er en arbeidsgruppe eller et domene. Dessverre er det ikke slik at alt går helt korrekt for seg på alle nettverk. La oss si at vi har et nettverk i en liten produksjonsbedrift. Kanskje det er arbeidsstasjonen til regnskapsføreren som er Master Browser. Plutselig velger han å skru av maskinen for å gå og spise lunch. Da kan det hende at det er en datamaskin som står ute i verkstedet som blir Master Browser. Her er det imidlertid et problem. Petter, som jobber som hjelpemann har en tendens til å skulke jobben og sitte og spille Counter Strike på denne maskinen. Den er ikke så veldig kraftig, og Petters spilling tar nesten all prosessorkraft. Dette betyr at browsingen blir sinket. Browsing må derfor være forberedt på at enhver maskin (server) kan komme og gå hele tiden, uten forvarsel. Eftersom det er slik at stort sett alle Windowsmaskiner kan ta rollen som Master Browser, må det finnes en måte å avgjøre hvem som faktisk ender opp med å bli Master Browser. Dette krever et valg. Det er innebygget en algoritme, en metode for å bestemme hvem som blir Master Browser og hvem som blir backup browser i nesten alle Microsoft operativsystemer. Et slikt valg kan fremtvinges når som helst. La oss si at regnskapsføreren kommer tilbake fra lunch og skrur på arbeidsstasjonen igjen. Når den nå registrerer seg med et NetBIOS navn på nettverket blir spørsmålet om maskinen Petter spiller CS på skal fortsette å være Master Browser, eller om regnskapsmaskinen skal ta tilbake rollen.

Når det foretas et browservalg vil alle maskiner i nettverket annonsere seg med datagrampakker. Disse datagrammene inneholder følgende:

• Hvilken versjon av browservalgprotokollen den bruker.

• Hvilket operativsystem maskinen har.

• Hvor lenge klienten har vært koblet til nettverket i denne omgangen.

• Klientens hostname (NetBIOS navn).

Browservalg settes i gang ved at det sendes ut et election request datagram av en maskin som oppdager at det ikke er noen Master Browser på nettverket. Dersom en Master Browser blir skrudd av på riktig måte (ikke dra ut kontakten) vil den sende ut et datagram som sier at de andre må foreta et valg seg i mellom. Ellers vil det vanligvis være en klient som forsøker å browse som ikke finner Master browser som gjør dette, eller det er en backup browser som leter efter en oppdatering / synkronisering av sin browse list og ikke får svar fra Master browser. I alle tilfellene settes det i gang fordi en eller annen maskin ikke får svar fra Master Browser.

Browservalg foregår i flere omganger. I hver enkelt av disse rundene vil alle maskinene sende ut broadcast datagrammer med election request. Disse pakkene inneholder også informasjon om avsenderens kvalifikasjoner (f.eks. Type operativsystem) og beskjed om at det foregår et valg akkurat nå. Dersom mottager er bedre kvalifisert bør den også delta i valget. Når avsenderen av et slikt datagram får svar fra en bedre kvalifisert maskin vil den trekke seg fra valget. Så skjer det samme igjen med utgangspunkt i den nyere maskinen. Slik fortsetter det til det bare er en potensiell Master Browserkandidat igjen. Nå vil den sende ut datagrammer 4 ganger, uten å få svar fra en bedre kvalifisert maskin, før den endelig bestemmer seg for at den har vunnet og sender beskjed om dette ut på nettverket. Derefter vil den velge backup browser(e) fra de som nesten vant valget.

Det er flere ting som avgjør hvor kvalifisert en maskin er til å bli Master Browser:

• Om den nylig har tapt et valg.
  Hvis den har det, vil den automatisk bli diskvalifisert.

• Hvilken versjon den kjører av valgprotokollen.

• Valgkriterier, hovedsaklig operativsystemets versjon (Dessuten, hvis den allerede er backup vil den ha større sjanse for å vinne valget).
  Det er vanligvis valgkriteriet som er avgjørende.

• Hvor lenge systemet har vært oppe.

• NetBIOS navn.

Det er to deler av valgkriteriene. De forskjellige elementene gis en verdi (poeng) og den som ender med høyest sum vil vinne.
De to delene av valgkriteriene og verdiene deres er:

Operativsystemets rolle:

Computerens arbeidsoppgaves rolle:

Operativsystemet vurderes først. Dette er fordi det er ønskelig at domenekontrolleren har rollen som Master Browser. Dersom det ikke er noen domenekontroller vil en Windows NT/2000/XP vinne over Windows 9x som igjen vil vinne over en WfW maskin.

Det er bare dersom det er delt førsteplass efter vurdering av operativsystem at maskinens rolle i nettverket vurderes. En og samme maskin kan ha flere roller og da vil poengene legges sammen og gi den bedre sjanse for å vinne et valg.

Det er to roller her som bør få litt mer forklaring, nemlig «preferred master» og «running master». Preferred master er en maskin som nettverksadministratoren har bestemt at hun vil at skal vinne disse valgene. Å sette en maskin som «preferred master» gjør vi ikke lenger, det forsvant efter Windows 9x. Tidligere ble dette satt opp i kontrollpanel – nettverk. Dette ble brukt i P2P nettverk.

Hvis du har lyst til å se om din maskin er Master Browser i et nettverk bruker du kommandoen: nbtstat -a maskinnavn.

Windows autentisering:

Under Windows 9x var det lite sikkerhet. Passord på 9x maskiner var ikke der for å hindre at noen kunne bruke maskinen, uten tillatelse. Hvis du ikke tror meg så kan du prøve å trykke på «Esc» knappen på tastaturet på en 9x maskin når du får dialogboksen for brukernavn og passord efter at du har startet maskinen. Det ble brukt til å få tilgang til en fil med Windows nettverkspassord og passord til delte ressurser. Denne filen opprettes når en bruker logger på for første gang og blir lagret i
%system root%, vanligvis vil det være C:\windows. Filen vil få brukernavnet som navn, og ekstensjonen .pwl f.eks. C:\windows\sarah.pwl. Denne filen er kryptert og det er brukerens passord som er krypteringsnøkkelen. Krypteringen er ikke særlig kraftig og det er derfor ikke vanskelig for en dreven cracker å fiske ut nettverkspassord. Dette er en sikkerhetsrisiko.

Windows autentisering i et domene:

Arbeidsgrupper er ikke den foretrukne måten å sette opp et Windows nettverk. Det fungerer bare i små miljøer hvor brukerne kjenner og stoler på hverandre. Det er sikrere å sette opp et domene, et nettverk hvor pålogging og autentisering foregår sentralt.

Illustrasjon 1-5: NT domenemodell.

Domenekontrollere:

En domenekontroller i et Windows domene, eller for den saks skyld en Network Information Server (NIS) i et Unixnettverk, har til hovedoppgave å vedlikeholde en database med oversikt over brukere og deres passord samt hvilke ressurser i nettverket den enkelte bruker skal ha tilgang til. Det inkluderer hvilken type tilgang; f.eks bare lesetilgang eller rett til å endre (skrivetilgang) en fil. Dessuten kjører domene­kontrolleren tjenester (services) som gjør det mulig benytte disse restriksjonene og rettighetene i nettverket uten å måtte oppgi nye passord for hver gang brukeren kobler seg til en ny delt ressurs.
Domenekontrollerens oppgaver er hovedsaklig knyttet til sikkerhetsspørsmål, altså tilgangsrettigheter og autentisering av brukere. Det siste foregår vanligvis ved bruk av en brukernavn og passordkombinasjon. Tjenesten som vedlikeholder databasen i et Windows domene heter Security Account Manager (SAM).

Windows NT sikkerhetsarkitektur er sentrert rundt Security IDentifiers (SID) og Security Access Lists (ACL). Security Identifiers representerer objekter i et NT domene. Disse inkluderer, men er ikke begrenset til, brukere, grupper, computere og prosesser. En SID er normalt i ASCII format og består av flere felt som er adskilt med bindestrek. En typisk SID kan se slik ut:

S-1-5-21-1638239387-7675610646-9254035128-545

Den delen av SID som starter med «s» og helt frem til den bindestreken som står lengst til høyre identifiserer domenet. Tallet som står til høyre for den siste bindestreken kalles en relative identifier (RID) og er et unikt nummer i domenet som identifiserer brukeren, gruppen, datamaskinen, prosessen eller et annet objekt.
I et Unixnettverk vil RID være analogt til UID (User IDentifier) og GID (Group IDentifier). Det samme gjelder Linux.
Forutsatt at det brukes NTFS filsystem kan man sette rettigheter på enkeltfiler og gjøre dem tilgjengelige for et bestemt utvalg av brukere. I dette tilfellet er Windows SID et mer fleksibelt system enn UID og GID i Unix og Linux systemer. Bruk av ACL blir stadig vanligere i Unix og Linuxsystemer.

Autentisering:

Når en bruker logger på et Windows NT domene må hun skrive inn et brukernavn og et passord. En forbindelse opprettes mellom klienten og domenekontrolleren og brukernavnet og passordet blir kontrollert for å se om det er gyldig. Til dette benyttes en kryptert forbindelse, en protokoll som kalles Named Pipes. Domenekontrolleren sender tilbake en SID som klienten bruker til å generere et Security Access Token (SAT). En slik SAT er bare gyldig for en pålogging og bare i domenet den gjelder. Det går an å få den til å gjelde i andre domener også, da opprettes en såkalt trust mellom domenene, men det skal vi ikke gå inn på i denne omgang. Når brukeren har fått sin SAT er hun logget på og bruker sin SAT til å bli autentisert i alle delte ressurser. Man kan tenke på en SAT som en nøkkel som åpner porten til en delt mappe eller printer.