Julien Cabillot a écrit :
Ah mais non, je ne veux pas faire ça. Je me posais juste la question du 'comment les bloquer'. C'est maintenant beaucoup plus clair.2008/5/8 Nicolas Letellier <nicolas AT nicoelro POINT net>:Emilien Gaspar a écrit : On Thu, May 08, 2008 at 05:38:53PM +0200, Nicolas Letellier wrote :Hello. Pour tester pour pf (qui bloque tout ce qui sort, excepté quelques ports), j'ai testé un telnet sur un port bloqué. Comme prévu, ça me bloque : May 08 17:33:50.085021 rule 1/(match) block out on sk0: 192.168.1.1.4196587.98.216.147.7766: [|tcp] (DF) [tos 0x10] (dixit tcpdump)Alors, je vois bien que j'ai essayé d'atteindre 87.98.216.147 sur le port 7766 en TCP. Mais à quoi correspond le "41965" sur mon l'IP locale de mon interface ? Ca semble être aléatoire. C'est un port ? Pourquoi ça ne sort pas sur le port 7766 ? J'ai commencé à fouiller le man de tcpdump, mais j'ai vite lâché l'affaire, c'est un peu trop imposant je trouve... Merci.Ce fonctionnement est propre à celui de TCP. Quand un *client* se connecte sur un port distant, il utilise un port local (éphémère) généralement tiré au hasard (et supérieur à 1024). Aucun rapport avec tcpdump donc ;-)Merci Pierre et Emilien. Il me semblait bien que c'était TCP ça, mais ça remonte à trop loin mes cours de réseaux :-) Mais je me posais cette question parce que ce port ne semble pas bloqué par pf. Apparemment, cette sélection est dans une couche avant le firewall.? Tu peux spécifier un truc comme : block out quick on $if proto tcp/udp from <ip_locale> port <port_local> to <ip_distante> port <port_distant> Mais je vois pas l'interet de bloquer un port local puisqu'il peut être utilisé par tout les softs utilisants tcp.
Merci ! -- - Nicolas