Skåne Sjælland Linux User Group - http://www.sslug.dk Förstasida   Anmälning   Postarkiv   Översikt   Kalender   Sök
 

Netværkssikkerhed - Services

Artikel 2 - Sikkerhed på Linux

Hanne Munkholm <hanne@geekgirl.dk> og Peter Toft <pto@sslug.dk>


Take One!
Forfatterne har copyright på artiklen, men udgiver den under OpenContent License.
Alle kan trykke artiklen, så længe OPL licensen overholdes, men vi vil gerne vide, hvor den bringes.

Licensen, der skal overholdes, kan findes på http://www.opencontent.org/opl.shtml.


Denne artikel er en del af en artikel serie om netværkssikkerhed som kan findes på http://www.sslug.dk/artikler/Linux_sikkerhed

TCP/IP-services

En Linux-maskine er bygget til netværksbrug. Hvis der ikke er noget netværk, laver den bare et for sig selv. Uanset om din Linux-maskine er på et netværk eller ej, tilbyder den en række netværksservices.

Er din computer koblet til netværk, er den udsat for misbrug udefra. Derfor er det vigtigt, at du forstår, hvilke services din maskine tilbyder, hvad disse services gør, hvem de tilbydes til, og at du i øvrigt har så få services kørende som muligt. Services, du ikke bruger, bør slås fra, idet de kan give andre adgang til maskinen. Hvis din Linux-maskine ikke er på et netværk, kan du egentlig være ligeglad med, hvilke services den tilbyder. Og dog - imorgen kommer den måske på lokalnet, og i overmorgen bliver lokalnettet sluttet til Internettet. Denne kendsgerning kommer bag på de fleste, og det er en god ide at gøre sig nogle sikkerhedsovervejelser på forhånd. Desuden har IBM foretaget en undersøgelse der viser, at over 40% af alle sikkerhedsangreb sker internt, hvilket også skal med i overvejelserne ved sikring af Linux-maskine.

Hvad er en service? Det er et program, der kører på din computer, som er beregnet til at andre kan koble sig til din computer og udveksle data. Det kan f.eks. være ftp, telnet, finger, pop-2, pop-3, rpc (herunder NFS), nntp og talk. Det kan også være http, smtp eller linuxconf.

Netværksprotokoller og porte

Før vi ser nærmere på, hvad Linux-maskinen kan servicere for et netværk, så lad os lige træde et skridt tilbage og se på, hvordan systemet er bygget op.

En Linuxmaskine vil normalt lave en masse ting samtidig, f.eks. håndtere emails, login brugere som kører programmer, samt have en web-server kørende. Derfor har man ikke bare kunnet nøjes med at hver enkelt computer har en IP-adresse. De forskellige services lytter på hver sin port, som har sit eget nummer. F.eks. bruges port 21 til ftp, port 22 til ssh (secure shell), port 23 til telnet, port 25 til smtp og port 80 til http. De mest kendte (well-known) portnumre, er tildelt af organisationen IANA (Internet Assigned Numbers Authority). I TCP/IP protokollen er det i TCP-datapakkerne, man finder information om afsender port og modtager port, imens IP-adressen på afsender og modtager er indeholdt i IP-transportlaget.

Porte er ikke fysiske men logiske konstruktioner, som anvendes i den måde, man sender data over netværket. Man skelner imellem TCP- og UDP-porte, som bruges til to forskellige typer dataoverførsler. TCP er forbindelsesorienteret. Den sender hele tiden kvitteringer frem og tilbage (handshakes), og når det går godt, behøver den ikke at få kvittering for sine data så tit. Hvis en datapakke går tabt, vil den blive gentransmitteret af protokollen. Der findes også en anden type IP-pakker med betegnelsen UDP. UDP anvendes oftest til hurtig letvægtsinformation, som kan accepteres at gå tabt i netværket såsom f.eks. NFS-forespørgsler. UDP-pakker, der går tabt vil kun blive retransmitteret, hvis applikationen sørger for det (typisk NFS).

Ofte tildeles en service både TCP og UDP porten med et givet nummer, selvom den kun bruger den ene.

User Friendly http://www.userfriendly.org/static ser på IP-pakker... User Friendly

Porte vælges ikke tilfældigt, men mange er standardiserede, så maskiner kan koble sig til en given port og dermed vide hvilken service, der kan findes. Hvis du læser filen /etc/services på en vilkårlig UNIX-maskine såsom Linux, kan du se hvilke porte, der bruges til hvad. Udsnit af en /etc/services:

ftp-data        20/tcp
ftp             21/tcp
telnet          23/tcp
smtp            25/tcp          mail
Først står navnet på servicen, derefter portnummeret og om det er tcp eller udp. Det sidste felt er til et evt. alias for denne service - i eksemplet er mail et alias for smtp.

Portnumre under 1024 kaldes priviligerede porte, og man skal være root for at kunne lytte på dem. Dette er lavet, så en klient, der kontakter en fremmed maskine på en port under 1024, kan regne med at få fat i en standard service og ikke et eller andet tilfældigt bruger-program. Se man services.

IP (Internet Protocol) er den netværksprotokol, man bruger på Internet-baserede netværk. Der findes mange andre. - Apple har deres egen AppleTalk-protokol, og Novell har IPX/SPX. Unix-maskiner bruger normalt IP, men har historisk også gjort brug af andre protokoller, f.eks. Digital's DECNET og Regnecentralens IMC. Linux-maskiner kan forstå mange af disse andre protokoller.

Daemons

En service kan enten køres som en selvstændig daemon, eller den kan styres af inetd. En daemon er en proces, som kører i baggrunden hele tiden, og venter på forespørgsler. Nogle services skal køre hele tiden og altid være klar, fordi det er nødvendigt med en hurtig responstid, eller at de ikke må være nede. Et eksempel er named, som laver navneoplag via DNS, og som skal være hurtigt. Andre eksempler på daemons er lpd (printer daemon), syslogd (logger system events) og sendmail. Vi kigger nærmere på sendmail i et senere afsnit. En anden daemon, som vi skal se på om lidt, er inetd, der bruges til at starte andre services efter behov.

Prøv at køre kommandoen

