ICMP ack, AT&T ..

Dans sa prose, HelloMan nous ecrivait :

voilà ce que ça donne au niveau de snort (scan.log):! juste pour
l'ouverture de la page de garde.

OK, let's analyse this...

12/17-15:01:48.432407 TCP src: 195.36.194.233 dst: 144.85.15.51 sport:
34466 dport: 80 tgts: 7 ports: 7 flags: ******S* event_id: 12

TCP SYN de 195.36.194.233 à destination du port 80 de 144.85.15.51. C'est
une demande d'ouverture de connexion, vraisemblablement pour aller sur le
site web.

cbr@elendil:~$ host 195.36.194.233
Name: l01m-23-233.d2.club-internet.fr
Address: 195.36.194.233

Je présume que c'est toi ça ;)

12/17-15:01:53.872644 TCP src: 195.36.194.233 dst: 198.108.0.18 sport:
34467 dport: 43 tgts: 8 ports: 8 flags: ******S* event_id: 12

Toujours toi, qui essaye de te connecter au port 43 de 198.108.0.18, aka
rpsl-p.merit.edu. Pourquoi ? Je ne sais pas, mais en tout cas, ça répond
fermé de l'autre côté :

cbr@elendil:~$ nc rpsl-p.merit.edu 80
rpsl-p.merit.edu [198.108.0.18] 80 (www) : Connection refused

12/17-15:01:58.526903 UDP src: 195.36.194.233 dst: 194.117.200.15
sport: 33342 dport: 53 tgts: 9 ports: 9 event_id: 12

Tu fais une requête DNS vers le DNS de ton FAI :

cbr@elendil:~$ host 194.117.200.15
Name: ns2.club-internet.fr
Address: 194.117.200.15

12/17-15:01:59.070840 UDP src: 195.36.194.233 dst: 154.11.145.2 sport:
33342 dport: 53 tgts: 10 ports: 10 event_id: 12

Encore toi la source... Encore une requête DNS, mais cette fois
ailleurs...

cbr@elendil:~$ host 154.11.145.2
Name: pri2.dns.ca.telus.com
Address: 154.11.145.2

Pourquoi tu vas taper là-bas, y'a que toi qui puisse le dire.

12/17-15:01:59.242115 UDP src: 195.36.194.233 dst: 154.11.136.2 sport:
33342 dport: 53 tgts: 11 ports: 11 event_id: 12

Et on remet le couvert sur le même serveur DNS...

12/17-15:02:00.281091 ICMP src: 195.36.194.233 dst: 213.228.0.42 type: 8
code: 0 tgts: 12 event_id: 12

Là, tu réponds à un ping de la machine 213.228.0.42 qui n'est autre que
le web de Free :

cbr@elendil:~$ host 213.228.0.42
Name: www1.free.fr
Address: 213.228.0.42

12/17-15:02:20.208922 UDP src: 195.36.194.233 dst: 211.232.1.1 sport:
33342 dport: 53 tgts: 13 ports: 13 event_id: 12

Décidemment, tu ne te lasses pas de faire joujou avec la DNS...

cbr@elendil:~$ host 211.232.1.1
Name: ns1.intertns.com
Address: 211.232.1.1

12/17-15:02:20.586172 UDP src: 195.36.194.233 dst: 211.232.1.2 sport:
33342 dport: 53 tgts: 14 ports: 14 event_id: 12

Rebelotte.

cbr@elendil:~$ host 211.232.1.2
Name: ns2.intertns.com
Address: 211.232.1.2

12/17-15:02:23.385038 ICMP src: 195.36.194.233 dst: 145.254.215.133
type: 3 code: 3 tgts: 15 event_id: 12

Là, tu renvoies une erreur ICMP. C'est déjà plus étrange. Type 3, code
3, c'est protocol unreachable, c'est à dire que la machine d'en face
essaye de communiquer avec un protocole de transport qui n'est pas
supporté par ta stack IP. Si on avait la trace complète de cet ICMP, on
pourrait aller plus loin.

Manifestement, c'est étranger à tes histoires de site web, cette IP
n'apparaît pas ailleurs. D'ailleurs :

cbr@elendil:~$ host 145.254.215.133
Name: dialin-145-254-215-133.arcor-ip.net
Address: 145.254.215.133

