Per chi volesse apprezzare e rilevare le effettive performance delle schede GPU, anche in ambiente Hyper-V/RDS, un valido aiuto sono i software di test messi a disposizione da UNiGiNE
http://unigine.com/en/products/benchmarks
già le versioni disponibili in licenza grautita consentono di valutare le effettive differenze nell’impiego delle GPU anche in ambienti come RDS con RemoteFX.
Syslog è un protocollo che consente il trasporto di messaggi di log, e di informazione più in generale, è nato all’inizio degli anni ’80 tuttavia è stato definito come RFC dall’IETF soltanto vent’anni dopo. In questo lasso di tempo diverse implementazioni hanno generato differenti “servizi”, la prima RFC che ne documenta il funzionamento è la 3164 mentre una sua evoluzione è descritta dalla RFC 5424
I servizi più comuni che lo utilizzano in ambienti *NIX hanno nome SYSLOG, SYLOG-NG, RSYSLOG ma molti altri prodotti, sia commerciali, che rilasciati sotto licenza Open Source lo implementano al fine di permettere la raccolta di eventi generati da molteplici apparati e sistemi.
Ormai non è affatto raro trovare apparati di rete, firewall, telecamere ma anche prodotti legati al mondo industriale, come ad esempio PLC e controllori di processo più in generale, che implementano il protocollo Syslog al fine di inviare ad un unico collettore i propri eventi di funzionamento.
Struttura del Sylog
Inizialmente implementato sul protocollo UDP, in porta 514 (recenti implementazioni lo rendono disponibile anche in TCP) il pacchetto trasporta le informazioni suddivise in:
Possiamo considerare le Facility come le entità che generano il messaggio di Syslog e ognuna di queste definisce poi una Severity che gradua la “gravità” dell’evento stesso.
Le Facility sono codificate da un numero e si riferiscono a componenti diverse del sistema; kernel, demoni di sistema, autenticazione ecc.
| Cod. | Facility |
| 0 | Kernel messages |
| 1 | User-level messages |
| 2 | Mail system |
| 3 | System daemons |
| 4 | Security/authorization messages |
| 5 | Messages generated internally by Syslogd |
| 6 | Line printer subsystem |
| 7 | Network news subsystem |
| 8 | UUCP subsystem |
| 9 | Clock daemon |
| 10 | Security/authorization messages |
| 11 | FTP daemon |
| 12 | NTP subsystem |
| 13 | Log audit |
| 14 | Log alert |
| 15 | Clock daemon |
| 16 | local0 |
| 17 | local1 |
| 18 | local2 |
| 19 | local3 |
| 20 | local4 |
| 21 | local5 |
| 22 | local6 |
| 23 | local7 |
Le severity seguono la stessa struttura e sono:
| Cod. | Severity |
| 0 | Emergency: System is unusable. |
| 1 | Alert: Action must be taken immediately. |
| 2 | Critical: Critical conditions. |
| 3 | Error: Error conditions. |
| 4 | Warning: Warning conditions. |
| 5 | Notice: Normal but significant condition. |
| 6 | Informational: Informational messages. |
| 7 | Debug: Debug-level messages. |
Un pacchetto Syslog potrà avere per ogni Facility un codice di Severity differente, l’informazione dell’hostname che lo ha generato,l’ora di generazione ed in aggiunta una descrizione ulteriore relativa all’evento.
Syslog è quindi un “mezzo di trasporto” che viene utilizzato da differenti mittenti che classificano i propri messaggi secondo la codifica delle Facility, dipende quindi da ognuno dei servizi che generano messaggi log classificare i propri secondo la struttura del protocollo stesso.
Ad esempio SSHD di default utilizza la facility AUTHPRIV per i suoi messaggi relativi al logon degli utenti e quindi all’interno della configurazione del syslog, relativamente a questa facility, è indicato il percorso del file dove vengono salvati gli eventi.
Configurazione del Servizio Rsyslog su Linux
Su sistemi Linux ( RH,Centos, Oracle Linux) normalmente il demone rsyslog ha il file di configurazione in /etc/rsyslog.conf e la struttura di default prevede il salvataggio in locale dei messaggi che vengono generati dal sistema
#### RULES ####
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console
# Log anything (except mail) of level info or higher.
# Don’t log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages
# The authpriv file has restricted access.
authpriv.* /var/log/secure
# Log all the mail messages in one place.
mail.* -/var/log/maillog
# Log cron stuff
cron.* /var/log/cron
# Everybody gets emergency messages
*.emerg *
# Save news errors of level crit and higher in a special file.
authpriv.* istruisce syslog a salvare tutte le severity di questa facility nel file /var/log/secure, se volessimo differenziare le varie severity in percorsi distinti dovremmo dichiararlo per ognuna
authpriv.info /var/log/file1
authpriv.notice /var/log/file2
ecc.
Redirezione dei messaggi verso un collettore in rete
Come detto in precedenza il protocollo syslog è in grado di trasportare i vari messaggi verso un collettore, ossia un ulteriore syslog che riceve ed archivia.
Per configurare un sistema in modo che invii tutti o solamente alcuni messaggi verso un altro server è sufficiente nel file .conf dichiarare l’host anziché un file locale come visto sopra.
La facility AUTHPRIV archiviata verso l’host 192.168.0.1 diventerà così:
authpriv.* @192.168.0.1
mentre se l’host di destinazione invece che in UDP fosse configurato per ricevere in TCP dovremmo impostare
authpriv.* @@192.168.0.1
ed ancora, se la porta di destinazione dell’host ricevente non fosse la standard 514 ma supponiamo la 25224 TCP dovremmo dichiarare
authpriv.* @@192.168.0.1:25224
Operations Management Suite Agent in Linux
L’agente OMS per Linux quando installato sul sistema si comporta come un ricevitore di messaggi Syslog che poi redirige verso il servizio di log analizer in cloud. Il file di configurazione è in:
/etc/opt/microsoft/omsagent/conf/omsagent.conf
e per impostazione predefinita riceve i messaggi che sono generati localmente al sistema secondo questa configurazione:
<source>
type syslog
port 25224
bind 127.0.0.1
protocol_type udp
tag oms.syslog
</source>
Questo richiede (se si vogliono redirigere eventi Syslog verso il Log Analyzer) che il file di configurazione del Syslog venga modificato in modo da reindirizzare gli eventi sulla porta ed indirizzo su cui è configurato l’agente stesso.
Secondo quanto visto sopra, se volessimo inviare ad OMS i messaggi relativi a SSH configurato per utilizzare la Facility AUTHPRIV, dovremo impostare il file conf di Syslog in questo modo
authpriv.* @127.0.0.1:25224
Modificando ulteriormente la configurazione dell’agente OMS, è possibile fare sì che questo diventi a sua volta un gateway di messaggi raccolti da vari Syslog verso il servizio di Log Analyzer di OMS, impostando omsagent.conf in questo modo:
<source>
type syslog
port 25224
bind 192.168.0.1 ( ip del sistema )
protocol_type udp
tag oms.syslog
</source>
e configurando i vari sitemi ad inviare i messaggi verso l’agente, otterremo il risultato di avere un gateway unico verso OMS senza dover installare ulteriori agenti.
Chiaramente così facendo si perde la possibilità, offerta dall’installazione diretta dell’agente sul sistema, di avere a disposizione ulteriori dati come ad esempio valori di occupazione dischi, ram, cpu etc.
report ottenuto eseguendo il monitoraggio degli accessi in SSH su sistemi linux con le configurazioni descritte sopra
Problemi riscontrati
Durante la configurazione di alcuni sistemi (abbastanza datati) con demone Syslog, non era possibile cambiare la porta di destinazione sia TCP che UDP
Riferimenti
Portale OMS esecuzione di query
OMS agent considerazioni generali
Lo stumento di Microsoft che prende il nome di Operations Management Suite è effettivamente un ambiente molto potente ed articolato che può essere di aiuto per gli amministratori di sistema.
Nella console del portale sono disponibili già preconfigurate una buona serie di query legate alla sicurezza, così come viene eseguito in automatico un “Assesment” del sistema, ad esempio nel mio caso, relativamente ad un Domain Controller, sono sato “avvisato” che questo non aveva le impostazioni di rete corrette per la parte DNS.
Uno strumento molto potente è la ricerca all’interno del mare di eventi che sono archiviati dai vari agent, in questo articolo sono forntite una serie di informazioni ed esempi che possono aiutare molto chi dovesse iniziare con questo strumento.
Personalmente ho voluto realizzare una query che evidenzi tutti gli eventi di logon relativamente ad un gruppo di utenti amministratori il cui nome contiene “_” e due lettere “as”, l’evento codificato per il login di un utente corrisponde all’id 4624 quindi impostando la quey
Type=SecurityEvent AccountType=user Account=*_*as EventID=4624| measure count() as Logons by Account
ho potuto in modo semplice avere in evidenza gli accessi effettuati da questo gruppo di utenti.
Nel caso in cui fosse, come è necessario, rilevare anche i tentativi di accesso falliti, sempre di questo gruppo di utenti, sarà sufficiente modificare la query con l’id evento che viene generato all’atto di un tentativo fallito di login ossia il 4625
Type=SecurityEvent AccountType=user Account=*_*as EventID=4625| measure count() as Logons by Account
se volessimo poi restringere la ricerca agli eventi di questo tipo occorsi nelle utime 6 ore sarà sufficiente modificare le query aggiungendo il seguente “filtro” TimeGenerated>NOW-6HOURS
e la query diventerà così:
Type=SecurityEvent AccountType=user Account=*_*as EventID=4625 TimeGenerated>NOW-24HOURS | measure count() by Account
nel caso in cui si debbano utilizzare caratteri jolly per la ricerca di determinati valori è bene ricordare che questi non possono esssere immessi come parte di una stringa racchiusa tra “” altrimenti verranno interpretati come caratteri oggetto essi stessi di ricerca.
Recentemente nel portale OMS è stata introdotta la possibilità di creare query personalizzate ed organizzarle in un pannello che può essere visualizzato direttamente da console, questo strumento si chiama View Designer e deve essere abilitato dalla gestione delle impostazioni nelle preview
qui sotto è riportato un pannello composto da query personalizzate che può essere utile attivare per il controllo della propria infrastruttura
OMS è valutabile gratuitamente per un periodo illimitato, ma con la limitiazione di conservazione dei dati di 7 giorni e per un massimo di 5oo MB giornalieri di log archiviati
Appunti e note tecniche 