FAQ LinuxConsultez toutes les FAQ

Placez les urls dans un fichier texte (nommé par exemple pg_dwd), et tapez simplement :

$ wget -i pg_dwd

Sur un réseau de classe C :

$ ping -b 192.168.0.255

L'adresse IP dépend de l'adresse de broadcast du réseau.
Si par exemple vous avez un serveur DHCP qui vous fournit automatiquement une IP, la commande :

$ ifconfig ethX

vous donnera l'adresse de broadcast.

Oui. Vous pouvez utiliser Lynx (présent dans la plupart des distributions), ou encore w3m.

Mettez dans un script au démarrage (par exemple : /etc/rc.local)

#Active le forwarding dans le kernel 
echo 1 > /proc/sys/net/ipv4/ip_forward                
# Efface les règles actuelles 
iptables -F                                           
# idem 
iptables -t nat -F                                    
# Active le routage vers ppp0
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE  

Voici diverses méthodes pour récupérer uniquement l'adresse IP en ligne de commande, utile pour intégrer dans un script.

Si vous avez une interface Ethernet :

ifconfig eth0 | grep inet | cut -d":" -f2 | cut -d" " -f1

Si vous avez une interface PPP :

/sbin/ifconfig | grep "P-t-P" | sed "s/^[: a-z]*\([.0-9]*\).*/\1/"

Pour trouver l'adresse de la passerelle :

user@host:~$ awk '/eth0/{print $1}' /proc/net/arp 
192.168.0.101 

Ou bien (toujours pour la passerelle) :

grep $(awk '/\t0003\t/{print $1}' /proc/net/route) /proc/net/arp | cut -d ' ' -f 1 

Ou encore :

grep $(netstat -arn |grep UG |awk '{ print $8 }' ) /proc/net/arp |awk ' {  print $1 }'

Depuis la machine A, je veux une connexion rsh vers une machine B pour un user.
Entre les deux machines, il est important d'avoir le même UID pour le user.
Configurer la machine B:
Dans le répertoire home du user, créer un fichier .rhosts (700 au niveau des droits) contenant

machineA mon_user

Dans /etc/hosts, rajouter la machineA

x.x.x.x    machineA

Dans (x)inetd, décommenter ou rajouter le service rsh et rlogin

shell  stream tcp  nowait root   /usr/sbin/tcpd       in.rshd

Configurer la machine A:
Dans /etc/hosts, rajouter la machineB

y.y.y.y   machineB

Tester la connexion
Lancer une commande depuis la machine A:

rsh machineB "hostname"

Si le hostname de la machine B apparait, c'est bon.

Je veux connecter deux pc par le port parallèle (via un cable de type LAPLINK) et que le second pc puisse accédé à internet (dans mon exemple je suis sous debian). La gestion TCP/IP via le port parallèle est géré par le module plip :


pc1 : 192.168.1.10 est connecté à Internet sur eth0
pc2 : 192.168.1.9 n'a que le port parallèle

sur pc1 :

Si le pc1 possède un système d'impression il faut le désactiver pour pouvoir enlever le module imprimante du port parallèle. Dans mon exemple mon gestionnaire d'impression est CUPS :

# /etc/init.d/cupsd stop
# rmmod lp

sur pc1 : J'ajoute la gestion de TCP/IP par port parallèle :

# insmod /lib/module/2.6.x.x/kernel/driver/net/plip.ko

(plip dépend de parport.ko et parport_pc.ko, il faut les charger de la même manière s'il ne le sont pas déjà)

On ajoute l'interface plip0 (vérifier avec dmesg si c'est plip0 ou plip1 ou etc....)

ifconfig plip0 192.168.1.10 pointopoint 192.168.1.9

On va permettre la redirection pour que l'autre PC puisse se connecter à Internet :

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE

eth0 est l'interface qui est connecté à Internet
sur pc2 :
Je charge le module plip de la même manière que sur pc1
je définis l'interface de connection :

ifconfig plip0 192.168.1.9 pointopoint 192.168.1.10

Je définis PC1 comme 'routeur' :

route add default gw 192.168.1.10 plip0

Je copie les lignes commençant par 'nameserver' du fichier /etc/resolv.conf de pc1 dans /etc/resolv.conf de pc2 (pour les DNS, la résolution des noms)
Voilà pc2 à accès à internet et peut se connecter sur pc1.

Voici dans l'ordre la liste des opérations pour diagnostiquer. Suivant leurs succès/échec, vous pouvez ainsi en déduire votre problème.
Si vous utilisez un proxy, vérifier que votre navigateur est bien configuré pour passer par le proxy.
Pour vous assurez que c'est votre navigateur qui pose problème, essayez :

