Slutteksamen in115 Nettverksdrift (bokmål) Svarskisse: Løsningsforslag

Slutteksamen in115 Nettverksdrift (bokmål) Svarskisse: Løsningsforslag Dato: 11. Mai 2004 tidsrom: kl. 0900 1100 Hjelpemidler: Formelsamling (ett ark) og kalkulator (tomt minne) Oppgaven har fem (5) oppgaveark. Les dette før du begynner: Karakter på denne slutteksamen gis som bokstavkarakter (A-F, der F er stryk). Karakteren teller 1/3 av sluttkarakter i kurset. Alle spørsmål skal besvares. Det er mange små spørsmål, så du må gi korte og presise svar. Forklar resonnementet, spesielt hvis du er usikker på hva du skal svare! Lykke til! 1. Forklar hvorfor det i visse driftssituasjoner kan være aktuelt å se på Handles og DLL som en kan se i Windows-verktøyet ProcExp. Diskuter fordeler og ulemper med bruk av sentralt lager for lagring av DLL (for eksempel på en NFS- eller Sambatjener). Svarskisse: Initielt i svaret beskrives hva Handles og DLL er i korte ordelag. Med Handles ser en blant annet filer som prosessene har åpnet. DLL derimot er filer som inneholder rutiner prosessen bruker under kjøring. En prosess kan ha store startvansker hvis DLL og/eller andre filer ikke kan åpnes som ønsket. Underveis kan DLL lastes inn, og ulike filer aksesseres. ProcExp gir da info om dette som er viktig i feilsituasjoner. Dynamiske bibliotek inneholder objekt (kode, data) som brukes i ulike program. Når prosessene etterspør objekt som ikke er i RAM må de hentes fra biblioteket og kopieres til RAM. Hvis dette skjer ofte og/eller det er langt til biblioteket (som ligger sentralt, hos en filservere) vil kjøretiden gå opp. Brukeren kan bli misfornøyd og rapportere om at data n er treg. Fordel med sentralt lagrede DLL er at oppdatering skjer ett sted, backup likens. Sikring av DLL (mot endring, fjerning) skjer ett sted. En kan spekulere i at sentral lagring gir hyppigere versjonskonflikter, men det avhenger av hvordan man navngir filene eventuelt, hvor man plasserer de sentralt. Uansett er det et viktig moment som med fordel nevnes. 2. Forklar hva YP/NIS er. Legg vekt på å skille mellom tjeneste og programvare. Forklar hva som er driftsmessige fordeler og ulemper med YP. Hva var problemet med broadcast-basert søk i YP? Svarskisse: YP betyr Yellow Pages og er en katalogtjeneste for UNIX. Et sett av programmer utviklet for Linux og andre operativsystem, implementerer YP, eksempelvis ypbind, ypset, ypwhich, ypserv og ypcat. For Windows finnes egne programmer som implementerer YP. Som tjeneste representerer YP generelt sett en katalogtjeneste, et oppslagsverk for et IT-system. Det vanligste er at info om brukere legges til YP. I tillegg kan nevnes grupper, postalias og egentlig alt mulig annet, den er veldig skreddersy-bar. Fordelen med YP er at felles informasjon kan legges sentralt og vedlikeholdes derfra, på ett sted. Problemer kan være at avstanden fra klient til tjener øker hvilket øker svartiden ved oppslag. 1

