Traffic d'une IP non bloqué malgré règle firewall

MatPoweR

Bonjour,

j'ai un pfsense qui gère l'accès à internet,
avec un utilisateur qui abuse de la bande passante, plutôt que de lui courir après, je souhaite lui bloquer l'accès internet

seulement malgré plusieurs tentatives de règles, il continue à sévir
ci-dessous, les règles actuellement en place
{LAN}
/block/ IPv4 TCP/UDP * * 192.168.1.116 * * none pompe a mort
{WAN}
/block/ IPv4 TCP/UDP * * 192.168.1.116 * * none pompe a mort

avez-vous une piste/idée ?

Tatave

Salut salut

Je me pose quelques questions:

la légalité d'un telle action.
l'environnement
la zone d'intervention
le cadre

Pour le coté privé, libre à vous de faire cela.
Pour le coté professionnel, enseignement, associatif, autre … pas sûr que vous en avez la possibilité et ou le droit.

Apres comme je l'ai déjà écrit, aider oui, mâcher le travail non.

Cordialement.

MatPoweR

bonjour,

je ne suis pas juriste mais l'objectif ici n'est pas de regarder les données personnelles de l'utilisateur mais l’empêcher d'abuser d'une ressource fournie dans le cadre d'un travail qui ne nécessite en aucune manière un trafic tel que constaté (trafic type P2P or que le boulot consiste principalement à appeler puis saisir quelques infos dans un CRM).

après l'objectif est de trouver ce qui fait que la règle ne soit pas appliquée,
des liens ou des idées sont les bienvenus.

merci,

ccnet

avez-vous une piste/idée ?

Oui. Que vous commenciez par lire et comprendre la documentation de Pfsense. Cela vous permettra d'écrire une règle qui puisse fonctionner, en dépit de plusieurs réserves importantes. Comme vous allez trouver ma réponse abrupte quelques compléments :
1. La règle Wan ne sert strictement à rien. Vous le comprendrez lorsque vous aurez comprise le fonctionnent de Pfsense.
2. La règle Lan laisse supposer que 192.168.1.116 est l'ip de l’utilisateur. Mais elle n'est pas bonne non plus. Avec plus de précisions sur votre adressage il sera possible d'en dire plus.
3. L'efficacité de ce filtrage, une fois la bonne règle écrite, restera de toute façon douteuse. Il suffit à l'utilisateur de changer d'ip.

Et donc il s'avère que seul un proxy avec authentification pourrait traiter le problème.

Sur le problème lui même, il est plus organisationnel que technique. L'entreprise a t elle mis en place une charte informatique digne de ce nom ? Elle seule permettra de mettre un terme à ce type d'agissement en fournissant le poids hiérarchique et réglementaire qui convient.

Tatave

Salut salut

@Ccnet

je l'avais oublier la charte info :p

@all
je faite d'être ou pas juriste est plus une demande de bon sens éthique.
Comme l'a indiqué Ccnet il y a un manque manifeste de compréhension et de logique
Tout bloquer au mauvaise endroit à tout va, c'est sur vous que cela risque de retomber et pas sur la personne que vous voulez "discipliner".

L'informatique en général est plus une question de bonne / mauvaise pratique, le cas est d'autant plus vrai en entreprise.
Cela est aussi l'affaire d'éducation et de culture informatique à marteler pour tous que cela soit d'un simple utilisateur en passant par un directeur qui pense que par son status de cadre dirigeant le protège sans oublier l'équipe technique qui à aussi un rôle pédagogique et informatif.

Si je ne fais pas erreur, indépendamment de l'idée du proxy est bonne, mais n'avez vous pas aussi la solution du limiteur de bande passante ? sans pour autant fermer le port ou l'accès à cette machine, car certain outils on besoin du p2p pour se mettre à jour ou tout bonnement pour renvoyer des information vers une machine centrale.

Cordialement.

ccnet

Contrôler l'allocation de la bande passante est aussi une option possible. Pfsense sait le faire, Squid aussi.

jdh

Avec ccnet et tatave, tout est dit !

Dans Firewall > Rules, il y a des onglets : ce n'est pas pour rien !
D'où l'inutilité de la règle WAN (comme indiqué par ccnet) !

Vous écrivez

{LAN}
/block/ IPv4 TCP/UDP * * 192.168.1.116 * * none pompe a mort

Ce n'est pas simple à lire !

Vous pourriez écrire

Onglet : LAN / Action : Block / Proto : ipv4 tcp/udp / Source : * / Port : * / Destination : 192.168.1.116 / Port : * / Gateway : * / Queue : * / Schedule : none / Description : pompe a mort

Ce serait plus aisé à lire et … à trouver pourquoi cette règle est totalement inefficace (et ne correspond pas à ce qui est souhaité).

L'informatique, en entreprise, est affaire de bonnes pratiques, mais avant tout d'expertise réseau minimale pour configurer dans le bon sens un firewall !

AMHA il est probable (=prévisible) que cette règle devra être reprise par une vraie (et légale) solution : Squid !

Tatave

Salut salut

@jdh
merci jdh pour ton retour ;o

@all

Dans un cas comme celui d'un débordement d'une mauvaise pratique d'un utilisateur.
Il y a lieu de faire plusieurs choses

