Après tout, le port est finalement ouvert de même ?
A te lire, on a le sentiment que le port ouvert c'est le point faible de ta sécurité. Attention, il y a des nuances, et c'est là toute le cœur de la discussion entre Gérald d'une part et Bruno et moi d'autre part.
Ce qu'il faut bien comprendre, c'est que de base, ton kernel, il va dropper tous les messages. Tout ce qui entre va partir directement à la poubelle. En effet, le kernel n'implémente aucun service réseau (j'oublie ICMP pour les besoins de la démonstration - et peut-être autre chose ?), il n'est pas là pour ça. Donc pas besoin de "INPUT DROP", c'est ce qu'il fera de toutes façons.
Si un jour tu veux jouer avec Apache par exemple, tu vas lancer le programme Apache, et la première chose qu'il va faire c'est dire au kernel "bon, dès que t'as un truc sur le port 80, tu me l'envoies". Du coup, quand un message arrive sur le port 80, le kernel l'envoie au processus Apache (au lieu de le jeter).
Et attention, la faille potentielle, le trou de sécurité, la peur du petit malin, elle n'est pas dans le fait que le port 80 soit ouvert. La faille si elle existe, elle est dans Apache et nulle part ailleurs. Au moment où tu installes Apache, tu dois te dire "merde, j'ajoute un programme qui va traiter des messages venant de l'extérieur, je ne dois pas faire n'importe quoi". C'est ça LE réflexe de sécurité. Sur quel port j'écoute, et sur quelle interface j'écoute (ou quelle plage d'adresse j'autorise). Les règles de firewall qui se contentent d'ouvrir ou de fermer des ports ne te serviront à rien : en effet tu vas ouvrir le port 80 (sinon ça marche pas), et Apache les traitera, exactement comme si tu n'avais pas de règles du tout. Les règles dont vous parlez depuis le début de ce thread ne serviront en rien à mieux protéger ton ordinateur, même dans cette situation (un desktop avec qques serveurs bien définis comme SSH, Apache, MySQL etc.)
Des règles firewall intéressantes c'est par exemple ce qui te permet de bannir une IP qui tente un peu trop de se connecter à ton SSH (style fail2ban), ou qui limitent une attaque DDOS (des milliers de requêtes qui arrivent simultanément sur ton Apache pour tenter de mettre à plat ton serveur). Là oui, tu améliores la situation par rapport à si tu n'avais pas de firewall du tout. Là oui tu te protèges mieux.
Voilà donc le message c'est attention au faux sentiment de sécurité : "j'ai mis Apache, mais j'ai un firewall donc ça va". Si le firewall en question se contente de tout fermer sauf le port 80, en fait il ne t'aide pas spécialement, le kernel l'aurait fait tout seul.
Tu peux par exemple faire un simple netstat -l, qui va te lister tous les ports en écoute sur ta machine. Ça veut dire que derrière il y a un service prêt à répondre (et donc potentiellement une faille). Vérifie déjà que tu es d'accord avec cette liste et que tu as bien compris chaque service à quoi il sert. Une fois ceci fait tu peux dormir tranquille, même sans INPUT DROP :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Merci ! Encore quelques questions...
Posté par gUI (Mastodon) . En réponse au message IPtables -configuration. Évalué à 3.
A te lire, on a le sentiment que le port ouvert c'est le point faible de ta sécurité. Attention, il y a des nuances, et c'est là toute le cœur de la discussion entre Gérald d'une part et Bruno et moi d'autre part.
Ce qu'il faut bien comprendre, c'est que de base, ton kernel, il va dropper tous les messages. Tout ce qui entre va partir directement à la poubelle. En effet, le kernel n'implémente aucun service réseau (j'oublie ICMP pour les besoins de la démonstration - et peut-être autre chose ?), il n'est pas là pour ça. Donc pas besoin de "INPUT DROP", c'est ce qu'il fera de toutes façons.
Si un jour tu veux jouer avec Apache par exemple, tu vas lancer le programme Apache, et la première chose qu'il va faire c'est dire au kernel "bon, dès que t'as un truc sur le port 80, tu me l'envoies". Du coup, quand un message arrive sur le port 80, le kernel l'envoie au processus Apache (au lieu de le jeter).
Et attention, la faille potentielle, le trou de sécurité, la peur du petit malin, elle n'est pas dans le fait que le port 80 soit ouvert. La faille si elle existe, elle est dans Apache et nulle part ailleurs. Au moment où tu installes Apache, tu dois te dire "merde, j'ajoute un programme qui va traiter des messages venant de l'extérieur, je ne dois pas faire n'importe quoi". C'est ça LE réflexe de sécurité. Sur quel port j'écoute, et sur quelle interface j'écoute (ou quelle plage d'adresse j'autorise). Les règles de firewall qui se contentent d'ouvrir ou de fermer des ports ne te serviront à rien : en effet tu vas ouvrir le port 80 (sinon ça marche pas), et Apache les traitera, exactement comme si tu n'avais pas de règles du tout. Les règles dont vous parlez depuis le début de ce thread ne serviront en rien à mieux protéger ton ordinateur, même dans cette situation (un desktop avec qques serveurs bien définis comme SSH, Apache, MySQL etc.)
Des règles firewall intéressantes c'est par exemple ce qui te permet de bannir une IP qui tente un peu trop de se connecter à ton SSH (style fail2ban), ou qui limitent une attaque DDOS (des milliers de requêtes qui arrivent simultanément sur ton Apache pour tenter de mettre à plat ton serveur). Là oui, tu améliores la situation par rapport à si tu n'avais pas de firewall du tout. Là oui tu te protèges mieux.
Voilà donc le message c'est attention au faux sentiment de sécurité : "j'ai mis Apache, mais j'ai un firewall donc ça va". Si le firewall en question se contente de tout fermer sauf le port 80, en fait il ne t'aide pas spécialement, le kernel l'aurait fait tout seul.
Tu peux par exemple faire un simple
netstat -l, qui va te lister tous les ports en écoute sur ta machine. Ça veut dire que derrière il y a un service prêt à répondre (et donc potentiellement une faille). Vérifie déjà que tu es d'accord avec cette liste et que tu as bien compris chaque service à quoi il sert. Une fois ceci fait tu peux dormir tranquille, même sans INPUT DROP :)En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.