Néanmoins les attaques que tu donnes impliquent déjà un haut niveau d'accès
A moins que ton serveur de logs soit accessible depuis l'extérieur (et là il y a un vrai problème), le niveau d'accès dans tous les cas est le même : avoir accès à une machine sur la même branche réseau. Faire un poisonning ARP c'est une ligne de script.
spammer le serveur de syslog non.
Le truc c'est que la solution de Lennart va pas changer grand chose. A la limite, si j'ai envie de saturer/forcer une rotation sur un serveur de log chez quelqu'un, je n'ai qu'à ouvrir des milliers de connexions ssh par seconde et à les couper brutalement, ou à réclamer des milliers de pages web inexistantes sur un site. Et là j'ai même pas besoin d'être sur la même branche réseau. Suivant la sécurité du réseau ça passera ou pas.
monter une petite pki, ou un système à la ssh n'est pas très complexe à mettre en oeuvre
En externe non, en interne (ie dans le programme de syslog lui même) je vois pas l’intérêt. Ca prend effectivement 10 secondes de dire à ton serveur de log de n'écouter qu'en lo0 et de dire aux demons distants de monter un tunnel ssh avant de loguer (pour peu que le démon distant en question soit démarré suffisamment tard). Maintenant Lennart invoque une solution en interne, donc soit ca s'appuie sur des systèmes connus (Kerberos, IPSec éventuellement SASL) dont il est client, soit il va falloir coder un service complet d'auth dans le syslog. Et très honnêtement un syslog qui possède son propre service PKI à maintenir et à mettre à jour ....
Bon maintenant Lennart veut que Journal s'appuie sur HAL, ConsoleKIT, SystemD (et donc DBus), un serveur de base de données (j'espère en no-sql parce que les logs c'est pas forcément très structuré), donc rajouter un système d'auth par dessus tout ça, ça doit pas lui faire peur. Ceci dit je serais quand même curieux de voir comment il compte loguer la phase 2 du boot et le dmesg (ou même un crash DBus tient).
Interpreter c'est justement ce que je lui reproche, de remplacer l'ip de l'émetteur par celle du message
Non, il reçoit un message qui possède un contenu dont une section "IP" avec une adresse. Lui il enregistre le message sans y toucher. La seule chose qui intéresse syslog c'est le numéro de processus, le reste tu fais ce que tu veux.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Kaane . En réponse au journal Lennart casse les logs!. Évalué à 5.
A moins que ton serveur de logs soit accessible depuis l'extérieur (et là il y a un vrai problème), le niveau d'accès dans tous les cas est le même : avoir accès à une machine sur la même branche réseau. Faire un poisonning ARP c'est une ligne de script.
Le truc c'est que la solution de Lennart va pas changer grand chose. A la limite, si j'ai envie de saturer/forcer une rotation sur un serveur de log chez quelqu'un, je n'ai qu'à ouvrir des milliers de connexions ssh par seconde et à les couper brutalement, ou à réclamer des milliers de pages web inexistantes sur un site. Et là j'ai même pas besoin d'être sur la même branche réseau. Suivant la sécurité du réseau ça passera ou pas.
En externe non, en interne (ie dans le programme de syslog lui même) je vois pas l’intérêt. Ca prend effectivement 10 secondes de dire à ton serveur de log de n'écouter qu'en lo0 et de dire aux demons distants de monter un tunnel ssh avant de loguer (pour peu que le démon distant en question soit démarré suffisamment tard). Maintenant Lennart invoque une solution en interne, donc soit ca s'appuie sur des systèmes connus (Kerberos, IPSec éventuellement SASL) dont il est client, soit il va falloir coder un service complet d'auth dans le syslog. Et très honnêtement un syslog qui possède son propre service PKI à maintenir et à mettre à jour ....
Bon maintenant Lennart veut que Journal s'appuie sur HAL, ConsoleKIT, SystemD (et donc DBus), un serveur de base de données (j'espère en no-sql parce que les logs c'est pas forcément très structuré), donc rajouter un système d'auth par dessus tout ça, ça doit pas lui faire peur. Ceci dit je serais quand même curieux de voir comment il compte loguer la phase 2 du boot et le dmesg (ou même un crash DBus tient).
Non, il reçoit un message qui possède un contenu dont une section "IP" avec une adresse. Lui il enregistre le message sans y toucher. La seule chose qui intéresse syslog c'est le numéro de processus, le reste tu fais ce que tu veux.