Greywolf

des virus qui grillent du matériel, même si c'est théoriquement possible, il faudrait qu'ils soient spécifiquement dirigés contre le contrôleur IDE/SATA/RAID du disque dur ET l'électronique du DD. Autant dire que ça ne coure pas les rues. idem que Flo => panne matérielle.

c'est manifestement un problème côté serveur. Tu n'y peux pas grand chose

Il faut insérer ces lignes dans ton script iptables ou, si des règles de filtrage existent, les insérer au bon endroit (en utilisant -I <nom_de_lachaine> <numéro_de_règle>) et sauvegarder ces nouvelles règles avec l'exécutable iptables-save > lefichierquetuveux un simple iptables-restore < lefichiercontenantlesrègles suffira à restaurer les choses. Je ne connais pas les GUI, donc je peux pas t'aider pour une configuration par ce biais.

exact la gamme de fréquence utilisée pour ces types d'appareils est la-même (bande des 2.4GHz). Afin d'éviter des problèmes d'interférences dues aux recouvrement de spectres, il convient d'espacer les canaux utilisés d'au moins 20 MHz (i.e. utiliser les canaux 1, 6 ou 11)

je crois me souvenir qu'il le diffuse son SSID, ça commence par DWB-200-xxxxx. Ton interface wifi devrait le "voir" dans la liste des AP environnants.