[robin@sherwood robin]$ ps aux |more
Denne kommando viser alle de kørende processer på systemet, og du vil kunne genkende processer som lpd, syslogd og inetd.

Inetd

En del services har kun brug for at køre relativt sjældent. Disse services er i Linux styret af inetd-programmet. I stedet for at have f.eks. in.telnetd kørende hele tiden, sættes inetd daemonen til at lytte efter, om der er telnet forespørgsler, og starter in.telnetd efter behov.
Hvilke services, der skal startes, bestemmes af filen /etc/inetd.conf
Eks.:

# These are standard services.
#
ftp    stream  tcp     nowait  root    /usr/sbin/tcpd  in.ftpd -l -a
telnet stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd
gopher stream  tcp     nowait  root    /usr/sbin/tcpd  gn

...

En service kan slås fra ved at udkommentere den linie, der starter den pågældende service. Eks.:

ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  in.ftpd -l -a

bliver efter udkommentering til

#ftp    stream  tcp     nowait  root    /usr/sbin/tcpd  in.ftpd -l -a

dvs. du indsætter et # foran den linie, der styrer den enkelte service. Dette gør, at denne service ikke bliver startet, og dermed vil din maskine ikke længere stille ftp-servicen til rådighed for andre maskiner på nettet.
Når du alligevel retter i /etc/inetd.conf, så udkommenter også linien med gopher, som er en ældre service, der i dag er helt erstattet af http.

For at ændringerne i /etc/inetd.conf skal træde i kraft, er det nødvendigt at genstarte inetd processen. Dette kan gøres på flere måder. Nogle distributioner har en struktur med startup scripts, der bruges til dette formål. Under Red Hat og Debian ligger de under /etc/rc.d/init.d hhv. /etc/init.d. Så kan man bruge startup scriptet til at genstarte inetd med.

Red Hat:

[root@sherwood robin]# /etc/rc.d/init.d/inet reload 
Debian:
[root@locksley robin]# /etc/init.d/netbase restart 

Der er dog også nogle Linux-distributioner, der ikke benytter denne struktur herunder Slackware, så vi har brug for en mere generel løsning. For en vilkårlig distribution kan man genstarte inetd ved at skrive:

[root@sherwood robin]# killall -1 inetd

Bemærk, at du i eksemplet kun slår din ftp server fra. Du kan stadig bruge ftp fra maskinen til andre maskiner. Man kan bare ikke længere bruge ftp udefra og ind til din maskine.

Inetd har den sikring, at en service bliver lukket ned i 10 minutter, hvis der kommer mere end 20 forespørgsler i sekundet. For nogle services er dette ikke acceptabelt. Det er derfor, programmer som named og syslogd kører udenom inetd som daemons.

Gennemgå de andre services i /etc/inetd.conf på samme måde som vist ovenfor. Undersøg, hvad der kører på din maskine, og find ud af om det er nødvendigt at de enkelte services kører. Hvis ikke, så slå det fra. En gylden regel er, at du hellere må køre for få end for mange services. Vi kommer senere til en gennemgang af de services, der findes i /etc/inetd.conf.

Husk slutteligt, at hvis du ender med at du slet ikke vil køre services via /etc/inetd.conf, så kan du lige så godt lukke selve inetd programmet ned.

TCP-wrappere

Adgangen til de services, der styres af inetd, kan på en nem måde konfigureres, så der er kontrol over hvem, der har adgang til at bruge de forskellige services, maskinen tilbyder.

Dette gøres ved at anvende en TCP-wrapper (tcpd), som er en agent, der bliver eksekveret i stedet for din normale server applikation. Den sørger for at requests om service bliver logget til syslogd, og den giver en stærk og fleksibel adgangskontrol. Man kan f.eks. også få den til at sende sig en email, hvis nogen udefra forsøger at få adgang via telnet til maskinen.

Tcpd virker sådan, at hver gang, der kommer en forespørgsel til inetd om at starte en service, er det tcpd, der får lov at starte den. Tcpd rapporterer til syslogd, hvad der sker, så det bliver skrevet i logfiler, og kontrollerer, om den kaldende host har adgang til den pågældende service. Hvis alt er i orden, starter tcpd servicen, og afslutter sig selv. Simpelt og elegant. Tcpd skal sættes ind i /etc/inetd.conf-filen i stedet for navnet på den service, der skal udføres. Navnet på serviceprogrammet gives som parameter til tcpd. I de viste linier fra /etc/inetd.conf ovenfor er tcpd allerede sat ind.

Adgang til din maskine

Adgangskontrol sker via filerne /etc/hosts.allow og /etc/hosts.deny.

Når tcpd skal finde ud af, om der er adgang til en service, checker den først /etc/hosts.allow. Hvis der her er givet explicit adgang, godkendes forsøget, og servicen bliver startet. Hvis der ikke står noget om den pågældene service i /etc/hosts.allow, læses nu /etc/hosts.deny. Hvis /etc/hosts.deny ikke indeholder noget, der forbyder den forsøgte adgang, vil forsøget blive godkendt. Det kan altså være en god ide at sætte sin /etc/hosts.deny op til at slutte med at afvise alt og alle. På den måde er man sikker på, at hvis der er noget, man ikke explicit har givet adgang til, så er der ikke adgang. På den anden side må man så sikre sig, at alle services, der skal kunne anvendes, er sat op i /etc/hosts.allow.

Filerne har det følgende format:

Eks. på en linie:
in.telnetd: 192.168.0.0/255.255.255.0

I /etc/hosts.allow ville denne linie tillade alle på lokalnettet 192.168.0.* at benytte telnet servicen. Stod linien i /etc/hosts.deny, ville det betyde, at de ikke kunne.

Eksempel på /etc/hosts.allow fil:

in.ftpd: 0.0.0.0/0.0.0.0
ALL: 192.168.0.2
ipop3d: 192.168.0.0/255.255.255.0

Denne /etc/hosts.allow vil tillade hele verden adgang til ftp, og giver host 192.168.0.2 lov til alt. Hosts på netværket 192.168.0.* har desuden adgang til pop3.

Eksempel på /etc/hosts.deny fil:

