4.1.1. telnet og xhost

Hvis du på hven kører en X-baseret grafisk brugergrænseflade, og du vil køre X-programmer (grafiske programmer) fra maskinen "bohr", skal du starte med at fortælle maskinen "hven", at det er i orden, at maskinen "bohr" benytter dens display. Dette gøres ved at føje "bohr" til listen med godkendte X-klienter med kommandoen xhost:

[tyge@hven ~]$ xhost +bohr
bohr being added to access control list 

Dermed vil grafiske programmer fra "bohr" blive accepteret af "hven". Udelades maskinnavnet, betyder det, at alle maskiner kan vise grafik på din skærm. Lad være med det, da det sikkerhedsmæssigt er en ekstremt dårlig ide.

Lad os nu logge ind på "bohr" med telnet,

[tyge@hven ~]$ telnet bohr
Trying 192.168.0.2...
Connected to bohr.herne.dk.
Escape character is '^]'.
Debian GNU/Linux 2.1 bohr.herne.dk

bohr login: tyge
Password:

Efter at have skrevet brugernavn og adgangskode på bohr-maskinen får du en kommandolinje, og du kan udføre programmer på maskinen, som om du var logget ind lokalt.

For at kunne få de grafiske programmer, du starter på bohr, til at vise sig på hvens skærm er det nødvendigt at sætte systemvariablen DISPLAY:

[tyge@hven ~]$ export display=hven:0.0

Mange X-programmer kan dog også kaldes med "-display" som option.

Nu kan du køre dit X-program, f.eks. "xload", som om du sad på bohr. Programmet kører på bohr, men alt grafik vises på hven, og programmet styres fra hven.

[tyge@bohr tyge]$ xload -display hven:0.0 -geometry 60x60 -nolabel &

Problemet er ikke at du nu kan kalde grafik op på en anden skærm end din egen. Problemet er, at den adgang du har etableret med xhost så at sige går begge veje. I og med du har lavet xhost +bohr har alle brugere på bohr adgang til at læse og skrive fra og til dit dislay på "hven". Er bohr et multibrugersystem, og har en cracker, eller blot en nysgerrig kollega konto på maskinen, kan vedkommende køre kommandoen xwd -display hven:0.0 -root -out hven.dump efterfulgt af xwud -in hven.dump. Den første giver vedkommende et skærmdump af hven, den næste viser dette billede lokalt (på bohr). Alt hvad du kan se på skærmen på hven kan enhver på bohr tage et dump af.

Selv hvis hven har xhost - kan en bruger, der har lokal shell-adgang på hven, i visse tilfælde stadigvæk køre xwd-kommandoen! Vedkommende skal så blot være logget ind på hven, når kommandoen udføres - det kan ikke ske over nettet som beskrevet ovenfor.

Det bliver værre: Med xlswins kan man vise hvilke vinduer (xterm, netscape osv.) der er åbne på den anden maskine, og så dump disse enkeltvis med xwatchwin. Begge programmer er enten med i standard X, eller fås kvit og frit på internettet.

Og værre: Programmet xscan skal efter sigende kunne lave et tilsvarende trick, men med tastetryk. Direkte til en logfil, alt hvad der tastes på maskinen, der har xhost: brugernavne, adgangskoder, pgp-koder.

xhost er generelt en meget dårlig ide, og bør i alle tilfælde erstattes med SSH, der automatisk og transparent sørger for at sætte display og X rettigheder, så man hele tiden "har sit display med sig".

4.1.2. Pas på adgangskoder sendt over netværk

For at aflytte netværkstrafikken kan man hente programmet sniffit til Linux. Når det startes op vises alle kommunikationslinjer, såsom telnet- og ftp-forbindelser, mellem maskinerne på netværket. Det kommer an på opsætning af routere, firewalls, switche og hubs, hvor meget man reelt får at se. Sniffit kan hentes fra http://reptile.rug.ac.be/~coder/sniffit/sniffit.html.

Det er en udbredt misforståelse at man ikke kan aflytte switchede netværk - men kun netværk med hubs. Dette er forkert og aflytningen kan typisk foretages ved hjælp af ARP spoofing - eksempelvis med arpspoof programmet der følger med dsniff. Link: http://www.monkey.org/~dugsong/dsniff/. Dsniff kan opsamle og afkode traffik fra mange usikre protokoller. Sniffit og dsniff skal køres som root.

