Tu peux me dire la version de noyau utilisée?
Parce qu'à moins d'un petit miracle, impossible d'utiliser un noyau récent ET l'accélération matérielle qui requiert des modules closed source qui ne tournent qu'avec le noyau fournit sur le firmware d'origine. Donc je m'attends à quelque chose comme une 3.10.X, pour lequel bon nombre de CVE exploitables et exploitées en remote existent. Donc une superbe passoire. Gênant pour un routeur...

Sur le R7800, c'est le très vieux noyau 3.4.103 qui en effet est nécessaire pour l'accélération matérielle (merci Netgear  )
La bonne nouvelle est que le noyau étant Open Source, les failles ont été à ma connaissance patchées sur cette version (Voxel est très pointu dans les CVE et la sécurité, je ne suis qu'un amateur à côté, il pourrait en parler en détail, pas moi…)

Comme je disais. CQFD.
Impossible: si tu touches au kernel d'origine, les modules propriétaires ne se chargeront plus (le hash du kernel change).

Ensuite je vois bien le bonhomme seul s'atteler à backporter l'ensemble des fixs CVE des kernels récents dont l'API a tellement changée qu'elle n'a plus rien à voir avec un 3.4.
Il y a une raison pour laquelle les vieux noyaux sont "EOL" et ne reçoivent plus de mise à jours. Le support 3.4 a pris fin en octobre 2016!

Pardonne-moi d'être un peu brutal mais tu es en plein rêve là: tu utilises une passoire. Libre à toi, mais ne va pas t'imaginer que tu es sur une plateforme sécurisée. Et ce serait judicieux d'éviter de prendre tes rêves pour des réalités en disant que "les failles ont été patchées" alors que c'est strictement impossible: tu induis potentiellement d'autres utilisateurs en erreur.

J'ajoute accessoirement que nulle part sur son README il n'indique qu'il touche au kernel, ce qui ne m'étonne pas comme expliqué ci-dessus, et son github ici https://github.com/SVoxel/R7800/ montre bien qu'il se contente de mettre à jour quelques utilitaires.

Non vraiment, on est bien sur une passoire atomique, à fuir absolument ;P

Non mais des CVE EXPLOITABLES en remote, y'en pas non plus tous les jours. Pour un routeur il faut que ça touche ce qui est Ethernet / IP / TCP|UDP... car la plupart des CVE sont des "local privilege escalation" donc il faut DÉJÀ un accès non-privilégié sur la machine, donc mettre à jour le userland permet de se prémunir de la très grosse majorité des soucis en réduisant drastiquement la surface d'attaque possible. Bref, ce nc'est pas pour rien qu'il y a des score au CVE aussi hein..

De ce que je comprends, le EOL du kernel n'est pas à cause des CVE, mais à cause des nouvelles fonctionnalités dans les noyaux suivants… (bref, c'est logique qu'à un moment, de son ancienneté un noyau ne soit plus supporté).

Le noyau du firmware n'est pas le kernel 3.4.103 d'origine, mais une version modifiée et supportée par QCA avec des correctifs apportés par QCA jusqu'à au moins 2019.
Enfin, Voxel m'a confirmé avoir ajouté lui-même les correctifs CVE à sa version (c'est dans son log). Par exemple: 

1.0.2.68SF:

 1. Kernel vulnerability: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479 are fixed.

            https://nvd.nist.gov/vuln/detail/CVE-2019-11477

            https://nvd.nist.gov/vuln/detail/CVE-2019-11478

            https://nvd.nist.gov/vuln/detail/CVE-2019-11479

