Arkisto ajaksi 'Logging "luokkaan

Yhdistämällä Logwatch ja OSSEC - Osa 4

18 helmikuu 2010

Minun viimeinen viesti asensimme Logwatch sekä OSSEC. Nyt on aika saada Logwatch ja OSSEC pelissä samassa hiekkalaatikossa. Tässä post tulen keskustelemaan, miten saada Logwatch yhteenvedon tiedot ovat tuottaman OSSEC.

Asennusvaihtoehdot

Meillä on kaksi polkuja voimme seurata teet asetukset:

  1. Onko Logwatch jäsentää OSSEC lokit suoraan.
  2. Onko OSSEC lähettää hälytyksiä Syslog tyyppi palvelimeen, suorita Logwatch siitä lokipalvelin.

Hyötyä optio # 1 on, että tarvitsemme vain yksi järjestelmä. Logwatch ajetaan järjestelmässä hosting OSSEC palvelimelle. Ongelma aiomme törmätä kuitenkin liittyy OSSEC hälytys tiedosto. Kirjaudu merkinnät eivät saa normalisoitunut. Tämä tarkoittaa muoto voi muuttua pääse pääsy, ja se voi jopa jakaa usealle riville. Se tulee olemaan todellinen painajainen luoda Logwatch komentosarjan, joka suodattaa ja yhteenveto ilmoituksilla.

Jos me mennä optio # 2, vaadimme toinen laatikko toimimaan Keskitettyjen kirjautumalla palvelimelle. Jotta OSSEC palvelin hyväksy lokitiedot ei-agentti järjestelmiä, se on kuuntelemaan UDP/514. Tämä on sama käyttämä portti keskitetysti kirjautumalla palvelimelle, ja et voi olla kaksi hakemusta sama portti (paitsi Windows, mutta socket-yhteys on erittäin sotkuinen). Hyvänä puolena, hälytys merkinnät saavat normalisoitui, kun ne siirretään lokipalvelin näin ollen syntyy Logwatch yhteenveto skripti on paljon helpompaa. Lisäksi Logwatch jo tietää standardin Syslog tiedostoja, joten meillä on vähemmän räätälöintiä työtä.

Lopuksi mainitsin aiemmin viesti, joka OSSEC ei ole suunniteltu SIM. Tämä johtuu siitä ei tallenna kaikkea, vain tapahtumia, jotka tuottavat hälytys. Joten olemme luultavasti menossa halua keskitetylle palvelimelle joka tapauksessa, ja on järkevää olla se tallentaa tiedot ovat tuottaman OSSEC.

Joten jos se kuulostaa Olen ohjausryhmän sinua kohti optio # 2 Olet täysin oikeassa. Tämän sanoi, olen todella tulee kattaa optio # 1, koska se on paljon monimutkaisempi setup.

Suhtautuminen pvm / aikaleimat

Tutustu tärkein OSSEC lokitiedostoon ja sinun pitäisi nähdä seuraavanlainen:

[Root @ Fubar lokit] # tail -3 / var / ossec / logs / ossec.log

18.02.2010 12:32:05 ossec-rootcheck: INFO: Ending rootcheck skannata.

18.02.2010 14:27:06 ossec-syscheckd: INFO: Starting syscheck skannata.

18.02.2010 14:39:21 ossec-syscheckd: INFO: Ending syscheck skannata.

Huomaa miten päivämäärä / aikaleima on alustettu. Tämä on erilainen kuin useimmat sovellukset, joten ensimmäinen asia, joka meidän tulee tehdä, on kertoa Logwatch miten käsitellä tätä muotoa. Meidän täytyy luoda skriptin, että voimme soittaa tarvittaessa joka ymmärtää muodossa yllä.

Aloita siirtymällä jaettu scripts hakemistossa:

cd / usr / share / logwatch / scripts / jaettu

Käyttämällä mielimuokkaimellasi, luo tiedosto nimeltä "applylongdate":

vi applylongdate

Tässä on mitä tarvitset sisällä kyseisen tiedoston. Voit vapaasti kopioida / liittää tältä sivulta:

käyttää Logwatch ": päivämäärät";

