Ping non-autorisé

bonjour,
par je ne sais quel raison, je n’ai plus accès à mon serveur via SSH.
J’ai déicdé de voir ce qui se passait en m’y mettant et en tentant d’accéder au web via un navigateur mais il ne se connecte pas au net.
j’ai tenté un Ping sur le domaine et l’ip mais là le message me dit que je ne suis pas autorisé (à pinguer je pense)

je n’ai pas le souvenir d’avoir touché quoique ce soit sur le serveur ou le routeur et à coté de ca, mes ordis fonctionnent parfaitement (connexion au web)…

quelqu’un pourrait m’aider svp ?

merci par avance

Règles de filtrage iptables ?

avec UFW :
Status: active

To Action From

                   ------      ----

631 ALLOW Anywhere

53 ALLOW Anywhere

993/tcp ALLOW Anywhere

995/tcp ALLOW Anywhere

22/tcp ALLOW Anywhere

137/udp ALLOW Anywhere

138/udp ALLOW Anywhere

139/tcp ALLOW Anywhere

445/tcp ALLOW Anywhere

25/tcp ALLOW Anywhere

443/tcp ALLOW Anywhere

182/tcp ALLOW Anywhere

51234/tcp ALLOW Anywhere

110/tcp ALLOW Anywhere

631 ALLOW Anywhere (v6)

53 ALLOW Anywhere (v6)

993/tcp ALLOW Anywhere (v6)

995/tcp ALLOW Anywhere (v6)

22/tcp ALLOW Anywhere (v6)

137/udp ALLOW Anywhere (v6)

138/udp ALLOW Anywhere (v6)

139/tcp ALLOW Anywhere (v6)

445/tcp ALLOW Anywhere (v6)

25/tcp ALLOW Anywhere (v6)

80/tcp ALLOW Anywhere (v6)

443/tcp ALLOW Anywhere (v6)

8080/tcp ALLOW Anywhere (v6)

182/tcp ALLOW Anywhere (v6)

51234/tcp ALLOW Anywhere (v6)

110/tcp ALLOW Anywhere (v6)

51234/tcp ALLOW OUT Anywhere

110/tcp ALLOW OUT Anywhere

8080/tcp ALLOW OUT Anywhere (v6)

51234/tcp ALLOW OUT Anywhere (v6)

110/tcp ALLOW OUT Anywhere (v6)

Un copié-collé complet (comme ci-dessous) de la commande et du retour de la commande (et en particulier du message d’erreur) aiderait sans doute à mieux comprendre l’origine du problème.

[quote]michel@deb9550:~$ ping -c4 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=1.00 ms
64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=0.925 ms
64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=0.923 ms
64 bytes from 192.168.0.1: icmp_req=4 ttl=64 time=0.895 ms

— 192.168.0.1 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.895/0.936/1.001/0.039 ms
michel@deb9550:~$
[/quote]

Et pas seulement pour le ping mais aussi pour les autres tentatives (SSH, web…)

kri2sis :
Ta liste ne vaut pas un bon iptables-save pour afficher les règles iptables en place, mais je ne vois pas d’autorisation pour le ping (ICMP echo) ni pour le HTTP (TCP 80) en IPv4, seulement en IPv6.

salut et merci

[code]root@smtp:~# ping -c4 192.168.0.1

PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.

ping: sendmsg: Operation not permitted

ping: sendmsg: Operation not permitted

ping: sendmsg: Operation not permitted

ping: sendmsg: Operation not permitted

— 192.168.0.1 ping statistics —
4 packets transmitted,
0 received, 100% packet loss, time 3024ms

[/code]
pour ce qui est du http en ipV4, il semble que UFW le choississe automatiquement…
mais ce qui parait bizarre c’est que je n’ai pas touché à ce fichier depuis un bon moment et je me rappelle avoir fait des Update et Upgrade régulierement depuis sa config…

Ce message est typique d’un blocage en sortie par iptables. Il y a peut-être des messages correspondants dans les logs du noyau. Tu peux être fixé en vérifiant le jeu de règles iptables complet produit par ufw avec iptables-save.

bon et bien tout semble rentré dans l’ordre…
je mets ici ce que j’ai fait :

les commandes :

rien ne semblait étrange. j’ai été voir le fichier /etc/network/interfaces
rien de bizarre non plus

et enfin cette commande qui je pense à résorbé le probleme :

mais est ce que je n’ai pas ouvert des failles ?
ou est passé UFW ?