Donc ce n'est pas forcément plus vulnérable qu'OpenWRT où le noyau 5.10 est utilisé pour le R7800 (CVEs pour ce noyau 5.10: https://vulmon.com/searchpage?q=linux+linux+kernel+5.10 ).

Enfin, comme le précise Ralph, les failles doivent être exploitables, demandant un accès direct au terminal (donc accès telnet ou ssh…), et certaines sont sans effet sur le routeur, comme une vulnérabilité du module x86/x64 pour les instructions AES ou sur un pilote de cd-rom…

Après, je n'ai rien contre OpenWRT, mais l'absence d'accélération matérielle est vraiment dommage… C'est pour moi perdre une grosse fonctionnalité du routeur.
Je ne vais pas critiquer ton choix, que je comprends parfaitement et respecte. On se rejoint sur le fait que la sécurité et un accès au routeur sont importants ; après, il faudrait comparer point par point tous les CVE etc… pour savoir quelle solution est la plus sécuritaire.

La honte, c'est les firmwares officiels, qui eux sont ouvertsaux failles, et sont de loin les plus utilisés…

N'oublions pas enfin que je monitor régulièrement mon routeur (processus, cpu, mémoire, traffic, IRQ, etc…), donc si son comportement venait à changer (botnet), je le vois. L'accès au terminal du routeur est très sécurisé : aucun accès distant depuis internet, même pour moi, aucun accès telnet, seulement SSH avec obligatoirement avec une clé… Mon LAN est protégé aussi, port knockers etc…

C'est en faisant du monitoring justement que j'ai repéré le problème DHCPv6 d'ailleurs… L'activité SoftIRQ et CPU du routeur étaient un peu plus élevés… J'ai du coup vérifié aussi le monitoring de mon ONT (que je check aussi régulièrement de toute façon) et j'ai vu cette charge anormale de paquets multicast… Un tcpdump sur le routeur m'a montré le problème.


EDIT (ajout) :
Après avoir échangé avec Voxel, il m'indique (assez logiquement) que les vulnérabilités du noyau les plus dangereuses sont celles où l'attaquant peut attaquer via le port WAN sans besoin d'être connecté au terminal du routeur : buffer overflow, DDoS… Et d'autant qu'il le sache toutes ces failles ont été fixées dans ses firmwares.

Il rappel que la règle d'or est de ne pas autoriser d'accès au routeur via HTTPS, de ne pas activer ReadyCLOUD, ni miniupndp, et si besoin d'accès à distance de n'utiliser que SSH depuis le WAN.

Ce qui est le plus vulnérable dans le firmware natif et le sien, c'est ReadyCLOUD/Kwilt (CVEs OpenSSL 1.0.2), une vieille version de miniupnpd (pas de code source pour le corriger), l'accès par https (CVEs OpenSSL 1.0.2).
Ainsi que ReadySHARE (si l'attaquant a accès depuis le LAN), ce qui est identique pour OpenWRT.

Sur mon routeur, j'ai déjà tout cela désactivé, et tout ce qui appel à la maison de Netgear ou Amazon Cloud ou autre… Et je n'autorise même pas un accès SSH au routeur depuis le WAN.

C'est cool, je sais aussi faire une recherche de CVE rank 10, mais quand tu vois que par exemple pour la CVE-2017-18017 il faut "presence of xt_TCPMSS in an iptables action", on peut pas dire que ça soit la configuration classique...

Faux. C'est une configuration très classique. Google "TCP MSS Clamping".

Surtout que les correctifs de toutes les CVE remontées sont assez triviaux : le git diff fait pas plus d'une page. Donc pas besoin avoir une 5.17.4
pour se sentir en sécurité, les backports peuvent se faire facilement (et c'est pas comme si j'en avait pas fait dans ma "jeunesse" sur un kernel concurrent).

Encore faux. Quand les API concernées ont changé d'une version à l'autre, il peut devenir très difficile voir quasiment impossible de backporter certains fixes. Ou alors avec le risque d'introduire d'autres bugs quand une adaptation trop importante est faite sans contrôle.

Après, un routeur qui laisserait entrer de l'UDP non sollicité (pour la CVE-2016-10229) c'est clair qu'il doit finir à la poubelle.

Oui parce que c'est bien connu, la plupart des configs par défaut des routeurs commerciaux sont toujours bien ficelées

Et bon, généralement suite à ce genre de CVE, tu as quand même des mises à jours chez certains constructeurs. Il y a 807 patchs sur le Kernel 3.12 utilisé sur un Archer AX50 par exemple, avec des noms très explicites. D’ailleurs il y a du code openwtr aussi dedans

Oui. Certains constructeurs patchent ce qu'ils peuvent, quand ils le veulent bien (quand ils le veulent pas, l'utilisateur final l'a dans l'os). Le 3.12 a été maintenu à jour 1 an de plus que le 3.4 mentionné par bolemo.

Mais curieusement, j'ai plus tendance à faire confiance à un OS complètement opensource avec une équipe dédiée qui suit les alertes de sécurité de près et publie les patchs rapidement et en communiquant correctement dessus, qu'à un OS tenu à bout de bras par un gars tout seul dans son coin. Je dois être biaisé

De ce que je comprends, le EOL du kernel n'est pas à cause des CVE, mais à cause des nouvelles fonctionnalités dans les noyaux suivants… (bref, c'est logique qu'à un moment, de son ancienneté un noyau ne soit plus supporté).

C'est exactement ça, et c'est exactement ce qui rend la maintenance des vieux kernels difficile. L'ajout de "nouvelles fonctionnalités", ça peut être aussi des changements d'API, des modifications dans la structure du code, qui font qu'un fix qui fonctionne sur un kernel récent peut ne pas être applicable ou ne pas fonctionner sur un vieux kernel. Donc au bout d'un moment, les mainteneurs estiment qu'il est temps de passer à autre chose, ce qui est logique.

Le noyau du firmware n'est pas le kernel 3.4.103 d'origine, mais une version modifiée et supportée par QCA avec des correctifs apportés par QCA jusqu'à au moins 2019.

Donc plus mis à jour depuis bientôt 3 ans. Securitas maximus. Et qui te dit que QCA a pu traiter toutes les CVEs si par exemple certaines ne bénéficient pas d'un patch proposé par les devs kernel (les kernels EOL ne reçoivent précisément plus ces patchs)?

Enfin, Voxel m'a confirmé avoir ajouté lui-même les correctifs CVE à sa version (c'est dans son log). Par exemple: 