my $ Debug = $ ENV {'LOGWATCH_DEBUG "} | | 0;

$ SearchDate = TimeFilter ('% Y /% m /% d% H:% M:% S ");

if ($ Debug> 5) {

Tulosta stderr "DEBUG: Inside ApplyLongDate ... \ n";

Tulosta stderr "DEBUG: Looking For:". $ SearchDate. "\ N";

}

while (määritelty ($ ThisLine = <STDIN>)) {

if ($ ThisLine = ~ m / ^ $ SearchDate / o) {

print $ ThisLine = ~ s / ^ .... \ / .. \ / .. ..:..:.. / /;

print $ ThisLine;

}

}

# VI: shiftwidth = 3 syntaksi = perl tabstop = 3 et

Kun olet tallentanut tiedoston, meidän täytyy nyt asettaa käyttöoikeudet:

chmod 755 applylongdate

Määritä Lokitiedostot

Seuraavaksi meidän täytyy kertoa Logwatch jossa OSSEC lokitiedostot sijaitsevat. Aina kun lisäät uusia lokitiedostot tai luoda uusia palveluja seuraamaan Logwatch, sinun tulee tehdä muutoksia alla / etc / logwatch hakemistosta. Aiomme luoda kaksi asetustiedostoja. Ensimmäinen käsittelee OSSEC viestejä, ja toinen käsittelee OSSEC hälytykset ja aktiivinen vaste muuttuu.

Aloitetaan luomalla konfigurointitiedostoa tärkein OSSEC lokitiedosto:

cd / etc / logwatch / conf / lokitiedostot

vi ossec.conf

Tiedoston sisältö pitäisi olla seuraa:

Logfile = / var / ossec / logs / ossec.log

* ApplyLongDate =

Voit nyt tallentaa ja poistua tiedosto. Seuraavaksi luomme config tiedostosta jäljellä lokitiedostot:

VI ossec-alert.conf

Tämän tiedoston sisällön pitäisi olla seuraa:

Logfile = / var / ossec / logs / aktiivinen-responses.log

Logfile = / var / ossec / logs / ilmoitukset / alerts.log

Logfile = / var / ossec / logs / palomuuri / firewall.log

Kun olet valmis, tallenna ja poistu. Oletuskäyttöoikeuksia pitäisi hyväksyä meidän setup.

Konfigurointi OSSEC Palvelut

Seuraavaksi meidän on määriteltävä OSSEC palvelut ja selvittää, mitä haluamme käyttää nimenä, kun raportteja syntyy. Näin voit luoda ensimmäisen tiedoston:

cd / etc / logwatch / conf / palvelut

vi ossec.conf

Tämän tiedoston sisällön on melko yksinkertainen:

Title = "OSSEC viestit"

Logfile = ossec

Kun olet valmis voit tallentaa ja poistua. Meidän on luotava yksi tiedosto tähän hakemistoon:

VI ossec-alert.conf

Tämän tiedoston sisällön pitäisi olla:

Title = "OSSEC hälytykset"

Logfile = ossec-hälytys

Kun olet valmis, tallenna ja poistu normaalisti.

Jäsennys Merkinnät

Seuraavaksi meidän täytyy kertoa Logwatch kuinka muotoilla lokitiedot sisällä raportti. Meidän on luotava räätälöinnin käsikirjoitus kullekin laajemman palveluvalikoiman. Aiomme aloittaa käyttämällä Logwatch mukana testikoodi, vain varmista, kaikki toimii.

Aloita siirtymällä asianmukainen hakemisto:

cd / etc / logwatch / scripts / palvelut

Käytä mielimuokkaimellasi luomaan ensimmäinen käsikirjoitus:

vi ossec

Sisältö käsikirjoituksen pitäisi olla seuraa:

#! / Bin / bash

# Tämä on niin mukavaa skripti, joka näyttää sinulle linjat tulet

# Voidaan käsittely ja raportointi. Se ensimmäinen näyttö

# Vakio ympäristömuuttujat ja kestää STDIN ja

# Dumpata sen takaisin ulos STDOUT.

# Nämä ovat standardin ympäristömuuttujat. Voit määritellä

# Enemmän palveluksessasi config tiedosto (ks. edellä).

echo "Ajanjakso: $ LOGWATCH_DATE_RANGE"

echo "Detail Level: $ LOGWATCH_DETAIL_LEVEL"

echo "Temp Dir: $ LOGWATCH_TEMP_DIR"

echo "Debug Level: $ LOGWATCH_DEBUG"

# Nyt ottaa STDIN ja dumpata se STDOUT

kissa

Nyt Luo Toisella koodilla:

VI ossec-hälytys

ja sisältää täsmälleen sama sisältö:

#! / Bin / bash

# Tämä on niin mukavaa skripti, joka näyttää sinulle linjat tulet

# Voidaan käsittely ja raportointi. Se ensimmäinen näyttö

# Vakio ympäristömuuttujat ja kestää STDIN ja

# Dumpata sen takaisin ulos STDOUT.

# Nämä ovat standardin ympäristömuuttujat. Voit määritellä

# Enemmän palveluksessasi config tiedosto (ks. edellä).

echo "Ajanjakso: $ LOGWATCH_DATE_RANGE"

echo "Detail Level: $ LOGWATCH_DETAIL_LEVEL"

echo "Temp Dir: $ LOGWATCH_TEMP_DIR"

echo "Debug Level: $ LOGWATCH_DEBUG"

# Nyt ottaa STDIN ja dumpata se STDOUT

kissa

Lopuksi meidän on asetettava tarvittavat oikeudet:

chmod 755 ossec *

Testaus Setup

Helpoin tapa testata uuden asennuksen on ajaa komento:

logwatch | less

Jos haluat vain nähdä muutokset, voit suorittaa raportin kunkin palvelun, yksi kerrallaan:

logwatch-palvelu ossec | less

logwatch-palvelun ossec-hälytys | less

Muokata edelleen

Kun saat kaikki edellä toimii, voit keskittyä saamaan Logwatch suodattaa ja tiivistää lokitiedot. Logwatch on melko joustava, ja voit muokata lähtö haluamallasi tavalla. Yksi mukavia asioita edellä testikoodi yläpuolella on, että se näyttää sinulle täsmälleen, mitä sinun täytyy työskennellä. Joten hieman säännöllinen lauseke magic voit tehdä yhteenvetoja merkinnät kun pitävät asianmukaisina. Joillekin ideoita, tutustu tiedostojen alla:

/ Usr / share / logwatch / scripts / palvelut

Nämä ovat oletuksena yhteenveto skriptejä mukana Logwatch. Erityisesti on tarkasteltava tiedostot "pam" ja "sshd". Ne ovat erinomaisia ​​esimerkkejä sekä yksinkertaisia ​​ja monimutkaisia ​​yhteenveto suodattimia.

Kun kehität skriptejä, kiinnitä huomiota $ LOGWATCH_DETAIL_LEVEL "muuttuja. Tämän ansiosta voit muokata lähtötasoa raportin riippuen siitä kuinka paljon näyttötaso käyttäjä etsii. Esimerkiksi kun olet vielä edellä palveluiden hakemistoon, suorita seuraava komento:

vähemmän sshd

Kun ensimmäisen sivun tiedoston sisältö näytetään, kirjoita:

/ Detail <Anna Key>

Kenoviiva auttaa meitä etsiä tiedoston tietyn merkkijonon. Tässä tapauksessa Etsimme sana "Detail". Kun painat Enter haku hyppää läpi tiedosto kunnes se löytää ensimmäisen oikeusasteen merkkijono. Siinä korostuvat myös hakumerkkijonon. Ensimmäisessä ottelussa huomaat, että kirjailija määritetty muuttujaan "$ Detail" olla sama kuin muuttuja $ LOGWATCH_DETAIL_LEVEL ". Näin pyritään säästämään heille joitakin kirjoittamalla.

Paina nyt kenoviiva näppäintä uudelleen sen jälkeen Enter-näppäintä. Tämä hyppää läpi tiedosto seuraavaan esiintymään "Detail". Sinun pitäisi nähdä:

if ($ tietoja> = 20) {

$ Käyttäjät {$ user} {$ host} {$ Method} + +;

} Else {

if ($ isäntä! ~ / $ IgnoreHost /) {

$ Käyttäjät {$ user} {$ host} {"(kaikki )"}++;

Huom kirjailija saa lisää tietoa, jos yksityiskohtien määrä on asetettu 20 (välissä pieni ja keskisuuri) tai korkeampi. Pidä hyppäämällä läpi tiedoston ja näet muita esimerkkejä, joissa kirjailija velkarahalla tätä tekniikkaa.

Nyt sivu alas tiedoston loppuun ja sinun pitäisi nähdä tämä lausunto:

if (avaimet% OtherList) {

print "\ n ** Ylivertainen Entries ** \ n";

print "$ _: $ OtherList {$ _} Aika (s) \ n" foreach avaimet% OtherList;

}

Tämä osio on erittäin tärkeä, koska se on lopullinen Haavi. Ajattele palomuurin politiikan hetkeksi. Useimmat meistä luoda lopullinen sääntö, joka sanoo, "Jos en ole erikseen salli laskukierroksessa läpi, kieltää". Toisin sanoen, jos jotain yllättävää tapahtuu, näin minä haluan teidän käsitellä sitä.

Lausumassa palvelee samaa tarkoitusta jäsennettäessä lokitiedostoon. Kaikki aiemmat "jos" lausunnot yrittää sovittaa tietyn tekstin merkkijono lokimerkintä jotta alustaa sen kunnolla. Tämä artikkeli sanoo "Jos et ole sovitettu ja painettu erityinen lokitapahtuman vielä, tulosta se on osio" ** Ylivertainen Entries ** ". Tämä vaihe on erittäin tärkeä, koska ilman sitä emme koskaan näe odottamattomia merkinnät. Se on odottamaton merkinnät, jotka luultavasti tärkein ja kiinnostavin.

Exec Yhteenveto

Sekä OSSEC ja Logwatch ovat erinomaisia ​​ilmaisia ​​työkaluja. OSSEC kunnostautuu varoittaa, kun tunnettu hyökkäys kuvio tapahtuu. Logwatch on loistava työkalu yhteenvedon aika kimpale lokit jotta ihmiset voivat todella saada tolkkua, mitä tapahtuu. Yhdistämällä kaksi työkalua voit luoda paljon vakaampi puolustus syvällistä asennon. Koko tulee enemmän kuin osiensa summa.

Yhdistämällä Logwatch ja OSSEC - Osa 3

17 helmikuu 2010

Minun kaksi viimeistä viestiä Keskustelin Logwatch ja OSSEC sekä miten niitä voidaan hyödyntää laajentaa tietoturvaa ryhti. Tässä erä tulen keskustelemaan siitä, miten asentaa molemmat näistä työkaluista.

Asentaminen Logwatch

Logwatch on melko helppo asentaa. Itse asiassa se on asennettuna monien Linux-jakeluiden niin saatat jo kopioi järjestelmään. Voit tarkistaa, kirjautuminen pääkäyttäjänä ja yritä ajaa Logwatch kanssa "-v"-kytkin. Jos näet:

[Root @ Fubar logwatch] # logwatch-v

Logwatch 7.3.6 (julkaistu 19.5.07)

Logwatch on asennettu ja olet kopio uusimman version. Jos sinulla ei ole uusinta versiota, voit napata sen Logwatch lataussivulta .

On olemassa kolme makuja Logwatch jonka voi ladata, binäärejä, rpm-muodossa, lähde RPM-muodossa, tai lähde Tar pallo. Jos järjestelmä tukee RPM pakettien hallinnan, binary RPM on paras valinta. Se on yksinkertainen asentaa ja RPM automaattisesti päivittää ohjelmistoa, kun uudet versiot ovat saatavilla.

Asentaminen Logwatch alkaen RPM

Voit asentaa binary version RPM, yksinkertaisesti kirjautua pääkäyttäjänä ja siirry hakemistoon, johon latasit RPM-tiedoston. Nyt suorittaa komennon:

rpm-U logwatch-7.3.6-1.noarch.rpm

Älä unohda voit SARKAIMELLA automaattinen täydennys tiedoston nimi eikä tarvitse kirjoittaa koko jutun.

Asentaminen Logwatch From Source

Asennus lähde on vähän enemmän aikaa. Muista, että voidakseen asentaa lähdekoodin sinulla on jo kääntäjä (kuten GCC) asennettuna järjestelmään. Logon pääkäyttäjänä ja siirry hakemistoon, johon latasit Tar pallo. Voit purkaa arkiston, suorita komento:

terva xvzf logwatch-7.3.6.tar.gz

Näet hakemistorakenteen alle nykyisen sijainnin saada luotu ja paljon tiedostoja kopioidaan tuumaa Meillä on nyt siirtyä alkuun kaikkein hakemistoon luotu:

cd logwatch-7.3.6

Jotta Logwatch juosta, on olemassa joukko hakemistoja, jotka on luotu järjestelmä. Nämä on dokumentoitu README nykyiseen hakemistoon. Onneksi Logwatch sisältää asentaa skripti, joka voi tehdä kaiken työn puolestasi. Valitettavasti käsikirjoitus on väärä oikeudet asettaa niin se ei toimisi oletuksena. Tämä on melko helppo korjata kuitenkin kanssa chmod-komennolla:

chmod 500 install_logwatch.sh

Nyt voimme suorittaa komentosarjan setup järjestelmämme:

. / Install_logwatch.sh

Älä unohda kauden alussa linja.

Testaus Logwatch

Testaa Logwatch setup, suorita komento:

logwatch | less

Näet päätelaitteen näyttö pimeni, mutta se on normaalia. Tulet lopulta nähdä Logwatch raportin saada tulostuu näyttö, voit selata käyttämällä "Sivu ylös" ja "Page Down" näppäimiä. Miten loki kuluu raportin näy ruudulla riippuu siitä, kuinka paljon lokitietoja pitää saada jäsennetään. Se voi kestää muutaman sekunnin tai pari minuuttia. Joko niin, se antaa sinulle mahdollisuuden tutustua raportin muodossa.

Asentaminen OSSEC

Kuten mainitsin viime post, sinulla on kaksi asennusvaihtoehtoja kanssa OSSEC, paikallisten tai client / server. Tässä post aion keskittyä client / server setup, koska se on vähän monimutkaisempi. Jos olet suorittamassa paikallisen asentaa, valitse vain "paikallinen" vaihtoehto aikana asennuksesta ja ohittaa osio perustaa suojatun kanavan välillä agentti ja palvelin.

Aloita Server

OSSEC käyttää Blowfish salausta turvallisen viestinnän asiakkaan ja palvelimen. Blowfish on symmetrinen avain pohjainen, joten molempien osapuolten on tiedettävä, mitä avain arvo, jota käytetään, jotta kommunikoida. Palvelin vastaa tuottaa symmetrinen avain, joten meidän on asennettava palvelinohjelmisto ensin. Aikana asiakas asentaa me kysytään keskeinen arvo niin ilmeisesti meidän pitää olla, että kätevä etuajassa.

Tässä aikaa säästävä kärki. Tärkein arvo on pitkä ja lähes mahdoton muistaa. Helpoin tapa siirtää keskeinen arvo palvelimelta järjestelmän agentti järjestelmää on käyttää SSH. Luo turvallinen yhteys OSSEC palvelimelle, ja ote sopiva avain (Ajo alla). Toisessa pääteikkunaa luoda ssh-istunto järjestelmä, jossa sinua asennuksen agentti. Kun asiakas asentaa kysyy keskeinen arvo, voit yksinkertaisesti kopioi / liitä välillä kaksi terminaalia.

Asentaminen OSSEC Server

Palvelinohjelmisto on saatavilla Terva pallo, joten voit napata kopio uusin versio OSSEC lataussivulta . Tällöin sinun täytyy purkaa sisällön Tar pallo:

terva xvzf ossec-HIDS-2.3.tar.gz

Seuraavaksi siirrymme hakemiston rakenne juuri luomaasi:

cd ossec-HIDS-2.3

OSSEC tarjoaa asentaa script opastaa prosessin asentamista palvelimelle. Aloita käsikirjoitus, tyyppi:

. / Install.sh

Älä unohda kauden alussa komennon. Olet nyt kysytään monin asennusvaihtoehdot

  • Kieli - Oletuksena on Englanti. Vaihda tarvittaessa.
  • Vahvistus asennus - Paina Enter kun olet lukenut näytöllä.
  • Asennustapa - Kirjoita "palvelin" ilman lainausmerkkejä ja paina Enter.
  • Asennuspaikka - Hyväksy oletusnimi.
  • Sähköposti-ilmoitus - Oletus on kyllä, valitse Jos haluat ilmoituksia sähköpostitse. Jos valitset Kyllä, sinulta kysytään kelvollinen sähköpostiosoite ja sähköpostipalvelin.
  • Integrity Check - Oletus on kyllä. Valitse, haluatko paikallisen järjestelmän säännöllisesti tarkastetaan tunkeutumista.
  • Root kit tunnistus - Oletus on kyllä. Hyvä vaihtoehto, sillä meidän täytyy ylläpitää korkeaa eheys tässä järjestelmässä.
  • Active Response - Oletus on kyllä. Valitse tämä vaihtoehto, jos haluat pystyä reagoimaan tapahtumiin.
  • Palomuuri pudota - Luvat OSSEC palvelin puolustamaan sitä itse, jos suora hyökkäys todetaan.
  • Valkoinen lista - Tämän ansiosta voit lisätä IP-osoitteet, joista mahdolliset hyökkäykset ohitetaan. Ole varovainen tämän vaihtoehdon. Jos et ole Konsolin käytön OSSEC palvelimelle, saattaisi olla järkevää tunnistaa yhden IP-osoitteen, joka voi aina päästä sisään vain varmistaa lähde IP on luotettava järjestelmä.
  • Ota Syslog - Oletus on kyllä. Valitse tämä vaihtoehto, jos haluat kerätä lokeja järjestelmä ei pysty ajamaan OSSEC agentin (kuten palomuurit, kytkimet, reitittimet, tukiasemat, jne.).
  • Lokitiedostoja seurata - Tämä näyttö tunnistaa kaikki paikalliset lokitiedostot OSSEC seuraa. Se on puhtaasti tietoa, joten kaikki mitä voi tehdä on painaa Enter siirtää sen ohi. Jos huomaat yhden tai useamman lokitiedostot ole luettelossa, voit lisätä ne myöhemmin ossec.conf tiedostoon.

Tässä vaiheessa OSSEC pääsevät paikallisen kääntäjä ja asentaa kaikki tarvittavat tiedostot siirretään järjestelmään. Kun olet valmis, voit aloittaa OSSEC palvelimen suorittamalla komento:

/ Var / ossec / bin / ossec-ohjaus alkaa

Määrittely OSSEC Agents

Emme ole tehneet OSSEC palvelimen ihan vielä. Seuraavaksi meidän on ennalta määritellä mitään järjestelmiä, jotka ovat käynnissä OSSEC agentti (client) ohjelmisto. Tämä tehdään käyttäen manage_agents komentoa. Ensin meidän on kuitenkin tehdä hieman kotitehtäviä. Tee luettelo kaikista järjestelmien on käynnissä OSSEC Agent-ohjelma. Kunkin järjestelmän, tarvitset kuvaava nimi sekä tämän järjestelmän IP-osoite.

Nyt, suorita seuraava komentoriviltä:

/ Var / ossec / bin / manage_agents

Tämä tuottaa Agent Manager päävalikosta. Paina "" ja sen jälkeen Enter-näppäintä määritellä ensimmäinen järjestelmä. Anna kuvaava nimi ensimmäinen järjestelmä, jota seuraa järjestelmän IP-osoite. Älä ole huolissasi agentti tunnus. Yksinkertaisesti hyväksy oletusnimi ja OSSEC tulee automaattisesti määrittää seuraavan käytettävissä tunnus. Kun vahvistat syöttämäsi tiedot, sinut palautetaan Agent Manager päävalikosta. Toista edellä kuvattu prosessi kunkin järjestelmän, joka on käynnissä OSSEC agentti.

Generating Keys

Kun olet lisännyt kaikki teidän järjestelmissä, on aika tuottaa salausavaimia. Tämä vaihe on myös esiintynyt manage_agents apuohjelma. Jos suljetun työkalun jälkeen viimeinen vaihe, uudelleen se nyt.

Paina "E"-näppäintä ja sen jälkeen Enter Valitse "Poimi avain agentti"-valikko. Voit sitten kysytään ID-numero avain haluat poimia. Kuvaavia nimiä ja IP-osoitteet on lueteltu jokaisen tunnus, niin se olisi triviaalia tunnistaa, mitä haluat. Aloita järjestelmän aiot asentaa agentin ohjelmiston päälle ensin.

OSSEC Agent asentaa Linux

Asennettaessa agentin ohjelmiston Linux-tai UNIX asiakas, käytät täsmälleen sama Tar pallo käytimme asennettava palvelinohjelmisto. Suorita sama asentaa skripti, mutta tällä kertaa, kun sinulta kysytään tyyppi asentaa haluat suorittaa, kirjoita "agentti" jälkeen Enter-näppäintä.

Asiakas asentaa on monia samoja ohjeita kuin palvelimen asennus. Käytä info edellä opastaa sinut prosessin läpi. Kehotetta vaihtelevat kuitenkin on, että sinua pyydetään antamaan IP-osoite OSSEC palvelin. Kun olet valmis, OSSEC pääsevät paikallisen kääntäjä ja asentaa kaikki tarvittavat tiedostot siirretään järjestelmään.

Seuraavaksi meidän täytyy tuoda Blowfish avain OSSEC palvelimelle. Vaikka edelleen agentti järjestelmään, suorita komento:

/ Var / ossec / bin / manage_agents

Kun Agent Manager valikko avautuu, valitse "I" tuoda Blowfish avain.

Kun seuraava kehote tulee näkyviin, sinun täytyy manuaalisesti sopiva Blowfish avain. Jälleen, jos käytät SSH sekä järjestelmiin samanaikaisesti, voit yksinkertaisesti kopioi / liitä välillä kaksi terminaalia. Varmista avain näyttää oikein, paina Enter-näppäintä ja valitse "y" vahvistaa, että avain näyttävät oikeilta. Sinut palautetaan Agent Manager-valikkoa. Valitse "q", jotta palaa komentoriville.

Nyt täytyy vain aloittaa OSSEC agentti. Voit tehdä sen suorittamalla seuraava komento:

/ Var / ossec / bin / ossec-ohjaus alkaa

Sinun pitäisi nähdä kaikki OSSEC agentin komponentit alkavat, jota seuraa "Completed" viesti.

OSSEC Agent asentaa Windows

OSSEC on itsesuorittuva suoritettava joka sallii sinun asentaa agentin ohjelmiston Windows-järjestelmässä. Yksinkertaisesti kaksoisnapsauttamalla suoritettavaa aloittaa asennuksesta. Sinua pyydetään hyväksymään lisenssin sekä mitkä komponentit, jotka haluat asentaa. Seuraa vain ohjeita asti OSSEC Agent Manager-ikkuna avautuu.

OSSEC Agent Manager-ikkuna kysyy sinulta IP-osoite OSSEC palvelimelle. Se myös kysyy Blowfish keskeinen arvo käyttämään, niin ote sopiva avain palvelimelle ja anna arvo tällä alalla. Varmista, että poistat nopeasti tämän kentän ennen liitä Blowfish-näppäintä. Muuten tietoliikenne palvelimen kanssa voi epäonnistua.

Seuraavaksi valitse "Hallitse" From OSSEC Agent Manager-valikkoa ja sen jälkeen "Start OSSEC". Sinun pitäisi nyt nähdä "Tila:" ilmaisin muuttuu "Running ...".

Testaus OSSEC

Kun olet palvelin ja agentti asennettuna, alkoi ja sopiva avaimet määritetty, nyt on aika tarkistaa meidän setup. Suorita seuraava komento OSSEC palvelimessa:

cd / var / ossec / lokit

Ja tutustu ossec.log tiedosto:

vähemmän ossec.log

Tarkista lokitiedosto mahdollisista virheistä. Yleinen virhe on, että OSSEC raportteja se ei voi lähettää sähköpostia. Varmista postipalvelin on käynnissä ja että se on vastaanottamasta yhteyksiä. Kun olet tyytyväinen palvelimen asennuksen, nyt on aika tarkistaa tekijöille. Siirrä alas "hälytyksiä" hakemistoon:

cd hälytykset

Ja tutustu alerts.log tiedosto:

vähemmän alerts.log

Erityisesti etsit merkintöjä seuraavan kaltainen:

2010 17 helmikuu 16:09:16 (desktop) 192.168.1.10-> ossec

Sääntö: 501 (taso 3) -> 'Uusi ossec agentti kytketty. "

Src IP: (ei mitään)

Käyttäjä: (ei mitään)

ossec: Agent alkoi: "test_system-> 192.168.1.10".

Sinun pitäisi nähdä merkinnän jokaiseen järjestelmään, johon asensit Agent-ohjelma.

Lisää on tulossa

Vau! Se on enemmän kuin tarpeeksi yhdelle artikkeli! Minun Seuraava viesti Saan osaksi hyödyntämällä Logwatch jäsentää kaikki ilmoituksilla on tuottaman OSSEC.

Yhdistämällä Logwatch ja OSSEC - Osa 2

16 helmikuu 2010

Minun viimeinen viesti Olen esitellyt Logwatch voitaisiin käyttää yksinkertaistaa log arviointiprosessissa. Tässä postitse me tarkastelemme OSSEC ja mitä se tuo pöytään.

Mikä on OSSEC?

OSSEC , lyhenne sanoista "Open Source Security", on isäntä perustuu Intrusion Detection System (HIDS). Toisin sanoen, se on suunniteltu havaitsemaan hyökkäyksiä tai sääntörikkomusten jos ja kun niitä ilmenee. Vaikka sillä ei ole kykyä estääkseen tuntemattomia tai 0-Day hyökkäykset (se olisi isäntä tietomurtojen ehkäisyyn), se sisältää laajan valikoiman työkaluja, jotka auttavat tunnistamaan tunkeutumisen, kun se tapahtuu, sekä missä määrin vahingosta, joka on aiheuttanut.

Tuetut alustat

Voit hyödyntää kaikki ominaisuudet OSSEC on tarjota, sinun täytyy ajaa agentin järjestelmässä suojattu. OSSEC aineet voivat ajaa Windows-, Mac OS X, Linux, ja laaja UNIX-järjestelmissä. Jos olet vain kiinnostunut lokitiedostoanalyyseistä osa kuitenkin yhä useampia järjestelmiä voidaan tukea. Tämä sisältää laitteet sekä Cisco ja Juniper. Joitakin erityisiä tuotteita ovat myös tuettuja, kuten Checkpoint palomuurien, Symantec Anti-Virus, Snort, Squid, ja Arpwatch, vain muutamia mainitakseni.

Kun asennat OSSEC sinulla on kaksi asetuksia, paikallisen tai client / server. Paikallinen asentaa käytetään, kun haluat suorittaa kaiken yhteen järjestelmään. Client / server asennuksen avulla voit käyttää hajautetussa ympäristössä suojata useita järjestelmiä samanaikaisesti. Vaikka useimmat käyttöönotot ovat client / server perustuu, jos haluat antaa OSSEC spin voit helposti käyttää kaiken yhden testin, joka käyttää paikallista asentaa.

Log Analysis

OSSEC sisältää Log-pohjainen Intrusion Detection System (kannet). Tämä on kyky tarkastella lokitiedostoa lähes reaaliajassa, kun taas tarkastelua niitä tunnetaan hyökkäyskuviot. Kun loki on luotu on suojattu järjestelmä, agentti hoitaa turvallisesti välittää log (Blowfish-salaus ennalta jaettua salaista) takaisin palvelimelle. Palvelin huolehtii analyysilaboratorioiden.

Useimmat log analyysityökalut prosessi säännöksensä lineaarinen muodossa. Tarkoitan tällä sitä, jos meillä on 500 sääntöjä, sääntö yksi on valittu, niin yleensä kaksi, sitten sääntö kolme ja niin edelleen kunnes ottelu on löydetty tai pääsemme loppuun sääntöä. OSSEC toimii vähän eri tavalla kuin se toteuttaa hieratical rakenne sääntöjä. Lokitietoihin ensin luokitellaan ja tarkastetaan vain vastaan ​​kumpi säännöt ovat asianmukaisia. Tuloksena on, että sen sijaan tarvitse käsitellä kaikkia 500 sääntöjä, useimmat tapahtumat saavat verrataan 10 sääntöä tai vähemmän. Tämä dramaattisesti vähentää yleiskustannusten käsittelyssä tarvittavat sääntöä.

Integrity tarkistaminen

OSSEC sisältää työkalun nimeltään Syscheck suorittamaan tiedostojen ja hakemistojen eheyden tarkistamiseen. Jos käytät Windows agentti, voit myös erityisiä avaimet sisällä Windowsin rekisterin seurattava samoin. Tiedoston muutokset voidaan havaita sekä MD-5 ja SHA-1 algoritmeja. Järjestelmä on erittäin muokattavissa. Voit lisätä tai jättää pois yksittäisiä tiedostoja tai koko hakemistosta rakenteita. Voit jopa asettaa lippu tunnistaa uudet tiedostojen luominen.

Agent-ohjelma on suunniteltu käyttämään mahdollisimman vähän CPU aikana eheystarkistus. Vaikka tämä merkitsee Tarkista kestää kauemmin, se myös auttaa minimoimaan suorituskyky osuma järjestelmään. Hash tiedot lähetetään takaisin palvelimeen. Palvelin huolehtii Esittävän hash verrattuna nähdä, jos jokin järjestelmän kriittiset tiedostot on muuttunut. Palvelin myös tallentaa kopion eheystarkistus politiikkaa, niin että jos politiikan muutokset tehdään agentti, ne voidaan havaita ja raportoidaan samoin.

Poikkeamien ilmaisuun

OSSEC paljon muutakin kuin lokin tarkistus tarkistaa järjestelmän eheys. Käyttö politiikkaa voidaan hallita keskitetysti palvelimelle, ja sitten ulos sopivaan tekijöille. Esimerkiksi voit määrittää koskeva politiikka, joka Windows-sovelluksia voidaan käyttää (Office, Firefox, tms.) ja mitkä eivät (pikaviestiohjelma, Skype, jne.). Voit jopa määritellä hyväksyttävä asetuksia, kuten todentaa että NT hash käytetään salasanaa säilytetään mutta ei LanMan hajautustauluilta.

OSSEC sisältää useita muita herkkuja auttaakseen tarkistaa järjestelmän eheyden. Esimerkiksi OSSEC on kyky suorittaa komentoja agentista ja monitori ulostulo että saa syntyy. Esimerkiksi voit olla Linux agentti suorittaa "DF" komento säännöllisin väliajoin ja tuottaa hälytyksen, jos levyn käyttö ylittää 90%. Windows esimerkki voidaan saada OSSEC tuottaa hälytyksen kun kuvan tiedot kirjoitetaan varajäsen tietovirrat alue NTFS.

Active Response

Lopuksi OSSEC kuuluu kyky reagoida kun epäilyttävää toimintaa havaitaan. Vastaukset voidaan luoda palvelimelle tai agentti, joka koskaan voit määrittää. Vastaukset voi olla hyvänlaatuinen tuottavan sähköposti-ilmoituksen, olemaan niin aktiivinen kuin estää kauko IP-osoite rajallinen määrä aikaa. On olemassa useita mukana aktiivisia toimia skriptejä Voit piirtää, tai voit helposti kirjoittaa oman.

Secure Arkkitehtuuri

OSSEC kirjoittajat ovat menneet hyvin pitkälle varmistaa kaikki komponentit tuote. Tehtäviä, kuten rehellisyys tarkistus suoritetaan palvelimella, eikä agentti, joten luotettavuutta hash ei voi vaarantaa aikana hyökkäys. Prosessit ajetaan alhaisinta käyttöoikeuksia mahdollista, ja eri tilejä käytetään juosta jokaisen OSSEC komponentti. Tämä tarkoittaa, että kompromissi on ainoa hakemus sisällä OSSEC ei heti johda kompromissia koko paketin. Lisäksi useimmat suoritettavat osat sisällä chrooted vankilaan niin niiden pääsyä järjestelmään on vielä enemmän rajoituksia.

Loppusanat

Vaikka OSSEC on tehokas työkalu, on tärkeää muistaa, että se on HIDS eikä log hallintaratkaisun. OSSEC voi tarkistaa lokitiedot etsien epäilyttäviä kuvioita, mutta se vain pelastaa ilmoituksilla. Joten vaikka OSSEC ei korvaa Security Information Management (SIM) ratkaisu, se voi varmasti lisätä sitä. Voit määrittää helposti OSSEC sen eteenpäin kaikki hälytykset se tuottaa on keskeinen kirjautumalla palvelimelle .

Vaikka OSSEC on avoimen lähdekoodin ohjelmisto, Trend Micro on ensisijaisesti kehittää sitä. Jos tarvitset kaupallisen tuen, voit ostaa tukisopimusta läpi niitä kohtuullinen maksu.

Lisää on tulossa

Minun seuraavan erän tutustumme asentamista OSSEC ja Logwatch. Sen jälkeen me siirrymme yhdistämällä kaksi yhdessä.

Yhdistämällä Logwatch ja OSSEC

15 helmikuu 2010

Olen viime aikoina ollut opiskelija kysy minulta kysyttävää integrointi Logwatch kanssa OSSEC. Tunsin tämä oli monimutkainen ja vielä tarpeeksi viileä idea, jota asia edellytti useita virkoja peitellä sitä kokonaan. Joten tulevina päivinä minä puhua kaikkien näiden työkalujen, kuinka yhdistää ne yhteen, samoin kuin mitä lisäturvaa näkyvyyden voidaan saada, kun prosessi on valmis.

Mikä on Logwatch?

Logwatch on erinomainen avoimen lähdekoodin työkalu tuottaa päivittäin luettava log raportit. Lokitiedot yleensä jakaa kolmeen luokkaan:

  • Stuff tiedät on paha
  • Stuff tiedät on normaalia ja voi turvallisesti jättää
  • Kaikki muu

On, että "kaikki muu" luokka, jossa Logwatch todella loistaa. Sillä tavaraa tiedämme on paha, me setup jonkinlaista varoitusjärjestelmään. Esimerkiksi voimme kirjoittaa varoittaa allekirjoitus, joka varoittaa turvallisuus analyytikko, kun tilisi on raa'alla pakko. Mutta entä hyökkäyksiä emme tiedä tai ole varma, mitä ne näyttävät? Tämä olisi selkeä esimerkki, että "kaikki muu" luokka. Liikenne ei ole normaalia, mutta emme ole nähneet sitä ennen saada allekirjoitusta odottamassa tuottaa hälytyksen. Koska emme voi ottaa kiinni hyökkäystä reaaliajassa, meidän on kiinni sen aikana päivittäin kirjaa uudelleen.

Tietenkin ongelma tekee päivittäin kirjaa katsauksissa on, että se on työläs ja aikaa vievä. Siis olkaamme rehellisiä, kuka todella haluaa viettää päivänsä tarkistamalla miljoona plus lokitiedot? Vaikka et, oletko varma todella kiinni tavallisesta liikennettä?

Miten se toimii

Mitä Logwatch tekee hyvin on anna sinun uudelleen tietosi muotoon, on helpompi ihmisille seurata. Sen todellinen vahvuus on, että se sallii sinun siirtyä tavaraa ymmärrät pois tieltä (normaali tai pahaa), jotta odottamaton lokitiedot erottua kuin kipeä peukalo. Toisin sanoen Logwatch voit Tiivistä lokitiedot niin epätavallinen tavaraa on helpompi havaita.

Mitä minä todella rakastan Logwatch on, että et menetä mitään. Monet kirjautua uudelleen työkalut näkyy vain sinulle kamaa, että on ennalta määritelty niin, että pahan. Ongelma niille kaikille on, että kun jotain pahaa, mutta odottamatonta tapahtuu, se lentää mukaista oikeutta lanka. Koska Logwatch näet kaiken, et enää menetä odottamatonta.

Logwatch In Action

Lets keskustella siitä, miten Logwatch teokset SSH Server-palvelu esimerkkinä. Skriptejä käsitellä SSH on jo määritelty Logwatch, joten sinun ei tarvitse tehdä mitään säätämistä saada ominaisuuksia aiomme keskustella.

Kun tarkastellaan lokitiedoston, ensimmäinen asia Logwatch ei on uudelleen lokitiedot perustuu niiden viestityypit. Esimerkiksi kaikki onnistuneet SSH kirjautumiset ryhmitellään sekä liian monta kirjautuminen epäonnistumisia, kieltäytyi yhteydet, lukittu tilit, tilinpäätös ilman asianmukaista kuori, protokolla MIS-otteluita, jne. jne. jne. Kun kaikki SSH viestit ryhmitellään niiden tyyppi, tiedot on sitten yhteenveto vähentää tiedon määrää on raportoitu.

Esimerkiksi oletus on tiivistää epäonnistunut kirjautuminen yrityksistä huomioon ja lähde IP. Joten tyypillinen epäonnistunut kirjautuminen raportin kohta voi näyttää tältä:

Epäonnistuneet kirjautumiset näistä:

bsmith / salasana 1.2.3.4: 637 kertaa (s)

jsmith / salasana 1.2.3.5: 2 kertaa (s)

Joten mieluummin kuin ottaa uudelleen 639 lokimerkinnät raportointi huono kirjautuminen yritys, olemme kaikki olennaiset tiedot tiivistää kolmeen riviä (jos kuuluu otsikko). Jatka tätä prosessia kaikkien muiden SSH viestejä, ja meillä on vähentänyt dramaattisesti tarvittava aika tarkistaa Lokeistamme.

Mutta mitä jos jotain tapahtuu, että Logwatch ei ole valmiiksi ohjelmoitu tunnistamaan? Kun odottamaton lokimerkintä löytyy, Logwatch lisää osiossa loppuun palvelun raportin "Vertaansa vailla olevat maininnat". Joten jos näemme tämän osaston SSH Server-osiossa, tiedämme jonkin tapahtuman, joka on joko epänormaali tai odottamattomia varten SSH-palvelu. Tämä voisi hyvin olla jonkinlainen hyökkäys, että emme ole tietoisia tekee kierroksilla.

Keskittymällä vuonna on vertaansa vailla merkinnät, voimme nopeasti tunnistaa odottamatonta toimintaa. Kuten aiemmin totesin, tämä on oikeastaan ​​tärkein tavoite tehdä päivittäin kirjaa arvion. Voit etsiä juttuja emme odota joka livahtaa ohitse varoitusjärjestelmään. Logwatch tekee tämän prosessin nopeasti ja mahdollisimman vaivattoman.

Ominaisuus Yhteenveto

Yllä olevassa esimerkissä puhuin tekee päivittäin kirjaa arvosteluja, mutta ollakseni rehellinen Logwatch on hyvin muokattavissa. Voit määrittää minkä tahansa alue, jota haluat käyttää alas kulunut sekunti. Esimerkiksi Sanotaan olen tutkii tunkeutumista sijaan suorittamalla päivittäin kirjaa uudelleen. Voisin määrittää alueen, kuten "14.2.2010 17:05:00 tätä hetkeä" keskittyä aivan tiedoista, jotka kiinnostavat minua. Voin myös keskittyä yhteen tiettyyn lokitiedosto tai palvelua.

Yksityiskohtien määrä raportti on myös muokattavissa. Yleensä kun tapahtuu turvallisesti saat tapana aina halunnut eniten yksityiskohtia raportointia. Ollakseni rehellinen, jossa Logwatch korkea yksityiskohta on luultavasti enemmän kuin sinun koskaan tarvitse. Itse olen yleensä kiinni "med" keskipitkän ja joka toimii oikein mukavasti. Voit myös määrittää raportoinnin tasoa kuin "vähäinen" tai "korkea" tai käyttää numeerista valikoima 0-10 korkeammalle tasolle rakeisuuden (low = 0, med = 5, korkea = 10).

Logwatch voidaan suorittaa automaattisesti tai manuaalisesti. Yleensä sinun kannattaa asettaa se suoritettavaksi automaattisesti joka päivä ja tiivistää yhden päivän edestä lokitiedot. Jos joudut laajentaa tai keskittyä raportin, voit aina ajaa Logwatch komentoriviltä ja määriteltiin, mitä haluat nähdä. Voit sitten käyttää "-save"-vaihtoehto määrittää raportin nimi ja hakemiston sijainti varastointiin.

Lisää on tulossa

Edellä pitäisi antaa sinulle hyvä idea, että ominaisuuksia Logwatch voi tuoda pöytään. Vuonna Seuraava viesti Tulen keskustelemaan OSSEC samalla tarkkuudella. Sen jälkeen menen miten asentaa kukin työvälineen sekä kuinka yhdistää ne yhteen.

Perustamalla Security Information Management System-osa 6

20 elokuu 2009

Toistaiseksi tässä sarjassa olemme käsitelleet:

  • Määrittely laajuus ja painopiste SIM
  • Tärkeää rakentaa sen sijaan ostaa ensimmäinen järjestelmä
  • Arkkitehtuuri ja kapasiteetin suunnittelu
  • Suositeltava vaiheiden käyttöönotto
  • Valinta keskitetyn kirjautumalla palvelinympäristöön
  • Miten hyväksyä kauko lokimerkinnät
  • Facility, vakavuus ja prioriteetti
  • Miten lajitella lokien
  • Konfigurointi laitteita ja käyttöjärjestelmiä toimittamaan lokimerkinnät

Cool. Joten olemme lokitiedot useita järjestelmiä kerätään keskitetysti palvelimelle. Nyt tulee tärkein tehtävä, joka hyödyntää tätä tietoa. Lokimerkintöjä on jaettu kahteen ryhmään; kriittiset viestit haluamme tietää heti, ja lokitiedot, joka jää kiinni osana säännöllistä tarkastelua.

Kieltolistalle Vs. Sallittujen osoitteiden luettelosta

Kun tarkastellaan lokiviestit, meillä on kaksi mahdollista asennot voimme käyttää. Ensimmäinen kutsutaan sulkemiseen. Kun mustien listojen menetelmä me määrittelemme mitä tekee tapahtumasta mielenkiintoisen riitä perusteeksi raportointiin. Tämä on samanlainen kuin miten virustorjuntaohjelma havaitsee haittaohjelmia tai prosessi käytämme roskapostin suodatuksen.

Kuten useimmat asiat elämässä, mustia listoja on hyviä ja huonoja puolia. Hyvänä puolena, se on yleensä melko helppo kirjoittaa allekirjoitus, jos tiedämme, mitä haluamme etsiä. Allekirjoitukset voidaan rajata tarkasti auttaa minimoimaan määrä vääriä positiivisia törmäämme. Ongelma mustalle listalle on se, että meidän on tiedettävä, mitä etsimme. Jos uusi hyökkäys luo ainutlaatuinen allekirjoitus olemme koskaan kohdanneet aikaisemmin, mustien listojen järjestelmä todennäköisesti kaipaamaan tapahtuma, koska ei allekirjoitusta ole määritelty.

Kun sallittujen osoitteiden luettelosta me määrittelemme tapahtumia ymmärrämme, ja sitten keskittää huomiomme uusi ja ainutlaatuinen lokisanomia että kohdataan. Hyvänä puolena olemme paljon todennäköisemmin kiinni kärjessä hyökkäyksiä. Sallittujen osoitteiden luettelosta yleensä melko meluisa mutta koska olemme varmasti kohdata ainutlaatuinen lokiviestit, jotka eivät ole osoitus turvallisuus tapahtuma.

Joten mikä meidän pitäisi käyttää? Hyvä puolustus syvällistä toimintatapojen Kerro meille käyttää molempia. ;)

Reaaliaikainen hälytys

Voimme hyödyntää mustalle listalle suorittaa reaaliajassa varoittaa tapahtuman haluamme olla tietoisia heti, kun ne tapahtuvat. Kieltolistalle pitäisi käyttää vain hiljainen erilaisten tapahtumien järjestämiseen. Toisin sanoen haluamme pitää kiinni kirjallisesti allekirjoituksia tapahtumista, jotka ovat erittäin todennä todellinen tietoturvaongelma. Hyviä esimerkkejä ovat:

  • Eri kirjautumisnimi epäonnistumisia kaikki samasta IP-osoitteesta lyhyessä ajassa
  • Useita HTTP 403 virheet on tuottaa yhden IP lyhyessä ajassa
  • Sisäisiä järjestelmiä saa monet ICMP virheistä tai TCP nollaa lyhyessä ajassa

Voidakseen suorittaa reaaliajassa hälyttää, tarvitsemme ohjelmisto, seuraa lokit reaaliajassa. Lokitiedot on tarkistettava määritellä allekirjoituksen, joka myös osoittaa mitä tehdä, kun tapahtuma.

Swatch

Yksi helpoimmista työkaluja voit käyttää seurantaan lokitiedot on Swatch . Swatch perustuu Perl. Tämä tarkoittaa, että vaikka se on suunniteltu UNIX-ja Linux-järjestelmiin, voit saada sen käynnissä Windows Jos olet Perl asennettu. Yksinkertaisuus on sekä Swatch suurin vahvuus ja heikkous. Vaikka Swatch on suhteellisen helppo ottaa käyttöön, se on myös hieman rajoitettu sen toiminnallisuutta. Silti, jos olet uusi hakkuut, Swatch on erinomainen ensimmäinen työkalu reaaliaikaiseen hälytyksen.

Jos haluat asentaa Swatch, sinun tulee luoda ainutlaatuinen asetustiedosto jokaiselle lokitiedoston haluat tarkkailla. Vuonna asetustiedosto kerromme Swatch mitä etsiä kyseisellä lokitiedoston, ja mitä tehdä, kun tapahtuma havaitaan.

Esimerkiksi Sanotaan meillä tulee olemaan Swatch seurata Web-palvelimen virhe loki. Saatamme haluta luoda merkinnän samanlainen seuraavat Swatch n konfigurointitiedostoa virhelokiin:

# Varo puskurin ylivuotoja

watchfor / asiakas kiistää palvelinmäärityksissä | Tiedostonimi liian pitkä /

Mail = noc@fubar.org: webmaster@fubar.org, subject = Web-palvelimen ylivuoto yrittää

Linja alkaa "#" on yksinkertaisesti kommentaari allekirjoitus. Watchfor linja tunnistaa mikä merkkijono (s) halutaan määritellä olevan mielenkiintoinen. Tässä nimenomaisessa sääntö olemme määritelleet kaksi eri jousille, "asiakas kieltää palvelimen määritykset" ja "Tiedostonimi liian pitkä" kuin mielenkiintoinen. Putki merkin välissä jouset toimii looginen "tai". Jos jompikumpi merkkijono on kohdannut, posti parametri määrittelee kaksi eri sähköpostiosoitteet meidän pitäisi yhteyttä. Otsikoksi sähköposti tulee "WWW-palvelin ylivuoto yrittää", kun taas ruumis sähköposti on todellinen lokitapahtuman.

Jos on muita kuvioita haluamme havaita, voisimme lisätä watchfor ja postin lausunnot. Jos haluamme tehdä enemmän kuin lähettää sähköpostia, exec parametrin avulla voidaan suorittaa minkä tahansa sovelluksen sijaitsee paikalliseen järjestelmään. Kynnys parametri voidaan käyttää myös arvostellaksesi rajoittaa raportointia tapahtumista.

Yksinkertainen Tapahtuman koordinaattori (SEC)

SEC on hämmästyttävä hälytys työkalulla voit ladata tärkein verkkosivustosta . Se tukee BSD ja Linux, ja mukana useita suosittuja Linux makuja. SEC tukee täysin säännölliset lausekkeet ja voit luoda äärimmäisen rakeista allekirjoituksia.

Sääntö muoto on seurannut:

type = havaitsemis

ptype = Kaavatyypin (säännöllinen lauseke, string ottelu)

pattern = Mitä etsiä

desc = Kuvaus (voi olla muuttuja)

action = Mitä tehdä, kun havaitaan

On erinomainen arkisto ennalta kirjoitetun sääntöjä , voit käyttää sitä on myös syytä tarkastella. Voit ottelussa useita malleja, määrittää useita kynnyksiä, kaikki käsittelyn aikana satoja lokiviesteistä sekunnissa. Oikeastaan ​​ainoa haittapuoli SEC on, että tarvitset hyvää ymmärrystä säännöllisiä lausekkeita käyttää työkalua tehokkaasti. Silti työkalu voi olla paljon tehokkaampi ja joustavampi kuin Swatch.

Mistä saan lisää hälytys ideoita?

Olin mukana luomisen alkuperäinen SANS Top 5 Log Reports . Saat huhtikuuta, 2009 Kirjaudu Summit Päivitin esitykseni hajottaa raportin esimerkit tulee hiljainen ja meluisuus luokkiin. Mitään hiljainen lista olisi hyvä ehdokas hälyttämiseen. Mitään meluisia osa on parempi seurata päivittäin raportteja.

Päivittäiset raportit

Joten me velkarahalla mustalle listalle tuottaa meille reaaliaikaisen hälytyksiä. Me nyt hyödyntää sallittujen osoitteiden luettelosta auttaa esiin tuntemattomia mutta kiinnostavia liikkumistavan sisällä meidän päivittäiset raportit.

Kun se tulee päivittäin raportteja, meillä on taipumus kallistua kohti suuret numerot. Mitkä ovat top 5 IP tiedonsiirto? Mitkä sähköpostiosoite lähetetään eniten viestejä? Vaikka suuret numerot ovat varmasti tärkeitä, se on kokemukseni, että turvallisuus tapahtumia sinun tarvitse pelätä eniten tuottavat vähiten lokitiedot. Smart hyökkääjät yrittävät erittäin vaikea pysyä piilossa sisällä melua. Joten ainoa tapa löytää niitä on alentaa kohinasuhde.

Olen kirjailija turva raita varten SANS. Yksi Labs minulla opiskelijat suorittavat on jäsentää 200000 rivin lokitiedostoon. Tavoitteena on paikalla mielenkiintoisia kuvioita sekä muotoilla uudelleen osaksi automaattinen prosessi. Useimmat ihmiset löytää sataman skanneri, koska se on melko meluisa. Jotkut jopa paikalla IP-osoite suorittamalla sovellustason hyökkäykset palvelimelle. Mitä useimmat ihmiset kaipaamaan ovat kuitenkin kuusi riviä, jotka ovat melko selkeä osoitus siitä, että sisäinen järjestelmä on jo heikentynyt ja vaatii kotiin lähtöpassit. Miten löytää ne 6 riviä? By sallittujen osoitteiden luettelosta kaiken ymmärrät ja keskitytään siihen, mitä koskaan on jäljellä.

Joten se on OK jokapäiväiselle raportit antaa meille melko listaykköseksi suuret numerot. Yksi raporteissa kuitenkin on voitava siirtää kaikki lika sivuun, jotta voimme paremmin paikalla mielenkiintoisia hahmoja.

Logwatch

Yksi parhaista työkaluja tekevät päivittäin kirjaa tarkastelu on Logwatch . Logwatch tekee yhteenvedon koko lokin kuvioita sen ymmärtää, kun taas esiin mitään ilman määritetyn allekirjoituksen. Paras tapa ymmärtää tämä ominaisuus on tarkastella esimerkiksi.

Sshd Killed: 2 Aika (s)

Sshd alkuun: 1. Aika (s)

Liitännät:

Epäonnistuneet kirjautumiset näistä:

msmith / salasana 1.3.247.11: 6 kertaa (s)

jsmith / salasana 1.3.247.11: 5 kertaa (s)

psmith / salasana 1.3.247.11: 4 kertaa (s)

Käyttäjiä kirjautumalla kautta sshd:

jjones kirjautunut sisään Sundown (1.3.247.9) käyttäen publicKey: 146 kertaa (t)

jsmith kirjautunut sisään dialup5533.wnskvtao.sover.net (216.114.181.200) käyttäen Salasana: 1 kertaa (s)

jsmith kirjautunut sisään dialup984.wnskvtao.sover.net (216.114.163.223) käyttäen Salasana: 1 kertaa (s)

bjones kirjautunut sisään Charlie (1.3.247.11) käyttäen publicKey: 444 Times (t)

jsmith kirjautunut sisään 192.168.1.173 käyttäen Salasana: 2 kertaa (s)

djones kirjautunut sisään Charlie (1.3.247.11) käyttäen salasana: 47 kertaa (s)

** Ylivertainen Entries **

Saanut katkaista 148.64.147.168: 3: Key Exchange epäonnistui.

Saanut katkaista 216.114.160.132: 11: Kaikki avoimet kanavat kiinni

skannattu 146.87.114.150 kanssa SSH-1.0-SSH_Version_Mapper. Älä hätäile.

skannattu 211.184.226.99 kanssa SSH-1.0-SSH_Version_Mapper. Älä hätäile.

Yllä olevassa esimerkissä Logwatch käytetään tiivistää SSH toimintaa. Se ymmärtää palvelu pysäytetään ja käynnistetään, epäonnistuneet kirjautumisyrityksiä sekä onnistuneiden kirjautumisten. Kaikki tämä tieto näkyy yhteenveto formaatissa, joten se on helpommin sulavaa. Esimerkiksi emme tiedä tarkalleen, milloin msmith väärin tuli salasanansa, mutta näemme se tapahtui kuusi kertaa, kaikki lähtee IP-osoite 1.3.247.11. Joten sen sijaan, kuusi riviä sulatella, meidän tarvitsee vain katso. Jos haluamme nähdä kuhunkin lokimerkintä, voimme aina palata alkuperäiseen lokit.

Katsokaa nyt "Vertaansa vailla olevat maininnat"-osiossa. Jokainen näistä on tapahtuma, joka Logwatch ei ole allekirjoitusta varten. Sen sijaan sivuuttaa niitä, mikä tapahtuu mustan listan perustuva järjestelmä, ne on koottu täällä meille uudelleen. Sitten on mahdollisuus luoda allekirjoituksen erillinen merkintä niin se saa luokitella samalla tavalla kuin prosessin ja kirjautumisessa kohdat.

Selvästi tämä antaa meille molempien maailmojen parhaat puolet. Edellä raportti edustaa hieman yli 650 riviä arvoinen lokimerkintöjen tiivistää alas helppolukuinen raportti. Tärkeintä on, mikään lokitiedot jouduttiin huomiotta voidakseen tuottaa tämän yhteenvetoraportin.

Beyond päivittäinen raportointi

Saatat myös olla hyödyllistä tehdä pitkän aikavälin analyysiä ja data mining oman lokitiedot. Tämä voi auttaa paljastamaan malleja, jotka normaalisti jäävät havaitsematta, kun lokit pieni tilannekuvan ajoissa (kuten 24 h) tarkistetaan. Luultavasti yksi parhaista työkaluista käsittelyä varten paljon tietoa on splunk .

Splunk

Splunk on saatavilla ilmainen versio on rajoitettu käsittely 500 MB per päivä, tai voit sijoittaa kaupallisen version, joka tukee rajoittamaton tietojenkäsittelyä. Splunk on erittäin joustava osoitteessa hyväksyä tiedot. Se voi toimia keskitetysti kirjautumalla palvelimelle, tai voit siirtää tiedostoja kautta useita menetelmiä, kuten FTP ja HTTP. Kun tiedot on vastaanotettu, splunk indeksit jokaisen kentän jokainen lokitiedosto. Tämä antaa sinulle ainutlaatuisen lajittelu ja hakutoiminnot.

Täydelliset ominaisuustiedot ovat splunk ovat liian lukuisia päästä tässä viestissä. Tarkista heidän sivuston Täydellinen lista tuetuista ominaisuuksista. Mitä splunk on erittäin hyvä manipuloi ja raportointi valtava määrä lokitiedot. Se voi indeksoida, etsiä ja raportoida miljardeja lokitiedot sekunnissa. Tämä tekee siitä erittäin hyödyllinen tuottaa pitkän aikavälin suuntaus raportteja tai käynnissä Tallennetut haut tiedon louhintaan tarkoituksiin.

Exec Yhteenveto

Me olemme päässeet loppuun polkua. Toivottavasti et tuntuu et on parempi kahva miten käyttää keskitettyä kirjautumalla ratkaisu, sekä miten hyödyntää sitä paremmin suojata ympäristöä. Jos sinulla on kysyttävää, ota vapaasti pudota kommentin. :)

Perustamalla Security Information Management System-Part5

14 elokuu 2009

Minun viimeinen viesti puhuin kuinka kirjautumalla palvelin käyttää viestin prioriteetti arvo lajitella Tul.puh.loki viestejä. Tässä erä minä puhua testaus yhteydet, sekä miten saada eri vaihdetta lanka esittämään lokitiedot keskitettyyn palvelimeen.

Vaatimukset

Jotta järjestelmä esittää lokimerkintöjen sillä on oltava tukea syslog. Lokitiedot tarvitse lähettää selväkielisinä satamaan UDP/514 siitä kirjautumalla palvelimelle. Jos käytät rsyslog palvelimella, TCP/514 on hyväksyttävä samoin.

Kirjoittanut pitkä merkinnät tulisi sisältää seuraavat tiedot:

  • Prioriteetti arvo (<PRI> muodossa) alussa hyötykuorma
  • Sovelluksen nimi lähettämistä lokitapahtuman
  • Prosessi ID jota sovellus käyttää
  • Elin lokisanomia

Mutta ollakseni rehellinen, Syslog ei ole kovin kranttu. Se yrittää tallentaa mitä lähetetään sen portin niin pitkä merkintä. Jos ensisijainen arvo ei ole läsnä, se kirjaamista mihin tahansa tiedostoon käytetään laitoksen 1. Yleensä tämä on / var / log / messages.

Testaus Connectivity

Kun käyttöön uuden asennuksen, haluan tarkistaa välisen yhteyden ensimmäiset asiakkaat ja kirjautumalla palvelimelle. Jos tietojen keruu ei toimi, haluat pystyä eristämään ongelma-alue. Tyypillisiä ongelmia ovat:

  • Client määritetty virheellisesti
  • Palomuuri tavalla (työasemassa, lanka, tai kirjautumalla palvelin)
  • Server määritetty virheellisesti

Haluat seurata viestejä tiedoston kirjautumalla palvelin varmistaa testi lokimerkinnät on vastaanotettu. On kirjautumalla palvelimelle, suorita seuraava komento:

tail-f / var / log / messages

Tail avaa lokitiedoston lukea vain ja tulostaa viimeiset viisi riviä. Kun uusia lokitiedot vastaan, he saavat tulostuvat näytön samoin.

Voit luoda testi lokitapahtuman, tykkään käyttää netcat . Netcat voidaan käyttää mistä tahansa Windows, Linux tai Unix-järjestelmissä. Vuodesta testausjärjestelmän, suorita komento:

echo "Tämä on UDP testi lokitapahtuman" | nc-u-w 1 <IP osoite kirjautumalla server> 514

Sinun pitäisi nähdä kaikui osa komento näy / var / log / messages-tiedoston kirjautumalla palvelimelle. Jos ei, käynnistää paketin narkomaani ja katso jos voit selvittää, missä vika esiintyy. Jos haluat testata TCP liitettävyyttä sekä yksinkertaisesti komento uudestaan ​​jättäen pois netcat "-u" kytkin:

echo "Tämä on TCP testi lokitapahtuman" | nc-w 1 <IP osoite kirjautumalla server> 514

Jos molemmat merkinnät ovat saaneet, olemme valmiit aloittamaan osoitinlaitteet meidän kirjautumalla palvelimelle.

Verkkolaitteita

Useimmat verkkolaitteet tukee Syslog kautta UDP/514. Se on vain asia menee läpi asiakirjat ja määrittää oikea-käskyjä lähettää lokitiedot ja etäpalvelimeen.

Jos käytät Cisco IOS, suorita seuraavat maailmanlaajuisista ohjelmointitilassa:

kirjautumalla <IP-osoite osoite kirjautumalla server>

Jos haluat muuttaa kirjautumalla välineen "paikalliseen käyttöön 7" jotain muuta, komento on:

kirjautumalla laitos <facility lyhyt nimi>

Joten muuttaa kirjautumalla mahdollisuus "paikalliseen käyttöön 3", komento olisi:

kirjautumalla laitos local3

Linux-ja UNIX-järjestelmät

On syslog vaihtoehtoja saatavilla Linux-ja UNIX. Tässä osiossa tulen kansi miten saada Syslog ja rsyslog välittämään heidän lokiviestit etäpalvelimeen.

Syslog

Jos asiakas on käynnissä Syslog, sinun täytyy muokata / etc / syslog.conf tiedosto. Lisää seuraava rivi tiedoston alareunaan:

*.* @ <IP-osoite Osoite kirjautumalla server>

Joten esimerkki olisi:

*.* @ 192.168.1.150

Huom väliin tilaa villi kortti ottelun ja kauko IP-osoite on sarkainmerkeillä. Jos käytät välilyöntejä, Sysylog ei voi jäsentää tiedostoa. Tallenna ja poistu tiedoston, käynnistä Syslog aktivoida muutoksia.

rsyslog

Kanssa rsyslog meillä on mahdollisuus huolinta meidän lokiviestit UDP tai TCP. Kummassakin tapauksessa meidän täytyy muokata / etc / rsyslog.conf tiedosto. Välittämään pitkä merkinnät UDP, lisää seuraava rivi tiedoston loppuun:

*.* @ <IP-osoite Osoite kirjautumalla server>: <portti>

Joten esimerkki olisi:

*.* @ 192.168.1.150:514

Jos haluamme käyttää TCP sijaan, me vain käyttää kahta "@" symboleita:

*.* @ @ 192.168.1.150:514

Kun olet valmis tallenna ja poistu tiedosto. Sinun pitää käynnistää rsyslog aktivoimaan muutoksia.

Windows-järjestelmät

Kuten edellisessä postitse Windows ei sisällä tukea syslog. Tämä tarkoittaa sinun kolmannen osapuolen ohjelmisto muuntaa lokisi reaaliajassa ja toimittaa ne kirjautumalla palvelimelle. Loganalysis Web-sivusto on luettelo mahdollisista ratkaisuista.

Varten tähän virkaan, minä kansi Snare . Se on vapaasti käytettävissä, voidaan käyttää kaupallisesti lisensoitua, ja on erittäin helppo ottaa käyttöön prosessi.

Kun olet ladannut ohjelman, sinun täytyy määrittää sen järjestelmässä. Tämä on esitetty kuvassa # 1. Snare on tiedettävä sijainnin kirjautumalla palvelimelle sekä mitä laitokseen ja vakavuusasteen käyttää. Kun olet valmis, klikkaa "Viimeisimmät tapahtumat"-valikosta juoma mitkä erityiset Tapahtumienvalvonta lokitiedot Snare on välittämisestä kirjautumalla palvelimelle.

snare-config

Exec Yhteenveto

Tässä postitse Keskustelin testaus yhteyden kirjautumalla palvelimelle, sekä miten määrittää asiakkaat keskittämään lokit. Vuonna Seuraava viesti Minä puhun siitä, mitä etsiä ja päivittäisen raportoinnin työkalu sekä reaaliaikaisen hälytyksen.

Perustamalla Security Information Management System-Part4

12 elokuu 2009

Viime viesti puhuin miten asetukset kirjautumalla palvelimelle joka hyväksyy kauko lokitiedot. Tässä erä Minä puhun siitä, miten lajittelu lokimerkinnät osaksi yksittäisiä tiedostoja.

Facility, vakavuus ja prioriteetti

Puhutaanpa miten kirjautumalla palvelimet selvittää, mikä tiedosto tallentaa log merkintä, kun se saa vastaan. Kirjaudu viestit sisältävät kaksi kuvailevaa parametrit, tila ja vaikeusaste. Kun nämä kaksi tekijää yhdistetään, arvo kutsutaan painopisteenä lokisanoman.

Laitos

Facility määrittelee tyyppinen prosessi, joka syntyy lokitapahtuman. Esimerkiksi kaikki sähköpostipalvelimet odotetaan tunnistaa, että niiden lokitiedot ovat osa "mail" laitokseen. FTP prosessit tulisi käyttää FTP laitos, NTP prosessit tulisi käyttää NTP-sali ja niin edelleen. RFC 3164 määrittelee voimassa tilat, mutta tässä lista:

Numeerinen Facility

Koodi

0 ytimen (Kern)

1 käyttäjä-tason viestejä (käyttäjä) - oletuksena, jos ei ole määritetty

2 viestijärjestelmä (mail)

3-järjestelmän demoneja (daemon)

4 Turvallisuus / lupa viestejä (auth)

5 Sisäinen syslogd (syslog)

6 rivikirjoitin Subsystem (LPR)

7 Network News Subsystem (uutinen)

8 UUCP Subsystem (uucp)

9 kello daemon

10 turvallisuus / lupa viestejä (authPriv)

11 FTP daemon (ftp)

12 NTP Subsystem (NTP)

13 log tilintarkastus

14 log hälytys

15 vuorokauden daemon (cron)

16 paikalliseen käyttöön 0 (local0)

17 paikalliseen käyttöön 1 (local1)

18 paikalliseen käyttöön 2 (local2)

19 paikallista käyttöä 3 (local3)

20 paikallista käyttöä 4 (local4)

21 paikalliseen käyttöön 5 (local5)

22 paikalliseen käyttöön 6 (local6)

23 paikalliseen käyttöön 7 (local7)

"Paikalliseen käyttöön" tilat muistuttavat yksityisiä osoitteita IP maailman. Nämä tilat eivät ole varattuja, ja ovat käytettävissä kuka tahansa voi käyttää parhaaksi katsomallaan tavalla.

Facility ongelmia

On pari ongelmaa tässä. Aloita, jossa on Web-palvelin laitokseen? Tämä luettelo syntyi jo vuonna 1987 ennen Web-palvelimet (tai Gopher itse asiassa) olemassa. Joten Osa palveluista käytämme tänään (VoIP, SQL, jne.) puuttuvat. Myös jotkut luetelluista palveluista tyypillisesti jäävät käyttämättä yritysympäristössä. UUCP ja Network News (NNTP) ovat erinomaisia ​​esimerkkejä.

Puute nykyisistä palveluista on aiheuttanut monia myyjiä hyvin riippuvainen paikallisen käytön tiloissa. Tämä voi ilmetä ristiriitoja, kun pääsemme lajittelu meidän lokitiedot. Esimerkiksi Linux on käytetty paikallisia käyttää 7 tunnistaa sen käynnistyksen aikana lokitiedot. Apache käyttää myös paikallista käyttöä 7 Web-palvelimen virheitä. Joten tiellä voi olla vaikeaa meille lajitella Web virheet ja nistysviesteistä eri lokitiedostoja.

Toinen ongelma on, että ei ole pidemmän kuvauksen kustakin näistä laitoksista. Tämä voi tehdä hieman vaikea ohjelmoija tunnistaa mitä käyttäisit. Esimerkiksi, sanokaamme olemme kirjoitettu ohjelma, joka todentaa käyttäjän verkkoon pääsyn. Mitkä toimintoa olisi käytämme? Facility 4 ja 10 näyttävät todennäköisesti, mutta niiden kuvaukset ovat identtisiä. Miten me valitsemme? Jos ohjelmamme toimii taustana prosessin pitäisi oikeastaan ​​valita Facility 3 sijaan?

Saat ajatus. Luettelo ei ole niin selkeä kuin se voisi olla. Ei ole harvinaista nähdä valmistajat käyttävät eri laitokseen kuin voisi odottaa. Esimerkiksi olen nähnyt VPN myyjät avoimeksi kuin erot tilojen välillä 4 ja 10, joten ne lähetä osalle lokitiedot kullekin.

Vakavuus

Vakavuus määrittelee merkityksen lokitapahtuman. Sama RFC 3164 määrittelee vakavuusasteella kuten:

Numeerinen Vakavuus

Koodi

0 Emergency: järjestelmä on käyttökelvoton (kehittyvillä)

1 Alert: toimiin on ryhdyttävä välittömästi (hälytys)

2 Kriittiset: kriittisissä tilanteissa (crit)

3 Virhe: virhetilanteet (virhe)

4 Varoitus: varoitus olosuhteissa (varoittaa)

5 Huomaa: normaali, mutta merkittävä ehto (ilmoitus)

6 Tiedotteet: informational viestit (info)

7 Debug: debug-tason viestejä (debug)

Onneksi Vakavuustasot ovat paljon vähemmän epämääräisiä kuin laitos kuvaukset. Tämä tarkoittaa, että ne ovat paljon vähemmän sekava työskennellä. Korkeampi numeroitu vakavuusasteella yleensä hyvin monisanainen. Tämä tarkoittaa sanonta haluat lähettää debug-tason viestejä kirjautumalla palvelin voisi helposti tulva verkkoon. Käytä korkeampi numeroitu vakavuusasteella varoen.

Prioriteetti

Kun lokitapahtuman saa tarttua kirjautua palvelimelle, ensimmäinen arvo sisällä on viestin prioriteetin. Prioriteetti on mahdollisuus ja vakavuus arvot yhdessä kohti seuraavaa matematiikka kaava:

(Facility x 8) + vakavuus = Priority

Joten avulla sanoa meidän sähköpostipalvelimen täytyy lähettää varoitusviestin. Mikä olisi ensisijaisesti? Mail laitos on arvo 2, mutta varoitukset ovat vaikeusasteen 4. Joten matematiikka olisi:

(2 x 8) + 4 = 20

Jos tulostuspalvelin (sali 6) toimittamiseen tarvittavan lokimerkintä sanonta tällä hetkellä tulessa (vaikeusaste 0), prioriteetti arvo viesti olisi:

(6 x 8) + 0 = 48

Kun lokitapahtuman saa lähettää, prioriteetti arvo on kapseloitu alle ja yli merkkejä. Joten prioriteetti arvoa yllä sähköpostipalvelimen viesti olisi "<20>" kun tulostuspalvelin olisi "<48>". Tämäkin on ensimmäinen tieto lähetetään loki viesti.

Lajittelu lokitiedot

Prioriteetti arvoa käytetään kirjautumalla palvelimet lajitella saapuvia viestejä. Esimerkiksi jos haluaisimme kaikki sähköpostiviestit mennä samaan tiedostoon, olisimme kertoa kirjautumalla palvelimelle, että kaikki viestit, joiden prioriteetti 16 (2 × 8 +0) kautta 23 (2 × 8 +7) pitäisi mennä " maillog "tiedosto. Useimmat kirjautumalla palvelimet (kuten rsyslog) antaa sinun tehdä tämän numeerisesti tai käyttämällä lyhyt kuvaus nimiä.

rsyslog.conf esimerkiksi

Tässä on kaksi riviä pois rsyslog.conf tiedoston mukana Fedora. Puhutaanpa mitä he ovat tekemässä:

authPriv .* / var / log / secure

*. Info, mail.none, authpriv.none; cron.none / var / log / messages

Nämä rivit määrittävät kaksi säännöt sen määrittämiseksi, lokitiedot pitäisi mennä joka lokitiedostoja. Syntaksi lajittelu on:

facility.severity

Joten ensimmäinen rivi kertoo kaiken laitoksessa 10 (authPriv) lokimerkintöjen riippumatta vakavuus ("*" on villi kortti ottelu) tulee lähettää tiedosto / var / log / turvallista.

Toinen rivi on vähän monimutkaisempi kuin se on useita ehtoja erotettu puolipisteellä. Nämä ehdot valtio:

  • *. Info = Kaikki tilat, kunhan vakavuusasteen on info
  • mail.none = Ei postia laitos lokimerkintöjen riippumatta vaikeusasteesta
  • authpriv.none = Ei authprive laitos lokimerkintöjen riippumatta vaikeusasteesta
  • cron.none = Ei cron laitos lokimerkintöjen riippumatta vaikeusasteesta

Tai kääntää tämän ja Englanti, rivi sanoo "Lähetä kaikki vakavuus" info "viestejä / var / log / messages, paitsi ne, jotka sisältävät laitoksen" postia "," authPriv "tai" cron ".

Joten näiden sääntöjen voimme määritellä tahansa laitoksen ja vaikeusaste arvoja ja joka lokitiedoston haluaisimme suoraan sen. Kun ensimmäiset tähän asti, kiinni oletusarvot. Kun alkaa kerätä lokitiedot voit muokata sääntöjä kuin parhaaksi näette.

Taivutus RFC

Ihanteellisessa maailmassa, RFC olisi täydellinen sovi kaikkien tarpeisiin. Valitettavasti näin ei aina tapahdu. Hyvä esimerkki on hakkuita tilat. Kuten olemme puuttuu helpottaa nykyaikaisen päivä palveluita, mutta samalla on mahdollistaa, että emme koskaan käytä. Ilmeinen vastaus on kierrättää vanhentunut tilat tukeakseen nykyaikaisia ​​palveluita.

Esimerkiksi UUCP (laitos 8) ei edes tue nykyaikaisia ​​käyttöjärjestelmiä. Tässä mielessä, haluan käyttää sitä Windows-laitokseen. Näin voin lajitella kaikki Windows lokitiedot omaan tiedostoon. Saat verkkolaitteita, käytän Network News laitos (laitos 7). Jos olet epävarma, jos laitos on käytössä, muokata kirjautumalla palvelimen asetustiedosto lähettää lokin tietojen kohdalle mahdollisuus ainutlaatuinen tiedostoon:

ftp .* / var / log / laitos-testi

Ellei merkintöjä saapuvat, olet hyvässä kunnossa. Pidä mielessä, että laillisesta palvelusta voi käyttää sitä myöhemmin. Esimerkiksi jos kolmen kuukauden nyt joku perustaa FTP-palvelin, meillä voi olla ongelmia, jos meillä on jo käytössä FTP laitos (laitos 11). Jos olet epävarma, voit aina kiinni paikalliseen käyttöön tiloja, koska sitähän ne on tarkoitettu. Paikallinen käyttö 0 ja 7 näyttävät olevan eniten käytetty, joten vältä niitä, kun mahdollista.

Muut lajittelu vaihtoehtoja

Vaikka se ei ole osa RFC, jotkut kirjautumalla palvelimet antavat sinulle mahdollisuuden järjestellä lokimerkinnät perustuvat mallit viestissä. Hyvä esimerkki on syslog-ng . Syslog-ng lajitellaan perustuu laitoksen ja vakavuudesta, mutta voit myös lajitella perustuu lähde IP, sovellus, joka syntyy lokimerkintä jne. Tämä antaa sinulle paljon joustavampia lajittelu vaihtoehtoja ja se voi olla jotain harkita, jos laitos / vakavuus ei rakeinen riitä tarpeisiisi.

Exec Yhteenveto

Tässä erä puhuimme miten laitos ja vaikeusaste käytetään lajitella lokitiedot. Minun Seuraava viesti Minä puhun siitä, miten saada jokaisen meidän järjestelmiä toimittamaan lokiviestit meidän keskitetyllä palvelimella.

Perustamalla Security Information Management System-Part3

11 elokuu 2009

Viime viesti I kattoi noin arkkitehtuurin koskee liikkuvaa ulos keskitetyn turvallisuus tietojärjestelmä. Tässä post minä kattavat käyttöön perus loki palvelin, ja tarkistaa, että se on valmis hyväksymään lokitiedot.

Valitsemalla kirjautumalla palvelimelle

Ensiksi meidän tarvitsee vain valita alustan meidän kirjautumalla palvelimelle. Jos olemme yksinkertaisesti perustamalla testilaboratorio, Windows, UNIX tai Linux kaikki tekevät suuria valintoja. Valitsemalla Windows saattaa olla avuksi Windowsin järjestelmänvalvojan, koska ne eivät tarvitse leikata käyrän uuden käyttöjärjestelmän, kun se yrittää testata hakkuita. Vaikka Windows ei tue Syslog kättelyssä, on joitakin erinomaisia ​​paketteja kuten Kiwi lokipalvelin ja WinSyslog että lisää Syslog tuki. Molemmat ovat kokeiluversiot ja ovat suhteellisen edullisia lisensoida.

Jos puhumme perustamalla tuotantoa palvelin kuitenkin, me haluamme pysyä kaukana ikkunoista. Windows on pahamaineinen siitä kamala IP pino. Jos siitä edellinen "laastaria" on rujo sitä vielä edun mukaista hidastaa madon leviämistä ja nopeuttamalla GUI. Vaikka monet näistä rajoituksista on poistettu vuonna 2008 Server ja Windows 7, IP suorituskyky on edelleen sub-par verrattuna Linuxissa tai Unixissa käyttöön samoihin laitteisto.

Niin että lähtee Linux ja UNIX kuin valintoja tuotantojärjestelmää. Mikä valita riippuu henkilökohtaisen valinnan. Jotkut pitävät vakautta BSD taas toiset, kuten joustavuutta Linux. Varten tämän asiakirjan Tulen kanssa Fedora perustuu Linuxiin. Asennus ja asetusten OS on suhteellisen intuitiivinen ja suoraviivainen.

Hyväksyminen kauko lokit

Jotta hyväksyä lokimerkinnät päässä etäjärjestelmien, vanhemmat versiot Fedora tarvitaan sinun alustaa Syslog daemon (syslogd) kanssa "-R" vaihtoehto. Tämä tehtiin lisäämällä "-R" syslogd_options rivi / etc / sysconfig / syslog-tiedoston. Jotkut versiot Linux vielä tue vanhoja Syslog, ja vaativat voit lisätä "-R" Syslog RC alustuksen tiedosto. Tarkista dokumentit käyttöön erityisiä jakeluun.

Uusi Fedora järjestelmät kuitenkin tukevat "Luotettava Syslog" tai rsyslog. Toteutus on melko samanlainen kuin tavallinen vanha Syslog, paitsi rsyslog tukee viestinnän TCP/514 sekä UDP/514. Viime viesti kuvailin että käynnissä lokitiedot TCP voi korjata joitakin syitä me löysä lokimerkintöjen, mutta ei niitä kaikkia. Jos haluat leikkiä TCP tukea, mennä eteenpäin ja avaa molemmat portit kirjautumalla palvelimelle.

Saadaksesi rsyslog hyväksymään kauko lokimerkintöjen meidän täytyy muokata / etc / rsyslog.conf tiedosto. Kohti alussa tiedoston sinun pitäisi nähdä seuraavat:

# Tarjoaa UDP syslog vastaanotto

# $ ModLoad imudp.so

# $ UDPServerRun 514

# Sisältää TCP syslog vastaanotto

# $ ModLoad imtcp.so

# $ InputTCPServerRun 514

"#" (Punta) symboli alussa rivi kertoo järjestelmä ei käsitellä Loput linjasta. Käytämme tätä tekniikkaa kommentit sekä "kommentoimalla pois" komennot emme halua olla käsitelty. Kommentoimalla ulos ModLoad ja satama erittely linjat, estämme rsyslog avaamasta kuuntelee pistorasiaan. Auttaa pitämään järjestelmän varmempi tilaan.

Koska olemme luodaan keskitetty kirjautumalla palvelin, meidän täytyy avata nuo pistorasiat hyväksyä kauko lokitiedot. Muokkaa / etc / rsyslog.conf tiedoston poistaa sopiva punta symboleja. Tiedosto pitäisi nyt näyttää tältä:

# Tarjoaa UDP syslog vastaanotto

$ ModLoad imudp.so

$ UDPServerRun 514

# Sisältää TCP syslog vastaanotto

$ ModLoad imtcp.so

$ InputTCPServerRun 514

Jos tiedät et koskaan käytä TCP, voit jättää kaksi viimeistä riviä kommentoi pois. Kun olet valmis Tallenna muutokset ja poistu tiedosto.

Nyt pitää käynnistää hakkuut niin meidän muutokset pannaan täytäntöön. Tämä tehdään Fedora suorittamalla seuraava komento:

palvelun rsyslog uudelleen

Kun suoritat komennon, sinun pitäisi nähdä rsyslog lopettaa ja aloittaa tila "OK". Jos shutdown epäonnistui, se johtuu rsyslog ei alustetaan käynnistyksen aikana. Komentoriviltä, ​​komento "setup" ja valitse "System palvelut" päävalikosta. Kun palvelut valikko avautuu, selaa luetteloa kunnes löydät rsyslog. Ruksata ruutu vasemmalle ja sitten valitse "OK". Lopeta Setup Utility ja rsyslog nyt alustaa aina, kun on käynnistetty.

Tarkistetaan portin

Seuraavaksi meidän on varmistettava, että hakkuut prosessi on hyväksyä kauko lokitiedot. Komentoriviltä, ​​kirjoita "netstat-| grep: 514". Ulostulo pitäisi näyttää seuraavat:

[Root @ Fubar ~] # netstat-| grep: 514

tcp 0 0 0.0.0.0:514 0.0.0.0: * LISTEN

tcp 0 0::: 514::: * LISTEN

udp 0 0 0.0.0.0:514 0.0.0.0: *

udp 0 0::: 514::: *

Ensimmäinen rivi kertoo, että TCP/514 kuuntelee kautta IPv4 kaikilla verkkoliittymissä. Linjalla kaksi kertoo TCP-portin myös kuuntelee mitä tahansa rajapinta IPv6-osoite. Rivit kolme ja neljä ovat samat tiedot, paitsi UDP. Jos jokin merkinnät valtion "127.0.0.1:514" eikä "0.0.0.0:514", niin portti on vain pakko loopback liitäntä. Vain paikallinen järjestelmä pystyy saavuttamaan sen. Tämä voi tapahtua legacy Syslog järjestelmien jos unohdit ajaa niitä "-R" kytkin.

Sinun pitäisi nyt olla kirjautumalla palvelin, joka kykenee vastaanottamaan saapuvaa lokitiedot. Vuonna Seuraava viesti Minä puhun siitä, miten nämä lokitiedot päästä lajitellaan yksittäisiä tiedostoja.

Perustamalla Security Information Management System-Part2

10 elokuu 2009

Minun viimeinen viesti keskustelimme määrittelemällä tavoitteesi Security Information Management (SIM)-järjestelmä. Tässä postitse me puhumme arkkitehtuurin koskee sekä kapasiteetin suunnittelusta.

Verkkoviestintää

Tavoitteena on saada yksi tai useampia SIM-palvelimia, jotka keräävät lokitiedot muista järjestelmistä. Tällä on varmasti vaikutusta verkon käyttöastetta. Kuinka paljon vaikutukset riippuvat määrästä ja tyypistä järjestelmien keräämme lokitiedot alkaen.

UDP/514

Lähes kaikki järjestelmät tukevat alkuperäinen Syslog viestinnän toteuttamisesta, joka menee aina takaisin vuoteen 1988. Viimeinen kuvaus spec ilmestyi RFC 3164 . Vaikka tämä RFC on vanhentunut RFC 5424 , RFC 3164 edustaa vielä toteuttamista tukevat useimmat myyjät. Windows on merkittävä poikkeus (oma, ei Syslog tuki), mutta 3rd party ohjelmia korjaamiseksi.

Sekä RFC määritä käytön UDP lähettäessään lokitiedot. Tunnettu portti käyttö on UDP/514. Missä RFC 3164 ja 5424 eroavat on muotoa lokisanoman. Minä kaivaa nämä erot myöhemmin postitse.

Rakkaus / viha käyttää UDP

Myönteistä, UDP on yhteydetön. Tämä tarkoittaa, että se synnyttää vähemmän liikennettä kuin jos käytämme TCP. Myös log lähetykset ovat yksisuuntainen prosessi. Isäntä tuottaa lokitapahtuman lähettää paketin kirjautumalla palvelimelle, mutta kirjautumalla palvelimelle koskaan vastausta. Tämä tarkoittaa, että voimme valvoa liikennevirtoja staattisella suodatuksen sijaan tilallista suodatusta, joka asettaa vähemmän yläpuolella liikenteestä ohjauslaite. Myös UDP otsikko on tyypillisesti 1 / 3 - 1 / 4 koko TCP-otsikon, joka tarkoittaa pienempiä siirto paketteina, jolloin vähemmän verkon yläpuolella.

Kielteistä, UDP on yhteydetön. ;) Tämä tarkoittaa, että se on minimaalinen Error Reporting ominaisuus. Esimerkiksi jos välitämme lokitapahtuman ja runko katoaa (sanoa törmäys tai palomuurin pudottamalla paketti), UDP ei ole kykyä havaita, että edelleenlähetystä vaaditaan. Tämä tarkoittaa sen mahdollista lokitiedot mennä puuttuu, jos me ylivuoto verkkoon. Lisäksi UDP ei virtauksen kyky. Jos SIM-palvelin tunnistaa se saavuttaa toimintakyky se ei tapa hidastaa tulevan lähetyksen ja lokitiedot. SIM-palvelimen ainoa vaihtoehto on heittää paketit pois ilman käsittelyä niitä.

Lienee tarpeetonta sanoa, meidän on varmistettava, että oikein määrittää kapasiteettia. Jos verkko-tai SIM-palvelin ylikuormittuu, aiomme menettää lokitiedot. Oikea kapasiteetin suunnittelu alkaa ymmärtää vaikutuksen kirjaudut työasemalle.

Verkon vaikutus kirjautumalla

Maksimikoko UDP Syslog paketti on eri vaatimukset eri RFC-luvulla. Vanhentuneet RFC 3164 määrittelee Viestin enimmäiskoko olevan 1024 tavua. RFC 5426 DROPS tämä enimmäiskoko on 480 tavua. Jos myyjä seuraa edelleen vanha spec, sen mahdollisista he voivat silti ajatella 1024 tavu koko on oikeutettu. Se on kokemukseni kuitenkin, että useimmat lokitapahtuman paketit ovat kooltaan 75-225 tavua, niin maksimit ovat ei-kysymys.

Windows-järjestelmissä, palomuurit ja tunkeutumisen havainnointi on taipumus tuottaa suurimman viestejä. Verkkolaitteita taipumus tuottaa pienin viestejä. If we have a 100 Mb Ethernet network, the theoretical maximum would be somewhere around 50,000 to 130,000 frames per second. This assumes zero other traffic, which is rarely the case. For the purposes of capacity planning, assume you will be limited to 5,000 log entries per second. This number might even be less if you have a busy network. Taking some utilization measurements during the planning process is key.

Syslog over TCP

As mentioned above, UDP introduces the problem that log entries can become lost without us even knowing it. There are ways to validate capacity, which I will cover in a later post. Some feel running Syslog over TCP can rectify this problem. TCP can be leveraged for its reliability to insurie our log entries are properly received.

Unfortunately TCP support for Syslog is no were near standardized. Some vendors support TCP by simply listening on TCP/514. RFC 3195 defines Reliable Syslog as using port TCP/601, but its adoption has been extremely limited. RFC 5425 defines the use of TLS to secure Syslog transmission. This RFC specifies the use of port TCP/6514. This is a brand new specification and I'm unaware of anyone supporting it just yet.

So support for TCP is all over the board. Further, TCP does not completely fix the problem. While TCP will give us flow control and reliability on the wire, it cannot make up for the fact that Syslog at the application layer does not acknowledge the receipt of log entries. This was by design as it reduces overhead. The problem is that even by using TCP we can still lose messages within the IP stack and never know it is occurring.

So if you want to try and transmit logs via TCP, its only going to work between a specific vendor's client and server software. For example you may need to run Syslog-NG on both ends of the connection to leverage it's support for TCP. This is not always practical, as you cannot run the software client on appliances like access points, switches, routers, etc.

Where to place the logging server

When deciding where to place the logging server, we have to keep both network capacity and security in mind. Take a look at Figure #1. This is an ideal situation where the logging server has been isolated to a dedicated network operations network. This isolates it from the other security zones and makes it much easier to leverage the firewall to restrict access to the logging server.

sim-placement

Piirustus olettaa me tarvitsemme vain yhden kirjautumisen palvelimelle koko ympäristöön. What if we have 100,000 nodes to keep track of? Large networks may need to look at aggregating the data. For example if I have 10 field offices, I may need to have a logging server located at each of them collecting local log info. Each of these logging servers would then relay summary information back to the corporate office for network wide trend reports. This way we maintain a high level of visibility while reducing network load. I'll cover some possible aggregation options in a later post.

How many systems can log to a single logging server?

There is no single answer to this question as each network is different. It is going to depend on how much capacity is available on your network and how many log entries each of these systems generate. For example I could probably point 50,000 switches at a single logging server, as switches tend to generate very few messages. Firewalls on the other hand are extremely chatty, so I might max out the network or SIM server with only 20-50 firewalls. So to answer the question we need to look at two metrics:

  • How much free capacity is there on the wire?
  • How many log entries will each host generate?

The second question is not as straightforward as it may seem. For example the average desktop may only generate 40-100 log entries per day. If we can push 1,000 log entries per second, the math says we should be able to point 86 million desktops at a single logging server. The problem is about 80% of those messages are generated at initial boot time. If everyone typically powers around 9:00 AM, the math changes to a more realistic 750 desktops (again, assuming we can push 1,000 log entries per second over the wire).

So we can't just look at quantity of long entries. We need to take time of day into account as well. This will identify the actual number of log entries per second we can expect under worse case conditions. Worse case is the capacity level we need to plan for.

Deploy centralized logging in phases

If you have tens of thousands of systems to deal with, it is easy to get overwhelmed with the work involved with deploying centralized logging. Rolling out the solution in phases makes it easier to wrap your brain around the whole process.

First, start with a single logging server. You may not be able to cover your whole network, but we have to start somewhere. Large networks should consider a deployment at the corporate office first, moving out to field offices once the corporate system is fully vetted and functional.

You will also want to phase in which devices you are collecting information from. I usually go with the following order:

  1. Network intrusion detection systems
  2. Firewalls
  3. Network hardware (routers, switches, access points, print servers, etc.)
  4. Internet facing servers
  5. Internal servers
  6. Internal desktops

Obviously you can tweak this list to fit your needs. For example if you do not plan on collecting info from desktops, simply leave that step out. I like to start with network intrusion systems first as their log entries are well suited for vetting both daily reports and real time alerting. Once we have a handle on alerting and reporting, adding additional devices becomes far easier.

Exec Yhteenveto

In this post I covered all the things you need to consider when initially deploying a centralized logging solution. We covered how to predict the impact it will have on network utilization, how to calculate the number of hosts per logging server, and why it is important to deploy the solution in phases. In the next post we'll start talking about configuring the centralized logging server. Specifically, we'll look at how we are going to sort log entries.

Perustamalla Security Information Management (SIM) System - Osa 1

08 elokuu 2009

Saan paljon kirjautumalla liittyviä kysymyksiä. Niin paljon, että päätin tehdä sarja miten käyttää kirjautumaan hallintaan. There are some excellent logging resources on the Internet, but they are fragmented in scope and/or vendor specific (usually written by the vendors). Halusin luoda jotain myyjä neutraali, joka pitää oman käden kautta koko prosessin käyttöön log hallintaratkaisun.

Miksi minun pitäisi käyttää turvallisuus tietojen hallintajärjestelmä?

Olkaamme rehellisiä, käyttöönottokustannukset log hallinta on vaikeaa ja tuskallista. Tämä on syy, miksi niin monet järjestelmänvalvojat välttää sitä kuin ruttoa. On vaikea käyttää ja villi Buck suorittamiseksi pitkän aikavälin hallintoa. Weekly matkoja hammaslääkäri luultavasti miellyttävämmäksi.

Kun kaikki, jotka sanoivat, kirjaudu hallinta on luultavasti tehokkain yksittäinen tietoturvaratkaisu voit asentaa. Et voi pudota ja unohda kuten palomuuri, mutta loki johto voi antaa sinulle ainutlaatuisen näkyvyyden sisempi toimintaa verkkoon. Kun sen ei perehdyttäisi suojaustapahtumia saatat muuten kaipaamaan, se tekee kaksinkertainen velvollisuus auttaa vianmäärityksessä viestintä ja järjestelmän kysymyksiä. Hakkuut järjestelmä voidaan resursseja vaativat, mutta se voi myös tarjota erittäin korkea tuotto.

Miksi haluat SIM?

Ennen kuin aloitamme, ensimmäinen kysymys sinun täytyy kysyä itseltäsi, miksi haluat SIM ratkaisu . Haluatko parantaa turvallisuutta tai on siellä noudatetaan eritelmää sinun täytyy noudattaa? Se voi tuntua oudolta haluavat erottaa toisistaan ​​kaksi, mutta vaatimukset ovat hyvinkin erilainen. Standards are far easier (and cheaper) to meet than true security.

Standardeja, kuten PCI-DSS edellyttävät kirjautumista käyttäjä, sovellus ja verkon toimintaa. Kuitenkin ne ovat yleensä hyvin epämääräinen miten tietoja käsitellään. Voit yleensä saada pois pudottamalla musta laatikko, joka tuottaa värikkäitä hallintokertomukset, ja pitää "yhteensopiva". Se ei voi auttaa sinua löytämään että backdoored järjestelmä, joka soittaa kotiin, mutta olet täyttänyt standardin.

Standards tend to focus on the lowest common denominator. Ne on voitava soveltaa moniin eri kohderyhmille, kuten yritykset ilman paljon resursseja. Sen sijaan arvioidaan kunkin organisaation riski ja perustaa vaatimuksia, jotka asetimme bar alhaalla niin se on saavutettavissa pienten ja suurten organisaatioiden keskuudessa.

Myös yksinkertaistaa prosessia, meillä on taipumus keskittyä tarkistuslistoja. Tarkistuslistat ovat viileitä koska he kertomaan sinulle, mitä on tehtävä olevan valituksen. If an auditor can put a checkmark next to all the items, you pass the testing. Ongelmana on tarkistuslistoja keskittyvät oireita, ei itse ongelma.

Minä annan teille hyvä esimerkki. Minulla oli asiakas tuoda Qualified Security Assessor todistamaan niitä PCI-DSS. This was one of my clients running a strict implementation of application control, so they could show a year and a half history of zero Malware infections. Vaikka he varmasti saivat Malware yli, että aikaa, voisimme todistaa, että oli nolla tapauksissa todellisen infektion joka Malware hyökkäys oli heti sisälsi ja poistetaan. Ei monet yritykset voivat hakea vuosittain + nolla haittaohjelmien varalta.

Tilintarkastaja pettänyt heidät. PCI-DSS vaatimuksen # 5 todetaan: "anti-virus ohjelmisto on käytettävä kaikissa järjestelmissä yleisesti suorittaa haittaohjelman". Koska he juoksivat sovellusten hallinta, ei anti-virus, ne katsottiin vaatimustenvastainen. Jos vaatimus 5 oli kirjoitettu määrittää hyväksyttävää kynnystä haittaohjelmien, he varmasti olisivat tavanneet erittely. Kuitenkin riskien arviointi ja mittarit eivät tee helppoa tarkistuslistan kohteita.

Joten jos haluat ottaa käyttöön SIM todella lisätä turvallisuutta omassa ympäristössä, se vie kauemmin ja vaatii enemmän työtä kuin vain kokouksen erittely.

Pitäisikö sinun rakentaa oman SIM?

Olen vakaasti sitä mieltä, että joku harkitsee SIM ratkaisu pitäisi aloittaa rakentamalla omaa. Vaikka on olemassa joitakin ihmisarvoisen kaupallinen SIM ratkaisuja siellä, ne eristää sinut sisäisen teoksia kirjautumalla prosessi. Tämä voi olla hyvä asia, että se säästää aikaa. Ongelmana on, et oppia niin paljon.

Myös log hallinta käyttöönotto on matka. Löydät aikana aikatauluvaatimuksia että vaatimukset voivat muuttua. Tietoja, joita luultiin ensin oli tärkeää, yhtäkkiä ei. Raportit ette edes ajattele, yhtäkkiä hyppää listan kärkeen. Rakentamalla oma järjestelmä sinulla on enemmän joustavuutta tehdä muutoksia lennossa. Jos myöhemmin haluat kaupallinen ratkaisu, olet nyt paremmin tietoa asiakkaan tarpeita ja voi tehdä paremmin arvioida mahdollisuuksia ostaa. Tämä on tärkeää, koska monet log ovat kalliita. Et halua pudottaa paljon rahaa ratkaisu, joka ei tavata pitkän aikavälin tarpeisiin.

I'll give you a good example. Useimmat sivustot olen työskennellyt aluksi ajatella epäonnistuneet kirjautumiset ovat tärkeitä ja haluat nähdä raportit. Se ei vie niitä kauan selvittää nähdä kaikki epäonnistuneet kirjautumiset on täydellistä ajanhukkaa kuin kaikki rasva sormet näppäimistöllä toisinaan. Sitten he ymmärtävät he haluavat kynnyksiä ympäri tiedot. Esimerkiksi he vain haluavat nähdä epäonnistuneet kirjautumiset jos kolme tai useampi epäonnistumisia nähdään viisi sekuntia (osoittaa Automaattinen hyökkäys). Or only show failed logons when multiple logon names are used from the same source IP (indicating a password guessing attack). So by dealing with some information overload, they become better skilled at defining exactly what they wish to see.

Yhteenveto

OK, joten olemme kata määrittelyssä painopiste (turvallisuus Vs. Standardien vaatimus) sekä merkitys alunperin rakentaa oma järjestelmä. Seuraavassa erässä Saan osaksi arkkitehtuuria ja kapasiteetin suunnittelusta.