ping www.google.com

Si le ping est bon, alors c'est le navigateur. Sinon, afficher /etc/resolv.conf

more /etc/resolv.conf

Vérifier que la ligne

nameserver x.x.x.x

contient bien l'adresse ip du serveur DNS de votre FAI. Modifiez la ligne, le cas échéant et recommencez le ping www.google.com
Si le fichier est bien renseigné, faites un

ping 216.239.57.104

C'est l'adresse IP de google.
Le ping est bon, alors tout va bien, vous avez bien un accès au web. Vérifiez l'adresse dns et le fichier /etc/resolv.conf

Votre ping ne passe pas? La connexion n'est pas établie. Vérifier votre configuration ethernet, adresse ip/passerelle grâce à la commande ifconfig.
Faites un ping de votre passerelle :

ping x.x.x.x

Si ce ping passe bien mais le ping de 216.239.57.104 alors votre problème se trouve au niveau du routeur.

/etc/hosts contient une liste d'association nom de machine - adresse IP permettant de bypasser la résolution de nom classique (qui interroge les serveurs DNS) pour quelques serveurs dont on connaît l'adresse. Typiquement utilisé pour renseigner des noms de machines locales, plus facilement accessibles par leur nom qu'en tapant l'adresse complète. Le format du fichier est très simple :

127.0.0.1    localhost.localdomain    localhost
192.168.1.11    mamachine
192.168.1.12    monpc    lepc

En première colonne l'adresse de la machine, ensuite en 2e colonne (séparée par un espace ou une tabulation) le nom correspondant, suivi éventuellement par ses alias.

/etc/host.conf définit la séquence de recherche pour la résolution de nom. En général on trouve ceci :

order hosts,bind
multi on

Cela signifie que le résolveur commencera par chercher dans le fichier /etc/hosts, puis interrogera le DNS. Le multi on veut simplement dire que le résolveur renverra toutes les adresses qu'il trouve pour un nom inscrit dans le fichier hosts, et non seulement la première. C'est l'option par défaut sous Debian et sans d'autres distributions aussi.

Le but de l'opération est que l'utilisateur A de la machine Source se connecte comme utilisateur B de la machine Destination. L'opération est un transfert de clé publique entre votre Source et votre Destination.
Sur la SourceEn tant qu'utilisateur A, vous devez générer une paire de clé RSA privée/publique :

ssh-keygen -t rsa -b &gt nombre de bits de la clé &lt -N ""

Je conseillerai 4096 pour la complexité de la clé.
Deux fichiers sont apparus dans ~/.ssh :

• id_rsa
• id_rsa.pub

id_rsa correspond à la clé privée
id_rsa.pub correspond à l'autre clé, celle publique.

Sur la DestinationLa clé publique va être recopié sur la Destination dans ~/.ssh/authorized_keys :
Vous avez un fichier dans le format suivant

ssh-rsa &gt la clé publique&lt A@Source

Maintenant depuis la machine Source en utilisateur A, il vous suffit de faire :

ssh B@Destination

Linux accepte la création d'interfaces réseaux virtuels de manière simple, il suffit de configurer une carte eth0:1.
exemple

/sbin/ifconfig eth0:1 192.6.1.23 broadcast 192.6.1.255 netmask 255.255.255.0

Ceci autant de fois que l'on désire d'interfaces différentes.

Outre les outils graphiques qui peuvent être inclus dans votre distribution, la désactivation et l'activation d'une interface réseau se font respectivement par les commandes ifdown et ifup, en passant en argument le nom de l'interface.

L'interface pour un modem se nomme ppp0, pour une carte réseau eth0. Ainsi, pour réinitialiser la connexion du modem, cela donne :

/sbin/ifdown ppp0
/sbin/ifup ppp0

Pour connaître quelles sont les interfaces réseau sur votre machine, y compris les non actives :

/sbin/ifconfig -a

Avant toute chose plantons le décor : Nous avons un réseau local, un firewall, et l'internet

LAN <====> Firewall <====> Internet

