question pour ipchains

[HadaDeLaLuna]

Bonjour,

Voilà... j'ai un serveur Free-EOS (basé sur e-smith /sme server)

et j'ai un souci avec ipchains

je souhaite qu'il interdise à certains postes d'envoyer des courriels mais en laissant les dits postes:
-* utiliser la webmail imp du serveur passerelle
-* ainsi que de surfer et d'utiliser les webmails du genre yahoo gmail et autres formulaires de contact

(en fait c parce que ces postes envoient des courriels avec des adresses autres que celles hébergées et dépassent les quotas du smtp donc je ne veux plus qu'ils envoient quoi que ce soit depuis outlook et autres d'autant que ce sont des postes sans utilisateur attitré)

je lui ai donc dit (au bon endroit pour modifier les templates)

Code: Tout sélectionner

# bloquer depuis le poste nomduposte
/sbin/ipchains -I -p tcp -s nomduposte -d all -j DENY
/sbin/ipchains -I -p udp -s nomduposte -d all -j DENY

résultats (depuis "nomduposte"):

• il semble que plus rien n'arrive sur les boites courriels du serveur même le spam (aux exceptions portées ci dessous)
• avec la webmail imp du serveur passerelle on peut envoyer des courriels au moins vers gmail mais yahoo n'a pas encore reçu ceux envoyés hier (pas de failure notice mais elles mettent une semaine à arriver en général)
• entre gmail et yahoo pas de problème
• depuis yahoo vers une boite mail du serveur: une failure notice "permanent error" (couriel envoyé hier juste après la mise en place des règles ci dessus) un nouveau envoyé là pas encore reçu ni de failure notice pour le moment
• depuis gmail: un courriel est arrivé (envoyé juste après la mise en place des règles ci dessus) et pas de failure notice pour l'autre envoyé aujourd'hui (pour le moment du moins)
• entre les boites sur le serveur: pas de problème ça fonctionne
• formulaire de contact sur mon serveur: pas de problème
• formulaire de contact sur un autre serveur (mais envoyant vers une de mes boites): rien reçu à l'instant...
• edit: les double bounces tombent toujours dans la boite admin cependant...

:shock:
bref, j'ai l'impression de m'être largement gourrée (ou pas ?)... (je sais qu'il y a ipchains sur le serveur depuis 3 jours alors que ça fait 3 ans que je l'ai et je ne sais pas trop quoi penser n'y connaissant pas grand chose...)

donc si par hasard qqun a des idées comment faire à la place... merci d'avance

(si j'aurais du poster ailleurs dans le forum merci de déplacer ce message)

[jibe]

Salut,

Ce document devrait déjà pas mal dégrossir ton problème. Je te le laisse lire et revenir demander ce dont tu as besoin comme éclaircissements pour aller plus avant.

Tu me sembles être bien partie, mais tes règles me paraissent à priori curieuses (mais bon, ça fait longtemps que je n'ai plus pratiqué Ipchains et mes souvenirs peuvent me trahir). J'ai l'impression que tu bloques tout ce qui sort du poste ! Soit je me trompe, soit ça ne fonctionne pas pour je ne sais quelle raison (la façon dont tu as mis les règles en place ?). En effet, dans ce cas le poste ne devrait plus communiquer du tout (sauf pour ce qui n'est ni tcp ni udp).

Mais bon, lis déjà mon topo, donne-moi le temps de le relire et on essaiera d'étudier ça de plus près.

Pour tes double bounces, il y a une méthode décrite sur le site de Swerts-Knudsen. Je l'ai indiquée à plusieurs utilisateurs de FreeEOS, mais je n'ai jamais pu obtenir de retour. Je ne sais donc pas si elle fonctionne sur FreeEOS (SME 5.5, alors que la manip est donnée pour SME 6). AMHA, il n'y a pas gros risque à essayer et il y a des chances que ça fonctionne. (faudra quand même que j'arrive un jour à finir de remonter ma FreeEOS de test !...)

[tomtom]

Serieux, ça existe encore des pare-feux sous IPChains ????

Je peux perdre les pédales aussi, mais dans mon souvenir il faus specifier un nom de chaine (INPUT, OUTPUT, FORWRD ?) après le -I.

Par ailleurs, IPChains ne faisait pas de résolution de nom je pense, donc "nomduposte" devrait etre une adresse ip !


Enfin, pour bloquer jsute les mails, il faudrait bloquer uniquement les bons ports.... (-p n° port).



Pour finir, je dirai que la méthode est pkus qu'approximative... Il vaut miex bien comprendre ce que l'on fait avant de bricoler IPChains...
Tu as visiblement un problème de messagerie, ça ne se résoudra probablement pas juste avec des règles de firewall !


t.