in.telnetd: 0.0.0.0/0.0.0.0

Denne /etc/hosts.deny fil sørger for, at ingen har adgang til telnet servicen. Dette gælder dog ikke for 192.168.0.2, da den allerede i /etc/hosts.allow har fået lov til alt herunder telnet.

En mere sikker /etc/hosts.deny ville være denne:

ALL: 0.0.0.0/0.0.0.0

Denne linie nægter alle adgang til alt, medmindre der specifikt er givet lov i filen /etc/hosts.allow. Bemærk dog, at du kan blive overrasket over ting, der ikke virker, hvis du har sat den restriktive /etc/hosts.deny-fil op. Vær omhyggelig med at sætte de nødvendige tilladelser op i /etc/hosts.allow. Hvis du har glemt at give adgang til noget, opdager du det sikkert, når du skal bruge det, eller når nogen brokker sig. Har du derimod glemt at spærre for noget, opdager du det måske først den dag, det bliver brugt til at bryde ind på dit system.
Med sikkerhed og paranoia i højsædet er det smart at have ovenstående linie i sin /etc/hosts.deny. Så bliver forespørgsler afvist, hvis du ikke har sat dem ind i /etc/hosts.allow. HUSK at en forespørgsel bliver godkendt, hvis du ikke har angivet andet.

Se i øvrigt man tcpd, og man hosts.allow eller man hosts.deny (de to sidste er samme fil).

Hvilke inetd services skal jeg slå fra?

Hvilke services, der kan undværes på dit system, afhænger af hvad det skal bruges til, og det er dig selv der må afgøre det. Men vi vil gennemgå de mest almindelige services, hvad de gør, om de er usikre, og hvad de evt. kan erstattes af.

Telnet

Telnet (telnetd) er en service der gør, at folk kan logge ind på maskinen ved hjælp af en telnet-klient. For at det er muligt at logge ind, skal man have et brugernavn og tilhørende password, som findes på maskinen. Når man er logget ind, kan man så udføre de tekstkommandoer, man plejer at kunne udføre, når man sidder foran maskinen. Telnet kører normalt på port 23, men kan sættes op til en anden port.

Telnet er en gammel sag, fra dengang i begyndelsen af Internets historie, hvor der kun var venner og ingen fjender på nettet. Det var mest forskere på universiteter, der havde adgang, og de ville ikke hinanden noget ondt. Alle kendte mere eller mindre hinanden, så hvis man lavede ballade var man hurtigt upopulær blandt ligesindede. Den slags moral kan vi ikke regne med mere.

Mange af de "gamle" services er usikre i dag, fordi de slet ikke er designet med sikkerhed i tankerne men alene stabilitet og fornuftig ydelse.

Telnet er først og fremmest usikker, fordi den sender brugernavn og password som klar ukrypteret tekst over nettet. Dvs., at det er lige til at læse for enhver, der måtte sidde og kigge på nettrafikken et sted imellem dig selv og den maskine, du logger ind på. Det er særdeles risikabelt at bruge telnet over Internet, hvor alle i princippet kan sidde og lytte med.

På en maskine, der har adgang til Internet, bør telnet slås fra, og erstattes med ssh. En grund til at beholde telnet kan dog være, at der findes telnet-klienter til stort set alle systemer. Hvis man har brug for at logge ind fra et system, hvortil der ikke findes en ssh-klient, kan det være nødvendigt at bruge telnet. Men det er risikabelt at lade en telnet service køre, hvis maskinen er på Internet. Så overvej, om der ikke er andre muligheder for at løse dine behov.

Hvis telnet skal køre, kan man sikre sig bedre med adgangskontrol (/etc/hosts.allow), ved at skifte password hver gang og ved ikke at have det samme password på andre maskiner i lokalnettet, så skaden ved indbrud trods alt begrænses.

Ftp

FTP (File Transfer Protocol) bruges, når man vil kopiere filer fra en maskine til en anden. FTP er ligesom telnet en af de gamle services, som er meget stabil men slet ikke sikker, idet login navn og password sendes i klar tekst. FTP er imidlertid ofte mindre farlig end telnet, da det meste ftp-trafik foregår som "anonymous ftp".

Når man skal ftp'e til en maskine, skriver man ftp maskinnavn (evt portnavn). F.eks.:

ftp locksley 37067

Ovenstående kommando vil forsøge at åbne en ftp forbindelse til host "locksley" port 37067. Så bliver man spurgt om loginnavn og derefter password. Går det godt, er man inde, og man kan downloade filer med kommandoen "get" og uploade med "put". Man kan desuden vælge, om det skal være binær eller ascii overførsel, skrive "ls" for at se indhold af katalog eller skifte katalog med "cd" mm.

Har man en rigtig bruger konto på maskinen, og er ftp sat op til det, kan man logge ind med sit normale brugernavn og password. Dette kan være relevant på f.eks. et lokalnet, hvor brugerne har behov for at flytte filer. Faren er her den samme som ved brug af telnet, nemlig at brugernavn og password sendes i klar tekst over nettet. Foregår dette over det usikre Internet, må vi bestemt anbefale at man bruger scp (secure copy fra ssh-pakken), hvis det er muligt. Alternativet er en speciel krypteret udgave af ftp, men dette kræver, at klienten kan tale samme sprog. Ftp kører normalt på port 20 (data) og 21 (kommandoer).

