Logok küldése linuxos logszervere

Microsoft Windows

Sziasztok!

Központi logolást kellene megoldanom, a Linuxoknál ez egyszerű és működik, de Windowsra nem találtam ilyen ingyenes log agent-et.
De bármilyen megoldás érdekel a Windowsok központi logolására Linuxra!

  • 2036 megtekintés

( _ventura_ v | 2017. 03. 23., cs – 09:46 )

Valami rémlik hogy a syslog-ng-nek van windows -os agentje.

Fedora 25, Thinkpad x220

Van.
Ha nagyon low budget-bol kell, nem a legszebb megoldas, de:
beregisztralsz teszt-licencre egy SSB-re. (De lehet regisztralni a sylog-ng PE teszt-re is, ha az jobban tetszik)
Emiatt hozza fogsz ferni a syslog-ng pe windowsos agentjehez is.
Letoltod. A windowsos agent nem fizetos, inkabb amolyan kiegeszito szolgaltatas az SSB/PE kozonsegnek.
Ergo, mivel csak tesztlicencre regisztraltal, lesz kvazi legalisan windowsos agented, de supportod nem lesz hozza.

Magyaran, ha fogtal egy bugot, akkor a supporton az egyik elso kerdes ugye az licence aggreemented sorszama... lenne.
Szoval, max. a support team-en mulik, hogy ennek ellenere javitjak-e.
(Jo fejek, ha ertelmesen irsz nekik, segitve oket a problema pontos leirasaval stb, akkor nem lehetetlen. Dolgoztam ott 2 evet!)

De ha javitjak is, es mar lejart a tesztidoszakod, akkor kicsit maceras lessz elerned a frissiteseket...
Amugy meg, egy legkisebb support csomag egy evre valamelyik syslog termekre (ssb, v. syslog-ng pe) nem egy komoly osszeg, foleg ha doboz nelkul kered.

A syslog-ng 7-el nem tudom hogy allnak, ami mar tervezetten teljesen kozos kodbazis lesz a ose verzioval + official binary buildek + par closed source modul.
Ha makod van, akkor a windowsos kliens reszt nem kiganajozzak, hanem ose resz lesz, aztan mar csak avval kell megkuzdj, hogy buildelj magadnak! ;)

Ugy latszik kopnak az emlekek! :)
Elfelejtettem, hogy az agent-bol is van trial build.

Btw.: Mar nem is nagyon emlexem, mi a fenenek voltak a trial buildek, amikor a licencben ugyis ott van az ervenyessegi ido.
Illetve csak sejtem... Dupla ellenorzes, ha valaki trial reggel probal okoskodni, es fizetest megkerulni.

( koqsz | 2017. 03. 23., cs – 15:05 )

A megoldás ELK (Elasticsearch - Logstash - Kibana ).
A Logstas továbbítja a logokat, az Elasticsearch tárolja, a Kibana meg megjeleníti színes-szagos módon webfelületen a dolgokat. Gyors, opensosurce, free.

Arrol a logstash agentrol beszelsz ami TCP protokollon kuldi a cuccot es ha elakad akkor hajlamos 98%-ra felporgetni a procit gyakorlatilag csontra tenni egy prod servert csak mert a tavoli loggolas akadozik ? Amit en ezzel szivok es nem tudok lecserelni policy-miatt azert valakinek a felmenoi naponta csuklanak... En szent eskut tettem hogy soha tobbe logstash...

Tessek :

top - 17:26:46 up 1 min, 1 user, load average: 3.83, 1.16, 0.40
Tasks: 99 total, 2 running, 97 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 10.7 sy, 81.9 ni, 0.0 id, 0.3 wa, 7.0 hi, 0.0 si, 0.0 st
KiB Mem: 1533964 total, 1330764 used, 203200 free, 11664 buffers
KiB Swap: 974844 total, 943396 used, 31448 free. 68176 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
350 logstash 39 19 1439732 130816 8088 S 54.5 8.5 0:23.60 java
349 logstash 39 19 1445104 137756 8056 S 40.9 9.0 0:23.01 java

Magyarazat:
Ez egy adatbazis szerver amit most koltoztetek. A Logstash forward meg nem eri el a Redis szervert tuzfal miatt (ugyanaz mint ha halozatkieses lenne...) Azert probalkozik a lelkem rendesen es pont nem erdekli hogy kiveri a szuszt a CPU-bol...

Hat ez az... :) regi ... De gov.uk es production ... A logstash-forward + konfigja bele van sutve az imagek-be es raadasul tobbszaz hostrol beszelunk PROD-ban kicsit megorokolt spagettis ansible konfigmanagementtel... Nem trivialis a lecsereles... Egyebkent akar az ordog TCP-n loggolni - annal tobbre tartom a stabilitast mint hogy TCP log miatt aggodjak a threadeken...