[jibe]

Serieux, ça existe encore des pare-feux sous IPChains ????

Ben oui : FreeEOS en version actuelle (1.3.3) est toujours basée sur SME 5.5 (quoi que bien patchée !), donc sous noyau 2.2 et donc Ipchains. FreeEOS se prépare donc à un grand saut avec sa version 2 : passer du noyau 2.2 de SME 5.5 au 2.6 de SME 7.2, voire SME 8 !

Je peux perdre les pédales aussi, mais dans mon souvenir il faus specifier un nom de chaine (INPUT, OUTPUT, FORWRD ?) après le -I.

C'est aussi ce qui me semblait. Je vérifierai, mais c'est probablement ça.

Par ailleurs, IPChains ne faisait pas de résolution de nom je pense, donc "nomduposte" devrait etre une adresse ip !

Tiens, il me semblait pourtant bien que si... Quoique je ne l'avais pas utilisé dans les modifs que j'avais faites et qui ont débouché sur mon howto... Tu es sûr de cette non-résolution ?

Enfin, pour bloquer jsute les mails, il faudrait bloquer uniquement les bons ports.... (-p n° port).

Bien évidemment ! Et peut-être aussi bloquer dans les deux sens... Quoi que HadaDeLaLuna parle d'interdire les envois seulement... Il serait peut-être bon que tu confirmes ce que tu désires exactement, HadaDeLaLuna (bien qu'à la relecture, ça me paraisse assez clair).

Tu as visiblement un problème de messagerie, ça ne se résoudra probablement pas juste avec des règles de firewall !

Oui, il sera peut-être bon de refaire un point précis des problèmes et des besoins. Il m'a semblé :
- Qu'il y a quelques problèmes au niveau de la messagerie (les mails qui n'arrivent pas tous n'ont rien à voir avec les changements effectués dans ipchains). Ces problèmes seront à traiter par d'autres moyens que des règles ipchains (sauf peut-être les bouncing bouces ? Jamais fait ça avec le firewall, mais est-ce que ça pourrait être un bon moyen ?)
- Qu'il y a un désir d'interdire l'envoi de mails depuis certains postes, et cela me parait assez simple et bien de le faire par quelques règles ipchains.

Merci pour tes remarques et conseils, tomtom. Si tu en as d'autres, ils seront bienvenus

[tomtom]

t;]Par ailleurs, IPChains ne faisait pas de résolution de nom je pense, donc "nomduposte" devrait etre une adresse ip !

Tiens, il me semblait pourtant bien que si... Quoique je ne l'avais pas utilisé dans les modifs que j'avais faites et qui ont débouché sur mon howto... Tu es sûr de cette non-résolution ?

Non...
A vrai dire si la résolution ne se faisait pas, la commande retournerait une erreur.... donc ça doit se faire


t.

[jibe]

Bien qu'ipchains sache faire la résolution de noms en traitant les règles du firewall, nous travaillerons avec des adresses numériques, ce qui évite une recherche DNS pour chaque règle.

Si j'en juge par ce que j'ai écrit dans mon howto, il est normal qu'il n'y ait pas de message d'erreur

Il va falloir que je révise sérieusement !

[tomtom]

Il va falloir que je révise sérieusement !

Bof, réviser IPChains....

[HadaDeLaLuna]

he, beh, ça a causé pendant mon absence

Bonjour jibe et tomtom

Ce document devrait déjà pas mal dégrossir ton problème. Je te le laisse lire et revenir demander ce dont tu as besoin comme éclaircissements pour aller plus avant.

Tu me sembles être bien partie, mais tes règles me paraissent à priori curieuses (mais bon, ça fait longtemps que je n'ai plus pratiqué Ipchains et mes souvenirs peuvent me trahir). J'ai l'impression que tu bloques tout ce qui sort du poste ! Soit je me trompe, soit ça ne fonctionne pas pour je ne sais quelle raison (la façon dont tu as mis les règles en place ?). En effet, dans ce cas le poste ne devrait plus communiquer du tout (sauf pour ce qui n'est ni tcp ni udp).

Mais bon, lis déjà mon topo, donne-moi le temps de le relire et on essaiera d'étudier ça de plus près

Ce que j'ai posté je l'ai écris après avoir lu ton topo (entre autres) et le script ne bloque pas la navigation du tout... donc j'attends que tu te remémore les informations entre les lignes

Serieux, ça existe encore des pare-feux sous IPChains ????

oui, dans la Free-EOS en cours (dixit jibe plus haut), et le souci c'est qu'en attendant la nouvelle version plus personne ne se souvent comment on fait et que les How-To et autre modes d'emplois s'adressent à un public "au courant" mais qui a oublié entretemps...