Lad os antage, at den ondsindede "nottingham" (192.168.0.3) lytter med på, hvad vi laver mellem "hven" (192.168.0.1) og "bohr" (192.168.0.2). Programmet sniffit startes i interaktiv tilstand med angivelse af hvilket netværks-interface, der skal lyttes på:

[root@nottingham root]#  sniffit -F eth0 -i 

hvor eth0 betyder første ethernet kort i maskinen, og i betyder interaktiv tilstand. Ud kommer nedenstående billede, hvor man ser, at maskinen med netværksadresse 192.168.0.1 (hven) har oprettet en forbindelse til port 23 på maskinen med netværksadresse 192.168.0.2 (bohr). Port 23 er den port, telnet lytter på. Port 3211, som man sender fra, er valgt blandt maskinens ledige porte, dvs. de porte, der ikke er nogen service, der lytter på. Der er valgt et portnummer, som er større end 1024, dvs. en ikke priviligeret port.

Trykkes return på en linje vil den blive markeret med "*LOGGED*", og det mindre vindue mod højre vil vise trafikken på den forbindelse. Først kommer login navn: "tyge", og efter to punktummer kommer adgangskoden i klar tekst: "qwe123". Der skal ikke stor fantasi til at forestille sig, at dette program nemt kan sættes til at dumpe samhørende brugernavne og adgangskoder ned i en fil over en periode, indtil der er gevinst.

Vi har vist, at man ikke skal bruge telnet til at kommunikere mellem to maskiner, hvis der er risiko for, at nogen lytter med, og slet ikke hvis man skal logge ind som root på maskinen. Det er simpelthen for nemt at lede efter loginnavn root og derefter få adgangskoden. Derfor har mange Linux-distributioner per default forhindret, at root logger ind via netværket. Red Hat 6.0, Debian 1.3 og SuSE 6.2 har filen "/etc/securetty", der indeholder de konsoller, hvor root må logge ind. Dette kan være "tty1" til "tty6", som er de tekst login konsoller, der normalt er på selve Linux-maskinen - dvs. ikke via netværket. Hvis man absolut vil tillade root login via netværk, kan man tilføje "0", "1" og opefter (for Linux-kerne 2.2.X) svarende til hvor mange logins, du forventer på maskinen fra netværket. Normalt er det ikke klogt at tillade direkte root login via netværk.

4.1.3. ftp

Hvis vi vil overføre filer fra "hven" (192.168.0.1) til "bohr" (192.168.0.2), er ftp et af de gennemprøvede og gamle værktøjer. Også her er der sikkerhedsproblemer. Vi sætter igen "nottingham" (192.168.0.3) til at køre sniffit som vist nedenfor. Denne gang sætter vi sniffit op til at vise alle pakker som ankommer til "bohr" (192.168.0.2), og man kan nemt se, hvad der sker.

