Mise en service TigerGuard

Nous avons déci­dé de chan­ger une des fonc­tion­na­li­tés de nos offres Cloud et Pro.

En effet, nous rem­pla­çons Imunify360 par Tiger­Guard, une solu­tion déve­lop­pée par o2switch.

Préa­la­ble­ment, il faut savoir qu’une seule fonc­tion d’Imunify360 était uti­li­sée sur les offres o2switch : la véri­fi­ca­tion en temps réel des uploads, pro­ces­sus PHP à la recherche de malveillances.

Pour­quoi ? Car depuis tou­jours, o2switch a sou­hai­té déve­lop­per en interne ses propres outils pour ne pas dépendre de tiers et pou­voir gérer le plus pro­pre­ment pos­sible les fonc­tions proposées.

Ain­si, nous uti­li­sons depuis de nom­breuses années des fron­taux web. Ces der­niers sont char­gés : de répar­tir des charges (par­fois entre plu­sieurs ser­veurs phy­siques) ; d’appliquer cer­tains caches ; de véri­fier les requêtes réa­li­sées sur le ser­veur ; d’appliquer des élé­ments de sécu­ri­té. Ceci plus en pro­fon­deur et avant même mise sur le mar­ché d’Imunify360.

Ces fron­taux peuvent être, par exemple, per­son­na­li­sés par la fonc­tion Tiger­Pro­tect du cPanel.

Imunify360 venait alors en complément.

Imunify360, dans son usage com­plet, fait par­tiel­le­ment cela : il redi­rige les requêtes à des­ti­na­tion du ser­veur web vers un déri­vé Nginx de fil­tra­tion. Fonc­tion déjà pré­sente, depuis long­temps, chez o2switch.

Imunify360, par rap­port à Imu­ni­fyAV+, pou­vait per­mettre, côté o2switch de « délé­guer » la par­tie sur­veillance temps réel à une solu­tion tiers. Une marque pro­po­sée à nos héber­gés. Moins de main­te­nances à réa­li­ser par nos propres équipes. Cqfd. Le com­bo sem­blait gagnant.

Pro­blème ? Nous avons ren­con­tré cer­tains com­por­te­ments qui ne conve­naient pas aux ser­vices o2switch et à nos hébergés :

• Imunify360 mal­gré des fonc­tions désac­ti­vées, redi­ri­geait tout de même le tra­fic vers son fil­trage interne, par règle posi­tion­née sur iptable. (couche linux) : cela pro­vo­quait des blocages/timeout aléa­toires. Et des conflits avec nos propres mécanismes.
• Imunify360, pour sa pro­tec­tion temps réel, rajoute un module PHP char­gé et qui dif­fère de quelques ms le char­ge­ment PHP. Ceci pro­vo­quait cer­taines frus­tra­tions, mais aus­si une charge inutile des comptes d’hébergement.
• Imunify360, sur cer­tains sites, pou­vait pro­vo­quer des erreurs 503 lors d’opérations. À savoir qu’une erreur 503 est sou­vent en liai­son avec des erreurs dans le dérou­le­ment d’un script.

De manière brute, nous avons donc rem­pla­cé Imunify360 par Imu­ni­fyAV+ (comme avant) et rajou­té ce que nous nom­mons Tiger­Guard sur Cloud. Et Pro. Afin de ne pas perdre la fonc­tion­na­li­té de pro­tec­tion en temps réel.

Tiger­Guard n’est pas nou­veau, nous avons ce méca­nisme dans les car­tons depuis longtemps.

Nous tra­vaillons alors avec des édi­teurs tiers, que nous payons, sur la four­ni­ture de signa­tures anti-mal­wa­re/­vi­rale. Et nous trai­tons nous-mêmes le filtrage.

Imunify360 est sans doute une solu­tion par­faite pour cer­tains petits héber­geurs. Car il per­met de mettre à dis­po­si­tion un outil com­plet sans com­pé­tence tech­nique. Il n’est pas à blâ­mer. Mais dans le contexte de rési­lience, d’optimisations, de sécu­ri­té, et d’outils déve­lop­pés par une équipe internes de tech­ni­ciens qua­li­fiés, il n’est pas adap­té à nos ser­veurs.

Ceci étant un constat, nous avons modi­fié en consé­quence pour la satis­fac­tion de nos héber­gés. Notre sou­hait premier.