DHCP

DHCP er ein protokoll for automagisk konfigurasjon av IP-adresser, nettmaske, gateway og ein del andre parametrar i eit nettverk. DHCP består av ein DHCP-server, og klienter. DHCP er ein ikkje-rutbar protokoll, så om ein vil ha ein DHCP-server felles for fleire nett må ein i tillegg ha ein spesiell type DHCP-server, såkalla DHCP relays.

DHCP er ein relativt enkel protokoll, som ikkje går over IP (naturleg nok, sidan IP krever ei IP-adresse). Når ein host vil ha info via DHCP sender den ut ein DHCP Discovery-pakke, som broadcast. Det vil sei at alle maskiner på nettet vil motta den, men kun DHCP-servarar vil svare på den. Alle DHCP-servarar som mottek den vil sende eit svar. Dette går også som broadcast. Imidlertid vil kun den serveren som sendte svar først bli brukt, resten av svara vil bli forkasta av klienten. For nøyaktig beskrivelse av discovery-prosessen er wikipedia om DHCP anbefalt lesning.

DHCP-serveren vil typisk gi klienten nettverksadresse, IP-adresse, broadcast, nettmaske og DNS-server. I tillegg kan den gi info om boot-tenarar, nytta for tynnklienter, dato, wins-tenarar m.m. For full oversikt over DHCP-options er IANA sin dokumentasjon gull verdt.

HTTP / WWW

HTTP er kanskje ein av dei få protokollane folk faktisk har eit forhold til, ettersom folk flest ser http://… i adressefeltet i nettlesaren dagleg. Men kor mange tenkjer over kva det faktisk er… HTTP, Hyper Text Transfer Protocol, er ein svært enkel, tilstandslaus protokoll. Med tilstandslaus meiner en at protokollen i seg sjølv ikkje tar vare på informasjon om kva som har skjedd tidlegare frå samme klient.

HTTP nyttar rein ASCII for requests, og ein typisk HTTP-request ser slik ut:

GET / HTTP/1.1
Host: www.bitsex.net

HTTP/1.1 200 OK
Date: Sat, 26 Apr 2008 15:31:22 GMT
Server: Apache/2.2.8 (Unix) PHP/5.2.5 mod_perl/2.0.4 Perl/v5.8.8
X-Powered-By: PHP/5.2.5
X-Pingback: http://bitsex.net/xmlrpc.php
Transfer-Encoding: chunked
Content-Type: text/html; charset=
X-Pad: avoid browser bug

297b

Først sender klienten sin request, som kan vere ein av dei typane som er lagde fram i RFC2616. Dei to mest brukte er GET og POST. Get er for å hente innhald frå tenaren, post for å sende innhald til tenaren. Etter at klienten har sendt sin request, og alle sine headers, sender den ei blank linje. Blank linje vil sei at serveren skal begynne å behandle requesten. Tenaren sender så protokollinfo og statuskode, HTTP/1.1 200 OK, som forklarer at den vil svare med protokollen HTTP/1.1, og statuskoden 200 OK, som faktisk bare betyr OK. Deretter kjem div. headers, som har varierande meining. X-* headers er ikkje offisielle HTTP-headers, og blir nytta til meir eller mindre tilfeldige føremål. Etter headers kjem ei blank linje, og deretter kjem innhaldet av fila, /, vi etterspurte.

Som du ser er HTTP rimelig enkel protokoll, som er lett å nytte seg av. Om du vil prøve, kan du nytte telnetklienten som er i dei fleste OS, eller laste ned netcat og nytte det. Opprett tilkopling mot port 80 på den sida du vil teste mot, og skriv noko liknande det i eksempelet. Bytt gjerne ut / med eit anna filnamn.

FTP

FTP er en eldgammel, arkaisk, protokoll fra tidlig 80-tal. Protokollen var laga for grunnleggande filoverføringer, og er i motsetning til HTTP ikkje tilstandslaus. Den støttar også enkel autentisering, haken der er at passordet går i klartekst, og kan sniffast av alle som har tilgang til nettverkseiningar langs path.