Intéressant. On peut voir le source code de ces correctifs?

Donc ce n'est pas forcément plus vulnérable qu'OpenWRT où le noyau 5.10 est utilisé pour le R7800 (CVEs pour ce noyau 5.10: https://vulmon.com/searchpage?q=linux+linux+kernel+5.10 ).

T'as pas du bien comprendre le concept: le 5.10 utilisé par OpenWRT, il est maintenu par les devs kernel jusqu'en décembre 2026 (décembre 2025 pour le 5.4 sur OpenWRT 21.02), et la version fournie par OpenWRT est une des dernières disponibles au moment de la release: donc le kernel proposé contient tous les fixs disponibles pour toutes les CVEs connues à date de release.

J'ajoute que pour les drivers wifi, ils vont même plus loin puisque typiquement ils backportent les drivers de kernels plus récents pour bénéficier du meilleur support et des meilleures performances possibles ET de la sécurité.

Enfin, comme le précise Ralph, les failles doivent être exploitables, demandant un accès direct au terminal (donc accès telnet ou ssh…), et certaines sont sans effet sur le routeur, comme une vulnérabilité du module x86/x64 pour les instructions AES ou sur un pilote de cd-rom…

Oui je te remercie de donner des exemples absurdes. Les CVE que j'ai listée sont exploitables dès lors qu'il y a un échange réseau quel qu'il soit entre une machine malicieuse et une autre machine. Sur un routeur, certaines failles sont exploitables dès lors que le routeur voit simplement _passer_ ce traffic. Les CVE que j'ai indiquées et celles que tu mentionnes sont dans ce cas.

Après, je n'ai rien contre OpenWRT, mais l'absence d'accélération matérielle est vraiment dommage… C'est pour moi perdre une grosse fonctionnalité du routeur.

ça dépend ce que tu as comme lien derrière, et ça dépend du routeur. Une nanopi R2S n'a pas besoin d'accélération matérielle pour saturer un lien giga par exemple. (c'est pas un routeur wifi, mais c'est pour illustrer).

Je ne vais pas critiquer ton choix, que je comprends parfaitement et respecte. On se rejoint sur le fait que la sécurité et un accès au routeur sont importants ; après, il faudrait comparer point par point tous les CVE etc… pour savoir quelle solution est la plus sécuritaire.

La honte, c'est les firmwares officiels, qui eux sont ouvertsaux failles, et sont de loin les plus utilisés…

N'oublions pas enfin que je monitor régulièrement mon routeur (processus, cpu, mémoire, traffic, IRQ, etc…), donc si son comportement venait à changer (botnet), je le vois. L'accès au terminal du routeur est très sécurisé : aucun accès distant depuis internet, même pour moi, aucun accès telnet, seulement SSH avec obligatoirement avec une clé… Mon LAN est protégé aussi, port knockers etc…

C'est en faisant du monitoring justement que j'ai repéré le problème DHCPv6 d'ailleurs… L'activité SoftIRQ et CPU du routeur étaient un peu plus élevés… J'ai du coup vérifié aussi le monitoring de mon ONT (que je check aussi régulièrement de toute façon) et j'ai vu cette charge anormale de paquets multicast… Un tcpdump sur le routeur m'a montré le problème.

C'est très bien. Tu es un poweruser et tu fais attention. Mais quand tu encourages des utilisateurs lambda à utiliser du matériel et un firmware "bof bof" pour le dire poliment (accessoirement utiliser un firmware maintenu par un seul gugus - a priori sans peer review en plus? - c'est pas franchement une solution très robuste si le gugus passe à autre chose pour X raison) tu ne pars j'espère pas du principe qu'ils vont passer autant de temps que toi à surveiller leur routeur comme le lait sur le feu?