• On ne maitrise pas les machines du réseau local (donc on ne peut pas désinstaller skype)
• Le firewall est déjà configuré de façon assez restrictive. Le traffic autorisé est donc très restreint (HTTP et HTTPS au moins, plus une poignée de trucs en plus comme le NTP, l'IRC, etc)
• Comme le firewall laisse passer le HTTPS : skype passe (d'ailleurs le HTTP suffirait s'il n'y pas de filtre applicatif HTTP). Nous désirons cependant bloquer Skype du LAN vers Internet.

Après quelques recherches, j'ai noté quelques aspects du protocole Skype qui semblaient intéressants :

Au tout début du protocol, Skype tente de se connecter à un Super Noeud. Un Super Noeud c'est, en substance, un utilisateur normal qui a été élu pour tenir la fonction de super noeud en vertu de sa bande passante et de son uptime au dessus du lot. Un super noeud attend les connections sur un port préférentiel qu'il définit arbitrairement et aléatoirement, mais également sur les ports 80 et 443.
Comme les super noeuds sont des utilisateurs normaux Skype n'embarque pas de liste de super noeud "en dur" dans l'exécutable, c'est une liste dynamique et on ne peut donc bien entendu pas bloquer toutes les ip des super noeuds en dur sur le firewall. Chaque entrée de la liste est constituée d'un couple : adresse IP du super noeud, et port préférentiel du super noeud (ce port étant, je le rappelle, choisi aléatoirement par le super noeud).

Skype tente donc de se connecter de la façon suivante à un super noeud (dès qu'une connection est établie les étapes suivantes ne sont, bien entendu, pas tentées) :

• Tentative de connection en UDP aux super noeuds sur leur port préférentiel
• Tentative de connection en TCP aux super noeuds sur leur port préférentiel
• Tentative de connection en TCP aux super noeuds sur le port 80 (HTTP)
• Tentative de connection en TCP aux super noeuds sur le port 443 (HTTPS)

Généralement donc, sur un réseau firewallé, skype commence à jouer les passe muraille à partir de l'étape 3.

Une fois connecté à un super noeud le protocole de connexion continue, mais cette suite ne nous intéressera pas puisque nous allons tenter d'empécher toute connexion à un super noeud (ce qui fait abandonner à Skype la tentative de connexion et remplie donc notre cahier des charges : Skype est bloqué !)

Si vous avez bien suivi, vous avez déjà deviné comment je propose de bloquer Skype.
Le principe :Lorsque Skype tente de connecter des super noeuds en UDP sur leur port préférentiel cela se repère aisément au niveau du firewall (les ports étant "exotiques" il y a bien peu de chances qu'ils soient autorisés à sortir) et on va donc, grâce au module recent d'iptables, mémoriser les ip des super noeuds. Ensuite l'idée est simple : toujours grâce au module "recent" d'iptables on DROP tous les paquets (tcp et udp, sur tous les ports, ou au moins 80 et 443) en provenance de ces super noeuds pendant 10 minutes. De cette façon Skype ne parvient jamais à connecter un Super Noeud (puisque nous bloquons les SYN retour), et il abandonne les tentatives de connexions.

Bien entendu cette méthode a quelques "désagréments" :

• Si, par malheur, un interlocuteur extérieur autorisé se trouve être un super noeud que quelqu'un du réseau local tente de contacter, il risque de ne plus être accessible depuis le réseau local
• Si un individu mal intentionné sur le réseau local est au courant du fonctionnement de ce filtrage il lui est plus qu'aisé de couper toute communication entre les serveurs de son choix et le réseau local (joli DoS encore une fois, au moins pour les ports 80 et 443)

En résumé : cette méthode est utilisable pour des réseaux où la sûreté de fonctionnement n'est pas critique (tout à fait au hasard on va dire : sur le réseau local d'une résidence étudiante par exemple ^_^ ).

Maintenant place au code :

#!/bin/bash

#.................Début du script de firewall
#.................flush des tables principalement

#premiere regle a mettre : on drop tout ce qui vient d'une ip identifiee comme super noeud.
iptables -A FORWARD -m recent --rcheck --name skype_super_noeuds --second 600 -j LOG
iptables -A FORWARD -m recent --rcheck --name skype_super_noeuds --second 600 -j DROP

#.................suite du script de firewall,
#.................éventuel nat,
#.................tout les jumps en ACCEPT y compris sur ESTABLISHED
#.................etc

#en fin de script on memorise les ip des Super Noeuds grace a la tentative d'udp sur port bizarre
iptables -A FORWARD -p udp -m recent --name skype_super_noeuds --rdest --set
#on memorise toutes les autres tentatives bizarre, 
#en effet j'ai cru remarquer que pour certains Super Noeud skype tente directement en tcp sans passer par la case udp...
iptables -A FORWARD -p tcp -m recent --name skype_super_noeuds --rdest --set

Etant donné que Skype peut aussi passer les proxy applicatif via httpS (port 443) et ne voulant pas bloquer https, je n'ai trouvé qu'une solution qui ne m'a pas franchement satisfaite et que je n'ai d'ailleurs pas testé. A savoir : bloquer les accès https sur ip n'ayant pas de résolution DNS au niveau du proxy... d'où la solution alternative que je propose et qui se passe de proxy applicatif (plutôt gourmand en cpu)