Question / Réponses

Cet article traite des questions globales sur l’utilisation d’OSSEC et des agents.

les règles, écriture de nouvelles règles

Prochaine étape : gérer les règles : les lister, les éditer, historiser les changements effectués et permettre de revenir en arrière. C’est ambitieux, mais il va y avoir un réel avantage dans l’interface utilisateur, c’est par là que pèchent les outils habituels, d’où confusion et perte de temps.

Il faudra aussi pouvoir gérer un whitelistage (ou au contraire une augmentation du niveau d’alerte) en fonction de agent/id/srcip. Par exemple, l’alerte ossec-server/5715/164.132.107.166 correspond à l’interrogation par PRTG. Aucun intérêt évidemment.

Ossec et les firewalls

Report Windows Firewall events through Event Channel

Windows Event Channel monitoring in OSSEC is the modern version of Event Log, and unlike this, Event Channel allows you to make queries in order to filter events. In this case we will configure OSSEC to monitor events that log when the Windows Firewall has been started or stopped, and when a rule has been created, modified or removed.
Identifying Windows Firewall events

ID 2003 : The firewall was activated for a profile.
ID 2004 : A new rule was created.
ID 2005 : A rule was modified.
ID 2006 : A rule was deleted.

Configuring the Windows agent

We want to filter every event whose ID is between 2003 and 2006. So, we go to the installation directory of OSSEC, edit the file “ossec.conf”, and add the following lines :

       
<ossec_config>
 <localfile>
   <location>Microsoft-Windows-Windows Firewall With Advanced Security/Firewall</location>
   <log_format>eventchannel</log_format>
   <query>Event/System[EventID \>= 2003 and EventID \<= 2006]</query>
 </localfile>
</ossec_config>

Note that we escaped the symbols ‘<‘ and ‘>’, since there are used to delimit the XML tags. It’s necessary to restart the agent for the changes to take effect.

Creating a rule in the manager

Generally, rules in OSSEC require decoders to extract some fields from logs. In this case, OSSEC brings a decoder called “windows” that filters logs from Windows.

Windows logs referred to information events match the rule 18101, defined at file “rules/msauth_rules.xml”. We will edit this file “rules/local_rules.xml” and insert the following rules as children of the rule 18101 :

       
<rule id="100002" level="0">
 <if_sid>18101</if_sid>
 <id>2003</id>
 <description>Firewall configuration changed</description>
</rule>

<rule id="100003" level="3">
 <if_sid>100002</if_sid>
 <regex>Type: Enable \.* Value: Yes</regex>
 <description>Firewall enabled for private/domain profile</description>
</rule>

<rule id="100004" level="3">
 <if_sid>100003</if_sid>
 <regex>Public profile</regex>
 <description>Firewall enabled for public profile</description>
</rule>

<rule id="100005" level="3">
 <if_sid>100002</if_sid>
 <regex>Type: Enable \.* Value: No</regex>
 <description>Firewall disabled for private/domain profile</description>
</rule>

<rule id="100006" level="4">
 <if_sid>100005</if_sid>
 <regex>Public profile</regex>
 <description>Firewall disabled for public profile</description>
</rule>

<rule id="100007" level="3">
 <if_sid>18101</if_sid>
 <id>2004</id>
 <description>Firewall rule created</description>
</rule>

<rule id="100008" level="3">
 <if_sid>18101</if_sid>
 <id>2005</id>
 <description>Firewall rule modified</description>
</rule>

<rule id="100009" level="3">
 <if_sid>18101</if_sid>
 <id>2006</id>
 <description>Firewall rule deleted</description>
</rule>

After that, we must restart the manager in order to apply these changes.
Generating alerts

