Probleme Nat sur port samba (pour imprimer sur print server)

verash

Bonjour a tous,

Me revoici avec un ptit problème. J'utilise le pf dans le reseau interne, ou j'ai séparé les serveurs des machines clientes…L'interface dit "Wan" ne correspond pas réellement à un interface Wan, puisque c'est le réseau ou j'ai mes utilisateurs...(le parefeu est entre l'internet et le 'lan pc user')

La conf est la suivante :

internet==>parefeu==>Lan Pc user ==>(wan int==>Pfsense==>Lan int) ==>Serveurs

Le schéma est bien comme ceci, coté gauche internet avec un parefeu, et le pfsense isole les serveurs…avec au millieu les utilisateurs.

Le problème est le suivant :

Un poste client (dans le lan user) voudrait imprimer sur un serveur qui se trouve derrière le pf. De plus je voudrais aussi prendre le controle du serveur depuis mon poste dans le lan client…

1 - J'ai donc crée un adresse virtuelle .234.12 puis j'ai naté en 1:1 mon adresse virtuel sur celle de mon serveur d'impression (.244.12).

2 - dans le pfsense, sur l'interface dit "wan", J'ai autorisé le reseau utilisateur vers l'adresse naté (.244.12)...puisque le pf natte avant de passer au firewall...

3 - dans le pfsense, sur l'interface dit "Lan", celui ou se trouve mon serveur d'impression, j'ai autorisé TOUTES les connexions du .244.12 vers toutes les adresses des postes utilisateurs...(le serveur doit se connecter des fois à d'autres systemes...

Et lorsque je veux depuis le "lan user" installer une imprimante, il me demande un login/mdp sauf que si je rentre mon login admin, cela ne fonctionne pas...windows me dit acces refusé...

Idem pour l'impression, ou lorsque j'ouvre une file d'impression depuis mon poste user il me marque conexion refusé...

J'ai mis wireshark sur mon poste client pour voir a quel moment il demande l'authentification et voici le message d'erreur :

le 234.12 src port 445 (adresse virtuelle nattée) ==> @ip XX.X (poste user) vers port >1024 ==> spools openprinterEX response, Access Denied

J'ai donc regardé sur les règles bloqué par le pfsense et effcetivement il y a des règles qui bloque...Mais truc super etonnant, il me bloque une requete qui va de :

234.12:445 vers 234.12:>1024 sur l'interface "dit Wan"...

Alors que le nat se passe dans un sens et pas dans l'autre a la rigueur, mais la le nat passe dans les 2 sens, je vais du mstsc sans problème, je peux ouvrir des partages, je pingue evidement, mais des qu'il utilise les ports samba pour du partage d'imprimantes, alors la il part en vrille...

Cela devient du genre le pf recoit la requete initial, il la natte et l'envoi bien au serveur, le serveur repond avec sa vrai adresse qui est natté au retour, mais elle reste dans les tuayx pour rechanger le nat dest et finalement se retrouver avec la meme adresse source et destination...

Chai pas si j'ai été clair, je trouve cela tellement esoterique...

A vot bon coeur m'sieur dames, si qqun a deja eu le meme type de problème, car je pense que ceal doit exister avec les port samba...

J'ai essayer de mettre le serveur dans le meme lan que les user, et j'installe sans problème une imprimante depuis le serveur...Cela provient bien du pfsense et des ports samba...

Merci de votre aide...

jdh

Pourquoi faire simple quand on peut faire compliqué !
Je ne vois aucun intérêt à ce schéma.

Le bon schéma serait le pfsense en position du firewall avec 2 zones (LAN+DMZ) ce qui, sans renoncer à filtrer les flux, éliminerait un NAT qui ne sert à rien !

Quel serait le rôle d'un NAT 1:1 ?
N'y a-t-il pas de partage d'imprimante BEAUCOUP plus simple que SMB/CIFS ?

Pour partager une imprimante, on peut faire très simple avec un serveur dans le LAN
qui, d'une part, accède à une imprimante avec par exemple lpd (515/tcp),
et qui, d'autre part, la propose en local (avec le driver).
Peut-être aussi avec IPP (631/tcp) ou raw (9100/tcp) si l'imprimante est en réseau.

