Iptables : pourquoi bloquer les ports qui sont déjà fermés ?

Support Debian
#1

Bonjour,

je sais que un port est fermé par défaut lorsqu’il n’y a aucun logiciel de service (comme apache, postfix, …)
qui ouvre ce port. Il suffit de taper la commande nmap localhost pour confirmer :

root@localhost:/home/guest# nmap localhost

Starting Nmap 5.00 ( http://nmap.org ) at 2012-10-12 13:11 CEST
Warning: Hostname localhost resolves to 2 IPs. Using 127.0.0.1.
Interesting ports on localhost (127.0.0.1):
Not shown: 988 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
110/tcp  open  pop3
111/tcp  open  rpcbind
143/tcp  open  imap
443/tcp  open  https
631/tcp  open  ipp
783/tcp  open  spamassassin
3306/tcp open  mysql

Nmap done: 1 IP address (1 host up) scanned in 0.25 seconds
root@localhost:/home/guest#

=> comme vous le voyez, il y a marqué Not shown: 988 closed ports => donc tous les numéros de port qui ne sont pas listés sont ceux qui ne fournissent aucun service, et donc qui sont fermés par défaut.

Donc ma question est la suivante : si ces ports non listés sont fermés par défaut, alors pourquoi plusieurs tutos sur iptables recommandent quand même de bloquer ces ports (en appliquant dès le départ une politique par défaut DROP pour INPUT, OUTPUT, et FORWARD) ? Est-ce vraiment utile :doh: ? Et quels sont les risques (ou plutôt quels genres d’attaques risqueront nous) si on ne bloque pas ces ports qui sont déjà fermés par défaut ?

Merci d’avance pour vos réponses.

#2

Voir la différence entre REJECT (le comportement par défaut d’un port fermé) et DROP.

Deux raisons principalement :

  • un REJECT permet de savoir avec certitude qu’un port est fermé, tandis qu’un DROP ne conduit qu’à un timeout ; quand un attaquant attend une réponse qui ne vient pas forcément il y passe plus de temps avant de se rendre compte du timeout
  • moins de bande passante utilisée étant donné l’absence de réponse
#3

Bonjour, merci pour ta réponse.

=>effectivement, j’ai fait le test, le DROP fait retarder les prises de décision du pirate.
Mais même si ça retarde le pirate, ce n’est pas vraiment un bon argument pour recommander un DROP, parce
qu’on peut se contenter du comportement par défaut d’un port (REJECT) tant que ce port est fermé (c’est l’essentiel).

[quote=“syam”]- moins de bande passante utilisée étant donné l’absence de réponse[/quote].
=>Oui mais la bande passante que consomme une réponse est vraiment microscopique, donc ce n’est pas vraiment un bon argument pour recommander un DROP.

Y a t’il vraiment des attaques qui réussissent à créer un deni de service ou autres perturbations en agissant sur les ports fermés ? Si oui, des exemples ?

A+

#4

Je dirais aussi pour la sécurité.
Un utilisateur ayant un minimum e droit peut ouvrir un port avec un service par forcement en accord avec la politique de sécurité. Dans la même veine, si quelqu’un arrive a pénétrer sur ton système et y installer une backdoor avec cette politique restrictive cela empêcheras le vilian soft de fonctionner correctement. :stuck_out_tongue:
Exemple : bloquer un relai à SPAM.

#5

=>Oui, mais si dans ma machine je n’ai donné aucun droit d’administration (sudoers) à mes utilisateurs non-root.
Il n’y a pas de risque que ces utilisateurs ouvrent des ports fermés.

[quote=“Mimoza”]
Dans la même veine, si quelqu’un arrive a pénétrer sur ton système et y installer une backdoor avec cette politique restrictive cela empêcheras le vilian soft de fonctionner correctement. :stuck_out_tongue:
Exemple : bloquer un relai à SPAM.[/quote]
=>c’est vrai qu’on est pas à l’abri d’un exploit d’un pirate qui arrive à rentrer dans ma machine, et qui se procure les droits d’administration pour par exemple vers minuit (quand je dors) éditer le fichier de configuration d’un logiciel de service (apache, vsftpd, etc…) dans lequel il va mettre une ligne (du style listen 1029) pour ouvrir et exploiter le port 1029.

Je suis tombé sur ces liens qui parlant des failles de sécurité récentes :
vupen.com/english/searchengi … word=linux
et un autre lien pour tester la sécurité de votre machine :
pcflank.com

enjoy !

#6

=>Oui, mais si dans ma machine je n’ai donné aucun droit d’administration (sudoers) à mes utilisateurs non-root.
Il n’y a pas de risque que ces utilisateurs ouvrent des ports fermés. [/quote]
Si, il y a bel et bien un risque réel !
Seuls les ports inférieurs à 1024 sont réservés à root. N’importe quel utilisateur même sans droits peut ouvrir en écoute un port supérieur à 1024 comme il veut, sans aucune restriction.

C’est avant tout pour ça que la stratégie INPUT ACCEPT est une mauvaise idée. Partant de là il ne reste que deux choix viables comme stratégie par défaut pour INPUT :

  • soit REJECT : tout ce qui n’est pas explicitement autorisé dans iptables se comportera comme si c’était un port fermé, en renvoyant un ICMP Port Unreachable (UDP) ou un RST (TCP)
  • soit DROP : tout ce qui n’est pas explicitement autorisé dans iptables est purement ignoré
    Vu que le choix est uniquement entre REJECT et DROP, autant utiliser celui qui emmerde le plus celui d’en face (DROP). :wink:
#7

=>Je ne demande que des exemples :033

#8

$ nc -l -p 555 nc: Permission denied $ nc -l -p 5555 _
Dans un autre shell pendant que nc est toujours lancé :

$ netstat -tapn | grep 5555 tcp 0 0 0.0.0.0:5555 0.0.0.0:* LISTEN 17650/nc $ ps aux | grep 'nc -l' syam 17650 0.0 0.0 8828 368 pts/2 S+ 16:32 0:00 nc -l -p 5555 syam 17767 0.0 0.0 7832 852 pts/0 S+ 16:38 0:00 grep --color=auto nc -l
Le port 5555 est bel et bien ouvert en écoute par un utilisateur non privilégié.
CQFD. :mrgreen:

#9

Merci beaucoup syam :118 , ta commande est de la bombe atomique qui peut provoquer beaucoup de dégats si on va plus loin dans les commandes.

Moi, j’aime bien ces petits commandes de hackers :dance: , un régal.

Si tu as d’autres codes d’attaque (car j’en ai besoin pour checker la sécurité de mon serveur), n’hésite pas à nous fournir des liens :wink: !.

#10

Petite précision supplémentaire quant à la sécurité en général.

Pour un environnement sécurisé, il vaut toujours mieux tout interdire et n’autoriser les choses que au cas par cas.
Même si la plupart du temps ça ne sert à pas grand chose, c’est justement au moment où tu as une attaque que ça devient important d’avoir autant de barrières que possible. Et même comme ça ils arrivent encore à passer au travers !

Disons que tu n’oublies jamais de fermer ton portail à clé en partant de chez toi. Il se passe quoi si quelqu’un passe par dessus le grillage mais que tu as laissé ta porte déverrouillée parce que tu avais confiance dans ta sécurité de périmètre ?
Ou si tu es parti en vacances sans fermer les volets, et que le cambrioleur peut rentrer comme il veut en cassant simplement les fenêtres ?
Une machine sécurisée, c’est :

  • portail fermé à clé
  • tessons de bouteille et barbelés en haut du mur d’enceinte
  • des pièges à loup partout dans le jardin, voire des fosses à pieux et quelques mines antipersonnel
  • volets fermés, fenêtres grillagées et avec des barreaux
  • portes extérieures et intérieures toutes blindées et verrouillées indépendamment
  • un système d’alarme bien bruyant pour faire fuir le gars, couplé à une téléalarme qui rameute les flics
  • un fusil chargé braqué sur toutes les ouvertures, la gâchette reliée à la poignée d’ouverture
  • d’autres pièges à loup à l’intérieur pour faire bonne mesure
  • le bijou en toc de tante Gisèle (le seul truc vaguement de valeur de la maison) soigneusement rangé dans le coffre-fort enterré par 3 mètres de fond dans la cave
  • éventuellement un panneau “Attention chien méchant” sur le portail pour décourager les indésirables (mais en même temps, s’ils rentrent quand même c’est à leurs risques et périls :violence-guntoting: )
    (j’ai comme la vague impression que je suis parti en vrille là :005)

Tout ça pour dire, la sécurité de périmètre n’est jamais suffisante en elle-même car une fois qu’elle est franchie il te reste quoi. C’est pour ça que chaque service est lancé avec son propre utilisateur, voire chrooté : si jamais un service donné a une faille ça empêche une propagation trop facile aux autres services (heureusement sur Debian la plupart des choses sont déjà pré-configurées en prenant tout ça en compte).

iptables n’est qu’une partie de cette sécurité de périmètre, et si tu ne penses même pas à fermer ton portail à clé en partant je préfère pas imaginer ce qu’il en est du reste. :wink:

#11

=> :laughing: , merci encore :wink:

#12

J’ai oublié de préciser que c’est quand même mieux d’entourer le bijou de tata Gisèle d’une bonne épaisseur de papier bulle avant de le mettre au coffre. On sait jamais avec les secousses dues aux mines antipersonnel, vaut mieux prévenir que guérir. :033

Allez zou, j’arrête mes conneries je vais faire autre chose, j’suis en surchauffe aujourd’hui y me faut du repos. :unamused:

#13

Malheureusement tu serais civilement responsable des actes de chien (tout du moins en France). Sinon ça serais trop facile, il suffirais de mettre un autocollant “Attention conducteur sous l’emprise de l’alcool” sur sa voiture pour ne pas se prendre de prunes :030

#14

Non je parlais juste d’un panneau pour faire peur, pas d’un vrai chien. Le pauvre il ferait pas long feu dans ces conditions.
Quant aux responsabilités civiles, franchement, une morsure de chien ça serait mon dernier souci avec des mines dans le jardin. :mrgreen: