Si tu as déployé à l'arrache et que ce devait être accessible de l'extérieur, le pare-feu avec les ports http/https ouverts n'y aurait donc rien changé.
Comme je te l'écrivais: "à des fins de tests".
Et oui, à des fins de tests, il m'est arrivé de dire à mysql d'écouter sur autre chose que la "boucle locale" (vrai traduction de loopback).
Mysql n'est en écoute que sur l'interface de bouclage et ce n'est généralement pas installable sans mot de passe « root » (Celui-ci n'est plus nécessaire sur les versions récentes de toute façon).
Sur debian, un MySQL s'installe sans soucis sans mdp root ...
Dernière élément: que se passe-t-il si, un jour, le mainteneur se loupe sur une évolution d'un fichier de config ou autre et que ton MySQL se met à écouter sur INADDR_ANY plutôt que sur 127.0.0.1 ?
On est dans le même cas que précédemment, si le service SSH devait être accessible de l'extérieur le port a été ouvert et le pare-feu n'y change rien.
Je ne vois pas l'intérêt d'autoriser un quelconque port sur un desktop, que ce soit ssh ou autre.
Dans l'idée, je préfère faire:
iptables -P INPUT DROP
plutôt que:
apt-get remove --purge openssh-server samba ...
Ca permet d'ouvrir le service temporairement en cas de besoin.
Tu connais beaucoup de cas où de telles failles ont été exploitées sur un système GNU/Linux ?
Généralement, quand les mecs s'emmerdent à trouver des failles et à ne pas les divulguer, c'est pas pour juste les garder au chaud sur un coin du disque mais bien pour les exploiter oui ...
Après, effectivement, dans le cas d'une station de travail, on va plus avoir à composer avec des bots scanner de SSH et de SMTP en open-relay qu'avec un vilain black hat.
De toute façon si ce sont des failles dans un service, on est toujours dans le même cas: tu as probablement ouvert le port concerné de ton pare-feu parce que tu avais besoin d'y accéder de l'extérieur. La faille est donc toujours potentiellement exploitable.
Dixit ma remarque plus haut. Que le service soit là à ne rien faire n'implique pas qu'on l'ouvre sur l'extérieur...
Si tu as mis en place un partage samba c'est que tu es sur un réseau local privé. Personne (enfin j'espère) n'utilise de partage SMB accessible sur l'Internet.
Oui sauf que sur une machine portable, un jour t'es sur un réseau local privé et le lendemain t'es sur un réseau local de gare.
D'habitude t'oublie pas de faire /etc/init.d/samba stop, mais il se trouve que ce jour là, t'as oublié ...
De manière générale la sécurité commence par la sécurisation des services qui sont en écoute plutôt que d'essayer d'enfoncer des portes ouvertes (ouvrir des ports sur lesquels un service est déjà en écoute) ou de mettre des cadenas sur les murs (fermer des ports sur lesquels aucun service n'est en écoute).
Pas tout à fait d'accord.
L'un des principes de base de la sécurité informatique est celui du moindre privilège (et c'est pas moi qui le dit mais l'ANSSI).
L'article wikipedia à ce sujet parle principalement de code, mais ce principe s'applique aussi au réseau: n'ouvrir que ce dont on a besoin.
Avoir un firewall qui droppe tout ce qui arrive en entrée est la première application de ce principe.
Ensuite vient la sécurisation des services.
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . En réponse au message IPtables -configuration. Évalué à 2.
Comme je te l'écrivais: "à des fins de tests".
Et oui, à des fins de tests, il m'est arrivé de dire à mysql d'écouter sur autre chose que la "boucle locale" (vrai traduction de loopback).
Sur debian, un MySQL s'installe sans soucis sans mdp root ...
Dernière élément: que se passe-t-il si, un jour, le mainteneur se loupe sur une évolution d'un fichier de config ou autre et que ton MySQL se met à écouter sur INADDR_ANY plutôt que sur 127.0.0.1 ?
Je ne vois pas l'intérêt d'autoriser un quelconque port sur un desktop, que ce soit ssh ou autre.
Dans l'idée, je préfère faire:
iptables -P INPUT DROP
plutôt que:
apt-get remove --purge openssh-server samba ...
Ca permet d'ouvrir le service temporairement en cas de besoin.
Généralement, quand les mecs s'emmerdent à trouver des failles et à ne pas les divulguer, c'est pas pour juste les garder au chaud sur un coin du disque mais bien pour les exploiter oui ...
Après, effectivement, dans le cas d'une station de travail, on va plus avoir à composer avec des bots scanner de SSH et de SMTP en open-relay qu'avec un vilain black hat.
Dixit ma remarque plus haut. Que le service soit là à ne rien faire n'implique pas qu'on l'ouvre sur l'extérieur...
Oui sauf que sur une machine portable, un jour t'es sur un réseau local privé et le lendemain t'es sur un réseau local de gare.
D'habitude t'oublie pas de faire /etc/init.d/samba stop, mais il se trouve que ce jour là, t'as oublié ...
Pas tout à fait d'accord.
L'un des principes de base de la sécurité informatique est celui du moindre privilège (et c'est pas moi qui le dit mais l'ANSSI).
L'article wikipedia à ce sujet parle principalement de code, mais ce principe s'applique aussi au réseau: n'ouvrir que ce dont on a besoin.
Avoir un firewall qui droppe tout ce qui arrive en entrée est la première application de ce principe.
Ensuite vient la sécurisation des services.