Samba et ssh serveurs : Limiter l'usage

Sergio

06/10/2017 à 14:38

Le 06/10/2017 à 14:16, zeLittle a écrit :

Mon but, en fait, est sur mon poste principal (sous Linux, je rassure) d'utiliser le réseau local filaire (en 192.168.1.x) pour accéder à internet et aux autres machines (imprimantes, PC sous Linux
ou Windows.

Je n'ai peut être rien compris, mais il me semble que tu veux un PC relié en filaire à ta box (PC qui sera donc ta passerelle pour les autres PC, si tu veux aussi leur permettre d'aller sur internet),
et qui peut aussi être relié à d'autres PC, imprimantes (ton réseau local): il te faut donc un switch-hub pour relier tes périphériques du réseau privé.
Si c'est ça, la configuration dite d'un "bastion dedans-dehors" y ressemble: pour se faire, il te faut 2 cartes réseaux sur ce "PC bastion": une vers ta box (la patte côté réseau publique) et une vers
ton réseau interne (la patte côté réseau privé). Les données doivent pouvoir être forwardées d'une carte à l'autre.
Pour ce qui est de qui a le droit d'accéder où et depuis où, c'est comme tu t'en doutes ce sont les règles du pare-feu du "PC bastion" qui seront le centre de tri.
D'autre part, si tu veux accéder à ce poste depuis l'internet publique, tu dois laisser monter des ports depuis ta box sur ce "PC bastion", et en plus ouvrir un port serveur sur ton PC bastion depuis
les @ip autres que celles de ton réseau privé.
Une solution simpliste pour commencer, mais moins souple que les tables @ip, serait de mettre un place bête commutateur derrière ton PC côté patte vers ton réseau privée (ie venant de la carte
dedans): quand tu veux aller sur internet, tu coupes la connexion avec le bouton du commutateur entre la carte dedans et le switch-hub où arrivent tous tes autres PC, imprimantes, etc, privatifs -->
ton réseau privé est alors physiquement isolé.

Pas bon pour mon cas (trop radical) :
- Des fois l'internet box tombe en marche, et là j'ai un réseau "classique" et je partage des ressources (répertoires, ssh...) sur le réseau local (pratique ! SFR-Numéricable n'est pas encore à l'IPV6).
- Des fois, l'internet box est en panne, le réseau local fonctionne (la box fait routeur, même si l'internet est en rade), et je branche une clef 4G reliée au monde, et il ne faut pas que les partages
de ma machine soient accessibles depuis internet (mes mots de passe sont triviaux).
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org

Le 06/10/2017 à 14:16, zeLittle a écrit :

Mon but, en fait, est sur mon poste principal (sous Linux, je rassure) d'utiliser le réseau local filaire (en 192.168.1.x) pour accéder à internet et aux autres machines (imprimantes, PC sous Linux
ou Windows.

Je n'ai peut être rien compris, mais il me semble que tu veux un PC relié en filaire à ta box (PC qui sera donc ta passerelle pour les autres PC, si tu veux aussi leur permettre d'aller sur internet),
et qui peut aussi être relié à d'autres PC, imprimantes (ton réseau local): il te faut donc un switch-hub pour relier tes périphériques du réseau privé.
Si c'est ça, la configuration dite d'un "bastion dedans-dehors" y ressemble: pour se faire, il te faut 2 cartes réseaux sur ce "PC bastion": une vers ta box (la patte côté réseau publique) et une vers
ton réseau interne (la patte côté réseau privé). Les données doivent pouvoir être forwardées d'une carte à l'autre.

Pour ce qui est de qui a le droit d'accéder où et depuis où, c'est comme tu t'en doutes ce sont les règles du pare-feu du "PC bastion" qui seront le centre de tri.
D'autre part, si tu veux accéder à ce poste depuis l'internet publique, tu dois laisser monter des ports depuis ta box sur ce "PC bastion", et en plus ouvrir un port serveur sur ton PC bastion depuis
les @ip autres que celles de ton réseau privé.