Je peux perdre les pédales aussi, mais dans mon souvenir il faus specifier un nom de chaine (INPUT, OUTPUT, FORWRD ?) après le -I.

étant passée en coup de vent hier soir, j'ai testé avec OUTPUT après le -I: ça donne exactement la même chose... peut être que j'eusse du redémarrer le serveur ? (je ne sais pas je suggère ce qui me traverse l'esprit, je n'ai fait que "/sbin/e-smith/signal-event ip-change")

Par ailleurs, IPChains ne faisait pas de résolution de nom je pense, donc "nomduposte" devrait etre une adresse ip !

si si, j'ai trouvé cela dans plusieurs How-To (mais jibe ne cause mieux que moi plus haut)

Enfin, pour bloquer jsute les mails, il faudrait bloquer uniquement les bons ports.... (-p n° port).

je ne suis pas ingénieurs réseaux (sinon je n'aurais pas pris une distribution où on est sensés ne rien tripoter dedans) on fait comment pour localiser un port ? (he oui c'est de ce niveau, je suis vulgarisatrice pas experte) et est ce qu'on peut interdire simplement les sorties ? (les entrées je m'en moque) et surtout sans empécher l'utilisation des webmail,s forumaires de contacts en ligne, etc.

Tu as visiblement un problème de messagerie, ça ne se résoudra probablement pas juste avec des règles de firewall !

sauf que ces problèmes (à part la saturation des sorties pour cause de trops de courriels envoyés au SMTP tiers) sont apparus en mettent le script pour ipchains sur le serveur...

Hi. This is the qmail-send program at yahoo.com.
I'm afraid I wasn't able to deliver your message to the following
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<unedesboites@undesdomainesvirtuels.com>:
Sorry, I wasn't able to establish an SMTP connection. (#4.4.1)
I'm not going to try again; this message has been in the queue too
long.

--- Below this line is a copy of the message.

Return-Path: <pseudoyahoo@yahoo.fr>
Received: (qmail 78192 invoked by uid 60001); 16 Nov 2007 11:19:43
-0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=yahoo.fr;

h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;

b=lSsS/tAeORwPDmXd++yG4ucHo5+kLkYZd0ABarvKF6ZnX0CbE7kv+
qoLvnYVJAlp3FxWqJACUWwPhU8h4y3h0OrR9FXLc4rMJWOh70d2aaUDE6WV
Q4w+8TSPMTc0wz020+Hx1Fg4Jj6akmeAwl2wnLdU9NiMx7Rm3czqHKRSD/g=;
X-YMail-OSG:
HJeL_HoVM1kWAErND0QHmbBb.smlgH9_BlmOSN.RT_Gi6b5eJer0cEc56.ObCgxFgadFoQDT39sQo_VCoRoaahdhQiMBIRpD9g1LLfdIkJhnVWCn
Received: from [xx.xx.xx.xx] by web27705.mail.ukl.yahoo.com via
HTTP; Fri, 16 Nov 2007 12:19:42 CET
Date: Fri, 16 Nov 2007 12:19:42 +0100 (CET)
From: NN <pseudoyahoo@yahoo.fr>
Subject: Tr: test yahoo depuis pcabloquer
To: unedesboites@undesdomainesvirtuels.com
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="0-1774897613-1195211982=:71466"
Content-Transfer-Encoding: 8bit
Message-ID: <941722.71466.qm@web27705.mail.ukl.yahoo.com>

--0-1774897613-1195211982=:71466
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit



NN <pseudoyahoo@yahoo.fr> a écrit : Date: Thu, 15 Nov 2007 21:44:00
+0100 (CET)
De: NN <pseudoyahoo@yahoo.fr>
Objet: test yahoo depuis pcabloquer
À: unedesboites@undesdomainesvirtuels.com

pour voir...

Pour vous donner des idées de la cause puisque vous vous y connaissez certainement mieux que moi (je découvre depuis 3 jours seulement)

Il va falloir que je révise sérieusement !

Bof, réviser IPChains....

c'est le problème quant je pose des questions sur lui, personne ne se souvient de ce qu'il faut faire, c'est trop loin et réviser ne sert à rien sauf pour me répondre...

Pour le moment, j'ai fait un rm sur le fichier et carrément rebooté le serveur... j'ai besoin de mes boites courriels pour ratrapper mon retard par ailleurs (je ne suis pas informaticienne) et je viens d'envoyer des courriels de test depuis mes webmails... pour voir si c rétabli comme avant

donc à vot'bon coeur m'sieurs dames, s'ils vous reste des bribes de souvenirs sur comment faire pour bloquer les courriels en sortie sans bloquer la navigation et l'utilisation des webmails (même sur le serveur passerelle) et autres formulaires de contact... c'est très pénible de devoir renvoyer une bonne partie de ses courriels 5 jours après parce qu'ils n'ont pas été envoyés pour cause de saturation du SMTP (mais moins que de ne plus rien envoyer ni recevoir, ou presque, comme avec le script)

