Mayo 18

wannacry-vaccine.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskdl.exe]
"Debugger"="taskkill /F /IM "

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskse.exe]
"Debugger"="taskkill /F /IM "

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\wannacry.exe]
"Debugger"="taskkill /F /IM "

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\mssecsvc.exe]
"Debugger"="taskkill /F /IM "

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\tasksche.exe]
"Debugger"="taskkill /F /IM "

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskhsvc.exe]
"Debugger"="taskkill /F /IM "

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\wcry.exe]
"Debugger"="taskkill /F /IM "

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\111.exe]
"Debugger"="taskkill /F /IM "

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\lhdfrgui.exe]
"Debugger"="taskkill /F /IM "
Category: TIPS AND TRICKS | Los comentarios están deshabilitados en wannacry-vaccine.reg
Mayo 17

Use NMAP to Scan network for WCRY or WannaCry Ransomware vulnerability

  1. If you havent already got it, download and install NMAP from https://nmap.org/
  2. Download the script from https://github.com/cldrn/nmap-nse-scripts/blob/master/scripts/smb-vuln-ms17-010.nse
  3. Save it to Nmap NSE script directory
    1. Windows location is C:\Program Files (x86)\Nmap\scripts
    2. Linux – /usr/share/nmap/scripts/ or /usr/local/share/nmap/scripts/
    3. OSX – /opt/local/share/nmap/scripts/
  4. Test the script on a known vulnerable device such as 202.157.185.31 or 64.17.101.90
    1. nmap -sC -p 445 -max-hostgroup 3 -open -script smb-vuln-ms17-010.nse 64.17.101.90
  5. Run against your enviroment