Une solution simpliste pour commencer, mais moins souple que les tables @ip, serait de mettre un place bête commutateur derrière ton PC côté patte vers ton réseau privée (ie venant de la carte
dedans): quand tu veux aller sur internet, tu coupes la connexion avec le bouton du commutateur entre la carte dedans et le switch-hub où arrivent tous tes autres PC, imprimantes, etc, privatifs -->
ton réseau privé est alors physiquement isolé.

Pas bon pour mon cas (trop radical) :
- Des fois l'internet box tombe en marche, et là j'ai un réseau "classique" et je partage des ressources (répertoires, ssh...) sur le réseau local (pratique ! SFR-Numéricable n'est pas encore à l'IPV6).
- Des fois, l'internet box est en panne, le réseau local fonctionne (la box fait routeur, même si l'internet est en rade), et je branche une clef 4G reliée au monde, et il ne faut pas que les partages
de ma machine soient accessibles depuis internet (mes mots de passe sont triviaux).

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org

Vous avez filtré cet utilisateur ! Consultez son message

Le 06/10/2017 à 14:16, zeLittle a écrit :

Mon but, en fait, est sur mon poste principal (sous Linux, je rassure) d'utiliser le réseau local filaire (en 192.168.1.x) pour accéder à internet et aux autres machines (imprimantes, PC sous Linux
ou Windows.

Je n'ai peut être rien compris, mais il me semble que tu veux un PC relié en filaire à ta box (PC qui sera donc ta passerelle pour les autres PC, si tu veux aussi leur permettre d'aller sur internet),
et qui peut aussi être relié à d'autres PC, imprimantes (ton réseau local): il te faut donc un switch-hub pour relier tes périphériques du réseau privé.
Si c'est ça, la configuration dite d'un "bastion dedans-dehors" y ressemble: pour se faire, il te faut 2 cartes réseaux sur ce "PC bastion": une vers ta box (la patte côté réseau publique) et une vers
ton réseau interne (la patte côté réseau privé). Les données doivent pouvoir être forwardées d'une carte à l'autre.
Pour ce qui est de qui a le droit d'accéder où et depuis où, c'est comme tu t'en doutes ce sont les règles du pare-feu du "PC bastion" qui seront le centre de tri.
D'autre part, si tu veux accéder à ce poste depuis l'internet publique, tu dois laisser monter des ports depuis ta box sur ce "PC bastion", et en plus ouvrir un port serveur sur ton PC bastion depuis
les @ip autres que celles de ton réseau privé.
Une solution simpliste pour commencer, mais moins souple que les tables @ip, serait de mettre un place bête commutateur derrière ton PC côté patte vers ton réseau privée (ie venant de la carte
dedans): quand tu veux aller sur internet, tu coupes la connexion avec le bouton du commutateur entre la carte dedans et le switch-hub où arrivent tous tes autres PC, imprimantes, etc, privatifs -->
ton réseau privé est alors physiquement isolé.

Pas bon pour mon cas (trop radical) :
- Des fois l'internet box tombe en marche, et là j'ai un réseau "classique" et je partage des ressources (répertoires, ssh...) sur le réseau local (pratique ! SFR-Numéricable n'est pas encore à l'IPV6).
- Des fois, l'internet box est en panne, le réseau local fonctionne (la box fait routeur, même si l'internet est en rade), et je branche une clef 4G reliée au monde, et il ne faut pas que les partages
de ma machine soient accessibles depuis internet (mes mots de passe sont triviaux).
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org

Doug713705

06/10/2017 à 21:28

Le 06-10-2017, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<59d73f35$0$10182$) :

Doug713705 , dans le message <or7c4b$omk$, a
écrit :
Pas faux, d'où l'intérêt de bien choisir son réseau local et bien

Tu peux expliquer le critère de « bien », là ?

Ahaha, je me doutais qu'on allait arriver là. Évidement "bien" n'a que
peu de sens mais choisir un réseau autre que 192.168.{0,1}.0/24 permet
d'éviter 90% (au doigt mouillé) des collisions avec les réseaux publics
qui utilisent bien souvent les réglages par défaut, tout au moins sur la
plage réseau utilisée.
Pareil avec certains réseaux dans 10.10.0.0/16 qui sont parfois dans
des conf par défaut de certains équipements réseau (routeur notamment).

entendu d'effectuer un filtrage plus précis, genre machine par
machine.

Ça reste un filtrage par adresse IP, donc totalement inefficace quand on
est connecté à un réseau qu'on ne contrôle pas.

Après il faut aussi mesurer le risque.
- Qu'est qu'on en a faire qu'un quidam tente de se connecter si
tout est bien configuré (accès par clef pour SSH, mot de
passe et autre solution pour samba que je ne connais pas dans
le détail) ?
- Quelle est l'importance des données mise en jeux (les photos de
bobonne sur la plage, le dernier compte rendu financier d'un grand
groupe coté en bourse) ?
- Si la crainte c'est le ransomware, une solution de sauvegarde a t-elle
été mise en place ?
Après si on veut vraiment assurer la sécurité, on peut mettre en place
un VPN à l'intérieur du réseau local et ne faire écouter les démons
uniquement sur cette interface et'autoriser les accès sur les
ports 22 et Samba (je ne connais pas la plage de ports pour Samba,
probablement TCP/137,138,139). C'est la solution que je mets généralement
en place pour les serveurs qui sont en accès direct sur le net.
De fait l'accès sera autorisé unqiuement aux machines authentifiées sur
le VPN et répondant aux adresses IP fournies par le service VPN et autorisées.
Par contre il ne faut pas que le service VPN tombe et prévoir la
possibilité de redémarrer le service/la machine si le cas, rarissime, se
présentait.
On doit pouvoir faire un filtrage sur couple adresse MAC/IP (c'est probablement ce
que doit faire windows pour identifier ces réseaux publics/privés) mais
je ne sais pas le faire et une adresse MAC se spooffe en 2 coups de cuillère à pot.

Mais on peut supposer que le partge samba est protégé par mot de passe,
ce qui semble la moindre des choses quand on expose des données.

Euh, non, on ne peut certainement pas supposer ça. Il me semble au
contraire évident que Sergio veut exposer son partage sur le réseau
local à toutes les machines qui y sont connectées. Après tout, elles ont
déjà prouvé qu'elles sont dignes de confiance par leur capacité à se
connecter audit réseau local.

Effectivement on ne peut pas le supposer mais on peut que le conseiller.
On peut difficilement ouvrir sa maisons au 4 vents et vouloir qu'elle
soit sécurisée comme une banque.
Et ne jamais oublier que la sécurité n'est qu'une illusion.
Après tout ça ne reste que des propositions. Je suis loin d'être un
expert en la matière.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43

Le 06-10-2017, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<59d73f35$0$10182$426a74cc@news.free.fr>) :

Doug713705 , dans le message <or7c4b$omk$3@golgoth99.redatomik.org>, a
écrit :

Pas faux, d'où l'intérêt de bien choisir son réseau local et bien

Tu peux expliquer le critère de « bien », là ?

Ahaha, je me doutais qu'on allait arriver là. Évidement "bien" n'a que
peu de sens mais choisir un réseau autre que 192.168.{0,1}.0/24 permet
d'éviter 90% (au doigt mouillé) des collisions avec les réseaux publics
qui utilisent bien souvent les réglages par défaut, tout au moins sur la
plage réseau utilisée.

Pareil avec certains réseaux dans 10.10.0.0/16 qui sont parfois dans
des conf par défaut de certains équipements réseau (routeur notamment).

entendu d'effectuer un filtrage plus précis, genre machine par
machine.

Ça reste un filtrage par adresse IP, donc totalement inefficace quand on
est connecté à un réseau qu'on ne contrôle pas.

Après il faut aussi mesurer le risque.
- Qu'est qu'on en a faire qu'un quidam tente de se connecter si
tout est bien configuré (accès par clef pour SSH, mot de
passe et autre solution pour samba que je ne connais pas dans
le détail) ?

- Quelle est l'importance des données mise en jeux (les photos de
bobonne sur la plage, le dernier compte rendu financier d'un grand
groupe coté en bourse) ?

- Si la crainte c'est le ransomware, une solution de sauvegarde a t-elle
été mise en place ?