[jibe]

Salut,

Mon temps est un peu limité ce soir, mais ne t'inquiète pas, je reviendrai et on trouvera bien la solution. C'est vrai que ça fait longtemps que je n'ai pas travaillé sur ipchains, mais je devrais bien savoir refaire ce que j'avais fait !

En attendant que je regarde d'un peu plus près, quelques remarques et précisions :
- Il serait préférable que tu fasses les essais sur une FreeEOS de tests. Si tu n'as pas de matos dispo, tu peux peut-être le faire avec VMWare ou autre émulateur (j'ai fait un tuto pour qemu, mais il faut le compléter avec un échange qui a eu lieu sur le forum FreeEOS). Cela simplement pour t'éviter des problèmes de mails pendant la mise au point

le script ne bloque pas la navigation du tout... donc j'attends que tu te remémore les informations entre les lignes

Si, je t'assure que tout fonctionne bien, je l'ai mis en place chez des clients et sur mon serveur perso. Mais j'ai surtout donné le principe, et si ce que tu veux faire peut bien s'appuyer dessus, il y a quand même quelques adaptations à faire.

En gros (j'essaierai de te préciser demain ou Lundi), il faut arriver à bloquer en OUTPUT (tu avais bien compris !) tout ce qui transite par le port 25 en provenance des postes n'ayant pas le droit d'envoyer d'emails (25 est le port réservé au SMTP). Quelque chose du genre :

Code: Tout sélectionner

/sbin/ipchains -I OUTPUT 1 -p 25 -s pc_a_bloquer -d all -j DENY

Je te confirme et te replace ça un peu dans le contexte de mon tuto prochainement...

[tomtom]

Ca fait longtemps que je n'ai pas fait d'IPChains, mais je pense qu'il y a confusion.
Si ton Free-EOS ets passerelel, il fait surement du nat.
Du coup, au moment du OUTPUT, l'adresse source risque d'avoir été modifiée....


Moi je jouerai au niveau de la chaine FORWARD, donc :

Code: Tout sélectionner

ipchains -I FORWARD -p tcp -s ipduposte --dport 25 -j REJECT


Mais je comprends pas vraiment ton problème : via quel SMTP tes postes clients envoient-ils leurs mails ? C'ets probablement les ocnnexions vers ces serveurs qu'il faut bloquer, et non le SMTP sortant....


D'une manière générale, décris l'architecture utilisée, les services utilisés sur ton serveur, et ce que tu souhaites faire !


t.

[jibe]

Salut,

Bon, c'est vrai que je me posais un peu certaines questions, et effectivement je me demande s'il n'y a pas plusieurs choses dans ce que cherche à faire HadaDeLaLuna :

(en fait c parce que ces postes envoient des courriels avec des adresses autres que celles hébergées et dépassent les quotas du smtp donc je ne veux plus qu'ils envoient quoi que ce soit depuis outlook et autres d'autant que ce sont des postes sans utilisateur attitré)

Si je comprends bien, il faudrait :
- Interdire les envois de mail via le serveur SMTP interne de FreeEOS,
- Interdire les envois de mail via des serveurs SMTP externes divers.

Mais ceci pose plusieurs questions :
- Comment se fait-il que les postes dépassent leur quota s'ils envoient des mails via d'autres serveurs ? Quels sont exactements ces quotas dont tu parles ? Les quotas définis sur SME, des quotas définis par ton FAI, ou d'autres ?
- Comment les postes peuvent-ils envoyer des courriers "avec des adresses autres que celles hébergées" ? Moi, j'appelle ça du relaying, et par quels SMTP passent-ils pour que ce relaying soit autorisé (sauf bien sûr si c'est le SMTP de ton FAI) ? Ou alors, je n'ai pas compris ?
- Qu'est-ce que tu penses que ça changera s'ils utilisent le webmail ? Désolé, cela remet peut-être en cause ta manière de voir les choses, mais je pense que ça vaut la peine de se poser la question : soit c'est moi qui comprends mal ton problème, et l'éclaircissement de ce point pourrait peut-être m'aider à y voir clair, soit tu pars sur une mauvaise idée, et c'est mieux de s'en apercevoir avant de modifier le comportement normal de FreeEOS...
- N'est-il pas plus simple de désactiver le serveur mail de FreeEOS et de laisser les utilisateurs se débrouiller avec le webmail correspondant à leur BAL ? En effet, pourquoi se compliquer la vie si le serveur mail de FreeEOS n'est pas vraiment utile et que les utilisateurs utilisent des adresses externes ?

