Bonjour,
y-a-t-il une utilité à utiliser un noyau RT (Real-Time) hors MAO (Musique Assistée par Ordinateur)?
je me pose la question de savoir si le RT peut être utile sur un équipement destiné à de la sécurité (IDS/IPS, parefeu)
Cordialement
Bonjour,
À vérifier auprès des experts mais peut-être que l’aléatoire est « meilleur » sur ce type de système.
j’ai vu sur un forum que globalement le temps de réponse est meilleurs, mais que les performances globales moins bonne. Mais comme cela date d’il y a au moins 5 ans, je ne suis pas certains de la validité actuelle.
Qu’entends-tu par aléatoire ?
A mon avis non, tu n’aura pas un système plus réactif dan ce genre d’utilisation, par contre si tu es partie dans l’envie de te faire une plateforme regarde pour alléger le kernel au strict minimum et à durcir le système car il ne sera pas amener à évoluer hormis pour les mise à jour …
@PascalHambourg : il me semble qu’utilisais un routeur maison avec ces propres Kernels, je ne sait pas si c’est toujours le cas mais il sera le plus a même de t’aiguiller sur ce qui est préférable ou non de gérer/faire.
Pour ma part Opnsense et PFsense font merveille est sont facile à maintenir, le restant étant hébergé à la maison sous forme de container et de machine virtuelles (en passe de disparaître au profit de container ^^ ).
j’ai déjà durci la configuration en me basant sur le CIS Workbench debian 10. Il y a déjà pas mal à faire avec.
je prends note 
J’utilise déjà OPNsense en remplacement de ma box orange, mais il y a pas mal de chose qui me déplaise dedans, en terme de facilité d’utilisation, et surtout de reporting, notamment sur les logs qui sont faibles (par exemple suricata), ou de fiabilité (comme Bind). Certes il y a pas mal de choses pratique pour ce qui est de la configuration de base mais il manque des fonctionnalités (comme le DHCPv6 par exemple).
Opnsense permet pourtant la gestion d’un dhcp en ipv4 et ipv6 oO
https://docs.opnsense.org/manual/how-tos/ipv6_dsl.html
Pour les logs dans mon esprit ce type de machine n’a pas vocation à collecter/exploiter les logs, c’est plus le rôles de ma stack elk derrière qui gère ça ^^
Après consolider plusieurs rôles sur une machines pourquoi pas mais la collecter et l’exploitation de logs reste en règle générale consommatrice de ressources.
J’ai déjà réfléchi à remplacer le matériel de Orange, mais à chaque fois c’est soit le service TV soit la téléphonie qui me bloque tant niveau matériel et que le temps à maintenir tous ça qui me freine.
Tu as effectué ton remplacement en suivant une documentation telle que celle-ci ?
https://lafibre.info/remplacer-livebox/opnsense-remplacer-livebox-aucune-modification-necessaire/
Les lois fondamentales de l’univers et de l’informatique n’ont pas changé depuis 5 ans. A capacité de traitement égale, on doit toujours faire un compromis entre le temps de réponse et le débit.
C’est toujours le cas, en partie pour des raison historiques qui n’ont plus vraiment cours et en partie par inertie de ma part. Mais ce n’était pas vraiment pour des questions de performance, et je n’ai jamais utilisé de noyau RT ni d’IDS/IPS.
OK. merci pour ces réponse. Je vais faire l’économie du RT.
Pour l’IDS je verrais
Je pensais à random.
Merci @Zargos pour ce fil, ça m’a permis d’apprendre que l’équipe RT va voir son travail appliqué en amont, peut-être à partir de la version 5.10 du noyau.
Ça ne m’éclaire pas franchement sur le sens de ton intervention.
Ah pardon, peut-être qu’avec plus de déterminisme, ce qui est fourni avec les noyaux RT, on peut produire un hasard de meilleure qualité.
Pour revenir à la question de départ, en dehors de la MAO, les noyaux RT, pas seulement linux, sont utilisés par tout un tas de systèmes dits critiques.
Je ne vois pas le rapport (instinctivement j’aurais plutôt tendance à penser l’inverse), mais admettons. Néanmoins, en quoi la qualité du hasard généré est-elle pertinente pour l’utilisation mentionnée dans le message initial, à savoir un pare-feu/IDS/IPS ?
Probablement pour la génération des différentes clefs pour les accès distants au système, que ce soit par SSH ou HTTPS.
Après, pour la « qualité du hasard », je possède personnellement un générateur de nombres aléatoires dont je suis très satisfaite. Bon, ça fait quinze ans qu’il ne me donne que des 9, mais à chaque tirage, rien ne permet de déterminer à l’avance quel nombre va sortir. Je trouve ça hyper excitant !
Les noyaux RT ont la même capacité que les noyau standard à généré de l’entropie, si c’est ce à quoi tu penses, pour améliorer leur comportement sur ce point le paquet Haveged est ce qu’il faut.
Mais là il n’en ai pas question, c’est plus le besoin de savoir si un noyau RT (Real Time) est plus efficace pour effectuer du traitement sur des applicatifs réseau, et là je ne pense pas que ce soit pertinents pour les besoin de Zargos.
Par contre pour ma culture personnel je veux bien quelques exemples , car le seul domaine où ça me paraissait importants c’est justement dans le traitement du son.
Si le patch ou les autres techno basé sur de la virtualisation sont utilisé pour gérer des thermostats ou autre appareils de contrôles, je pense pas que hors du monde de l’industrie il soit utilisé.
Oui mais il se trouve que nous baignons dans ce monde industriel, n’est-ce pas ?
Le RT a pour vocation de devenir le standard, à mon avis, même si je ne m’avancerai pas sur une date.
De fait, selon toi, le noyau de base sera remplacé par le RT ou il y aura toujours deux noyaux avec et sans RT?
Considerant une utilisation IPS (plus que pour l’IDS), le RT pourrait accélérer le temps de réponse du système à une alerte?
Le « temps réel » ne consiste pas à raccourcir le temps de réponse mais à garantir un temps de réponse maximum.
1 J'aime
En 2038, le noyau par défaut serait le RT mais le noyau sans resterait disponible.
Ok je vois la différence. Qui est importante dans nombre d’utilisation et de contractualisation potentielles.
ben ca va, on a le temps de voir ça à la retraite alors :)