règle iptables contre le brute-forcing (exemple pour ssh): iptables -A INPUT -p tcp --dport ssh -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP iptables -A INPUT -p tcp --dport ssh -m recent --set --name SSH iptables -A INPUT -p tcp --dport ssh -j ACCEPT la 1ère ligne vérifie la liste des adresses IP nommée SSH pour voir si celle-ci n'a pas tenté de se connecter 4 fois en 60 secondes; si tel est le cas, la connexion est refusée. Si l'adresse IP source ne fait pas partie de la liste, on passe à la ligne suivante la 2eme ligne crée la liste d'adresse IP SSH et logge l'adresse IP dans la liste la 3ème ligne accepte la connexion (à condition que le masque de la première ligne n'ait pas correspondu) on peut s'amuser à logger les tentatives de brute-forcing en créant une première ligne identique supplémentaire mais ayant comme cible -j LOG --log-prefix "Attention! attaque en cours sur SSH!!!"

manifestement tes en-têtes noyaux ne sont pas installés

oui bien sûr .... mais où as tu donc été cherché tout ça? J.Deneux est le mainteneur d'un projet d'un module noyau pour gérer les périphériques à retour de force (joystick, volant,...). Faut arrêter la parano...

de mémoire (n'ayant pas de windows sous la main): propriétés de la connexion wifi, liste des réseaux préférés => propriétés. Dans la fenêtre qui s'affiche, tu peux définir le SSID, le mode infrastructure/ad-hoc, le type de cryptage et le mode d'authentification lorsque WEP est sélectionné. Si des personnes équipées de windows et d'une connexion wifi peuvent confirmer, elles sont les bienvenues.

La freebox dans sa configuration par défaut se comporte comme une passerelle DHCP; c'est elle qui négocie la connexion auprès du FAI et transfère l'adresse IP au niveau de l'interface du PC auquel elle est reliée; la freebox se comporte alors comme un équipement de niveau 2 totalement transparent pour la couche IP. Le pare-feu est donc nécessaire pour protéger le PC qui se trouve derrière une freebox native; attention cependant aux pare-feu un poil alarmistes qui détecteront une tentative de corruption de cache ARP du fait du transfert de l'adresse IP publique de la freebox vers le PC. L'interface réseau du PC n'a en pratique qu'à réaliser une requête DHCP à la freebox pour obtenir ce tranfert d'adresse IP. La configuration du FW est par la suite identique à n'importe quel autre cas.

L'encryption WEP propose deux modes d'authentification, l'un en mode ouvert où l'AP accepte les débuts de connexion non cryptée et l'autre en mode partagé/restreint où les premiers échanges doivent être encryptés. Vérifié également que tu sois bien configuré en mode infrastructure et que le filtrage MAC de ton AP ne soit pas actif le temps de lui faire apprendre ton périphérique (bouton association sur l'AP en général)

exact, je ferme ce sujet étant donné que tu as mis ton rapport Smitfraud dans ton topic original

ben oui avec smbfs tu montes les partages samba où tu veux idem avec nfs suffit de le configurer (éditer fstab)

smb en effet ou nfs

HTTP fonctionne sur TCP car ce protocole de transport assure l'arrivée et l'ordonnancement des paquets échangés entre le serveur et le client. UDP n'offrant pas de telles fonctionnalités, son intérêt est très limité pour du http, voire quasi nul. Un projet de faire passer HTTP sur UDP a existé mais celui nécessite un client (navigateur) et un serveur remaniés au niveau du code source. Si ça t'amuse: http://www.cs.technion.ac.il/Courses/Compu...p_udp/index.htm

c'est toujours agréable d'avoir un bonjour, une petite intro du contexte qui vous a amené à faire une analyse HJT, c'est tellement plus sympathique pour les bénévoles qui se décarcassent pour vous... si c'est pas du foutage de gueule...

SynTPEnh.exe ne seait-ce pas les drivers Synaptics d'un touchpad? tu as un portable? une réinstallation est peut-être nécessaire vu que tu as du les "fixer" suite à l'analyse de ton log HJT.

AuthUserFile /.htpasswd

la directive Authuserfile "regarde" l'emplacement du fichier htpasswd en relatif par rapport au .htaccess => autrement dit dans c:\program files\easyphp1-8\www\monsite\www\monsite\.htpasswd est ce bien là que tu as mis ton htpasswd? et tu peux parfaitement utiliser l'encryption MD5 pour hasher les mots de passe

ça génère du traffic chez eux (faut bien aller sur leur site pour héberger l'image, quand tu demandes où tu peux héberger une image, on te dit www.hebergeimage.com), et qui dit traffic dit pub, qui dit pub dit argent... nous ne voyons pas d'autres explications

ben tu rajoutes single à la ligne: boot: linux noapic nolapic hw-detect/start_pcmcia=false single tu seras uniquement en mode texte, nano est un éditeur de texte assez intuitif vi nécessite un petit apprentissage: passage en mode édition: touche INS passage en mode commande: touche Esc commande pour enregistrer et quitter (write and quit): :wq <-- attention à bien indiquer les :

DHCP est en effet un protocole applicatif puisqu'il passe par UDP 67 mais est un peu sépcial. N'ayant aucune connaissance du réseau dans lequel il se trouve, les trames initiales émises par le client (DHCP Discover et DHCP Request) sont des messages adressés en diffusion (broadcast = 255.255.255.255) avec comme IP de référence 0.0.0.0 (qui désigne la machine locale) + l'adresse MAC de l'interface. Si un serveur répond à la trame DHCP Discover, le PC se voit attribuer une adresse IP valide sur le réseau. Dans un monde idéal, la couche IP est correctement établi et tous les autres protocoles fonctionnant sur IP en mode connecté ou non peuvent converser joyeusement avec leurs voisins. Quel message d'erreur (code/type ICMP) obtient-tu lorsque les pings ne passent plus? Peut-être la couche physique est-elle instable? le driver couche basse du périphérique est peut-être buggée (NDIS)? ...

si c'est la distance qui pêche, il faudra investir dans un répéteur wifi. (ou bidouiller une antenne plus puissante pour la LB)

c'est un peu vague comme info... tu essayes de te connecter comment (parce que du HTTP pour OPenVPN ) tu as bien créé les différents certificats pour le serveur et les clients, distribuer les clés publiques,...

Comment sont configurées tes cartes réseaux?