Il faut bien tester vos capacités.

Pour faire simple, à part le SSH en root sur le port 22, j'ai pas compris grand chose. Captain Obvious fait-il un forfait à la journée ?

Hum DNS, DHCP, les deux ou avec d'autres services ?

"Pas d'UPS ou de backup."
-Pas de salle machine ? En même temps un backup régulier pour un dns ... Tu mets la conf dans la doc du réseau.

"Des tas de règles iptables autorisant des connexions SSH depuis des adresses IP dynamiques."
-Enfin, je ne vois pas de problème pour cela. Ce n'est pas rare qu'un admin possède un ordinateur portable et qu'il ne rentre pas d'ip à la main à chaque changement de réseau sur les site différents. Tant qu'on arrive pas à taper dedans avec une ip publique (firewall en amont).

"ce serveur sert à gérer deux ranges d'IP publiques /24"
-Un serveur dns ne gère pas de range d'IP. Il gère des nom de domaines. D'où ma première question.

"« gagné » plus de 200 adresses IP publiques."
-Il n'y a aucun problèmes à avoir plusieurs entrées dns pour une machine.

Je valide ne pas à jour et pas de secondaire. Tout dépend de la nécessité des service dans sa zone.

"Pas de salle machine ? En même temps un backup régulier pour un dns ... Tu mets la conf dans la doc du réseau."
Si, une salle machine, mais ça ne fait qu'un an qu'on a un UPS. Quand j'ai découvert le serveur DNS, c'était un vieux serveur sans RAID, sans jamais avoir fait de backup. Il suffisait que le disque dur claque et on n'avait plus rien.

"Enfin, je ne vois pas de problème pour cela. Ce n'est pas rare qu'un admin possède un ordinateur portable et qu'il ne rentre pas d'ip à la main à chaque changement de réseau sur les site différents. "
- Y a un mot qui manque dans ma phrase en effet, c'étaient des ip publiques dynamiques de chez eux (fourni par leur FAI), donc rapidement obsolètes.

"Un serveur dns ne gère pas de range d'IP. Il gère des nom de domaines. D'où ma première question."
- Oui, c'est plus exact.

"Il n'y a aucun problèmes à avoir plusieurs entrées dns pour une machine."
- Pour te faire un résumé, à l'époque, chaque desktop avait une adresse ip fixe publique. Au fil des années, ces desktops disparaissaient au profit de laptop en dhcp (ip publique aussi).

Moi j'ai été largué a partir du premier tiret.

(Genre : oui, j'ai tout compris, et les autres c'est des n00bs)

Moi c'est le coup du CentOS qui m'a bien fait marrer. Genre je le mets en place pour faire mon Rulez mais pas foutu de le régler et de l'administrer convenablement (bon, sur ça, je fais confiance à Not_Found qu'il ne dise pas plein de conneries).

"Ces desktops disparaissaient au profit de laptop en dhcp". Donc, les premiers laptops étaient accessibles via un nom de domaine ? Et donc si j'ai bien compris, il était possible de tomber au hasard sur une des nouvelles machines via un ancien nom de domaine (à moins que les IP fixes aient été attribuées directement via le serveur DHCP - auquel cas nettoyer le serveur DNS n'a pas débloqué ces IP vu quelles sont toujours réservées au niveau du serveur DHCP) ?
Bref, c'est pas bien clair tout ça... Difficile de tout comprendre sans connaître le contexte.

Du coup en cas de coupure, il y a un an c'était le drame chez vous.

Je n'ai pas pris le bon mot je pensais à ip externe que publique. Car en effet tu mettre tes équipement en ip publique tant que tu as un bon firewall ;)

Mais bon ta précision laisse à penser qu'on peut taper dedans de l'extérieur.

Merci pour tes précisions, ca rend le pebkac plus savoureux ;)

@Link: Captain Obvious est malade, il est coincé aux toilettes, il m'a demandé d'assurer l'intérim sur ce coup là.

– Pas de serveur DNS secondaire.
En clair, ton DNS tombe (la femme de ménage coupe le courant, ta Carte-mère se suicide, [...]), tu est... Dans la merde en fait, puisque tu n'a plus aucun serveur qui puisse faire correspondre un nom de domaine à une IP (ce qui est gênant quand ton DNS pointe sur ton site Web par exemple, puisque ton site sera en ligne mais inaccessible sauf si tu l'attaque avec l'IP).

– Pas d'UPS ou de backup.
UPS: Uninterruptible Power Supply: Pour faire simple, "pas d'onduleur". Si tu as une panne électrique, byebye le serveur.
Pas de Backup: Si il crash méchamment et que tu ne peux pas récupérer les donnés de config, tu repars de Zéro pour monter un nouveau DNS.

– Tournant sur un vieux CentOS plus mis à jour depuis belle lurette.
Pas mis à jour: Pété jusqu'à la gorge de failles de sécurité potentielles.