Biztos hogy * beat-ek jobbak - de amikor te azt irtad hogy logstash+ akkor a logstash forwarder-re es logstash-web -re gondoltam es ramjott a remeges :D

Milyen egyeb valasztasa van?
udp, es vagy eljut valahova a log, vagy nem?

Bar a tcp is eleg tag fogalom.
rfc3164-et kicsit eroszak tcp-n atkuldeni, de nem lehetetlen, csak nem lett sok minden beletervezve. Igazibol tervezve se lett, az rfc3164-et meg megfigyelesek alapjan jegyeztek le.

Ami tervezve lett, az az rfc5424. es 5425, 5426.

Itt mar ki van talalva, hogy ha tls-ben akarod kuldeni, akkor minden egyes log-event payload-ot egy egyszeru framing-nek meg kell eloznie.
Ugyanevvel a buta framinggel ra lehet ultetni nyers tcp-re is a logolast.

Meg ugye van meg az rltp.
De az is tcp felett megy.

Szoval kicsit ilyen fura ez a kerdes.
Ti barmelyik ertelmes megoldast valasztja az ember (ha egyszeruen boolean-kent ertekeled ki a tcp-t mint kerdest, akkor) a valasz True lesz.

UDP vs. TCP-re gondoltam.

Ha a generalt nagy mennyisegu logot csak statisztikailag elemezzuk (pl. webszerver forgalma), akkor abba siman beleferhet az, hogy ha neha (havonta?) nehany package elveszik. Ellenben nem fog a logkuldo "szenvedni" (TCP retransmission + bufferelni az el nem kuldott logot), amig a syslog szerver nem elerheto.

Persze megertem, hogy kellhet a TCP audit jellegu logolashoz.

Egyik oldalrol bena. Sott, kifejezetten ronda.

Masik oldalrol egy szuksegszeru rossz, mert az osszes olyan tarolasi megoldas, ami valamilyen szinten modern elosztott rendszer (logstash, hadoop, kafka), na ezenkel az official kliens rendszerint java-ban van megirva.
Eleg durvan moving target es gyorsan fejlodo teruletek.
Szoval az rsyslog... May work.
Valami verzioval. Es aztan, ami protokollvaltozas van, vagy valami uj pl. auth opciot hozza kell adni, azt hogy kovetik?
Ronda spagetti-kod szemlelet! Szerintem.

( mort234 | 2017. 03. 24., p – 13:02 )

Köszönöm az eddigieket, nézem és tesztelem!
Természetesen nincs rá keret, mert itthon semmi értelmes dologra nincs, főleg ha az IT-s ja és ha hasznos is lehetne.
A linuxos szerverek és a hálózati eszközök szépen logolnak rsyslog > Mysql > Loganalyzer, csak az új Windows szervereket kell rávennem, hogy küldjék a logokat.
Az eddigi tapasztalatok:
- az rsyslog agent (trial 30 day) fizetős és nem jó formátumban küld.
- a syslog-ng fizetős és nem adnak próbaverziót csak úgy, így kipróbálni sem tudtam.
- az nxlog próbáltam, de nem volt megfelelő, mert nem értelmezhető a feletess kollégának :(
- SolarWinds agent-je semmit nem küldött, de szép és sok más toolt is letölthetsz vele.
- a Datagram SyslogAgent-vel megy most, nem mai darab, de free és "értelmezhető".
Nem zárnám le a témát, várom az esetleges további javaslatokat ötleteket!

nxlogon mi nem értelmezhető? (Tudom, a felettesnek, de azért, hátha...)

* Feltelepíted msi-ből az agentet

* 1 db konfig file-ba beállítod az inputot (windows eseménynapló, gondolom ez kell), meg az outputot (gondolom vmi tcp socket)

* + ha kell, parszolsz, ehhez kb. a reg. kifejezéseket kell ismerni

Itt van hosszabb, rövidebb példa is:
https://gist.github.com/stuart-warren/6726081

+gugliban ezer

Amit írtam miért nem jó?
100+ Win szerver küldi vele a logjait CentOS 7-es rsyslog-nak (onnan logstash -> elastic -> kibana)

Plusz egy szerveren beállítod, kiexportálod a reg file-t (a konfigurátora megcsinálja neked) és a többi Win-en már csak install + reg import + service restart.

( zeller | 2017. 03. 24., p – 14:49 )

Splunk forwarder-t már több esetben használtam, és teljesen jól át tudja tolni a logokat, akár rsyslog, akár syslog-ng, akár ssb, akár splunk felé.