Alexandre Dombrat a écrit 88 commentaires

La règle par défaut est donc d'accepter les paquets. Ensuite, normalement, tu devrais avoir des règles spécifiant l'action à lancer selon le port, le type de trame (tcp/udp/icmp), l'interface et les adresses...
Ici, tu n'as rien ! Donc tous les paquets passent, là c'est comme si tu n'avais pas de firewall !!

Mieux vaut alors regarder si tu as des ports réellement ouverts: netstat -taupenl (affiche la liste des ports que ta machine écoute, et les connexion ouvertes).
Si tu as des lignes avec les ports ssh, http... (se référer aux numéros de port respectifs), alors ça devrait normalement être possible de les atteindre (vu que tu n'as pas de règles de firewall...).

La solution radicale comme le disait "or zax", est effectivement de désactiver les services dont tu n'as pas l'utilité. Ca évite la machine d'écouter les ports en question (ce qui reste une faille potentielle pour le cas où une attaque traverse le firewall...).
Moins tu laisses de ports ouverts, mieux c'est !!

Le ping n'est effectivement pas un pb important, le plus grave c'est l'accès à tes services...
Tu peux d'ailleurs tester si tes ports peuvent être écoutés sur le réseau avec ce petit outil très sympa: nmap.

Shorewall est en fait une interface à iptables (si j'ai bien compris shorewall car j'utilise directement iptables).
Donc si tu veux vraiment savoir ce qui est autorisé/refusé sur ton firewall, essaie cette commande: iptables -L -v -n, elle t'affiche la totalité des règles pour la table filter. Tu y trouves la politique appliquée par défaut (DROP/ACCEPT par exemple), et pour chaque règle tu vois ce qui en est. Si l'icmp est refusé (ou pas accepté), alors le ping est impossible.

En revanche, les ports ssh/http/... que tu ne souhaites pas visibles sur le réseau, c'est pour tout le réseau ou sur une seule interface de ton routeur ?

Portable: Compaq Presario 2100, avec une Radeon IGP 320M.

Je n'ai pas réussi à prendre autre chose que vesa pour Xfree. A noter que sur un autre portable (carte S3), le vesa n'empêchait pas de lancer mplayer (c'est juste que le fullscreen était grugé car il n'étendait pas l'image à la largeur de l'écran... ça conservait la taille réelle de la vidéo, mais là je m'égare...)

Je suis aussi d'avis que mon xfree n'est pas très bien configuré... Tu voudrais le listing de mon XF86config-4 ?

Très honnêtement, je n'ai jamais eu de pb avec ma Debian pour le matériel USB ou la carte son. D'accord, l'interface n'est pas graphique et ça peut dérouter quelques-uns, mais j'installe tout sans pb en mode console (apt-get) et à l'aide d'interfaces avec ncurses (modconf par exemple).
Pour ce qui est de l'installation, tu peux toujours utiliser aptitude qui est assez sympathique pour installer un package quand tu veux.

Si tu ne veux/peux pas récupérer les packages depuis le net (ou un miroir local, ce que je fais), tu as le choix avec une version en 7CDs qui regroupent l'essentiel.
D'ailleurs, configurer le réseau est plutôt aisé, donc je vois pas trop de pb pour avoir le net...

Une stratégie intéressante consiste à ne pas suivre trop loin les instructions d'installation. Je configure le clavier, prépare mon disque, configure le réseau et installe le minimum. Ensuite, je reboote normalement (sans le CD) et j'installe tout le reste. Le CD d'install ne me sert donc que pour avoir un système minimal à partir duquel je peux développer mon système à mon goût.

Ah oui, et LILO ne m'a jamais posé de pb.

Pour ce qui est de répondre à cette question, j'admets que Debian n'est pas totalement à la portée du débutant, car cela nécessite de savoir un peu ce que l'on fait. Je pense donc pour débuter que soit on a un proche qui maîtrise Debian et peut nous aider à chaque instant et donc Debian ne pose pas de pb, soit on est un peu trop seul et dans ce cas on tentera plutôt Mandrake/RedHat.
Je dirais donc que si tu veux savoir lequel prendre, c'est en fonction de ses amis/connaissances. Si ils maîtrisent mieux l'une que les autres, autant prendre celle-ci car ils pourront t'aider en cas de pb.

Après, c'est une question de goût et troller apportera beaucoup de texte sans apporter de solution. La seule solution, c'est à chacun son système, du moment qu'on s'y sent bien...

Très franchement, si tu veux vraiment te faire une idée, la meilleure chose à te conseiller c'est d'essayer les trois !! Comme ça, tu seras fixé et tu verras par toi-même.

Je sais pas si tu as eu l'idée de faire un man iptables ou de chercher sur google (par exemple), mais tu aurais alors eu des tas de tutoriels pour répondre à ta question.

Je vais néanmoins t'en dire plus. :)

Voici un début pour savoir comment fonctionne iptables avec un exemple:
iptables -A OUTPUT -o eth0 -s 192.168.0.0/16 -p tcp --dport 80 -j ACCEPT
Ceci te fait accepter les paquets sortants sur ton interface eth0 dont l'adresse source est 192.168.0.0/16 (note bien la présence du masque avec le /16), en trafic TCP et vers un port HTTP (80) pour l'adresse de destination (non spécifiée ici, donc c'est valable pour n'importe laquelle).

Ensuite, il existe tellement de doc sur le sujet que tu n'auras aucun mal à trouver de plus amples explications en googleisant un peu... ;)

le pb avec LOG, c'est qu'il te loggera tout dans /var/log/syslog avec le reste des logs, ce qui peut causer quelques pb.
Essaie donc de voir avec ULOG (qui nécessite un démon du même nom je crois), qui te permettra de logger tous les logs iptables dans un fichier à part (du nom de ton choix).

Pas bête ton script, mais j'ai l'impression que ça ne lui conviendra pas, car le script envoie toujours avec la même adresse, et lui il veut en fait le faire sous des adresses différentes.
De plus avec cette commande, je ne sais pas comment serait rempli le champ objet par exemple (important pour tester un filtre anti-spam) ?

> c'est pas toi qui parlait de grammaire ? ;-)
On n'écrit pas plutôt "toi qui parlais" ??

> Thomas, qui espère ne pas avoir fait de fautes
Ne le prends pas mal, mais... si !! ;)

Pour en revenir au sujet de ce post, ça ressemble fort à du spam, que de vouloir bombarder une adresse mail, non ??
Je doute que cela soit déontologiquement correct...

Après, c'est vrai que j'ai pas trop compris (et je suis pas le seul apparemment) ce que tu voulais vraiment faire. :)