Klienter kan settes til å søke seg frem til en YP-server istedetfor å kontakte fast avtalte servere. Dette er risikabelt da en kan få svar fra en uvedkommende som imiterer YP-tjeneste men gir fra seg ukorrekte og kanskje villedende svar. 3. I kurset har vi brukt Putty som klient for å logge inn på andre maskiner. På tjenersiden er det vanligvis sshd som betjener Putty. Se på vedlagte manualside og besvar følgende spørsmål Hva er en port, og hvilken port lytter sshd på? Tror du dette er av type UDP eller TCP? Grunngi svaret. Svarskisse: En port er et kontaktpunkt for nettkommunikasjon. Mottatte IP-pakker skal styres videre gjennom transportlaget, til en ventende applikasjon. Portnummer brukes til dette, slik at korrekt applikasjon mottar pakken. To parter som vil kommunisere må derfor kjenne porten hos den andre for å treffe rett når pakker sendes gjennom Internettet. Fra manualsiden ser en at sshd bruker port 22. Dette må være en TCP-port da TCP garanterer feilfri overføring, hvilket vil være viktig for denne type tjeneste (terminaltrafikk). Brukere vil ikke like at deres tastetrykk sendes med feil, som eksempel. En kan si at TCP gir sikker forsendelse, men dette er sikkerhet i form av at en er garantert at mottaker ender opp med feilfritt materiale. Selv om sshd tilbyr sikker kommunikasjon, er dette en annen type sikkerhet, nemlig sikkerhet mot innsyn. Hvis en ikke var bekymret for at nettet kunne droppe pakker eller skape bitfeil, kunne en gjerne brukt UDP som transport. Anta at du ikke har tilbudt denne tjenesten tidligere. I en testfase må du prøve deg frem. Forklar hvordan du vil starte sshd for å få mest mulig informasjon om det som skjer i denne fasen Svarskisse: sshd kan startes med opsjon debug (-d). Denne gir ulike grader av detalj. For mest mulig detaljering startes sshd som -d 3. For kontroll med at innstillingene er korrekt satt opp (syntaktisk) kan en bruke opsjon -t som ikke starter server, men kontrollerer syntaks. Hvis en vil ha kjøreinformasjon på skjerm kan en starte med opsjon -D som gjør innsynet lettere. En kan drive pakkefangst som gir tilleggsinfo ved problematisk oppstart. Feil kan ligge hos klient, og redskap som ProcExp og klientlogg kan da brukes. List opp alle filer som du ser er involvert For hver fil vurder om filsperre kan være årsake til at serveren eventuelt ikke starter som forventet Svarskisse: Hvor mange filer som oppdages avhenger av graden av detaljering; en mappe er også en fil, en prosess er startet ut fra en fil, men vi holder oss til denne listen og kommenterer underveis (om sperreverket vil gi problemer blir en vurdering basert på erfaring): Filen /etc/rc.d/sshd nevnes først. Dette programmet vil ved boot starte sshd. Dette kan den gjøre feil slik at sshd ikke starter, men det vil da ikke være sperreverket på /etc/rc.d/sshd som er feil. 2

Filen /usr/sbin/sshd er programmet sshd i seg selv, og sperreverket på denne filen kan nekte ovennevnte program å starte sshd. Filen /etc/ssh/sshd config inneholder innstillingene for sshd. Manualsiden sier at sshd ikke vil starte hvis denne filen ikke kan åpnes. Filen /etc/motd skal bare leses, eventuelle lesesperrer bør ikke forhindre server fra å starte. Filen $HOME/.hushlogin vil, hvis den finnes, lage en støyfri innlogging, og påvirker ikke serverens start hvis filen eventuelt skulle være sperret. Filen /etc/nologin vil hvis den finnes, nekte vanlige brukere innlogging, men da er det ikke sperreverket som er problemet. Filen skal imidlertidig være lesbar for alle. Filen $HOME/.ssh/environment inneholder miljøoppsett for brukerens innlogging. Hvis den ikke kan leses kan miljøet settes opp feilaktig, selv om det ikke nødvendigvis betyr at brukeren ikke får logget inn. Filen $HOME, det vil si brukerens hjemmeområde; mapper er også filer. Filene $HOME/.ssh/rc og /etc/ssh/sshrc startes med programmet /bin/sh. Hvis de ikke kan leses vil nok innlogging skje, men miljø kan bli feil satt opp. Hvis filen /bin/sh er sperret mot bruk vil nok innlogging likevel kunne skje. Brukerens skall skal startes. Hvis dette er sperret mot oppstart, vil brukeren ikke bli videre betjent, ikke få et kommandoprompt. Filen /var/run/sshd.pid er ikke viktig. List opp alle muligheter til logging, nevn filnavn og innhold hvis de er nevnt. I testfasen slår du på all logging, og lar dette forbli påslått under vanlig produksjon Si kort fordeler og ulemper du mener full logging kan ha. Svarskisse: Med ovennevnte debugflag bestemmes detaljeringen av logging. Disse sendes vanligvis til systemlog, men kan overstyres til standard error. Ingen spesielle filnavn er nevnt. Med full logging i produksjonsfasen, vil sjansen for fullt lager øke. I og med at meldinger logges til systemlog er det ikke sshd som direkte berøres av dette problemet, men ved feilsøking vil jo loggene være mangelfulle. Fordelen med full detaljering er at det gir bedre innsikt i intrikate hendelser, men samtidig kan en lettere få problemer med å se helheten, en ser ikke skogen på grunn av alle trærne. hva menes generelt sett med begrepet autentisering (authentication) som er nevnt endel ganger i manualsiden? Svarskisse: Med autentisering menes at systemet blir overbevist om at klienten har (eller ikke har) den identitet som den utgir seg for. Etter autentisering brukes denne identitet for videre tilgangskontroll. Autentisering er ikke det samme som tilgangskontroll. Mekanisme for autentisering er eksempelvis passord, fingeravtrykk eller personlige smartkort. 3