[HadaDeLaLuna]

Bonjour,

En attendant que je regarde d'un peu plus près, quelques remarques et précisions :
- Il serait préférable que tu fasses les essais sur une FreeEOS de tests. Si tu n'as pas de matos dispo, tu peux peut-être le faire avec VMWare ou autre émulateur (j'ai fait un tuto pour qemu, mais il faut le compléter avec un échange qui a eu lieu sur le forum FreeEOS). Cela simplement pour t'éviter des problèmes de mails pendant la mise au point

ça me parait très diffficile à faire, voire impossible, la plupart des postes sont des vieux coucous saturés (achetés d'occases en 2003!)

En gros (j'essaierai de te préciser demain ou Lundi), il faut arriver à bloquer en OUTPUT (tu avais bien compris !) tout ce qui transite par le port 25 en provenance des postes n'ayant pas le droit d'envoyer d'emails (25 est le port réservé au SMTP). Quelque chose du genre :

Code: Tout sélectionner

/sbin/ipchains -I OUTPUT 1 -p 25 -s pc_a_bloquer -d all -j DENY

Je te confirme et te replace ça un peu dans le contexte de mon tuto prochainement...

oki, j'attends...

Ca fait longtemps que je n'ai pas fait d'IPChains, mais je pense qu'il y a confusion.
Si ton Free-EOS est passerelle, il fait surement du nat.
Du coup, au moment du OUTPUT, l'adresse source risque d'avoir été modifiée....

en fait, les poste ont une adresse fixe à partir de l'adresse du port ethernet car servent aussi pour les appareils ne possédant pas de driver linux (donc par exemple servent à imprimer d'où libre service car les postes linux ne peuvent pas imprimer directement via Free-EOS du coup)

Nom d'hôte Visibilité Emplacement IP locale IP globale Adresse Ethernet
clamav.nomdedomaine.net Local Self
nomduserveur.nomdedomaine.net Local Self
posteabloquer.nomdedomaine.net Local Local 192.168.105.66 00:02:B3:B4:40:95

Moi je jouerai au niveau de la chaine FORWARD, donc :

Code: Tout sélectionner

ipchains -I FORWARD -p tcp -s ipduposte --dport 25 -j REJECT


je note..

Mais je comprends pas vraiment ton problème : via quel SMTP tes postes clients envoient-ils leurs mails ? C'ets probablement les ocnnexions vers ces serveurs qu'il faut bloquer, et non le SMTP sortant....

il est probable qu'ils l'envoient vers le SMTP de Free qui est est mon FAI, car je contaste qu'avec moins d'une 10aines de courriels par jours, j'ai des temps d'envois de l'ordre de plusieurs jours et des "failure notice" avec des "too many connections" depuis mon adresse IP "Free"

D'une manière générale, décris l'architecture utilisée, les services utilisés sur ton serveur, et ce que tu souhaites faire !

Un serveurs Free-EOS 1.3-3 configuré d'origine sans aucune modifications que celles tentées pour bloquer les courriels (sujet de ce topic) et 3 ateliers avec
mofication des htaccess (mais c'est sans rapport avec le topic), le serveur sert de passerelle et:

Paramètres de réseau
Mode serveur servergateway
Adresse IP locale / masque de sous-réseau 192.168.105.1/255.255.255.0
Adresse IP externe / masque de sous-réseau /255.255.255.0
Passerelle
Réseaux locaux supplémentaires Aucun réseau supplémentaire défini
Serveur DHCP enabled
Début de l'intervalle d'adresses DHCP 192.168.105.65
Fin de l'intervalle d'adresses DHCP 192.168.105.250
Noms de serveur
Serveur DNS
Serveur Web www.nomdedomaine.net
Serveur mandataire proxy.nomdedomaine.net:3128
Serveur FTP ftp.nomdedomaine.net
Serveurs de courrier électronique SMTP, POP et IMAP mail.nomdedomaine.net
Informations de domaine
Domaine principal nomdedomaine.net
Domaines virtuels .... liste de 36 domaines et sous domaines hébergés ...
Site Web principal http://www.nomdedomaine.net
Administration du serveur EOS Server http://nomserveur/server-manager/
Gestion du Mot de passe utilisateur http://nomserveur/user-password/
Adresses de courrier électronique useraccount@nomdedomaine.net
firstname.lastname@nomdedomaine.net
firstname_lastname@nomdedomaine.net

Il y a un boitier routeur derrière la passerelle et tous les PC sont branchés directement dessus

Bon, c'est vrai que je me posais un peu certaines questions, et effectivement je me demande s'il n'y a pas plusieurs choses dans ce que cherche à faire HadaDeLaLuna :

(en fait c parce que ces postes envoient des courriels avec des adresses autres que celles hébergées et dépassent les quotas du smtp donc je ne veux plus qu'ils envoient quoi que ce soit depuis outlook et autres d'autant que ce sont des postes sans utilisateur attitré)

Si je comprends bien, il faudrait :
- Interdire les envois de mail via le serveur SMTP interne de FreeEOS,
- Interdire les envois de mail via des serveurs SMTP externes divers.

oui, surtout celui de Free, puisque la configuration de la messagerie au niveau du serveur est la suivante:

Les avis administratifs générés par le serveur EOS sont normalement envoyés par courrier électronique au compte admin. Si vous voulez qu'ils soient envoyés à une autre adresse de courrier électronique, entrez-la ci-dessous. Sinon, laissez ce champ vide.

Adresse de renvoi pour les avis administratifs

Chaque fois que le serveur EOS reçoit un message destiné à un usager inconnu, il peut le retourner à l'expéditeur avec un message d'erreur (pratique recommandée) ou l'envoyer à votre administrateur de système (sous la forme d'un avis administratif).

Courrier électronique destiné à des utilisateurs inconnus Retourner à l'expéditeur

Le serveur EOS peut transmettre des messages sortants directement jusqu'à leur destination (recommandé dans la plupart des cas) ou bien, il peut les transmettre en passant par le serveur SMTP de votre fournisseur d'accès (recommandé si votre connexion Internet n'est pas fiable ou si vous utilisez un service Internet résidentiel). S'il passe par le serveur SMTP de votre fournisseur d'accès, précisez son nom d'hôte ou son adresse IP ci-dessous. Sinon, laissez ce champ vide.

Serveur SMTP du fournisseur d'accès Internet smtp.free.fr

Vous pouvez contrôler l'accès à vos serveurs POP et IMAP. Le paramètre Confidentiel ne permet l'accès qu'à partir de votre ou vos réseaux locaux et le paramètre Public permet l'accès à partir de n'importe quel point sur Internet.

Accès serveurs POP et IMAP Public

Vous pouvez activer ou désactiver la messagerie Web sur ce système. La messagerie Web permet aux usagers d'accéder à leur courrier à l'aide d'un navigateur Web ordinaire. Pour cela, il leur suffit de pointer vers l'adresse nomduserveur.nomdudomaineserveur.net/webmail et de se connecter à leur compte.

Activer/désactiver la messagerie Web Activé (HTTPS seulement)

Mais ceci pose plusieurs questions :
- Comment se fait-il que les postes dépassent leur quota s'ils envoient des mails via d'autres serveurs ? Quels sont exactements ces quotas dont tu parles ? Les quotas définis sur SME, des quotas définis par ton FAI, ou d'autres ?

par le FAI, il n'y a pas de quota particulier par le serveur (ou alors c'est d'origine et je n'ai rien modifié)

- Comment les postes peuvent-ils envoyer des courriers "avec des adresses autres que celles hébergées" ? Moi, j'appelle ça du relaying, et par quels SMTP passent-ils pour que ce relaying soit autorisé (sauf bien sûr si c'est le SMTP de ton FAI) ? Ou alors, je n'ai pas compris ?