Les partages SMB, quelle galère ! C'est pour cela qu'il faut éviter de placer un serveur Windows en DMZ !
Usuellement c'est FTP ou porte ouverte !
Pourquoi ne pas simplifier avec WEBDAV (80/tcp ????) qui permet une règle élémentaire sans renoncer aux droits (ils seront sans doute différents que dans le LAN).

Bref du complexe où il faudrait simple.

verash

Pour l'utilité du schéma vu comme cela, c'est vrai que ce n'est pas forcement le plus adequat…Il y a des choses que je n'ai pas mentionné, car aucun rapport avec le problème que j'ai...

Pour répondre à tes autres questions :

Le bon schéma serait le pfsense en position du firewall avec 2 zones (LAN+DMZ) ce qui, sans renoncer à filtrer les flux, éliminerait un NAT qui ne sert à rien !

Sauf que je n'ai pas l'autorisation de mettre les (j'en ai 2 en carp-failover sur plusieurs vlan) pfsense en tete de pont…Je suis un site distant du central, et des appli doivent passer en temps réel, mon boss ne voulait donc pas...

N'y a-t-il pas de partage d'imprimante BEAUCOUP plus simple que SMB/CIFS ?
Pour partager une imprimante, on peut faire très simple avec un serveur dans le LAN
qui, d'une part, accède à une imprimante avec par exemple lpd (515/tcp),
et qui, d'autre part, la propose en local (avec le driver).
Peut-être aussi avec IPP (631/tcp) ou raw (9100/tcp) si l'imprimante est en réseau.

Mais c'est déjà ainsi…Mais je voulais faire un vlan impriamnte partant du pf et distribuant sur tout le reseau dans un vlan particulier, le serveur d'impression étant dans une zone secur, il n'y a que lui qui aurait pu prendre le contrôle des imprimantes, et je n'avais qu'à laisser passer les postes clients uniquement vers le serveur d'impression...

Les partages SMB, quelle galère ! C'est pour cela qu'il faut éviter de placer un serveur Windows en DMZ !
Usuellement c'est FTP ou porte ouverte !
Pourquoi ne pas simplifier avec WEBDAV (80/tcp Huh?) qui permet une règle élémentaire sans renoncer aux droits (ils seront sans doute différents que dans le LAN).

Oui pour les serveur Win je connais les galère, mais à force de réflexion ca fini par fonctionner…j'vous jure...ya un ami qui connait un ami à qui c'est arrivé...bon blague à part, c'et vrai que c'et compliqué, mais le pf tient bien la route...Généralement je coupe le netbios sur les serveurs qui n'en ont pas besoin, sauf que la pas possible...je vais donc revoir ma copie et comme tu as dit sans modifier grandement ce que j'ai deja fait, je vais faire des interfaces de control pour prendre la main dessus sur un vlan passant par le pf...

Bref du complexe où il faudrait simple.

Ben le problème c'est qu'a force de faire trop simple tout le monde pourrait etre admin…Et qu'en plus j'aurai jamais rien a faire car quand ca tourne, ca tourne...et plutot bien...alors je suis obligé de montrer que je suis la !!! en faisant des trucs que moi seul comprend, mais des fois meme moi je comprend plus !!! Alors ca fait pro...

En tout cas merci de ta réponse rapide conscit...

ccnet

Ben le problème c'est qu'a force de faire trop simple tout le monde pourrait etre admin…Et qu'en plus j'aurai jamais rien a faire car quand ca tourne, ca tourne...et plutot bien...alors je suis obligé de montrer que je suis la !!! en faisant des trucs que moi seul comprend, mais des fois meme moi je comprend plus !!! Alors ca fait pro...

Ce n'est pas sérieux. L'expérience m'a montré qu'il n'est pas à la porté du premier venu de faire simple. Le "simple" en question est parfois très complexe à concevoir. Toute cette architecture est bien alambiquée et je ne suis pas certain que cela aille dans le sens d'un meilleur niveau de sécurité. La complexité non maitrisée ("mais des fois meme moi je comprend plus") conduit à des erreurs. Invariablement. Elle est donc nuisible à la sécurité. Ici, de plus, la complexité est induite par des erreurs de conception ou d'utilisation (le réseau local sur la patte Wan de Pfsense par exemple). Que vous n'arriviez pas à gérer facilement l'impression au sein de cette architecture est un symptôme.

Je vois invite à méditer cette phrase de Bruce Schneier : "Ipsec est sans doute trop compliqué pour être sûr". Lorsque l'on sait qui est Bruce Schneier …

jdh

(Ce que j'ai oublié de mentionner, c'est que le problème exposé était déjà bien préparé. C'est à noter).

En fait, le problème est donc encore plus complexe que présenté …

Je pense qu'il serait bon de déterminer, parmi les besoins, les vrais besoins.
Et pour ceux là, la transformation permettant une simplification.

On utilise du 1:1 quand on a plusieurs adresses WAN, et qu'on veut absolument associer une ip publique à un serveur.
Par exemple, le firewall sort avec @ip1 mais un serveur smtp reçoit en @ip2, il faut alors que ce serveur sorte aussi en @ip2.
L'utilisation est donc assez rare !

Pour des sociétés multi-sites, je créé toujours un seul serveur d'impression par site, sous windows pour faciliter l'installation.
Mais j'ajoute le service d'impression Unix pour "émuler" un serveur lpd. Donc entre sites, on imprime en lpd entre serveurs.
Simple (1 seul protocole) et pas d'authentification (quel besoin pour imprimer ?)

Avec un serveur Windows, un partage (smb/cifs) peut être remplacé par un partage webdav (en installant IIS ?).
La sécurisation NTFS reste valide alors qu'on utilise plus qu'un protocole et non une foule de tcp, udp avec plein de port.
Mais il reste à s'authentifier !

J'aime des Schneier'facts (comme les Chuck Norris'Facts).
Un exemple : Bruce Schneier's PRNG is truly random, but he can predict its outcome too.

verash

Ce n'est pas sérieux. L'expérience m'a montré qu'il n'est pas à la porté du premier venu de faire simple.

Mais je ne pense pas etre le premier venu, meme si des fois je peux poser des questions a la réponse "facile", j'ai quand meme un certain bagages…et je vous épargnerai mon cv

Le "simple" en question est parfois très complexe à concevoir. Toute cette architecture est bien alambiquée et je ne suis pas certain que cela aille dans le sens d'un meilleur niveau de sécurité.

Je sais que pour un pro de la secu ont peut penser qu'avec un schema tel que celui-la ce n'est pas forcement la meilleure solution, mais le schema est largement incomplet, et pour des raisons de sécurité je ne donne pas toute les informations, mais seulement ce qui me pose problème.

La complexité non maitrisée ("mais des fois meme moi je comprend plus") conduit à des erreurs. Invariablement. Elle est donc nuisible à la sécurité. Ici, de plus, la complexité est induite par des erreurs de conception ou d'utilisation (le réseau local sur la patte Wan de Pfsense par exemple). Que vous n'arriviez pas à gérer facilement l'impression au sein de cette architecture est un symptôme.

La complexité se matrise avec le temps, je ne maitrise pas forcement tous les details du pf, d'ou mes questions (qui ne sont pas si bête puisque samba pose des problèmes au pf !!! Il faut aussi lire entre les lignes, c'etait plus ou moins un blague…
Maintenant sur les erreurs de conceptions, encore une fois il est vrai que sans le schéma entier, impossible de juger...Pourquoi avoir mis les user sur l'interface Wan, pour protéger mes serveurs...filtrer et etre informé de ce qui circule...car dans le schéma, je dispose du controle d'un site qui lui meme fait parti d'un domaine...sauf qu'il n'y a aucun firewall nulle part sur tout le domaine, les seuls firewall sont en tête de pont vers l'internet bien au delà de mon site...

Ensuite mon boss n'a pas voulu que je change les utilisateurs de place (emplacement logique non physique), il me proposait de faire du vlan par les routeurs avec des acls par ip...niveau sécurité 0...car en plus de l'adresse ip qui est modifiable aucune visibilité sur la couche niv2...j'ai donc fait des vlan sur tout le reseau, sans routage intervlan...Les vlan ont tous une passerelle qui sont les pfsense (en carp failover) je peux donc filtrer et voir qui passe...d'ou la mise des serveurs dans un vlan, les imprimantes idem, etc...et les clients reste dans le vlan par default...J'ai fait passer au travers du pfsense, les mises a jour wmsus, sccm, antivirus, divers serveurs d'appli)...et le contrôle de certains interfaces d'admin...(machine virtuelle, centreon nagios etc...)...

En plus puisque c'est un schema peu commun, je te l 'accorde, ca permet au hacker de ne pas savoir sur quel type de schéma il se trouve...et de le faire chercher un peu plus...

Maintenant parlons de securité...Je vous laisse méditer cette phrase de moi : Le réseau n'a pas été crée pour qu'il soit secure, mais fiable...Rajouter toutes les sécurités du monde tant qu'on aura tcp ip, la sécurité n'est que pure fiction...Un bon hacker perce n'importe quel firewall...je parle des vrai hackers, les dangereux, les groupuscule terroristes...D'ailleurs meme les antivurs sont incapable de resister a des jeunes en formation (epita project)...J'ai aussi fait des formations de hackers (car je pense qu'un admin "serieux" doit connaitre les aspects sombres pour mettre une sécurité en place),et c'est incroyable la facilité qu'il peuvent avoir à prendre le control d'une machine...et encore je ne sais que 1 %...j'imagine le reste, quand on pense que les ricains peuvent à distance remettre un reseau en route pour communiquer...En egypte ils ont failli le faire car le president egyptiens avait coupé tout ce qui etait internet etcet ils avaient la possibilité de remettre ca en route (a vrai dire ils font passer un gros awaks avec une antenne wifi enorme et hop ca fonctionne)...Alors niveau securité je pense qu'un pays a de gros moyens, mais comme cest pas secure, avec d'autres moyens on peut toujours passer...

Je vois invite à méditer cette phrase de Bruce Schneier : "Ipsec est sans doute trop compliqué pour être sûr". Lorsque l'on sait qui est Bruce Schneier …

Je suis totalement daccord avec toi sur ce qu'il dit, et il denonce les faille de securité notamment lié au terrorisme…Pourquoi ??? Ben parceque tcp/ip n'est pas fait pour etre secure...!!!cqfd...c'est comme le cambrioleur, il n'existe aucune porte inviolable...c'est juste une question de temps...en info c'est pareil...juste une question de temps...

Quand j'entends par exemple qu'il pourrait exister des bots qui apellerai le 911 pour saturer les lignes de defenses des US et donc faire sauter tout ce qu'il veulent puisque les alarmes seront saturées, quand j'entends que le pentagone est régulièrement piraté, quand j'entends les guerre cyber livrées entre les pays (russie et hongire ou pologne j'sais plus), je me dit que rien ne peux etre totalement secure...a moins de le débrancher du net !!!! Sans parler des centrales nucleaires etc...On est mal !!!

