CVE-2015-1212 CVE-2015-1211 CVE-2015-1209 ne s'appliquent pas (failles de Google Chrome), or on parle de serveurs ici.
La CVE-2015-4003 est sur le module OZWPAN kernel 4.0.5.
Les suivantes impliquent un serveur CIFS compromis ou l'authentification CEPH, ou l'utilisation de B.A.T.M.A.N.
Les précédentes par contre... Elles permettent toutes de planter le système (DOS puis boum).
L'intérêt de les patcher est donc énorme sur un système à forte visibilité.
A peu près négligeable sur un petit serveur (l'intérêt de faire tomber un serveur dont tout le monde se fout est négligeable, alors qu'en prendre le contrôle est particulièrement utile, mais on n'a pas de failles de ce genre, heureusement).
Mais tu as tout à fait raison, on a ici des failles DOS exploitables à distance, sur du TCP ou de l'UDP, ça en fait 4 sur la période considérée, largement de quoi planter un système. À voir aussi si un firewall protège ou non, mais comme ça a l'air d'être des failles sur les protocoles, pas gagné que le firewall intervienne assez tôt... Et sinon il suffirait d'un port ouvert au public et ça passerait.
Selon l'importance du serveur, et de son besoin de disponibilité, ce n'est pas obligatoire de mettre son noyau à jour pour ces failles là. L'indisponibilité cumulée des mises à jours peut largement dépasser celle du redémarrage du serveur après une attaque (mais alors il faudra mettre à jour parce qu'on sait que quelqu'un nous a déjà attaqué sur une faille donnée, il faut la colmater). Sachant qu'il n'y a ici aucun risque de perte ou vol des données.
[^] # Re: Slackware, oui, mais avec respect pour les autres distributions/logiciels ?
Posté par Yth (Mastodon) . En réponse à la dépêche Slackware 14.2. Évalué à 2.
CVE-2015-1212 CVE-2015-1211 CVE-2015-1209 ne s'appliquent pas (failles de Google Chrome), or on parle de serveurs ici.
La CVE-2015-4003 est sur le module OZWPAN kernel 4.0.5.
Les suivantes impliquent un serveur CIFS compromis ou l'authentification CEPH, ou l'utilisation de B.A.T.M.A.N.
Les précédentes par contre... Elles permettent toutes de planter le système (DOS puis boum).
L'intérêt de les patcher est donc énorme sur un système à forte visibilité.
A peu près négligeable sur un petit serveur (l'intérêt de faire tomber un serveur dont tout le monde se fout est négligeable, alors qu'en prendre le contrôle est particulièrement utile, mais on n'a pas de failles de ce genre, heureusement).
Mais tu as tout à fait raison, on a ici des failles DOS exploitables à distance, sur du TCP ou de l'UDP, ça en fait 4 sur la période considérée, largement de quoi planter un système. À voir aussi si un firewall protège ou non, mais comme ça a l'air d'être des failles sur les protocoles, pas gagné que le firewall intervienne assez tôt... Et sinon il suffirait d'un port ouvert au public et ça passerait.
Selon l'importance du serveur, et de son besoin de disponibilité, ce n'est pas obligatoire de mettre son noyau à jour pour ces failles là. L'indisponibilité cumulée des mises à jours peut largement dépasser celle du redémarrage du serveur après une attaque (mais alors il faudra mettre à jour parce qu'on sait que quelqu'un nous a déjà attaqué sur une faille donnée, il faut la colmater). Sachant qu'il n'y a ici aucun risque de perte ou vol des données.
Yth.