12/17-15:02:24.958431 UDP src: 195.36.194.233 dst: 210.217.192.1 sport:
33342 dport: 53 tgts: 16 ports: 16 event_id: 12

Encore de la DNS...

cbr@elendil:~$ host 210.217.192.1
Name: 210-217-192-1.intertns.com
Address: 210.217.192.1

12/17-15:11:32.382952 TCP src: 195.36.194.233 dst: 194.158.126.24 sport:
34509 dport: 80 tgts: 6 ports: 6 flags: ******S* event_id: 0

Là, tu fais un SYN pour aller chercher un site web sur 194.158.126.24,
qui est une machine Akamai.

inutile de dire que j'ai immédiatement refermé le browser.

Ah...

Par acquis de conscience, pour vérifier que ça ne j'ai vérifié
après en ouvrant des pages web classiques mais réputées comme
"sûres" (il se peut en effet que j'aie chopé un backdoor). genre
www.yahoo.fr, libération, le monde, club-internet, wanadoo, etc... sur
toutes les pages ouvertes de cette façon, je n'ai eu que ça:

12/17-15:12:00.955823 ICMP src: 195.36.194.233 dst: 213.228.0.42 type:
8 code: 0 tgts: 7 event_id: 14 (vraisemblablement due à un popup)

C'est un réponse à un ping, comme tout à l'heure, toujours pour le site
de Free. Donc rien à voir avec tes Yahoo, Libération et autres Le Monde.

heu, on fait quoi là dans ces conditions ??

On apprend à lire un log Snort ? :)

Va vraiment falloir que tu sortes ton ethereal parce que là, il n'y a
rien, amha, de terriblement vilain dans tout ça. D'autant que tous ces
paquets proviennent de _ton_ réseau, et qu'on n'a pas le trafic dans
l'autre sens, i.e. ce que les autres t'envoient. Or, c'est plus ce que tu
reçois qui nous importe en l'occurence.

Je jetterais quand même un coup d'oeil à ma configuration DNS si
j'étais toi, parce que c'est pas trop normal d'aller taper autant de
serveurs. T'aurais pas un cache DNS configuré sans forwarder (ou avec les
serveurs cités en forwarder) ?

--
panic ("No CPUs found. System halted.n");
2.4.3 linux/arch/parisc/kernel/setup.c

Cedric Blancher wrote:

Dans sa prose, HelloMan nous ecrivait :

voilà ce que ça donne au niveau de snort (scan.log):! juste pour
l'ouverture de la page de garde.

OK, let's analyse this...

12/17-15:01:48.432407 TCP src: 195.36.194.233 dst: 144.85.15.51 sport:
34466 dport: 80 tgts: 7 ports: 7 flags: ******S* event_id: 12

TCP SYN de 195.36.194.233 à destination du port 80 de 144.85.15.51. C'est
une demande d'ouverture de connexion, vraisemblablement pour aller sur le
site web.

cbr@elendil:~$ host 195.36.194.233
Name: l01m-23-233.d2.club-internet.fr
Address: 195.36.194.233

Je présume que c'est toi ça ;)

Bien présumé docteur Watson.

Je ne comprends pas le 144.85.15.51. Qu'est ce que ça fout là ? j'ai jamais
demandé à y aller.

12/17-15:01:53.872644 TCP src: 195.36.194.233 dst: 198.108.0.18 sport:
34467 dport: 43 tgts: 8 ports: 8 flags: ******S* event_id: 12

Toujours toi, qui essaye de te connecter au port 43 de 198.108.0.18, aka
rpsl-p.merit.edu. Pourquoi ? Je ne sais pas, mais en tout cas, ça répond
fermé de l'autre côté :

cbr@elendil:~$ nc rpsl-p.merit.edu 80
rpsl-p.merit.edu [198.108.0.18] 80 (www) : Connection refused

Je ne comprends pas le 198.108.0.18 non plus, je n'ai jamais demandé à y
aller, à moins que ce ne soient des popups de pub sur la page en question.

12/17-15:01:58.526903 UDP src: 195.36.194.233 dst: 194.117.200.15
sport: 33342 dport: 53 tgts: 9 ports: 9 event_id: 12

Tu fais une requête DNS vers le DNS de ton FAI :

cbr@elendil:~$ host 194.117.200.15
Name: ns2.club-internet.fr
Address: 194.117.200.15