FTP har ein kontrollkanal, og ein eller fleire datakaneler. Kontrollkanalen blir brukt til å formidle kommandoar og statusrapport mellom klient og tenar, og blir oppretta når klienten koplar seg til port 21 på FTP-tenaren. Datakanalane blir brukt til å transportere filer og kataloglister mellom server og klient, og blir oppretta ved behov. Det finst to FTP-modusar: Aktiv og passiv modus. I aktiv modus opprettar klienten ein socket på ein dynamisk port, formidlar portnummer via kontrollkanalen, og venter på at tenaren skal kople seg til den porten. Etterkvart som fleire og fleire eininger vart plassert bak NAT og brannmurar fungerte dette dårlig, og ein kom opp med passiv FTP, der klienten er passiv. I passiv FTP opprettar serveren ein socket på ein dynamisk port, og gir beskjed til klienten om kva port den lyttar på.

DNS

DNS er protokollen som utfører oppslag av domenenamn. Når du taster inn www.bitsex.net i nettlesaren din, så slår nettlesaren opp kva IP www.bitsex.net har. Den får så et svar som inneheld IPen. DNS er en av dei få hierkaiske systema på Internet, og grunnen er enkel: det må ha ei sentral styring for å unngå vill-vesttilstander på nettet. Det er ikkje et hieraki nedfelt i lov, men i praksis. Øvst har ein 13 rot-DNS-tenarar, plassert rundt om i verden. Dei held styr på kven som har namnetenarar for dei ulike TLD i verden. Om du spør etter www.bitsex.net, vil forespørselen først bli sendt til ein av dei 13 rot-tenarane. Dei vil så svare at .net har den navneserveren. Din lokale DNS-server vil så spørje den nye serveren den fikk beskjed om, og slik vil det fortsettje inntil den har funne ein som svarer autorativt på at www.bitsex.net har IPen 83.149.117.6.

DNS blir transportert over både UDP og TCP, men UDP er den dominerande protokollen for DNS. DNS er ein av dei viktigaste protokollane, samtidig som det er ein protokoll svært få tenkjer på . Ein av dei mest brukte tenarane for DNS er Berkley Internet Name Daemon, BIND.

SSH / SCP / SFTP

SSH er ein protokoll som var designa for å gi eit sikkert alternativ til den aldrande rsh-protokollsuita, ei protokollsuite for fjerninnlogging mot UNIX-maskiner over internett. ssh er meir eller mindre drop in replacement for rsh, og scp for rcp. ssh-suita nyttar sterk kryptografi for å transportere passord trygt via åpne nett, og støttar ulike autentiseringsløysinger. Ei av dei meir populære er kryptografiske nøkler, som gjev passordlaus fjerninnlogging, som like fullt er trygg. ssh er i hovudsak nytta i UNIX/Linux-verda, sidan windows ikkje har lagt mykje vekt på eit godt shell. Om du som windowsbrukar støyter på dette, er putty ein av dei betre ssh-klientar for windows. På Mac og *nix er ssh stortsett alltid installert, så det er nok å fyre opp ein terminal og skrive ssh user@host.

SCP og SFTP er to andre protokollar i ssh-suita, som også bruker sterk kryptografi for autentisering. Medan ssh er laga for fjerninnlogging er scp laga for sikker kopiering av filer mellom ulike maskiner, og sftp som eit sikkert alternativ til FTP. For windows er ein av dei meir kjende sftp/scp-klientane WinSCP, som er gratis.

IP-adressa si oppbygning.

Ei IP-adresse er et 32-bits tall, det vil sei mellom 0 og 4294967295. For lesbarheta si skuld deler ein dette opp i 4 grupper på 8 bit per gruppe. 8 bit vil bli eit tal mellom 0 og 255. Om ein tar for seg IP-adressa 255.255.255.255 vil den skrivast slik:

IPen 192.168.10.2 blir då følgande:

Det er enklare for menneske å hugse 192.168.10.2 enn 11000000101010000000101000000010

Kva er ei nettmaske?

Opprinneleg var IP-adresser inndelt i ulike klasser, for ulike føremål. Denne er ein gått vekk frå i dag med CIDR – Classless Inter-Domain Routing. Dei opphavelege klassane var følgande:

1. Klasse A: 0 som MSB (Most Significant Bit, talla heilt til venstre i bitstringen over), 126 forskjellige klasse A-nett, 16777214 adresser per nett. Opphaveleg 0.0.0.0-127.255.255.255
2. Klasse B: 10 som MSB, 16382 nett og 65534 adresser per nett. Opphaveleg 128.0.0.0-191.255.255.255.
3. Klasse C: 110 som MSB, 2097150 nett, og 254 adresser per nett. Opphaveleg 192.0.0.0-223.255.255.255.

