Bloquer les ports

par **nicostgermain** » 10 Avr 2003 15:47

Je viens d'installer ipcop et je voudrais savoir comment bloquer les ports superieur à 1024 à partir du GUI?

par **grosbedos** » 10 Avr 2003 16:20

ce n'est pas possible.

par **nicostgermain** » 10 Avr 2003 16:22

je sui donc obligé de modifié le fichier rc.firewall.up

par Si » 10 Avr 2003 17:43

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD>En réponse à:<HR></TD></TR><TR><TD><BLOCKQUOTE> Le 2003-04-10 16:20, grosbedos a écrit: ce n'est pas possible. </BLOCKQUOTE></TD></TR><TR><TD><HR></TD></TR></TABLE> Bon tu pourrais donne une solution.

par **Vinzstyle** » 10 Avr 2003 17:47

Tu édites le rc.firewall.up et à la place de ACCEPT tu met REJECTs (je ne sais pas si DROP ça existe avec IPchains) aux lignes qui concernes les ports > 1024.

par **JuLeS** » 13 Avr 2003 16:08

J'ai fais la modif que tu indiques Vinz, mais après, j'ai mon MSN qui marche plus, plus de oueb, plus de emule.... <IMG SRC="images/smiles/icon_bawling.gif"> Je suppose qu'il faut donc autoriser certains ports >1024 quand même (MSN=1863 je crois, emule=4662...). <IMG SRC="images/smiles/icon_help.gif"> Comment on fait ? De plus, ces ports seront-ils utilisables par 1 seule machine ou pour tout le LAN ? Et pour certains services (comme du FTP) comment va réagir IPCop, sachant que mon port de retour va etre >1024 <IMG SRC="images/smiles/icon_confused.gif">

par **antolien** » 13 Avr 2003 16:23

alors, vous cherchez à bloquer les ports >1024 et après vous vous plaignez que plus rien ne marche ? faut pas s'étonner. juste une petite remarque, sur les versions inferieures aux 1.3, ces ports étaient carément ouvert. or depuis la 1.3 ce que j'ai pu voir c'est qu'ils sont ouverts en sortie seulement ce qui est nettement mieux pour la sécurité. sinon, pour répéter éternellement la même chose, les ports >1024 sont utilisés par le ftp, les IM, voir pratiquement toutes les applications. donc bloquer ces ports c'est bien si vous souhaitez vraiment bloquer vos users sinon, vous allez être ennuyés plutôt qu'autre chose.

par **grosbedos** » 13 Avr 2003 16:48

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD>En réponse à:<HR></TD></TR><TR><TD><BLOCKQUOTE> Le 2003-04-10 17:43, Si a écrit: <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD>En réponse à:<HR></TD></TR><TR><TD><BLOCKQUOTE> Le 2003-04-10 16:20, grosbedos a écrit: ce n'est pas possible. </BLOCKQUOTE></TD></TR><TR><TD><HR></TD></TR></TABLE> Bon tu pourrais donne une solution. </BLOCKQUOTE></TD></TR><TR><TD><HR></TD></TR></TABLE> ben je l'ai donné la soluce..par la GUI ce n'est pas possible! a moins de modifier la GUI, ce qui est quand meme bien compliqué...

par **grosbedos** » 13 Avr 2003 16:51

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD>En réponse à:<HR></TD></TR><TR><TD><BLOCKQUOTE> Le 2003-04-13 16:23, antolien a écrit: alors, vous cherchez à bloquer les ports >1024 et après vous vous plaignez que plus rien ne marche ? faut pas s'étonner. </BLOCKQUOTE></TD></TR><TR><TD><HR></TD></TR></TABLE> lol <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD>En réponse à:<HR></TD></TR><TR><TD><BLOCKQUOTE> juste une petite remarque, sur les versions inferieures aux 1.3, ces ports étaient carément ouvert. or depuis la 1.3 ce que j'ai pu voir c'est qu'ils sont ouverts en sortie seulement ce qui est nettement mieux pour la sécurité. </BLOCKQUOTE></TD></TR><TR><TD><HR></TD></TR></TABLE> oui c'est bien ce que j'ai vu aussi.

par **tomtom** » 13 Avr 2003 16:52