C'est bien le DNS de mon FAI. Normalement, c'est ns1 qui répond, mais il
était peut être surchargé à ce moment.

12/17-15:01:59.070840 UDP src: 195.36.194.233 dst: 154.11.145.2 sport:
33342 dport: 53 tgts: 10 ports: 10 event_id: 12

Encore toi la source... Encore une requête DNS, mais cette fois
ailleurs...

cbr@elendil:~$ host 154.11.145.2
Name: pri2.dns.ca.telus.com
Address: 154.11.145.2

Pourquoi tu vas taper là-bas, y'a que toi qui puisse le dire.

Normalement je n'y tape jamais, je ne connaissais pas l'existence de ce DNS.
Et il n'apparait que cette fois dans les logs. Et je ne peux pas te dire
quoi que ce soit, pri2.dns.ca.telus.com est inconnu au bataillon ici.

12/17-15:01:59.242115 UDP src: 195.36.194.233 dst: 154.11.136.2 sport:
33342 dport: 53 tgts: 11 ports: 11 event_id: 12
144.85.15.51

Et on remet le couvert sur le même serveur DNS...

12/17-15:02:00.281091 ICMP src: 195.36.194.233 dst: 213.228.0.42 type: 8
code: 0 tgts: 12 event_id: 12

Là, tu réponds à un ping de la machine 213.228.0.42 qui n'est autre que
le web de Free :

cbr@elendil:~$ host 213.228.0.42
Name: www1.free.fr
Address: 213.228.0.42

Oui, là pour ça, c'est mea culpa, je suis sur Club-internet, avec un modem
Sagem F@st 800, le ping vers free c'est un test de présence réseau du
driver modem. OK, sorry, j'ai pas pensé à l'éliminer des logs.

12/17-15:02:20.208922 UDP src: 195.36.194.233 dst: 211.232.1.1 sport:
33342 dport: 53 tgts: 13 ports: 13 event_id: 12

Décidemment, tu ne te lasses pas de faire joujou avec la DNS...

cbr@elendil:~$ host 211.232.1.1
Name: ns1.intertns.com
Address: 211.232.1.1

Mais qu'est ce que ça fout là ça ??

12/17-15:02:20.586172 UDP src: 195.36.194.233 dst: 211.232.1.2 sport:
33342 dport: 53 tgts: 14 ports: 14 event_id: 12

Rebelotte.

cbr@elendil:~$ host 211.232.1.2
Name: ns2.intertns.com
Address: 211.232.1.2

Oui, OK, je me suis rendu compte d'un problème avec le DNS juste après avoir
posté ça, le problème c'est que les horaires concordent (l'heure plus 2 ou
3 minutes) je me suis rendu compte de l'existance d'un machin qui
communique en udp53 avec des serveurs DNS sur ma machine. On devra y
revenir plus tard.

12/17-15:02:23.385038 ICMP src: 195.36.194.233 dst: 145.254.215.133
type: 3 code: 3 tgts: 15 event_id: 12

Là, tu renvoies une erreur ICMP. C'est déjà plus étrange. Type 3, code
3, c'est protocol unreachable, c'est à dire que la machine d'en face
essaye de communiquer avec un protocole de transport qui n'est pas
supporté par ta stack IP. Si on avait la trace complète de cet ICMP, on
pourrait aller plus loin.

Pfff, heu, je ne comprends plus. Je crois que je vais tenter un truc mieux
contrôlé, parce que je me rends compte que je t'ai fourni des traces réseau
bien trop bruitées.

(snip du reste)

Par acquis de conscience, pour vérifier que ça ne j'ai vérifié
après en ouvrant des pages web classiques mais réputées comme
"sûres" (il se peut en effet que j'aie chopé un backdoor). genre
www.yahoo.fr, libération, le monde, club-internet, wanadoo, etc... sur
toutes les pages ouvertes de cette façon, je n'ai eu que ça:

12/17-15:12:00.955823 ICMP src: 195.36.194.233 dst: 213.228.0.42 type:
8 code: 0 tgts: 7 event_id: 14 (vraisemblablement due à un popup)

C'est un réponse à un ping, comme tout à l'heure, toujours pour le site
de Free. Donc rien à voir avec tes Yahoo, Libération et autres Le Monde.

Oui, voir la note sur le modem de Sagem

heu, on fait quoi là dans ces conditions ??

On apprend à lire un log Snort ? :)