Pour info moi j'aime bien quand je branche, ça tourne et je l'oublie. La vie est trop courte pour se farcir un monitoring quotidien d'un truc aussi simple et sans intérêt qu'un routeur ;P

EDIT (ajout) :
Après avoir échangé avec Voxel, il m'indique (assez logiquement) que les vulnérabilités du noyau les plus dangereuses sont celles où l'attaquant peut attaquer via le port WAN sans besoin d'être connecté au terminal du routeur : buffer overflow, DDoS… Et d'autant qu'il le sache toutes ces failles ont été fixées dans ses firmwares.

"D'autant qu'il sache". Nous voila bien rassurés

Il rappel que la règle d'or est de ne pas autoriser d'accès au routeur via HTTPS, de ne pas activer ReadyCLOUD, ni miniupndp, et si besoin d'accès à distance de n'utiliser que SSH depuis le WAN.

Again, les CVEs mentionnées plus haut affectent n'importe quel noyau qui fait du traffic réseau de base. Pas besoin de port ouvert!

Aller, j'en reste là, j'ai exposé mes arguments, libre à chacun de faire ce qu'il veut. Bisous.

PS: pour le contexte: je suis actuellement contributeur OpenWRT, et j'ai été pendant pas mal d'années contributeur du noyau Linux (même si je suis moins actif, il y a encore pas mal de code à moi dedans, drivers, support d'architectures exotiques, etc). Juste pour dire que j'ai une petite idée de quoi je parle quand j'en parle 

Je vois qu'on affute les couteaux ! 

Je ne vais certainement pas entrer dans les accusations… Je ne vous connais ni l'un ni l'autre, et je ne peux que considérer que vous êtes tous les deux sincères dans vos propos.

Au final, concernant les firmwares, je pense qu'on est tous d'accord sur le principe que :
– la sécurité est importante et trop souvent négligée (par les fabricants de routeurs grand public) ou méconnue (du grand public),
– les projets opensource comme OpenWRT, avec de nombreux contributeurs et vérificateurs, sont une très bonne chose, et on aimerait dans l'idéal que les constructeurs permettent un accès à toutes leurs spécifications pour permettre l'accélération matérielle et l'accès à toutes les ressources et possibilités qu'offre la machine.

Je trouve personnellement l'initiative de Voxel très louable. Son code est ouvert, on peut le compiler soi-même (je l'ai fait), et son objectif est triple : 1) augmenter la sécurité, 2) optimiser, 3) offrir un accès au routeur (ssh, Entware…)
Oui, il est seul, mais comme précisé, son code est ouvert. Il compile avec les derniers toolchains et compilateurs, avec des options pointues spécifique au processeur que même Netgear n'utilise pas, il surveille les publications CVE et met à jour en fonction… Bref, pour un gars tout seul, c'est honorable et impressionnant même, on ne va pas lui cracher dessus quand même…
Il offre un firmware amélioré qui donne accès à toute la puissance de ce qu'offre le routeur, est plus sécurisé et permet d'y accéder.
Même des personnes chez Netgear recommandent officieusement d'utiliser son firmware, car l'officiel est assez honteux…
Il y a toute une communauté sur SNB qui utilise son firmware, pose des questions, et il y a un support qui est ainsi fait… D'autre y proposent des utilitaires comme Kamoj avec un adon bien foutu ou moi avec Aegis.

Est-ce parfait ? Non, évidemment non… OpenWRT ne l'est pas non plus, et pas ou peu de routeurs récent n'est compatible (pas la faute d'OpenWRT).

Si on parlait d'entreprise et non d'un petit LAN perso sans vraie donnée sensible, alors oui, la sécurité maximale et garantie (autant que possible) serait de mise, et le routeur ne serait probablement pas un truc grand public…

Le jour où je devrai changer de routeur, je chercherai une solution 100% Open ; peut-être avec Pfsense ou quelque chose comme ça, ou un routeur 100% supporté par OpenWRT (accélération incluse).

Un conseil: oublie pfsense

Merci du conseil.
Quel est d'après toi le meilleur système récent, totalement ouvert, avec accélération matérielle ?
Non pas que j'ai besoin de changer de routeur, le miens remplis amplement mes besoins, mais j'aimerais avoir une idée d'où regarder pour le jour où (ou en cas de panne soudaine), et commencer à me renseigner.