[ CoyoteKG @ 18.03.2019. 11:11 ] @
Namestio sam neki ELK i dobijam logove od nekog firewall-a, ali su u pitanju ES indeksi po par GB dnevno.

Sa Curator-om sam namestio da briše indekse starije od 30 dana.

Ovo je config fil

Code:
actions:
  1:
    action: delete_indices
    description: >-
      Delete indices older than 30 days (based on index name), for logstash-
      prefixed indices. Ignore the error if the filter does not result in an
      actionable list of indices (ignore_empty_list) and exit cleanly.
    options:
      ignore_empty_list: True
      timeout_override:
      continue_if_exception: False
      disable_action: False
    filters:
    - filtertype: pattern
      kind: regex
      value: '^(panos-traffic-|panos-threat-|panos-system-|panos-config-).*$'
      exclude:
    - filtertype: age
      source: name
      direction: older
      timestring: '%Y.%m.%d'
      unit: days
      unit_count: 30
      exclude:


ali bih hteo i da ih arhiviram nekako pre nego što se obrišu. I da bude jednostavno uraditi restore tih indeksa po potrebi.

Kako vi rešavate ovo?
[ nkrgovic @ 18.03.2019. 11:29 ] @
Ja nikako, ali sam imao drugu strategiju koju bi spomenuo - mozda bude od koristi:

Sustina je bila da u elastic-u treba da stoje logovi za trenutnu obradu i analitike - u sustini to je :

1) Ono na sta reagujes nekim drugim sistemom (tipa splunk)
2) Ono sto zelis da proveris kako radi - tj. ono sto ti crta kibana

Sve ostalo je za arhivsku, tj. za neku detaljniju analizu. A kako detaljna analiza obicno ne ide iz elastica, meni je bilo dovoljno dobro da ih shipujem negde drugde.

Sustinski strategija je bila :

1) Ship to elastic, kao i ti, uz brisanje posle mesec dana
2) Ship also to long-term storage, za analize.

Ovo long term je zavisilo od toga gde se radi hosting, ali obicno je bio S3.

Tj. radis sto i do sad, samo namestis da se paralelno shipuje u S3. :) Kad to radis od odma (a ne na trenutnku arhiviranja) dodatna prednost je da analitike imaju takodje pristup od odma.
[ CoyoteKG @ 18.03.2019. 12:05 ] @
Citat:
2) Ship also to long-term storage, za analize.


Nisam shvatio.
To čuvaš u nekom izvornom formatu, tipa txt fajl? Pa analiziraš ručno gledajući zapise ako zatreba?

Mislio sam da je ideja da se analizira sve pomoću ELK.
[ nkrgovic @ 18.03.2019. 16:30 ] @
Da, zapravo najcesce tab separated. :)

ELK je za GUI, ne za duboke analize... bar u mojim slucajevima. Generalno:

- Kad mi treba da vidim sta je bilo, ELK je super. Brzo, jednostavno.
- Kad mi treba detaljna analiza, to tesko ide kroz ELK, to obicno cimam nekog iz data team-a, oni pisu svoj python, pale Hive ili sta vec - i onda je tab separated ziva zgoda. :)

Sve zavisi sta hoces da analiziras, ali, generalno, ako ti treba nesto in-depth kroz duzi period vremena, pa korelisano sa nekom drugom datom, onda je zgodnije neki drugi alat. Opet, to je za stvari tipa web logs, ne za tvoj use case.

Doduse, za tvoj use case je veliko pitanje da li ti ikad treba ista duze od 30 dana, osim za compliance - a za compliance je zgodno nesto read only. Ko gleda firewall logove od pre 6 meseci, ali realno - osim ako ne istrazujes incident od pre 6 meseci.... a u tom slucaju, cinjenica da je text file ti je najmanji problem.
[ CoyoteKG @ 18.03.2019. 21:48 ] @
Ja sam se oduševio sa ELK jer za čas pronađem ono što treba. Čak da ni ne koristim nikakav dashboard ili visualization, nego direktno iz Discoverer-a kad je dobro isparsiran log za čas nađem. Mogu i po nekom određenom vremenskom periodu.

Ovo za firewall ne gledam ja, nego kolega koji je zadužen za security, njemu vidim priličo znači.

Pa mi je palo na pamet da sve provlačim kroz ELK, nego deluje da je to mnogo GB :D

No nemam još nekog forenzičkog iskustva, nisam imao neke preterane potrebe da izvlačim iz logova nešto specifično.
I kad god sam to radio, brljanje po log fajlovima, grepovanje ili awkovanje mi je uvek zamorno zato pomislih da je ELK sjajno rešenje.
[ nkrgovic @ 19.03.2019. 15:07 ] @
Ja se generalno slazem sa svim sto si rekao, jedino sto elastic ima limit u velicini java heap-a, negde oko 62GB RAM-a, pa kad ti indexi (ne indices nego njihovi indexi) predju tu cifru, onda ne valja....

Ali ja samo razmisljam o tome: sta ce ti security data stara 6 ili 12 meseci? Realno? Ako ti treba, onda trazis nesto korelirano, ne jedan red. A onda ces, verovatno, pisati neki kod - pa ces sve jedno da parsiras... plus, ako ti treba retko, onda imas razlog vise da je ne drzis u redovnim podacima da smara - i da imas resursa, nisu besplatni.

Vidi da ti kolega definise koliko mu vremena treba, onda to drzi u elasticu, a ostatak, sve jedno treba da cuvas i kopiju u izvornom obliku... ;)
[ CoyoteKG @ 20.03.2019. 07:51 ] @
Sve jasnoi argumentovano, pro si :).
Sve što zagrebem i pitam ovde, ti već odavno kidaš :D

Hvala :)