Care ID syslog are cea mai mare prioritate. Syslog - jurnalul sistemului de rețea. syslog Mesaje interne de sistem syslog
Protocolul syslog și software-ul de asistență asigură înregistrarea informațiilor despre evenimentele din jurnalul de sistem (jurnal, consola de sistem), precum și transferul lor către serverul de logare prin rețea, sortarea și procesarea în funcție de sursa și importanța mesajelor. Articolul descrie protocolul syslog, implementarea lui în Solaris și Linux (syslogd), Cisco IOS, precum și instrumente auxiliare: logrotate, logwatch.
Componentele sistemului sunt un generator de mesaje (dispozitiv sau proces), un protocol de schimb, un colector de mesaje (colector, server syslog), un releu (releu, primește mesaje de la unul sau mai mulți generatori și le transferă la unul sau mai mulți colectori sau următoarele relee). Generatorul (sau releul la transmitere) nu știe dacă receptorul este un releu sau un colector, poate transmite un mesaj către mai mulți receptori, poate procesa mesajul în sine (de exemplu, scrierea într-un fișier).
Protocolul syslog nu conține nicio protecție împotriva falsificării mesajelor. Și mai rău, utilizarea protocolului UDP permite atacatorilor să trimită mesaje în numele oricărei gazde. LAN-ul trebuie protejat (IOS ACL, ipchains) împotriva primirii de pachete cu adrese locale falsificate (deși acest lucru nu împiedică trimiterea mesajelor falsificate din interiorul rețelei LAN) și a primirii pachetelor din exterior pe portul 514/udp. Sunt cunoscute cazuri de debordare a discului cu mesaje false.
Protocolul syslog și UDP nu oferă livrare garantată (mesajele pot fi pierdute din cauza congestionării rețelei sau interceptate, mesajele corupte sunt șterse fără avertisment), secvență de livrare corectă (un mesaj de terminare a procesului poate ajunge înainte de un mesaj de începere a procesului), livrare prioritară.
Confidențialitatea mesajelor nu este asigurată, acestea fiind transmise în text clar.
Dacă specificați o adresă incorectă a colectorului sau releului la configurarea generatorului de mesaje, atunci nu vor fi mesaje de eroare - mesajele vor fi șterse (sau vor fi scrise în jurnalul altcuiva;).
Nu există mijloace de prevenire a transmiterii mesajelor în buclă prin relee configurate incorect.
RFC 3195 propune un nou protocol peste TCP (syslog-conn, 601) care oferă livrare garantată în secvența corectă. Implementarea nu este cunoscută de mine. Un amestec monstruos de XML, comenzi în stil SMTP și coduri de returnare și anteturi MIME (BEEP) care înglobează mesajele în format syslog standard. Sunt utilizate două moduri - RAW (analog protocolului UDP actual) și COOKED (mesajele sunt structurate pe câmpuri). BEEP vă permite să oferiți autentificare, integritate și confidențialitate (SASL, TLS).
Proiectul syslog-sign RFC propune să ofere autentificare, ordonarea mesajelor, integritatea mesajelor și detectarea mesajelor lipsă prin generarea de mesaje speciale care conțin o semnătură digitală a unui bloc de mesaje anterioare, păstrând protocolul și formatul standard syslog și folosind UDP. Folosit de SHA1, OpenPGP DSA.
Portul 514/UDP este folosit pentru a primi mesaje. De asemenea, este recomandat să utilizați portul sursă 514 pentru transmiterea mesajelor. Mesajul este un șir de text și nu poate fi mai lung de 1024 de octeți, altfel poate fi trunchiat sau chiar aruncat. Chiar și un mesaj malformat trimis la portul 514 ar trebui tratat ca un mesaj syslog. Cu toate acestea, dacă releul trimite mesajul mai departe, trebuie să adauge anteturile standard la el (eventual trunchiându-l la 1024 de octeți) - UTILIZATOR, NOTIFICARE, ora locală și numele simplu al sursei mesajului.
Mesajul începe cu un câmp PRI, care a codificat informații despre sursa mesajului (facilitate) și nivelul de severitate (nivelul de severitate) al mesajului. Este urmat de ora (TIMESTAMP), un spațiu, numele gazdei sau adresa IP în notație zecimală (HOSTNAME), un spațiu, un text de mesaj personalizat (MSG) în US-ASCII (0x20 - 0x7e).
Numele de gazdă (simplu, nu FQDN!) este scris așa cum este cunoscut generatorului de mesaje. Dacă dispozitivul are mai multe interfețe cu adrese IP diferite, atunci oricare dintre ele poate fi folosită ca nume sau adresă gazdă.
Corpul mesajului (MSG) conține de obicei o etichetă (TAG) care indică programul sau procesul care a emis mesajul și corpul mesajului (CONTINUT). Eticheta poate conține litere și cifre latine. Începutul corpului mesajului este determinat de primul caracter special, de obicei două puncte sau o paranteză pătrată deschisă. De exemplu, Cisco IOS folosește un număr de secvență de mesaj și două puncte ca etichetă, în timp ce Unix folosește un nume de program simplu (corpul mesajului începe cu un număr de proces între paranteze pătrate și două puncte).
syslogd primește mesaje de la portul 514/UDP și din surse locale (socket /dev/log), le direcționează în funcție de sursa mesajului și de nivelul de severitate. Vă permite să trimiteți mesaje în jurnal, să trimiteți către consolă, către terminal, să trimiteți către un alt server. Este introdus un alt tip de sursă MARK (marca obișnuite, informații)
Fiecare linie de jurnal conține o singură intrare de mesaj, constând din câmpuri separate prin spații:
- data în format text standard (câmpul TIMESTAMP din mesajul syslog)
- nume de gazdă (fqdn sau prescurtare, câmp HOSTNAME din mesajul syslog)
- textul mesajului (câmpurile TAG și CONTENT din mesajul syslog)
Parametri de lansare:
- -A priză-de-ascultare suplimentară (util pentru chrootarea demonilor; poate fi mai mult de unul)
- -d(modul de depanare)
- -f config-file-name (Mod implicit, /etc/syslog.conf)
- -h(schimbați comportamentul obișnuit conform căruia mesajele primite de la gazde la distanță nu sunt transmise pentru a fi scrise gazdei la distanță pentru a evita bucla)
- -l listă-gazdă (lista de gazde ale căror nume nu trebuie scrise ca FQDN-uri; separate prin două puncte)
- -m minute (interval pentru intrările temporare obișnuite; implicit este 20; dacă 0, atunci nu o faceți deloc)
- -n
- -p priză de ascultare (Mod implicit: /dev/log)
- -r(permite primirea de mesaje de la gazde la distanță; firewall-ul ar trebui să fie întredeschis; syslog pentru 514/udp ar trebui definit în /etc/services)
- -s lista de domenii (decupați numele de gazdă de la numele de domenii specificate; separate prin două puncte; în mod implicit, domeniul care se potrivește cu domeniul serverului syslog este trunchiat)
- -v
- -X(interzice determinarea unui nume de gazdă din adresa sa, previne blocajul atunci când rulează pe aceeași gazdă ca un server DNS)
Fișiere utilizate:
- /etc/syslog.conf- fișier de configurare (schimbat la pornire prin parametru -f)
- /dev/log- socket din care sunt citite mesajele locale (schimbat la pornire de parametru -p)
- /var/run/syslogd.pid- ID proces
Reacția la semnale:
- SIGHUP - reinițializează (închide toate fișierele, recitește fișierul de configurare)
- SIGTERM - oprire
- SIGINT, SIGQUIT - ieșiți dacă depanarea este dezactivată
- SIGUSR1 - activați/dezactivați depanarea (numai când utilizați comutatorul -d)
Rulează ca root. Nu modifică permisiunile pentru fișiere. Dacă este forțat să creeze un fișier, atunci îl creează cu permisiuni 644. Dacă este necesară restricționarea accesului la jurnal, fișierul corespunzător trebuie creat manual (sau drepturile de acces trebuie modificate). Creează probleme speciale logrotate.
Reprezintă un set de reguli de rutare a mesajelor. Fiecare regulă constă dintr-un selector și o acțiune separate prin file (în sistemele mai vechi, Solaris 5) sau spații (Linux). La primirea unui mesaj de log (de la klogd, dintr-un program local sau la distanță), syslogd verifică fiecare regulă pentru a vedea dacă mesajul se potrivește cu modelul specificat de selector. Dacă se potrivește, atunci acțiunea specificată în regulă este efectuată. Pentru un mesaj m. au fost efectuate un număr arbitrar de acțiuni (adică procesarea mesajului nu se oprește la primul succes).
Selectorul este format din două părți separate printr-un punct: sursa mesajului și nivelul de severitate. Literele mari și micile nu se disting. De asemenea, puteți utiliza numere (consultați /usr/include/syslog.h). Pe lângă sursele definite în syslog.3, puteți specifica marcă(marcate de timp obișnuite), Securitate(sinonim învechit pentru auth). În plus față de nivelurile de severitate definite în syslog.h, puteți utiliza a avertiza(sinonim pentru avertizare), eroare(sinonim pentru a greșit), panică(sinonim pentru apar). Mesajele cu un nivel egal sau mai mare decât cel specificat în selector și o sursă egală cu cea specificată în selector sunt considerate eligibile. Un asterisc înaintea unui punct corespunde oricărei surse, după un punct - la orice nivel. Cuvânt nici unul după punct - nici un nivel pentru această sursă. Puteți specifica mai multe surse într-un singur selector (separate prin virgule). Se pot specifica mai multe selectoare pe aceeași linie. Semantica nu este clară: dacă folosești selectori pozitivi, atunci logica SAU, dacă este negativ ( nici unulși un semn de exclamare), apoi cel logic ȘI.
În noul syslogd (linux), puteți precede nivelul cu un semn egal - doar mesajele cu nivelul specificat (dar nu cu cel mai înalt) se vor potrivi cu selectorul; semn de exclamare - nu va potrivi mesajele cu un nivel egal sau mai mare; semn de exclamare și egal - nu vor potrivi mesajele cu un nivel egal cu cel specificat.
Ca acțiune, puteți specifica:
- numele fișierului obișnuit (calea completă de la rădăcină), minus în fața numelui dezactivează sincronizarea scrierii
- canale numite - fifo (o bară verticală este plasată înaintea numelui), canalul în sine ar trebui să fie creat înainte de a porni syslogd cu comanda mkfifo
- terminal sau consola
- @hostname (trimite mesaje pentru înregistrarea de la distanță)
- lista utilizatorilor (separati prin virgula) catre ale caror terminale va fi trimis mesajul
- asterisc pentru a trimite mesaj la toate terminalele (perete)
La analizarea fișierului de configurare syslogd compară adresa loghost(definit în /etc/hosts, nu prin DNS) cu adresa computerului dvs. și, dacă se potrivește, definește variabila LOGHOST. Syslog.conf este apoi trecut prin procesorul macro m4(1). Practic, acesta este folosit pentru ca același fișier de configurare să poată fi utilizat pe gazdele client și server (din punct de vedere syslog).
Procedura de pornire și oprire: /etc/init.d/syslog(linkuri către el din directoarele /etc/rc?.d). Numărul procesului este stocat în /etc/syslog.pid.
klogd citește mesajele kernelului (fie prin /proc/kmsg, fie prin apeluri de sistem), determină nivelul, convertește adresele de comandă în nume de programe și transmite mesajul către syslogd.
Parametri de lansare:
- -c nivel(mesajele de acest nivel și cele mai puțin grave vor fi trimise la syslog, iar cele mai serioase vor fi trimise în consolă; implicit este 7; 0 nu poate fi specificat)
- -d(modul de depanare)
- -f Nume de fișier (înregistrați în fișierul specificat în loc de syslog)
- -i(simbolurile modulului de reîncărcare într-un klogd care rulează deja, trebuie utilizate de fiecare dată când un modul este încărcat sau descărcat; sperăm că versiunile actuale de insmod, rmmod și modprobe fac acest lucru singure)
- -Eu(reîncărcați simbolurile nucleului și modulelor în klogd care rulează deja)
- -k Nume de fișier (utilizați fișierul specificat ca tabel cu simboluri kernel în loc de /boot/System.map)
- -n(nu treceți în fundal; trebuie să rulați de la init)
- -o(mod unic - înregistrați toate mesajele acumulate în buffer-ul kernelului și ieșiți)
- -p(doar pentru orice eventualitate, reîncărcați tabelul cu simboluri ale modulului în momentul traducerii adresei - kernel-ul ar putea să nu poată face acest lucru)
- -s(utilizați doar syscalls și nu accesați /proc/kmsg pentru a obține mesajele originale)
- -v(afișează versiunea și ieșire)
- -X(nu converti adresele în nume)
- -2 (mesajele de blocare a nucleului - Hopa! - sunt emise de două ori: înainte de conversia de la adresă la nume - pentru ksymoops - și după)
Niveluri ale mesajelor nucleului (determinate de numărul dintre paranteze unghiulare și convertite la nivelul de severitate syslog, neschimbate atunci când sunt scoase în fișier):
- KERN_EMERG - 0 (sistemul este inutilizabil)
- KERN_ALERT - 1 (acțiunea trebuie luată imediat)
- KERN_CRIT - 2 (condiții critice)
- KERN_ERR - 3 (condiții de eroare)
- KERN_WARNING - 4 (condiții de avertizare)
- KERN_NOTICE - 5 (stare normală, dar semnificativă)
- KERN_INFO - 6 (informațional)
- KERN_DEBUG - 7 (mesaje la nivel de depanare)
Reacția la semnale:
- SIGINT, SIGKILL, SIGTERM și SIGHUP - oprire
- SIGTSTP - opriți înregistrarea
- SIGCONT - reluare, eventual alegând altul sursa mesajului (/proc/kmsg sau apeluri de sistem)
- SIGUSR1 - simboluri modul de reîncărcare
- SIGUSR2 - reîncărcați simbolurile nucleului și modulelor
Numărul procesului este stocat în /var/run/klogd.pid.
Inițializarea înregistrării: jurnal deschis- indică prefixul standard adăugat tuturor mesajelor ulterioare (de obicei, numele programului, numărul procesului între paranteze drepte și două puncte); sursă și opțiuni. closelog- terminați înregistrarea. syslog- logging (indică sursa, nivelul de severitate și formatul liniei ca în printf).
logrotate(versiunea 3.2-1/3.3.2-1/3.5.9) - lupta împotriva buștenilor în creștere: rotație (versiune), compresie, ștergere și trimitere prin poștă. Rulați zilnic de cron /etc/cron.daily/logrotate) și vă permite să procesați jurnalele dacă acestea au depășit dimensiunea specificată sau la intervalul de timp specificat. Vă permite să procesați nu numai jurnalele syslog, ci și orice alte programe. Parametri:
- [-d](mod depanare, fără modificări reale)
- [-f](efectuați modificări chiar dacă logrotate nu vede nevoia - folosit la modificarea listei de jurnalele procesate)
- [-s nume-fișier-stat ] (starea curentă a jurnalelor este stocată în acest fișier între rulări, implicit este /var/lib/logrotate.status)
- config-file-names (nume separate prin spații; ordinea contează; dacă este specificat un nume de director, fiecare fișier din acesta este considerat un fișier de configurare; RH folosește fișierul /etc/logrotate.confși director /etc/logrotate.d)
Fișierul de configurare definește opțiuni globale (una pe linie) care setează opțiunile implicite pentru toate jurnalele. Pentru fiecare serie de jurnale de procesat, opțiunile locale sunt specificate prin specificarea numelui fișierului de bază urmat de opțiunile locale între acolade, câte una pe linie. Un nume de fișier poate fi citat conform regulilor shell-ului dacă conține spații și alte caractere speciale. Puteți specifica mai multe nume de fișiere sau modele de nume de fișiere separate printr-un spațiu (șabloanele urmează și regulile shell-ului). Prelucrarea fiecărei secțiuni este tratată ca o singură acțiune. Rândurile care încep cu „#” sunt comentarii. Opțiunile specificate în următorul fișier de configurare suprascriu semnificația opțiunilor specificate în fișierul anterior. Setările locale au prioritate față de cele globale. Ordinea fișierelor din directorul de configurare nu este definită.
Parametri:
- comprima | fara compresie(versiunile mai vechi comprimă sau nu se comprimă cu gzip)
- comprima cmd(specifică programul de compresie, implicit este gzip)
- decomprimați cmd(setează decompresorul, implicit este ungzip)
- compresext(setează sufixul pentru fișierele comprimate)
- opțiuni de compresie(setează parametrii programului de compresie; implicit este „-9”, adică compresia maximă pentru gzip)
- copytruncate | nocopytruncate(de obicei, versiunea veche este redenumită și se creează o versiune nouă a jurnalului; cu această opțiune, logrotate copiază jurnalul într-un fișier nou și apoi îl trunchiază pe cel vechi; folosit dacă programul care creează jurnalul nu știe cum să se închidă se pierd înregistrările făcute în intervalul dintre copiere și trunchiere; ar fi de ajutor dacă programul de înregistrare în loc să folosească modul adăugare doar scrie în fișier folosind un pointer intern?)
- crea[ permisiuni proprietar grup] | nocreate(imediat după redenumirea vechii versiuni a jurnalului și înainte de a suna postrotate se creează un nou jurnal cu atributele specificate - permisiunile sunt specificate în octal, ca în chmod.2; dacă atributele nu sunt specificate, atunci acestea sunt preluate din vechiul jurnal)
- zilnic(schimbarea versiunilor din serie are loc zilnic)
- delaycompress | nodelaycompress(unele programe nu închid imediat jurnalul, caz în care compresia ar trebui amânată până la următorul ciclu)
- erori e-mail (cui să raporteze erori)
- extensie sufix (specifică sufixul adăugat la numele fișierelor în timpul rotației înainte de sufixul de compresie)
- dacă gol | notificare gol(schimbați versiunile chiar dacă fișierul este gol; implicit)
- include Nume de fișier | nume-director (înlocuiți textual un fișier sau toate fișierele din directorul specificat; subdirectoarele, fișierele speciale și fișierele cu sufixe din lista de excludere nu sunt incluse; nu pot fi utilizate în interiorul unei secțiuni)
- Poștă adresa | nomail(atunci când o modificare a versiunii necesită ștergerea vechiului jurnal, apoi trimiteți-l la adresa specificată)
- mail first(trimiteți nu versiunea ștearsă a jurnalului, ci prima)
- mailast(trimite versiunea jurnalului pentru a fi ștearsă; implicit)
- lipsingok | nomissingok(nu trimiteți mesaje de eroare dacă lipsește jurnalul)
- lunar(versiunea se schimbă lunar)
- olddir director | noolddir(în timpul unei schimbări de versiune, jurnalul este mutat în directorul specificat; trebuie să fie pe același dispozitiv fizic)
- postrotate script final sunt executate ca comenzi shell după procesul de schimbare a versiunii)
- prerotate(toate liniile ulterioare până la linie script final sunt executate înainte de procesul de schimbare a versiunii)
- roti număr (câte versiuni vechi să păstrați; dacă 0, atunci niciuna)
- mărimea octet (schimbarea versiunii are loc dacă dimensiunea jurnalului depășește numărul specificat; puteți utiliza sufixele „k” - kilobyte - și „M" - megabyte)
- scripturi partajate | nosharedscripts(executați comenzi prerotateȘi postrotate o singură dată pentru toate fișierele descrise în secțiune)
- tabooext [+ ] sufix-list (setarea unei liste de sufixe de excludere pentru include; dacă este specificat semnul plus, atunci adăugarea, în caz contrar înlocuirea; implicit: .rpmorig, .rpmsave, .rpmnew, ",v", .swp și "~")
- săptămânal(versiunea se schimbă săptămânal)
Livrat de RH /etc/logrotate.conf descrie opțiunile și opțiunile globale pentru /var/log/wtmp și /var/log/lastlog și se referă la directorul /etc/logrotate.d, în care fiecare pachet scrie setări locale pentru jurnalele sale.
logwatch este un cadru de scriere a programelor (numite filtre) pentru a extrage informații utile din jurnalele numeroase, mari și variate (nu doar syslog). „Pachetul” vine cu mai multe filtre concepute pentru Red Hat Linux (unele versiuni antice, pentru că inetd este menționat în loc de xinetd), dar va trebui să le adaptați la o situație specifică. Ultima modificare a fost făcută de autor în septembrie 2000, așa că nu se mai poate aștepta dezvoltarea ulterioară.
Filtrele pot fi scrise în orice limbaj de programare, dar autorul pachetului preferă perl. Filtrele trebuie scrise în așa fel încât să citească datele din stdin și să scoată rezultatul în stdout. Înainte de a apela filtrul, sunt setate următoarele variabile de mediu: LOGWATCH_DATE_RANGE, LOGWATCH_DETAIL_LEVEL, LOGWATCH_TEMP_DIR, LOGWATCH_DEBUG. Programul principal este, de asemenea, scris în perl: /etc/log.d/scripts/logwatch.pl(/etc/log.d/logwatch, /usr/sbin/logwatch și /etc/cron.daily/00-logwatch sunt link-uri simbolice către acesta).
Director /etc/log.d/conf/logfiles/ conține fișiere de configurare a grupului de jurnal care stochează înregistrările serviciilor întreținute. Fiecare grup este descris într-un fișier separat numele Grupului.conf, care specifica:
- LogFile = numele fișierului care conține jurnalul sau modelul de denumire; pot fi specificate mai multe nume sau modele; numele pot fi relativ la LogDir
- Arhivă = numele fișierului creat de logrotate al versiunii arhivate a jurnalului sau un model de denumire; pot fi specificate mai multe nume sau modele; numele pot fi relativ la LogDir
- nume de filtre ( o singura data, desi se arata diferit!) din /etc/log.d/scripts/shared/ la fel de
*nume-filtru = parametrii , de exemplu, pentru a filtra jurnalul după dată dacă este în format standard syslog, utilizați linia:
*ApplyStdDate=
Director /etc/log.d/conf/services/ conține fișiere de configurare pentru serviciile ale căror intrări de jurnal le va procesa logwatch. Fiecare serviciu este descris într-un fișier separat numele serviciului.conf, care specifica:
- LogFile = numele grupului de jurnal
- filtru numele de la /etc/log.d/scripts/shared/ la fel de
*nume-filtru = parametrii , lansat înainte de filtrul de serviciu - $nume-variabilă-de-mediu = sens
Director /etc/log.d/scripts/logfiles/ conține filtre pentru procesarea grupurilor de jurnal: la procesarea unui grup de jurnal, toate fișierele din director /etc/log.d/scripts/logfiles/ numele Grupului folosite ca filtre.
Director /etc/log.d/scripts/services/ conține filtre pentru procesarea înregistrărilor unor servicii specifice.
Director /etc/log.d/scripts/shared/ conține filtre comune utilizate în fișierele de configurare a grupului de jurnal:
- applystddate - filtrează jurnalul după data cerută, dacă este scris în format syslog (aici și în filtre private după dată, introduceți LANG= înainte de data apelării, altfel Mar nu coincide în niciun fel cu Mar;)
- expandrepeat - transformă liniile „ultimul mesaj repetat” în numărul corespunzător de linii cu textul mesajului din linia anterioară
- onlycontains - lasă doar acele linii de jurnal care conțin șirul specificat (am pus ghilimele în jurul „$*”)
- onlyservice - selectează din formatul log in syslog liniile legate de serviciul specificat (numele serviciului este transmis ca parametru)
- remove - lasă doar acele linii de jurnal syslog care nu conțin linia specificată ( Am pus ghilimele în jurul „$*” și am făcut remove1, remove2 etc. pentru că nu am înțeles cum să specific mai multe submodele pentru egrep într-o singură linie; apropo, parametrii sunt înlocuiți în shell, așa că nici caracterele speciale nu pot fi folosite)
- removeheaders - eliminați câmpurile standard (data, ora, numele gazdei, eticheta serviciului și numărul procesului)
- removeservice - elimină linii din jurnalul syslog care nu sunt legate de serviciul specificat (numele serviciului este transmis ca parametru)
Parametrii impliciti sunt stocați în fișierul /etc/log.d/conf/logwatch.conf (/etc/log.d/logwatch.conf are o legătură simbolică către acesta), comentariile în care fac posibilă înțelegerea semnificației a parametrilor:
- LogDir - director referitor la care sunt luate în considerare numele de fișiere
- MailTo - cui să trimiți raportul
- Imprimare - în loc să trimiteți raportul prin poștă, tipăriți-l la stdout
- Salvare - în loc să trimită raportul prin poștă, îl va salva în fișierul specificat
- Arhive - utilizați versiuni ale jurnalelor generate de logrotate
- Interval - interval de timp considerat: Toate, Azi, Ieri (ziua calendaristică de ieri)
- Detaliu - nivelul de detaliu al raportului: de la 0 la 10 sau Scăzut, Mediu, Ridicat
- Service - Toate sau numele filtrului din /etc/log.d/scripts/services/ (pot fi specificate mai multe filtre)
- LogFile - Toate sau numele grupului de jurnal (pot fi specificate mai multe grupuri)
Parametri de lansare:
- --detaliu nivel (raportați nivelul de verbozitate: ridicat, mediu sau scăzut)
- --fișier jurnal jurnal-grup (procesează numai jurnalele acestui grup; grupul este specificat printr-un nume simbolic în fișierul de configurare; pot fi specificate mai multe grupuri)
- --serviciu numele serviciului (procesează numai acele intrări de jurnal legate de acest serviciu; serviciul este specificat printr-un nume simbolic în fișierul de configurare; pot fi specificate mai multe servicii; nume Toate cauzează procesarea înregistrărilor pentru toate serviciile)
- --imprimare(raportați la stdout)
- --mailto adresa (trimite raportul la adresa specificată)
- --salva Nume de fișier (scrieți raportul în fișierul specificat)
- --arhive(procesează nu numai versiunile curente ale jurnalelor, ci și copiile vechi create de logrotate)
- --gamă data-interval (procesează numai acele intrări din jurnalele care aparțin intervalului de timp dat: Ieri, Azi, Toate)
Utilizarea principală este includerea fișierului 00-logwatch (începe cu „00” pentru a rula înainte de logrotate) în directorul /etc/cron.daily, ceea ce face ca logwatch să ruleze zilnic cu opțiunile implicite.
Din păcate, toate filtrele sunt concepute pentru a se asigura că jurnalele sunt scrise pe aceeași gazdă pe care rulează serviciul.
Toate jurnalele sunt păstrate pe un singur computer (dacă sunteți paranoic, puteți scrie jurnalele pe două servere simultan).
Corespondența dintre un nume formal de sursă și un dispozitiv sau program real:
- local0-Cisco
- local3 - ftp (există un nume de sursă special, dar Solaris 2.5 nu îl cunoaște)
- local4 - rezervat contabilitatii
- local5 - POP3/IMAP
- local6-tac_plus>
Serverul trebuie să aibă un ecran deschis pentru portul 514/udp (puteți limita adresele sursă ale pachetelor, dar acest lucru va ajuta doar împotriva accidentelor). Pornirea syslogd (opțiunile din /etc/rc.d/init.d/syslog sau /etc/sysconfig/syslog) trebuie să fie cu comutatoarele „-r -m 0” (și, de asemenea, „-x” dacă rulează pe același computer server DNS). Începeți klogd cu comutatoarele „-2 -c 1”. Configurarea syslog.conf:
- *.crit - trimite mesaje de nivel de severitate CRIT și mai sus către terminale și scrie-le într-un fișier separat (chmod 600), trimite-ți mesajele către serverul de rezervă; sendmail consideră că primirea mesajelor este critică
- kern - creați un fișier kern pentru mesajele de toate nivelurile (chmod 600)
- mail - creați un fișier de e-mail pentru mesajele de toate nivelurile (fără sincronizare)
- auth, authpriv - creați un fișier securizat pentru mesajele de toate nivelurile (chmod 600)
- știri - creați un fișier separat pentru fiecare nivel de severitate în directorul de știri (depanare fără sincronizare)
- cron - creați un fișier cron pentru mesajele de toate nivelurile (cron în RH 6.2 și Solaris 2.5 nu știu cum să folosească syslog)
- local0 - creați un fișier separat pentru fiecare nivel de severitate din directorul Cisco (err și mai jos fără sincronizare)
- local3 - creați un fișier separat pentru fiecare nivel de severitate în directorul ftp (informații și depanare fără sincronizare)
- local5 - creați fișierul imap.log pentru mesajele de toate nivelurile
- local6 - creați fișierul tac_plus.log pentru mesajele de toate nivelurile
- local7 - fișier boot.log (mesaje la pornirea sistemului și la pornirea sau oprirea syslogd și klogd)
- toate mesajele de la nivelul INFO și mai sus care nu sunt incluse într-unul dintre fișierele definite mai sus, scrieți în fișierul de mesaje (chmod 600)
Pe computerele client, configurăm syslog astfel încât toate mesajele să fie transmise către serverul syslog, mesajele de eroare să fie duplicate în /var/log/syslog, mesajele de stare critică să fie duplicate pe consolă, terminalele utilizatorului. Pe computerele Linux, aruncați și mesajele de boot într-un fișier local (local7, boot.log). Serverul Syslog de rezervă ar trebui să primească mesaje de nivel critic din rețea și să le scrie într-un fișier (gaura ecranului, comutatorul de rulare „-r”).
logrotate: stocați pentru totdeauna, schimbați versiunile cât mai rar posibil (lunar, cu excepția squid), aruncați în directoare separate (cu excepția squid) și comprimați (în modul întârziat, cu excepția ftpd, linuxconf, sendfax), trimiteți erori și fișiere șterse către pe mine. Potriviți parametrii pentru syslog.
Fiecare dintre utilizatorii începători de Linux întâmpină, mai devreme sau mai târziu, unele probleme în configurarea și organizarea funcționării sistemului lor. Și fiecare dintre începători a auzit aproape sigur sfaturi de la utilizatorii mai experimentați: „Uită-te la jurnalele”. Sfatul este bun, dar un începător mai trebuie să știe: ce sunt buștenii și unde să le caute! Așa că voi încerca în acest articol să vă spun ce și unde să vizionați.În argoul programatorilor, „jurnalele” sunt numite protocoale de lucru care sunt menținute atât de sistemul de operare în sine, cât și independent de multe programe. Cuvântul „jurnal” este adesea folosit ca sinonim pentru cuvântul „protocol” în acest sens. Există două situații principale în care apare nevoia de a analiza protocolul: când ceva din sistem nu funcționează așa cum ne așteptam (rezolvarea problemei) și când există suspiciunea că sistemul a fost piratat de un atacator și trebuie să aflați exact ce s-a întâmplat, cum a fost făcut și ce trebuie făcut pentru a elimina consecințele invaziei.
Unul dintre cele mai faimoase cazuri de utilizare a fișierelor jurnal pentru a detecta un intrus este povestea prinderii celebrului hacker Kevin Mitnick de către specialistul în securitate informatică Tsuomo Shimomura. Iată un paragraf din articol care descrie cum s-a întâmplat.
„În ziua de Crăciun, când Shimomura a plecat la schi în Nevada în vacanță, cineva (știm deja cine) a intrat în computerul său super-securizat din Solana Beach, California, și a început să-și copieze fișierele - sute de fișiere clasificate. Un student absolvent de la Centrul de Supercomputing din San Diego, unde lucra Shimomura, a observat modificări în fișierele „jurnal” (jurnal) de sistem și și-a dat seama rapid ce se întâmplă.Toate acestea au fost posibile datorită faptului că Shimomura a instalat pe computerul său un program care copia automat "jurnalul" înregistrează pe un computer de rezervă din San Diego. Studentul l-a sunat pe Shimomura, care s-a grăbit acasă să facă inventarul bunurilor furate."
Nu voi spune aici toată povestea, este important pentru noi să remarcăm doar că analiza protocoalelor de funcționare a sistemului a servit drept bază pentru succesul anchetei de abatere efectuată. Puteți găsi o descriere mai detaliată a modului în care se desfășoară astfel de investigații în articol. Dar pentru a putea folosi rezultatele înregistrării, trebuie să înțelegem cum sunt create protocoalele, unde sunt stocate și ce se poate extrage din ele. Prezentul articol este dedicat luării în considerare a tuturor acestor întrebări.
Cum sunt generate mesajele pentru protocol
Trebuie să începem cu faptul că atunci când creează programe în limbajul C, programatorii au posibilitatea, dacă este necesar, de a insera un apel la funcții speciale. openlog, setlogmask, syslogȘi closelog, inclusă în biblioteca standard C. Aceste funcții sunt utilizate pentru a trimite mesaje despre anumite evenimente în timpul execuției programului către un demon special de sistem syslogd, conducând protocolul de sistem. Funcţie jurnal deschis stabilește o legătură cu demonul syslogd, funcție syslog generează un mesaj specific pentru scrierea în protocol și a funcției closelogînchide o conexiune deschisă.
Mesaje generate de funcție syslog, constau din mai multe câmpuri separate prin spații. Fiecare mesaj începe cu un câmp PRI, care în formă codificată conține informații despre categoria mesajului (facilitate) și nivelul de severitate (nivel de severitate) sau prioritatea (prioritatea) mesajului.
Categoria (facilitatea) este informații despre carei clase îi aparține mesajul dat. Categoria este codificată ca număr de la 0 la 23. Există următoarele categorii (sunt definite în fișier /usr/include/sys/syslog.h):
Tabelul 1.
| Valoare numerica | Simbol | Decriptare |
| 0 | kern | Mesaje kernel |
| 1 | utilizator | Proiectat pentru o varietate de mesaje din programele utilizatorului (mesaje din programele utilizatorului) |
| 2 | Poștă | Mesaje din sistemul de poștă. |
| 3 | demonul | Mesaje de la acele demoni de sistem care, spre deosebire de FTP sau LPR, nu au categorii special alocate pentru ei. |
| 4 | auth | Orice lucru legat de autorizarea utilizatorului, cum ar fi autentificare și su (securitate/permisiuni) |
| 5 | syslog | Sistemul de înregistrare poate înregistra mesaje de la sine. |
| 6 | lpr | Mesaje de la sistemul de imprimare. |
| 7 | știri | Mesaje de pe serverul de știri. (Netnews, USENET) |
| 8 | uucp | Mesaje din protocolul de copiere UNIX-to-UNIX. Aceasta face parte din istoria UNIX și, cel mai probabil, nu veți avea nevoie niciodată de el (deși o anumită proporție de mesaje e-mail sunt încă livrate prin UUCP). |
| 9 | cron | Mesaje de la programatorul de sistem. |
| 10 | authpriv | La fel ca auth, dar mesajele din această categorie sunt scrise într-un fișier pe care doar unii utilizatori îl pot citi (poate că această categorie este evidențiată deoarece mesajele care îi aparțin pot conține parole publice ale utilizatorilor care nu ar trebui să fie văzute de persoane neautorizate și, prin urmare, jurnalul). fișierele trebuie să aibă permisiunile corespunzătoare). |
| 11 | ftp | Cu această categorie vă puteți configura serverul FTP pentru a-și înregistra acțiunile. |
| de la 12 la 15 | - | Rezervat pentru utilizarea sistemului. |
| de la 16 la 23 | local0 - local7 | Categoriile rezervate pentru utilizare de către administratorul de sistem. Categoria local7 este utilizată de obicei pentru mesajele generate în timpul pornirii sistemului. |
Categorie auth are un nume-sinonim învechit Securitate, ceea ce nu este recomandat. În plus, există o categorie specială marcă(nu are un echivalent digital), care este atribuit mesajelor individuale generate de demonul însuși syslogd. Această categorie este folosită pentru a pune semne speciale în jurnal la un interval de timp specificat (la fiecare 20 de minute în mod implicit), ceea ce permite, de exemplu, să aflați cu o precizie de 20 de minute când computerul se blochează.
Rețineți că categoria nu are nimic de-a face cu numele programului care trimite mesaje către demon. syslogd. După cum se spune, orice coincidență este pură coincidență. Mai mult, unele programe pot genera mesaje de diferite categorii. De exemplu, un demon telnetdîn cazul încercărilor de înregistrare nereușite generează mesaje de categorie authpriv, iar în alte cazuri își clasifică postările ca demonul.
Al doilea parametru, pe baza căruia se formează valoarea câmpului PRI, este nivelul sau prioritatea mesajului (prioritatea), adică informații despre gradul de importanță a mesajului. 8 niveluri de importanță sunt setate implicit (sunt definite și în fișier /usr/include/sys/syslog.h), care sunt codificate prin numere de la 0 la 7:
Masa 2.
| Valoare numerica | Simbol | Decriptare |
| 0 | apar(nume vechi pentru PANIC) | De urgență. Sistemul este inoperabil. |
| 1 | alerta | Anxietate! Este necesară intervenția imediată. |
| 2 | crit | Eroare critică (stare critică). |
| 3 | a greșit(nume vechi EROARE) | Mesaj de eroare. |
| 4 | avertizare(nume vechi pentru WARN) | Un avertisment. |
| 5 | înștiințare | Informații despre un eveniment normal, dar important. |
| 6 | info | Anunţ. |
| 7 | depanare | Mesaje generate în timpul depanării. |
Camp PRI mesajul se formează astfel: valoarea numerică a categoriei se înmulțește cu 8 și se adaugă la valoarea numerică a priorității, numărul rezultat este cuprins între paranteze unghiulare și scris în câmp.
Urmărind câmpul PRI Următoarele câmpuri sunt incluse în mesaj:
- TIMESTAMP-UL- timpul de generare a mesajului,
- HOSTNAME- numele gazdei sau adresa IP în notație zecimală,
- MSG- textul mesajului arbitrar - un șir de text (informații) în codul US-ASCII (0x20 - 0x7e).
Ora (locală!) este scrisă în formatul: 13 feb 21:12:06. Dacă numărul zilei este o singură cifră, atunci este precedat de un spațiu suplimentar (nu 0!). Acordați atenție absenței unui an și a unei zone în dată, care trebuie luate în considerare atunci când organizați stocarea pe termen lung a fișierelor jurnal. Pentru ca ora din mesaj să fie corectă, trebuie să fie sincronizată (de exemplu, folosind protocolul NTP).
Numele gazdei este inclus în mesaj pentru a nu încurca mesajele de la diferite gazde, deoarece, așa cum se va arăta mai jos, înregistrarea se poate face pe unul dintre computerele dedicate din rețea. Numele gazdă este numele de rețea simplu al computerului, fără a specifica domeniul. Dacă computerul are mai multe interfețe cu adrese IP diferite, atunci oricare dintre ele poate fi folosită ca nume sau adresă gazdă.
Mesaj text ( MSG) conține de obicei o etichetă ( ETICHETĂ) indicând programul sau procesul care a emis mesajul și corpul mesajului ( CONŢINUT). Eticheta poate conține litere și cifre latine. De obicei, eticheta este un nume de program simplu, uneori urmat de un ID de proces inclus între paranteze drepte. Corpul mesajului este separat de etichetă prin caractere speciale - în Linux, acesta este de obicei două puncte și un spațiu.
Gestionarea mesajelor cu syslogd
Toate mesajele generate de programe individuale folosind funcția syslog, trimis prin priză /dev/log demonul de sistem syslogd, care este responsabil pentru procesarea acestor mesaje. Trebuie să spun că, de fapt, în sistem sunt lansate doi daemoni de înregistrare - syslogdȘi klogd. Ambii demoni sunt incluse în pachet syslogd, cea mai recentă versiune o găsiți pe site.
Daemon klogd este responsabil pentru înregistrarea evenimentelor care au loc în nucleul de sistem. Necesitatea unui daemon separat klogd deoarece nucleul nu poate folosi funcția standard syslog. Faptul este că bibliotecile standard (inclusiv biblioteca în care se află funcția syslog) sunt destinate a fi utilizate numai de aplicații normale. Deoarece nucleul are nevoie și de funcții similare, acesta include propriile biblioteci care nu sunt disponibile pentru aplicații. Prin urmare, nucleul folosește propriul mecanism de generare a mesajelor. Daemon klogd menite să organizeze procesarea acestor mesaje. În principiu, el poate efectua o astfel de prelucrare complet independent și independent de syslogd, de exemplu prin scrierea acestor mesaje într-un fișier, dar în majoritatea cazurilor setarea implicită este klogd, în care toate mesajele din nucleu sunt redirecționate către același demon syslogd.
Pentru a vă asigura că demonii syslogdȘi klogd rulează pe sistemul dvs., executați comanda ps-ax | jurnal grep. Această comandă mi-a dat următorul rezultat:
$ ps -ax | jurnal grep 569? S 0:00 syslogd -m 0 574 ? S 0:00 klogd -x 1013 ? S 0:00 autentificare -- kos 1191 ? S 0:00 kalarmd --login Primele două linii vă spun doar că demonii de logare rulează pe sistem.Gestionarea mesajelor de către demon syslogd constă în faptul că monitorizează constant aspectul mesajelor și compară fiecare intrare primită cu regulile care se află în fișier /etc/syslog.conf. Fiecare regulă este scrisă ca o linie în fișier /etc/syslog.conf, format din două câmpuri. Câmpul din stânga ("selector") specifică unul sau mai multe șabloane prin care sunt selectate mesajele. Șabloanele sunt separate prin punct și virgulă (consultați fișierul exemplu de mai jos /etc/syslog.conf). Câmpul din dreapta („acțiune”) determină ordinea în care sunt procesate mesajele selectate. Câmpurile sunt separate prin unul sau mai multe spații sau file.
Fiecare model din câmpul „selector” are forma „category.level” (adică „facility.priority”). Valorile câmpului „categorie” pot fi:
- una dintre denumirile convenționale ale categoriilor enumerate în tabelul 1,
- mai multe astfel de nume (în acest caz sunt separate prin virgule)
- sau simbolul * (însemnând „toate categoriile”).
Valorile câmpului „nivel” pot fi:
- unul dintre denumirile condiționale ale nivelului enumerat în tabelul 2,
- simbol * (înregistrați toate mesajele din această categorie, indiferent de nivel),
- sau cuvânt nici unul(nu înregistrați mesaje din această categorie).
Specificarea unei anumite valori în câmpul „nivel” este interpretată ca „toate valorile de la acest nivel și mai sus”. Dacă trebuie să înregistrați mesaje de un singur nivel, atunci trebuie să puneți un semn egal ("=") în fața valorii care trebuie setată. Dacă este necesară înregistrarea mesajelor de toate nivelurile, cu excepția celui specificat, atunci înaintea numelui nivelului este plasat un semn de exclamare ("!"). Punerea acestor două semne în același timp este interpretată ca „nu înregistrați mesaje de nivelul specificat și mai sus”.
Literele mari și micile din câmpul „selector” nu se disting. De asemenea, puteți utiliza numere (consultați /usr/include/syslog.h). Pe lângă categoriile enumerate în Tabelul 1, puteți specifica marcă(marcate temporale obișnuite) și Securitate(sinonim învechit pentru auth). Pe lângă valorile prioritare enumerate în Tabelul 2, puteți utiliza a avertiza(sinonim pentru avertizare), eroare(sinonim pentru a greșit), panică(sinonim pentru apar).
Când categoria și nivelul mesajului primit se potrivesc cu unul dintre modelele de câmp „selector” ale unui rând, syslogd procesează înregistrarea în conformitate cu acțiunea specificată în câmpul „acțiune” din acest rând.
Câmpul „acțiune” poate conține
- trebuie specificate numele unui fișier obișnuit (fișier jurnal) și calea completă către fișier, începând cu rădăcina „/”, iar dacă fișierul specificat nu există, syslogdîl creează
- numele conductei numite (conducta numită) - FIFO; în acest caz, numele este precedat de o bară verticală ("|"), iar canalul în sine trebuie creat înainte de a începe syslogd echipă mkfifo,
- indicând către un terminal sau consolă (ca dispozitiv: /dev/tty1),
- indicând către o gazdă la distanță (precedată de simbolul @),
- sau o listă de utilizatori (separați prin virgule) către ale căror terminale va fi trimis un mesaj conform acestei reguli. În loc de o listă de utilizatori, puteți pune un asterisc (*), ceea ce va însemna că mesajele sunt trimise tuturor utilizatorilor care lucrează în prezent în sistem.
Cel mai adesea, câmpul „acțiune” conține în continuare numele fișierului jurnal. Mai mult decât atât, înainte de numele fișierului, puteți pune un semn minus ("-"), ceea ce va însemna că sistemul poate stoca fișierul în memoria cache-tampon, și nu îl va șterge după ce fiecare mesaj este scris pe disc. Acest lucru, desigur, accelerează munca, mai ales dacă în jurnal sunt scrise multe mesaje mari, dar poate duce la pierderea unor mesaje în cazul unui blocaj neașteptat al sistemului, adică exact atunci când astfel de mesaje sunt deosebit de necesare. De asemenea, puteți specifica o imprimantă ca dispozitiv în câmpul „acțiune” - /dev/lp0. Este oportun să se aplice o astfel de variantă de „acțiune” în acele cazuri când este vorba de sisteme deosebit de importante. Protocoalele care sunt tipărite nu pot fi șterse sau modificate de hackeri, așa că aceasta este o utilizare bună pentru o veche imprimantă matriceală.
Pe lângă rândurile cu regulile din dosar /etc/syslog.conf poate conține linii goale și linii de comentarii care încep cu #. Mai multe despre structura fișierelor /etc/syslog.conf puteți citi pagina de manual syslog.conf pentru câteva exemple de intrări de reguli în acest fișier. Rețineți că atunci când specificați perechi „category.level” în fișier syslog.conf nu puteți folosi valorile numerice date în tabelele 1 și 2, sunt permise doar numele lor condiționate.
Dacă un mesaj se potrivește cu modelele a două sau mai multe linii, el va fi procesat conform fiecăreia dintre aceste reguli (adică procesarea mesajului nu se oprește la primul succes). Aceasta înseamnă că un număr arbitrar de acțiuni pot fi efectuate pe un singur mesaj. Prin urmare, puteți scrie un mesaj într-un fișier jurnal și îl puteți trimite către utilizator(i) sau către o gazdă de la distanță.
În plus, dacă în câmpul „selector” sunt listate mai multe perechi „category.level” (separate prin punct și virgulă), atunci perechile ulterioare pot anula efectul celor anterioare. Puteți vedea un exemplu de astfel de anulare în lista de fișiere de mai jos. /etc/syslog.conf: înregistrează toate mesajele la sau mai sus de informații în fișierul /var/log/messages, dar omite (nu jurnalele) mesajele de e-mail, authpriv și cron.
| Listarea 1. Fișier /etc/syslog.conf dintr-un sistem construit pe baza distribuției Red Hat Linux 7.1 (am tradus doar comentariile conținute în acest fișier în rusă și am evidențiat regulile cu caractere aldine). |
| # Imprimați toate mesajele din nucleu pe consolă. #kern.* /dev/console# Înregistrați toate mesajele de nivel de informații sau mai mari, # cu excepția mesajelor de sistem de e-mail care conțin informații confidențiale # din mesajele de autentificare și mesajele cron daemon. *.info;mail.none;authpriv.none;cron.none /var/log/messages# Scrieți mesaje care conțin # informații confidențiale de autentificare într-un fișier separat, indiferent de nivelul lor. authpriv.* /var/log/secure# Toate mesajele sistemului de poștă sunt, de asemenea, înregistrate separat. mail.* /var/log/maillog# Înregistrați acțiunile demonului cron. cron.* /var/log/cron# Mesajele de urgență trebuie primite imediat # de către toți utilizatorii sistemului *.emerge*# Mesajele de la serviciile de știri de nivel critic și superior sunt scrise într-un fișier separat. uucp,news.crit /var/log/spooler# Copiați mesajele emise în timpul fazei de pornire în fișierul boot.log local7.* /var/log/boot.log |
Fișier jurnal /var/log/messages
Desigur, este imposibil să spunem aici despre conținutul fiecărei linii a acestui fișier. Pentru ca cititorul să-și facă o idee despre ce informații pot fi găsite în protocol, vom oferi rânduri-mesaje separate cu comentarii foarte scurte.
Fiecare linie din fișierul jurnal conține o singură intrare de mesaj constând din următoarele câmpuri de mesaj, separate prin spații:
- data în format text standard (câmp TIMESTAMP-UL din mesaj syslog),
- numele gazdă (câmp HOSTNAME din mesaj syslog)
- textul mesajului (câmpuri ETICHETĂȘi CONŢINUT din mesaj syslog)
În primul rând, este de remarcat faptul că, dacă computerul nu rulează 24/7, dar este oprit noaptea, atunci acest fișier poate conține înregistrări ale mai multor „cicluri de lucru”, începând cu pornirea computerului și terminând cu închiderea computerului. Un astfel de ciclu începe cu un mesaj despre lansarea demonilor de înregistrare (acest lucru este de înțeles, nu au fost înregistrate mesaje înainte de a fi lansate):
17 septembrie 08:32:56 kos3 syslogd 1.4-0: reporniți. 17 septembrie 08:32:56 kos3 syslog: syslogd a început cu succes 17 septembrie 08:32:56 kos3 kernel: klogd 1.4-0, sursa jurnal = /proc/kmsg a început. 17 septembrie 08:32:56 kernel kos3: Inspectarea /boot/System.map-2.4.2-2 17 septembrie 08:32:56 kos3 syslog: pornirea klogd a reușit
Aproximativ aceeași structură are intrări în alte fișiere de protocol menționate în fișier /etc/syslog.conf.
comenzi logger și tailf
Din descrierea anterioară, putem concluziona că emiterea tuturor mesajelor pentru jurnalele de sistem ar trebui stabilită de programator în etapa creării programului. Acest lucru nu este în întregime adevărat. Utilizatorul are, de asemenea, capacitatea de a trimite un mesaj demonului syslogd. Pentru a face acest lucru, Linux are o comandă logger, care oferă trimiterea unui mesaj din linia de comandă (sh, bash etc.). Face parte din pachetul util-linux. Desigur, această comandă este destinată în primul rând să ofere capabilități de înregistrare în jurnal atunci când utilizatorul creează diferite tipuri de scripturi shell. Dar poate fi rulat și direct din linia de comandă, de exemplu, pentru a vă familiariza cu capacitățile sistemului de înregistrare. Format de executare a comenzii: logger [-isd] [-f fișier] [-p PRI] [-t TAG] [-u socket] Opțiunile liniei de comandă au următoarea semnificație:
- -i- includeți numărul procesului în mesaj
- -s- mesaj duplicat către stderr
- -d- utilizați modul datagramă atunci când trimiteți mesaje (în loc de streaming obișnuit)
- -f nume de fișier- salvați mesajul în fișierul specificat (implicit este /var/log/messages)
- -p facilitate.nivel- setați categoria și prioritatea mesajului (implicit: user.notice)
- -t ETICHETĂ - setați câmpul TAG
- -u priza- trimiteți un mesaj către socket-ul specificat, în loc să apelați syslogd
- MSG- Mesaj text
Trimiteți mai multe mesaje folosind programul loggerși admirați rezultatul din dosar /var/log/messages(cu excepția cazului în care, desigur, ați modificat valoarea implicită).
Apropo, există o modalitate foarte interesantă de a vizualiza mesajele scrise într-un fișier /var/log/messages echipă logger. Această metodă se bazează pe utilizarea unui program special coada. Deschideți o fereastră de terminal, obțineți drepturi de superutilizator (cu comanda su) și rulați comanda în această fereastră
tailf /var/log/messages
După aceea, treceți la alt terminal și executați comanda acolo logger custom_text. Mesajul dumneavoastră va fi afișat imediat în fereastra în care rulează programul. coada. Adică, cu ajutorul acestui program, administratorul de sistem poate monitoriza în timp real înregistrarea noilor mesaje în protocol. Adevărat, este puțin probabil ca administratorul de sistem să aibă timp să monitorizeze comportamentul sistemului în acest fel (cu excepția situațiilor de urgență). Prin urmare, au fost dezvoltate programe speciale pentru analiza protocoalelor. Dar despre ei puțin mai jos, dar deocamdată să trecem la întrebarea cum să organizăm supravegherea unui computer de la distanță (vă amintiți cum l-ați prins pe atacatorul Shimomura?).
Înregistrare în rețea
După cum sa menționat, mesajele de sistem de înregistrare pot fi trimise de demon syslogd către o gazdă la distanță. Dar cineva trebuie să o ducă acolo. Se pare că acesta este același demon syslogd rulează pe această gazdă la distanță. Mai precis, syslogd pe orice computer, poate asculta nu doar pe soclul /dev/log (acceptând astfel mesaje din surse locale), ci și pe portul 514/UDP, care asigură că mesajele sunt primite de la alte computere din rețeaua locală (și apoi scrise într-un fișier local). Acest lucru face posibilă crearea unui „server de înregistrare”, care poate fi foarte convenabil pentru un administrator de sistem (toate evenimentele din rețea sunt urmărite într-un singur loc) și, de asemenea, crește securitatea rețelei, deoarece raportează o intruziune a unui hacker într-unul dintre gazdele de rețea nu pot fi eliminate imediat din protocol de către acest hacker.
Totuși, pentru a organiza o astfel de „înregistrare în rețea”, trebuie depuse unele eforturi suplimentare.
În primul rând, deoarece portul 514/UDP este folosit pentru a primi și trimite mesaje prin rețea, acesta trebuie să fie disponibil pe ambele computere (client și server). Pentru asta în dosar /etc/services ambele calculatoare trebuie să aibă linia
syslog 514/udp
Dacă o astfel de linie este /etc/services dispărut, syslogd nu poate primi mesaje și nici nu le trimite în rețea deoarece nu poate deschide un port UDP. Dacă apare o astfel de situație, syslogdîncetează imediat scrierea oricăror mesaje chiar și în jurnalul local. Totuși, așa cum arată comanda ps, rămâne în memorie și chiar stochează mesaje în unele buffere, deoarece dacă șirul " syslog 514/udp" restaurați în fișier /etc/services pe client, atunci cel puțin unele dintre mesajele „lipsă” apar în continuare în jurnal (după repornire syslogd).
În al doilea rând, la pornirea demonului syslogd opțiunea trebuie specificată pe server -r, care oferă capacitatea de înregistrare la distanță (în mod implicit, demonul syslogd așteaptă un mesaj doar de la priza locală). Cum și unde să setați această opțiune va fi discutat mai jos, în secțiunea despre pornirea demonului. syslogd.
Ei bine, și în al treilea rând, setările din fișiere ar trebui corectate în consecință. /etc/syslog.conf pe ambele computere. De exemplu, dacă doriți să redirecționați toate mesajele către serverul de înregistrare, trebuie să scrieți în fișierul de pe computerul client /etc/syslog.conf o linie ca aceasta:
*.*@hostname
Dacă în timpul pornirii demonului syslogd serverul va fi indisponibil (de exemplu, în prezent este deconectat de la rețea) sau nu va fi posibil să-l găsiți după nume (serviciul DNS nu a funcționat corect) syslogd face alte 10 încercări de a găsi serverul și numai dacă după aceea nu a fost posibil să găsească serverul, nu mai încearcă și trimite un mesaj corespunzător.
Dacă aveți mai multe domenii în rețea care sunt deservite de același server de înregistrare, nu fiți surprinși să vedeți numele complete ale clienților (inclusiv domeniul) în înregistrarea pe server. Într-adevăr, la pornire syslogd pot fi utilizate opțiuni -s lista_domenii sau -L listă de gazde, care oferă înlocuirea numelor de gazdă complete în protocol cu numele lor scurte (fără a specifica domeniul).
Nu uitați după ajustarea opțiunilor de lansare și a fișierului /etc/syslog.conf reporniți demonul pentru că, spre deosebire de cron, syslogd nu recitește automat fișierele de configurare.
Opțiuni de pornire a demonului syslogd
Deoarece am atins problema setării parametrilor de pornire a demonului în subsecțiunea anterioară syslogd să ne uităm la această problemă mai detaliat. După cum sa menționat deja, ambii daemoni de logare sunt lansate în etapa de inițializare a sistemului și, mai precis, printr-un script /etc/rc.d/init.d/syslog(pentru care, precum și pentru scripturile de pornire ale altor servicii, se creează legături simbolice în directoarele /etc/rc.d/rc?.d/). Cu toate acestea, nu este nevoie să modificați acest script pentru a seta parametrii de pornire, deoarece, începând cu versiunea 7.2 în distribuția Red Hat, opțiunile de pornire pentru ambii demoni sunt citite dintr-un fișier de configurare separat. /etc/sysconfig/syslog. Iată o listă scurtă de parametri posibili pentru demon syslogd.Parametri de lansare syslogd:
- -o priză- Specifică un socket suplimentar pe care demonul va asculta syslogd. Puteți specifica până la 19 prize (sunt posibile mai multe, dar pentru aceasta trebuie să recompilați pachetul). Această opțiune este folosită atunci când un alt demon (cum ar fi ftp sau http) rulează într-un mediu restricționat (face un chroot).
- -d- Modul de depanare. În același timp, demonul nu trece în fundal și trimite toate mesajele către terminalul curent.
- -f config-filename Specifică numele unui fișier de configurare alternativ care va fi utilizat în locul celui implicit. /etc/syslog.conf.
- -h Implicit în syslogd este interzisă transferarea mesajelor primite prin rețea către un alt computer. Acest lucru se face pentru a evita transferurile nesfârșite de mesaje în jurul inelului. Opțiunea -h vă permite să suprascrieți comportamentul normal și să vă asigurați că mesajele primite de la gazdele de la distanță sunt redirecționate în rețea (și aveți grijă de posibilele bucle).
- -l listă de gazde- Specifică o listă de gazde ale căror nume nu trebuie scrise cu numele complet de domeniu (FQDN - Full Qwalified Domain Name); numele din listă sunt separate prin două puncte.
- -m minute Lansat fără această opțiune syslogdînregistrează în mod regulat (la fiecare 20 de minute) mesajele din categoria marcă, adică doar marcaje temporale. Cu optiune -m puteți fie să modificați intervalul dintre semne, fie să anulați complet emiterea unor astfel de mesaje, pentru care trebuie să setați intervalul la zero: -m0.
- -n Nu treceți în fundal; opțiunea este necesară în cazurile în care syslogd este pornit și controlat de un proces init.
- -p priza Specifică un socket UNIX alternativ (în loc de ascultarea implicită /dev/log). Vă rugăm să rețineți: opțiune -A specifică prize suplimentare și -p- alternativă!
- -r Permiteți primirea mesajelor de la gazde la distanță. Am vorbit despre asta în secțiunea anterioară, așa că omit detaliile.
- -s lista de domenii Specifică o listă de domenii ale căror nume nu trebuie înregistrate împreună cu numele gazdei (adică, pentru aceste domenii, numai numele gazdei vor fi înregistrate în loc de numele de domeniu complet calificat (FQDN). Numele din listă sunt separate prin două puncte Numele domeniului în care se află serverul syslogd nu este necesar în această listă (numele acestuia este eliminat implicit).
- -v Afișați versiunea și finalizați.
- -X Interzicerea stabilirii unui nume de gazdă din adresa sa previne blocajul atunci când rulează pe aceeași gazdă cu serverul DNS.
După pornirea demonului syslogd este creat fișierul de stare /var/lock/subsys/syslog lungime zero și un fișier cu ID de proces /var/run/syslogd.pid.
Cu comanda
kill -SIGNAL `cat /var/run/syslogd.pid`
poți trimite la demon syslogd unul dintre următoarele semnale:
- SIGHUP - repornire demon (reinițializare); toate fișierele deschise sunt închise, demonul repornește, recitindu-și fișierul de configurare.
- SIGTERM - oprire.
- SIGINT, SIGQUIT - dacă modul de depanare este activat (opțiunea -d), semnalele sunt ignorate, în caz contrar - ieșire.
- SIGUSR1 - activarea/dezactivarea modului de depanare (funcționează numai dacă demonul a fost pornit cu comutatorul -d).
Daemon klogd are cel puțin la fel de multe opțiuni de lansare ca syslogd, totuși, nu le vom da aici, îndrumarea cititorului către pagina de manual corespunzătoare (utilizatorul nu trebuie să configureze klogd, este mai bine să-l lăsați în stare așa cum a fost produs de dezvoltatorii distribuției).
fișierul dmesg și comanda dmesg
După cum sa menționat deja, fișierele jurnal menționate în fișier /etc/syslog.conf se află de obicei în director /var/logși subdirectoarele sale. Dar, dacă ne uităm în acest director, vom găsi acolo câteva fișiere, care în /etc/syslog.conf nu au fost mentionate. Să ne uităm la scopul lor. Să începem cu fișierul dmesg.În primul rând, este necesar să menționăm că Linux are o comandă cu același nume. Dacă comparăm rezultatul acestei comenzi (când este rulat fără parametri) cu conținutul fișierului /var/log/dmesg, veți descoperi că sunt foarte asemănătoare, deși nu identice (direcționați ieșirea comenzii către un fișier dmesg2și compara fișiere dmesgȘi dmesg2). Mai exact, dosarul /var/log/dmesg one to one coincide cu începutul ieșirii pe care o primim la comandă dmesg. După cum urmează din , nucleul are un buffer inel în care sunt scrise mesajele de la demonul de înregistrare a nucleului. Acele mesaje care sunt scrise în acest buffer în timpul procesului de descărcare și alcătuiesc conținutul fișierului /var/log/dmesg. Aparent, acest fișier este format la sfârșitul pornirii sistemului.
Dacă te uiți din nou la lista de fișiere de mai sus /etc/syslog.conf, vei vedea că toate postările din categorie kern emis și pentru consolă. Dar acolo trec repede pe ecran și cu greu ai timp să le citești și să le înțelegi. Dar sunt salvate într-un fișier /var/log/dmesgși astfel disponibil pentru reflecție pe îndelete (dacă procesul de descărcare s-a încheiat cu succes). După finalizarea procesului de pornire, scrierea mesajelor din nucleu în buffer-ul de inel continuă. Când comanda este executată dmesg, starea curentă a tamponului este returnată. Prin urmare, rezultatul acestei comenzi conține mai multe mesaje decât fișierul /var/log/dmesg: în rezultatul acestei comenzi, puteți vedea, de asemenea, mesajele pe care nucleul le emite după finalizarea procesului de pornire.
Toate mesajele de la /var/log/dmesg veti gasi in dosar /var/log/messages, doar acolo alternează cu mesaje din alte programe. Există o singură diferență semnificativă: în dosar dmesg ora și sursa mesajului (numele de gazdă și categoria mesajului) nu sunt specificate. Gazda de aici este întotdeauna „locală”, iar începutul numărătorii inverse este determinat de ultima repornire a computerului.
fișierele lastlog, wtmp și utmp
Cu excepția fișierului dmesgîn catalog /var/log/ mai sunt două fișiere care nu sunt menționate în /etc/syslog.conf, dar direct legate de înregistrare - acestea sunt fișiere ultimul logȘi wtmp. Dar priviți-le în același mod în care am căutat prin fișier /var/log/messages nu are sens - nu vei înțelege nimic. Faptul este că informațiile din aceste fișiere sunt înregistrate într-un format special și trebuie vizualizate folosind instrumente software speciale. Dar mai întâi trebuie să spunem câteva cuvinte despre scopul acestor fișiere.
Fişier ultimul log stochează informații despre ultima conectare a utilizatorului la sistem. Nu știu dacă ați observat că atunci când introduceți un nume de utilizator și o parolă, pe ecran apare un mesaj ca acesta:
Conectare localhost: kos Parola: Ultima conectare: miercuri 9 octombrie 19:25:53 pe tty1 Aceste trei linii sunt generate de utilitar Autentificare, care, după ce a stabilit că utilizatorul are drepturi de autentificare, accesează fișierul /var/log/lastlog, extrage de acolo informații despre autentificarea anterioară cu succes a utilizatorului, le afișează pe ecran și apoi actualizează intrarea din fișier ultimul log. Puteți suprima acest mesaj creând un fișier .hushlogin gol în directorul dvs. principal. Cu toate acestea, nu este recomandat să faceți acest lucru, mai degrabă, dimpotrivă, merită să acordați o atenție deosebită conținutului acestui mesaj pentru a nu rata cazurile în care altcineva s-a conectat sub numele dvs.
Spre deosebire de dosar /var/log/lastlog, care conține intrări de timp ultimul autentificarea fiecărui utilizator, în fișier /var/log/wtmp sunt amintite toate autentificarea și deconectarea utilizatorilor de când a fost creat acest fișier. Ca în dosar ultimul log, înregistrează în /var/log/wtmp sunt realizate într-un format special, astfel încât să poată fi vizualizate doar folosind comenzi speciale. Dar, înainte de a vorbi despre aceste comenzi, să spunem că există un alt fișier care conține intrări despre înregistrarea utilizatorilor - acesta este fișierul /var/run/utmp. Acest fișier conține informații despre ce utilizator este conectat în prezent în sistem.
Acum puteți vorbi despre cum să vizualizați informații despre utilizatorii care lucrează sau au lucrat anterior în sistem. Comanda principală pentru aceasta este comanda ultimul. Scoate toate înregistrările dintr-un fișier /var/log/wtmp, și numele utilizatorului, o indicație a terminalului de la care a lucrat utilizatorul, ora la care utilizatorul a intrat în sistem și ora la care a părăsit sistemul, precum și durata sesiunii utilizatorului în sistem. Dacă munca utilizatorului a fost întreruptă numai din cauza închiderii sistemului în sine, în locul timpului de ieșire al utilizatorului există cuvântul „jos” (este ușor să determinați timpul de oprire a sistemului din aceste linii). Ora de repornire este afișată pe rânduri separate, începând cu cuvântul „repornire”.
Comanda ultimulb ca o echipă ultimul, dar afișează informații despre încercările eșuate de conectare a utilizatorului. Cu toate acestea, trebuie remarcat că această comandă va funcționa numai dacă fișierul există. /var/log/btmp. Cu toate acestea, niciunul dintre programele discutate aici nu creează fișiere jurnal, așa că dacă unul dintre ele este șters, atunci păstrarea înregistrărilor se încheie.
Comanda ultimul log formatează și scoate conținutul unui fișier /var/log/lastlog. Vor fi afișate numele de utilizator, numele terminalului de la care utilizatorul s-a autentificat și ultima oră de conectare. Implicit (atunci cand comanda este introdusa fara parametri) elementele fisierului /var/log/lastlog va fi scos în ordinea numerelor ID utilizator. Dacă specificați opțiunea -u login-name, vor fi afișate numai informații despre ultima oră de conectare a utilizatorului specificat. Specificând opțiunea -t zile, veți obține doar înregistrări pentru ultimele zile de zile. Dacă utilizatorul nu s-a autentificat încă deloc, atunci în locul numelui terminalului și al ultimei ore de conectare, va fi indicat șirul „**Never logged in**”.
La executarea comenzii ultimul log pe un computer lent, în unele cazuri poate părea că comanda este „atârnată”. Acest lucru se datorează faptului că, chiar dacă doar doi utilizatori (root și user) sunt înregistrați în sistem, în fișier /var/log/lastlog spațiu este încă alocat pentru numărul maxim posibil de utilizatori care pot lucra în sistem. Prin urmare, în dosar /var/log/lastlog pot exista decalaje mari între numerele de identificare ale utilizatorilor care s-au autentificat. Deoarece atunci când vizualizați astfel de intervale, programul nu afișează informații pe ecran și există o impresie de „atârnat”.
Pentru a afișa informații despre cine lucrează în prezent în sistem, utilizați comenzile w, careȘi utilizatorii. Comanda utilizatorii este folosit atunci când doriți doar să știți care utilizator este în prezent conectat la sistem, dar nu sunteți interesat de ce terminal s-a conectat și ce face. Dacă doriți să știți cine este conectat de la ce terminal, utilizați comanda care. Această comandă imprimă informații dintr-un fișier /var/run/utmp. Îl puteți forța să scoată date dintr-un fișier /var/log/wtmp(sau orice alt fișier pentru care are sens) dacă specificați numele acestui fișier pe linia de comandă. Dar în rezultat, veți vedea în continuare doar numele de utilizator, o indicație a terminalului de la care utilizatorul s-a autentificat, ora de conectare și, în cazul unei autentificări de la un computer la distanță, numele acestui computer.
Comandă afișează mult mai multe informații w. În rezultatul său, veți vedea ora curentă, cât timp a funcționat sistemul, câți utilizatori sunt în prezent conectați la sistem și încărcarea medie a sistemului în ultimul minut, 5 și 15 minute. Apoi iese pentru fiecare utilizator:
După cum am menționat deja, comanda w imprimă informațiile stocate într-un fișier utmp. Apropo, conducere om afirmă că utilizatorilor obișnuiți ar trebui să li se refuze accesul la scriere la fișier utmp, deoarece multe programe de sistem (din anumite motive inexplicabile) depind de integritatea acestuia. Experiți riscul de a confunda fișierele cu statistici de sistem și de a face modificări la fișierele de sistem dacă permiteți oricărui utilizator să scrie în fișierul utmp.
Fișierele jurnal ale altor programe
Pe lângă acele fișiere despre care am vorbit deja, există și alte fișiere de protocol care sunt create de programe separate. Cele mai tipice exemple sunt protocoalele daemon. samba, ftpd sau httpd care sunt păstrate în dosare separate. Unele dintre aceste programe își creează protocoalele în subdirectoare ale directorului /var/log/, alții salvează protocoale în alte locuri. Și structura acestor fișiere poate diferi semnificativ de structura fișierelor create de sistem syslog. De exemplu, voi da câteva rânduri din protocolul serverului Apache rulează pe computerul meu: 192.168.36.21 - - "GET /ve/papers/new/log/ HTTP/1.1" 200 1774 "-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0 . 0) Gecko/20020530" 192.168.36.21 - - "GET /icons/back.gif HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0 ) Gecko/20020530" 192.168.36.21 - - "GET /icons/folder.gif HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko / 20020530" 192.168.36.21 - - "GET /icons/text.gif HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530 " 192.168.36.21 - - "GET /ve/papers/new/log/protok_lovim.htm HTTP/1.1" 200 46597 "http://linux/ve/papers/new/log/" "Mozilla/5.0 (X11; U ; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" 192.168.36.21 - - "GET /bugtraq.css HTTP/1.1" 404 279 "http://linux/ve/papers/new/log/protok_lovim .htm" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" 192.168.36.21 - - "GET /img/bug1.gif HTTP/1.1" 404 280 " http ://linux/ve/papers/new/lo g/protok_lovim.htm" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" 192.168.36.21 - - "GET /img/title.gif HTTP/1.1" 404 281 "http://linux/ve/papers/new/log/protok_lovim.htm" "Mozilla" /5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530" După cum puteți vedea, structura acestui fișier jurnal diferă semnificativ de ceea ce am văzut în jurnalele de sistem.Samba-server, pe lângă protocolul de operare al serverului principal, creează într-un subdirector /var/log/samba un număr de fișiere jurnal pentru diferite ocazii, în special fișiere separate pentru fiecare dintre utilizatorii cărora li se permite să utilizeze resursele furnizate de acest server. Dintr-un astfel de fișier, sunt luate următoarele două intrări:
smbd/service.c:make_connection(550) linux (192.168.36.10) conectați-vă la service public ca utilizator kos (uid=500, gid=500) (pid 1366) smbd/service.c:close_cnum(550) linux (192.168. 36.10) conexiune închisă la serviciul public Exemplele de mai sus arată că, dacă poți citi puțin limba engleză și înțelegeți structura înregistrărilor, puteți extrage o mulțime de informații utile din fișierele jurnal. Numai că trebuie extras din zăcăminte întregi de „rocă sterilă” - fișiere uriașe secvențiale de protocoale, care este o sarcină non-trivială. Prin urmare, au fost dezvoltate instrumente software speciale pentru analiza protocolului.
Mijloace de procesare a protocoalelor
Au fost dezvoltate o mulțime de programe și scripturi diferite pentru analiza protocolului. Mă voi limita la o scurtă descriere a două astfel de remedii: ceas de jurnalȘi ceas.
ceas de jurnal este un script Perl inclus cu distribuția standard Red Hat Linux. Chiar în momentul pregătirii acestui articol, versiunea 4.1 a acestui program a fost postată pe site-ul web al dezvoltatorului (și el este Kirk Bauer).
Ideea principală din spatele acestui program este că fișierul jurnal este trecut printr-un filtru care extrage din jurnal toate liniile (adică mesajele) care îndeplinesc criteriile date. Rezultatele sunt trimise prin e-mail utilizatorului specificat (root implicit). Filtrele pot fi scrise în orice limbaj de programare, dar autorul pachetului preferă Perl. Filtrele trebuie scrise în așa fel încât să citească datele din stdin și să scoată rezultatul în stdout.
Utilizare principală ceas de jurnal constă în includerea unui link către scriptul principal ( /etc/log.d/scripts/logwatch.pl) în directorul /etc/cron.daily, care determină execuția zilnică ceas de jurnal cu setările implicite. Link-ului i se dă un nume care începe cu „00” (de exemplu, 00-logwatch), astfel încât scriptul să ruleze înainte de logrotate.
Dar puteți rula scriptul și din linia de comandă. Desigur, dacă nu ați modificat parametrul de ieșire a informațiilor, atunci rezultatul muncii sale trebuie căutat în căsuța poștală a superutilizatorului. Dacă doriți să vedeți aceste rezultate pe ecran, atunci trebuie să specificați parametrul pe linia de comandă --imprimare- imprimați un raport către stdout.
Formatul general pentru rularea scriptului:
/etc/log.d/scripts/logwatch.pl [--detail nivel ] [--fișier jurnal jurnal-grup ] [--serviciu numele serviciului ] [--print] [--mailto adresa ] [--salva Nume de fișier ] [--arhive] [--gamă data-interval ]
Opțiunile implicite sunt stocate în fișierul /etc/log.d/logwatch.conf, comentariile în care fac posibilă înțelegerea semnificației opțiunilor din linia de comandă:
- LogDir - director relativ la care sunt luate în considerare numele de fișiere;
- MailTo - cui să trimită raportul;
- Imprimare - în loc să trimiteți raportul prin poștă, tipăriți-l la stdout;
- Salvați - în loc să trimiteți raportul prin poștă, salvați-l în fișierul specificat;
- Arhive - procesează nu numai versiunile curente ale jurnalelor, ci și copiile vechi create de logrotate;
- Interval - procesează intervalul de timp specificat: Toate, Azi, Ieri (ziua calendaristică de ieri);
- Detaliu - nivelul de detaliu al raportului: de la 0 la 10 sau Scăzut, Mediu, Ridicat;
- Service - Toate sau numele filtrului din /etc/log.d/scripts/services/ (pot fi specificate mai multe filtre);
- LogFile - Toate sau numele grupului de jurnal (pot fi specificate mai multe grupuri).
Mai multe informații despre scenariu ceas de jurnal vei gasi in .
Articolul descrie un alt script pentru procesarea fișierelor jurnal, care este inclus în distribuția Mandrake Linux. Acest script se numește ceas("Simple WATCHer") și este scris și în Perl.
Managementul muncii ceas realizat cu un singur fișier de configurare, implicit $HOME/.swatchrc. Acest fișier conține exemple de text (sub formă de expresii regulate) care ceas va căuta în fișierele jurnal. Fiecare astfel de tipar este urmat de o acţiune care ceas ar trebui să ia dacă găsește text care se potrivește cu modelul.
De exemplu, să presupunem că doriți să fiți avertizat de fiecare dată când se încearcă un atac de depășire a tamponului pe serverul dvs. web. Și știți că în astfel de cazuri în fișierul jurnal /var/apache/error.log apare un mesaj care conține cuvintele „Numele fișierului este prea lung”. În acest caz, în dosarul dvs .swatchrc introduceți următoarea afirmație:
Urmăriți /Numele fișierului prea lung/ e-mail [email protected], subiect=BufferOverflow_attempt
Nu voi da aici o descriere mai detaliată a programului. ceas. Un articol entuziast îi este dedicat, iar programul în sine poate fi găsit pe site. Vreau doar să subliniez și ceas, Și ceas de jurnal implementați un algoritm de procesare a fișierelor de protocol destul de primitiv, care se rezumă la căutarea protocolului pentru un șir de caractere dat (semnătură). Între timp, în primul rând, prezența unui astfel de șir adesea nu indică încă intruziunea unui atacator și, în al doilea rând, un atacator competent se poate ocupa de ștergerea urmelor activității sale. Un alt dezavantaj evident al produselor luate în considerare este că funcționează în „mod întârziat”, întrucât sunt lansate doar în program. Iar lupta împotriva intrușilor trebuie să se desfășoare „în timp real”, răspunzând imediat încercărilor de pătrundere în sistem. Prin urmare, produsele comerciale oferă sisteme de monitorizare care funcționează continuu și implementează algoritmi de analiză a protocolului „inteligenți”. Acești algoritmi se bazează pe analiza statistică a fluxului de mesaje și pe identificarea abaterilor semnificative statistic ale sistemului de la comportamentul său normal.
În încheierea acestei secțiuni, aș dori să remarc faptul că site-ul web SecurityLab.ru (http://www.securitylab.ru/tools/?ID=22111) conține o listă de link-uri către site-uri web ale diferitelor instrumente software de procesare a protocolului cu un o scurtă descriere a acestor instrumente. Puteți experimenta cu diferite programe și alegeți pe cel care vi se potrivește.
Rotație fișier jurnal
Desigur, înțelegeți că, dacă sistemul este utilizat intens, atunci fișierele jurnal cresc rapid. Ceea ce duce la o risipă de spațiu pe disc. De asemenea, există o problemă de „îmblânzire” a protocoalelor. Red Hat Linux rezolvă această problemă cu un script. logrotate, care se află în director /etc/cron.daily, și, prin urmare, condus de demon cron zilnic. Acest script vă permite să procesați nu numai jurnalele de sistem syslog dar și orice alte programe.Scenariul logrotate monitorizează creșterea fișierelor jurnal și asigură așa-numita rotație a acestor fișiere dacă depășesc dimensiunea specificată (sau după intervalul de timp specificat). Rotirea nu este altceva decât copierea secvențială a versiunilor anterioare ale fișierelor de arhivă în următorul mod:
și crearea unui nou fișier de mesaje pentru a înregistra mesajele ulterioare.
Lista fișierelor care urmează să fie procesate de script logrotate iar parametrii acestei prelucrări sunt determinați de fișierele de configurare, care pot fi mai multe. Numele fișierelor de configurare sunt specificate în linia de comandă de lansare a scriptului (vezi opțiunile de lansare de mai jos). Pe Red Hat Linux, implicit, ca fișiere de configurare pentru logrotate este utilizat fișierul /etc/logrotate.conf, care ar putea arăta cam așa:
Rotiți săptămânal 4 create compress include /etc/logrotate.d /var/log/wtmp /var/log/lastlog (creați lunar 0664 root utmp rotate 1)
Acest fișier este ca orice fișier de configurare pentru un script. logrotate constă din mai multe secțiuni. Prima secțiune definește opțiunile globale (una pe linie) care stabilesc opțiunile implicite pentru toate jurnalele. Următoarele secțiuni definesc opțiunile locale pentru o serie de fișiere jurnal. Numele acestor fișiere sunt listate în prima linie a secțiunii, iar apoi parametrii locali sunt setați între acolade care sunt validi numai la procesarea fișierelor specificate (tot un parametru pe linie). Numele fișierelor jurnal pot fi citate conform regulilor shell-ului dacă conțin spații sau alte caractere speciale. Puteți specifica mai multe nume de fișiere sau modele de nume de fișiere separate printr-un spațiu (șabloanele urmează și regulile shell-ului). Prelucrarea fiecărei secțiuni este tratată ca o singură acțiune. Rândurile care încep cu „#” sunt comentarii. Setările locale au prioritate față de cele globale.
În exemplul de fișier de configurare dat, sunt descriși mai întâi parametrii globali, iar apoi, într-o secțiune separată, parametrii pentru procesarea fișierelor /var/log/wtmp și /var/log/lastlog. În plus, printre parametrii globali, este dat un link către director /etc/logrotate.d, în care fiecare pachet scrie setări locale pentru jurnalele sale.
În secțiunea de setări globale, este setat mai întâi unul dintre următorii parametri, care determină criteriile de rotație a fișierelor:
și parametru include, urmat de numele altui fișier de configurare (suplimentar) sau chiar de numele unui director. În acest din urmă caz, toate fișierele din directorul specificat, cu excepția subdirectoarelor, fișierelor speciale și fișierelor cu sufixe din lista de excludere, sunt considerate fișiere de configurare pentru script. logrotate(directivă include nu poate fi utilizat în interiorul unei secțiuni care specifică parametrii de procesare pentru un grup de fișiere).
Parametru roti număr poate fi localizat atât printre parametrii globali cât și printre cei locali și determină câte versiuni vechi ar trebui stocate; dacă numărul este 0, nu sunt create versiuni arhivate ale protocolului.
Dacă parametrul este setat comprima, apoi versiunile mai vechi sunt comprimate cu gzip, iar dacă este specificat fara compresie- nu se comprimă. Parametru comprima cmd vă permite să specificați ce program de compresie va fi utilizat (implicit este gzip) și decomprimați cmd specifică programul de decompresie (implicit este ungzip). opțiuni de compresie setează parametrii programului de compresie; implicit este „-9”, adică compresie maximă pentru gzip. Folosind parametrul compresext puteți schimba sufixul pentru fișierele comprimate și opțiunea extensie sufix specifică un sufix care trebuie adăugat la numele fișierelor în timpul rotației (înainte de sufixul de compresie).
Printre cuvintele cheie găsite în fișierele de configurare, cuvintele postrotateȘi prerotate, care servesc drept paranteze de deschidere pentru includerea scripturilor shell în fișierele de configurare. Toate liniile fișierului de configurare din linie postrotate până la linie script final sunt executate ca comenzi shell după procesul de schimbare a versiunii fișierului jurnal. În consecință, toate liniile din linie prerotate până la linie script final sunt executate înainte ca fișierele jurnal să fie rotite. Folosind aceste scripturi, puteți organiza diverse proceduri pentru procesarea fișierelor jurnal în timpul rotației.
Folosind alți parametri ai fișierului de configurare, puteți suprascrie drepturile de acces la fișierele jurnal (dacă acest parametru nu este setat, atunci sunt utilizate atributele vechiului fișier jurnal); specificați cui să trimiteți mesaje de eroare despre funcționarea sistemului de logare; trimiteți o copie de arhivă a jurnalului utilizatorului specificat; specificați un director în care vor fi mutate protocoalele în timpul unei schimbări de versiune (directorul trebuie să fie pe același dispozitiv fizic ca /var/log) sau specificați o listă de sufixe de excludere pentru director include. O descriere detaliată a acestor caracteristici și opțiuni (precum și a celor care nu au fost menționate) poate fi găsită la comandă manlogrotate.
După cum am menționat deja, fișiere de configurare suplimentare logrotate poate fi specificat pe linia de comandă de lansare a scriptului. Puteți specifica un număr arbitrar de nume de fișiere de configurare sau de director. Numele fișierelor și directoarelor din această listă sunt separate prin spații simple. Ordinea numelor din listă contează deoarece opțiunile specificate în următorul fișier de configurare suprascriu semnificația opțiunilor specificate în fișierul anterior. Ordinea fișierelor din directorul de configurare nu este definită.
De asemenea, puteți specifica următoarele opțiuni pe linia de comandă de lansare:
- -d- modul de depanare, nu se fac modificări reale,
- -f- face modificări chiar dacă logrotate nu vede nevoia - este utilizat pentru modificări în lista de jurnalele procesate,
- om ceas de jurnal
- Mick Bauer, „Paranoid Penguin: swatch: Automated Log Monitoring for Vigilant but Lazy”
- RFC 3164. C. Lonvick, Protocolul BSD Syslog, august 2001.
- RFC 3195. D. New, M. Rose, Reliable Delivery for syslog, noiembrie 2001.
- Pe. S. Lapshansky, „Demonul urmărește sistemul”
- Denis Kolisnichenko,
Precedarea numelui fișierului cu un caracter pipe (|) vă va permite să utilizați fifo (primul intrat - primul ieşit, primul intrat, primul iesit) sau conductă numită ca receptor de mesaje. Înainte de a porni (sau reporni) syslogd, trebuie creat un fifo folosind comanda mkfifo. Uneori, fifo este folosit pentru depanare.
Terminal și consola
Terminal precum /dev/console.
mașină la distanță
Pentru a redirecționa mesajele către o altă gazdă, precedați numele gazdei cu semnul (@). Rețineți că mesajele nu sunt redirecționate de la gazda care primește. (pentru ca această misiune să funcționeze pe client și server din fișier /etc/services linia trebuie scrisă syslog 514/udpși deschideți portul UTP 514)
o listă de utilizatori
Lista de utilizatori care primesc mesaje, separate prin virgulă (dacă utilizatorul este autentificat). Acesta include adesea utilizatorul root.
Toți utilizatorii înregistrați
Pentru a notifica toți utilizatorii înregistrați folosind comanda wall, utilizați caracterul asterisc (*).
Un exemplu de simplu syslog.conf:
# Imprimați toate mesajele kernelului pe consolă. #kern.* /dev/console # Toate jurnalele de nivel de informații sau mai mari, cu excepția e-mailurilor, și # nu înregistrați mesajele de autentificare și mesajele cron daemon! *.info;mail.none;authpriv.none;cron.none /var/log/messages # Înregistrați mesajele care conțin # informații confidențiale de autentificare într-un fișier separat, indiferent de nivelul lor. authpriv.* /var/log/secure # Toate mesajele din sistemul de e-mail sunt de asemenea scrise într-un fișier separat. mail.* -/var/log/maillog # Înregistrați mesajele de planificare în fișierul /var/log/cron cron.* /var/log/cron # Mesajele de urgență trebuie primite imediat # de către toți utilizatorii sistemului *.emerg * # Salvați mesajele știri de nivel critic și mai sus într-un fișier separat. uucp,news.crit /var/log/spooler # Stocați mesajele de boot în boot.log local7.* /var/log/boot.log
Ca și în cazul multor fișiere de configurare, sintaxa este:
- liniile care încep cu # și liniile goale sunt ignorate.
- Simbolul * poate fi folosit pentru a indica toate categoriile sau toate prioritățile.
- Cuvântul cheie special none indică faptul că înregistrarea pentru această categorie nu trebuie efectuată pentru această acțiune.
- O cratimă înaintea numelui fișierului (cum ar fi -/var/log/maillog în acest exemplu) indică faptul că jurnalul nu trebuie sincronizat după fiecare scriere. În cazul unei erori de sistem, este posibil să pierdeți informații, dar dezactivarea sincronizării va îmbunătăți performanța.
În sintaxa fișierului de configurare, puteți pune înaintea priorității semn! pentru a arăta că acțiunea nu trebuie aplicată, de la acest nivel în sus. În mod similar, prioritatea poate fi prefixată semn = pentru a indica faptul că regula se aplică numai la acel nivel sau != pentru a arăta că regula se aplică la toate nivelurile, cu excepția acestuia. Mai jos sunt câteva exemple (man syslog.conf puteți găsi multe alte exemple):
# Trimiteți toate mesajele nucleului către /var/log/kernel. # Trimite toate mesajele critice și de nivel superior către mașina Sysloger de la distanță și consola # Trimite toate mesajele de nivel de informații, notificări și avertismente la /var/log/kernel-info # kern.* /var/log/kernel kern.crit @sysloger kern .crit /dev/console kern.info;kern.!err /var/log/kernel-info # Trimiteți toate mesajele sistemului de e-mail, cu excepția nivelului de informații, la /var/log/mail. mail.*;mail.!=info /var/log/mail
Am încercat să arăt activitatea lui syslogd cât mai clar posibil pe diagramă:
Pornirea demonului syslogd
Lansarea demonului de logare este începută în etapa de inițializare a sistemului prin intermediul unui script /etc/rc.d/init.d/syslog, cu toate acestea, pentru a seta opțiunile de lansare, nu este nevoie să modificați acest script - începând cu versiunea 7.2, opțiunile de lansare sunt citite dintr-un fișier de configurare separat /etc/sysconfig/syslog (/etc/default/syslogîn debian).
Iată câteva posibile Parametrii de pornire a demonului syslogd:
- -un /folder/socket- specificarea unei prize de ascultare suplimentare (nu uitați să creați o priză în prealabil)
- -d- modul de depanare. În acest caz, demonul nu trece în fundal și trimite toate mesajele către terminalul curent;
- -f config-file-name. Specifică numele unui fișier de configurare alternativ care va fi utilizat în loc de /etc/syslog.conf implicit;
- -l listă de gazde- setarea unei liste de gazde ale căror nume nu trebuie scrise cu numele complet de domeniu (FQDN - Full Qwalified Domain Name);
- -m minute- rulând fără această opțiune, sysklogd înregistrează mesajele cu marcajul categoriei (marcate de timp) la fiecare 20 de minute. Cu opțiunea -m, puteți fie să modificați intervalul dintre semne, fie să opriți complet emiterea de astfel de mesaje;
- -p priza- setarea unui socket UNIX alternativ (în loc de /dev/log de ascultare implicită);
- -r- permisiunea de a primi mesaje de la gazde la distanță;
- -X- interzicerea determinării numelui gazdei după adresa sa pentru a preveni înghețarea atunci când se lucrează pe aceeași gazdă cu serverul DNS.
- -v- arata versiunea si termina lucrarea
După pornirea demonului syslogd, este creat un fișier de stare /var/lock/subsys/syslog lungime zero și un fișier cu ID de proces /var/run/syslogd.pid.
Cu comanda
kill -SIGNAL `cat /var/run/syslogd.pid`
poate fi trimis daemon syslogd unul dintre următoarele semnale: SUPRAȚI- repornirea demonului; SIGTERM- finalizarea lucrărilor; SIGUSR1- activați/dezactivați modul de depanare.
De fapt, în sistem sunt lansate doi daemoni de înregistrare - syslogdȘi klogd. Ambii demoni sunt incluse în pachet syslogd.
demonul klogd responsabil pentru înregistrarea evenimentelor care au loc în miezul sistemului. Necesitatea unui daemon klogd separat se datorează faptului că nucleul nu poate utiliza funcția standard syslog. Acest lucru se datorează faptului că bibliotecile standard C (inclusiv biblioteca care conține funcția syslog) sunt destinate să fie utilizate numai de către aplicatii comune. Deoarece nucleul are nevoie și de funcții de logare, acesta include propriile biblioteci care nu sunt disponibile pentru aplicații. Prin urmare, nucleul folosește propriul mecanism de generare a mesajelor.
demonul klogd menite să organizeze procesarea acestor mesaje. În principiu, poate face această procesare complet pe cont propriu și independent de syslogd, cum ar fi scrierea acestor mesaje într-un fișier, dar în cele mai multe cazuri este folosită setarea implicită klogd, în care toate mesajele din nucleu sunt redirecționate către același syslogd. demonul.
Rotație automată (actualizarea fișierelor umplute) și arhivarea jurnalelor
În timp, fișierul jurnal tinde să crească, mai ales când un serviciu rulează intens. În consecință, este necesar să se poată controla dimensiunea buștenilor. Acest lucru se face folosind comenzile logrotate, care se realizează de obicei demonul cron. Voi vorbi despre munca lui cron în articolele următoare. obiectivul principal comenzile logrotate este să faceți periodic copii de rezervă ale jurnalelor și să creați noi jurnale curate. Se salvează mai multe generații de jurnale, iar când expiră jurnalul de ultima generație, acesta poate fi arhivat (comprimat). Rezultatul poate fi trimis prin poștă, de exemplu, către persoana responsabilă de arhivare.
Pentru a determina ordinea de rotație și arhivare a jurnalelor, utilizați Fișier de configurare /etc/logrotate.conf . Pentru jurnalele diferite, puteți seta o periodicitate diferită, de exemplu, zilnic, săptămânal sau lunar, în plus, puteți ajusta numărul de generații acumulate, precum și să specificați dacă copii ale arhivelor vor fi trimise managerului de arhivă și, dacă deci când. Mai jos este prezentat exemplu de fișier /etc/logrotate.conf:
# setați mai întâi parametrii impliciti (opțiuni globale) # actualizați fișierele jurnal săptămânal săptămânal # stocați arhiva jurnalului pentru ultimele 4 săptămâni rotiți 4 # creați un fișier nou (gol) după rotație (actualizare) creați # decomentați dacă doriți ca fișierele salvate să fie comprimate #comprimați # activați setările de rotație din directorul specificat includ /etc/logrotate.d # nu stocați wtmp sau btmp - setările de rotație a datelor de jurnal sunt după cum urmează: /var/log/wtmp (missingok lunar create 0664 root utmp rotate 1) / var/log/btmp ( missingok creați lunar 0664 root utmp rotiți 1 ) # syslog-uri specifice pot fi configurate mai jos
Opțiunile globale sunt plasate la început fișier logrotate.conf. Ele sunt folosite implicit, cu excepția cazului în care ceva mai specific este specificat în altă parte. În exemplu, bustenii sunt rotiti săptămânal iar copiile de rezervă sunt păstrate pentru patru săptămâni. De îndată ce un jurnal este rotit, unul nou este creat automat în locul vechiului jurnal. fișier logrotate.conf poate conține specificații din alte fișiere. Deci, include toate fișierele din director /etc/logrotate.d.
Acest exemplu conține și reguli speciale pentru /var/log/wtmpȘi /var/log/btmp(stochează informații despre încercările reușite și nereușite de a intra în sistem), a căror rotație are loc lunar. Dacă fișierele lipsesc, nu este emis niciun mesaj de eroare. Se creează un fișier nou și se păstrează o singură copie de rezervă.
În acest exemplu, când backup-ul ajunge la ultima generație, acesta este șters deoarece nu este definit ce să facă cu el.
Backup-uri în jurnal poate fi, de asemenea, generat atunci când jurnalele ating o anumită dimensiune, iar scripturile pot fi generate din seturi de comenzi pentru a rula înainte sau după o operație de backup. Exemplu:
/var/log/messages ( rotiți 5 mail [email protected] dimensiune 100k postrotate /usr/bin/killall -HUP syslogd endscript)
În acest exemplu, rotația /var/log/messages este produs când atinge dimensiunea de 100 KB. Se acumulează cinci copii de rezervă, iar când expiră cea mai veche copie de rezervă, aceasta este trimisă prin poștă [email protected] Cuvântul de comandă postrotate include un script care repornește demonul syslogd după ce rotirea este completă prin trimiterea unui semnal HUP. Cuvântul de comandă endscript este necesar pentru a termina scriptul și, de asemenea, dacă există un script prerotate. Consultați paginile de manual pentru logrotate pentru mai multe informații.
Parametrii, setat în fișierul de configurare logrotate.conf:
- comprima| fara compresie(versiunile mai vechi comprimă sau nu se comprimă cu gzip)
- comprima cmd(specifică programul de compresie, implicit este gzip)
- decomprimați cmd(setează decompresorul, implicit este ungzip)
- compresext(setează sufixul pentru fișierele comprimate)
- opțiuni de compresie(setează parametrii programului de compresie; implicit este „-9”, adică compresia maximă pentru gzip)
- copytruncate| nocopytruncate(de obicei, versiunea veche este redenumită și se creează o versiune nouă a jurnalului; cu această opțiune, logrotate copiază jurnalul într-un fișier nou și apoi îl trunchiază pe cel vechi; folosit dacă programul care creează jurnalul nu știe cum să se închidă acesta; înregistrările făcute în intervalul dintre copiere și trunchiere se pierd; ar fi de ajutor dacă programul de înregistrare în loc să folosească modul de adăugare doar scrie în fișier folosind un pointer intern?)
- crea[permisiuni-proprietar-grup] | nocreate(imediat după redenumirea vechii versiuni a jurnalului și înainte de a apela postrotate, se creează un nou jurnal cu atributele specificate - permisiunile sunt setate în octal, ca în chmod.2; dacă atributele nu sunt specificate, atunci acestea sunt preluate din jurnal vechi)
- zilnic(schimbarea versiunilor din serie are loc zilnic)
- delaycompress| nodelaycompress(unele programe nu închid imediat jurnalul, caz în care compresia ar trebui amânată până la următorul ciclu)
- erorie-mail(cui să raporteze erori)
- extensiesufix(specifică sufixul adăugat la numele fișierelor în timpul rotației înainte de sufixul de compresie)
- dacă gol| notificare gol(schimbați versiunile chiar dacă fișierul este gol; implicit)
- includeNume de fișier| nume-director (înlocuiește textual un fișier sau toate fișierele din directorul specificat; subdirectoarele, fișierele speciale și fișierele cu sufixe din lista de excludere nu sunt incluse; nu pot fi utilizate în interiorul unei secțiuni)
- Poștăadresa| nomail(atunci când o modificare a versiunii necesită ștergerea vechiului jurnal, apoi trimiteți-l la adresa specificată)
- mail first(trimiteți nu versiunea ștearsă a jurnalului, ci prima)
- mailast(trimite versiunea jurnalului pentru a fi ștearsă; implicit)
- lipsingok| nomissingok(nu trimiteți mesaje de eroare dacă lipsește jurnalul)
- lunar(versiunea se schimbă lunar)
- olddirdirector| noolddir(în timpul unei schimbări de versiune, jurnalul este mutat în directorul specificat; trebuie să fie pe același dispozitiv fizic)
- postrotate(toate liniile ulterioare până la linia endscript sunt executate ca comenzi shell după procesul de schimbare a versiunii)
- prerotate(toate liniile ulterioare până la linia finală sunt executate înainte de procesul de schimbare a versiunii)
- rotinumăr(câte versiuni vechi să păstrați; dacă 0, atunci niciuna)
- mărimeaoctet(schimbarea versiunii are loc dacă dimensiunea jurnalului depășește numărul specificat; puteți utiliza sufixele „k” - kilobyte - și „M" - megabyte)
- scripturi partajate| nosharedscripts(executați comenzile de prerotate și postrotate o singură dată pentru toate fișierele descrise în secțiunea)
- tabooext[+] sufix-list(setarea unei liste de sufixe de excludere pentru include; dacă este specificat un semn plus, atunci adăugare, în caz contrar înlocuire; implicit: .rpmorig, .rpmsave, .rpmnew, ",v", .swp și "~")
- săptămânal(versiunea se schimbă săptămânal)
Studierea și monitorizarea revistelor
Intrările de jurnal conțin de obicei un marcaj de timp, numele gazdei pe care rulează procesul descris și numele procesului. Vizualizați jurnalele Puteți utiliza un program de paginare, de exemplu, Mai puțin, puteți căuta anumite intrări (de exemplu, mesaje kernel de la un anumit demon) folosind comanda grep:
# mai puțin /var/log/messages # grep „ppp” /var/log/messages | tail Dec 17 16:34:25 proxy pppd: Conexiune terminată. 17 dec 16:34:25 proxy pppd: Ieșire. 17 decembrie 16:35:57 proxy pppd: LCP terminat de peer (^P]kV^@ Este posibil ca computerul să nu funcționeze în mod constant și să se oprească, să zicem noaptea. Prin urmare, intrările din /var/log/messages sunt stocate ciclic de la pornirea computerului până la oprire, acest lucru se poate vedea din mesaje: 17 decembrie 08:32:56 syslog-server syslogd 1.4-0: reporniți. 17 decembrie 08:32:56 syslog-server syslog: syslogd a început cu succes 17 decembrie 08:32:56 syslog-server kernel: klogd 1.4-0, sursa jurnal = /proc/kmsg început. 17 decembrie 08:32:56 syslog-server syslog: pornirea klogd a reușit 17 decembrie 08:32:56 kernel-server syslog: linie de comandă kernel: auto BOOT_IMAGE=linux ro root=303 BOOT_FILE=/boot/vmlinuz-2.4.2-2 17 decembrie 08:32:56 kernel-server syslog: Memorie: 125652k/130560k disponibile (1365k cod kernel, 4200k rezervat, 92k date, 236k init, 0k highmem) Dec 17 08:32:56 Syslog-server kernel: CPU: Intel(R) Pentium(R) 4GHz stepping 1.602 De asemenea, în acest fișier puteți găsi informații despre memoria discului (inclusiv informații despre geometria discului, structura partiției și întreruperile utilizate), informații despre dispozitivele periferice, despre pornirea serviciilor și serviciilor individuale, informații despre conectarea sistemelor de fișiere și mesajele de conectare ale utilizatorului. precum și mesajele de eroare. Uneori poate fi necesar monitorizarea jurnalului de sistem pentru a căuta evenimente curente. De exemplu, puteți încerca să surprindeți un eveniment care se întâmplă rar în momentul în care sa întâmplat. În acest caz, puteți utiliza comanda coadă cu optiune -f pentru a monitoriza conținutul jurnalului de sistem. Exemplu: # coada -f /var/log/messages | grep syslog-server 17 decembrie 16:46:09 syslog-server pppd: pptpd-logwtmp.so ip-up ppp0 maikop 94.77.0.150 17 decembrie 16:46:09 syslog-server pppd: Script /etc/ppp/ip-up terminat (pid 12552), stare = 0x0 17 decembrie 16:46:49 syslog-server pptpd: CTRL: Client 85.175.197.65 conexiunea de control începută 17 decembrie 16:46:49 syslog-server pptpd: CTRL: Pornirea apelului ppd deschidere GRE) 17 decembrie 16:46:49 syslog-server pppd: Plugin /usr/lib/pptpd/pptpd-logwtmp.so încărcat. În plus față de fișierele jurnal specificate în /etc/syslog.conf, există și alte fișiere, cum ar fi un fișier care stochează informații despre procesul de pornire a sistemului înainte ca syslogd să fie pornit, precum și fișiere care au un format binar și stocați informații despre ultima conectare a unui utilizator la sistem, despre toate conectările reușite ale utilizatorilor și, respectiv, despre toate conectările nereușite ale utilizatorilor. Directorul /var/log/ poate conține, de asemenea, fișiere jurnal pentru demoni, cum ar fi un server web sau un server proxy. Formatul acestor fișiere este similar cu jurnalele syslogd. În sfârșit, aș dori să subliniez că acest protocol nu este foarte sigur, deoarece. syslog nu conține nicio protecție împotriva falsificării mesajelor. Și mai rău, utilizarea protocolului UDP permite atacatorilor să trimită mesaje în numele oricărei gazde. LAN-ul dumneavoastră trebuie să fie protejat împotriva primirii de pachete cu adrese locale falsificate (deși acest lucru nu împiedică trimiterea mesajelor falsificate din interiorul rețelei LAN) și a primirii pachetelor din exterior pe portul 514/udp. Sunt cunoscute cazuri de debordare a discului cu mesaje false. Protocolul syslog și UDP nu oferă livrare garantată (mesajele pot fi pierdute din cauza congestionării rețelei sau interceptate, mesajele corupte sunt șterse fără avertisment), secvență de livrare corectă (un mesaj de terminare a procesului poate ajunge înainte de un mesaj de începere a procesului), livrare prioritară. Confidențialitatea mesajelor nu este asigurată, acestea fiind transmise în text clar. Dacă specificați o adresă incorectă a colectorului sau a releului la configurarea generatorului de mesaje, atunci nu vor fi mesaje de eroare - mesajele vor fi șterse (sau vor fi scrise în jurnalul altcuiva). Au fost propuse mai multe proiecte pentru a îmbunătăți protocolul syslog. De exemplu, RFC 3195 propune un sistem de înregistrare bazat pe TCP (syslog-conn) care asigură că mesajele sunt livrate în secvența corectă. Proiectul syslog-sign propune să ofere autentificare, ordonarea mesajelor, integritatea mesajelor și detectarea mesajelor lipsă prin generarea de mesaje speciale care conțin o semnătură digitală a unui bloc de mesaje anterioare, menținând în același timp protocolul și formatul standard syslog și folosind UDP. Să rezumăm puțin: Linux are un singur demon responsabil pentru înregistrarea evenimentelor din sistemul local și sistemele de la distanță. Toate evenimentele sunt colectate de la socketul /dev/log, portul UDP - 514, precum și de la demonul klogd „helper”, care trimite mesaje din kernel. Toate mesajele colectate sunt filtrate de demonul syslogd prin regulile din fișierul /etc/syslog.conf și distribuite către destinațiile corespunzătoare conform regulilor. Fișierele jurnal sunt periodic „decupate”. Frecvența este determinată de fișierul logrotate.conf și de comanda logrotate, care este rulată de programatorul de sistem - cron. Asta e tot pentru azi. Sper că am descris totul cât mai clar posibil. Cu timpul, voi completa articolul! Cu stimă, Mc.Sim!