Un ping pour le moins étrange

Support Debian
#1

Bonjour,

Version Debian 7.11 (wheezy)
Utilisation : Serveur

Problème : Utilisation de ping6 sur le serveur ne fonctionne pas.
Message d’erreur : # tom@server : ping6 google.com PING google.com(par03s15-in-x0e.1e100.net) 56 data bytes ping: sendmsg: Operation not permitted

Configuration parefeu par défaut: Policies INPUT OUTPUT FORWARD DROP IPv4 et IPv6
icmp autorisée en entrée et en sortie, pareil pour icmpv6, selon tuto sur ce site.

Test ping6 depuis un ordinateur distant vers le serveur : OK
Test de connexion en ssh -6 : 0K
Test serveur web en ipv6 depuis le web : OK

Bug : Pas d’accès au serveur par le web / ssh / ping / web / messagerie en ipv6

j’ai du relancer une première fois le parefeu en positionnant OUTPUT sur ACCEPT dans les policies ipv6 par défaut, puis remettre OUTPUT sur DROP et relancer le parefeu.

Test ping6 google.com depuis le serveur avec OUTPUT ACCEPT : ok
OUTPUT DROP : tout les services semblent fonctionner en dehors du ping6, traceroute6, donc depuis mon serveur vers une autre machine… et le message d’erreur retourné : opération not permitted

La il y a quelque chose que je ne comprends pas… est-ce un bug ou est-ce normal ?

Comment puis-je corriger ce problème ???

#2

Je lis une contradiction entre

et

Si tu fournis le jeu de règles actif qui pose problème affiché par ip6tables-save, on pourra regarder.

#3

ok, je donne ça…

Oui, en fait j’avais un soucis : rien n’était accessible depuis l’extérieur, pourtant le parefeu était lancé.
Juste que après avoir fait dans les policies IPv6 par défaut un OUTPUT ACCEPT / relancer le parefeu / et un OUTPUT DROP relancer le parefeu, les services depuis le web étaient disponibles…

ça aussi je trouve étrange…

Je te poste selon ta demande le iptables-save

# Generated by ip6tables-save v1.4.14 on Fri Jul 15 14:43:44 2016
*raw
:PREROUTING ACCEPT [76758:170395718]
:OUTPUT ACCEPT [64906:6159451]
COMMIT
# Completed on Fri Jul 15 14:43:44 2016
# Generated by ip6tables-save v1.4.14 on Fri Jul 15 14:43:44 2016
*mangle
:PREROUTING ACCEPT [793:160607]
:INPUT ACCEPT [793:160607]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [754:604462]
:POSTROUTING ACCEPT [730:602110]
COMMIT
# Completed on Fri Jul 15 14:43:44 2016
# Generated by ip6tables-save v1.4.14 on Fri Jul 15 14:43:44 2016
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [24:2352]
-A INPUT -d mon_ipv6/128 -p tcp -m tcp --dport 80 -m string --string "GET /w00tw00t.at.ISC.SANS." --algo bm --to 70 -j DROP
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 128 -m conntrack --ctstate NEW -m limit --limit 1/sec --limit-burst 1 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport xxxx -j ACCEPT #port de connexion SSH que j'ai masqué
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 873 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20:21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 49152:65534 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8723 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4949 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3306 -j ACCEPT
-A INPUT -p udp -m udp --dport 123 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,ACK FIN -j LOG --log-prefix "FIN: "
-A INPUT -p tcp -m tcp --tcp-flags FIN,ACK FIN -j DROP
-A INPUT -p tcp -m tcp --tcp-flags PSH,ACK PSH -j LOG --log-prefix "PSH: "
-A INPUT -p tcp -m tcp --tcp-flags PSH,ACK PSH -j DROP
-A INPUT -p tcp -m tcp --tcp-flags ACK,URG URG -j LOG --log-prefix "URG: "
-A INPUT -p tcp -m tcp --tcp-flags ACK,URG URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j LOG --log-prefix "XMAS scan: "
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j LOG --log-prefix "NULL scan: "
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j LOG --log-prefix "pscan: "
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j LOG --log-prefix "pscan 2: "
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,RST FIN,RST -j LOG --log-prefix "pscan 2: "
-A INPUT -p tcp -m tcp --tcp-flags FIN,RST FIN,RST -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN -j LOG --log-prefix "SYNFIN-SCAN: "
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j LOG --log-prefix "NMAP-XMAS-SCAN: "
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN -j LOG --log-prefix "FIN-SCAN: "
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,PSH,URG -j LOG --log-prefix "NMAP-ID: "
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,PSH,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j LOG --log-prefix "SYN-RST: "
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p ipv6-icmp -m icmp6 --icmpv6-type 135 -j ACCEPT
-A OUTPUT -p ipv6-icmp -m icmp6 --icmpv6-type 136 -j ACCEPT
-A OUTPUT -p ipv6-icmp -m icmp6 --icmpv6-type 133 -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 873 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 20:21 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 4949 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 3306 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 993 -j ACCEPT
COMMIT
# Completed on Fri Jul 15 14:43:44 201

