Greywolf

c'est une licence OEM dont tu disposes ?

attention, virtualbox émule un PC qui n'a rien à voir avec le matériel que tu possèdes (tout est virtuel), ce n'est pas un hyperviseur qui lui permet à plusieurs OS de fonctionner sur une même machine physique en même temps (i.e. avec les vrais composants qui la composent)

bonjour, qui te connectes à internet? quel serveur smtp utilises-tu? quel est le mode d'authentification au serveur smtp (authentifié ou non, port 25 ou 587 ?)

normal, si tu ne dis pas à ping le nombre de requetes echo que tu veux faire il continue en boucle (man ping ou renseigner -c x dans la ligne de commandes, x étant le nombre de requêtes à effectuer). Au delà de cette considération, le test de ping est concluant: la couche réseau fonctionne entre les deux appareils je n'ai pas relu le fil du sujet entièrement: tu as testé d'autres navigateurs? (si ça se trouve l'interface est uniquement compatible IE ) il n'y a pas de demande d'authentification via une popup bloquée ou quelquechose du même genre? tu peux tenter lynx en ligne de commande

ProfNotes ? beuh, j'ai essayé 2 minutes avec Wine, du VB à tout va => résultat, une virtualBox sur le PC avec windows et profnotes dedans...

Pourquoi installer quelquechose de supplémentaire quand iptables fournit déjà ce qu'il faut? 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 http://forum.zebulon.fr/index.php?s=&s...st&p=729965

182.xxxxxxx. ? Vérifiez que le chemin d'accès ou l'adresse internet sont corrects ne serait-ce pas plutôt 192.168.x.y ? Comment est tu connecté à ton routeur? peux tu, dans une invite de commande ms-dos (démarrer => exécuter => cmd), taper ipconfig /all et nous en donner le résultat? (tu peux éventuellement masquer l'adresse physique mais cela n'est pas forcément nécessaire)

bonjour, as-tu au moins jeté un coup d'oeil au fichier dhcpd.conf? Je ne connais pas tes besoins spécifiques en terme de serveur dhcp mais je mets ma main à couper qu'il contient un exemple détaillé de ce que tu souhaites faire http://ftp.traduc.org/doc-vf/gazette-linux...html#lg98l-2.fr

fort probablement une cochonnerie attrapée suis la procédure décrite ici http://forum.zebulon.fr/procedure-de-deman...oy-t138211.html et poste les rapports demandés (HijackThis et diaghelp) dans le forum dédié http://forum.zebulon.fr/index.php?act=SF&s=&f=51

il faut autoriser en sortie UDP 53 (DNS) et TCP 80 (http) si tu veux le net sur cette machine iptables -A OUTPUT -o eth0 -d <adresse_de_ton_serveur_dns_si_tu_veux> -p udp --dport 53 -j ACCEPT iptables -A OUTPUT -o eth0 -p tcp --dport 80 -j ACCEPT

exécuter dans une invite de commande regsvr32 chemin/vers/la/dll/qui/n'est/pas/energistrée

pour la configuration des cartes => /etc/network/interfaces (man interfaces pour la doc) pour la configuration du serveur dhcp => /etc/dhcp3/dhcpd.conf le fichier est très bien documenté avec pleins d'exemples en fonction de la configuration à réaliser de plus, le fichier /etc/default/dhcp3-server permet de configurer le serveur pour qu'il n'écoute que sur une seule interface réseau au lieu de toutes par défaut Tous ces fichiers sont des fichiers texte éditables avec n'importe quel éditeur de texte il faut forcer la relecture du fichier de configuration après chaque modification (ou redémarrer le daemon si on veut faire bourrin) /etc/init.d/dhcp3-server force-reload

un script iptables pour autoriser les connexions sur le port 22 à partir d'une seule adresse IP et le port 8888 à partir de n'importe quelle adresse. Attention, la machine à partir de laquelle sera exécuté ce script ne pourra pas établir de connexions sortantes d'elle même, il faudra l'autoriser spécifiquement ou, plus bourrin, régler la politique par défaut de OUTPUT à ACCEPT remplacer $wan par l'interface (ethX, wlanX, pppX, .... donnant accès à internet ) toutes les lignes de commande doivent tenir sur une seule ligne (attention à la mise en forme du forum) #flush des règles préexistantes iptables -F INPUT iptables -F OUTPUT iptables -F FORWARD #Réglage des politiques par défaut (si aucune règle écrite ne correspond, c'est la politique qui s'applique) iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT #on accepte les connexions locales iptables -A INPUT -i lo -j ACCEPT #Règles pour les connexions entrantes sur $wan iptables -A INPUT -s <adresse.IP.de.lamachinedistante>/32 -i $wan -p tcp --dport 22 -m state --state NEW -j ACCEPT iptables -A INPUT -i $wan -p tcp --dport 8888 -m state --state NEW -j ACCEPT #rgèles pour les connexions sortantes (la machine n'émet pas de nouvelles connexions et ne fait que répondre à des connexions légitimes) iptables -A OUTPUT -o lo -j ACCEPT iptables -A OUTPUT -o $wan -m state --state RELATED,ESTABLISHED -j ACCEPT tu peux faire exécuter ce script dans rc.local pour qu'il soit effectif à chaque démarrage de la machine ne connaissant pas gnump3d, je ne sais pas si la simple connexion sur tcp 8888 suffise pour que le service fonctionne (streaming sur UDP ?)

peut-être que le pilote de ton interface wifi n'autorise pas le mode "prosmiscuous" nécessaire à une écoute passive

tu as essayé de faire un echo des différentes variables que tu calcules? (avant de faire la requête UPDATE; que tu peux commenter ou afficher)