4. Anta at en gitt maskin av helt spesielle årsaker, til enhver tid bare kan ha en enkelt bruker innlogget via SSH. Hvis Anne er innlogget (for eksempel via Putty) kan ingen andre logge seg inn før Anne logger ut. Beregn snitt ventetid for å få logget seg inn, basert på M/M/m. Brukerne er i snitt inne i 10 minutt av gangen. Hver time er det i snitt 5 brukere som vil forsøke å starte tjenesten. Skriv utregningene inn i besvarelsen slik at det er lett å se hvordan du har tenkt Svarskisse: Det gir m = 1, da det bare er en som kan arbeides med. λ = 5 og µ = 6, tidsenhet er time. Det gir ρ = λ/mµ = 5/6. Sjansen for ingen jobber i systemet er p 0 = (1 + ρ/(1 ρ)) 1 = (1 + 5) 1 = 1/6. Sjansen for at noen venter er (det greske tegn): Snitt ventetid (punkt 16) blir da G = [ρ/(1 ρ)]p 0 = 5p 0 = 5/6. E[w] = G/[6(1 ρ)] = G/1 = 5/6. 5. Som fortsettelse på forrige oppgave: Du setter opp to ekstra maskiner med samme spesielle egenskap, at man på en maskin til en hver tid maksimalt kan ha en enkelt SSH-innlogget bruker. Anta at den opprinnelige maskinen hadde pålitelighet lik p 1 =.75. Hva er minimum krav til de nye for at påliteligheten totalt sett skal bli bedre enn 0.9? Lag gjerne en illustrasjon som viser tankegangen, spesielt hvis du ikke får til beregningene. Svarskisse: Det er tilsammen tre maskiner, og kravet er at P.9. Det skal regnes ut x, påliteligheten til hver av de to ekstra maskinene (som hver for seg, antas å være like pålitelig). Her skal en minst angi at dette er et parallellt system. Formel skal angis. Det blir for enkelt med et svar om at en trenger to maskiner som har p = 1.0, selv om en naiv tolkning tillater dette slike maskiner finnes ikke. Det man normalt leter etter er den rimeligste utvei som tilfredsstiller kravet. Derfor antas at de to ekstra er likens, og at vi skal finne minstekravet. Med prøving og feiling finner en etterhvert svaret, men en eksakt beregning er bedre:.9 P = 1 (1 p 1 )(1 x)(1 x).9 1 (1.75)(1 x) 2.1.25(1 2x + x 2 ) x 2 2x +.6 0.4 1 2x + x 2 4

Dette er uheldigvis en andregradsligning med parametre a = 1, b = 2, c =.6. Røttene kan beregnes til: x 1,2 = b ± b 2 4ac 2a = ( 2) ± ( 2) 2 4(1)(.6) 2(1) = 2 ± 1.6 2 = 1 ± 0.5 1.6 Da x er sjansen for at en maskin virker må den være mellom 0 og 1. Den eneste av de to røttene som kan brukes er da x = 1 0.5 1.6 =.367. De som har illustrert korrekt og iallefall satt opp ligningen korrekt, får delvis rett her. Full uttelling krever at røttene er beregnet. 5