Ben oui, mais ces accès DNS n'apparaissent que lors de la consultation de la
page en question. Et une fois toutes les heures et 2 minutes, vers
intertns.com, ce qui me fait penser à la présence soit d'une backdoor, soit
d'un problème de DNS, soit les deux (voir ci-dessous)

Va vraiment falloir que tu sortes ton ethereal parce que là, il n'y a
rien, amha, de terriblement vilain dans tout ça. D'autant que tous ces
paquets proviennent de _ton_ réseau, et qu'on n'a pas le trafic dans
l'autre sens, i.e. ce que les autres t'envoient. Or, c'est plus ce que tu
reçois qui nous importe en l'occurence.

Yess, mea culpa, j'ai fourni des logs complètement foireux, pas filtrés, et
des logs de sortie, et pas d'entrée; et j'ai fait la manip en même temps
que quelque chose envoyait des requetes à 3 DNS différents. J'ai vu les
logs qui augmentaient à toute vitesse, j'ai paniqué, tout arrêté, et envoyé
les logs brut de décoffrage sans même y jeter un coup d'oeil, imbécile que
je suis.

Je jetterais quand même un coup d'oeil à ma configuration DNS si
j'étais toi, parce que c'est pas trop normal d'aller taper autant de
serveurs. T'aurais pas un cache DNS configuré sans forwarder (ou avec les
serveurs cités en forwarder) ?

C'est ÇA qui m'emmerde: j'ai effectivement un DNS local configuré de la
façon suivante (/etc/named.conf)

(snip)
options {
pid-file "/var/run/named/named.pid";
directory "/var/named";
statistics-file "/var/log/named/stats.log";
forwarders {
194.117.200.10;
194.117.200.15;
};
forward first;
(et re-snip)

les 2 forwarders sont ns1.club-internet.fr et ns2.club-internet.fr.

CEPENDANT, et voir quelques posts plus haut, j'ai QUAND même eu droit aux
newnotsyn quelques minutes après (voir post plus haut).

C'est vrai, faudrait peut être y aller à coup d'ethereal, mais je crains que
cela ne dépasse mes compétances, d'autant plus que cette expérience aura eu
pour effet de mettre à jour un autre problème sous jaçent au niveau du DNS.
qu'il me semble important de résoudre en premier lieu (je pense soit à un
backdoor, soit à un spyware, soit à ce que ce soit le DNS de club-internet
qui fait un lui même un forward vers d'autres DNS en cas de surcharge et
que je me récupère les données du serveur DNS forwardé à la place de
ns1.club-internet.fr)

Voir un autre post pour les paquets que j'ai quand-même fini par recevoir.

C'est complexe, car de multiples paramètres sont apparus simultanément.

--
HelloMan

HelloMan <aaa@bbb.ccc> wrote:

forwarders {
194.117.200.10;
194.117.200.15;
};
forward first;
(et re-snip)

Ben "forward first;" si les DNS de club-internet ne répondent pas
assez vite, c'est normal d'aller voir directement les DNS
du domaine demandé.

qu'il me semble important de résoudre en premier lieu (je pense soit à un
backdoor, soit à un spyware, soit à ce que ce soit le DNS de club-internet
qui fait un lui même un forward vers d'autres DNS en cas de surcharge et
que je me récupère les données du serveur DNS forwardé à la place de
ns1.club-internet.fr)

Faut arreter la drogue. Tout ça est un comportement normal de
votre machine. Y compris l'ICMP 3/3 qui est envoyé quand la
réponse DNS arrive trop tard et que bind a déja refermé son
port de query. (Cedric 3/3 c'est port unreachable, pas
proto unreachable 3/2). CA ARRIVE TOUT LE TEMPS !

Quand aux autres probllèmes (les paquet ACK/RST, etc...) je
suppose que soit votre FW expire les états trop vite et
refuse des paquets hors session, renvoyés sans doute parce que
le serveur n'a pas reçu vos FIN.

Bref amha vous avez surtout une liaison saturée.

--
Nom d'un chat de nom d'un chat !

Faudrait faire ça avec un ethereal, mais je ne vois pas trop comment sans
ouvrir des ports sur le fw et ça serait un peu risqué.

