5.1.1. /var/log/messages

Den vigtigste log-fil er /var/log/messages, hvor mange af de vigtige systeminformationer gemmes, såsom

• hvem der loggede ind på maskinen hvornår

• hvem der skiftede identitet med su

• hvornår maskinen blev genstartet

• internetopkoblinger med ppp

• start og stop af tjenester, såsom NFS

• fejl i kernemoduler

Lad os se på nogle eksempler som alle er brudstykker fra /var/log/messages. Vi ser, at det kræver lidt øvelse at overskue alt i messages-filen, men modsat er der mange nyttige informationer om systemets drift. Lad os først se på Eksempel 5-1 nedenfor, som viser de linjer, der kommer i messages-filen, når systemet startes.

Jun 30 20:17:45 hven syslogd 1.3-3: restart.
Jun 30 20:17:45 hven syslog: syslogd startup succeeded
Jun 30 20:17:45 hven syslog: klogd startup succeeded
Jun 30 20:17:45 hven kernel: klogd 1.3-3, log source = /proc/kmsg started.
Jun 30 20:17:45 hven kernel: Inspecting /boot/System.map-2.2.5-15
Jun 30 22:17:16 hven rc.sysinit: Loading default keymap succeeded 
Jun 30 22:17:16 hven rc.sysinit: Setting default font succeeded 
Jun 30 22:17:16 hven swapon: swapon: warning: /dev/hdb1 has insecure permissions 0660, 0600 suggested 
Jun 30 22:17:16 hven rc.sysinit: Activating swap partitions succeeded 
Jun 30 22:17:16 hven rc.sysinit: Setting hostname hven.galaxy.dk succeeded 
Jun 30 22:17:16 hven fsck: /dev/hda3: clean, 56029/311296 files, 748112/1242864 blocks 
Jun 30 22:17:16 hven rc.sysinit: Checking root filesystem succeeded 
Jun 30 22:17:16 hven isapnp: Board 1 has Identity 70 01 00 00 00 01 00 93 05:  ALS0001 Serial No 16777216 [checksum 70] 
Jun 30 22:17:16 hven isapnp: ALS0001/16777216[0]{ALS100 Media Audio Controller}: Ports 0x220 0x330; IRQ5 DMA1 DMA5 --- Enabled OK 
Jun 30 22:17:16 hven isapnp: /etc/isapnp.conf:293 -- Fatal - resource conflict allocating 8 bytes of IO at 388 (see /etc/isapnp.conf) 
Jun 30 20:17:47 hven kernel: Loaded 6721 symbols from /boot/System.map-2.2.5-15.
Jun 30 20:17:47 hven kernel: Symbols match kernel version 2.2.5.
Jun 30 20:17:47 hven kernel: Loaded 146 symbols from 11 modules.
Jun 30 20:17:47 hven kernel: Linux version 2.2.5-15 (root@porky.devel.redhat.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Apr 19 22:21:09 EDT 1999 
Jun 30 20:17:47 hven kernel: Detected 120003903 Hz processor. 
Jun 30 20:17:47 hven kernel: Console: colour VGA+ 80x25 
Jun 30 20:17:47 hven kernel: Calibrating delay loop... 47.82 BogoMIPS 
Jun 30 20:17:47 hven kernel: Memory: 63140k/65536k available (996k kernel code, 412k reserved, 928k data, 60k init) 
Jun 30 20:17:47 hven kernel: VFS: Diskquotas version dquot_6.4.0 initialized 
Jun 30 20:17:47 hven kernel: CPU: Intel Pentium 75 - 200 stepping 06 
Jun 30 20:17:47 hven kernel: Checking 386/387 coupling... OK, FPU using exception 16 error reporting. 
Jun 30 20:17:47 hven kernel: Checking 'hlt' instruction... OK. 

Ud fra den ottende linje kan vi se, at harddisk partitionen /dev/hdb1 ikke har fornuftige læse/skriverettigheder. Vi kan også se, et ISA lydkort ALS100 bliver detekteret af isapnp-pakken, men at det ikke er konfigureret rigtigt. Derefter en del information om selve maskin-typen, CPU-hastighed (det er fra en Pentium 120 MHz PC). Du bør lige tjekke fra tid til anden, at der ikke logges fejl, såsom problemet med forkerte læse/skrive rettigheder eller hardwareproblemer. I øvrigt kan den opmærksomme læser se, at nogle tidspunkter er kl. 22 og andre 20. Dette skyldes, at nogle dele af systemet kører med lokaltid og andre med GMT. Vi kan også her nævne, at du med kommandoen "dmesg" kan se de fleste af de systemmeddelelser, som blev vist på skærmen under systemopstart. Tilsvarende information findes i /var/log/dmesg.

Eksempel 5-2 viser hvordan telnet, ftp og SSH logins gemmes i messages-filen. Den 3. juli kl. 10.06 kommer brugeren robin ind fra IP nummer 192.168.0.10 via secure shell (SSH). To minutter efter logges der ud igen. Dagen efter er det en telnet login, som går igennem PAM-adgangskodetjek (PAM_pwdb). Kun et minut er robin inde. Endelig er brugeren tuck kommet ind via ftp (ftpd) den 4. juli og kun blevet fire sekunder.

Jul  3 10:06:51 hven sshd[763]: log: Connection from 192.168.0.10 port 1023
Jul  3 10:06:57 hven sshd[763]: log: RSA authentication for robin accepted.
Jul  3 10:06:57 hven sshd[765]: log: executing remote command as user robin
Jul  3 10:08:58 hven sshd[763]: log: Closing connection to 192.168.0.10
Jul  4 23:07:07 hven PAM_pwdb[24298]: (login) session opened for user robin by (uid=0)
Jul  4 23:08:10 hven PAM_pwdb[24298]: (login) session closed for user robin
Jul  4 23:10:28 hven ftpd[24757]: FTP LOGIN FROM tuck @ vinglad.linus.dk [192.168.0.199], 
Jul  4 23:10:32 hven ftpd[24757]: FTP session closed

Lad os dernæst se på en internetopkobling via modem (ppp). Vi kan i de følgende linjer fra messages-filen se, at brugeren har koblet op via "/dev/ppp0". De to linjer med identd skyldes secure shell. Der er lavet en SSH-login til www.sslug.dk under opkoblingen. De sidste linjer viser, at der er sendt 55395 bytes til maskinen og 80884 bytes fra maskinen under opkoblingen.

Aug 18 21:28:35 hven ifup-ppp: pppd started for ppp0 on /dev/modem at 115200
Aug 18 21:28:36 hven pppd[10800]: pppd 2.3.7 started by root, uid 0
Aug 18 21:29:03 hven pppd[10800]: Serial connection established.
Aug 18 21:29:03 hven pppd[10800]: Using interface ppp0
Aug 18 21:29:03 hven pppd[10800]: Connect: ppp0 <--> /dev/modem
Aug 18 21:29:11 hven pppd[10800]: Remote message: Login Succeeded
Aug 18 21:29:12 hven pppd[10800]: local  IP address 212.54.78.125
Aug 18 21:29:12 hven pppd[10800]: remote IP address 212.54.64.66
Aug 18 21:29:16 hven identd[10930]: Connection from www.sslug.dk
Aug 18 21:29:16 hven identd[10930]: from: 192.38.71.98 ( www.sslug.dk ) for: 1132, 25
Aug 18 21:35:14 hven pppd[10800]: Terminating on signal 15.
Aug 18 21:35:14 hven pppd[10800]: Connection terminated.
Aug 18 21:35:14 hven pppd[10800]: Connect time 6.2 minutes.
Aug 18 21:35:14 hven pppd[10800]: Sent 80884 bytes, received 55395 bytes.
Aug 18 21:35:14 hven pppd[10800]: Exit.

Det sidste eksempel fra messages-filen er et sted, hvor man kan se, at bruger nummer 500 (robin) skifter bruger-ID over til root for at kunne stoppe sendmail. Derefter logges det at su-root sessionen afsluttes.

jul 26 22:15:04 hven PAM_pwdb[4220]: (su) session opened for user root by (uid=500)
jul 26 22:15:25 hven sendmail: sendmail shutdown succeeded
jul 26 22:15:41 hven PAM_pwdb[4220]: (su) session closed for user root

/var/log/messages kan blive meget stor. Da alle systemhændelser bliver logget i mellem hinanden, kan det således være svært umiddelbart at skelne de interessante beskeder i mængden.

5.1.2. Rotering af log-filer

Du kan opleve at finde filer i /var/log, der f.eks. hedder messages.1 og messages.2, eller messages.1.gz. Dette skyldes, at man på Linux-systemer ofte har et cron-job sat op til at rotere logfilerne, herunder messages-filen. Dette sker f.eks. en gang i døgnet eller en gang om ugen. I så fald indeholder /var/log/messages kun det nyeste log-information, som er sket siden sidste rotation.

Under Red Hat styres rotering med af logfiler med logrotate-pakken, som konfigureres i filen /etc/logrotate.conf

5.1.3. /var/log/secure

Fordi vigtig information så nemt kan drukne i anden information i messages-filen, findes filen /var/log/secure, som kun indeholder sikkerhedsrelateret information. Eksempel 5-5 viser /var/log/secure filen. Brugerne robin og john logget ind via terminal tty1 nogle gange, og en telnet og en ftp login findes i bunden af filen. /var/log/secure kan være en meget vigtig fil at se igennem jævnligt.

Aug 15 14:45:16 hven login: LOGIN ON tty1 BY robin
Aug 16 15:13:53 hven login: LOGIN ON tty1 BY john
Aug 16 21:00:55 hven login: LOGIN ON tty1 BY robin
Aug 17 11:22:41 hven login: LOGIN ON tty1 BY john
Aug 17 17:45:16 hven login: LOGIN ON tty1 BY robin
Aug 18 07:11:29 hven login: LOGIN ON tty5 BY robin
Aug 18 12:49:56 hven login: LOGIN ON tty1 BY john
Aug 18 20:17:07 hven login: LOGIN ON tty1 BY robin
Aug 18 23:07:03 hven in.telnetd[24297]: connect from 192.168.0.1
Aug 18 23:07:07 hven login: LOGIN ON 3 BY robin FROM linus
Aug 18 23:10:24 hven in.ftpd[24757]: connect from 192.168.0.1

5.1.4. /var/log/maillog

En anden vigtig fil er /var/log/maillog, hvor information om post til og fra maskinen gemmes. Vi kan i Eksempel 5-5 se, at robin sender en besked fra hven.galaxy.dk til <sslug-teknik@sslug.dk>. Postloggen kan nemt blive ekstremt stor og svær at overskue.

Jun 18 23:00:42 robin sendmail[1966]: XAA01966: 
from=<robin@hven.dk>, size=496, class=0, pri=30496,
nrcpts=1, 
msgid=<Pine.LNX.4.10.9906182300010.662-100000@hven.dk>, 
proto=ESMTP, relay=robin@localhost
Jun 18 23:00:44 hven sendmail[1968]: XAA01966: 
to=<sslug-teknik@sslug.dk>, delay=00:00:02, xdelay=00:00:02, 
mailer=esmtp, relay=mail.sslug.dk. [192.38.71.98], 
stat=Sent (ok 929739581 qp 27375)

5.1.5. Rapporting af log-meddelelser

I stedet for at læse logfiler direkte kan man installere programmer, der kan sortere i logfilerne og fremhæve vigtige ting. Vi vil nu se nærmere på LogWatch, der kan hentes fra http://www.kaybee.org/~kirk/html/linux.html.

LogWatch sættes normalt op til at køre en gang i døgnet via Linux maskinens crontab system. LogWatch skanner alle log-filerne og sender en samlet rapport til systemadministratoren som et e-brev. I filen /etc/log.d/logwatch.conf er det muligt at konfigurere LogWatch. Det kan f.eks. anbefales at sætte parameteren "Detail" fra "Low" til "High", så alle login og "su" hændelser rapporteres.

LogWatch kan f.eks. give følgende e-brev tilbage for en dags trafik for en maskine, der ikke kører telnet, men som tillader folk at hente filer over FTP og at logge ind med SSH. Man kan se, at ftp dæmonen har overført 5 Mb, og filerne er vist sammen med navnet på modtagermaskinen. På maskinen har der i PAM_pwdb (dvs. adgangskodehåndteringen) været en række skift af bruger-id. Desuden er alle SSH opkoblinger til maskinen vist, derefter cron kørsler og endelig de problemer, som navneserveren har haft igennem dagen. Let og overskueligt at se igennem. Har man pludselig logins fra uventede domæner, er det noget, der skal kigges nærmere på.

 --------------------- ftpd-messages Begin ------------------------ 

Anonymous FTP Logins:
   laptop.etsted.dk (192.168.0.10) : IE40user@ - 4 Time(s)
   dbserver.etandetsted.dk (192.168.0.98) :  mozilla@ - 1 Time(s)
   dbserver.etandetsted.dk (192.168.0.99) :  getright@ - 2 Time(s)

 ---------------------- ftpd-messages End ------------------------- 



 --------------------- ftpd-xferlog Begin ------------------------ 
TOTAL KB OUT: 5339KB (5MB)
TOTAL KB IN: 0KB (0MB)

Outgoing Anonymous FTP Transfers:
   /pub/linuxbog.pdf.gz -> dbserver.etandetsted.dk
   /pub/utils/cvsstat -> 192.168.1.10
   /pub/linuxbog.pdf.gz -> 192.168.10.12
   /pub/videoclips/Linux1601.mpg -> ns.etandetsted.dk
   /pub/utils/cvs2html -> cvs.etandetsted.dk

 ---------------------- ftpd-xferlog End ------------------------- 



 --------------------- Identd Begin ------------------------ 
Identd Lookups:


 ---------------------- Identd End ------------------------- 



 --------------------- PAM_pwdb Begin ------------------------ 

SU Sessions:
      robin(uid=71) -> john - 1 Time(s)
      john(uid=0) -> root - 3 Time(s)
      robin(uid=0) -> root - 5 Time(s)
      sherif(uid=0) -> root - 1 Time(s)
      john(uid=5192) -> charles - 1 Time(s)
      robin(uid=5192) -> charles - 5 Time(s)

Opened Sessions:
   Service: su
      User nobody - 1 Time(s)
      User news - 1 Time(s)

 ---------------------- PAM_pwdb End ------------------------- 



 --------------------- SSHD Begin ------------------------ 

Connections:
   laptop.etsted.dk (192.168.0.10) : 1 Connection(s)
   dbserver.etandetsted.dk (192.168.0.98) : 27 Connection(s)

 ---------------------- SSHD End ------------------------- 



 --------------------- Cron Begin ------------------------ 

Commands Run:
   User root:
      /usr/bin/mrtg /etc/mrtg/mrtg.cfg >/dev/null 2>&1: 288 Time(s)
      /usr/local/bin/daily_backup: 1 Time(s)
      run-parts /etc/cron.daily: 1 Time(s)
      run-parts /etc/cron.hourly: 24 Time(s)


 ---------------------- Cron End ------------------------- 


 --------------------- Named Begin ------------------------ 

**Unmatched Entries**
   Response from unexpected source ([157.151.95.204].53): 1 Time(s)
   bad referral (US !< RESTON.VA.US): 6 Time(s)
   bad referral (US !< SF.CA.US): 6 Time(s)

 ---------------------- Named End ------------------------- 

Et alternativ til LogWatch er logcheck, som kan hentes fra http://sourceforge.net/projects/sentrytools/ Ideen er den samme, og virkemåden er umiddelbart også ens. Blot er formatteringen af log-rapporter ikke sorteret så elegant som med LogWatch. Prøv begge programmer, og vælg selv dit foretrukne.

Problemet med programmer som LogWatch og logcheck er bl.a., at programmet normalt køres en gang per døgn (dette kan ændres). Ergo kan et eventuelt indbrud sløres, f.eks. ved at personen blot sletter linjer i log-filerne svarende til egen adfærd. Det eneste alternativ er nok, at væsentlig log-information skrives til en enhed som kun accepterer tilføjelser - ikke redigering af data. Nogle bruger f.eks. en almindelig gammel linje-printer, som udskriver log-meddelelser straks efter hændelsen.

5.1.6. Alarmer

Du kan lave dine egne hjemmelavede alarmer på dit Linux-system. Har du en maskine med meget få logins, kan det være interessant, at der afsendes et e-brev til en fast ekstern modtager, hver gang der laves login på din maskine. Brevet kan f.eks. sendes til en mobiltelefon eller pager, for at du med det samme kan få at vide, når der er gæster. Der er mange muligheder for, hvordan dette kan gøres. Den enkle måde er at tilføje følgende til filerne /etc/csh.login og /etc/profile.

mail < /dev/null > /dev/null -s "login at `date`" robin@hven.herne.dk

Derved får "robin@hven.herne.dk" en besked med tidspunkt for login, uden at den, der logger ind, kan se det. Personen kan dog bagefter selv læse /etc/csh.login og /etc/profile og se, at der er lagt en fælde, og evt. vælge at forsvinde. En interessant beskrivelse af indbrud, alarmer og fælder kan læses på http://www.ja.net/CERT/Cheswick/berferd.txt

En anden mulighed er at bruge en almindelig brugerkonto på systemet til at have et crontab job, der køres hvert minut, og ser hvem der er logget ind (via "who") og sender resultatet til din eksterne maskine, hvis der er brugere logget ind. Man vælger selv hvordan den type og niveau af alarm der sættes op, alt efter hvor paranoid man er :-)