il suffit de configurer un client mail avec n'importe quoi, je peux parfaitement créer une adresse mail du genre "louis14@palaisdeversailles.gouv" et envoyer n'importe quoi avec, bien sur le problème est au niveau du SMTP du FAI qui récupère tout ce qui vient de mon IP et les transmets, sauf qu'il ya un quota et que c'est pour ça que je veux bloquer ces courriels non autorisés

- Qu'est-ce que tu penses que ça changera s'ils utilisent le webmail ? Désolé, cela remet peut-être en cause ta manière de voir les choses, mais je pense que ça vaut la peine de se poser la question : soit c'est moi qui comprends mal ton problème, et l'éclaircissement de ce point pourrait peut-être m'aider à y voir clair, soit tu pars sur une mauvaise idée, et c'est mieux de s'en apercevoir avant de modifier le comportement normal de FreeEOS...

ils ne peuvent pas utiliser la webmail IMP du serveur, seule moi et certaines personnes ne venant jamais on un login dessus, et si ils veulent ils peuvent (et doivent) utiliser les yahoo, gmail et autres... donc aucun poste ne doit empécher l'envoi via les webmails, par contre via les clients mails si, rien ne doit passer sauf ceux des postes linux

- N'est-il pas plus simple de désactiver le serveur mail de FreeEOS et de laisser les utilisateurs se débrouiller avec le webmail correspondant à leur BAL ? En effet, pourquoi se compliquer la vie si le serveur mail de FreeEOS n'est pas vraiment utile et que les utilisateurs utilisent des adresses externes ?