pour sniffer les paquets il n'y a pas besoin que
le firewall soit ouvert. Ils sont pris par l'api
d'écoute avant d'être passés aux filtres.

Enfin sur un système normal :-]

--
Nom d'un chat de nom d'un chat !

:: Dec 17 16:12:32 msi kernel: Shorewall:newnotsyn:DROP:IN=ppp0 OUT :: MAC= SRC2.107.37.21 DST5.36.194.233 LENA TOS=0x08 PREC=0x00
:: TTL9 IDP127 DF PROTO=TCP SPT€ DPT843 WINDOWV31 RES=0x00
:: ACK URGP=0

SPT = 80
Pour moi, c'est tout simplement des réponses du serveur HTTP interprétée
comme des requetes car il y a un probleme dans le module de stateful
inspection...
Voila, c'étaient mes 2 centimes du jour.

Salut,

On 17 Dec 2003 17:49:09 GMT, HelloMan <aaa@bbb.ccc> wrote:

Donc, consultation des pages à 16h00 environ, et à partir de 16:12:32,

Ce serait bien d'avoir le délai exact entre la dernière connexion et le
premier paquet "bizarre".

Dec 17 16:12:32 msi kernel: Shorewall:newnotsyn:DROP:IN=ppp0 OUT= MAC > SRC2.107.37.21 DST5.36.194.233 LENA TOS=0x08 PREC=0x00 TTL9
IDP127 DF PROTO=TCP SPT€ DPT843 WINDOWV31 RES=0x00 ACK URGP=0