Voilà… j’ai d’autres questions mais chaque chose en son temps, car j’aimerais bien connaitre la raison de mon problème…

Merci Pascal

#4

Je ne vois pas la contradiction : un pare-feu ça sert à bloquer. Sans pare-feu, rien n’est bloqué.

On est bien d’accord, la sortie que tu donnes est obtenue quand ça bloque ? Tu peux comparer avec la sortie quand ça passe pour voir s’il y a des différences.

#5

Premières observations rapides.

  1. En INPUT, la règle de suivi de connexion censée accepter les paquets ICMPv6 a le protocole “icmp” au lieu de “icmp-ipv6” ou “icmpv6”.

Edit : peu importe en fait, il y a plus haut une règle de suivi générale sans mention du protocole qui a déjà accepté les paquets concernés.

  1. En OUTPUT, le type 128 (echo-request) n’est pas accepté.
#6

ahh cool, merci !

J’avais pas vu ! va falloir que je change mes lorgnons moi… Fallait juste ajouter la même ligne en OUTPUT… Maintenant ça marche

Donc j’ai fait ce que tu m’as demandé, le comparatif, rien de changé en dehors des infos entre crochet dans les tables filter et mangle.

Sinon, j’ai localisé et compris ce que tu m’as dit à propos de la règle de suivi de connexion, qui finalement ne sert à rien donc je l’ai supprimée.

J’ai deux questions qui me viennent à l’esprit :

Est-ce utile d’autoriser le ping en sortie ? est-ce que les softs l’utilisent ?

Et pour le port de la base de données, est-ce utile de l’avoir en entrée / sortie vu que la base de données est utilisée en interne ?

#7

Certains programmes particulier l’utilisent pour vérifier si une machine est en ligne avant de communiquer avec elle. Par exemple nmap utilise le ping ICMP pour vérifier si un hôte répond avant de le scanner.

Inutile si c’est déjà autorisé sur l’interface de loopack (lo).

Autres remarques sur le jeu de règles.

Placées comme elles le sont, les règles de LOG&DROP des paquets TCP ayant des combinaisons de drapeaux invalides ne sont pas très utiles.

L’unique règle dans FORWARD ne sert à rien.

Autoriser le port 20 en destination pour FTP est inutile.

Autoriser une plage de ports énorme en entrée, pour le FTP je suppose, n’est pas très sûr. Si c’est pour du FTP avec la connexion de commande en clair, il vaut mieux utiliser le module de suivi de connexion FTP nf_conntrack_ftp.

#8

D’accord, merci beaucoup,

je modifie le parefeu en fonctions des informations que tu m’as donné.

Edit : Les règles LOG et DROP, j’ai choppé ça sur un tuto sur le net pour éviter les scans de ports sur ma machine, ceci afin de faire taire nmap. Je me suis rendu compte que ça ne marchait pas vraiment en utilisant nmap sur internet, j’obtiens la liste de tous les ports ouverts…

Du coup, j’ai trouvé un soft bien sympa qui s’appelle portsentry, je ne sais pas si l’idée est bonne, mais j’essaye avec le peu de connaissances que j’ai en sécurité informatique de fermer un maximum de portes… donc je vais retirer ces règles de mon parefeu…

Faut que je me renseigne sur l’utilisation des modules ftp sur le parefeu et comment on les met en place, puis je vais faire comme tu as dit.

Merci Pascal pour tes conseils, si tu as d’autres commentaires n’hésites surtout pas !

Salutations

#9

Forcément, elles sont placées après toutes les règles ACCEPT pour les ports autorisés. Elles ne sont donc efficaces que pour les autres ports. Et elles ne seraient de toute façon pas efficaces contre un scan de ports “classique” (SYN scan) qui envoie des paquets valides.

#10

Ah oui ! c’est vrai que le shell lit les règles les unes derrières les autres… J’aurais dû y penser, mais bon j’en suis au niveau débutant. Ceci dit tes conseils sont précieux et je te remercie vraiment beaucoup.

Alors j’ai installé le module de suivi de connexion que tu m’as dit, mais lorsque je relance le parefeu, ça me met cette erreur :