[root@nottingham root]#  sniffit -t192.168.0.2 -a -F eth0

Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1299-192.168.0.2.21
 E . . 4 . . @ . @ . . . . . . . . . . . . . . . . . b . . . . . P . } x i !
 . . U S E R   r o b i n . .

Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1299-192.168.0.2.21
 E . . ( . . @ . @ . . . . . . . . . . . . . . . . . b ( . . . . P . } x . .
 . .

Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1299-192.168.0.2.21
 E . . 5 . . @ . @ . . . . . . . . . . . . . . . . . b ( . . . . P . } x N D
 . . P A S S   q w e 1 2 3 . .

På den første af de tre data-linjer kan man se login navn (tyge), og som vist på den sidste data-linje, vil man direkte kunne læse adgangskoden (qwe123). Ser man lidt nøjere efter, vises også ftp-porten, port 21. Port 1299 er ligesom ved telnet en ledig port, der vælges til denne session.

Som vi ser, er ftp også et meget usikkert program, hvor andre kan lytte med. Så brug det med omtanke. For en systemadministrator er paranoia ikke en sygdom, men en kvalifikation...

Det skal nævnes, at også resten af den nettrafik, du laver med telnet og ftp, kan læses i klar tekst via f.eks. sniffit. Starter du andre programmer, kan man se det. Laver du "su - root" og skriver "root"s adgangskode, er sikkerheden på den maskine væk, for "root"s adgangskode er ude, hvis du bliver aflyttet.

4.1.4. Remote login, remote shell og remote copy

To andre velkendte programmer i samme kategori er "rlogin" og "rsh". Programmerne virker næsten ens. Begge giver interaktivt login på maskinen, men rsh kan udføre en kommando samtidig med, at man logger ind. F.eks. vil den følgende kommando logge ind direkte fra hven til bohr og køre kommandoen "df" (som viser hvor fyldte dine diske er).

[tyge@hven ~]$ rsh bohr df

Nu prøver vi at køre sniffit på en rlogin session for at se, hvad man kan se. På maskinen "nottingham" kører vi sniffit:

[root@nottingham root]# sniffit -x -s192.168.0.1 -a -F eth0

Vi logger ind fra hven til bohr med kommandoen:

[tyge@hven ~]$ rlogin bohr
Password: qwe123
$ 

hvor adgangskoden naturligvis ikke kan ses på skærmen, når man taster den ind. Udklip fra sniffit's output:

TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA41   ACK (hex): 105DA03F
   FLAGS: -AP---   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ? s . @ . @ . F Q . . . . . . . . . . . . . . . A . ] . ? P . } x C .
 . . r o b i n . r o b i n . x t e r m / 9 6 0 0 .     


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA58   ACK (hex): 105DA040
   FLAGS: -A----   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ( s . @ . @ . F g . . . . . . . . . . . . . . . X . ] . @ P . } x } A
 . .


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA58   ACK (hex): 105DA041
   FLAGS: -AP---   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . 4 s . @ . @ . F J . . . . . . . . . . . . . . . X . ] . A P . } x . .
 . . . . s s . . . P . . . l


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA64   ACK (hex): 105DA04B
   FLAGS: -A----   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ( s . @ . @ . F U . . . . . . . . . . . . . . . d . ] . K P . } x } *
 . .


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA64   ACK (hex): 105DA04B
   FLAGS: -AP---   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ) s . @ . @ . F S . . . . . . . . . . . . . . . d . ] . K P . } x . !
 . . q


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA65   ACK (hex): 105DA04B
   FLAGS: -AP---   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ) s . @ . @ . F R . . . . . . . . . . . . . . . e . ] . K P . } x .
 . . w


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA66   ACK (hex): 105DA04B
   FLAGS: -AP---   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ) s . @ . @ . F Q . . . . . . . . . . . . . . . f . ] . K P . } x . .
 . . e


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA67   ACK (hex): 105DA04B
   FLAGS: -AP---   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ) s . @ . @ . F P . . . . . . . . . . . . . . . g . ] . K P . } x L .
 . . 1


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA68   ACK (hex): 105DA04B
   FLAGS: -AP---   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ) s . @ . @ . F O . . . . . . . . . . . . . . . h . ] . K P . } x K .
 . . 2


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA69   ACK (hex): 105DA04B
   FLAGS: -AP---   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ) s . @ . @ . F N . . . . . . . . . . . . . . . i . ] . K P . } x J .
 . . 3

Igen ser man tydeligt brugernavn og adgangskode blive sendt ukrypteret over nettet (se sidste tegn på hver linje). Man kan se, at rlogin på bohr bruger port 513, og at der på hven sendes fra port 1023.

Skal du kopiere filer mellem to maskiner, så er ftp som tidligere skrevet meget anvendt. Alternativt kan remote copy rcp anvendes. Skal du kopiere filen .emacs fra hven til bohr, sker dette med

[tyge@hven ~]$ rcp .emacs bohr:

Sikkerhedsmæssigt er rcp på linje med rlogin og rsh. Vi skal senere i artiklen vende tilbage til et fuldt krypteret alternativ til rcp.

Med rlogin, rsh og rcp kan man vælge, at login kan ske uden adgangskode. Dette gøres ved at sætte sit hostnavn og evt. brugernavn ind i filen ~/.rhosts i sit hjemmekatalog på den maskine, der skal logges ind på. Hvis du gerne vil kunne logge ind fra hven til bohr uden adgangskode, som brugeren tyge, kan .rhosts-filen i dit hjemmekatalog på bohr se sådan ud:

hven tyge

Der kan godt stå mange flere linjer med andre hostnavne. Brugernavnet kan udelades, idet brugeren sættes til den, hvis hjemmekatalog filen ligger i. Hvis filen er læsbar for alle, er det kun en bruger med samme brugernavn som sit eget, der kan logge ind fra en anden maskine. Er filen ikke læsbar for andre, kan man anføre linjer i .rhosts-filen med først maskinnavn og dernæst det brugernavn, som anvendes på den anden maskine. For at "peter" skal logge på ind på "hven" som "tyge", kan man således bruge rlogin hven -l tyge.