Après si on veut vraiment assurer la sécurité, on peut mettre en place
un VPN à l'intérieur du réseau local et ne faire écouter les démons
uniquement sur cette interface et'autoriser les accès sur les
ports 22 et Samba (je ne connais pas la plage de ports pour Samba,
probablement TCP/137,138,139). C'est la solution que je mets généralement
en place pour les serveurs qui sont en accès direct sur le net.

De fait l'accès sera autorisé unqiuement aux machines authentifiées sur
le VPN et répondant aux adresses IP fournies par le service VPN et autorisées.

Par contre il ne faut pas que le service VPN tombe et prévoir la
possibilité de redémarrer le service/la machine si le cas, rarissime, se
présentait.

On doit pouvoir faire un filtrage sur couple adresse MAC/IP (c'est probablement ce
que doit faire windows pour identifier ces réseaux publics/privés) mais
je ne sais pas le faire et une adresse MAC se spooffe en 2 coups de cuillère à pot.

Mais on peut supposer que le partge samba est protégé par mot de passe,
ce qui semble la moindre des choses quand on expose des données.

Euh, non, on ne peut certainement pas supposer ça. Il me semble au
contraire évident que Sergio veut exposer son partage sur le réseau
local à toutes les machines qui y sont connectées. Après tout, elles ont
déjà prouvé qu'elles sont dignes de confiance par leur capacité à se
connecter audit réseau local.

Effectivement on ne peut pas le supposer mais on peut que le conseiller.
On peut difficilement ouvrir sa maisons au 4 vents et vouloir qu'elle
soit sécurisée comme une banque.

Et ne jamais oublier que la sécurité n'est qu'une illusion.

Après tout ça ne reste que des propositions. Je suis loin d'être un
expert en la matière.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43

Vous avez filtré cet utilisateur ! Consultez son message

Le 06-10-2017, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<59d73f35$0$10182$) :

Doug713705 , dans le message <or7c4b$omk$, a
écrit :
Pas faux, d'où l'intérêt de bien choisir son réseau local et bien

Tu peux expliquer le critère de « bien », là ?

Ahaha, je me doutais qu'on allait arriver là. Évidement "bien" n'a que
peu de sens mais choisir un réseau autre que 192.168.{0,1}.0/24 permet
d'éviter 90% (au doigt mouillé) des collisions avec les réseaux publics
qui utilisent bien souvent les réglages par défaut, tout au moins sur la
plage réseau utilisée.
Pareil avec certains réseaux dans 10.10.0.0/16 qui sont parfois dans
des conf par défaut de certains équipements réseau (routeur notamment).

entendu d'effectuer un filtrage plus précis, genre machine par
machine.

Ça reste un filtrage par adresse IP, donc totalement inefficace quand on
est connecté à un réseau qu'on ne contrôle pas.

Après il faut aussi mesurer le risque.
- Qu'est qu'on en a faire qu'un quidam tente de se connecter si
tout est bien configuré (accès par clef pour SSH, mot de
passe et autre solution pour samba que je ne connais pas dans
le détail) ?
- Quelle est l'importance des données mise en jeux (les photos de
bobonne sur la plage, le dernier compte rendu financier d'un grand
groupe coté en bourse) ?
- Si la crainte c'est le ransomware, une solution de sauvegarde a t-elle
été mise en place ?
Après si on veut vraiment assurer la sécurité, on peut mettre en place
un VPN à l'intérieur du réseau local et ne faire écouter les démons
uniquement sur cette interface et'autoriser les accès sur les
ports 22 et Samba (je ne connais pas la plage de ports pour Samba,
probablement TCP/137,138,139). C'est la solution que je mets généralement
en place pour les serveurs qui sont en accès direct sur le net.
De fait l'accès sera autorisé unqiuement aux machines authentifiées sur
le VPN et répondant aux adresses IP fournies par le service VPN et autorisées.
Par contre il ne faut pas que le service VPN tombe et prévoir la
possibilité de redémarrer le service/la machine si le cas, rarissime, se
présentait.
On doit pouvoir faire un filtrage sur couple adresse MAC/IP (c'est probablement ce
que doit faire windows pour identifier ces réseaux publics/privés) mais
je ne sais pas le faire et une adresse MAC se spooffe en 2 coups de cuillère à pot.

