Greywolf

C'est censé me faire rabouler avec un bâton entre les crocs (nan je déconne.... quoique ) entre ça (si l'on peut le qualifier de délation) et jouer aux justiciers masqués en créant potentiellement des tensions inter-membres, je vous laisse juge pour déterminer des deux maux lequel est le moins mauvais.... (sinon y'a toujours la possibilité de ne rien faire et de laisser les modos parcourir les x mille(s) posts quotidiens avant de passer à une assistance qui est le but premier de ce forum )

modem (10.0.0.138)---(10.0.0.x ou @IP publique)PC_windows (192.168.0.1/24 partagée)---(192.168.0.2/24 PC Linux) Je connais peu ces modems mais 10.0.0.138 est l'adresse par laquelle on peut les administrer (hors connection internet il me semble) et sauf configuration expresse, ils doivent agir en tant que relais DHCP. PC linux pinge-t-il PC windows? les DNS de ton FAI sont correctement renseignés dans /etc/resolv.conf? (manifestement non au vu de la dernière capture d'écran, tu peux ne pas renseigner la recherche de domaine) BOOTPROTO='static' BROADCAST='192.168.0.255' IPADDR='192.168.0.2' MTU='' NAME='Sony RTL-8139/8139C/8139C+' NETMASK='255.255.255.0' NETWORK='192.168.0.0' REMOTE_IPADDR='' STARTMODE='auto' UNIQUE='rBUF.dS41GNOPmGE' USERCONTROL='no' _nm_name='bus-pci-0000:00:10.0' PREFIXLEN=''

CDEx tout simplement grip sous linux (entre de nombreux autres)

l'adresse de destination est celle de tous les réseaux soit 0.0.0.0/0 on peut l'ajouter en ligne de commande via route add default gw 192.168.0.1 sinon renseigner correctement le fichier de déclaration de tes interfaces réseaux (que je ne connais pas sous Suse) vérifie tes adresses de DNS dans /etc/resolv.conf également //edit: /etc/sysconfig/network apparemment pour la déclaration de la passerelle (GATEWAY) sinon le reste est dans /etc/sysconfig/network-scripts/ifcfg-ethX (où X est le n° de ton interface)

Wireshark (ex-Ethereal) http://www.wireshark.org/

t'aurais été sous linux, je t'aurais fait enlever le module IRdA mais bon ...

La mise en place d'un serveur proxy (transparent pour l'utilisateur autant que possible) permet de logger les activités. cela permet également de réaliser des listes de contrôle d'accès avec des blacklist ou des whitelist. Il est possible également à l'aide de sondes réseau de logger les activités à destination du port 80 (adresse source et destination). La mise en place de telles procédures doit être déclarée au niveau de l'entreprise.

http://www.enterasys.com/products/routing/x/X16-C/ ceci par exemple. C'est pas le même tarif non plus :-/

euh le problème est résolu ou a-t-il mystérieusement disparu?

en effet, si le mode routeur n'est pas activé, seul 1 PC peut se connecter à la fois au travers de la freebox. (sauf si on possède un élément qui fasse routeur intercalé entre la freebox et les PC)

netstat -petula pour voir les connexions en cours (avec l'exécutable participant à la connexion) y'a aussi lsof |grep IP un petit coup de chkrootkit ou de rkhunter peut-être utile également. Ceci dit si il n'existe aucune signature des exécutables originellement installés sur la machine, cela ne sera pas d'un grand secours

Tu as la possibilité d'attribuer un autre adressage à ton interface serveur VPN? Il est probable que si l'adressage de ton réseau local et que celui du VPN sont identiques, les tables de routage aient du mal à faire transiter les paquets "VPN" au travers du tunnel VPN créé

Apache est le logiciel qui communique à ton navigateur le contenu (dynamique ou non) d'un ou plusieurs site, c'est ce qu'on appelle le serveur http. Le problème que tu rencontres peut résulter de l'installation de Apache à la place de l'ancien utilisé chez ton hébergeur (il existe en effet d'autres logiciels serveur http). La page affichée indique qu'Apache a été installée sur la machine vers laquelle pointe ton nom de domaine. Il est possible que l'hébergeur soit en train de transférer le contenu de chaque site précédemment hébergé avec un autre logiciel vers Apache. Ceci dit, si les webmasters n'ont pas été prévenu, c'est un comportement quelque peu cavalier. Pire, le serveur a planté et des données ont été perdues (suite cause x ou y) et tout doit être réinstallé: il faut espérer qu'un système de sauvegarde des données ait été prévu :-/ Il est par ailleurs étrange que leur adresse mail ne soit plus valide voici les informations que l'on peut tirer en effectuant une requête whois sur le domaine en question. Tu peux éventuellement tenter de contacter les personnes que l'on y trouve: Domain Name : CMONFORUM.COM Created On : 2004-11-12 Expiration Date : 2007-11-12 Status : ACTIVE Registrant Name : Sebastien TARAS Registrant Street1 : 44 rue des Salamandres Registrant Street2 : Moulinieres A Registrant City : Six FOurs Registrant State/Province : FR Registrant Postal Code : 83140 Registrant Country : FR Admin Handle : AZ36675 Admin Name : NUXIT Admin Street1 : Les Espaces de Sophia Admin Street2 : 80 route des Lucioles - BP 037 Admin City : Sophia Antipolis Cedex Admin State/Province : FR Admin Postal Code : 06901 Admin Country : FR Admin Phone : +33.892460516 Admin Email : domains@nuxit.net Tech Handle : AZ36675 Tech Name : NUXIT Tech Street1 : Les Espaces de Sophia Tech Street2 : 80 route des Lucioles - BP 037 Tech City : Sophia Antipolis Cedex Tech State/Province : FR Tech Postal Code : 06901 Tech Country : FR Tech Phone : +33.892460516 Tech Email : domains@nuxit.net