vers la direction les alerter de ces mauvaises pratique et de proposer un mise en place d'un sensibilisation des utilisateurs,
vers la direction leur proposer la mise en place de la solution évoquer par Jdh et Ccnet,
vers la direction leur proposer de plancher sur un charte de bonne conduite informatique en relation avec la RH le services Juridique, et les partenaires sociaux (ne pas les oublier si vous ne voulez pas avoir de plus gros soucis).
vers les utilisateurs les informer par la suite de la situation souvent une fois certain état de faites annoncés sur la place publique la personne non nommé en écoutant les collègues à la pause café à fini par changer de comportement. et bien insister sur le point que l'accès à internet est un outil pas un obligation. cela fait partie aussi de l'EDUCATION des utilisateurs.

Après au vus des retours des différents intervenants, direction HR juridique partenaires sociaux, vous aurez ou pas plus de latitudes de mouvements.

MatPoweR

Bonjour,

j’essaierai d'écrire les choses de façon plus lisible, notamment les règles FW
la règle WAN est là car la LAN ne fonctionne pas et du coup, j'ai essayé une règle idiote en désespoir de cause.

les IP sont fournies par le DHCP de pfsense,
l'idée était simplement d'attribuer cette IP en fonction de l'adresse MAC

maintenant, j'aimerais avoir une vraie piste sur mon problème que des débats autour de celui-ci
merci pour toute votre aide.

PS : RTFM + google c'est déja fait avant de venir ici …

ccnet

@MatPoweR:

les IP sont fournies par le DHCP de pfsense,
l'idée était simplement d'attribuer cette IP en fonction de l'adresse MAC
Il est trivial de changer d'adresse mac.

maintenant, j'aimerais avoir une vraie piste sur mon problème que des débats autour de celui-ci
merci pour toute votre aide.

Quoi que vous en pensiez c'est ce qui a été fait. Et si, comme proposé, vous postiez votre règle dans un format lisible, ou une copie d'écran …

PS : RTFM + google c'est déja fait avant de venir ici …

Le résultat n'est pas probant.

jdh

Nous vous avons apporté une réflexion, une méthode (une piste de méthode).
A vous de chercher maintenant !

Je dirais que votre mauvaise configuration vient du fait que vous ne semblez pas avoir compris ce qu'est une "session IP".
Il est probable que vous direz, une fois bien configuré et testé, que votre erreur était assez grosse et bien visible.
Il n'est pas dans nos habitudes de donner la réponse quand l'erreur est aussi flagrante ! Cela n'aurait pas de sens !

MatPoweR

Bonjour,

voici la copie d'écran (la balise [ img ] n'affiche pas l'image :-/),
http://n54i.imgup.net/pfsense-fw446b.png

ccnet

@MatPoweR:

voici la copie d'écran

Manque un clic ou deux surement.

Tatave

Salut salut

En plus d'un certain énervement pâtant de parte et d'autre, je vous propose de remettre les chose à plat.

un schéma du montage de votre pf.
la ou les règles mise en place.
votre but ou besoin.

/troll on /

on retire le café, les clopes et les autres substances, on prend un tranxene et on respire.
on relit les doc sur le web.
on relit les pistes proposition deja faites s'en monter dans les tours.
on prends le Pfsense guide et ou cookbook Pfsense on va faire un tour dans un parc et on revient avec tout ça.
/troll off /

Cordialement mode zen

MatPoweR

@Tatave:

Salut salut

En plus d'un certain énervement pâtant de parte et d'autre, je vous propose de remettre les chose à plat.

un schéma du montage de votre pf.

la ou les règles mise en place.

votre but ou besoin.

/troll on /

on retire le café, les clopes et les autres substances, on prend un tranxene et on respire.

on relit les doc sur le web.

on relit les pistes proposition deja faites s'en monter dans les tours.

on prends le Pfsense guide et ou cookbook Pfsense on va faire un tour dans un parc et on revient avec tout ça.
/troll off /

Cordialement mode zen

voici le schéma du pfsense :
–--- user1
FAI ----- pfsense ----- switch ----- user2
----- user......

il fait également DHCP (192.168.1.50 --> .....200)
les DNS sont ceux du FAI et il gère un VPN IPsec

les règles du LAN sont dans l'image http://n54i.imgup.net/pfsense-fw446b.png

mon but est de pouvoir bloquer un utilisateur et surtout de comprendre pourquoi cela ne fonctionne pas

merci,

jdh

L'image est bonne : facile à lire.
(A défaut d'image, il faudrait utiliser ma notation … qui ne fait que reprendre les colonnes)

Votre règle n'est pas bonne : à vous de trouvez pourquoi, et c'est assez gros !
La logique serait de vous faire tout petit quand vous aurez trouvé votre erreur ...

ccnet

@MatPoweR:

surtout de comprendre pourquoi cela ne fonctionne pas

merci,

C'est assez évident à la vue de la copie d'écran. Vous avez vraiment lu la doc en diagonal et pas compris ce que vous avez lu. Quand on confond source et destination alors que l'utilisation de ces termes est parfaitement défini pour Pfsense …

Tatave

Salut salut

Même moi qui en suis pas un expert, je trouve cette règle inapplicable à votre besoin

Des pistes

qui fait quoi ?
qui va ou ?
qui passe par ou ?

Refaites vous un diagramme de processus de flux avec des fleches, cela m'aide personnellement à écrire mes règles de routage

Cordialement.

jdh

Si, avec les 3 derniers posts, vous n'arrivez pas à corriger, c'est à désespérer …

Maintenant, on attend ... et comme l'erreur est énaauurme ...