– Il a servi à gérer plus d'une dizaine de noms de domaine, pour finalement n'en gérer plus qu'un seul. Les anciennes zones étaient toujours là.
Tu as encore des millions d'entrés qui ne sont plus valide histoire de simplifier l'administration et la possibilité que ton DNS te donner une réponse qui n'est plus valide.

– Des tas de règles iptables autorisant des connexions SSH depuis des adresses IP dynamiques.
Là c'est plus subtile. En clair, le Firewall est un gruyère vers le DNS parce que l'administrateur précédant était en IP dynamique. Donc dès qu'il changeait d'IP, il ajoutait sa nouvelle IP vers le serveur pour l'administrer. A se tarif la autant ouvrir ton réseau en /8~/16~/24 vers lui, c'est tout aussi con.... Ça veut surtout dire que, le balayeur de ta boîte (sans vouloir manquer de respect à cette profession) qui à un PC pour les moment ou il à fini son travail, histoire de zyeuter Face de Bouc, si il récupère la bonne IP par le plus grand des hasards, télécharge Putty, connait l'adresse IP du DNS (ce qui n'est pas très dur à trouver avec un ipconfig) ET le mot de passe de Root (ce qu'il n'a pas, je l'espère), peut très bien se connecter sur ton serveur et te le pourrir.

– Connexion SSH en root sur le port 22.
Pas d'autre compte d'administration que Root histoire de pouvoir "déléguer" l'administration à d'autre sans risque qu'ils fassent d'autres conneries.... SSH sur le port 22, ça choque moins (puisque c'est le port par défaut), mais ça peut être changé pour plus de sécurité, il te suffit de dire à ton serveur sur quel port répondre (et adapter ta règle de FIrewall en fonction sinon ça ne fonctionnera pas).

– Et le meilleur : ce serveur sert à gérer deux ranges d'IP publiques /24, et durant des années, la zone était continuellement alimentée sans que personne ne supprime les données obsolètes.
En clair: admettons que ton site demande l'adresse 82.54.73.22 et que ton partenaire à, par le plus grand des hasard, un site en 82.54.73.56, et bien tu ne pourra pas aller chez lui puisque ton DNS répondra pour cette IP alors qu'il ne la gère pas.

Au final, ça mérite son propre PEBKAC pour chacun des points. Donc je le dis:
-BEDP
-BEDP
-BEDP
-BEDP
-BEDP
-BEDP
-BEDP

Et j'ajouterai même pour l'admin précédant: Putain d'incompétent de merde!

Il n'y a pas de quoi! Sur ce, je m'envole vers d'autres cieux!
Saute dans son Arwing

Si j'en crois ton PEBKAC #9516, les accès VPN sont possible (désormais?).

J'espère que tu as donc "banni" toutes les IP publiques présentes dans ton Firewall et que désormais, l'administration de tes serveurs se fait via le VPN.

@Link: Je ne peux plus éditer mon commentaire précédant donc, à la lumière de cette information j'apporte une précision: C'est encore pire que le balayeur! N'importe qui pouvait potentiellement accéder au DNS depuis chez lui!.

Pour ce qui est de ma vision globale du PEBKAC, je dirais que, "en tant qu'Architecte Réseau de formation", le DNS c'est LE foutue point faible d'un réseau! Si il y a un seul truc à sur-blindé, c'est le DNS! C'est pareil pour tous les réseaux! Internet compris! Quand vous venez ici, vous vous connectez sur http://www.pebkac.fr. Et si vous n'utilisiez pas de DNS? Comment viendriez vous ici?

J'aimerai assez me spécialiser dans les solutions de protection DNS... Malheureusement ça ne fais pas partie des ambitions de mon employeur actuel....

@Not_found: Je vais te donner quelques indications utiles pour mettre tes propos en relief:
*: pour mettre en italique (tu encercle ta phrase ou ton mot avec)
test
**: pour mettre en gras (pareil, tu encercle)
test
**: pour mettre enitalique* et en gras (toujours encerclé)
test
` (Alt Gr+7): pour indiquer une balise code. Personnellement, je m'en sers aussi pour les Quote (et je ne suis pas le seul).

Petite info: généralement le caractère n'apparait pas à la première frappe, il dois être suivis que quelque chose. C'est là même chose que pour "¨"ou "^".

Ce sont les balises Markdown les plus utiles. =)

Un serveur DNS gère effectivement des zones DNS mais également les zones dites inverses, qui permettent justement de faire la resolution entre une adresse IP et un nom.

Exemple de zone : 0.73.54.88.in-addr.arpa

Ce type de résolution peut être nécessaire pour certains protocoles (coucou SSH).


http://fr.wikipedia.org/wiki/Domain_Name_System#R.C3.A9solution_invers[...]

Merci !

Et alors ?

C'est la différence entre quelqu'un qui ne sait pas ce qu'il fait et quelqu'un qui sait.
Après, y'a l'expérience qui fait un peu aussi, mais là apparemment, il n'avait ni l'un ni l'autre l'ancien admin.

Le dns n'est qu'un service du réseau. Sans lui le réseau fonctionne encore.
Heureusement, je ne tape pas à chaque fois dans le dns de l'hébergeur. L'information est répliqués à plein d'endroit. C'est pour cela qu'une maj dns prend des jours.

Je pense que le dns poisonning est un problème plus important que l'arrêt un dns. car tout est répliqué et qu'il est assez facile à remettre en place, par contre faire nettoyer des dns qui ne nous appartiennent pas c'est plus dur. Mais personne utilise dnssec.

Après ca dépend de son utilité. Si ces noms doivent être accessible de l'extérieur c'est un peut normal que le service soit accessible de l'extérieur.

Je suis parfaitement d'accord avec toi. Cependant tu semble avoir pris mon "le DNS est le point faible du réseau" que dans le cas d'une menace directe (arrêt du service). Ma notion de "faiblesse" inclus également toutes les autres formes d'attaque de DNS, y compris comme tu le dis toi même, le poisonning.

Malheureusement, le DNS est ce qui fait l'interface entre l'Homme, pour qui retenir un nom est facile, et le monde informatique qui ne connais que le langage numérique ( pour faire simple, même si techniquement il s'agit de "binaire"). Leur protection est trop souvent négligée... :'(

oui, effectivement, le petit truc où l'homme est perdu sans lui. La longueur d'une ipv6 n'aidant pas à s'en passer :/

Bon je vois que deux (ou plus) n'ont jamais réellement essayé ;)
Le reverse donne tout les noms de domaines pour une IP. Ca marche tout seul.
SSH fait du reverse, mais ca n'a rien d'obligatoire. T'as pas besoin de dns pour utiliser ssh et encore heureux.

Donc si quelqu'un aurait l'amabilité de m'indiquer le problème...

Je suppose que vous parlez de celui qui a fait cette odieuse configuration?

@but2ene
Les zones inverses ne fonctionnent pas toutes seules comme par enchantement, de la même manière que les zones classiques ont besoin d'administrateurs DNS compétents. Ce n'est pas parce que tu n'en as pas besoin dans ton cas que c'est nécessairement vrai tout le temps.
Les serveurs DNS internes des grands comptes gèrent souvent plusieurs plages d'adresses IP (via les réseaux définis par la RFC 1918).
Bref, affirmer que ceux-ci ne peuvent pas gérer les reverses est faux.

Quant à SSH, ce n'est pas certes pas obligatoire mais c'est un comportement par défaut de sshd. De plus, en l'absence de cette résolution inverse, les délais pour obtenir la connexion peuvent augementer de plusieurs dizaines de secondes.

En fait, le pool dhcp est sur le 2ème range, donc peu utilisé. A ce niveau-là aucun problème.
Par contre, j'ai eu la joie de découvrir que lorsqu'une adresse ip était donnée à un utilisateur (pour l'imprimante de son bureau ou pour du matériel électronique se connectant au réseau), l'adresse n'était pas ajoutée au DNS. Du coup, lorsque je demandais à mon collègue une adresse ip de libre, lorsque je croyais qu'il ne consultait que la zone dns, en réalité, il faisait un nslookup et un ping d'ip au hasard. Autant dire que les conflits d'adresses ip était courants -__-

@Fox : Merci pour l'info !
Tout est sécurisé comme il faut désormais. Prochaine étape : nettoyer le serveur LDAP :(

Pas de quoi, plaisir. =)

Au début le Markdown on y fait pas vraiment gaffe, alors je donne l'indication pour que tu puisse l'utiliser au plus vite.

@Surcouf : dsl la plus part des dns le gèrent correctement cette fonctionnalité. T'as juste à t'enregistrer chez les autres. Enfin comme pour la résolution normale.

La RFC 1918 décrit les adresses privés ipv4. N'oublie pas celle définies par la rfc4193.
Tu peux même utiliser un hook bien documenté pour que ton dhcp remplisse tes serveur dns.
Ce n'est pas réservé aux grand compte ta box le fait chez toi.

"Bref, affirmer que ceux-ci ne peuvent pas gérer les reverses est faux."
Bref, je n'ai jamais dit cela. Si tu lis attentivement, j'ai dit qu'il ne gérais pas les IP mais des nom de domaines. La reverse est aussi un nom de domaine accessoirement. CQFD.
Un dns n'a aucun pouvoir sur les IP c'est juste un annuaire. Et non ce n'est pas le 118 218 qui t'attribue ton numéro de tel.

Je pense qu'il y a un architecte réseau qui mérite des baffes par chez toi....

ROB! Charge les torpilles à baffe, il nous faut du lourd là...

– Connexion SSH en root sur le port 22.
 Pas d'autre compte d'administration que Root histoire de pouvoir "déléguer" l'administration à d'autre sans risque qu'ils fassent d'autres conneries....

Pour moi, c'est surtout qu'il y a des bots russes ou chinois qui attaquent aléatoirement toute sorte de serveurs en tentant de brute-force le compte root sur le port 22. Du coup une bonne pratique est de ne pas autoriser la connexion ssh en tant que root : tu te connectes avec un compte client, puis tu passes en root avec su.