Starting Nmap 7.40 ( https://nmap.org ) at 2017-05-15 10:30 South Africa Standard Time
Nmap scan report for ns.bvtsvc.com (64.17.101.90)
Host is up (0.22s latency).
PORT STATE SERVICE
445/tcp open microsoft-ds

Host script results:
| smb-vuln-ms17-010:
| VULNERABLE:
| Remote Code Execution vulnerability in Microsoft SMBv1 servers (ms17-010)
| State: VULNERABLE
| IDs: CVE:CVE-2017-0143
| Risk factor: HIGH
| A critical remote code execution vulnerability exists in Microsoft SMBv1
| servers (ms17-010).
|
| Disclosure date: 2017-03-14
| References:
| https://technet.microsoft.com/en-us/library/security/ms17-010.aspx
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0143
|_ https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/

Nmap done: 1 IP address (1 host up) scanned in 4.63 seconds

Category: TIPS AND TRICKS | Los comentarios están deshabilitados en Use NMAP to Scan network for WCRY or WannaCry Ransomware vulnerability
Mayo 17

Close ports 135 and 445

According to the reports of antivirus companies, wcrypt penetrates computers through SMB (Server Message Block) ports. To prevent penetration, we block the ports 135 and 445 through which the virus penetrates (in most cases they are not used by ordinary users).

To do this, open the console with administrator rights (cmd.exe -> run as administrator). And we execute in turn 2 commands (after each command there should be status OK).

netsh advfirewall firewall add rule dir=in action=block protocol=TCP localport=135 name=”Block_TCP-135″

netsh advfirewall firewall add rule dir=in action=block protocol=TCP localport=445 name=”Block_TCP-445″

 

Disabling SMBv1 support

 

The vulnerability can also be closed by completely disabling SMBv1 support. Run this command in cmd (run as administrator).

dism /online /norestart /disable-feature /featurename:SMB1Protocol

Category: TIPS AND TRICKS | Los comentarios están deshabilitados en Close ports 135 and 445
Diciembre 23

Insert an iptables rule on a specific line number with a comment, and restore all rules after reboot

# First get the iptables list with the line numbers enabled
$ iptables -nL --line-numbers

# Look up the line number you want to use (the exisitng rule will shift down) and insert your rule
$ iptables -I INPUT {LINE_NUMBER} -i eth1 -p tcp --dport 21 -s 123.123.123.123 -j ACCEPT -m comment --comment "This rule is here for this reason"

# Aftarwards i always save my rules to a file in etc so i can reload them at the next reboot
$ iptables-save > /etc/iptables.local

# (To do this, add the following rule to your /etc/rc.local file)
/sbin/iptables-restore < /etc/iptables.local
Category: TIPS AND TRICKS | Los comentarios están deshabilitados en Insert an iptables rule on a specific line number with a comment, and restore all rules after reboot
Diciembre 15

CAMBIAR TECLADO DE LA CONSOLA DE UBUNTU A ESPAÑOL

Quien mas quien menos, alguna vez ha tenido que ponerse con la consola conectada a un servidor y se ha topado con que el layout del teclado esta en ingles, es decir, donde va la ñ sale un punto y coma y para sacar la / tenemos que pulsar en –

Esto después de años pues es molesto la primera vez cuando te lo encuentras pero ya tienes memorizada la disposición del teclado americano y tardas 2 segundos en cambiar el chip. Sin embargo si tienes que trabajar y reiniciar varias veces la maquina, terminas cansándote de cambiar el chip mentalmente e incluso del

El truco aquí es ir a elegir en la primera pantalla de selección Generic 102 (intl) keyboard, tras lo cual nos preguntara el origen del teclado y podremos elegir Spain. El resto de opciones podemos dejarlos tal cual se nos presentan.

Otra cosa que podemos encontrarnos es el teclado en una distribución azerty,dvorak, etc (la primera fila de teclas de arriba a la derecha, bajo los números, puede no ser, segun el pais, qwerty)

En ese caso, instalaremos console-data y lo reconfiguraremos con

Category: TIPS AND TRICKS | Los comentarios están deshabilitados en CAMBIAR TECLADO DE LA CONSOLA DE UBUNTU A ESPAÑOL
Diciembre 1

rename username and group for any linux

 

Under Linux, the usermod command changes user names. It modifies the system account files to reflect the changes that are specified on the command line.

To change just the username:

<code>usermod -l new_username old_username
</code>

To change the username and home directory name:

<code>usermod -l new_username -m -d /new/home/dir old_username
</code>

You may also want to change the name of the group associated with the user:

<code>groupmod -n new_username old_username</code>
Category: TIPS AND TRICKS | Los comentarios están deshabilitados en rename username and group for any linux
Noviembre 25

How to fix no public key available for the following key IDs in debian

On new debian servers, upon attempting to apt-get update you may see the following error

root@myserver:~# apt-get update
Get:1 http://security.debian.org wheezy/updates Release.gpg [1571 B]
Get:2 http://security.debian.org wheezy/updates Release [102 kB]
Get:3 http://ftp.debian.org wheezy Release.gpg [2390 B]
....
Reading package lists... Done
W: There is no public key available for the following key IDs:
9D6D8F6BC857C906
W: There is no public key available for the following key IDs:
7638D0442B90D010

The easiest way i’ve found to solve this problem is to do the following.

apt-get install debian-keyring debian-archive-keyring

Try to update again

apt-get update
Category: TIPS AND TRICKS | Los comentarios están deshabilitados en How to fix no public key available for the following key IDs in debian
Octubre 13

Como testear o probar un servidor syslog remoto en Linux

Muy seguramente muchos SysAdmin, nos ha tocado alguna vez, instalar y configurar un servidor rsyslog, a donde lleguen todos los logs de diferentes servicios y servidores, es decir, un servidor que recolecte de forma centralizada  todos los archivos logs de diferentes equipos. Y por que hacer esto? Principalmente hacerlo por seguridad y facilitar la administracion.

Ahora muchos se estaran preguntando por seguridad es necesario centralizar los logs? y la respuesta es si. Si. un atacante logra comprometer un servidor y los logs se almacen en el mismo, pues muy facilmente el atacante podra modificar dichos logs a su gusto para complicarnos mucho mas la tarea de descubrir como fue que vulneraron dicho servidor. por tal motivo siempre se recomienda enviar los logs a otro servidor

Ahora, despues de hacer todo el proceso de instalacion y configuracion, abrimos los archivos de logs, pero alguna veces no empieza a loguear, y nos preguntamos. ¿Donde esta el problema? en el servidor log, o en el dispositvo el cual es el encargado de enviar los logs? Para resolver esta inquietud y darnos una idea de donde esta el problema, podemos hacer una prueba muy sencilla, solo basta con enviar un pequeño mensaje al puerto donde esta escuchando rsyslog usando netcat:

nc -w1 -u ip_syslog  puerto <<< “Probando servidor syslog.. mensaje enviado desde mi maquina local”

Si nuestro servidor rsyslog esta bien configurado, despues de ejecutar la prueba anterior, al abrir los archivos de log debera aparecer el mismo mensaje:

probar syslog

De ser la prueba exitosa quiere decir que el problema radica en el equipo el cual es el encargado de enviar los logs, y se debe revisar la configuracion de dicho equipo para que envie los logs adecuadamente al servidor de logs remotos. Si por el contrario el mensaje no llega correctamente, deberas revisar la configuracion de tu servidor de logs.

Category: TIPS AND TRICKS | Los comentarios están deshabilitados en Como testear o probar un servidor syslog remoto en Linux
Septiembre 28

Creating and Using your own Repository

Custom repositories leverage package management solutions, which were designed to provide a convenient, efficient means to install software on many computers. This topic describes how to create a local package repository and then how to direct machines in your environment to use that repository.

To create a repository, you simply put the RPMs or DEBs you want to host in one directory. Then complete tasks with createrepo or reprepro, and then publish the resulting repository on a website.

Step 1: Download Installation Files

Creating a custom repository requires RPM or DEB files. If you already have these files, proceed to the next step. Otherwise, download the appropriate versions of Cloudera Manager. Available versions can be found at Cloudera Manager Version and Download Information.

Step 2: Prepare the RPM or DEB Files

Move the RPMs or DEBs to a directory that you will use for your repository. Suppose you have downloaded the Oracle JDK and want to host it internally to ease installation on various machines. After you have unpacked the RPMs or DEBs, you would have a collection of those files in your directory. For example, for a CentOS system, you might have:

$ls -l
total 79392
-rw-r--r-- 1 user group 70530937 Mar 13 14:42 jdk-6u24-linux-amd64.rpm
-rw-r--r-- 1 user group   499375 Mar 13 14:42 sun-javadb-client-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group    14627 Mar 13 14:42 sun-javadb-common-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group  4080625 Mar 13 14:42 sun-javadb-core-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group   969861 Mar 13 14:42 sun-javadb-demo-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group  4865183 Mar 13 14:42 sun-javadb-docs-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group   201273 Mar 13 14:42 sun-javadb-javadoc-10.6.2-1.1.i386.rpm

Step 3: Create a Repository

You can using createrepo or reprepro to create a repository. If you don’t have createrepo or reprepro installed, install it using the following command:

  • RedHat/CentOS: yum install createrepo
  • SLES: zypper install createrepo
  • Debian/Ubuntu: apt-get install reprepro

Creating a CentOS/RHEL/Oracle/SLES Repository

Having expanded the RPMs to a directory and ensured createrepo is installed, you can now create a repository. When you run createrepo in the directory that contains the files you will use to create a repo, the program creates an extra directory with some XML files that describing the repository. For example:

$ createrepo .
7/7 - sun-javadb-javadoc-10.6.2-1.1.i386.rpm                                    
Saving Primary metadata
Saving file lists metadata
Saving other metadata
$ ls -l
total 79400
-rw-r--r-- 1 user group 70530937 Mar 13 14:42 jdk-6u24-linux-amd64.rpm
drwxr-xr-x 2 user group     4096 Mar 13 14:45 repodata/
-rw-r--r-- 1 user group   499375 Mar 13 14:42 sun-javadb-client-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group    14627 Mar 13 14:42 sun-javadb-common-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group  4080625 Mar 13 14:42 sun-javadb-core-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group   969861 Mar 13 14:42 sun-javadb-demo-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group  4865183 Mar 13 14:42 sun-javadb-docs-10.6.2-1.1.i386.rpm
-rw-r--r-- 1 user group   201273 Mar 13 14:42 sun-javadb-javadoc-10.6.2-1.1.i386.rpm
$ ls -l repodata/
total 64
-rw-r--r-- 1 user group 32997 Mar 13 14:45 filelists.xml.gz
-rw-r--r-- 1 user group   482 Mar 13 14:45 other.xml.gz
-rw-r--r-- 1 user group  2429 Mar 13 14:45 primary.xml.gz
-rw-r--r-- 1 user group   951 Mar 13 14:45 repomd.xml

After this command completes, the specified RPMs have been added to your private repository.

  Note:

Over time, you may need to install multiple versions Cloudera software. To achieve this, you may need to update repository information. Do not create a situation where there are multiple repo files that package management tools could use to install Cloudera software. Either overwrite existing repo files with the new information or create a new repo file and delete the old one. If your machines have multiple repo files, installations may not complete as expected.

Creating a Debian/Ubuntu Repository

Having expanded the DEBs to a directory and ensured reprepro is installed, you can now create a repository.

To create a Debian/Ubuntu repository:

Create a directory that will host the repository and creating a configuration directory and file. The repo directory can have any location and name. The configuration directory must be named conf and be at the root level of the repository directory you create. For example:

$ mkdir /tmp/repo
$ mkdir /tmp/repo/conf

Create a configuration file that contains basic information about the repository. For example, after creating such a file, you could check its contents as follows:

$ cat /tmp/repo/conf/distributions
Origin: Cloudera
Label: Cloudera
Suite: stable
Codename: cloudera
Version: 0.1
Architectures: i386 amd64 source
Components: contrib
Description: Cloudera

Run reprepro on DEB files. If you had expanded the DEBs to the /tmp/repo/ directory, you might use the following command:

$ find /tmp/repo -name \*.deb -exec reprepro -Vb repo includedeb cloudera {} \;

After this command completes, the specified DEBs have been added to your private repository.

Step 4: Install a Web Server

The repository is typically hosted using HTTP on a machine inside your network. If you already have a web server in your organization, you can move the repository directory, which will include both the RPMs and the repodata/ subdirectory, to some a location hosted by the web server. If you are able to use an existing web server, then note the URL and skip to Modifying Clients to Find Repos.

An easy web server to install is the Apache HTTPD.

To install Apache HTTPD:

Install Apache HTTPD. You may need to respond to some prompts to confirm you want to complete the installation. For RedHat/CentOS:

[root@localhost yum.repos.d]$ yum install httpd

For SLES:

[root@localhost zypp]$ zypper install httpd

For Debian/Ubuntu:

[root@localhost apt]$ apt-get install httpd

Start Apache HTTPD: For RedHat

[root@localhost tmp]$  service httpd start
Starting httpd:                                            [  OK  ]

For SLES

[root@localhost tmp]$ service apache2 start
Starting httpd:                                            [  OK  ]

For Debian/Ubuntu

[root@localhost tmp]$ service apache2 start
Starting httpd:                                            [  OK  ]

Step 5: Publish Repository Files

Move your files to the web server directory and modify file permissions. For example, you might use the following commands:

[root@localhost tmp]$ mv /tmp/repo /var/www/html
[root@localhost tmp]$ chmod -R ugo+rX /var/www/html/repo

After moving files and changing permissions, visit http://<hostname>:80/repo to verify that you see an index of files. Note that Apache may have been configured to not show indexes, which is also acceptable.

Modifying Clients to Find Repos

Having established the repository, modify the clients so they find the repository.

For RedHat/CentOS systems: Create files on client systems with the following information and format, where hostname is the name of the web server you created in the previous step:

[myrepo]
name=myrepo
baseurl=http://hostname/repo
enabled=1
gpgcheck=0

See man yum.conf for more details. Put that file into /etc/yum.repos.d/myrepo.repo on all of your host machines to enable them to find the packages that you are hosting.

For SLES systems: Use the zypper utility to update client system repo information by issuing the following command:

$ zypper addrepo http://hostname/repo alias

For Debian/Ubuntu systems: Add a new list file to /etc/apt/sources.list.d/ on client systems. For example, you might create the file /etc/apt/sources.list.d/my-private-cloudera-repo.list. In that file, create an entry to your newly created repository. For example:

$ cat /etc/apt/sources.list.d/my-private-cloudera-repo.list
deb http://hostname/repo cloudera

After adding your .list file, ensure apt-get uses the latest information by issuing the following command:

$ sudo apt-get update

After completing these steps, you have established the environment necessary to install a previous version of Cloudera Manager or install Cloudera Manager to machines that are not connected to the Internet. Proceed with the installation process, being sure to target the newly created repository with your package management tool.

Category: TIPS AND TRICKS | Los comentarios están deshabilitados en Creating and Using your own Repository
Septiembre 5

Centralisez vos logs avec Rsyslog

I. Présentation

La centralisation des logs de plusieurs serveurs sur un seul peut présenter un grand intérêt au niveau de la sécurité au sein d’un système d’information. En effet, il est plus facile pour des outils d’analyse de logs de comparer, lire et scanner des fichiers se situant sur un seul et unique serveur plutôt que de le faire à distance ou via des agents distants. De plus en cas de crash serveur, vous serez capable de récupérer les erreurs et actions menées sur votre serveur avant que celui-ci ne crash, facilitant ainsi la remise en activité de celui-ci et sa sécurisation future.

Par défaut sur la plupart des Linux modernes, l’outil de gestion des logs est Rsyslog, c’est celui-ci que nous allons utiliser dans ce tutoriel. Nous travaillerons sur deux machines sous Debian 7, l’un faisant office de serveur, l’autre de « client » qui enverra ses logs sur le serveur. Dans les deux cas, le fichier de configuration à modifier est toujours « /etc/rsyslog.conf« . On peut néanmoins  en mettre dans « /etc/rsyslog.d/ » puis faire un « include » dans le fichier de configuration principale pour importer.

 

II. Configuration du serveur

Pour le serveur, il faut simplement paramétrer le serveur pour qu’il accepte les logs venant de l’extérieur en ouvrant le port adéquate, on va pour l’instant par soucis de simplicité ouvrir le port UDP (514). Pour cela, on va décommenter les deux lignes suivantes :

$ModLoad imudp
$UDPServerRun 514

On pourra alors redémarrer le service rsyslog :

service rsyslog restart

Pour vérifier que notre serveur est bien à l’écoute, on peut effectuer la commande suivante :

netstat -npul

On verra alors notre port 514 ouvert en UDP :

serveur rsyslog linux

Port 514 ouvert en UDP sur notre serveur Rsyslog

III. Configuration du client

Au niveau du client, il faut aller dans ce même fichier puis, pour rediriger tous les logs sur le serveur, ajouter cette ligne à la fin du fichier :

*.* @IP_SERVER:514

Note : Le « @ » doit figurer dans la ligne

On va alors redémarrer notre service rsyslog :

service rsyslog restart

Puis on pourra générer des logs (redémarrer un service quelconque par exemple) et aller voir s’ils figurent sur le serveur rsyslog. Par défaut comme nous l’avons fait, les logs des clients se situeront dans le même fichier que les logs du serveur donc par exemple dans le « /var/log/syslog » du serveur. Vous verrez simplement que le nom de l’hôte ayant généré la ligne de log n’est pas celui du serveur mais celui du client.

III TCP/UDP

Nous avons précédemment configuré notre client et notre serveur pour échanger en utilisant le protocole de transport (couche 4) UDP. Brièvement, UDP permet un échange unique pour transmettre un paquet, c’est un protocole qui ne cherche pas à se synchroniser, à suivre l’état des paquets ou des échanges entre deux éléments actifs. Au contraire, TCP va chercher à savoir pour chaque paquet si celui-ci a bien été reçu par le correspondant, ce qui engendre des paquets supplémentaires par rapport à UDP. TCP est ainsi capable de savoir si un échange ou une information n’a pas été reçu et de la retransmettre au besoin, ce que ne fait pas UDP.

Tout cela pour souligner que dans notre cas, les échanges TCP ont un désavantage qu’il faut prendre en compte par rapport à l’UDP. En effet, le TCP va générer plus d’échanges (et donc de consommation de ressource) par rapport à UDP mais va vous assurer que les informations reçu le sont dans le totalité. Il y a donc un choix à faire qui dépend de vos ressources disponibles et du nombre de client et d’informations gérées par votre serveur. Pour mettre les échanges en mode TCP, il faut recommenter ces lignes dans le fichier de configuration serveur, à noter que les deux méthodes peuvent cohabiter si on les met sur des ports différents, par exemple :

Serveur Rsyslog

Configuration du serveur Rsyslog pour recevoir les logs des clients en UDP sur le port 514 et en TCP sur le port 1514

Sinon, il faudra commenter les deux lignes supérieures. Côté client, il faut ajouter cette ligne dans la configuration pour que les échanges s’effectuent en TCP :

*.* @@IP_SERVEUR:1514

Note : Les @@ doivent figurer dans la ligne de commande, le fait qu’il y en ai deux indique que les échanges se feront en TCP.

On peut laisser également deux lignes pour indiquer que les logs seront envoyés une fois en TCP et une fois en UDP. Cela présente peu d’intérêt mais permet de comprendre que l’on peut également envoyer nos logs sur plusieurs serveurs différents si on change l’IP d’une des deux lignes. On va ensuite redémarrer le serveur ainsi que le client si besoin :

service rsyslog restart

 IV. Rediriger ou copier selon la facilitie ou la priorité

Sous Linux quand on parle de gestion de logs, les facilites sont des catégories dans lesquelles les logs vont se « ranger » afin de mieux les archiver et les trier. Parmi ces facilites, on retrouve par exemple :

  • auth : Utilisé pour des évènements concernant la sécurité ou l’authentification à travers des applications d’accès (type SSH)
  • authpriv : Utilisé pour les messages relatifs au contrôle d’accès
  • daemon : Utilisé par les différents processus systèmes et d’application
  • kern : Utilisé pour les messages concernant le kernel
  • mail :  Utilisé pour les évènements des services mail
  • user : Facilitie par défaut quand aucune n’est spécifiée
  • local7 : Utilisé pour les messages du boot
  • * : Désigne toutes les facilities, par soucis de simplicité c’est ce que nous avons spécifié lors de notre première règle de redirection des logs un peu plus haut
  • none : Désigne aucune facilites

En plus de ces facilites, nous retrouvons pour chaque facilities un niveau de gravité (appelé Priorité) qui va du plus grave à la simple information :

  • Emerg : Urgence, système inutilisable
  • Alert : Alerte. Intervention immédiate nécessaire
  • Crit : Erreur système critique
  • Err : Erreur de fonctionnement
  • Warning :  Avertissement
  • Notice : Évènement normaux devant être signalé
  • Info : Pour information
  • Debug : Message de debogage

On retrouve alors plusieurs façons de spécifier les logs qui nous intéressent et donc ceux que l’on va rediriger. Par exemple si l’on chercher à rediriger vers notre serveur de logs 192.168.19.145 uniquement les messages critiques et supérieurs concernant les mails sur le port UDP 514, on ajoutera la ligne suivante :

mail.err @192.168.19.145:514

On peut également rediriger tous les logs mails :

mail.* @192.168.19.145:514

On peut également saisir en une ligne plusieurs types de facilities et de priorité, on trouve pas exemple dans le fichier de configuration par défaut des lignes comme celles-ci :

*.=debug;\
       auth,authpriv.none;\
       news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
       auth,authpriv.none;\
       cron,daemon.none;\
       mail,news.none          -/var/log/messages

On voit ici que toutes les priorités debug sont redirigées vers le fichier « /var/log/debug » et que toutes les prioritésinfo,notice et warn seront dans « /var/log/messages« . Pour que ces filtres soient redirigés vers le serveur de logs, il suffit de spécifier l’IP du serveur ainsi que son port comme fait plus haut à la place du nom du fichier.

V. Rediriger les logs vers un dossier/fichier par host

On peut également, pour faciliter la hiérarchisation et l’archivage de nos logs lorsque l’on a un grand nombre de client Rsyslog utiliser une arborescence avec un dossier/fichier par hôte plutôt que de mettre tous les logs dans le même fichier que le serveur de logs. On va pour cela utiliser une template que nous mettrons après le bloc « RULES » dans le fichier de configuration du serveur :

$template syslog,"/var/log/clients/%fromhost%/syslog.log"

On va ensuite appliquer ce template à tous les logs entrants :

*.* ?syslog

Il nous suffira ensuite de redémarrer notre service rsyslog puis de générer des logs depuis les clients. On se retrouvera alors avec un dossier « /var/log/clients/ » contenant un dossier par IP/nom client et contenant respectivement un fichier « syslog.log » avec les logs de chaque client respectif, ce qui simplifie la recherche d’information dans les logs d’un client précis

Category: TIPS AND TRICKS | Los comentarios están deshabilitados en Centralisez vos logs avec Rsyslog