Ah, merci, c'est super cool, exactement ce qu'il me fallait !!
En fait, mon man est beaucoup moins prolixe que le tien... et du coup j'avais pas compris l'utilité de l'option bs !!
C'est cette option qui me manquait... :/

Merci encore ! ;P

merci ! ;)

Quelqu'un pourrait m'expliquer ce que signifie l'histoire des "2cents" qui reviennent si souvent sur DLFP ?

Pour savoir si un package est installé (sous Debian), il y a la commande dpkg -l "*monpackage*"|grep "^ii", ce qui renverra la liste de packages installés matchant le nom que tu lui donnes (ici, *monpackage*).

Pour ce qui est de l'option noauto dans fstab, ça n'a rien à voir avec l'automount.
noauto spécifie juste que le filesystem ne se montera pas automatiquement lors du démarrage de la machine (ce sera alors à toi de le faire à la main avec mount), mais regarde avec man mount pour de plus amples précisions. (le premier réflexe si tu sais pas, c'est man ;P )

Mais tu as raison sur le fait que certains périphériques peuvent s'automonter au moment où tu les insères (CD, cléUSB...), j'ai déjà entendu parler de ça sans savoir comment ça marche...

Si tu développes en Java (mais je crois que ça marche aussi pour d'autres langages, je me souviens avoir développé du C++ et rédigé mes rapports LaTeX avec) tu peux utiliser Eclipse qui gère très bien le CVS (en plus, ça marche nickel que tu bosses sous win ou sous linux ! :P ).

ntpdate est un programme
ntpd est un démon (ici, c'est aussi un service)

Pour les définitions, je résumerais par ceci:
démon: programme qui tourne en permanence.
service: c'est un programme qui réagit lorsqu'on lui fait une requête (exemple: httpd, proftpd... qui sont aussi des démons ! Ils réagissent en renvoyant une page web ou une connexion ftp)
programme: c'est une appli qui se termine une fois qu'elle a fini, mais qui peut aussi ne jamais s'arrêter, sauf quand on le lui spécifie (c'est alors un démon).

distinction entre la définition d'un démon ntpd et celui de ntpdate?
ntpdate n'est pas un démon !! Alors que ntpd tourne en permanence, ntpdate ne tourne que lorsque tu l'appelles, fait ce qu'il a à faire (càd une requête NTP) et se termine aussitôt !!
ntpdate n'est pas un programme qui tourne en boucle, il faut l'appeler à chaque fois que tu en as besoin. ntpd tournant en boucle, tu ne t'en soucies pas car il fait toujours son travail à intervalles réguliers (chaque heure environ pour le cas de ntpd)

J'espère que mes explications t'ont éclairé... et bon courage pour trouver la solution à ton problème !! A mon avis maintenant, peu de monde tombe sur cette page qui est devenue trop récente, les gens voient davantage les posts plus récents. Ca expliquera certainement le silence des autres... (pour mon cas, c'est parce que je suivais en fait l'actualité de ce post car je me sentais les capacités de t'aider).

C'est un peu dommage qu'un post soit ainsi "oublié" des visiteurs, car ça oblige à reposter un nouveau message pour la même question juste histoire de remettre le sujet parmi les plus récents... une idée à soumettre aux admins de Linuxfr ??

Les lignes en question ne sont pas des commentaires (un commentaire débute par un '#'), mais je ne sais pas trop à quoi elles servent, elles étaient par défaut dans ma config...

Ce qui me gêne dans ton log n'est pas le error 0.000015, mais l'offset qui reste nul... chez moi aucune valeur n'est nulle.
Tu n'as jamais ce genre de ligne ?? 15 Feb 13:14:53 ntpd[714]: time reset -0.161377 s
Dailleurs, je n'ai pas de RedHat, mais une Debian. Elle n'est pas constamment connectée au net (seulement durant la journée en fait) mais elle reste à l'heure quand même.
Je ne lance jamais de ntpdate sur cette machine, le ntpd se lance tout seul au démarrage et s'occupe du reste... et tout fonctionne !!

En clair, je ne sais plus du tout pourquoi ça ne fonctionne pas chez toi... désolé !! :/

Pour les actions d'iptables par défaut, il faut savoir que c'est à toi de les définir dans ton script... (comme ça tu es sûr et c'est plus propre aussi)
Mais vu que tu as vidé les tables NAT et FILTER avec ceci:
iptables -F
iptables -t nat -F
Je pense que les actions par défaut sont justement de tout laisser passer... (tu le constates d'ailleurs avec iptables -L -v -n, c'est indiqué par policy ACCEPT).
C'est pas sécurisé du tout, mais au moins tu peux te connecter !!

Et si tu essayais ceci ? (eth0 est donc ton interface vers le net et eth1 celle vers le LAN)
iptables -F
iptables -t nat -F
echo "0" > /proc/sys/net/ipv4/ip_forward
iptables -t filter -A FORWARD -i eth0 -o eth1 -s 0.0.0.0/0 -d 192.168.0.2 -p tcp --dport 22 -j ACCEPT
iptables -t filter -A FORWARD -i eth1 -o eth0 -s 192.168.0.3 -d 0.0.0.0/0 -p tcp --sport 22 -j ACCEPT
iptables -n net -A PREROUTING -i eth0 -s 0.0.0.0/0 -d $IP_WAN -p tcp --dport 28 -j DNAT --to-destination 192.168.0.3:22
echo "1" > /proc/sys/net/ipv4/ip_forward

Normalement, ça devrait marcher (mais je ne fais pas de port forwarding dans mon réseau, donc je n'ai rien testé !!)

mon fichier /etc/ntp.conf se trouve comme suit, si ça peut t'aider:
logconfig all
logfile /var/log/ntpd.log

driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server excalibur

Si ton offset est toujours à 0.00, c'est à mon avis parce que tu as mis localhost en server (127.0.0.1). C'est logique que l'horloge d'un ordi soit la même qu'elle-même !!
Tu devrais donc mettre server excalibur à la place pour que ton client se synchronise non plus avec lui-même mais bien avec excalibur !! ;)

En fait, je crois que le fichier drift contient l'écart qu'il a dû appliquer à ton horloge lors du dernier sync.
Le chemin keys est à utiliser si tu dois avoir une authentification par clés pour se synchroniser au serveur (genre clés SSH je crois, mais je n'ai jamais essayé, je n'utilise pas d'authentification pour NTP...)

En revanche, je ne connais pas les VmWare, je ne sais pas si ça vient de là.

Merci de m'avoir rectifié pour le WAN, j'ai fait un lapsus... Wide est la bonne transcription :)

Pour l'histoire de ton routeur, d'après ce que je comprends, c'est donc bien une architecture en DMZ (Demilitarized Zone ou un truc du genre... décidément, j'ai du mal avec les sigles !)

Une archi de ce genre serait la suivante au niveau des 3 réseaux:
-WAN sur ppp0 vers le net
-LAN sur eth0, c'est ici que sont connectés tes utilisateurs
-DMZ sur eth1, c'est ici qu'est connecté ton serveur web

Au niveau du routeur, c'est lui qui a tout pouvoir pour allouer/bloquer les accès d'un réseau à un autre.
Tu peux donc faire en sorte que LAN puisse accéder à DMZ (et uniquement sur le port 80 si tu veux), que LAN puisse accéder à WAN (pareil, tu spécifies les ports autorisés), et si tu veux que WAN puisse accéder à DMZ, tu fais alors du port forwarding, càd que toute requête depuis le WAN sur le port 80 de ppp0 sera renvoyée vers le port (80 aussi, mais tu peux justement faire ce que tu veux !) de ton serveur web.

Généralement, on n'autorise pas grand chose à sortir de la DMZ (en principe, personne n'a besoin de faire du net depuis ce serveur !) hormis les réponses aux requêtes venant de l'extérieur évidemment !! Comme ça, si ton serveur est compromis, le pirate ne pourra pas faire très mal au reste du réseau... (il faut toujours imaginer le pire !)

Ca, c'est l'archi qui est préconisée pour toute install d'un serveur web avec firewall (sur le routeur !) et LAN.

En revanche, j'ai pas vraiment compris pourquoi installer une seconde ligne ADSL... Comment ça, le routeur de leur site est fermé ??

Essaie de nous informer davantage sur le réseau, et ce que tu veux exactement faire, là je suis un peu trop dans le flou pour t'aider de manière efficace...

Ton port 123 est-il disponible en UDP sur ton serveur ??
Depuis ta machine cliente, essaie (sous root) un nmap -n -sU -p 123 IPduSERVEUR

Tu peux aussi faire sur le serveur (sous root) un netstat -taupenl pour vérifier que tu as bien un LISTEN devant 123/udp...

Il est possible qu'un firewall te bloque des accès... à ce moment-là il faudra regarder vers iptables si c'est le cas...

Je ne veux pas paraître pointilleux, mais tu confonds LAN et interface (ne le prends pas mal !!).

Une LAN est un réseau local comme l'indique son nom (Local Area Network).
Si ta passerelle a une LAN pour le net, alors ça s'appellerait plutôt une WAN (World Area Network)...

Un interface est le dispositif qui permet la liaison entre une machine et un réseau.
Exemples d'interfaces:
ppp0 (PointToPoint, je pense que ça doit correspondre à ce que tu appelles LAN)
eth0 et eth1 (Ethernet, tu peux les mettre pour tes accès à ton LAN2 et ton site LAN3)

Donc dans route, tu spécifies les plages d'adresses qui correspondent à ce que chaque interface relie, mais il nous faudrait effectivement plus de détails sur ces plages pour t'aider davantage...

D'ailleurs, ton fameux site, il est juste en interne ?? (une DMZ ?)

Pour ce qui est de iptables, ça te servira par contre à protéger ton système par firewall (iptables -t filter ...) et à déclarer ta passerelle (iptables -t nat ...), mais pas à router vers ton site.

Je viens de penser à un truc... (oui, ça m'arrive !!)
Et si tu coupais ton ntpd un petit moment ??
Tu en profites alors pour lancer ntpdate qui te recalera ton horloge, et ensuite tu lances ntpd pour garder l'ordi à l'heure à l'avenir ??
Bon, d'accord, ça fait revenir au pb du time server not found (je sais plus le message exact que tu avais...), mais je viens de réessayer sur mes machines, et ntpdate fonctionne bien une fois sur 5... j'avoue que j'ai pas tout compris, mais bon !! En clair, attends un peu avant de relancer un ntpdate (environ 5 à 10min je pense...)
On dirait que le serveur ne répond pas toujours au client si les requêtes sont trop rapprochées... ça doit être une sorte de sécurité, il faudrait consulter la doc du protocole...

En tous cas, l'avantage si tu arrives à faire ça, c'est que tu fera une grosse correction d'un coup et ensuite ntpd se chargera des petites corrections progressivement, sinon il risque d'avoir du mal à rattraper un tel retard !!

Sinon, je comprends ta lassitude à ne pas trouver ce que tu cherches...

Sur ma Debian, je trouve les paquets officiels ainsi que leurs sources sur http://packages.debian.org(...)
Pour la petite histoire, ça se passe généralement comme ceci.
Un auteur développe un programme libre et fournit les sources en tar.gz.
Un mainteneur de chez Debian est chargé d'en construire un paquet Debian, il doit pour cela modifier légèrement les sources (en fait, c'est juste les chemins d'installation/fichiersconf qu'il modifiera si ce n'est pas conforme à l'archi du système). Ces différences sont listées dans un fichier (qui est fourni sur la même page Debian que le paquet en question).
Ca te permettra d'avoir les sources liées à ta RedHat même si ça vient de chez Debian... :)

Donc les sources d'origine: fichier package.orig.tar.gz (c'est ce qui t'intéresse)
Les différences entre package/sources: fichier package.diff.gz

Donc si c'est juste les sources qui t'intéressent, tu peux aller voir sur la page citée au début de mon post, en précisant bien que tu veux le package source dans ta recherche.
D'ailleurs, je te donne carrément la page des sources: http://packages.debian.org/testing/source/ntp(...)

Voilà, amuse-toi bien !! :)

Rajout de dernière minute:
Je viens de voir ton nouveau post, je n'en sais pas plus que toi et ne peux malheureusement répondre à ce pb bizarre autant qu'étrange... je crois que tu devrais essayer de chercher sur google un peu de doc sur le sujet... (il y a aussi un package ntp-doc qui existe sous Debian et qui copie des fichiers html dans /usr/share/doc/ntp-doc, vérifie pour l'équivalent sous RedHat !)
Bonne chance !

ben je suis pas un expert dans la signification de ces logs, mais je dirais que error n'est pas le nb de paquets perdus. Ca doit être plutôt l'erreur de mesure pour la sync des horloges...
Pour connaître la signification précise de ces informations, il faudrait regarder les spécs de NTP et certainement le code source de ntpd... mais ça me tente pas trop en ce moment, j'ai un peu d'autres chats à fouetter !! (oh non, les pauvres bêtes...)

A la vue de ton log, tout ce que je peux te dire c'est que ton ntpd tourne correctement, et qu'en attendant un peu il va te régler ton horloge comme il faut.

En revanche, je viens de relire le man ntpd, et ils parlent de la correction de l'horloge. Si l'écart est trop important, ça peut prendre des heures pour décaler progressivement l'horloge jusqu'à l'heure exacte (ntp ne règle pas l'horloge d'un coup mais procède à de petites corrections amorties dans le temps...). Du coup, je pense encore moins que ça marche de lancer ntpd juste pour quelques heures si ton horloge est totalement déréglée pour tes tests.

En règle générale, quand tu cherches des infos sur une commande ou un fichier de conf du système, tu appelles man dans une console (shell).
Ici, man fstab te renvoie une description des champs de ce fichier, mais pour le quatrième champ, il dit surtout For more details, see mount(8).
Donc regarde avec man mount et tu as la liste des options. :)

Je vais être sympa, je vais te suggérer une modif de ton /etc/fstab, tu as effectivement trouvé la ligne à modifier, et voici ce que tu peux mettre à la place:
/dev/hdb5 /mnt/win_c2 vfat noauto 0 0Tu peux rajouter l'option user si tu veux autoriser un utilisateur à monter/démonter ton disque, sinon c'est limité à root (ce qui est recommandé pour des raisons évidentes de sécurité !).
/dev/hdb5 /mnt/win_c2 vfat user,noauto 0 0

Pour ce qui est de la signification des entrées de ce fichier, voici un bref résumé de la fonction de chaque champ:
1) la partition
2) le point de montage
3) type du filesystem (vfat,ntfs,ext3,iso9660,swap...)
4) options. Il faut au moins en spécifier une, et les séparer par des virgules et sans espaces.
defaults (=auto,rw,suid,atime,async,nouser,dev,exec)
user: autorise un utilisateur non-root à monter le fs
nouser: limite le mount/umount à root (option par défaut)
ro: read only=accès en lecture seule
rw: read-write=accès en lecture et écriture (option par défaut)
auto: monte le fs (=filesystem ou partition) automatiquement lors du boot (option par défaut)
noauto: ne le monte pas lors du boot
...(il y en a plein d'autres, elles correspondent à l'option -o de mount =>man mount)
5) (là, javoue que j'ai pas tout capté sur le fonctionnement... cette valeur est 0 pour chacun de mes fs... quelqu'un sait-il à quoi ça sert ??)
6) utilisé par fsck pour vérifier la partition (0=pas de vérif, 1=réservé au point de montage root "/", 2=les autres points de montage pour qu'ils soient vérifiés à chaque reboot)

Ensuite, tout dépend de ce que tu veux faire de ce fs (droits en accès/mount...). Normalement, avec tout ça, tu devrais t'en sortir, sinon... ben tu sais où demander, on est là !! ;)