Tres bonne réponse <IMG SRC="images/smiles/icon_smile.gif"> Allez comme j'ai du temps cet après-midi, un petit cours de tcp/ip ! A chaque fois qu'un application se connecte à internet, elle établit une communication bidirectionnelle avec un serveur. Pour faire cela, elle choisit un port > 1024, et elle envoie un paquet sur internet : ip source : votre ip publique port source : le port choisi ip destination : ip du serveur où vous vous connectez port destination : le port d'ecoute du serveur. ¨ Pour ne pas que ce soit trop le bazar, il a été décidé que les serveurs écouteraient sur un port qui depend de ce qu'ils proposent comme service. Ces ports sont appelés "well known ports" et portent des numéros < 1024. Ils sont définis par la RFC 1700. Cela permet par exemple de savoir qu'un serveur telnet ecoute sur le port 23 en général. Les applications clients choisissent un port > 1024 pour ne pas risquer de masquer un serveur qui ecouterait sur la même adresse ip. Une première reflexion : A priori en bloquant les ports source > 1024 en sortie, on bloque tous ses clients !!! Une seconde reflexion : Quand le serveur va me repondre, le paquet va arriver avec un port destination egal au port que j'ai choisi, donc si je veux avoir la reponse, il faut que mon firewall laisse passer tous les paquets entrant avec un port destination > 1024. Hum, bonjour la sécurité !! Un pirate n'a qu'à forger des paquets avec un port destination > 1024 et le firewall les laissera tous passer <IMG SRC="images/smiles/icon_mad.gif"> Bon, on va se protéger un peu plus : n'autorisons que les paquets dont : 1- le port destination > 1024 2- le port source est celui d'un serveur que l'on autorise à utiliser : par exemple uniquement 80, 81,20, 21, 22, 23 pour avoir web telnet ssh ftp. OK, on a amélioré un peu, mais tout de même, un pirate peut là encore forger le paquet et choisir son port source pour se faire passer pour un serveur aux yeux du firewall. Il va alors falloir jongler entre applications possibles et sécurité, et c'est là la grosse limite des firewalls dits "stateless". Comme le fait remarque Antolien, en version 1.3 les ports sont ouverts uniquement en sortie (un client peut envoyer un paquet avec port > 1024 comme source et traverser le firewall.). Mais alors, comme le serveur peut-il repondre ? Grace à Netfilter, qui est un firewall statefull, et à son interface IPTables. En effet, avec ce genre de firewall, on peut ouvrir dynamiquement les ports pour des connexions déja établies par un client. Genial, non ? Exemple : Je me connecte à <a href="http://www.ixus.net" target="_blank">www.ixus.net</a> pour poster ce merveilleux message. 1- envoi d'un paquet tcp : ip source : mon ip publique (apres translation d'adresse mais c'est un autre histoire). port source : 2035 ip destination : <a href="http://www.ixus.net" target="_blank">www.ixus.net</a> port destination : 80 Ce paquet a une particularité : il est l'initiateur d'une connexion et contient un drapeau appelé "SYN". 2- le firewall laissep asser ce paquet (le port source est > 1024, le port destination est autorisé. 3- le firewall crée une entrée dans une table (un "conntrack"), qui contient l'ip source, le port source, l'ip destination et le port destination, ainsi que l'etat actuel : "syn sent") 4- le paquet revient du serveur : ip source : <a href="http://www.ixus.net" target="_blank">www.ixus.net</a> port source : 80 ip destination : mon ip publique port destination : 2035 Ce paquet est la reponse à une connexion. Il contient deux flags : SYN et ACK 5- le firewall examine ce paquet. Il parcourt sa table de conntracks, et s'apperçoit qu'il attendait ce paquet. Il le laisse passer.. La connexion est établie. Le firwall va maintenant laisser passer tous les paquets suivants, jusqu'à epuisement d'un timeout. Voila, c'est très grossier comme présentation mais ca peut toujours eclairer. Il faut savoir que IPables permet d'affiner les règles en regardant tous les flags TCP et UDP, ce qui permet des comportements très proches de ce que l'on recherche. Pour revenir à la question : Si tu as un IPCop avec IPChains (version avant 1.3), tu ne peux pas benéficier de ces merveilles. Si malgré tout tu veux bloquer les ports, il ne te reste qu'a installer une version plus recente. Thomas

par **JuLeS** » 13 Avr 2003 17:00

Ben voila une réponse qu'elle est bien claire et précise <IMG SRC="images/smiles/icon_bise.gif"> Merci Thomas. Donc, maintenant je sais ce que je voulais savoir : IPCop en V.1.2 n'est pas Statefull. Reste à attendre une V.1.3 finale, j'ai eu qq probs avec les betas 2 et 3. Au fait, elle arrive quand <IMG SRC="images/smiles/icon_confused.gif">

par **grosbedos** » 13 Avr 2003 17:10

juste une petite remarque a ton discours (qui est assez bon) <TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD>En réponse à:<HR></TD></TR><TR><TD><BLOCKQUOTE> Le 2003-04-13 16:52, tfillaud a écrit: 2- le firewall laissep asser ce paquet (le port source est > 1024, le port destination est autorisé. </BLOCKQUOTE></TD></TR><TR><TD><HR></TD></TR></TABLE> comme tu l'avait remarqué ce n'est pas parce que c'est un port >1024 qu'il passe, mais seulement parce que c'est un port en sortie, cela aurait pu etre 32 ou autre chose.. les ports ouverts >1024 (sur 1.2) ne concernent que le traffic depuis internet.

par **tomtom** » 13 Avr 2003 17:14

Erf Grosbedos, desolé je me suis basé sur ma config iptables qui n'autorise pas les ports serveurs à sortir, sauf config particulière.... Une protection supplémentaire comme qui dirait <IMG SRC="images/smiles/icon_wink.gif"> Sinon en fait je fais des hypothèses, vu que je n'ai jamais installé IPCop, mais je suis sur que la 1.2 est sur IPChains et donc stateless... A peluche.. Tom

par **grosbedos** » 13 Avr 2003 17:47

ouioui tu as raison..c'était juste pour infos, tout le reste est juste et bien dit!

Bloquer les ports

Qui est en ligne ?