Mais on peut supposer que le partge samba est protégé par mot de passe,
ce qui semble la moindre des choses quand on expose des données.

Euh, non, on ne peut certainement pas supposer ça. Il me semble au
contraire évident que Sergio veut exposer son partage sur le réseau
local à toutes les machines qui y sont connectées. Après tout, elles ont
déjà prouvé qu'elles sont dignes de confiance par leur capacité à se
connecter audit réseau local.

Effectivement on ne peut pas le supposer mais on peut que le conseiller.
On peut difficilement ouvrir sa maisons au 4 vents et vouloir qu'elle
soit sécurisée comme une banque.
Et ne jamais oublier que la sécurité n'est qu'une illusion.
Après tout ça ne reste que des propositions. Je suis loin d'être un
expert en la matière.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43

Nicolas George

07/10/2017 à 10:08

Doug713705 , dans le message <or8lhf$qfr$, a
écrit :

Après il faut aussi mesurer le risque.

Et pour le coup, tu peux probablement supposer que Sergio l'a déjà fait.
Et contrairement à toi, en connaissant la situation.

Après si on veut vraiment assurer la sécurité, on peut mettre en place
un VPN à l'intérieur du réseau local et ne faire écouter les démons
uniquement sur cette interface et'autoriser les accès sur les
ports 22 et Samba (je ne connais pas la plage de ports pour Samba,
probablement TCP/137,138,139). C'est la solution que je mets généralement
en place pour les serveurs qui sont en accès direct sur le net.

On peut employer de nombreuses solutions baroques, mais ça ne répond
absolument pas à la question, qui est précise et sensée.

On doit pouvoir faire un filtrage sur couple adresse MAC/IP (c'est
probablement ce que doit faire windows pour identifier ces réseaux
publics/privés)

Je suis à peu près sûr que non.

Effectivement on ne peut pas le supposer mais on peut que le conseiller.

Conseiller sans connaître la situation...

On peut difficilement ouvrir sa maisons au 4 vents et vouloir qu'elle
soit sécurisée comme une banque.

Il ne s'agit pas d'ouvrir sa maison aux quatre vents, bien au contraire,
il s'agit de se dire que puisque sa maison est bien fermée, on peut se
permettre de s'y promener en sous-vêtements.

Philippe Weill

13/10/2017 à 08:17

Le 06/10/2017 à 11:56, Sergio a écrit :

Le 06/10/2017 à 10:59, Nicolas George a écrit :
Sergio , dans le message <59d742dc$0$8946$, a
écrit :
Comment fait Windows alors ?

J'ai une tête de commercial Microsoft, peut-être ?
De toute évidence, il se base sur autre chose que juste l'adresse IP.
C'est assez facile.

Si c'est du wifi, il peut se baser sur le SSID de la box, néanmoins, sur mon PC Windows, j'ai plusieurs réseaux avec le même nom :
- "gerard" : ma box en ethernet
- "gerard : ma box en wifi
- "gerard" : résidu d'essai de configuration du wifi
Mon but, en fait, est sur mon poste principal (sous Linux, je rassure) d'utiliser le réseau local filaire (en 192.168.1.x) pour
accéder à internet et aux autres machines (imprimantes, PC sous Linux ou Windows. Et, vue la fiabilité de l'internet via
SFR-Numéricâble, utiliser en dépannage une clef 4G, reliée directement au réseau des réseaux.

dans ton cas je ne démarrerais pas les services samba et ssh au boot du portable de façon standard
un script qui verifie l'interface,l'adresse IP + eventuellement celle de la passerelle de ton portable pour decider du demarrage de
samba et sshd
chez moi cela donnerais si interface eth0 ou wlanO ip 192.168.133.27 et passerelle en 192.168.133.163 ( donné par dhcp fixe par la
freebox )
on a déja moins de chance de le trouver ailleurs
pour la partie 4G cela est simple en cas de double attachement
je suppose que ta clef 4G te montre une nouvelle interface réseau
donc la regle iptable suivante protege ton portable
iptables -A INPUT -p tcp -m multiport --dport 22,139,445 -i NOM_INTERFACE_4G -j DROP

Samba et ssh serveurs : Limiter l'usage

4 réponses

Veuillez sélectionner un problème