IPer over 223 var reservert til ting som multicast og forskning. For kvar av klassane har ein eit privat nett. Eit privat nett er eit som ikkje blir ruta av en vanlig ruter, og som ikkje kan brukast til å snakke med andre maskiner på internett. Dei eksisterer med andre ord mange plasser, og treng kun vere unike innan eit nett. Desse adressene er følgande:

• 10.0.0.0/8 som er klasse A-nett.
• 172.16.0.0/12 som er klasse B-nett.
• 192.168.0.0/16 som er klasse C-nett.

Full oversikt over reserverte adresser finner en i RFC3330. Så kom noko som heiter CIDR, som er såvidt nemt over. Etterkvart som IP-adressene vart tatt i bruk, innsåg ein at det var veldig skjelden ein hadde bruk for så enorme nett som A-klasse, og det var hensiktsmessig å dele opp desse. Den observante vil legge merke til at det over står ting som 192.168.0.0/16. Den skråstreken er skiljeteikn mellom IP og nettmaske. Nettverksmaska maskerer IPen, og gir maskina beskjed om kva IP-adresser som eksisterer i samme nett som seg sjølv, og kva IPer den må gå via en ruter (ofte kalt gateway eller GW på kortform). Tallet etter skråstreken seier kor mange bits som skal vere 1 i nettmaska, om du skriv den ut på samme form som IPen over. Om vi tar for oss eit kjapt eksempel med IPen 192.168.10.2 og nettmaska 255.255.255.0 ser vi følgande:

Dei 24 første bits i nettmaska er 1, dei siste 8 er 0. Det stemmer med 255.255.255.0. Det seier då maskina at dersom den skal nå ei IP-adresse der alle einaste forskjellen ligg innanfor nettmaska, så treng den ikkje gå via en ruter. IPen 192.168.10.127 ligg innanfor nettmaska. 192.168.11.1 ligg utanfor nettmaska, og maskina må sende pakken til sin gateway istadenfor å sende den direkte. Om ein skal jobbe litt med slikt er ipcalc veldig nyttig verktøy for å visualisere det og konvertere mellom notasjoner. Nettmaska seier med andre ord kor mange IPer du kan ha i samme nett, og som kan kommunisere direkte med kvarandre uten å måtte gå vegen om ein ruter.

UDP og TCP

Ein har to protokoller på toppen av IP: TCP og UDP. UDP er ein tilstandløs protokoll, der serveren sender pakker, uten å vente på svar fra klienten. UDP blir derfor brukt til ting som streaming, DNS og NTP, der det er (relativt) uviktig om en bestemt pakke kjem fram eller ikkje. Om en UDP-pakke kjem vekk eller blir skada, blir det berre ignorert. Klienten gir ikkje beskjed om det til serveren. TCP blir brukt til nesten alt anna, der det er viktig at pakker kjem fram heile, og i rett rekkefølge. For kvar TCP-pakke som blir sendt vil serveren få et svar – ACK – på at pakken er komt fram heil og uskada. Det gjer at pakker som blir skada eller ikkje kjem fram blir sendt på nytt.

Kort om porter

En port i internett-verdenen er eit tall mellom 0 og 2^16-1, eller 0 og 65535. Dette seier kva lyttande program på mottakarmaskina som skal svare. Det er ei offisiell portliste, velikeholdt av IANA, som seier kva tenester ein kan [b]forvente[/b] å finne på ein gitt port. Det er ingenting i vegen for å kjøre ting på andre porter enn det som er spesifisert som standard, men då må typisk klienten oppgi kva port han vil kople seg til. Når du trykker inn http://vg.no i nettleseren din kontakter nettleseren vg.no på port 80, som er porten tildelt protokollen http. Om du bruker ein e-postklient vil den typisk nytte seg av port 110 (POP3) eller 143 (IMAP). Den offisielle lista over tilordna porter finn du hos IANA. Den er delt i tre: registrerte, velkjente og dynamiske porter. Velkjente porter er dei portane under 1023. Dei kan vanligvis ikkje nyttast av andre enn root/Administrator på ei maskin, og dei skal ikkje nyttast av uregistrerte protokollar.Dei over 1024 kan alle brukarar på ei maskin vanligvis lytte til, og dei blir i praksis brukt rimelig vilkårleg, utan tanke på at dei skal i prinsippet vere registrert hjå IANA før dei blir brukt åpent i distribuert programvare. Porter over 49152 er fritt fram, og kan ikkje registrerast hos IANA på nokon måte.