je vois pas le rapport, le souci c'est un blocage de quotas du FAI, le serveur mail de Free-EOS sert surtout à recevoir les courriels et aux gens qui ont besoin de la webmail avec le nom de domaine, pas les gens en local

[jibe]

Salut,

- N'est-il pas plus simple de désactiver le serveur mail de FreeEOS et de laisser les utilisateurs se débrouiller avec le webmail correspondant à leur BAL ? En effet, pourquoi se compliquer la vie si le serveur mail de FreeEOS n'est pas vraiment utile et que les utilisateurs utilisent des adresses externes ?

je vois pas le rapport, le souci c'est un blocage de quotas du FAI, le serveur mail de Free-EOS sert surtout à recevoir les courriels et aux gens qui ont besoin de la webmail avec le nom de domaine, pas les gens en local

Oui, oublie : je n'avais effectivement pas compris ton problème !

En attendant que je regarde d'un peu plus près, quelques remarques et précisions :
- Il serait préférable que tu fasses les essais sur une FreeEOS de tests. Si tu n'as pas de matos dispo, tu peux peut-être le faire avec VMWare ou autre émulateur (j'ai fait un tuto pour qemu, mais il faut le compléter avec un échange qui a eu lieu sur le forum FreeEOS). Cela simplement pour t'éviter des problèmes de mails pendant la mise au point