Det er imidlertid meget almindeligt, at en ftp server er sat op til at i acceptere brugernavnet "anonymous" eller "ftp". En del ftp servere er beregnet til kun at understøtte denne type login. Det kaldes anonymous ftp, og bruges ved "offentlige" ftp servere, hvor enhver kan hente de filer der er lagt frem. Her bruger man sin email adresse som password. Ved anonymous ftp kan alle logge ind, og det lyder måske farligt, men det er det kun, hvis man har sat sin ftp server forkert op.
Der sendes ikke brugernavne og passwords over nettet. Der sendes kun brugernavnet "anonymous", samt en email adresse, og det gør ingenting for serverens sikkerhed, at det bliver opsnappet.
Ved anonymous ftp har folk ikke brug for at kunne ret meget. De har brug for at kunne downloade og måske uploade. Og for at kunne gå hen i det katalog de skal uploade i og tilsvarende downloade fra, men stort set har de ikke brug for mere. De har ikke brug for at kunne bevæge sig rundt på hele maskinen, og det bør de ikke i have lov til. Dette undgås ved, at man "chroot'er" dem, dvs., at man f.eks. får kataloget /home/ftp til at se ud som roden af filsystemet (dvs. /). Brugeren kan ikke se resten af filsystemet og kun få ordrer kan anvendes. Dermed er serveren ikke nær så udsat, som hvis alle og enhver kunne logge "rigtigt" ind. Det er kun lidt, der skal sættes op, før et chroot'et environment virker (så bla. "ls" og "cd" virker) - nogle filer skal kopieres til /home/ftp/lib, /home/ftp/bin og /home/ftp/etc filer. Dette er gjort for dig i alle de store Linuxdistributioner.
Endelig bør man huske, at /home/ftp ikke bør været ejet af den bruger, folk logger ind som, dvs. anonymous eller ftp. Så kan de ændre environment, lave .rhosts-filer og andet, som kan bringe net-sikkerheden i fare.
Der er et par ting mere, man bør tænke på. For det første bør der ikke være læse og skriverettigheder på det samme katalog. Folk skal uploade et sted og download'e et andet, og serverens administrator skal så sørge for at uploadede ting evt. bliver tilgængelige til download. Dette skyldes, at hvis man bare lader sin server stå åben for up - og downloads uden kontrol, vil folk bruge den til piratsoftware, porno etc. Derfor er det smart først at lade det folk uploader være tilgængeligt for download, efter at man har kigget det igennem.

Der er en sidste ting, man skal være opmærksom på med en ftp server. Folk kan med vilje eller ved et uheld uploade så meget, at harddisken løber fuld. Det kan give Linuxsystemet problemer, så det skal man undgå. Det kan styres ved at lade uploadkataloget ligge på en partition (eller disk) for sig selv, eller ved i opsætningen af ftp serveren at lave begrænsninger for størrelsen af den uploadede mængde. Hvis folk med vilje fylder ens disk op, for at systemet skal holde op med at fungere, kaldes det et "denial of service attack" ("ude af drift angreb", også kendt som DOS attack) - maskinen nægter brugerene den service, som skulle leveres, fordi den er sat ud af drift af angrebet. Der findes også sikkerhedshuller til andre slags DOS attacks i nogle ftp-servere. Hvis du ikke skal bruge ftp, bør du slå den fra i /etc/inetd.conf.

ftp    stream  tcp     nowait  root    /usr/sbin/tcpd  in.ftpd -l -a
bliver til
#ftp    stream  tcp     nowait  root    /usr/sbin/tcpd  in.ftpd -l -a

Husk at "reloade" inetd.

Finger

Finger er et program, som viser hvem, der er logget på maskinen lige nu, hvornår de sidst var logget ind og hvor længe:

[robin@sherwood]$ finger robin
Login: robin                             Name:
Directory: /home/robin                   Shell: /bin/bash
On since Fri Jul  9 10:18 (CEST) on tty1    1 hour 14 minutes idle
     (messages off)
On since Sat Jul 10 01:13 (CEST) on tty2    1 hour 14 minutes idle
     (messages off)
On since Sat Jul 10 01:14 (CEST) on pts/0   1 hour 15 minutes idle
     (messages off)
On since Sat Jul 10 01:14 (CEST) on pts/2   26 minutes 11 seconds idle
     (messages off)
No mail.
No Plan.                    

Denne kommando kan køres fra andre maskiner mod din maskine, og kan anvendes af folk udefra til f.eks. at finde frem til en brugerkonto, der ikke har været brugt længe. Denne information bør du ikke give videre ud over maskinen selv. Derfor bør du i /etc/inetd.conf tilføje et "#" foran linien

finger  stream  tcp     nowait  root    /usr/sbin/tcpd  in.fingerd      

Finger er for de fleste fuldstændig unødvendig og en dum sikkerhedsrisiko at lade stå åben. Hvis du kan finde en undskyldning for, at du har brug for finger, så skal den i hvert fald kun være tilgængelig internt. Dvs., at adgang fra andre maskiner skal være spærret f.eks. med tcp-wrappers.

POP

Hvis din maskine ikke skal være mailserver, så udkommenter pop-2, pop-3 og imap i /etc/inetd.conf.

POP står for Post Office Protocol, og man bruger POP til at hente mail fra en mailserver og lægge i sin inbox på ens egen maskine. Bemærk, at selvom man slår POP-serveren fra lokalt, forhindrer det ikke, at man kan hente mail via sin udbyders POP-server. Da POP-daemonen skal skrive i brugernes hjemmekataloger, er den nødt til at køre som root. Dette er et sikkerhedsproblem. Ligesom med telnetd og ftpd er det desuden et stort problem, at POP kører med ukrypteret transmission af brugernavn og password.

Afhængig af hvad man skal bruge POP til, kan man sikre den. Hvis den kun skal bruges internt i ens firma, kan man enten

Man kan kryptere POP, men igen er dette en udvidelse, som kræver at alle klienter understøtter det. Det er ikke altid tilfældet. Der findes også en metode, der hedder APOP, som de fleste POP-programmer understøtter. Med APOP sendes passwordet krypteret. Dette er baseret på MD5-kodning, hvor der også er et time stamp involveret. Mere information kan findes i RFC 1725.

IMAP er en udvidet version af POP. Den kan sætte sig selv til at køre med brugerens privilegier noget af tiden i stedet for root, og man kan meget mere med den end med POP. F.eks. kan man med IMAP være flere brugere om én account, nøjes med at downloade headerene fra sine mails og lade resten ligge på serveren, etc.

For at slå POP og IMAP fra i /etc/inetd skal følgende linier udkommenteres:

pop-2   stream  tcp     nowait  root    /usr/sbin/tcpd ipop2d
pop-3   stream  tcp     nowait  root    /usr/sbin/tcpd ipop3d
imap    stream  tcp     nowait  root    /usr/sbin/tcpd  imapd

bliver til