libkmod: ERROR ../libkmod/libkmod.c:554 kmod_search_moddep: could not open moddep file '/lib/modules/3.14.32-xxxx-grs-ipv6-64/modules.dep.bin'
libkmod: ERROR ../libkmod/libkmod.c:554 kmod_search_moddep: could not open moddep file '/lib/modules/3.14.32-xxxx-grs-ipv6-64/modules.dep.bin'

je suis en train de chercher pourquoi sur le net…

#11

Qu’est-ce que c’est que ce noyau 3.14.32-xxxx-grs-ipv6-64 qui n’est pas le noyau standard de Wheezy ?
Comment as-tu “installé” le module ?

#12

pour ta première question, je n’en sais rien du tout…
J’ai pris un serveur chez Kimsufi c’est pas un HD, mais un SSD 80 Gb…

Pour la deuxième j’ai placé avant le flush des tables : modprobe nf_conntrack_ftp

#13

Vu, c’est un noyau fourni par OVH.
D’après son fichier .config disponible à ftp://ftp.ovh.net/made-in-ovh/bzImage/latest-production/config-3.14.32-xxxx-grs-ipv6-64 c’est un noyau totalement monolithique sans module chargeable, et la fonctionnalité du module nf_conntrack_ftp est compilée en dur (CONFIG_NF_CONNTRACK_FTP=y).
La fonctionnalité est déjà présente et la commande n’est donc pas nécessaire.

#14

bin heureusement que tu es là…

Je ne crois pas que j’aurais trouvé…
Ce que tu dis là, ç donne l’impression que l’on se fait “arnaquer” du fait que l’on loue une machine que l’on ne peut pas configurer en totalité… D’un côté ça aide les débutants à ne pas trop ramer, quoi que… Mais de l’autre côté, ça n’aide pas vraiment dans l’apprentissage si l’on automatise les fonctions… Personnellement, j’ai la sensation de ne pas être totalement maître de ma machine…

Enfin bon… déjà de mon côté, en ayant potassé un peu netfilter, je rame quand même lol…

#15

Apparemment c’est un noyau “durci” incluant le patch grsecurity, et le fait de ne pas utiliser de modules chargeables participe au durcissement, sans compter que cela simplifie l’installation avec un seul fichier image à installer dans /boot, sans l’arborescence classique des modules installés dans /lib/modules. Le revers, c’est que toutes les fonctions compilées en dur sont actives même si on n’en a pas besoin.

Mais a priori rien ne t’empêche d’utiliser un autre noyau comme le noyau standard fourni par Debian ou ton propre noyau compilé par tes soins, du moment qu’il est compatible avec la plate-forme.

#16

je ne sais pas si c’est possible de faire une install sans leur templates…
en tout cas par curiosité j’ai été jeter un œil pour valider tes informations, et en dehors de l’installation personnalisée pour les partitions, il n’y a pas d’installation personnalisée possible d’un quelconque noyau…, Leur netboot, c’est leur noyau à eux… donc voilà pour le retour…

#17

Le serveur doit obligatoirement démarrer en netboot ?
Sinon, tu peux installer n’importe quel noyau à n’importe quel moment après l’installation de base effectuée avec un template.

#18

Non, chez Kimsufi il y a 3 possibilité de démarrage : HD, netboot, ou rescue mode.

Sinon, je te remercie pour l’information, je suis en train de me créer ma propre PME et pour le moment , afin de limiter les coûts, je fais tout tout seul donc j’essaye de m’informer et de mettre un maximum de chances de mon côté pour éviter les attaques les plus connues on dira.

Et puis dans un sens si mes problèmes peuvent aider à solutionner les mêmes chez les autres, c’est pas plus mal :slight_smile:

j’ouvre un nouveau sujet sur le scan de ports… ça promet LoL.

#19

Donc tu peux installer le noyau standard de Debian (linux-image-amd64), un chargeur d’amorçage s’il n’y en a pas déjà un (grub-pc si amorçage en mode BIOS) et basculer en démarrage HD. Si ça ne marche pas, tu peux toujours repasser en netboot.

#20

hum… ça me parait compliqué…
sur l’interface de kimsufi, il y a 3 boutons : réinstaller (qui ne propose que les templates), redémarrer et netboot. Mon netboot est déjà en HD. Et donc si ça ne marche pas, je peux réinstaller via le bouton réinstaller, ça pas de problème…
Le truc est que je ne me trouve pas directement à l’emplacement de mon serveur, pour me connecter à lui j’utilise le ssh, avec un jeu de clés. Après il faudrait que je me documente sur la façon de faire une réinstall de debian à distance, en ayant inséré au préalable mes clés ssh et je ne suis pas assez spécialisé dans ce domaine pour savoir si c’est ou non, réalisable…

Ceci dit le sujet est suffisamment intéressant pour que je me penche sur cette question.
Mais pour le moment, j’ai du pain sur la planche…