Att öppna en fil på en server eller skriva ut ett dokument på en nätverksskrivare är något som användare gör utan att ägna en tanke åt hur det går till. Bakom kulisserna är det en gammal trotjänare som ser till att allt fungerar som det ska: protokollet server message block, smb.

Enkelt uttryckt beskriver smb hur en klient ska kunna skicka en begäran till en server och hur servern ska svara på den. Först kommer klienten och servern överens om vilken dialekt de ska använda (mer om det senare). Sedan öppnas en session mellan klient och server där klienten autentiseras och därefter är det bara att börja skicka data mellan klient och server.

För att kunna gå på djupet och se vad som händer under den här processen behöver vi ta en titt på hur smb-paketen ser ut. Paketen består av ett huvud (header), ett parameterblock och ett datablock. Hur huvudet ser ut syns i bilden på nästa sida.

Huvudet börjar med protokollfältet som visar att det är en smb-sändning. Sedan följer kommandofältet som visar vilken typ av smb-trafik det rör sig om.



Välpaketerat. Så här ser ett huvud (header) till ett smb-paket ut i detalj. All information som behövs för att leda paketen rätt ryms i knappt ett dussin fält.



Fram och tillbaka. En smb-sändning behöver gå igenom tre faser innan någon nyttoinformation kan börja skickas mellan klient och server.


Flaggor i fält
Statusfältet innehåller fel­koder som visar vad som har gått fel om en sändning skulle misslyckas. Därefter dyker flaggorna upp i två fält. Det första fältet är en byte stort och används för att beskriva om det är en begäran eller ett svar på en begäran som skickas. Det andra fältet är på två byte och visar om det är gamla eller nya instruktioner som används.

”Smb är så gammalt att

det från början är anpassat för

16 bitars Dos och OS/2.”


Smb-protokollet är så gammalt att det från början är anpassat för 16 bitars Dos och OS/2 med en ursprunglig uppsättning av exempelvis felkoder.

När Microsoft gick över till 32-bitarssystem i och med NT lade man till en ny uppsättning koder som utnyttjar alla 32 ­bitarna. Bitarna i Flags 2-fältet används för att tala om vilken uppsättning som ska användas.


Stopp för kidnappare
Extra-fältet används främst för att signera paketen med hjälp av kryptering. Det här är ett enkelt sätt att undvika att obehöriga ”kidnappar” en förbindelse och kommer åt resurser på nätet som de inte ska ha tillgång till.

Till sist har vi de fyra identifikationsfälten tid, pid, uid och mid. Uid står för user id. När ­klienten har loggat in skapar servern ett user id som den klienten behåller under hela sessionen. Det visar att klienten har blivit godkänd och att den inte behöver logga in igen.

Process id, pid, identifierar en viss process så att det ska gå att se vilka klienter som har initierat­ vissa processer.

Tree id, tid, används under Tree Connect och anger vilka partitioner som klienten ska vara ansluten till. Mid är multiplex id som klienten använder för att hålla reda på alla förfrågningar den har skickat till en server men ännu inte fått svar på.


Information om dialekten
Efter huvudet kommer para­meterblocket som bara består av två fält: Word Count och Words. Här läggs värden som sedan används som parametrar för negotiate protocol-trafiken. Det kan exempelvis vara vilken dialekt servern kan använda ­eller eventuella andra begränsningar på servern som klienten måste ta hänsyn till.

Datablocket innehåller förstås de data som skickas. Här kan servern skicka data som klienten har begärt att få läsa och klienten kan skicka över data som ska skrivas till servern.

Med den här informationen som bakgrund kan vi titta lite mer i detalj på vad som händer i processen. Först skickar klienten en negotiate protocol-begäran till servern, vilket den gör ­genom att ange att det rör sig om negotiate i kommandofältet i huvudet. Den sätter också en bit i flaggfältet till 0 för att visa att det är en begäran. Övriga fält är tomma (eller snarare fyllda med nollor), med undantag för datablocket. Här anger klienten vilka dialekter den bemästrar. Det finns ett gäng dialekter, till exempel core protocol (som är originalprotokollet), cifs och Samba.


Svar från servern
Servern tar emot klientens begäran och skickar tillbaka ett svar, negotiate protocol response. Här ingår förstås svaret på vilken dialekt som ska användas, men servern lägger även in en mängd annan information. Det mesta av informationen kläms in i parameterblocket, men en del läggs i datablocket.

Att gå igenom all information som servern kan skicka över har vi inte plats för här, men vill du veta mer kan du kika på sajterna i rutan ”Så går du vidare” på sidan 72. Ett exempel är securitymode där servern använder fyra bitar för att ange hur den kan hantera autentiseringen. Servern kan exempelvis visa om den klarar message autentication code-identifiering (mac), om den rent av kräver mac-identifiering eller om den godkänner okrypterade lösenord. Den anger också om den använder user level eller share level för säkerheten.


Maxlängd för meddelande
Andra parametrar som servern kan sätta anger bland annat vilken maxlängd ett meddelande får ha och hur många obesvarade förfrågningar en klient får ha. Blir det för många sådana kan servern bli alltför belastad. Servern bestämmer också en sessionsnyckel som ska användas av klienten för att visa att det är just den här sessionen trafiken gäller.

När det här är avklarat och klient och server är överens om grunderna för kommunikationen är det dags att sätta upp själva sessionen. Det viktigaste här är att klienten ska logga in på servern.