Den viste .rhosts-fil vil betyde, at du fra maskinen "hven" som brugeren "tyge", godt må komme ind på bohr som "tyge", uden adgangskode. Det kræver, at brugeren findes på begge maskiner, og ".rhosts" filen skal ligge i brugerens hjemmekatalog på den maskine, man prøver at logge ind på. Det er nemt og giver lynhurtig adgang til, at man hopper fra maskine til maskine og laver meget effektive arbejdsgange. Det lyder smart, men medaljen har en bagside. En med root-adgang på maskinen "nottingham" (eller andre maskiner i netværket) kan aflytte rsh/rlogin netværkstrafik et stykke tid, og derved finde ud af fra hvilken maskine og med hvilket bruger navn, man kan logge ind direkte. Derefter kan man med lidt snilde sætte maskinen "nottingham" lidt anderledes op, så "bohr" tror, at den er "hven".

Der kan imidlertid være situationer, hvor det kan virke mere sikkert at lade en bruger logge ind uden adgangskode fra en kendt host end at lade brugeren have en adgangskode. Har man tillid til sit interne netværk, og er det nødvendigt, at nogle brugere kan logge på en udsat maskine, kan man vælge, at disse brugere ikke har nogen adgangskode på den udsatte maskine. I stedet får de en stjerne ("*") i /etc/passwd, der hvor adgangskoden normalt ville stå. Dette vil forhindre dem i at logge ind fra andre maskiner end dem, der er angivet i deres ~/.rhosts fil i deres hjemmekatalog på den udsatte maskine. Når en bruger ikke har en adgangskode, kan man ikke bryde ind på den udefra ved at gætte eller knække adgangskoden. Men kan kun logge ind som denne bruger, hvis man kan overbevise maskinen om, at man logger ind fra en betroet maskine. Der kan i øvrigt læses mere om adgangskodebeskyttelse og håndtering i Kapitel 3.

Hvis man ikke tillader .rhosts-filer, vil der ved hver login sendes adgangskoder i klar tekst over nettet. Hvis der er .rhosts-filer, bliver der slet ikke sendt adgangskoder over nettet - i stedet for at give sin adgangskode skal man logge ind fra en betroet host. Ingen kan nu opsnappe adgangskoder - til gengæld kan de udgive sig for at være den betroede host. Stoler man ikke på sit interne netværk, eller er nogen sluppet ind, er begge dele nok lige dårligt.

Vi vil anbefale, at man i stedet for rlogin bruger et program, der krypterer login såvel som selve dataoverførslen, som f.eks. SSH giver mulighed for.

Som systemadministrator kan du se om dine brugere har .rhosts filer, og hvis det ikke er ønsket, kan du slette dem (og skælde brugeren ud). Hvis brugerne har hjemmekataloger under /home/, så kan dette gøres med

[root@hven root]# find /home/* -maxdepth 1 -name .rhosts -print;

Hvis man samtidigt vil slette de fundne .rhosts filer kan man anvende

[root@hven root]# find /home/* -maxdepth 1 -name .rhosts -print -exec rm {} \;

Det er enklere at disable brugernes egne .rhosts-filer ved, at man tilføjer parameteren -l efter in.rshd i filen /etc/inetd.conf og genstarter inetd-dæmonen.

Et andet argument imod at tillade ".rhosts"-filer er, at brugeren kan komme til at køre et program, som skriver til en fil uden hans viden. Filen kunne "~/.rhosts" og dermed give adgang til en ekstern bruger, som ikke behøver at have en konto på maskinen.

Et alternativ til "~/.rhosts" metoden er "hosts level equivalence" via filen "/etc/hosts.equiv". Dine brugere har ikke adgang til denne fil, og kun root kan rette i den. Root kan vælge at sætte en række hostnavne ind i denne fil eller evt. bare et plus. Det betyder, at disse hosts (+ betyder alle maskiner) har adgang til at udføre rlogin og rsh kommandoer uden adgangskode. Dette gælder alle brugere (dog ikke root) - brugeren skal dog findes på begge maskiner. Filen "/etc/hosts.equiv" kan være en bekvem løsning, men den er en bombe under systemsikkerheden - find en anden løsning, hvis du har et åbent eller halvåbent netværk.

Her i User Friendly fra den 12. december 1997 kan Greg fra Columbia Internet aflytte netværkstrafikken i forsvarsministeriet...

Fortsættelsen kan findes på http://www.userfriendly.org/cartoons/archives/97dec/19971216.html :-)