Man skal dog passe på, at de alarmsystemer, der sættes op, ikke åbner et nyt sikkerhedshul. Som eksempel kan det være, at du har ændret kildeteksten til /bin/login, så der logges mere information til f.eks. /var/log/messages, men du kom måske ved et uheld til at få en buffer overflow fejl, som efterfølgende udnyttes af en ihærdig cracker. Det er heldigvis sådan, at den person, som bryder ind på din maskine, ikke i forvejen ved, hvor du lægger fælder, og forhåbentlig ikke har en chance for at vide, hvordan de virker, før du har opdaget indbruddet.

Husk også de følgende tre ting: Backup, backup og backup. Lav jævnligt backup af din maskine. Har du haft besøg af en ondsindet cracker, kan du have mistet alt. Sørg også for at have ældre backups. Hvis dit system har været inficeret igennem et stykke tid, er dine nyeste backups også inficerede. En sund strategi er, at have en system backup, som du laver før systemet sættes i drift - alle ændringer skrives ned, så de kan geninstalleres fra din sikre backup. Derudover skal du lave jævnlige separate backups af dine brugeres data.

5.1.7. Ændringer af filsystemet

Du bør holde øje med hvilke filer på dit system, der ændrer sig. Forestil dig, at en person er kommet ind på din maskine og har haft held til at erstatte passwd kommandoen med en ny binær fil, som dels laver det den skal men samtidig sender login-navn og password til supercracker@passwordcracker.net. Det er ikke urealistisk svært at lave sådan et program, idet alle har adgang til kildeteksten til Linux-systemet, og dermed kan lave ændringerne uden at behøve at skrive hele programmet forfra. Er crackeren først inde på dit system, og har han lavet programændringerne på forhånd, skal han blot erstatte de rigtige programmer med de nye. Det er normalt de binære filer i /usr/bin, /bin, /usr/sbin/, /usr/X11R6/bin og /sbin, man skal passe på, samt biblioteker, som normalt findes i /lib, /usr/X11R6/lib og /usr/lib.