Ce sont des paquets d'une connexion HTTP établie précédemment, et que le
serveur de destination ne considère aparemment pas comme fermée (alors que
ton firewall a déjà "oublié" l'existance de cette connexion). Et si le
paquet est "droppé" sans renvoyer un RST ou un ICMP, le serveur continue à
penser que la connexion est établie, et qu'il ne fait que perdre des
paquets, donc il recommencera, encore et encore, jusqu'à en avoir
définitivement marre.

en masse (raisonnable) toujours la même adresse source jusqu'à 16:43:52

C'est bizarre que ça dure aussi longtemps, j'aurais eu tendance à penser
qu'une session TCP sans aucune réponse tiendrait moins longtemps que ça,
mais bon, c'est une question de paramétrage...

les ports de destination sont les suivants:

# grep 32.107.37.21 /var/log/syslog | grep 'Dec 17 16' | cut -d' ' -f19 |
sort | uniq

DPT843
DPT86
DPT818
[...]

et ils ne m'évoquent toujours rien.

Ce sont les ports source de tes connexions HTTP sur ce serveur, tirés au
hasard parmi les ports non privilégiés.

J'ai tendance à penser qu'il y a une règle idiote quelque part qui fait
que le destinataire ne voit jamais les sessions se fermer. C'est valable
sur une seul et unique site, ou sur plusieurs?

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Dans sa prose, Alain Thivillon nous ecrivait :

(Cedric 3/3 c'est port unreachable, pas proto unreachable 3/2).

Quelle burne je fais. J'avais un doute et j'ai sauté une ligne dans ma
référence.... La prochaine fois, j'irai sur NetworkSorcery, au moins,
c'est plus clair...

http://www.networksorcery.com/enp/default0504.htm

Désolé...

--
Debout, face au mur et les paluches en l'air... que j'les vois bien.
On est charge a la magnum. Si vous bougez seulement les oreilles, on vous
coupe par le milieu.
-+- Bernard Blier, Faut pas prendre les enfants du Bon Dieu...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jacques Caron wrote:

Salut,

On 17 Dec 2003 17:49:09 GMT, HelloMan <aaa@bbb.ccc> wrote:

Donc, consultation des pages à 16h00 environ, et à partir de 16:12:32,

Ce serait bien d'avoir le délai exact entre la dernière connexion et le
premier paquet "bizarre".

Il faut que je retente le coup, mais je suis assez occuppé jusqu'à la
semaine prochaine. Il faut un ethereal, un chronomètre, une liaison web.
D'après Patrick MATHEVON, dans le post juste au dessus, on peut le faire
avec firewall fermé (chose que j'ignorais, je le reconnais). Attention, je
reconnais également avoir fait la manipe avec un système dont je ne suis
pas sûr de l'intégrité à 100% (voir les remarques justifiées de C. Blancher
à propos du DNS). En gros, les paquets bizarres arrivent à peu près 15
minutes après la consultation des pages dudit site. Mais on peut les voir
facilement en laissant un shell ouvert avec un petit tail -f
/var/log/kernel/infos si, comme moi vous êtes sur Mandrake linux. ou en
tout cas les logs en ligne de iptables/Shorewall. J'ai consulté plusieurs
pages au hasard dudit site.

Ce sont des paquets d'une connexion HTTP établie précédemment, et que le
serveur de destination ne considère aparemment pas comme fermée (alors que
ton firewall a déjà "oublié" l'existance de cette connexion). Et si le
paquet est "droppé" sans renvoyer un RST ou un ICMP, le serveur continue à
penser que la connexion est établie, et qu'il ne fait que perdre des
paquets, donc il recommencera, encore et encore, jusqu'à en avoir
définitivement marre.

en masse (raisonnable) toujours la même adresse source jusqu'à 16:43:52

C'est bizarre que ça dure aussi longtemps, j'aurais eu tendance à penser
qu'une session TCP sans aucune réponse tiendrait moins longtemps que ça,
mais bon, c'est une question de paramétrage...

Moi aussi, mais bon, je peux avoir un firewall dont la configuration n'est
pas optimale, malgré les précautions que j'ai pris à le configurer; je le
reconnais.

J'ai tendance à penser qu'il y a une règle idiote quelque part qui fait
que le destinataire ne voit jamais les sessions se fermer. C'est valable
sur une seul et unique site, ou sur plusieurs?

Pour moi, je n'ai jamais vu ça que sur ce site, et sur ce site seulement. Et
en plus, depuis Dimanche matin, ça s'est répété 3 fois. Bien sûr, j'ai des
fois des paquets newnotsyn qui arrivent, que je sois en train de surfer le
web, ou pas, mais ce ne sont jamais que des paquets isolés, une dizaine au
GRAND maximum, jamais 200.

Bon, alors OK, je n'ai pas été forcément très scientifique dans ma démarche.
Pour plusieurs raisons, dont surtout cette dernière, je trouverais
intéressant que quelqu'un d'autre que moi, peut être plus expérimenté dans
ce genre de démarche, ou plus équipé, ou je en sais pas quoi, fasse la
manipe de son côté. C'est légal, il n'y a qu'à se connecter sur le site et
cliquer sur une dizaine de liens, on a le droit de consulter l'information
publique. et d'enregistrer ce qui sort et qui rentre. Une fois cela fait,
qu'il en fasse profiter le newsgroup. Cela pourra peut être ne serait-ce
que m'aider à corriger la configuration de mon système et ma connaissance
du réseau. Ou bien me faire prendre conscience que j'ai été trop alarmiste
pour rien, ce que je peux comprendre, mais il faut fournir des faits et des
logs. Et cela serait déjà pas mal.

merci d'avance.

- --
HelloMan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/4a1teId4S2LZgTURAsAbAKCGBMOTKZaOme5oWQDh1F7SWegIWACeJRFY
VXGwTKZ46hAA3dYkeKt2OFA =LDxG
-----END PGP SIGNATURE-----

Alain Thivillon wrote:

HelloMan <aaa@bbb.ccc> wrote:

forwarders {
194.117.200.10;
194.117.200.15;
};
forward first;
(et re-snip)

Ben "forward first;" si les DNS de club-internet ne répondent pas
assez vite, c'est normal d'aller voir directement les DNS
du domaine demandé.

Je corrige de ce pas avec forward only; ?

--
HelloMan

Faudrait faire ça avec un ethereal, mais je ne vois pas trop comment
sans ouvrir des ports sur le fw et ça serait un peu risqué.

pour sniffer les paquets il n'y a pas besoin que le firewall soit ouvert.
Ils sont pris par l'api d'écoute avant d'être passés aux filtres.

Enfin sur un système normal :-]

Pour du TCP, ça ne risque pas de donner gd chose si le SYN n'a pas de
réponse...

--
°°°°°°°°°----------------°°°°°°°°°
Pierre BETOUIN
soulrider@unsigned.ath.cx
°°°°°°°°°----------------°°°°°°°°°