Peut être forcer l'enregistrement sur un serveur WINS plutôt que d'utiliser la résolution netbios par diffusion ? http://technet2.microsoft.com/WindowsServe...9a927e1033.mspx P-node ou H-node

Un IPS réglé de façon trop aggressive ne sait pas trier le bon grain de l'ivraie et cause des dénis de service illégitime, c'est ce qui t'est arrivé avec le blocage de l'adresse de zebulon. Pour moi, c'est grave. Si encore la routine ne consistait qu'en un IDS (Détection) et remonte une alerte que l'administrateur (personne humaine) gère et décide de lui attribuer une criticité, soit. Bloquer arbitrairement une ressource du fait d'un faux-positif, non. Si tu captures la trame envoyée par le serveur de zebulon avec n'importe quel sniffer, tu t'apercevras que le champ Data ne contient rien (et surtout pas des commandes propres au trojan) Le problème de Norton (et probablement d'autres routines IPS) est d'associer une tentative de connexion sur le port 1024 au trojan Netsky; le raisonnement est beaucoup trop simpliste et contournable: Il suffit de modifier la partie serveur du trojan pour écouter sur le 1025 au lieu du 1024 et pouf contournement de la signature IPS de Norton. idéalement, il faut éviter que le ver (le trojan en fait, abus de langage mais c'est pour la métaphore) ne soit déjà dans le fruit. Je me contrefous absolument de recevoir des connexions de la partie client d'un trojan si je suis persuadé qu'il n'y a pas la partie serveur en attente de connexion sur mon PC. Que Norton ou autre solution miracle pré-packagée empêche déjà ça et il sera toujours temps de faire des routines de détection des instructions envoyées par la partie cliente. c'est là que réside ton incompréhension, le test n'utilise que des propriétés des protocoles réseau (IP) et de transport (TCP) et pas de l'applicatif (champ data, payload comme tu veux dans lequel on retrouve les commandes en fonction du protocole applicatif utilisé: HTTP, FTP, IRC, .....)

si tu parles de l'adresse IP de ton réseau local (192.168.x.y), peu importe. Ce sont des adresses privées qui n'ont pas d'existence réelle sur internet (pour faire simple). Si c'est l'adresse publique qui t'est attribuée par ton FAI, tu n'y peux rien.

la routine de Norton logge l'adresse IP et la bloque tout simplement... ou comment faire un DoS illégitime en profitant des défauts des routines IPS des usines à gaz

Un cheval de troie est une application serveur qui met en écoute un port de manière illégitime. Il s'avère que le trojan Netspy se met en écoute sur le port 1024 sur la machine infectée. Pour contrôler une machine infectée à distance, il faut établir une connexion sur ce port (TCP Syn entrant). Un test de sécurité tel celui de zebulon envoie des requêtes TCP Syn pour déterminer s'il existe des ports ouverts sur la machine testée. Le firewall, en fonction de ses réglages, bloque ou autorise telle ou telle connexion, point. Le champ data des paquets est nul ou aléatoire, j'aimerai bien savoir sur quelle base Norton a déterminé que le paquet est spécifique de la partie cliente du trojan (il fait de l'analyse des trames protocolaires des paquets échangés ou il se base sur une pauvre signature : TCP Syn dport 1024 = Trojan.Netsky ) La routine de Norton raconte encore une fois n'importe quoi: il a simplement bloqué une requête entrante sur le port en question. Qu'y a-t-il d'étonnant à celà puisque c'est le rôle d'un pare-feu.... C'est hallucinant comme ils peuvent exploiter la paranoïa des gens.

pfiou ..... :-0 peut-être avec ultimate boot cd et ses outils de recovery (Active Partition recovery) http://www.ultimatebootcd.com/ pour du ext2, y'a ça: http://e2undel.sourceforge.net/recovery-howto.html

si le routeur ne dispose pas de fonctionnalité de QoS ou de traffic shaping, il va falloir te résoudre à installer un soft du type Netlimiter sur le PC dont tu veux gérer la bande passante

est ce que les ROMs considérés sont des abandonwares? i.e. les droits d'auteurs ont-ils été cédé au domaine public?

le lien VPN était-il créé lorsque tu as exécuté ces 2 commandes?

il n'y a pas d'entrée dans le gestionnaire de périphériques?

c'est l'encapsulation des trames PPP sur 1/ un lien ATM 2/un lien Ethernet ça dépend de ton FAI (en général, l'ATM est privilégié)

c'est une DWORD en effet http://support.microsoft.com/kb/285089