#pop-2   stream  tcp     nowait  root    /usr/sbin/tcpd ipop2d
#pop-3   stream  tcp     nowait  root    /usr/sbin/tcpd ipop3d
#imap    stream  tcp     nowait  root    /usr/sbin/tcpd  imapd

Linuxconf

Anvender du en nyere Linux-distribution, kan det være, at du har programmet linuxconf kørende på din maskine på port 98. Du kan i /etc/initd.conf se, om du har linuxconf kørende ved at lede efter en linie, der indeholder ordet linuxconf. Den kan f.eks. se sådan ud:

linuxconf stream tcp wait root /bin/linuxconf linuxconf --http

Ganske vist kan linuxconf umiddelbart kun tilgås fra den lokale maskine og ikke fra netværket, men programmets egen usikrede webserver bør man ikke stole blindt på. Luk det, hvis du har et usikkert net. Tilsvarende argumenter kan anvendes overfor programmer såsom webmin, som giver et webinterface til systemadministration. Webmin er normalt ikke installeret, men skal hentes som særskilt pakke. For at værktøjet til webadministration kan accepteres på et usikkert net, skal SSL eller bedre kryptering indbygges i server og klient.

RPC og portmap

Ud over services, som konfigureres via /etc/inetd.conf, er der en klasse af services, som anvender RPC - Remote Procedure call. Vi vil se lidt på RPC og de mest kendte RPC-baserede services.

RPC går ud på, at man har et netværk af computere og kan få dem til at arbejde sammen som et system. Altså en slags "distributed computing". Man kan driste sig til at kalde det en tidlig forgænger for CORBA. Det overordnede princip er, at man kalder en funktion, som enten udføres af den lokale maskine eller en anden maskine i netværket.

I praksis betyder det, at der kan køre en række RPC services på din maskine. I stedet for at RPC services kører på et bestemt portnummer, får de tildelt et portnummer ved opstart. De registrerer sig hos portmapper daemonen, når de bliver startet. Portmapper daemon'en holder styr på hvilken RPC services der kører på hvilket portnummer, og videresender forespørgsler fra klienter til den rette service. RPC services behøver altså ikke køre på et bestemt portnummer, som klienten kender i forvejen. Klienten henvender sig til portmap på serveren og bliver "stillet igennem" til den rigtige service.

Dette er meget smart, men det komplicerer opsætningen af firewalls, da man ikke på forhånd ved, hvilken port den RPC service vil benytte.

Prøv at skrive
[robin@sherwood robin]$ /usr/sbin/rpcinfo -p localhost
   program vers proto   port
    100000    2   tcp    111  rpcbind
    100000    2   udp    111  rpcbind
    100005    1   udp    635  mountd
    100005    2   udp    635  mountd
    100005    1   tcp    635  mountd
    100005    2   tcp    635  mountd
    100003    2   udp   2049  nfs
    100003    2   tcp   2049  nfs
[robin@sherwood robin]$

(Dette er fra et Red Hat system. På Debian står der portmapper i stedet for rpcbind). Man kan se at NFS og mountd (NFS mount) kører, men ikke NIS.

Portmapperen kører normalt på port 111. Hvis man ikke har brug for, at nogle RPC services er tilgængelige udefra, kan man i sin firewall blokere port 111. Hvis ikke du ved, om du bruger RPC, så gør du det ikke. Fjern det, og stop portmapper servicen.

Det er i øvrigt ikke nok at stoppe portmapperen. Der findes værktøjer til at sniffe på alle åbne porte og dermed afsløre kendte RPC-services uden at spørge portmapperen.

Udefra kan man spørge maskinen hvilke netværksprocesser, som tilbydes. Et program, som er velegnet til dette, er "nmap", som kan download'es fra http://www.insecure.org/nmap. Prøv at køre nmap på din egen maskine:

[robin@sherwood robin]$ nmap localhost

Starting nmap V. 2.2-BETA4 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on localhost (127.0.0.1):
Port    State       Protocol  Service
25      open        tcp       smtp
37      open        tcp       time
53      open        tcp       domain
70      open        tcp       gopher
80      open        tcp       http
98      open        tcp       linuxconf
111     open        tcp       sunrpc
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
113     open        tcp       auth
139     open        tcp       netbios-ssn
143     open        tcp       imap2
513     open        tcp       login
514     open        tcp       shell
515     open        tcp       printer
635     open        tcp       unknown
2049    open        tcp       nfs
6000    open        tcp       X11

Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds

Man kan således udefra se, at sherwood har sunrpc til at lytte på port 111 - sunrpc er det samme som portmapperen. Processen - det kørende program - hedder portmap, men servicen hedder sunrpc. Bliv ikke forvirret, kært barn har mange navne. Kør ps -aux |grep portmap på dit system, og du kan indefra se, at portmapper daemonen kører.

Portmapper daemonen er et program, der hedder portmap (på nogle systemer hedder det rpcbind). Den bliver startet op i dine startup scripts (Red Hat: /etc/rc.d/init.d/portmap, Debian: /etc/init.d/netbase).

RPC er rent sikkerhedsmæssigt noget skidt. RPC er, som alt muligt andet fra dengang, designet med henblik på funktionalitet og stabilitet fremfor sikkerhed. RPC blev i sin tid lavet af Sun, men det blev hurtigt efterlignet af andre og vandt stor udbredelse. Problemet med RPC er, at metoden til autentifikation er baseret alene på brugerens UID og GID (User/Gruppe ID). RPC serveren tror på, at man er den, man giver sig ud for at være - uden yderligere validering af identitet. Udgiver man sig for at være en bruger med adgang, så bliver man lukket ind.

Sun kom senere med en mere sikker version, secure RPC, som bruger en kryptering baseret på DES. Secure RPC vandt aldrig den samme udbredelse, fordi den ikke blev efterlignet af andre (noget med at den anvendte krypteringsmetode var patenteret, og man skulle købe en licens for at bruge den).

Det er en dårlig ide at slå portmapper daemonen fra, før du har undersøgt hvilke programmer, der bruger den. NFS kører f.eks. via RPC, hvilket vi allerede så, da vi kørte rpcinfo programmet. Vi så faktisk alle de services, der har registreret sig hos portmapperen. Portmap er selv en af dem (kan hedde rpcbind). Alt efter hvor mange services, du har startet op, så kan du se, at services som nfs, mountd, nis, automounteren amd m.fl.kører på dit system via RPC.

