[fan.2]

Si mais c'est pour voir si c'est un filtrage au niveau du network OVH ou si en plus tu as un parefeu logiciel sur ton VPS.

C'est une installation neuve de debian 8 sur un "vps cloud ram 2" donc je n'ai encore aucune règle avec iptables.
Je voulais justement tester et comprendre le "firewall network" d'abord.

J'ai deux autres "vps ssd 2" sur le même datacenter (gravelines) et j'ai fait le test suivant : pour l'un "firewall network" est activé (mais sans la moindre règle !) et pour l'autre "firewall network" est désactivé.
La commande "tracert" que tu suggérais montre le passage par le VAC1 sur le VPS où le "firewall network" est activé et pas sur l'autre.
Mais j'ai toujours le doute (par rapport à ce que j'ai lu : https://www.ovh.com/fr/anti-ddos/ges...taque-ddos.xml) sur le fait que cela passe par le VAC parce qu'il a ou il y a eu récemment une attaque DDOS
ou si cela passe systématiquement par le VAC.

- - - Mise à jour - - -

d'ailleurs sur ton VPS, si tu fais
cd /tmp && wget google.fr çà marche bien ? tu obtiens quoi comme réponse ?

Cela donne cela :

IDENT@vpsXXXXXX:~$ cd /tmp && wget google.fr
--2016-08-02 15:30:23--  http://google.fr/
Resolving google.fr (google.fr)... 172.217.16.67, 2a00:1450:4007:806::2003
Connecting to google.fr (google.fr)|172.217.16.67|:80... failed: Connection timed out.
Connecting to google.fr (google.fr)|2a00:1450:4007:806::2003|:80... failed: Network is unreachable.

[buddy]

Si mais c'est pour voir si c'est un filtrage au niveau du network OVH ou si en plus tu as un parefeu logiciel sur ton VPS.

d'ailleurs par rapport au tutoriel d'OVH, je te conseille d'augmenter le bantime dans fail2ban. 300 (secondes par défaut) c'est beaucoup trop court, il vaut mieux mettre plusieurs jours.

- - - Mise à jour - - -

d'ailleurs sur ton VPS, si tu fais
cd /tmp && wget google.fr çà marche bien ? tu obtiens quoi comme réponse ?

[fan.2]

Sinon enlève la règle 19 (tout refuser)..

Sans cette dernière règle... tout n'est-il pas autorisé ??!??!

[buddy]

et si tu remets la règle pour le FTP ?

Il me semblait que APT-get marchait avec le port 80 ( http ).

Sinon enlève la règle 19 (tout refuser)..

[fan.2]

Sinon, concrètement, ton serveur reste bloqué sur quelle ligne ? peu-tu faire un copier coller de la ligne qui bloque ?

J'ai supprimé la règle relative au port 21 que j'avais ajoutée pour résoudre le problème pour reproduire ce qu'il s'est passé hier.
Et en fait, un simple "apt update" cherche à accéder à des adresses ftp :

$ sudo apt update

0% [Connecting to ftp.debian.org (130.89.148.12)] [Connecting to security.debian.org (212.211.132.250)]

... et cela reste bloqué sur 0%.


Je me dis que je vais peut-être remettre uniquement un règle pour le port 21 relativement à cette IP de ftp.debian.org mais il risque d'y en avoir d'autres et apparemment on ne peut avoir que 20 règles (0 à 19).

[buddy]

pour vérifier si ton serveur et sous VAC ou non, tu fais un traceroute
démarrer
exécuter
cmd
tracert 123.123.123.123 (en remplacant par l'ip du serveur).

Si tu es sur le VAC, vers la fin tu devrais voir des lignes de ce style

vacx-0-a9.fr.eu.vaccum
vacx-1-n7.fr.eu.firewall
vacx-2-n7.fr.eu.tilera
vacx-3-n7.fr.eu.arbor

Sinon, concrètement, ton serveur reste bloqué sur quelle ligne ? peu-tu faire un copier coller de la ligne qui bloque ?

[fan.2]

1) non, il me semble qu'elles s'appliquent tout le temps..

Quand on lit cela https://www.ovh.com/fr/anti-ddos/ges...taque-ddos.xml
et cela https://www.ovh.com/fr/anti-ddos/mitigation.xml
on voit que le firewall network est dans le vac et que l'on n'y passe que lors d'une attaque.

3) non je ne pense pas.

Je me demande s'il y a un moyen de savoir si on est ou pas dans une période où on passe par le VAC.

4) je pense qu'il faut 2 regles.

Il m'a semblé aussi.

apt-get utilise le port 80 normalement ... Donc c'est étonnant que çà ne marche pas...
Si tu fais apt-get update et apt-get upgrade -y çà marche correctement ?
quel est le paquet que tu veux installer ? (pour savoir si il est sur le dépot "standard" ou sur un dépôt différent.

Je cherchais à installer nmap depuis un vps sous debian 8 et il avait un paquet à récupérer sur un ftp.

[buddy]

Bonjour,

non, il me semble qu'elles s'appliquent tout le temps.
2) oui au flux entrants mais pour communiquer, le serveur utilise les fluxs sortants pour envoyer la demande et la réponse arrive sur un flux entrant ... donc si l'entrant est bloqué il n'est pas possible de communiquer.
3) non je ne pense pas
4) je pense qu'il faut 2 regles

apt-get utilise le port 80 normalement ... Donc c'est étonnant que çà ne marche pas...
Si tu fais apt-get update et apt-get upgrade -y çà marche correctement ?
quel est le paquet que tu veux installer ? (pour savoir si il est sur le dépot "standard" ou sur un dépôt différent.

[fan.2]

Bonjour,

en ayant suivi le tutoriel OVH sur le FirewallNetwork et m'être contenté des règles indiquées, j'ai connu hier le problème suivant :

en faisant un "apt install" d'un paquet, je suis resté bloqué à 0% d'un téléchargement depuis une adresse ftp.

J'ai également lu le tutoriel sur la solution anti-DDoS d'OVH et je me pose donc plusieurs questions :

1. Ai-je bien compris que les règles du "FirewallNetwork" ne sont appliquées qu'en cas d'attaque DDos et de passage par le VAC ?
2. Ai-je bien compris que les règles s'appliquent au flux entrant uniquement ?
3. Dois-je en déduire de mon problème d'hier qu'il y avait une attaque DDoS et que cela passait par un des VAC ?
4. Je suppose que je dois ajouter les ports 20-21 dans les régles mais y a t-il une syntaxe pour indiquer une plage d'adresse ou faut-il deux règles ?
5. Pourrait-on avoir un exemple dans la FAQ avec davantage d'exemples de règles ?
6. Pourrait-on avoir des explications sur les mystérieuses options TCP ?
   
   • Case à cocher "Fragments"
   • Drapeaux (Aucun ou ETABLISHED ou SYN)
   
   Est-il recommandé d'utiliser l'une de ces options pour un fonctionnement normal du VPS lors d'un passage par le VAC ?

D'avance un grand merci pour toute tentative d'éclaircissement par rapport à mes difficultés de compréhension.