voici le nouveau ertour iptables-save :

[code]root@smtp:~# iptables-save

Generated by iptables-save v1.4.14 on Sun Dec 15 17:06:25 2013

*mangle
:PREROUTING ACCEPT [13452]
:INPUT ACCEPT [13452]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [8695:1114371]
:POSTROUTING ACCEPT [8695:1114371]
COMMIT

Completed on Sun Dec 15 17:06:25 2013

Generated by iptables-save v1.4.14 on Sun Dec 15 17:06:25 2013

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [488:37359]
:POSTROUTING ACCEPT [488:37359]
COMMIT

Completed on Sun Dec 15 17:06:25 2013

Generated by iptables-save v1.4.14 on Sun Dec 15 17:06:25 2013

*filter
:INPUT DROP [31:3875]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [8695:1114371]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-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 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 995 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 666 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
COMMIT

Completed on Sun Dec 15 17:06:25 2013[/code]

bon et bien tout semble rentré dans l’ordre…
je mets ici ce que j’ai fait :

les commandes :

ls -al /bin/ping
netstat -nr

rien ne semblait étrange. j’ai été voir le fichier /etc/network/interfaces
rien de bizarre non plus

et enfin cette commande qui je pense à résorbé le probleme :

iptables - X

mais est ce que je n’ai pas ouvert des failles ?
ou est passé UFW ?

voici le nouveau ertour iptables-save :

[code]root@smtp:~# iptables-save

Generated by iptables-save v1.4.14 on Sun Dec 15 17:06:25 2013

*mangle
:PREROUTING ACCEPT [13452]
:INPUT ACCEPT [13452]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [8695:1114371]
:POSTROUTING ACCEPT [8695:1114371]
COMMIT

Completed on Sun Dec 15 17:06:25 2013

Generated by iptables-save v1.4.14 on Sun Dec 15 17:06:25 2013

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [488:37359]
:POSTROUTING ACCEPT [488:37359]
COMMIT

Completed on Sun Dec 15 17:06:25 2013

Generated by iptables-save v1.4.14 on Sun Dec 15 17:06:25 2013

*filter
:INPUT DROP [31:3875]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [8695:1114371]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-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 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 995 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 666 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
COMMIT

Completed on Sun Dec 15 17:06:25 2013[/code]

iptables -X ne fait que supprimer les chaînes utilisateur vides et non référencées donc qui ne servent à rien. Autrement dit, ça ne change rien aux règles en place. Ce jeu de règles semble bien trop simple (mais pas simpliste) pour avoir été généré par les firewalls “usines à gaz” habituels, on dirait plutôt un jeu de règles généré par un script maison comme celui qui figure dans la section T&A. Tout est autorisé en sortie et seuls les ports TCP mentionnés et le ping sont autorisés en entrée, à toi de voir si c’est ce que tu veux ou pas. Par contre je ne vois pas le port 22 pour SSH dans la liste, donc à moins que tu ais changé le port d’écoute le serveur n’est pas accessible par SSH.

en effet le port pour le ssh est modif et ça fonctionne…

un script, tu dis ?? euh je ne connais pas le langage pour programmer à ce noveau là donc je ne pense pas m’aventurer à y mettre un code…maison…

Toi seul sais ce que tu as fait avec ufw et iptables. En tout cas ce n’est pas juste iptables -X qui a transformé le jeu de règles complexe que tu as publié puis effacé avant que je puisse l’examiner en le jeu de règle actuel.

beh pourtant j’ai bien énuméré ce que j’ai fait

bon et bien ça recommence et je n’ai toujours rien touché de plus !!!

que se passe-t-il svp ?
comment je peux régler ce probleme ?

svp merci pour votre aide

ps : je récapitule : le serveur ne se connecte pas au web et ne peut par exemple par faire de MAJ et je n’arrive pas à le joindre via SSH à un port que je lui ai attribué…

[code]# Generated by iptables-save v1.4.14 on Tue Dec 17 18:19:47 2013
*mangle
:PREROUTING ACCEPT [1081:264539]
:INPUT ACCEPT [1041:262507]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1735:245674]
:POSTROUTING ACCEPT [759:53760]
COMMIT

Completed on Tue Dec 17 18:19:47 2013

Generated by iptables-save v1.4.14 on Tue Dec 17 18:19:47 2013

*nat
:PREROUTING ACCEPT [317:68088]
:INPUT ACCEPT [4:196]
:OUTPUT ACCEPT [530:38989]
:POSTROUTING ACCEPT [432:30981]
COMMIT