SSHD(8) NetBSD System Manager s Manual SSHD(8) NAME sshd - OpenSSH SSH daemon SYNOPSIS sshd [-deiqtd46] [-b bits] [-f config_file] [-g login_grace_time] [-h host_key_file] [-k key_gen_time] [-o option] [-p port] [-u len] DESCRIPTION sshd (SSH Daemon) is the daemon program for ssh(1). Together these programs... provide secure encrypted communications between two untrusted hosts over an insecure network. The programs are intended to be as easy to install and use as possible. sshd is the daemon that listens for connections from clients. It is normally started at boot from /etc/rc.d/sshd. It forks a new daemon for each incoming connection. The forked daemons handle key exchange, encryption, authentication, command execution, and data exchange. This implementation of sshd supports both SSH protocol version 1 and 2 simultaneously. sshd works as follows.. Command execution and data forwardin If the client successfully authenticates itself, a dialog for preparing the session is entered... Finally, the client either requests a shell or execution of a command. The sides then enter session mode. In this mode, either side may send data at any time, and such data is forwarded to/from the shell or command on the server side, and the user terminal in the client side. When the user program terminates... the server sends command exit status to the client, and both sides exit. sshd can be configured using command-line options or a configuration file. Command-line options override values specified in the configuration file. sshd rereads its configuration file when it receives a hangup signal, SIGHUP, by executing itself with the name it was started as, i.e., /usr/sbin/sshd. The options are as follows: -d Debug mode. The server sends verbose debug output to the system log, and does not put itself in the background. The server also will not fork and will only process one connection. This option is only intended for debugging for the server. Multiple -d options increase the debugging level. Maximum is 3. -e When this option is specified, sshd will send the output to the standard error instead of the system log. -f configuration_file Specifies the name of the configuration file. The default is 6

/etc/ssh/sshd_config. sshd refuses to start if there is no configuration file. -g login_grace_time Gives the grace time for clients to authenticate themselves (default 600 seconds). If the client fails to authenticate the user within this many seconds, the server disconnects and exits. A value of zero indicates no limit. -o option Can be used to give options in the format used in the configuration file. This is useful for specifying options for which there is no separate command-line flag. -p port Specifies the port on which the server listens for connections (default 22). Multiple port options are permitted. Ports specified in the configuration file are ignored when a command-line port is specified. -q Quiet mode. Nothing is sent to the system log. Normally the beginning, authentication, and termination of each connection is logged. -t Test mode. Only check the validity of the configuration file and sanity of the keys. This is useful for updating sshd reliably as configuration options may change. -D When this option is specified sshd will not detach and does not become a daemon. This allows easy monitoring of sshd. CONFIGURATION FILE sshd reads configuration data from /etc/ssh/sshd_config (or the file specified with -f on the command line). The file format and configuration options are described in sshd_config(5). LOGIN PROCESS When a user successfully logs in, sshd does the following: 1. If the login is on a tty, and no command has been specified, prints last login time and /etc/motd (unless prevented in the configuration file or by $HOME/.hushlogin; see the FILES section). 2. If the login is on a tty, records login time. 3. Checks /etc/nologin; if it exists, prints contents and quits (unless root). 4. Changes to run with normal user privileges. 5. Sets up basic environment. 6. Reads $HOME/.ssh/environment if it exists. 7. Changes to user s home directory. 8. If $HOME/.ssh/rc exists, runs it; else if /etc/ssh/sshrc exists, runs it 9. Runs user s shell or command. 7

FILES /var/run/sshd.pid Contains the process ID of the sshd listening for connections (if there are several daemons running concurrently for different ports, this contains the process ID of the one started last). The content of this file is not sensitive; it can be world-readable. /etc/nologin If this file exists, sshd refuses to let anyone except root log in. The contents of the file are displayed to anyone trying to log in, and non-root connections are refused. The file should be world-readable. $HOME/.ssh/environment This file is read into the environment at login (if it exists). It can only contain empty lines, comment lines (that start with # ), and assignment lines of the form name=value. The file should be writable only by the user; it need not be readable by anyone else. $HOME/.ssh/rc If this file exists, it is run with /bin/sh after reading the environment files but before starting the user s shell or command. The primary purpose of this file is to run any initialization routines which may be needed before the user s home directory becomes accessible; This file should be writable only by the user, and need not be readable by anyone else. /etc/ssh/sshrc Like $HOME/.ssh/rc. This can be used to specify machine-specific login-time initializations globally. This file should be writable only by root, and should be world-readable. NetBSD 1.6 September 25, 1999 9 8