Generelt leder man efter ændringer af filsystemet ved at tjekke fire ting:

• Om ejerskab/gruppeejerskab er ændret

• Om filens rettigheder (permissions) er ændret

• Om filstørrelse er ændret

• Om indholdet er ændret

Hvis vi kan stole på output af kommandoen "ls", så er de tre første nemme at undersøge. Man kan f.eks. sammenligne output fra "ls -l FILNAVN" før og efter ændringer.

Det er dog straks sværere at tjekke, om indholdet af filen er intakt. For et filsystem med en stor mængde data er det ikke muligt at have en kopi af hele filsystemet og tjekke byte for byte, om de er ens. Det tager for meget diskplads og alt for lang tid. Derfor er en del matematisk forskning gået på at udtænke metoder til at generere en funktion, som tager f.eks. indholdet af en fil og ud fra dette genererer et langt tal, som i princippet skal være unikt. Denne hash-funktion må således kun give det samme tal for to filer, hvis de er helt ens. Dermed kan man kontrollere, om en fil er ændret, blot ved at generere et tal for filen med hash-funktionen og sammenligne med det tal, filen gav sidste gang. Giver hash-funktionen samme output, antager vi, at filen er urørt.

En simpel hashfunktion kunne være summen af alle de tal, som filen består af. Den er blot alt for nem at forfalske. I litteraturen vil man ofte støde på CRC-tjek, som er relativt nemme funktioner at beregne. Mange komprimeringsprogrammer anvender CRC til at kontrollere, om det, der pakkes ud, er i orden. Til at opdage ændringer af filer med tanke på sikkerhed, er CRC-tjek ikke gode nok. Et hyppigt anvendt alternativ er MD5, som genererer en 128 bit kode ud fra en fil. På de fleste Linux-systemer findes programmet md5sum, som køres med et filnavn som argument.