Completed on Tue Dec 17 18:19:47 2013

Generated by iptables-save v1.4.14 on Tue Dec 17 18:19:47 2013

*filter
:INPUT DROP [273:65860]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:fail2ban-dovecot - [0:0]
:fail2ban-postfix - [0:0]
:fail2ban-roundcube - [0:0]
:fail2ban-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 80,443,25,587,110,995,143,993,4190 -j fail2ban-postfix
-A INPUT -p tcp -m multiport --dports 80,443,25,587,110,995,143,993,4190 -j fail2ban-dovecot
-A INPUT -p tcp -m multiport --dports 80,443,25,587,110,995,143,993,4190 -j fail2ban-roundcube
-A INPUT -p tcp -m tcp --dport 666 -j fail2ban-ssh
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-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 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 995 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 666 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -d 212.211.132.250/32 -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -d 195.20.242.89/32 -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -d 212.211.132.32/32 -p tcp -m tcp --dport 80 -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 993 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 465 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 8080 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -j LOG
-A OUTPUT -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-dovecot -j RETURN
-A fail2ban-postfix -j RETURN
-A fail2ban-roundcube -j RETURN
-A fail2ban-ssh -j RETURN
COMMIT

Completed on Tue Dec 17 18:19:47 2013[/code]

Il serait bien de connaitre ton IP ou ton site web si tu as.
De plus le N° de ton port SSH qu’on puisse voir s’il est présent.
Tu le changeras ensuite, si tu veux.
Il faut aussi voir si tu n’as pas une fermeture quelconque dans fail2ban.

EDIT :
Si tu ne veux pas communiquer ton IP en public, envoie-la moi en MP ainsi qu’à Pascal.

EDIT 2 :
Le iptables-save du dessus est bien celui du serveur, pas du client ?

mon ip: 88.189.56.174

port ssh : 666

oui les iptables-save sont ceux du serveur

ps : je ne l’ai pas signalé, mais lorsque je suis rentré, mon serveur était éteint pour je ne puis dire quelle raison alors qu’il tourne 27/7 habituellement

[quote=“kri2sis”]…
ps : je ne l’ai pas signalé, mais lorsque je suis rentré, mon serveur était éteint pour je ne puis dire quelle raison alors qu’il tourne 27/7 habituellement[/quote]
Tu habites sur quelle planète :laughing:

Plus sérieusement, as-tu essayé en ouvrant totalement ton parefeu ?
Tu t’autohéberges donc !
On dirait que tu as un serveur de courrier avec postfix, fonctionne-t-il ?

Je pingue ton IP : [mono]ricardo@ordibureau:~$ ping 88.189.56.174
PING 88.189.56.174 (88.189.56.174) 56(84) bytes of data.
64 bytes from 88.189.56.174: icmp_seq=1 ttl=53 time=63.9 ms
64 bytes from 88.189.56.174: icmp_seq=2 ttl=53 time=62.4 ms
64 bytes from 88.189.56.174: icmp_seq=3 ttl=53 time=63.8 ms
64 bytes from 88.189.56.174: icmp_seq=4 ttl=53 time=64.3 ms[/mono]

Encore un jeu de règles iptables différent ! D’où vient-il, celui-là ?
Cette fois il manque une règle acceptant les paquets sortants émis en réponse à un paquet entrant, ce qui la rend inaccessible par SSH ou autre :

Par contre cela ne devrait pas bloquer les connexion sortantes sur les ports autorisés. Regarde quand même dans les logs du noyau si le problème persiste.
Il est aussi recommandé d’autoriser le trafic sur l’interface de loopback en entrée ET en sortie, ce qui a été oublié :

Apparemment, le serveur est derrière une box en mode routeur NAT avec des redirections de ports, donc c’est la box qui répond au ping de l’extérieur. En revanche pas de réponse après la redirection.

Oui, d’ailleurs je crois que Kri2sys est sous FreeBox et si c’est bien ça, il faut que tu vérifies la redirection de tes ports.
Le système a été modifié dernièrement :
[mono]mafreebox.freebox.fr[/mono] t’ouvre une sorte de page “freebox OS”.
/paramètres de la freebox/mode avancé/redirection de ports.
Là, tu vérifies les ports qui vont bien et leur destination (le serveur)

Je pense que la redirection est active car de l’extérieur la box répond différemment au traceroute TCP sur un port censé être redirigé et sur un port ne l’étant pas.