To test our new rules, we need to disable and re-enable the Windows Firewall, or create a rule, and read the last alerts from OSSEC’s “alerts.log” :

   $ tail -n 20 /var/ossec/logs/alerts/alerts.log

   ** Alert 1462555630.4574541: – local,syslog,
   2016 May 06 19:27:10 (wserver) any->WinEvtLog
   Rule: 100006 (level 4) -> ‘Firewall disabled for public profile’
   User: LOCAL SERVICE
   2016 May 06 17:27:45 WinEvtLog: Microsoft-Windows-Windows Firewall With Advanced Security/Firewall: INFORMATION(2003): Microsoft-Windows-Windows Firewall With Advanced Security: LOCAL SERVICE: NT AUTHORITY: WIN-UENN0U6R5SF: A Windows Firewall setting in the Public profile has changed. New Setting: Type: Enable Windows Firewall Value: No Modifying User: S-1-5-21-2910110503-590998239-2551655963-500 Modifying Application: C:\Windows\explorer.exe

utiliser Ossec pour surveiller le fonctionnement des services

Windows EventChannel Example To monitor a Windows event log on Windows Vista or later, you have the possibility to use the “eventchannel” log format. The location is the name of the event log. This is the only way to monitor Applications and Services logs. If the file name contains a “%4”, replace it with “/”. Example :
<localfile>
   <location>Microsoft-Windows-PrintService/Operational</location>
   <log_format>eventchannel</log_format>
</localfile>

utiliser la réponse active d’ossec pour redémarrer un service qui se serait arrêté

autre ecrit

mesurer la charge, la mémoire et générer des alertes

encore autre écrit

L’heure

toutes les heures sont en UTC. Il faut mettre les horloges des systèmes en UTC afin que time() retourne de l’UTC.

Après, ce que l’on affiche, c’est un autre problème.

Noter que le message (Msg) peut contenir une heure locale. L’agent la convertit en UTC, ce sera bien l’heure sous laquelle est enregistré l’événement dans la base de données et sous laquelle elle apparait dans les tableaux.

Règles 5501, 5502 ... - Horodatage des événements inversé

Ossec date l’événement en fonction de l’heure du log. Mais quand on regarde le message, on voit que l’événement est daté d’une seconde ou plus avant. Il y a même des événements inversés. Par exemple 5501 Login session opened apparait après 5502 Login session closed.

Règle 9707 - dovecot : on n’extrait pas l’IP source

Dovecot, échec de connexion : l’IP source apparait dans msg ; mais srcip reste vide.

Règle 11301 - pure-ftpd : nécessite de compléter les règles

Dans /var/log/messages : Dec 10 10:00:26 vps99861 pure-ftpd : (?@188.165.197.110) [INFO] New connection from 188.165.197.110 Dec 10 10:00:31 vps99861 pure-ftpd : (?@188.165.197.110) [WARNING] Authentication failed for user [bidiweb@bidiweb.com] Dec 10 10:00:31 vps99861 pure-ftpd : (?@188.165.197.110) [INFO] Logout.

Seul le premier message est tracé par Ossec. Il est pourtant intéressant de connaître l’user et le fait que la tentative de connexion a échoué. Et si elle réussit ???

Il faut :
- compléter les règles,
- associer ces trois événements et les filtrer si on a "Authentification failed".

Règle 5715 - sshd : mieux contrôler l’IP et l’user

La règle signale une authentification sshd réussie, par exemple : vps223233 sshd[19571] : Accepted password for root from 164.132.107.166 port 50952 ssh2

le niveau d’alerte 3 irait bien si on avait vérifié que l’user et l’IP sont autorisés pour cet agent.

Il faut donc une table de white-list : agent (ou tous les agents), user, IP.
Si on ne trouve pas dans la white-list, on monte le niveau d’alerte.

Règle 533 - netstat : erronnée

La règle signale des changements d’ouverture de port qui n’existent pas.

Règle 18130 - Windows Logon Failure : manque l’indication de la source

Logon Failure - Unknown user or bad password. Windows ne fournit pas de données pour Source Network Address : - Source Port : qui restent vides.

Règle 2502 - User missed the password more than one time : srcip manquant

rhost (remote host) devrait passer en srcip. Exemple : Dec 11 08:43:20 vps223233 sshd[21427] : PAM 5 more authentication failures ; logname= uid=0 euid=0 tty=ssh ruser= rhost=182.120.128.183