Cet article traite des questions globales sur l’utilisation d’OSSEC et des agents.
les règles, écriture de nouvelles règles
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
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.exeutiliser Ossec pour surveiller le fonctionnement des services
<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é
mesurer la charge, la mémoire et générer des alertes
L’heure
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é
Règle 9707 - dovecot : on n’extrait pas l’IP source
Règle 11301 - pure-ftpd : nécessite de compléter les règles
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
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.