Processen börjar med att klienten skickar en session setup-begäran. Här skickas bland ­annat information som hur ­stora meddelanden klienten kan ta emot och hur många utstående förfrågningar den tillåter (det måste vara färre än serverns ­totala antal). Dessutom verifierar den sessionsnyckeln så att servern är säker på att de är överens om vilken session det här handlar om. Det är i stora delar samma information som servern skickade över i sitt ­negotiate protocol-svar.


Versaler eller gemener
Det finns också en del information i datablocket som klienten kan modifiera. Den kan exempelvis ange om den vill skilja på versaler och gemener i lösenorden och vilket operativsystem som används.

Det är själva autentiseringen som är det viktigaste i det här steget. Hur den går till skiljer sig lite åt beroende på vilken dialekt som används, men idén är ungefär densamma. Här använder vi Lan Manager challenge/response-metoden som exempel.
Inloggningsprocessen börjar med att servern redan i negotiate protocol-svaret genererar en slumpmässig teckensträng. Den läggs in i Encryption_Key-fältet i datablocket i negotiate protocol response. Som namnet antyder kan den sedan användas som krypteringsnyckel i exempelvis en des-kryptering.


Båda har lösenordet
Både servern och klienten har användarens lösenord. Det är en teckensträng som bildats av en hashfunktion som använder lösenordet och den slumpmässiga sträng som servern genererade som ingångsvärden.

I stället för att skicka lösenordet i klartext över nätet har vi skapat en till synes slumpmässig teckensträng. Den skickas över till servern som har en databas som kopplar ihop alla användare med deras respektive lösenord i form av ett hashvärde. Servern tar användarens hashvärde och den slumpmässiga teckensträngen den genererade till att börja med och kör dem genom krypteringsalgoritmen. Om resultatet blir samma sträng som klienten skickade över har autentiseringen lyckats och klienten loggas in.

Klienten skickar då en tree connect-begäran där den anger vilken nätverksadress den vill nå. Servern kontrollerar att adressen verkligen finns och att klienten har rättighet att komma åt den. Sedan skickar servern ett tree connect-svar. Om allt är okej kan klienten nu komma åt filerna på servern.

Tree connect innehåller bara en handfull parameter- och data­fält. Den som är mest intressant är path i datablocket. Här anges adressen till den resurs klienten vill nå. Normalt är det en sökväg som \\Nod\Share som visar exakt vilken server och vilken partition på den ­servern som klienten vill nå.


Tjänster som erbjuds
När servern får en tree connect-begäran svarar den med ett tree connect-svar. Även här finns en handfull val i parameter- och datablocket. De mest intressanta är service och nativefilesystem.

Service anger vilka tjänster servern kan erbjuda. A: betyder att den fungerar som filserver, lpt1 visar att den kan hantera utskrifter och comm betyder att det går att nå andra enheter via portar.

Nativefilesystem är det fält där servern lägger informationen om vilka filsystem den ­använder, oftast fat och ntfs.


Ett pratigt protokoll
Nu är det bara att börja skicka och ta emot information via smb genom att skicka kommandon som talar om för servern vad du vill göra. Ett problem med smb är att det finns så många kommandon (opcodes) och det är svårt att hålla reda på alla. Vad Create_new och Delete-directory gör är inte så svårt att lista ut, men det är knepigare att intuitivt inse nyttan med Trans2_set_fs_information och Trans_mailslot_write.

Smb kan också vara något av en prestandatjuv på nätet och det anses vara ett ”tjattrigt” protokoll. Det krävs mycket information fram och tillbaka mellan server och klient, vilket innebär att även enkla åtgärder, som att öppna en fil, genererar en hel del trafik på nätet.

När det var dags för Microsoft att släppa Windows Vista bestämde sig därför företaget för att göra om smb ordentligt. Resultatet blev smb 2, som dök upp i Vista 2007 och sedan även lades in i Windows Server 2008.


Från 100 till 19 kommandon
Det tydligaste sättet att åskådliggöra skillnaden mellan smb och smb 2 är att titta på antalet kommandon. I smb finns det över 100 kommandon medan det i smb 2 bara finns 19. Ändå klarar smb 2 av allt som smb klarade och mer därtill. Det Microsoft gjorde var helt enkelt att slå samman kommandon som gör i stort sett samma sak till ett enda.

Den största fördelen med smb 2 är dock att prestanda kan förbättras. I smb 2 finns det till exempel mycket bättre funktioner för att packa ihop flera kommandon i ett paket och skicka många kommandon efter varandra utan att behöva vänta på svar från servern först. Det betyder att mängden trafik som smb genererar minskar betydligt, vilket förbättrar prestanda i nätet.

Dessutom kan smb 2 hantera större block när det läser och skriver filer. Då kan stora ­filer ­delas upp i färre fragment än med smb, och ju färre paket som behöver skickas, desto mer effektivt utnyttjas nätets kapacitet.


Fler användare och filer
Skalbarheten förbättrades också. Det går att låta varje server hantera fler samtidiga användare och antal öppna filer än i smb.

Trots att smb 2 har ett huvud som ser rätt annorlunda ut är det bakåtkompatibelt med smb. ­Under de närmaste åren kommer vi att få se en gradvis övergång till smb 2. Det protokoll som först dök upp för 25 år sedan kommer fortsätta att hantera fil- och skrivdelning i många år, om än i en lite nyare kostym.

Illustration & grafik: Jonas Englund

» Så går du vidare