[tyge@hven ~]$ md5sum /bin/ls
dc2ac9d1c1658d5b4381ca2c280425ee  /bin/ls

Et karakteristisk træk ved MD5 algoritmen er at selv små ændringer i input giver radikale forskelle i checksummen. Det er en almindelig antagelse, at det er umuligt at ændre filen /bin/ls uden at det kan afsløres ved hjælp af MD5-sum af den oprindelige version. Lad os lave et eksempel med en lille fil, der får indholdet ændret, men hvor man kan ikke se udefra, at den er ændret.

[robin@hven robin]$ echo "robin og tuck" > testfil 
[robin@hven robin]$ touch -d 19990719 testfil
[robin@hven robin]$ ls -al testfil
-rw-r--r--   1 robin      robin            14 Jul 19 00:00 testfil  
[robin@hven robin]$ md5sum testfil
e829f144f6e43d55daa442baf1462544  testfil   

[robin@hven robin]$ echo "tuck og robin" > testfil 
[robin@hven robin]$ touch -d 19990719 testfil
[robin@hven robin]$ ls -al testfil
-rw-r--r--   1 robin      robin            14 Jul 19 00:00 testfil  
[robin@hven robin]$ md5sum testfil 
18b8426e71e781dc68f8f4ee415963cc  testfil   

Vi ser, at filen i de to tilfælde indeholder de samme bogstaver, har samme længde (14 tegn), har samme datostempel (efter lidt snyd med touch-kommandoen) - men MD5-tjeksummen er helt forskellig. Derfor ved vi, at indholdet ikke det samme. Prøv selv at eksperimentere med dette.

Der er andre hash-funktioner end MD5, såsom MD4 og Snefru. Det er ikke så vigtigt, hvilken algoritme man anvender (selv om en inkarneret kryptoanalytiker vil natuligvis protestere her!). Det vigtige er at kontrollere. Men selvfølgelig er MD5 den bedste, og nemmeste, da den jo kan kontrollere ud fra en tidligere genereret filliste.

Vi vil nu omtale tre forskellige programmer til at hjælpe dig med at lave tjek af ændringer i filsystemet; RPM, Tripwire og Aide.