Skip to content

Ajout d'un filtre dans Cywise pour ne plus afficher les événements rejetés

Depuis la page d'accueil de Cywise, les utilisateurs peuvent rejeter des événements. Le but est de ne plus afficher ce type d'événement au bout de 3 rejets.

Instruction de Cyrille

J'ai un petit truc urgent à faire : sur la homepage tu peux flagger certains événements de sécurité comme "à rejeter" (colonne ynh_osquery.dismissed). Il faudrait que quand l'utilisateur en a flaggé 3 pour un même couple (ynh_server_id, name, action, columns_uid) on fasse disparaitre les nouveaux événements de ce type de l'email et de l'UI (je pense qu'il suffit de faire ça au niveau des vues).

Analyse

La vue qui liste les événements est resources/views/components/suspicious-activity.blade.php. Le composant qui récupère les données est app/View/Components/SuspiciousActivity.php. Donc la(les) requête(s) à modifier se trouve dans app/Models/YnhOsquery.php, méthode suspiciousEvents.

La méthode récupère plusieurs types d'événements à l'aide de vue qui interroge ynh_osquery. ynh_osquery contient les colonnes ynh_server_id, name, action et columns_uid. Mais les vues ne récupèrent pas la colonne columns_uid. Il va donc falloir que je modifie les vues pour la récupérer.

Ensuite, je vois 2 possibilités :

  • filtrer au niveau des vues SQL
  • filtrer au niveau du code

Nous avons finalement décidé de ne pas mettre le filtre dans chaque vue. J'ai fait une vues qui renvoie uniquement les événements avec dismiss à true. Puis, dans le code, je filtre avec un whereNotExists :

->whereNotExists(function (Builder $query) {
    $query->select(DB::raw(1))
        ->from('v_dismissed')
        ->whereColumn('ynh_server_id', '=', 'v_logins_and_logouts.server_id')
        ->whereColumn('name', '=', 'v_logins_and_logouts.name')
        ->whereColumn('action', '=', 'v_logins_and_logouts.action')
        ->whereColumn('columns_uid', '=', 'v_logins_and_logouts.columns_uid')
        ->havingRaw('count(1) >=' . self::HIDE_AFTER_DISMISS_COUNT);
})

J'ai tout de même dû modifier chaque vues afin qu'elles renvoient les 4 colonnes permettant de faire le lien entre les événements et ceux de la vue v_dismiss (il manquait name et columns_id dans la plupart des cas).

Création des données pour pouvoir tester

Pour pouvoir vérifier que le filtre fonctionne comme attendu, j'ai besoin de données dans ma base locale. Je vais donc faire un seeder qui va les mettre en place.

Les événements YnhOsquery appartiennent à un serveur YnhServer qui lui-même appartient à un utilisateur User.

Je dois donc créer un utilisateur (je préfère avoir un utilisateur dédié aux tests des événements rejetés), créer un ou plusieurs serveurs puis créer des événements pour chaque serveur.

Il y a plusieurs types d'événements particuliers que la page d'accueil affiche, une vue pour chaque type, donc je vais devoir créer des événements pour chaque type.

Commandes pour tester

Lancer le serveur web (et prendre en compte les nouvelles classes avec composer) : 

composer dump-autoload && php artisan cache:clear && php artisan serve --port=8080

Lancer le seeder pour créer 3 serveurs et 10 événements de chaque type par serveur :

php artisan db:seed Database\\Seeds\\RecentEventsSeeder

Lancer le seeder pour créer 20 événements d'un type en particulier pour un serveur, par exemple :

php artisan db:seed Database\\Seeds\\RecentKernelModuleEventsSeeder

Créer un nouveau seeder :

php artisan make:seeder RecentKernelModuleEventsSeeder

ATTENTION : il faut changer le namespace de namespace Database\Seeders; vers namespace Database\Seeds;.

Faire la commande qui applique la migration pour changer la vue :

php artisan migrate --step

   INFO  Running migrations.  

  2025_04_01_105500_update_dismiss_view_suid_binaries ............ 32.78ms DONE

NOTA : utiliser l'option --step permet de pouvoir annuler les dernières migrations une à une. C'est pratique pour corriger la vue si besoin.

php artisan migrate:rollback

   INFO  Rolling back migrations.  

  2025_04_01_105500_update_dismiss_view_suid_binaries ........... 306.90ms DONE

Pour tester donc, faire les modifications dont la migration, appliquer la migration, redémarrer le serveur web (prise en compte des nouvelles classes) puis lancer un seeder.

Les événements doivent apparaître sur la page d'accueil. J'ai systématiquement repéré un événement en 3 exemplaires ou plus, cliqué sur 2 dismiss, rafraichi (F5) et vérifié que les événements s'affichaient, cliqué sur un troisième dismiss, rafraichi (F5) et vérifié que les événements ne s'affichaient plus.

Pour certains types, la vue utilise la table ynh_osquery_latest_events et, comme elle ne se met pas à jour automatiquement, aucun événement ne s'affiche.

Pour remplir la table ynh_osquery_latest_events, il faut lancer les jobs (un par serveur). Démarrer Tinker avec :

php artisan tinker

Lancer les jobs avec :

RebuildLatestEventsCache::sink()

Puis traiter les jobs qui se trouvent dans la file d'attente low avec :

php artisan queue:listen --queue low