Kort om NAT (Les:Kvifor verden vil ha IPv6)

NAT, Network Adress Translation, er ein teknikk som kom i bruk mot slutten av nittitallet, når ein innsåg at det begynte å bli mangel på IP-adresser i verden, og ein trengte ei stop-gap solution inntil IPv6 var rulla ut. NAT går i korte trekk ut på å tilordne en ruter/gateway ei offentleg adresse. Deretter lar ein alle maskiner som står bak den ruteren få ei privat IP-adresse frå eit av områda beskreve i RFC3330. Maskinene som står bak ruteren sender då trafikken sin mot internett til ruteren. Sidan dei har private IP-adresser kan ikkje ruteren sende dei ut på internett og forvente svar – den må skrive om litt. Den noterer ned kva intern IP som sendt pakken, kva port som vart nytta og slikt, og bytter ut IPen i pakkeheaderen med sin eigen, offentlege IP, før den sender den ut på internett. Når den så får svar, slår den opp i tabellen sin over IP:port-par og finn ut kva for ein interne klient som skal ha svaret den fekk. Så skriv den atter ein gang om headers, og sender pakken ut på det interne nettet. NAT har ført til at ein kan ha bokstaveleg tala tusenvis av maskiner bak ein offentlig IP. Dei fleste heimebrukarar har NAT-ruter.

Applied networking…

Mkay, enough primer om IPer. Over to the real stuff. La oss sjå på følgande nettverk gjennom eksempla etterpå:

Kort forklaring av dette:

• Vi har en ruter som har tilkopling mot internett.
• En brannmur for arbeidsstasjonane. Tillater kun www mot internett, og imap mot intern mailserver.
• En brannmur for serverparken. Tillater kun www mot www-server, kun ftp mot ftp-server, imap fra internett og lokalt, og SMTP bare fra lokale maskiner i nettet arbeidsstasjoner.

Vi antar at alle maskiner står på offentlig IP. Her har brannmurane to litt ulike roller. Den for klientnettet skal beskytte klientnettet mot angrep, ved å nekte alle innkommande tilkoplinger, slik at sårbarheter og malware på arbeidsstasjonane skal kunne gjere mindre skade. Den filtrerer i tillegg utgåande connections, slik at kun www-browsing, og sending av e-post via bedrifta sitt e-postsystem funker. Brannmuren foran serverparken skal også beskytte serverparken mot angrep, men også filtrere vekk trafikk for å redusere problem med kjørande tenester. I staden for å sette opp SMTP skikkelig er admin her lat, og tillater kun SMTP fra internt nettverk. Det vil sei at firewall for servere må sjekke om tilkoplinger på port 25 kommer fra en IP innen bedrifta sitt nettverk, og kun tillate det om så er tilfelle. IMAP skal tillatast fra internett og lokalt, sidan selgerane skal kunne lese epost når dei er ute… WWW og ftp er sjølvsagt public mot internett, sidan dei trossalt er bedrifta sitt ansikt utad. Her gjer ikkje ruteren noko meir enn å sende viare alle pakker mot destinasjonen – det er opp til brannmuren å filtrere trafikk.

Det samme gjelder i eit heimenett, sjølv om ein har NAT der: ruteren filtrerer ikkje trafikk, den berre viaresender blindt. Det er opp til ein eventuell brannmur å filtrere vekk uønska trafikk! Så tar vi for oss det samme – bare med NAT. Reglane blir omtrent dei samme, utover at ruteren no må få beskjed om at port 143(IMAP) skal peikast til mail sin IP, port 80 (WWW) må peikast mot www, og 21 mot ftp. Dette er det som er kalla portforwarding. Brannmurane ville gjere nokså lik jobb.

Takk til m0b for kommentarer og innspel undervegs. Denne posten er lisensiert under Creative Commons Share Alike, Non-commercial, Attribution. Det vil sei at du står fritt til å kopiere og endre denne, så lenge du beholder ein tilsvarande lisens på kopien din, og du siterer meg som opphavsmann, med lenke tilbake til http://bitsex.net.