ça me parait très diffficile à faire, voire impossible, la plupart des postes sont des vieux coucous saturés (achetés d'occases en 2003!)

Alors, il va falloir que je sois très prudent avant de te faire faire des essais, et toi, n'oublie pas de faire une sauvgarde complète, config comprise (par ex. une sauvegarde sur poste de travail), avant toute modif. Travailler sur un serveur en prod est un risque énorme... Surtout si tu héberges 36 domaines !

Bon, cela dit, avec les précisions que tu as apportées, je commence à y voir plus clair. Mais il m'en manque encore un peu ! Et surtout, je relève quelques incohérences, par exemple le posteabloquer.nomdedomaine.net" qui figure dans tes Noms d'hôtes a selon toi une adresse fixe, mais cette adresse (192.168.105.66) est dans la plage des adresses attribuées par DHCP (192.168.105.65 à ...250)...

Peux-tu faire un petit schéma de ton réseau, afin qu'on soit bien sûr de bien comprendre ? Par exemple :

Internet
|
routeur ---- FreeEOS
|
Postes clients

D'après ce que tu dis, j'ai un peu l'impression que ton schéma est celui-ci, en considérant que FreeEOS et les postes clients sont au même niveau (LAN, pas de DMZ). confirme STP ou corrige.

Dans l'état actuel de ce que je comprends, je pense que les mails sortants (tout comme le partage de connexion internet) ne passent pas à travers FreeEOS. Un blocage à ce niveau serait donc inopérant !

Je pense que la solution sage serait :
- Faire un point précis du réseau actuel et des impératifs à respecter,
- Adapter l'architecture réseau en fonction des besoins et contraintes (qui devront donc être bien définis) pour tenter d'améliorer la sécurité et résoudre les problèmes.

En effet, si c'est bien ce que je pense (et peut-être bien aussi si ça ne l'est pas !), la raison de tes problèmes de quotas est probablement dû au fait que les postes clients ont possibilité de se connecter à internet sans aucun filtrage (ou seulement celui de ton routeur mais qui n'offrirait pas une sécurité suffisante). Et comme probablement il y a dans le lot des postes W$ infectés par différents malwares, il y a émission de spam qui fait exploser les quotas...

Si tu as du mal à suivre, ne t'inquiète pas : contente-toi de nous donner de manière détaillée tes besoins et contraintes, et on t'expliquera quoi faire. Si tu veux essayer de comprendre, tu peux lire mon howto sur les petits réseaux qui te permettra de voir si ton architecture est bonne ou pas, et comment l'améliorer.

PS : Je n'oublie pas ton problème d'upload de photos, mais impossible de me connecter sur le forum FreeEOS ce week-end... Je retenterai dans un moment, en espérant que j'y arriverai : malheureusement, nos problèmes d'hébergement ne semblent pas s'améliorer...

[HadaDeLaLuna]

Bonsoir

Bon, cela dit, avec les précisions que tu as apportées, je commence à y voir plus clair. Mais il m'en manque encore un peu ! Et surtout, je relève quelques incohérences, par exemple le posteabloquer.nomdedomaine.net" qui figure dans tes Noms d'hôtes a selon toi une adresse fixe, mais cette adresse (192.168.105.66) est dans la plage des adresses attribuées par DHCP (192.168.105.65 à ...250)...

c'est ce qu'il semble et que j'ai configuré d'après le mode d'emploi de Free-EOS à cause de l'imprimante

Peux-tu faire un petit schéma de ton réseau, afin qu'on soit bien sûr de bien comprendre ?

Internet
|
FreeBox
|
FreeEOS
|
Boitier Netgear
|
Les postes clients

toutes les connections sont ethernet et le serveur à 2 cartes, une vers la FreeBox, une pour le boitier Netgear

PS : Je n'oublie pas ton problème d'upload de photos, mais impossible de me connecter sur le forum FreeEOS ce week-end... Je retenterai dans un moment, en espérant que j'y arriverai : malheureusement, nos problèmes d'hébergement ne semblent pas s'améliorer...

Pas de problème c'est bien moins urgent que ce problème d'arriver à bloquer ces courriels

[jibe]

Salut,

Désolé pour le temps à répondre... Pas pu repasser plus tôt

Ok, ton architecture n'est pas mauvaise. J'avais des doutes à cause de l'@IP externe manquante sur la FreeBox, mais je suppose que tu l'as effacée ?

Comme je te disais, je pense que ton problème est que des postes infectés se connectent soit directement au smtp de Free, soit au smtp de ta FreeEOS, et émettent un paquet de spam qui fait exploser les quotas. La solution rationnelle est d'identifier ces postes et de supprimer la cause de l'émission du spam (passage à l'antivirus et à l'anti-spyware en ne bootant pas sur le disque infecté.

Si, par sécurité supplémentaire, tu veux éviter les envois de mail, tu peux effectivement interdire les accès SMTP par les postes clients et ne leur laisser que le webmail. Mais je pense que ce ne doit être qu'une mesure supplémentaire, et que le ou les émetteurs de spam doivent être identifiés de toutes façons.

Avertissement important : je n'ai pas de FreeEOS de test, donc j'ai pris le temps de bien vérifier ce que je dis, mais je ne l'ai pas testé. Vu qu'il y a longtemps que je n'ai pas pratiqué, des erreurs ne sont pas exclues. Il est donc impératif de bien tester les règles comme indiqué au paragraphe 3.1 de mon howto ! En cas de problème, le retour à la normale serait assuré par les commandes :

Code: Tout sélectionner

/sbin/e-smith/expand-template /etc/rc.d/init.d/masq
/sbin/e-smith/signal-event ip-change

Pour bloquer les mails sortants pour les postes voulus seulement, il faut absolument pouvoir identifier ces postes de façon sûre. Or, il semblerait qu'au moins certains soient en DHCP, ou en conflit avec la plage d'adresses DHCP. Il faut donc commencer par régler ce problème.

As-tu besoin de DHCP ? Si non, reconfigure FreeEOS sans DHCP. C'est le plus simple.

Si tu en as besoin, assure-toi que les postes à bloquer aient une adresse en dehors de la plage DHCP, c'est à dire les adresses inférieures à 192.168.105.65.

Pour les règles, nous allons reprendre le principe décrit dans mon howto, et créer la chaine jbfilter suivante (partie à remplacer au paragraphe 2.3) :

Code: Tout sélectionner

# jbfilter
#==============================================================
# Interdiction d'envoi de mails via SMTP
#
# Blocage du SMTP interne
ipchains -I jbfilter -p tcp -s ipduposte -d ipfreeEOS smtp -j REJECT

# Blocage des SMTPs externes
ipchains -I jbfilter -p tcp -s ipduposte -d ipfreeEOS smtp -j REJECT

Bien entendu, ipduposte et ipfreeEOS sont à remplacer par les valeurs correspondantes de ton réseau. Tu peux aussi ne mettre qu'une seule des deux règles, si tu ne veux bloquer qu'une partie du traffic.

Remarque : ceci place inutilement en OUTPUT un filtrage sur une adresse LAN qui a été NATée. Je ne pense pas que ce soit gênant. De même que ne pas faire le filtrage sur la chaine FORWARD ne devrait pas gêner l'efficacité du filtre, la trame ne devant normalement pas passer les règles précédentes. Si l'expérience me donnait tort, il faudrait tenter soit de supprimer la règle OUTPUT appelant jbfilter, soit la remplacer par une règle FORWARD. Ce qui veut dire supprimer ou modifier ces lignes du script du paragraphe 2.3 :

Code: Tout sélectionner

# OUTPUT
#==============================================================
# Par sécurité, on peut insérer ici aussi nos règles au début
/sbin/ipchains -I output 1 -s 0/0 -d 0/0 -j jbfilter

L'expérimentation devrait être assez vite faite sans modifier les templates dans un premier temps, comme décrit au paragraphe 3.1.

Voilà. J'espère que cela répond à ta demande, mais je rappelle que le plus important est d'éliminer (disons désinfecter ) les postes spammeurs.