Du er nødt til at tage stilling til, om du har brug for disse services, hvis ikke skal de slås fra. Hvis rpcinfo -p localhost kun viser portmapperen selv, evt fordi du har slået de andre services fra, så kan du godt slå portmap fra også. Men bemærk, at den skal slås til igen, hvis du vil anvende en af de services, der benytter RPC.

NIS og NIS+

NIS (Network Information Service) er en måde, hvorpå man kan nøjes med at have sin /etc/passwd fil og andre konfigurationsfiler (typisk en del filer fra /etc/) på én server. Klienterne får de nødvendige oplysninger af serveren via NIS. NIS er baseret på RPC. Med NIS slipper man for at vedligeholde sine konfigurationsfiler på en masse maskiner. Det gør det lettere at holde styr på sine brugere, grupper og hvem, der har lov til hvad. NIS er mere komplekst end UNIX bruger og gruppe rettighedssystemet og gearet til at holde styr på et stort netværk, hvor en bruger ikke må det samme på alle maskiner. NIS+ er en mere sikker version med lettere administration af store systemer (lettere opdatering af serveren etc).

Klient daemonen til NIS hedder ypbind, server daemonen ypserv og kommandoerne starter med yp (et levn fra dengang NIS hed yellow pages). Se i øvrigt http://www.sunsite.auc.dk/ldp/HOWTO/NIS-HOWTO-6.html.

NFS

NFS (Network File System) er et netværksfilsystem, som muliggør af flere maskiner kan dele den samme disk via netværket. Med NFS kan man eksportere hele eller dele af sit lokale filsystem, så en bruger kan mounte det fra andre maskiner over nettet. Det er dumt og unødvendigt at eksportere hele sin systemdisk - man bør nøjes med at eksportere de dele af filsystemet, der er behov for NFS-adgang til. NFS kører normalt på port 2049.