Bon je suis parti tres loin, dsl, ca resoud pas mon problème a vrai dire, j'ai bien pris note de tes remarques qui sont constructives et interessantes et donc je vais essayer de mettre en place, notamemt en generalisant le transfert des imprimantes par le port 9100...

Merci à toi de tes infos et a plus tard...

verash

(Ce que j'ai oublié de mentionner, c'est que le problème exposé était déjà bien préparé. C'est à noter).
µMerci c'est sympa, avec l'intervention de ccnet, j'avais le moral a 0…lol...

En fait, le problème est donc encore plus complexe que présenté …
re-lol…

Je pense qu'il serait bon de déterminer, parmi les besoins, les vrais besoins.
Et pour ceux là, la transformation permettant une simplification.

200% avec toi…

On utilise du 1:1 quand on a plusieurs adresses WAN, et qu'on veut absolument associer une ip publique à un serveur.
Par exemple, le firewall sort avec @ip1 mais un serveur smtp reçoit en @ip2, il faut alors que ce serveur sorte aussi en @ip2.
L'utilisation est donc assez rare !

Oui, perso je l'utilise pour transférer toutes les protocoles vers un serveur…J'avais bien fait des bridges avant, mais le problème c'est posé car je voulais faire du vlan sur un bridge, chose possible avec pf, mais impossible avec pfsense...a l'époque toi ou ccnet m'avait répondu qu'on ne pouvait pas avoir le beurre et l'argent du beurre (en gros), et que tout n'était pas forcement implémenté car le pfsense était une trousse a outils...j'avais donc modifié les schéma en faisant du nat 1:1...

Pour des sociétés multi-sites, je créé toujours un seul serveur d'impression par site, sous Windows pour faciliter l'installation.
Mais j'ajoute le service d'impression Unix pour "émuler" un serveur lpd. Donc entre sites, on imprime en lpd entre serveurs.
Simple (1 seul protocole) et pas d'authentification (quel besoin pour imprimer ?)
Oui mais je doit avoir un serveur spare au cas ou…(tout est doublé). Le serveur est déjà en 9100 vers les imprimantes, mais les user atteigne le serveur d'impression par les partages samba...d'ou mon problème

Avec un serveur Windows, un partage (smb/cifs) peut être remplacé par un partage webdav (en installant IIS ?).
La sécurisation NTFS reste valide alors qu'on utilise plus qu'un protocole et non une foule de tcp, udp avec plein de port.
Mais il reste à s'authentifier !

C'est effectivement une méga solution, qui m'a l'air propre, il est vrai que je ne connais pas webdav (juste de nom), je vais plancher des maintenant sur ca…Merci pour la soluce...J'aurai préféré que pfsense passe bien le samba, mais bon le principal est de maitriser les éléments installés...

ccnet

Je sais que pour un pro de la secu ont peut penser qu'avec un schema tel que celui-la ce n'est pas forcement la meilleure solution, mais le schema est largement incomplet,

Je ne vois pas comment, si un schéma partiel montre que l'infrastructure n'est pas sûre (ce que d'ailleurs je n'ai pas dit, je dis juste qu'elle est alambiquée) elle pourrait être considéré e comme sûre avec un schéma complet. L'étendu du schéma ne change rien aux problèmes de conception.

et pour des raisons de sécurité je ne donne pas toute les informations, mais seulement ce qui me pose problème.

Cette tarte à la crème je l'entend et la lis régulièrement. C'est la conception qui doit assurer la sécurité pas le fait de la cacher.

verash

Je ne vois pas comment, si un schéma partiel montre que l'infrastructure n'est pas sûre (ce que d'ailleurs je n'ai pas dit, je dis juste qu'elle est alambiquée) elle pourrait être considéré e comme sûre avec un schéma complet. L'étendu du schéma ne change rien aux problèmes de conception.

Dans l'absolu aucune infra est sur, mais tu ne dit pas ca donc…je ne dit pas ca non plus...Elle est alambiquée, ben un peu comme moi, ca permet d'arriver a des trucs sympa des fois genre un squid en proxy bridge transparent avec authentification AD et proxy parent...

Tu parles de problèmes de conceptions, je suis parti du principe qu'il me fallait une vision "temps reel", et qu'il fallait que les communications passent par un point et un seul (enfin 2 puisque je suis en carp failvoer sur des vlans)...tout en me permettant de filtrer et d'isoler des réseaux comme dans les salles de réunions par exemple qui sont une populations "extérieure" et donc aucun accès au serveurs internes, les imprimantes qui n'ont besoin d'être contacté que par les serveurs d'impression, le serveur antivirus qui ne doit pas recevoir de comm des clients mais juste du serveur parent, des réseaux sensibles avec accès très restreins, voir aucun accès sauf les admins (réseau dans le réseau)...etc etc...

A partir de la et quand tu sais que tu n'a pas la maitrise à 100 % de l'endroit ou tu te trouves, sachant qu'il ne fallait pas que les user soient pris en otages et que tout à été fait sans aucune coupure de services et sans travailler les we (ttes les facons on est en 3X8 7X7),

Maintenant je en pense pas être en faute de conception...je pense avoir fait les bon choix quand à la conception, même si cela semble ésotérique pour toi et compliqué, je maitrise le schéma, il est stable, les communications sont séparées et comme je visionne les logs grace à (en cours de realisation) nagios/centreon, cela me permet de savoir ce qui n'est pas autorisé par reseaux...Certe je n'ai pas encore la possibilité d'isoler une machine qui n'aurait pas le droit à circuler sur un réseau, mais je cherche des solutions...

Maintenant penses-tu réelement que j'ai fait des erreurs et si oui dit moi lesquelles...Dit moi la théorie voir si elle peut coiincider avec ma réalité...Tout en te répétant une fois encore quà mon avis une conception "classique" permet au hackers de faires des attaques "classiques"...Une conception plus rare, peut lui causer plus de soucis...Mais et pour finir comme dit la pub firestone :

Sans la maitrise la puissance n'est rien !!!

Cette tarte à la crème je l'entend et la lis régulièrement. C'est la conception qui doit assurer la sécurité pas le fait de la cacher.

Oui c'est vrai, mais étant parano de nature, vivons heureux, vivons caché…