Följande delsektioner innehåller information som man måste förstå för att kunna konfigurera sitt nätverk. Det är fundamentala principer som gäller oavsett karaktären på nätverket som man skall använda.
Innan man börjar bygga eller konfigurera sitt nätverk behöver man några saker. De viktigaste är:
Eftersom kärnan som man kör nu inte nödvändigtvis ännu har stöd för de nätverk och nätverkskort som man vill använda så behöver man antagligen källkoden för kärnan så att man kan kompilera om den med lämpliga tillägg.
Man kan alltid hämta den senaste källkoden från: ftp.funet.fi.
Vanligtvis så packas källkoden upp till katalogen /usr/src/linux. För
mer information om hur man lägger till patchar och hur man kompilerar kärnan så
bör man läsa
Kernel-HOWTO. För information om
hur man konfigurerar kärnans moduler så bör man läsa
Module-HOWTO.
Om inte annat sägs specifikt så rekommenderar jag att man håller dig till standardversionerna av kärnan (de med jämna nummer som andra siffra i versionsnummret). Versioner under utveckling (de med udda andra siffra) kan ha strukturella eller andra ändringar som kan skapa problem med annan mjukvara i sitt system. Om man är osäker på om man klarar av att lösa den typen av problem, så skall man inte använda de versionerna.
Nätverksverktygen är de program som man använder för att konfigurera nätverksenheter i Linux. Med dessa verktyg kan man tilldela adresser till enheter och konfigurera routes till exempel.
De flesta moderna Linuxdistributioner är utrustade med nätverksverktyg, så om man har installerat från en distribution och ännu inte installerat nätverksverktygen så bör man göra detta nu.
Om man inte har installerat från en distribution så behöver man källkoden för att kompilera verktygen själv. Detta är inte svårt.
Nätverksverktygen handhas av Bernd Eckenfels och finns på: ftp.inka.de och är speglade på: ftp.uk.linux.org.
Man skall vara noga med att välja en version som passar den kärna som man har tänkt att använda och med att följa instruktionerna i paketet för att installera.
För att installera den senaste versionen då detta skrivs så behöver man göra följande:
# # cd /usr/src # tar xvfz net-tools-1.33.tar.gz # cd net-tools-1.33 # make config # make # make install #
Dessutom, om man tänker konfigurera en brandvägg eller använda IP-maskering, så behöver man ipfwadm kommandot. Den senaste versionen finns på: ftp.xos.nl. Återigen så finns det ett antal versioner tillgängliga. Se till att välja den som passar bäst till din kärna.
För att installera den senaste versionen då detta skrivs så behöver man göra följande:
# # cd /usr/src # tar xvfz ipfwadm-2.3.0.tar.gz # cd ipfwadm-2.3.0 # make # make install #
Applikationsprogrammen är program såsom telnet och ftp och deras
respektive serverprogram. David Holland <dholland@hcs.harvard.edu> handhar
en distribution av de vanligaste av dessa. man kan hämta dem från:
ftp.uk.linux.org.
För att installera den senaste versionen då detta skrivs så behöver man göra följande:
# # cd /usr/src # tar xvfz /pub/net/NetKit-B-0.08.tar.gz # cd NetKit-B-0.08 # more README # vi MCONFIG # make # make install #
Internet Protokoll Adresser är uppbyggda av fyra bytes. Konventionen är att skriva adresser i vad som kallas 'punkterad decimal notation'. I denna formen är varje byte konverterad till ett decimalt tal (0-255), utan nollor i början, och skrivs med varje byte separerad med ett '.' tecken. Varje (nätverks-)gränssnitt hos en värddator eller router har en IP-adress. I vissa fall är det tillåtet att ha samma IP-adress på alla gränssnitt på en och samma maskin, men vanligtvis har varje gränssnitt sin egen adress.
Internet Protokoll nätverk är kontinuerliga sekvenser av IP-adresser. Alla adresser inom ett nätverk har ett antal siffror i adressen gemensamma. Den del av adressen som är gemensam för alla adresser inom ett nätverk kallas 'nätverksdelen' ('network portion') av adressen. Antalet bitar som är delade av alla adresser inom ett nätverk kallas 'nätmasken' ('netmask') och det är nätmaskens uppgift att avgöra vilka adresser som hör till nätverket som nätmasken tillhör och vilka som inte gör det. Beakta följande exempel:
----------------- --------------- Host Address 192.168.110.23 Network Mask 255.255.255.0 Network Portion 192.168.110. Host portion .23 ----------------- --------------- Network Address 192.168.110.0 Broadcast Address 192.168.110.255 ----------------- ---------------
Alla adresser som blir 'bitvis andade' med sin nätmask kommer att avslöja adressen till nätverket som den tillhör. Nätverksadressen är därför den lägst numrerade adressen i den rad av adresser som finns i nätverket och har värddatordelen av adressen satt till nollor.
Broadcastadressen är en speciell adress som varje värddator på nätverket lyssnar
till utöver sin egen unika adress. Till denna adress sänds datagram om det är tänkt
att alla maskiner på nätverket skall ta emot dem. Vissa typer av data såsom route
information och varningsmeddelanden sänds till broadcastadressen så att alla
maskiner på nätverket kan ta emot dem samtidigt. Det finns två vanligt förekommande
standarder för vad broadcastadressen skall vara. Den mest använda är att den
högsta möjliga adressen i nätverket används som broadcastadress. I exemplet ovan
skulle detta vara 192.168.110.255. Av någon anledning använder vissa
sajter nätverksadressen som broadcastadress. I praktiken spelar det ingen större
roll vilket man använder men man måste vara säker på att alla maskiner på nätverket
använder samma broadcastadress.
Av administrativa skäl någon gång tidigt i utvecklingen av IP-protokollet delades adresserna in i några slumpvisa grupper av nätverk och dessa nätverk grupperades i vad som kallas för klasser. Dessa klasser tillhandahåller ett antal nätverk av standardstorlekar som kan bli allokerade. De allokerade är:
---------------------------------------------------------- | Network | Netmask | Network Addresses | | Class | | | ---------------------------------------------------------- | A | 255.0.0.0 | 0.0.0.0 - 127.255.255.255 | | B | 255.255.0.0 | 128.0.0.0 - 191.255.255.255 | | C | 255.255.255.0 | 192.0.0.0 - 223.255.255.255 | |Multicast| 240.0.0.0 | 224.0.0.0 - 239.255.255.255 | ----------------------------------------------------------
Vilka adresser som man skall använda beror på vad det är exakt man skall göra. Man kan behöva använda en kombination av följande för att få de adresser man behöver:
Om man vill installera en Linuxmaskin på ett existerande IP-nätverk så bör man kontakta den som administrerar nätverket och fråga efter följande:
Om man bygger ett privat nätverk som man aldrig tänker ansluta till Internet så kan man välja vilka adresser man vill. Men, för säkerhets och konsistens skull så har vissa IP-adresser blivit reserverade speciellt för detta ändamål. De är specificerade i RFC1597 och är följande:
----------------------------------------------------------- | RESERVED PRIVATE NETWORK ALLOCATIONS | ----------------------------------------------------------- | Network | Netmask | Network Addresses | | Class | | | ----------------------------------------------------------- | A | 255.0.0.0 | 10.0.0.0 - 10.255.255.255 | | B | 255.255.0.0 | 172.16.0.0 - 172.31.255.255 | | C | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 | -----------------------------------------------------------
Man bör först bestämma hur stort nätverket skall vara och sedan välja så många adresser som man behöver.
Det finns några olika metoder för Linux systemstartprocedurer. Efter det att kärnan
bootar, så exekverar den alltid ett program som heter init. init
programmet läser sedan en konfigurationsfil som heter /etc/inittab och
inleder uppstartsprocessen. Det finns några olika versioner av init och det
är denna variationen som är den största orsaken till skillnad mellan distributioner
eller maskiner.
Vanligtvis så innehåller /etc/inittab filen en rad som ser ut någonting
som liknar:
si::sysinit:/etc/init.d/boot
Denna raden specificerar namnet på det shell-script som verkligen utför uppstarten.
Denna fil skulle kunna jämföras med filen AUTOEXEC.BAT i MS-DOS.
Vanligtvis finns det andra script som anropas av boot-scriptet och ofta så konfigureras nätverket i något av dessa.
Följande tabell kan användas som guide för ett system:
-------------------------------------------------------------------------------
Distrib. |Interface Config/Routing |Server Initialisation
-------------------------------------------------------------------------------
Debian |/etc/init.d/network |/etc/init.d/netbase
| |/etc/init.d/netstd_init
| |/etc/init.d/netstd_nfs
| |/etc/init.d/netstd_misc
-------------------------------------------------------------------------------
Slackware|/etc/rc.d/rc.inet1 |/etc/rc.d/rc.inet2
-------------------------------------------------------------------------------
RedHat |/etc/sysconfig/network-scripts/ifup-<ifname>|/etc/rc.d/init.d/network
-------------------------------------------------------------------------------
De flesta moderna distributioner har ett program med vilket man kan konfigurera många av de vanligaste sorterna av nätverksgränssnitt. Om man har en av dessa så bör man se om det kan göra det man vill innan man ger sig på manuell konfiguration.
-----------------------------------------
Distrib | Network configuration program
-----------------------------------------
RedHat | /sbin/netcfg
Slackware | /sbin/netconfig
-----------------------------------------
I många Unix operativsystem så framträder nätverksenheterna i /dev katalogen. Så är inte fallet i Linux. I Linux skapas nätverksenheterna dynamiskt i mjukvara och därmed måste inte enhetsfiler finnas.
I de flesta fall skapas nätverksenheterna automatiskt av drivrutinen när den
initialiseras och hittar din hårdvara. Till exempel så skapar
Ethernetdrivrutinen eth[0..n] gränssnitten sekvensiellt medan den
hittar din Ethernethårdvara. Det första Ethernetkortet som hittas blir
eth0, det andra eth1 osv.
Men i några fall, tex slip och ppp, så skapas nätverksenheterna genom att något användarprogram körs. Samma sekvensiella numrering gäller, men enheterna skapas inte automatiskt vid systemstarten. Anledningen till detta är att, till skillnad från Ethernetenheterna, så kan antalet aktiva slip eller ppp enheter variera under tiden systemet är igång. De här fallen gås igenom mer noggrannt senare.
När man har alla program man behöver och sina adress- och nätverksuppgifter så kan man konfigurera sina nätverksgränssnitt. När vi pratar om att konfigurera ett nätverksgränssnitt så pratar vi om processen att tilldela en nätverksenhet lämpliga adresser och att ge lämpliga värden till andra konfigurerbara parametrar hos en nätverksenhet. Det mest använda programmet för detta är kommandot ifconfig (interface configure).
Vanligtvis bör man använda ett kommando som liknar följande:
# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
eth0 med IP-adressen
192.168.0.1 och en nätmask 255.255.255.0.
Parametern up som följer kommandot talar om för enheten att den skall
bli aktiv.
Kärnan förutsätter vissa förvalda värden när man konfigurerar gränssnitt. Till
exempel så kan man specificera nätverksadress och broadcastadress för ett
gränssnitt. Men om man inte gör det, som i exemplet ovan, så gör kärnan
rimliga gissningar baserade på nätmasken, och om man inte specificerat någon
nätmask så tittar kärnan på klassen av IP-adress. I exemplet ovan skulle
kärnan anta att det är ett klass C nätverk som skall konfigureras och därmed
sätta nätverksadressen till 192.168.0.0 och broadcastadressen till
192.168.0.255.
Det finns många andra parametrar till ifconfig. De viktigaste är:
aktiverar ett gränssnitt.
deaktiverar ett gränssnitt.
slår av eller slår på 'address resolution protocol' för gränssnittet.
slår av eller slår på mottagning av alla hårdvaru-multicastpaket. Hårdvaru-multicast låter grupper av maskiner att ta emot paket som är adresserade till speciella destinationer. Detta kan vara viktigt om man använder applikationer såsom videokonferenssystem men används normalt inte.
specificerar MTU för enheten.
specificerar nätmasken för nätverket som maskinen tillhör.
denna parameter fungerar endast för viss hårdvara och sätter IRQ för enheten.
slår på mottagning av datagram som skickas till broadcastadressen, eller slår av mottagning av dessa datagram.
sätter adressen på maskinen på andra änden av en punkt till punkt förbindelse som tex slip eller ppp.
sätter hårdvaruadressen för nätverksenheten. Oftast är detta inte användbart för Ethernet, men är användbart för andra typer av nätverk som tex AX.25.
Name Resolvern är en del av Linux standardbibliotek. Dess huvudsakliga
funktion är att tillhandahålla en tjänst för att översätta människovänliga
datornamn som ftp.funet.fi till maskinvänliga IP-adresser som
128.214.248.6.
De flesta är antagligen bekanta med hur datornamn uppträder i Internet, men man kanske inte vet hur de är konstruerade, eller rekonstruerade. Internet domännamn är av hierarkisk karaktär, dvs de har trädstruktur. En domän är en familj, eller grupp av namn. En domän kan brytas ned i subdomäner. En toppdomän är en domän som inte är en subdomän. Toppdomänerna är specificerade i RFC-920. Några exempel på de vanligaste topdomänerna är:
Kommersiella Organisationer
Utbildningsorganisationer
Regeringsorganisationer
Militärorganisationer
Andra Organisationer
Internet-Relaterade Organisationer
Detta är koder som består av två bokstäver och som representerar ett visst land.
Alla dessa toppdomäner har subdomäner. Toppdomänerna baserade på landsnamn
bryts sedan ned i subdomäner baserade på com, edu, gov,
mil och org domäner (detta är ju dock inte fallet i .se-domänen ännu.
Översättarens kommentar). Så till exempel blir det com.au och gov.au
för kommersiella och regeringsorganisationer i Australien. Av historiska skäl
så används de domäner som tillhör de icke landsbaserade toppdomänerna
mestadels av organisationer i USA, trots att USA har sin egen landskod
.us.
Nästa nedbrytningsnivå representerar oftast namnet på organisationen. Ytterligare subdomäner varierar i karaktär, oftast så baseras nästa nivå på avdelningar inom organisationen, men den kan baseras på vilket kriterium som helst som har någon betydelse för nätverksadministratörerna i organisationen.
Delen längst till vänster av namnet är alltid det unika namnet som värddatorn har och det kallas för hostname, den delen av namnet som finns till höger om hostname kallas för domainname och hela namnet heter Fully Qualified Domain Name.
Med min egen emailvärddator som exempel, så är
`Fully Qualified Domain Name' perf.no.itg.telstra.com.au. Detta betyder
att hostname är perf och domainname är no.itg.telstra.com.au.
Domännamnet är baserat på en toppdomän vilken är baserad på mitt land, Australien och
eftersom min epostadress tillhör en komersiell organisation så har vi
.com på nästa nivå. Företagets namn är (var) telstra och vår
interna namnstruktur är baserad på den organisationella strukturen, i mitt fall
så tillhör maskinen Information Technology Group, Network Operations sektionen.
Man behöver veta vilken domän datorns namn skall tillhöra. Name Resolvermjukvaran tillhandahåller namnöversättning genom att göra förfrågningar till en Domain Name Server, så man behöver veta IP-adressen till en lokal namnserver som man kan använda.
Det finns tre filer som man behöver editera, jag berättar om dem i tur och ordning.
Filen /etc/resolv.conf är huvudfilen för att konfigurera
namnöversättaren. Dess format är ganska enkelt. Det är en textfil med ett
nyckelord per rad. Det finns tre nyckelord som vanligtvis används, de är:
detta nyckelord specificerar det lokala domännamnet.
detta nyckelord specificerar en lista med alternativa domännamn att leta i efter ett datornamn.
detta nyckelord, som kan användas flera gånger, specificerar en IP-adress till en namnserver (Domain Name Server) att använda när man översätter namn.
/etc/resolv.conf kan se ut någonting som följande:
domain maths.wu.edu.au
search maths.wu.edu.au wu.edu.au
nameserver 192.168.10.1
nameserver 192.168.12.1
maths.wu.edu.au till
datornamn som ges utan domännamn, och om datorn inte hittas där så skall man
leta även i wu.edu.au domänen. Två namnservrar är specificerade, som båda
kan kontaktas av namnöversättaren när ett namn skall översättas.
I filen /etc/host.conf kan man konfigurera hur namnöversättaren
beter sig. Formatet för filen är beskrivet i detalj i manualsidan
resolv+. I nästan alla fall fungerar följande exempel:
order hosts,bind
multi on
Denna konfiguration talar om för översättaren att titta i filen
/etc/hosts innan den försöker göra en förfrågning till namnservern och
att returnera alla giltiga adresser för en dator som den hittar i
/etc/hosts och inte bara den första.
I filen /etc/hosts kan man lägga namn och IP-adresser för lokala
maskiner. Om man placerar ett datornamn med respektive IP-adress i denna fil
så behöver man inte göra en förfrågan till namnservern för att få reda på dess
IP-adress. Nackdelen med detta är att man måste hålla filen uppdaterad själv
ifall IP-adresserna ändras. I ett väl underhållet system så finns endast rader
med 'loopback' och lokala datornamn i denna fil.
# /etc/hosts
127.0.0.1 localhost loopback
192.168.0.1 this.host.name
Man kan ange mer än ett datornamn per rad som på den första raden i exemplet, vilket är standardutformningen för loopbackenheten.
loopback-enheten är ett särskilt gränssnitt med vilket man kan göra
anslutningar till sig själv. Det finns olika anledningar varför man skulle
vilja göra detta, till exempel så kanske man vill testa någon nätverksmjukvara utan
att störa någon annan på sitt nätverk. Av tradition så har IP-adressen
127.0.0.1 reserverats speciellt för loopback. Så, oavsett vilken maskin
man går till, om man öppnar en telnet-anslutning till 127.0.0.1 så blir
man alltid ansluten till den lokala datorn.
Att konfigurera loopbackenheten är enkelt och man bör göra följande:
# ifconfig lo 127.0.0.1
# route add -host 127.0.0.1 lo
Vi pratar mer om route kommandot i nästa sektion.
Routing är ett stort ämne. Det skulle vara lätt att skriva stora mängder text om detta. De flesta kommer att ha hyfsat enkla krav på routingen, men vissa har det inte. Jag kommer bara att behandla grunderna om routing. Om man är intresserad av mer detaljerad information så föreslår jag att man letar i referenserna som ges i början av detta dokument.
Låt oss börja med en definition. Vad är IP routing? Här följer den definition som jag använder:
IP routing är processen där en dator med flera nätverksanslutningar avgör vart den skall skicka IP datagram som den har tagit emot.
Det kan vara bra att illustrera detta med ett exempel. Antag en typisk kontorsrouter, den skulle kunna ha en PPP-länk till Internet, ett antal Ethernetsegment som går till arbetsstationerna och en annan PPP-länk till ett annat kontor. När routern tar emot ett datagram på någon av dess nätverksanslutningar, så är routing mekanismen den använder för att avgöra till vilken av nätverksanslutningarna som den skall skicka vidare datagrammet. Enkla datorer behöver också använda routing, alla Internetdatorer har åtminstone två nätverksenheter, en är loopbackenheten som beskrivs ovan och den andra är den som den använder för att 'prata' med resten av nätverket, kanske ett Ethernetkort, kanske ett PPP- eller SLIP-gränssnitt.
Hur fungerar routing? Varje dator har en speciell lista med routingregler som kallas för routingtabellen (routing table). Denna tabell innehåller rader som vanligtvis innehåller åtminstone tre fält, det första är en destinationsadress, det andra är namnet på gränssnittet som datagrammet skall routas till och det tredje är IP-adressen på en annan maskin som skall ta datagrammet på sitt nästa steg genom nätverket. I Linux kan man se denna tabell genom att använda följande kommando:
# cat /proc/net/route
# /sbin/route -n
# /bin/netstat -r
Routingprocessen är hyfsat enkel: ett inkommande datagram tas emot, destinationsadressen undersöks och jämförs med varje rad i tabellen. Den rad som bäst matchar adressen väljs och datagrammet skickas vidare till det specificerade gränssnittet. Om gateway-fältet är ifyllt så skickas datagrammet vidare till den maskinen via det specificerade gränssnittet, annars antas det att destinationsadressen finns på nätverket som gränssnittet är kopplat till.
För att manipulera tabellen använder man ett speciellt kommando. Detta kommando tar kommandoradsargument och konverterar dem till systemanrop vilka ber kärnan att lägga till, ta bort eller ändra rader i routingtabellen. Kommandot är route.
Ett enkelt exempel. Antag att man har ett Ethernetnätverk. Man har fått veta
att det är ett klass C nätverk med nätverksadressen 192.168.1.0. Man har
fått IP-adressen 192.168.1.10 som man kan använda och man har fått veta att
192.168.1.1 är en router som är ansluten till Internet.
Det första steget är att konfigurera gränssnittet som det beskrivits ovan. Man skulle använda ett kommando som:
# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
192.168.1.* skall sändas
till en Ethernet-enhet. Detta med ett kommando som:
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
-net parametern som används för att tala om för routingprogrammet
att denna rad är en nätverksroute. Det andra alternativet är en -host route som
är en route som är till en specifik IP-adress.
Med denna route kan man upprätta IP-anslutningar till alla datorer på sitt Ethernet-segment. Men vad händer med alla IP-datorer som inte finns på ens Ethernet-segment?
Det skulle vara ett väldigt svårt jobb att behöva lägga till router till varje
tänkbart nätverk, så det finns ett specialtrix som används för att förenkla denna
uppgift. Trixet kallas för default route. Default routen passar
varje möjlig destination, men dåligt, så om det finns någon annan rad som
passar den önskade adressen bättre så kommer den att användas istället för
default routen. Tanken med default routen är helt enkelt att man skall kunna
säga "och allt annat skall skickas dit". Så i exemplet som vi följt så bör man
använda en rad som:
# route add default gw 192.168.1.1 eth0
gw talar om för route kommandot att nästa parameter är
IP-adressen, eller namnet, på en gateway eller router dit alla datagram som
passar denna rad skall skickas för vidare routing.
Så exemplets kompletta konfiguration skulle se ut så här:
# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
# route add default gw 192.168.1.1 eth0
rc-filer för nätverket så kommer man att hitta
åtminstone en som liknar detta. Detta är en väldigt vanlig konfiguration.
Låt oss nu titta på en något mer komplicerad routingkonfiguration. Antag att vi konfigurerar routern som vi tittade på tidigare, med en PPP-länk till Internet och några LAN-segment med arbetsstationer på kontoret. Antag att routern har tre Ethernet-segment och en PPP-länk. Vår routingkonfiguration skulle likna följande:
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
# route add -net 192.168.2.0 netmask 255.255.255.0 eth1
# route add -net 192.168.3.0 netmask 255.255.255.0 eth2
# route add default ppp0
default route mekanismen hand om allihop och låter routern sköta
den 'riktiga' routingen. Man kanske undrar varför defaultrouten inte anger en
gw. Anledningen är enkel, seriella länkprotokoll såsom PPP och SLIP har
alltid endast två maskiner på sitt nätverk, en i varje ända. Att ange maskinen
på andra sidan länken som gateway är meningslöst och redundant eftersom det
inte finns något annat val, så man behöver inte ange någon gateway för den typen
av nätverksanslutningar. Andra nätverkstyper såsom Ethernet, arcnet eller
Token Ring kräver att en gateway specificeras eftersom dessa nätverken stödjer
att ett stort antal datorer ansluts till dem.
Routingkonfigurationen som beskrivs ovan passar bäst för enklare nätverksarrangemang där det endast finns en möjlig väg till varje destination. När man har ett mer komplext arrangemang så blir det lite besvärligare. Som tur är behöver de flesta inte bry sig om detta.
Det stora problemet med 'manuell routing' eller 'statisk routing' är att om en maskin eller länk fallerar i nätverket så kan man endast dirigera om sina datagram, om det finns någon annan väg, genom att manuellt ge lämpliga kommandon. Naturligtvis är detta klumpigt, långsamt, opraktiskt och felbenäget. Olika tekniker har utvecklats för att automatiskt ändra routingtabeller om det uppstår nätverksfel där det finns alternativa vägar att leda trafiken, alla dessa tekniker är löst samlade under termen 'dynamiska routing algoritmer'.
Man kanske har hört talas om några av de vanligare dynamiska routingalgorimerna. De allra vanligaste är RIP (Routing Information Protocol) och OSPF (Open Shortest Path First). RIP är väldigt vanlig i små nätverk som till exempel små/mellanstora företagsnätverk. OSPF är modernare och mer kapabel att hantera stora nätverk och bättre anpassad till omgivningar där det finns ett stort antal möjliga vägar genom ett nätverk. Vanliga implementeringar av dessa är: routed (RIP) och gated (RIP, OSPF och andra). Programmet routed finns normalt med i Linuxdistributioner eller finns inkluderat i 'NetKit' paketet ovan.
Ett exempel på var och hur man skulle kunna använda en dynamisk routingalgoritm skulle kunna se ut som följer:
192.168.1.0 / 192.168.2.0 /
255.255.255.0 255.255.255.0
- -
| |
| /-----\ /-----\ |
| | |ppp0 // ppp0| | |
eth0 |---| A |------//---------| B |---| eth0
| | | // | | |
| \-----/ \-----/ |
| \ ppp1 ppp1 / |
- \ / -
\ /
\ /
\ /
\ /
\ /
\ /
\ /
\ /
ppp0\ /ppp1
/-----\
| |
| C |
| |
\-----/
|eth0
|
|---------|
192.168.3.0 /
255.255.255.0
Vi har tre routrar A, B och C. Var och en har ett Ethernet-segment med ett klass C IP-nätverk (nätmask 255.255.255.0). Varje router har även en PPP-länk till var och en av de andra routrarna. Nätverket bildar en triangel.
Det bör vara klart att routingtabellen för router A skulle kunna se ut som:
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1
Men vänta lite nu, om A kan prata med C och C fortfarande kan prata med B, varför skulle inte A kunna routa sina datagram till B via C och låta C skicka dem till B? Detta är precis den typen av problem som dynamiska routingalgoritmer som RIP designades för att lösa. Om var och en av routrarna A, B och C körde en routingdaemon så skulle deras routingtabeller automatiskt uppdateras till att spegla det nya tillståndet i nätverket om någon av länkarna skulle fallera. För att konfigurera ett sådant nätverk är enkelt, på varje router behöver man endast göra två saker. I detta fall för router A:
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
# /usr/sbin/routed
Detta har varit en väldigt översiktlig förklaring av dynamisk routing och var man bör använda det. Om man vill ha mer information så sök ibland referenserna i början av dokumentet.
De viktiga punkterna relaterade till dynamisk routing är:
Nätverksservrar och tjänster är de program som låter en avlägsen användare använda sig av ens Linuxburk. Serverprogram lyssnar på nätverksportar. Nätverksportar är hjälpmedel för att adressera en speciell tjänst på en dator och är hur en server vet skillnaden mellan en inkommande telnet-anslutning och en inkommande ftp-anslutning. Den avlägsna användaren upprättar en nätverksanslutning till Linuxburken och serverprogrammet, nätverksdaemonen, lyssnar på den porten och accepterar anslutningen och exekverar. Det finns två sätt på vilka nätverksdaemoner kan fungera. Båda är flitigt använda i praktiken. De två sätten är:
nätverksdaemonen lyssnar på den angivna porten och när den upptäcker en inkommande anslutning så sköter den om anslutningen själv för att vidare tillhandahålla tjänster.
inetd servern är en särskild nätverksdaemon som är specialiserad på att ta hand om inkommande nätvarksanslutningar. Den har en konfigurationsfil som talar om vilket program som skall köras då en inkommande anslutning tas emot. Varje port kan konfigureras för något av protokollen TCP eller UDP. Portarna är beskrivna i en annan fil som vi skall prata om snart.
/etc/services som tilldelar namn till portnummer och
/etc/inetd.conf som är konfigurationsfilen till nätverksdaemonen
inetd.
/etc/servicesFilen /etc/services är en enkel databas som associerar ett
människovänligt namn med en maskinvänlig port. Formatet är ganska enkelt. Filen
är en textfil där varje rad representerar en rad i databasen. Varje rad består
av tre fält som är separerade av valfritt antal vita tecken (tab eller space).
Fälten är:
name port/protocol aliases # comment
ett namn, bestående av ett ord, som representerar tjänsten som skall beskrivas.
detta fält är indelat i två delfält.
ett nummer som anger portnummret som den namngivna
tjänsten kommer att vara tillgänglig på. De flesta vanliga tjänster
har tilldelats reserverade nummer. Dessa finns beskrivna i
RFC-1340.
detta delfält kan sättas till antingen tcp
eller udp.
Det är viktigt att notera att en rad med 18/tcp är väldigt olik en rad
med 18/udp och att det inte finns någon teknisk anledning till att
samma tjänst finns tillgänglig på båda. Normalt råder sunt förnuft och det är
bara om en viss tjänst finns tillgänglig via både tcp och udp
som man kommer att se rader med båda.
andra namn som kan användas för att referera till denna tjänsten.
# tecken på en rad ignoreras och behandlas
som en kommentar.
/etc/services fil.Alla moderna Linuxdistributioner kommer med en bra /etc/services fil.
Men i fall man råkar bygga ett system från grunden så är här en kopia av
/etc/services filen som kommer med
Debian distributionen.
# /etc/services:
# $Id: services,v 1.3 1996/05/06 21:42:37 tobias Exp $
#
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, most entries here have two entries
# even if the protocol doesn't support UDP operations.
# Updated from RFC 1340, ``Assigned Numbers'' (July 1992). Not all ports
# are included, only the more common ones.
tcpmux 1/tcp # TCP port service multiplexer
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp users
daytime 13/tcp
daytime 13/udp
netstat 15/tcp
qotd 17/tcp quote
msp 18/tcp # message send protocol
msp 18/udp # message send protocol
chargen 19/tcp ttytst source
chargen 19/udp ttytst source
ftp-data 20/tcp
ftp 21/tcp
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol
telnet 23/tcp
# 24 - private
smtp 25/tcp mail
# 26 - unassigned
time 37/tcp timserver
time 37/udp timserver
rlp 39/udp resource # resource location
nameserver 42/tcp name # IEN 116
whois 43/tcp nicname
re-mail-ck 50/tcp # Remote Mail Checking Protocol
re-mail-ck 50/udp # Remote Mail Checking Protocol
domain 53/tcp nameserver # name-domain server
domain 53/udp nameserver
mtp 57/tcp # deprecated
bootps 67/tcp # BOOTP server
bootps 67/udp
bootpc 68/tcp # BOOTP client
bootpc 68/udp
tftp 69/udp
gopher 70/tcp # Internet Gopher
gopher 70/udp
rje 77/tcp netrjs
finger 79/tcp
www 80/tcp http # WorldWideWeb HTTP
www 80/udp # HyperText Transfer Protocol
link 87/tcp ttylink
kerberos 88/tcp kerberos5 krb5 # Kerberos v5
kerberos 88/udp kerberos5 krb5 # Kerberos v5
supdup 95/tcp
# 100 - reserved
hostnames 101/tcp hostname # usually from sri-nic
iso-tsap 102/tcp tsap # part of ISODE.
csnet-ns 105/tcp cso-ns # also used by CSO name server
csnet-ns 105/udp cso-ns
rtelnet 107/tcp # Remote Telnet
rtelnet 107/udp
pop-2 109/tcp postoffice # POP version 2
pop-2 109/udp
pop-3 110/tcp # POP version 3
pop-3 110/udp
sunrpc 111/tcp portmapper # RPC 4.0 portmapper TCP
sunrpc 111/udp portmapper # RPC 4.0 portmapper UDP
auth 113/tcp authentication tap ident
sftp 115/tcp
uucp-path 117/tcp
nntp 119/tcp readnews untp # USENET News Transfer Protocol
ntp 123/tcp
ntp 123/udp # Network Time Protocol
netbios-ns 137/tcp # NETBIOS Name Service
netbios-ns 137/udp
netbios-dgm 138/tcp # NETBIOS Datagram Service
netbios-dgm 138/udp
netbios-ssn 139/tcp # NETBIOS session service
netbios-ssn 139/udp
imap2 143/tcp # Interim Mail Access Proto v2
imap2 143/udp
snmp 161/udp # Simple Net Mgmt Proto
snmp-trap 162/udp snmptrap # Traps for SNMP
cmip-man 163/tcp # ISO mgmt over IP (CMOT)
cmip-man 163/udp
cmip-agent 164/tcp
cmip-agent 164/udp
xdmcp 177/tcp # X Display Mgr. Control Proto
xdmcp 177/udp
nextstep 178/tcp NeXTStep NextStep # NeXTStep window
nextstep 178/udp NeXTStep NextStep # server
bgp 179/tcp # Border Gateway Proto.
bgp 179/udp
prospero 191/tcp # Cliff Neuman's Prospero
prospero 191/udp
irc 194/tcp # Internet Relay Chat
irc 194/udp
smux 199/tcp # SNMP Unix Multiplexer
smux 199/udp
at-rtmp 201/tcp # AppleTalk routing
at-rtmp 201/udp
at-nbp 202/tcp # AppleTalk name binding
at-nbp 202/udp
at-echo 204/tcp # AppleTalk echo
at-echo 204/udp
at-zis 206/tcp # AppleTalk zone information
at-zis 206/udp
z3950 210/tcp wais # NISO Z39.50 database
z3950 210/udp wais
ipx 213/tcp # IPX
ipx 213/udp
imap3 220/tcp # Interactive Mail Access
imap3 220/udp # Protocol v3
ulistserv 372/tcp # UNIX Listserv
ulistserv 372/udp
#
# UNIX specific services
#
exec 512/tcp
biff 512/udp comsat
login 513/tcp
who 513/udp whod
shell 514/tcp cmd # no passwords used
syslog 514/udp
printer 515/tcp spooler # line printer spooler
talk 517/udp
ntalk 518/udp
route 520/udp router routed # RIP
timed 525/udp timeserver
tempo 526/tcp newdate
courier 530/tcp rpc
conference 531/tcp chat
netnews 532/tcp readnews
netwall 533/udp # -for emergency broadcasts
uucp 540/tcp uucpd # uucp daemon
remotefs 556/tcp rfs_server rfs # Brunhoff remote filesystem
klogin 543/tcp # Kerberized `rlogin' (v5)
kshell 544/tcp krcmd # Kerberized `rsh' (v5)
kerberos-adm 749/tcp # Kerberos `kadmin' (v5)
#
webster 765/tcp # Network dictionary
webster 765/udp
#
# From ``Assigned Numbers'':
#
#> The Registered Ports are not controlled by the IANA and on most systems
#> can be used by ordinary user processes or programs executed by ordinary
#> users.
#
#> Ports are used in the TCP [45,106] to name the ends of logical
#> connections which carry long term conversations. For the purpose of
#> providing services to unknown callers, a service contact port is
#> defined. This list specifies the port used by the server process as its
#> contact port. While the IANA can not control uses of these ports it
#> does register or list uses of these ports as a convienence to the
#> community.
#
ingreslock 1524/tcp
ingreslock 1524/udp
prospero-np 1525/tcp # Prospero non-privileged
prospero-np 1525/udp
rfe 5002/tcp # Radio Free Ethernet
rfe 5002/udp # Actually uses UDP only
bbs 7000/tcp # BBS service
#
#
# Kerberos (Project Athena/MIT) services
# Note that these are for Kerberos v4 and are unofficial. Sites running
# v4 should uncomment these and comment out the v5 entries above.
#
kerberos4 750/udp kdc # Kerberos (server) udp
kerberos4 750/tcp kdc # Kerberos (server) tcp
kerberos_master 751/udp # Kerberos authentication
kerberos_master 751/tcp # Kerberos authentication
passwd_server 752/udp # Kerberos passwd server
krb_prop 754/tcp # Kerberos slave propagation
krbupdate 760/tcp kreg # Kerberos registration
kpasswd 761/tcp kpwd # Kerberos "passwd"
kpop 1109/tcp # Pop with Kerberos
knetd 2053/tcp # Kerberos de-multiplexor
zephyr-srv 2102/udp # Zephyr server
zephyr-clt 2103/udp # Zephyr serv-hm connection
zephyr-hm 2104/udp # Zephyr hostmanager
eklogin 2105/tcp # Kerberos encrypted rlogin
#
# Unofficial but necessary (for NetBSD) services
#
supfilesrv 871/tcp # SUP server
supfiledbg 1127/tcp # SUP debugging
#
# Datagram Delivery Protocol services
#
rtmp 1/ddp # Routing Table Maintenance Protocol
nbp 2/ddp # Name Binding Protocol
echo 4/ddp # AppleTalk Echo Protocol
zip 6/ddp # Zone Information Protocol
#
# Debian GNU/Linux services
rmtcfg 1236/tcp # Gracilis Packeten remote config server
xtel 1313/tcp # french minitel
cfinger 2003/tcp # GNU Finger
postgres 4321/tcp # POSTGRES
mandelspawn 9359/udp mandelbrot # network mandelbrot
# Local services
/etc/inetd.confFilen /etc/inetd.conf är konfigurationsfilen för serverdaemonen
inetd. Dess funktion är att tala om för inetd vad som skall hända när
den tar emot en anslutningsförfrågan för en viss tjänst. För varje tjänst för
vilken man önskar acceptera anslutningar måste man tala om för inetd vilken
nätverksserver den skall starta och hur den skall startas.
Dess format är ganska enkelt. Det är en textfil där varje rad beskriver en
tjänst som man vill tillhandahålla. All text efter ett # tecken på en rad
ignoreras och ses som en kommentar. Varje rad innehåller sju fält som är
separerade av valfritt antal vita tecken (tab eller space). Det generella
formatet är som följer:
service socket_type proto flags user server_path server_args
är tjänsten som är relevant för denna konfiguration som den
benämns i /etc/services.
detta fält beskriver vilken typ av socket som denna rad
kommer att beteckna som relevant, tillåtna värden är stream, dgram,
raw, rdm eller seqpacket. Detta är lite tekniskt till karaktären
men som tumregel så använder nästan alla tcp-baserade tjänster stream
och alla udp-baserade tjänster dgram. Det är bara väldigt speciella
typer av daemoner som använder de andra värdena.
protokollet som skall anses som giltigt för denna rad. Detta
skall passa ihop med lämplig rad i /etc/services och är vanligtvis
antingen tcp eller udp. Sun RPC (Remote Procedure Call) baserade
tjänster använder rpc/tcp eller rcp/udp.
det finns egentligen bara två möjliga värden för detta fält.
Detta fält talar om för inetd om serverprogramvaran stänger socketen
efter det att den startats och därför om inetd kan starta en annan server
på nästa anslutningsförfrågan. Återigen så är detta lite besvärligt att lista
ut, men som tumregel så skall alla tcp servrar ha värdet nowait och
de flesta udp servrar wait. Observera att det finns undantag för
detta, så man bör endast följa exemplet om man inte vet.
detta fält talar om vilket användarkonto från
/etc/passwd som skall sättas som ägare till nätverksdaemonen när den
startas. Detta är ofta användbart för att skydda sig mot säkerhetsrisker. Man
kan sätta värdet till nobody så att skadan minimeras ifall
nätverksserverns säkerhet fallerar. Men vanligtvis så är detta fält satt till
root eftersom många servrar måste ha root-rättigheter för att fungera
korrekt.
detta fält skall innehålla det absoluta filnamnet till serverprogrammet som skall exekveras för denna raden.
detta fältet utgör resten av raden och är valfri. Det är här som man placerar kommandoradsargument som man vill skicka med till serverdaemonen när den startas.
/etc/inetd.conf fil.Som för filen /etc/services så inkluderar alla moderna distributioner
en bra /etc/inetd.conf fil som man kan arbeta med. För att vara
komplett så inkluderas /etc/inetd.conf från
Debian distributionen.
# /etc/inetd.conf: see inetd(8) for further informations.
#
# Internet server configuration database
#
#
# Modified for Debian by Peter Tobias <tobias@et-inf.fho-emden.de>
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
# Internal services
#
#echo stream tcp nowait root internal
#echo dgram udp wait root internal
discard stream tcp nowait root internal
discard dgram udp wait root internal
daytime stream tcp nowait root internal
daytime dgram udp wait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
time stream tcp nowait root internal
time dgram udp wait root internal
#
# These are standard services.
#
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.ftpd
#fsp dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.fspd
#
# Shell, login, exec and talk are BSD protocols.
#
shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd
login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd
talk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.talkd
ntalk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.ntalkd
#
# Mail, news and uucp services.
#
smtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.smtpd
#nntp stream tcp nowait news /usr/sbin/tcpd /usr/sbin/in.nntpd
#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico
#comsat dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.comsat
#
# Pop et al
#
#pop-2 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop2d
#pop-3 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop3d
#
# `cfinger' is for the GNU finger server available for Debian. (NOTE: The
# current implementation of the `finger' daemon allows it to be run as `root'.)
#
#cfinger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.cfingerd
#finger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.fingerd
#netstat stream tcp nowait nobody /usr/sbin/tcpd /bin/netstat
#systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx
#
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers."
#
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /boot
#bootps dgram udp wait root /usr/sbin/bootpd bootpd -i -t 120
#
# Kerberos authenticated services (these probably need to be corrected)
#
#klogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k
#eklogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k -x
#kshell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd -k
#
# Services run ONLY on the Kerberos server (these probably need to be corrected)
#
#krbupdate stream tcp nowait root /usr/sbin/tcpd /usr/sbin/registerd
#kpasswd stream tcp nowait root /usr/sbin/tcpd /usr/sbin/kpasswdd
#
# RPC based services
#
#mountd/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.mountd
#rstatd/1-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rstatd
#rusersd/2-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rusersd
#walld/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rwalld
#
# End of inetd.conf.
ident stream tcp nowait nobody /usr/sbin/identd identd -i
Det finns ett antal andra filer som är relaterade till nätverkskonfiguration i Linux som man skulle kunna vara intresserad av. Man behöver kanske aldrig modifiera dessa filer, men det är värt att beskriva dem ändå så att man vet vad de innehåller och vad de används till.
/etc/protocolsFilen /etc/protocols är en databas som mappar protokollens id-nummer
mot protokollens namn. Detta används av programmerare för att låta dem ange
protokoll med dess namn i program, och även av vissa program, som till
exempel tcpdump, för att kunna skriva ut namn istället för nummer.
Syntaxen för filen är:
protocolname number aliases
/etc/protocols ut som följande:
# /etc/protocols:
# $Id: protocols,v 1.1 1995/02/24 01:09:41 imurdock Exp $
#
# Internet (IP) protocols
#
# from: @(#)protocols 5.1 (Berkeley) 4/17/89
#
# Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).
ip 0 IP # internet protocol, pseudo protocol number
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # Internet Group Management
ggp 3 GGP # gateway-gateway protocol
ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'')
st 5 ST # ST datagram mode
tcp 6 TCP # transmission control protocol
egp 8 EGP # exterior gateway protocol
pup 12 PUP # PARC universal packet protocol
udp 17 UDP # user datagram protocol
hmp 20 HMP # host monitoring protocol
xns-idp 22 XNS-IDP # Xerox NS IDP
rdp 27 RDP # "reliable datagram" protocol
iso-tp4 29 ISO-TP4 # ISO Transport Protocol class 4
xtp 36 XTP # Xpress Tranfer Protocol
ddp 37 DDP # Datagram Delivery Protocol
idpr-cmtp 39 IDPR-CMTP # IDPR Control Message Transport
rspf 73 RSPF # Radio Shortest Path First.
vmtp 81 VMTP # Versatile Message Transport
ospf 89 OSPFIGP # Open Shortest Path First IGP
ipip 94 IPIP # Yet Another IP encapsulation
encap 98 ENCAP # Yet Another IP encapsulation
/etc/networksFilen /etc/networks har en liknande funktion som filen
/etc/hosts. Den tillhandahåller en enkel databas av nätverksnamn som
mappas mot nätverksadresser. Dess format skiljer sig genom att det får endast
finnas två fält per rad och att fälten skrivs som:
networkname networkaddress
Ett exempel kam se ut såhär:
loopnet 127.0.0.0
localnet 192.168.0.0
amprnet 44.0.0.0
När man använder kommandon som route, om en destination är ett nätverk
och det nätverket finns i /etc/networks, så kommer route att
visa nätverksnamnet istället för dess adress.
Låt mig börja denna sektion med att varna för att säkra en maskin och ett nätverk mot illvilliga attacker är en komplex konst. Jag anser mig inte själv vara en expert på detta område och även om de följande mekanismerna som jag beskriver kommer att hjälpa, så om man är riktigt allvarlig när det gäller säkerhet så rekommenderar jag att man gör egna undersökningar i ämnet. Det finns många bra referenser på Internet relaterade till detta ämne.
En viktig tumregel är:
`Kör inte servrar som inte skall användas'.
Många distributioner kommer konfigurerade med alla möjliga tjänster som startas
automatiskt. För att säkerställa en miniminivå av säkerhet så bör man gå igenom
sin /etc/inetd.conf och kommentera bort (sätt ett '#' i början
av raden) alla rader som innehåller tjänster vilka man inte tänker använda.
Bra kandidater är tjänster såsom: shell, login, exec, uucp,
ftp och informativa tjänster som finger, netstat och systat.
Det finns alla möjliga sorters säkerhets- och åtkomstkontrollmekanismer, jag kommer att beskriva de mest elementära av dem.
Filen /etc/ftpusers är en enkel mekanism med vilken man kan vägra vissa
användare att logga in till maskinen via ftp. Filen /etc/ftpusers
läses av ftp-daemonen (ftpd) när en inkommande ftp-anslutning tas emot.
Filen är en enkel lista av de användare som inte är tillåtna att logga in. Den
skulle kunna se ut som:
# /etc/ftpusers - users not allowed to login via ftp
root
uucp
bin
mail
I filen /etc/securetty kan man specificera vilka tty enheter som
root är tillåten att logga in på. Filen /etc/securetty läses av
loginprogrammet (vanligtvis /bin/login). Dess format är en lista av
de tty enhetsnamn som är tillåtna, på alla andra är root login otillåten:
# /etc/securetty - tty's on which root is allowed to login
tty1
tty2
tty3
tty4
Programmet tcpd som man sett listat i /etc/inetd.conf
tillhandahåller loggning och åtkomstkontrollmekanismer för tjänster som det är
konfigurerat att skydda.
När det aktiveras av programmet inetd så läser det två filer som innehåller åtkomstregler och antingen tillåter det eller nekar åtkomst till servern som det skyddar.
Programmet söker i reglerna tills dess att det hittar det första mönstret som
passar. Hittar det inget passande mönster så antas det att åtkomst skall
tillåtas till vem som helst. Filerna som söks igenom i sekvens är:
/etc/hosts.allow, /etc/hosts.deny. Jag kommer att beskriva
dem i ordning. För en komplett beskrivning av detta så bör man titta i lämpliga
manualblad (hosts_access(5) är ett bra ställe att börja på).
Filen /etc/hosts.allow är en konfigurationsfil för programmet
/usr/sbin/tcpd. Filen innehåller regler som beskriver vilka datorer
som är tillåtna åtkomst till en tjänst på maskinen.
Filformatet är ganska enkelt:
# /etc/hosts.allow
#
# <service list>: <host list> [: command]
service listär en kommaseparerad lista av servernamn som denna
regeln gäller för. Exempel: ftpd, telnetd och fingerd.
host listär en kommaseparerad lista av datornamn. Man kan
även använda IP-adresser. Man kan dessutom ange datornamn eller adresser med
hjälp av 'wildcards' för att täcka grupper av datorer. Exempel: gw.vk2ktj.ampr.org för att täcka en enskild dator, .uts.edu.au för att täcka
alla datornamn som slutar med den strängen, 44. för att täcka alla
IP-adresser som börjar med de siffrorna. Det finns några särskilda tokens för
att förenkla konfigurationen, några av dessa är: ALL täcker alla datorer,
LOCAL täcker alla datornamn som inte innehåller en '.' dvs som är i
samma domän som din maskin och PARANOID täcker alla datorer vars namn inte
stämmer överens med sin adress (name spoofing). Det finns en sista användbar
token. EXCEPT tillåter dig att ange en lista med undantag. Detta visas i
ett exempel senare.
commandär en valfri parameter. Detta är det absoluta
filnamnet för ett kommando som skall exekveras varje gång denna regel används.
Det skulle till exempel kunna köra ett program som försöker identifiera vem som
är påloggad på den anslutande datorn, eller att generera ett mail eller någon
annan varning till en systemadministratör att någon försöker ansluta. Det finns
ett antal utökningar som kan inkluderas, till exempel: %h expanderar till
namnet på den anslutande datorn eller adress om den inte har något namn,
%d daemonnamnet anropas.
Ett exempel:
# /etc/hosts.allow
#
# Allow mail to anyone
in.smtpd: ALL
# All telnet and ftp to only hosts within my domain and my host at home.
telnetd, ftpd: LOCAL, myhost.athome.org.au
# Allow finger to anyone but keep a record of who they are.
fingerd: ALL: (finger @%h | mail -s "finger from %h" root)
Filen /etc/hosts.deny är en konfigurationsfil för programmet
/usr/sbin/tcpd. Filen innehåller regler som beskriver vilka datorer
som är nekade åtkomst till en tjänst på maskinen.
Ett enkelt exempel:
# /etc/hosts.deny
#
# Disallow all hosts with suspect hostnames
ALL: PARANOID
#
# Disallow all hosts.
ALL: ALL
Raden med PARANOID är egentligen redundant eftersom den andra raden
fäller allt i vilket fall. Någon av dessa rader skulle vara tänkbara beroende
på vilka krav man har.
Att ha ALL: ALL i /etc/hosts.deny och sedan specifikt ange de
tjänster och datorer som man vill ha i filen /etc/hosts.allow är den
säkraste konfigurationen.
Filen hosts.equiv används för att ge vissa datorer och användare
åtkomsträttigheter till konton på maskinen utan att behöva ange ett lösenord.
Detta är användbart i en säker omgivning där man kontrollerar alla maskinerna,
men det är en säkerhetsrisk i annat fall. Datorn är bara så säker som den
minst säkra av de datorer man litar på. För att maximera säkerheten så bör man
inte använda denna mekanismen och påverka sina användare att inte använda filen
.rhosts heller.
Många sajter är intresserade av att köra en anonym ftp server för att
tillåta andra personer att ladda upp och ladda ner filer utan att ha ett
särskilt användarid. Om man bestämmer sig för att tillhandahålla denna tjänst så
skall man se till att man konfigurerar sin ftp-daemon ordentligt för anonym åtkomst.
De flesta manualblad för ftpd(8) beskriver hur man skall göra
detta. Man bör alltid försäkra sig om att man följer dessa instruktioner. Ett
viktigt tips är att inte använda en kopia av sin /etc/passwd fil i
/etc katalogen för det anonyma kontot, se till att man tar bort alla
detaljer om konton som man inte måste ha, annars kommer man att vara sårbar mot
tekniker för lösenordscracking.
Att inte tillåta datagram att ens nå fram till din maskin eller servrar är ett utmärkt sätt att säkra systemet. Detta beskrivs i Firewall-HOWTO.
Här är några andra, potentiellt religiösa förslag som man kan tänka på.
oavsett dess popularitet så framträder sendmail daemonen med skrämmande jämna mellanrum på säkerhetsmeddelanden. Det är upp till en själv om man väljer att köra den.
man bör vara aktsam med dessa. Det finns alla möjliga olika sätt att utnyttja dessa tjänster. Det är svårt att hitta alternativ till en tjänst som NFS, men om man konfigurerar dem så skall man se till att vara försiktig med vem man ger mount-rättigheter till.