le test sur zebulon est un TCP Scan, càd qu'il faut le "three-way handshake" pour considérer qu'un port est ouvert ou non (SYN/SYN-ACK/ACK ou SYN/RST-ACK/ACK). Le scan ne s'effectue par ailleurs que sur certains ports courants et pas sur l'ensemble de la plage tcp (trop long, trop coûteux en ressources). Si aucun de ces ports n'est à l'écoute et qu'aucun firewall ne droppe la réponse RST-ACK, les ports apparaitront comme fermés Si un firewall droppe le RST-ACK d'un port fermé (ou un SYN-ACK d'un port ouvert), le port apparaitra comme masqué Si il y a échange SYN/SYN-ACK/ACK, le port apparait ouvert

bonjour quel est le rapport de cette citation avec l'ouverture de port? la citation indique qu'un serveur http se met en écoute sur le port 80. C'est à dire que son processus est en attente de connexion entrante sur un socket TCP port 80. Le processus a demandé au système cet ouverture, le système peut autoriser ou interdire cette action (et pas un pare-feu qui stricto-sensu est chargée de filtrer le traffic, quand il y en a). Un client http (un navigateur web par exemple) se connecte par défaut à l'url qui lui est transmise en argument à destination du port TCP 80. Il est possible d'indiquer au client http de se connecter sur url:9324 si l'envie nous prenait (et pour peu que nous sachions qu'à l'adresse indiquée quelquechose écoute sur le port TCP 9324). Là le client http ouvre un socket dans la couche haute des ports TCP (ports non attribuées à un service qui ne requiert pas de droits administrateurs pour l'ouverture), i.e. > 1024. Fort de cette ouverture de socket, le client envoie sa requête http vers l'ip résolue correspondant à l'url transmise. C'est là que le pare-feu peut filtrer (vu qu'il y a du traffic); il "voit" la tentative d'envoi et tâche de déterminer si la connexion vers TCP 80 est légitime ou non au vu de sa configuration. UPnP permet d'ouvrir et de router automatiquement les ports nécessaire au fonctionnement d'une application à la fois client et serveur. Le soft émet une requête upnp vers le routeur compatible, le routeur reconnait l'application et va router les connexions entrantes (wan -> lan) vers le PC émetteur. Dans le même genre, on a le port triggering qui ne sont que des évolutions du suivi de protocole normé (conntracking) Un firewall n'est pas un proxy applicatif (ou alors on mélange tous les termes), il n'a pas pour rôle de verifier que ce qui transite à destination de TCP 80 contient bien une requête http (niveau 7 OSI, couche applicative) correctement formulée etc etc ... ça c'est le travail d'un proxy ou d'un IDS un parefeu sur chaque poste de travail c'est bien,encore faut-il que les gens sachent le configurer (et si en plus ils sont administrateurs de leur machine .... ). En entreprise, avoir un routeur filtrant permet de centraliser la gestion. Afin de pallier les lacunes d'un pare-feu déporté(niveau 3), il existe des projets avec authentification utilisateur (qui a le droit de faire quoi d'où qu'il se connecte): http://www.nufw.org/ il me semble que de nombreuses personnes confondent la notion d'ouverture de port (application serveur en écoute de connexions entrantes) de l'autorisation de flux sortants (à destination d'un port défini)

chmod u+x bonjour

en effet, le fin ack n'est pas une exclusivité zebulon http://linux-france.unixtech.be/prj/inetdo...cteristics.html l'échange FIN/FIN-ACK n'est pas une demande de connexion mais la notification de clôture ton PC (ou ZA) peut ne pas attendre le FIN/ACK du serveur qui est l'accusé de réception de la demande de fin de connexion que tu as initiée. Retrace tes sessions TCP et il sera peut-être possible de voir qqch

salut, retrace tes sessions TCP avec wireshark. Tu pourras regarder le payload aussi Si ça se trouve c'est un FIN ACK qui arrive et qui est filtré par le pare-feu.

copie de mon MP oula non tu m'as mal compris (ou je me suis mal exprimé) le .htaccess contenant le chemin absolu doit être mis dans le répertoire à protéger Tu as 3 .htaccess à faire à la racine Options -Indexes dans le répertoire .Nikita deny from all dans le répertoire à protéger (admin en l'occurence) PerlSetVar AuthFile /mnt/104/sda/4/f/wullfk/.Nikita/list.txt AuthName "Acces Restreint" AuthType Basic require valid-user c'est plus compréhensible?

Si un logiciel tiers (fourni avec le pilote de l'interface wifi en général) a été configuré pour s'occuper du réseau wifi, cet onglet n'apparait pas. Il faut désactiver ce logiciel ou le configurer pour qu'il ne s'occupe de rien

sous win98, cela passait par l'installation d'un pilote RasPPPoE ou WinPoET A toi de désinstaller ce pilote dans les propriétés de ta connexion réseau (là où il y a protocole TCP/IP, clients pour réseaux microsoft windows,...)

Si tu utilises IRC, le fait de laisser ce port répondre qu'il est effectivement fermé accélère la phase d'authentification avec le serveur distant (il laisse tomber auth pour passer au challenge login/password). Souci potentiel: ton PC n'est plus invisible (masqué) vu de l'extérieur Si tu utilises IRC et si tu masques le port 113 avec ton pare-feu, la phase d'authentification sera plus longue (attente du time-out de connexion) Si tu n'utilises pas IRC, autant faire en sorte que ce port soit masqué. Tout dépend donc de ton utilisation

php n'a rien à voir avec .htaccess, c'est directement interprété par Apache Je ne comprends pas pourquoi la désactivation de l'indexation du répertoire racine entraîne une erreur dans DotClear tu as viré le répertoire admin? suite en MP