NFS er en RPC baseret service og er afhængig af at portmapperen kører. NFS startes af et startupscript (Red Hat: /etc/rc.d/init.d/nfs, Debian: /etc/init.d/nfs-server. Daemonerne hedder rpc.mountd og rpc.nfsd. mountd daemonen tager sig af selve mount processen, imens NFS daemonen tager sig af at åbne, lukke, læse og skrive filer etc.

Filsystemer, der skal være tilgængelige via NFS, angives i /etc/exports, f.eks.

/home/robin     192.168.0.0/255.255.255.252(rw)  

Denne linje eksporterer kataloget /home/robin/ med adgang for maskinerne 192.168.0.1, 192.168.0.2 og 192.168.0.3. Den eneste option, der er sat i ovenstående linie, er "rw" (read write). Der findes desuden nogle sikkerhedsrelaterede options til /etc/exports, men angiver du ingen, er de sat til det sikreste. Du skal således manuelt slå dem til for at få den mere usikre version. F.eks. "secure" option, som betyder at en forespørgsel skal komme fra en port mindre end 1024. Den er default slået til - vil man slå den fra, må man specificere "insecure". Beskrivelse af yderligere options findes i man exports.

Lad ikke dette forlede dig til at tro, at NFS er sikkert. Det er grundlæggende usikkert, da det kører via RPC, som du ikke kan betragte som sikker. Selve datatrafikken er heller ikke krypteret. Begræns din filsystemexport til det, du rent faktisk har brug for, og mount kun de drev du har brug for. Lad være med at mounte alle eksporterede drev på alle klientmaskiner, hvis der ikke er behov for det. Dette er i øvrigt klogt af hensyn til den almindelige driftstabilitet, idet du kun bliver afhængig af de maskiner, du skal bruge.

Hvis du ikke bruger NFS, så slå den fra. I Red Hat, Debian eller SuSE gøres det ved at fjerne symlinkene til startup scriptet i de forskellige runlevel kataloger /etc/rc.d/rcN.d / /etc/rcN.d, hvor N er runlevel (0-6). I nogle distributioner er det i stedet nødvendigt at fjerne de linier, der har med NFS opstart at gøre, i et større script, der køres, når maskinen startes, og som starter mange andre ting end NFS. Kører du Red hat, så kig på programmet chkconfig, som er et nemt og overskueligt værktøj til at styre, hvad der startes ved de forskellige runlevels.

Apache webserveren

Apache er verdens mest anvendte webserver. Den følger standard med Linux, og findes desuden til alle andre UNIX systemer. Ofte sker det under installationen af Linux, at Apache er installeret uden, at du har lagt mærke til det. Hvis din maskine ikke skal fungere som webserver, har du kun brug for Apache, hvis du vil lege med CGI-scripts, PHP eller andre smarte ting (hvor du for alvor skal passe på din sikkerhed). Check om du kører Apache eller en anden webserver på port 80 (kan være andre steder såsom port 8080) ved at skrive

[robin@sherwood robin]$ telnet MASKINNAVN 80

og så skriv f.eks. "?" og tryk retur. Ser du noget HTML kode, så er der en webserver. Apache er meget stabil og gennemtestet, men tænk over, om du behøver den.

Sendmail

Sendmail er en MTA (Mail Transfer Agent). Den bruges til at dirigere email rundt på systemet og lytter normalt også på smtp porten. Sendmail er et meget komplekst program at sætte op og meget komplekst at forstå. Hvis du er begynder, vil vi anbefale, at du ikke begynder at sætte dig dybdegående ind i sendmail lige nu, medmindre du har brug for det. Vi vil her kort forsøge at forklare, hvornår dit system anvender sendmail, hvorfor/hvornår det er farligt, og hvilke alternativer, der er.

Hvorfor er sendmail farlig?

Sendmail er en meget gammel sag, og den har et ret dårligt rygte, hvad sikkerhed angår, men er uhyre anvendt. Den har eksisteret i mange år og har i tidens løb haft mange slemme sikkerhedshuller. Se ftp://koobera.math.uic.edu/www/maildisasters/sendmail.html. Disse er dog blevet rettet efterhånden - men der kan komme nye. Da sendmail er et meget komplekst program, kan der også godt være nogle fejl, som der går lang tid, før nogen opdager. Sendmail kører med root-privilegier, d.v.s., den har adgang til hele systemet og kan gøre alt, hvad en administrator også kan gøre. Den fungerer på de fleste systemer som daemon, dvs., at den kører hele tiden og lytter på sin port (sendmail kører default på port 25), om der er noget mail, den skal tage imod. Hvis sendmail kører som daemon, og der er et sikkerhedshul i den, kan enhver ude fra nettet sende en forespørgsel til dens port og udnytte sikkerhedshullet. En af grundene til, at man ofte hører skrækhistorier om sendmail, er at den kører på langt de fleste maskiner, der håndterer email på Internet. Fordi den kører på så mange systemer, er det let nok at finde et system at udnytte, hvis man har fundet et sikkerhedshul. Det er dog ofte folk, der kører gamle versioner af sendmail, der er udsat. Hvis man hele tiden holder sin sendmail opdateret, er risikoen ikke så stor. Hent den nyeste version på http://www.sendmail.org/.

Skal jeg slå sendmail fra?

Det er desværre ikke så smart at slå sendmail helt fra - med mindre man i stedet installerer et sikrere alternativ som qmail eller postfix - da flere dele af systemet skal kunne levere mails internt på maskinen. Skal maskinen imidlertid ikke acceptere mail udefra, men kun fordele mail lokalt, kan man lade være med at lade sendmail køre i "daemon mode", hvor den lytter på en port. Man kan i stedet starte den i "queue mode". Sendmail kører stadig som en baggrundsproces, som med jævne mellemrum kommer frem og tømmer mailkøen. F.eks. en gang i timen, eller en gang hvert kvarter. Men den lytter ikke længere efter forespørgsler på port 25. Sendmail startes i "daemon mode", der tømmer mailkøen en gang i timen, ved at starte den med parametrene

sendmail -q1h
i stedet for
sendmail -bd -q1h

hvor -q1h betyder at køen tømmes en gang hver time, og bd betyder, at den startes i "daemon mode". Sendmail startes normalt fra et startup script. I Red Hat er det /etc/rc.d/init.d/sendmail. I SuSE skal man i /etc/rc.config ændre linien

SENDMAIL_ARGS="-bd -q30m -om"
til
SENDMAIL_ARGS="-q30m -om"

Parameteren -q30m betyder, at mail-køen tømmes hver 30. minut. Hvis man ikke vil køre sendmail i "daemon mode", kan man ændre i startup scriptet. Hvis man slet ikke vil køre sendmail, skal man fjerne det symlink, der er til sendmail startup scriptet under de forskellige runlevels kataloger. I Red Hat er det /etc/rc.d/rcN.d, hvor N er runlevel nummeret. På Debian hedder det /etc/rcN.d. Red Hat eksempel: Prøv at skrive

[robin@sherwood robin]$ ls -l /etc/rc.d/rc3.d |grep sendmail
lrwxrwxrwx   1 root     root           18 Oct  3  1998 S80sendmail -> ../init.d/sendmail

Der kan man se at sendmail bliver startet i runlevel 3. Hvis sendmail ikke skal startes, skal dette symlink slettes. Ligeså under de andre runlevels, og husk også at slette shutdown symlinkene til sendmail (dem der starter med K).

Man kan også vælge at køre sendmail i "queue mode", selvom man har brug for, at maskinen tager imod mails udefra. Dette kræver, at man anvender en anden smpt-daemon, f.eks. optuse smtpd (http://www.optuse.com). Den tager sig af indgående smtp og lægger posten over i sendmails kø, hvor sendmail så kan overtage. Vi kan også nævne smap/smapd, som er en del af TIS Internet i Firewall Toolkit (http://www.tis.com/research/software/fwtk/fwtk_over.html).

Sikring af sendmail

Hvis du kører sendmail som i "dameon mode", kan du sikre den. Du kan bl.a enable nogle security options i /etc/sendmail.cf - som er en ret forvirrende fil ved første blik. Man kan f.eks. sætte linien

O PrivacyOptions=authwarnings,needmailhelo, noexpn, novrfy

ind i sin /etc/sendmail.cf. authwarnings enabler email authentication warnings, så man får x-authentication-warning beskeder i sine mail headers, som f.eks.

X-Authentication-Warning: sherif.nottingham.dk: sherif owned process doing -bs. 

authwarnings er pr. default slået til. needmailhelo gør, at den maskine, der vil sende mail til sendmail, skal identificere sig før den får lov. novrfy forhindrer VRFY kommandoen, som bruges til at bekræfte, om et bestemt brugernavn findes på maskinen. noexpn forhindrer EXPN, som er en kommando, der bruges til at finde ud af hvilken bruger/program på systemet en email adresse reelt peger på, dvs., hvem et mail alias dækker over, hvem der modtager root mails på systemet etc.

Prøv at skrive telnet hostname 25, hvor hostname er navnet på en maskine, der har sendmail (evt. din egen linux-maskine - du behøver ikke 2 forskellige maskiner til dette). Sendmail bruger normalt port nummer 25. Så du kan faktisk kommunikere direkte med sendmail på maskinen ved at bruge telnet:

[robin@sherwood robin]$ telnet locksley 25
Trying 192.168.0.1...
Connected to locksley.herne.dk.
Escape character is '^]'.
220 sherwood.dk ESMTP Sendmail 8.9.3/8.9.3; Mon, 19 Jul 1999 22:47:59 +0200
VRFY robin
250 <robin@sherwood.dk>
EXPN robin
250 <robin@sherwood.dk> 

Vi fik at vide at maskinen kører sendmail version 8.9.3, at robin fandtes på maskinen, og at mail til robin går til robin. Skal andre også have dette - og måske mere følsomme ting - at vide? Hvad nu hvis robin bare var et mail alias for brugeren marion - kommer det andre ved? Skal andre kunne se, at roots mail også går til marion? Vi prøver samme kommando, når VRFY og EXPN er slået fra.

[robin@sherwood robin]$ telnet locksley 25
Trying 192.168.0.1...
Connected to locksley.herne.dk.
Escape character is '^]'.
220 sherwood.dk ESMTP Sendmail 8.9.3/8.9.3; Mon, 19 Jul 1999 22:53:17 +0200
VRFY robin
252 Cannot VRFY user; try RCPT to attempt delivery (or try finger)
EXPN robin
502 Sorry, we do not allow this operation

Der er flere muligheder. Man kan nøjes med at slå expn og vrfy fra, indtil den fremmede maskinen har identificeret sig selv. Se http://hoth.stsci.edu/man/man1m/sendmail.html.

Mail relaying

Derudover skal man slå mail relaying fra. Det gøres i accessfilen - /etc/sendmail.cf indeholder oplysningerne om, hvor den ligger. På Red Hat hedder den /etc/mail/access.
Der må gerne stå f.eks.

localhost.localdomain           RELAY
localhost                       RELAY

- dette tillader relaying for den lokale maskine. Men der må ikke stå andre linier med RELAY. (Man kan f.eks. også bruge IP-adressen på sit interne netværk og tillade intern mail relaying). Hvis man tillader extern mail relaying - dvs. at folk, der logger ind udefra, kan sende mails, så det ser ud som om, de er sendt indefra - så kan man risikere, at spammere bruger en som afsender for deres spam. Så selvom det til tider kunne være praktisk at logge ind på sin computer, når man er ude, og sende email med sin "hjemmeadresse" som afsender, så tillader Internetsikkerheden i dag ikke dette. Man bliver meget upopulær, hvis nogle garvede internet folk opdager, at man har mail relaying slået til. Man kan komme på deres sortlister, så en masse folk ikke kan modtage mail fra ens domæne etc. Man kan dog også træffe andre foranstaltninger imod mail relaying end at slå det fra i sendmail.

Der skal også nævnes, at der findes interessante alternativer til sendmail: qmail (http://www.qmail.org) og postfix (http://www.porcupine.org/postfix-mirror/start.html). Begge er fra begyndelsen designet med tanke på sikkerhed. De er bl.a.sikrere, fordi smtpd her er en selvstændig proces, som ikke kan skrive til nogen filer. Hver lille delopgave foretages af et separat program, som kun har en snæver, veldefineret funktion. Sendmail er derimod designet som et enkelt do-it-all program. Det er en grundlæggende i designfejl, som gør den håbløs i sikkerhedssammenhæng. Vi kommer ikke her nærmere ind på qmail og postfix, men har man et i seriøst mailserver behov, kan det godt anbefales at kigge nærmere på disse to programmer.

Andre services

Udenfor de forrige kategorier falder XDM og DNS:

Xdm-lignende login

En service man ikke må overse, er XDM, som er en X-login daemon, der normalt kører på UDP port 177. Det er muligt at forbinde sig til en kørende XDM-server, dvs. direkte til X-systemet, ved at skrive "X -query SERVER". Alt efter Linux-distribution, kan du have xdm, kdm (KDE's XDM) eller gdm (GNOME XDM) kørende. Hvis XDM kører, starter maskinen op med en grafisk login menu i stedet for den almindelige konsol mode login prompt. Hvis du er i konsol mode, kan du se, om du har en X-login daemon kørende, ved at trykke Alt-F7. Er der en menu, hvor du kan skrive loginnavn og password ind, så kører du en XDM-lignende service.

På din hjemmecomputer kan det grafiske login være meget rart, men hvis du administrerer en server, er det en uacceptabel sikkerhedsrisiko. Luk den ned og sørg for, at dette ikke automatisk startes op fra startupscriptet i /etc/rc.d:

I øvrigt bør man slet ikke køre X på en server, hvis det kan undgås. Kan du af en eller anden grund ikke undgå at have XDM kørende, så bør du som minimum læse http://metalab.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html. Dette sted beskriver, hvordan du med "magic cookies" kan gardere dig mod sådan noget som spoofingangreb, hvor andre på nettet prøver at tage din identitet. Det kan nævnes, at vi i Artikel 4. Remote login og netværksaflytning ser nærmere på, hvordan du kan transmittere X-programmer fuldt krypteret. Denne løsning er klart at foretrække, hvis man ser på netværks-sikkerheden.

DNS

DNS (Domain Name System) er navne service, som anvendes til at få oversat et hostnavn f.eks. sunsite.auc.dk til dets IP-nummer. DNS er en af de store grundpiller i Internet og derfor også meget gennemprøvet men ret komplekst. Der er blevet fundet sikkerhedshuller i DNS-programmerne, f.eks. var der en fejl i Red Hat 4.2, hvor man kunne sende en meget stor datamængde til en nameserver, hvilket medførte, at den blev "overrasket" (buffer overflow problem) og fejlede. Man kunne derefter mirakuløst udføre rootkommandoer på systemet! Resultatet var fatalt. Det er nok ikke sandsynligt, at du kører en nameserver (på port 53) uden at vide dette, men du kan verificere dette ved at skrive.

[robin@sherwood robin]$ ps aux |grep named
Du skal kun køre et nameserverprogram, hvis maskinen reelt skal bruges som nameserver.

Epilog

Selvom vi har været inde på mange services her, har vi ikke været inde på alle. Programmer som nmap og kommandoer som rpcinfo og netstat kan vise dig hvilke porte, der benyttes, hvilke services, der kører, og hvilke netværksforbindelser, der er etableret. Brug også ps aux flittigt og se hvilke processer, der rent faktisk kører på dit system. Sørg for at alle unødvendige services i /etc/inetd.conf er kommenteret ud, og check dine runlevel kataloger. Læs manualsiderne til de services, du vælger at køre. Følg med på sikkerhedslister på Internet, og følg med i fejlrapportet for din Linuxdistribution. Tænk dig om, og hold øje med dine logfiler. Og læs de resterende artikler i denne serie.


Revisionshistorie

 
Förstasida   Anmälning   Postarkiv   Översikt   Kalender   Sök

 
 
Fel och synpunkter angående webb-sidorna skickas till <www_admin>. Senaste ändring 2004-03-07, klockan 21:25 .
 

Denne side vedligeholdes af Hanne Munkholm (<hanne@sslug.dk>)