Pages : 1
#1 Le 19/07/2014, à 18:58
- iro
probleme de configuration GUFW
Bonjour,
je suis tomber sur ca
En mettant la règle pour gufw (173.193.41.0/22, il ne veut pas la prendre: il me met 173.193.40.0/22)
J'ai donc essayé ces deux règles iptables données sur Korben:
sudo iptables -A INPUT -s 173.194.41.0/22 -j DROP
puis
sudo iptables -A OUTPUT -p tcp -d 173.194.41.0/22 -j REJECT --reject-with tcp-reset
puis j'ai sauvegarder
sudo -s iptables-save -c
En vérifiant l'ip de youtube, je ne voie pas de changement.
Merci de me donner la solution parce que la je suis perdu.
Dernière modification par iro (Le 19/07/2014, à 19:06)
Aime la vie et vis la vie que tu aimes.
Boinc pour aider la science.
Hors ligne
#2 Le 19/07/2014, à 20:17
- pires57
Re : probleme de configuration GUFW
si tu m'expliquais ce que tu cherches a faire ce serai plus simple
Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn
Hors ligne
#3 Le 19/07/2014, à 20:21
- iro
Re : probleme de configuration GUFW
Salut,
c'est explique dans le lien.
C'est pour régler les problèmes de lenteur entre Free et Youtube.
Aime la vie et vis la vie que tu aimes.
Boinc pour aider la science.
Hors ligne
#4 Le 20/07/2014, à 11:26
- pires57
Re : probleme de configuration GUFW
salut,
je ne suis pas le genre de personne qui va lire toute une page web pour comprendre le problème qui est expliqué ailleurs.
J'estime que tu es capable de faire une phrase pour expliquer brièvement ton problème.
Maintenant pour ton problème il faudrait que tu vois quel serveur tu interroge.
Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn
Hors ligne
#5 Le 20/07/2014, à 13:37
- iro
Re : probleme de configuration GUFW
Salut,
voici un extrait :"une petite astuce pour contourner les problèmes de peering entre Free et Google qui provoquent de gros problèmes au niveau de YouTube. Il faut comprendre que pour distribuer ses vidéos, Google utilise des serveurs de cache. Apparemment, c'est la connexion avec ces serveurs qui est sous-dimensionnée par Free.
Si on observe ce qui se passe lorsqu'on lit une vidéo sur YouTube, on remarque que l'IP des serveurs de cache de Google est situé sur la plage 173.194.x.x.
Si on bloque l'accès à cette plage IP, on constate que YouTube contourne le cache et fait taper directement sur ses serveurs, à savoir sur une IP en 208.117.x.x.''
Un extrait vaut mieux qu’une longue explication. Pour ce qui est du serveur interrogé, ça varie mais ils sont situé dans la plage 173.194.41.0-173.194.41.255.
Aime la vie et vis la vie que tu aimes.
Boinc pour aider la science.
Hors ligne
#6 Le 20/07/2014, à 13:45
- pires57
Re : probleme de configuration GUFW
salut,
je n'ai pas eu la réponse souhaité a mon dernier post.
Je vais reformuler, est ce que tu as vérifié quel IP tu interroge maintenant avec cette régle
Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn
Hors ligne
#7 Le 20/07/2014, à 13:51
- iro
Re : probleme de configuration GUFW
Pour être plus clair, l'ip avant règle et après règle est située dans cette plage (173.194.41.163 a l'heure actuelle)
Aime la vie et vis la vie que tu aimes.
Boinc pour aider la science.
Hors ligne
#8 Le 20/07/2014, à 14:13
- pires57
Re : probleme de configuration GUFW
donnes moi le retour de
iptables -L
Dernière modification par pires57 (Le 20/07/2014, à 14:13)
Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn
Hors ligne
#9 Le 20/07/2014, à 14:15
- iro
Re : probleme de configuration GUFW
sudo iptables -L
[sudo] password for iro:
Chain INPUT (policy DROP)
target prot opt source destination
ufw-before-logging-input all -- anywhere anywhere
ufw-before-input all -- anywhere anywhere
ufw-after-input all -- anywhere anywhere
ufw-after-logging-input all -- anywhere anywhere
ufw-reject-input all -- anywhere anywhere
ufw-track-input all -- anywhere anywhere
Chain FORWARD (policy DROP)
target prot opt source destination
ufw-before-logging-forward all -- anywhere anywhere
ufw-before-forward all -- anywhere anywhere
ufw-after-forward all -- anywhere anywhere
ufw-after-logging-forward all -- anywhere anywhere
ufw-reject-forward all -- anywhere anywhere
ufw-track-forward all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ufw-before-logging-output all -- anywhere anywhere
ufw-before-output all -- anywhere anywhere
ufw-after-output all -- anywhere anywhere
ufw-after-logging-output all -- anywhere anywhere
ufw-reject-output all -- anywhere anywhere
ufw-track-output all -- anywhere anywhere
Chain ufw-after-forward (1 references)
target prot opt source destination
Chain ufw-after-input (1 references)
target prot opt source destination
ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:netbios-ns
ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:netbios-dgm
ufw-skip-to-policy-input tcp -- anywhere anywhere tcp dpt:netbios-ssn
ufw-skip-to-policy-input tcp -- anywhere anywhere tcp dpt:microsoft-ds
ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:bootps
ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:bootpc
ufw-skip-to-policy-input all -- anywhere anywhere ADDRTYPE match dst-type BROADCAST
Chain ufw-after-logging-forward (1 references)
target prot opt source destination
Chain ufw-after-logging-input (1 references)
target prot opt source destination
Chain ufw-after-logging-output (1 references)
target prot opt source destination
Chain ufw-after-output (1 references)
target prot opt source destination
Chain ufw-before-forward (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere icmp source-quench
ACCEPT icmp -- anywhere anywhere icmp time-exceeded
ACCEPT icmp -- anywhere anywhere icmp parameter-problem
ACCEPT icmp -- anywhere anywhere icmp echo-request
ufw-user-forward all -- anywhere anywhere
Chain ufw-before-input (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ufw-logging-deny all -- anywhere anywhere ctstate INVALID
DROP all -- anywhere anywhere ctstate INVALID
ACCEPT icmp -- anywhere anywhere icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere icmp source-quench
ACCEPT icmp -- anywhere anywhere icmp time-exceeded
ACCEPT icmp -- anywhere anywhere icmp parameter-problem
ACCEPT icmp -- anywhere anywhere icmp echo-request
ACCEPT udp -- anywhere anywhere udp spt:bootps dpt:bootpc
ufw-not-local all -- anywhere anywhere
ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
ACCEPT udp -- anywhere 239.255.255.250 udp dpt:1900
ufw-user-input all -- anywhere anywhere
Chain ufw-before-logging-forward (1 references)
target prot opt source destination
Chain ufw-before-logging-input (1 references)
target prot opt source destination
Chain ufw-before-logging-output (1 references)
target prot opt source destination
Chain ufw-before-output (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ufw-user-output all -- anywhere anywhere
Chain ufw-logging-allow (0 references)
target prot opt source destination
Chain ufw-logging-deny (2 references)
target prot opt source destination
Chain ufw-not-local (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere ADDRTYPE match dst-type LOCAL
RETURN all -- anywhere anywhere ADDRTYPE match dst-type MULTICAST
RETURN all -- anywhere anywhere ADDRTYPE match dst-type BROADCAST
ufw-logging-deny all -- anywhere anywhere limit: avg 3/min burst 10
DROP all -- anywhere anywhere
Chain ufw-reject-forward (1 references)
target prot opt source destination
Chain ufw-reject-input (1 references)
target prot opt source destination
Chain ufw-reject-output (1 references)
target prot opt source destination
Chain ufw-skip-to-policy-forward (0 references)
target prot opt source destination
DROP all -- anywhere anywhere
Chain ufw-skip-to-policy-input (7 references)
target prot opt source destination
DROP all -- anywhere anywhere
Chain ufw-skip-to-policy-output (0 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain ufw-track-forward (1 references)
target prot opt source destination
Chain ufw-track-input (1 references)
target prot opt source destination
Chain ufw-track-output (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere ctstate NEW
ACCEPT udp -- anywhere anywhere ctstate NEW
Chain ufw-user-forward (1 references)
target prot opt source destination
Chain ufw-user-input (1 references)
target prot opt source destination
ACCEPT udp -- freeplayer.freebox.fr anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:ircd
ACCEPT tcp -- anywhere anywhere tcp dpt:51413
ACCEPT udp -- anywhere anywhere udp dpt:51413
DROP all -- mil02s06-in-f0.1e100.net/22 anywhere
Chain ufw-user-limit (0 references)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain ufw-user-limit-accept (0 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain ufw-user-logging-forward (0 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain ufw-user-logging-input (0 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain ufw-user-logging-output (0 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain ufw-user-output (1 references)
target prot opt source destination
Aime la vie et vis la vie que tu aimes.
Boinc pour aider la science.
Hors ligne
#10 Le 26/07/2014, à 12:34
- Compte supprimé
Re : probleme de configuration GUFW
Bonjour.
En supposant que cette astuce soit valable, j'annulerais la règle que tu as créé dans Iptables et j'utiliserais le fichier hosts pour rejeter la plage d'ip conseillée par Korben..
Des fois que
Édit:
127.0.0.1 173.194.41
Le fait de lui indiqué 173.194.41 (ou 173.194.41. me rappelle plus s'il faut ce point aussi, teste!) suffit à bloquer la plage d'ip de 173.194.41.0 à 173.194.41.255.
Reboot ton pc après modification. Certains note comme ceci dans le fichier hosts
0.0.0.0 173.194.41
Mais ça revient au même.
ÉDIT :2
À bien y réfléchir, je ne suis pas certain que ce soit pertinent d'entrer une règle directement dans iptables quand on utilise (g)UFW, ce dernier étant un frontend qui agit directement sur Iptables, tu peux donc avoir des règles non prises en compte Soit tu utilses ufw ou iptables mais pas les deux.
D'autre part, l'astuce que je t'ai donnée plus haut n'est pas une certitude, je sais quelle fonctionne correctement avec un fichier .htaccess sur un serveur
order allow,deny
allow from all
deny from 173.194.41
, donc si le résultat est négatif, interdit la connexion au domaine google...
127.0.0.1 www.google.com
Dernière modification par ignus (Le 26/07/2014, à 15:44)
#11 Le 27/07/2014, à 16:44
- iro
Re : probleme de configuration GUFW
Bonjour ignus,
je n'avais pas pensé au fichier hosts.
Mais malheureusement, ça n'a pas l' air de fonctionner.(en mettant le nom de domaine www.google.com, ça ne bloque que le moteur de recherche. Et pour les plages d'adresses avec ou sans le '.' ça ne bloque rien.)
Aime la vie et vis la vie que tu aimes.
Boinc pour aider la science.
Hors ligne
#12 Le 27/07/2014, à 17:52
- Ubuntu1988
Re : probleme de configuration GUFW
Bonjour,
Avec ufw, il y a plus simple
sudo ufw deny from 173.194.41.0/22
Mais attention, si ces IP sont utilisées par d'autres services de Google, ils seront aussi bloqués !
Personnellement, le changement de DNS a résolu le problème chez moi
Dernière modification par Ubuntu1988 (Le 27/07/2014, à 17:55)
J'ai perdu ! :(
Hors ligne
#13 Le 27/07/2014, à 21:08
- iro
Re : probleme de configuration GUFW
Merci Ubuntu1988,
mais la règle ufw est la même qu'avec gufw, c'est a dire qu'il remplace le 41 par un 40
Vers Action De
---- ------ --
[ 1] Anywhere ALLOW IN 212.27.38.253/udp
[ 2] 6667/tcp ALLOW IN Anywhere
[ 3] 51413/tcp ALLOW IN Anywhere
[ 4] 51413/udp ALLOW IN Anywhere
[ 5] Anywhere DENY IN 173.194.40.0/22
Aime la vie et vis la vie que tu aimes.
Boinc pour aider la science.
Hors ligne
#14 Le 28/07/2014, à 00:30
- fruitsecrases
Re : probleme de configuration GUFW
Hello j'ai été confronté à un problème qui me fait penser au tien lors de mon utilisation du logiciel Spotify, j'ai téléchargé mes playlist pour les écouter hors connexion (pour diverses raisons, comme ma volonté de ne pas être "suivi" lors de mes écoutes journalières (comme ça ma façon d'écouter ma musique leur est inconnue (car ils ne savent pas quel titre j'écoute à quelle heure et combien de fois par semaine par exemple)), mais aussi je me dis qu je ne fais pas appel au réseau informatique entre leurs serveurs et mon PC tous les jours donc ils ne seront pas surchargé et ne consommeront pas d'électricité pour moi, bref chacun fait comme il veut...). Alors j'ai téléchargé mes playlists afin de les écouter hors connexion, mais je me suis rendu compte que si mon Ubuntu était connecté à Internet, alors Spotify le remarquait et l'utilisait quand même (ce qui a eu pour effet que tout le temps que je venais de prendre à télécharger chaque musique de mes playlists sur mon PC, était perdu car le logiciel se connectait quand même au réseau s'il y en avait un !!!).
Mais là où ça été balaise à couper, c'est que en voulant comme toi interdire une plage d'IP je me suis confronté à ce problème : _le logiciel SPotify n'arrivant pas à se connecter à Internet parce que je lui avais bloqué ses plages d'adresses IP s'est mis à réagir autrement ! Il s'est connecté avec d'autres plages d'adresses IP et j'ai du les découvrir grace à la commande "netstat" sous Ubuntu). Le problème est que lorsque je quittai complètement le logiciel Spotify, et que je le redémarrai, je voulais être en mode "hors-connexion" tout de suite (pour les raisons que j'explique au dessus) dès le lancement de Spotify, mais ce n'est pas possible avec ce logiciel, il n'y a pas de réglages de disponible dans les préférences de celui-ci pouvant me permettre de faire comprendre à Spotify que dès son lancement, je veux être hors connexion. Donc j'ai feinté. J'avai repéré que je pouvais couper l'accès à Internet sur ces plages IP (je le fais avec IPtables, mais tu peux le faire avec GUFW ou UFW bien sûr).
Ça se sont les premières adresses IP bloquées sous SPotify (avant qu'il n'en recherche d'autres de disponible lui même, comme un grand...) :
# iptables -t filter -A OUTPUT -d 193.235.232.0/24 -j DROP
# iptables -t filter -A OUTPUT -d 54.192.0.0/16 -j DROP
Tout a donc fonctionné mais quand j'ai quitté complètement le logiciel et que je l'ai redémarré, il s'est connecté au net avec d'autre adresses IP qu'il avait en mémoire ! Donc là avec la commande "netstat" j'ai repéré pas à pas quelles étaient les autres adresses IP qu'il utilisait, et au final je les ai toutes repéré très rapidement et je les ai bloqué de la même façon qu'expliqué au dessus (avec mes règles IPtables). J'ai donc découvert et bloqué "en plus" ces adresses IP, (et seulement après j'étais tranquille), j'ai donc bloqué en plus celles-ci :
# iptables -t filter -A OUTPUT -d 194.132.0.0/16 -j DROP
# iptables -t filter -A OUTPUT -d 78.31.0.0/16 -j DROP
# iptables -t filter -A OUTPUT -d 194.14.0.0/16 -j DROP
# iptables -t filter -A OUTPUT -d 193.182.0.0/16 -j DROP
# iptables -t filter -A OUTPUT -d 194.68.0.0/16 -j DROP
Pour voir donc comment Spotify se connectait à son démarrage et trouvait le net avec d'autres adresses IP j'utilisais la commande "netstat" de cette façon :
# netstat -utan
Le "n" à la fin permet de ne pas "résoudre les noms de dommaines" donc ce ne seront que les adresses IP qui seront visibles une fois cette commande netstat entrée dans le terminal. Et je me susi aidé de cette commande netstat aussi mais différement, comme ceci :
# netstat -utaW
Le "W" en majuscule à la fin permet lui par contre de résoudre les noms de dommaines et c'est là tout l'intérêt, il suffit de repérer si Google utilise encore Internet avec la commande "netstat -utaW" (le W te permettant de voir si un service Google est connecté en ce moment sur le net), si tu en trouves un alors tu comptes à quelle ligne (dans ton terminal et bien sûr après avoir tapé "netstat -utaW")) se trouve ce nom de domaine Google, et là il faut vite taper l'autre commande netstat (netstat -utan) dans le terminal, afin que tu puisses voir l'adresse IP utilisée pile au même numéro de ligne que tu viens de trouver avec la commande "netstat -utaW" et qui comportait le nom "Google" dans tes résultats juste au dessus !
Et tu te mets à la recherche des adresse IP utilisées par Google afin de toutes les bloquer avec tes règles UFW. Comme tu vois au dessus dans mes règles IPtables j'ai du une fois indiquer une plage d'adresses IP se terminant par"...0/24" ou par "....0.0/16". Prenons l'exmple de celle-ci :
# iptables -t filter -A OUTPUT -d 193.235.232.0/24 -j DROP
Pour celle juste au dessus donc j'ai remarqué (avec mes commandes "netstat") que Spotify ne faisait varier cette plage d'adresse IP que comme ça :
il a testé ces adresses IP :
193.235.232.41
Ou bien :
193.235.232.132
Ou bien :
193.235.232.60
Mais jamais comme ça :
193.235.57.78
Donbc sur ce dernier exemple on voit que j'ai fait évoluer l'adresse IP vers sa fin (une série n'est plus "en gras" vers la fin d'adresse IP), et le numéro 232 qui se répette au dessus est remplacé par le numéro 57. Si cela avait été le cas, alors ma bonne règle IPtables se serait terminée comme ça """...0.0/16", ce qui aurait donné ceci :
# iptables -t filter -A OUTPUT -d 193.235.0.0/16 -j DROP
Mais donc ici pas besoin, donc la bonne règle IPtables reste celle se terminant par "....0/24", comme suit :
# iptables -t filter -A OUTPUT -d 193.235.232.0/24 -j DROP
J'ai reprodui cette même façon de faire pour trouver mes règles IPtables se terminant par : "....0.0/16". Le tout est donc de découvrir avec nos commandes netstat si Google ne fait que changer la dernière série de numéro de ses adresses IP ou bien s'il change aussi l'avant dernière série de numéro de ces adresses IP en plus de ceux de la toute fin de ses adresses IP.
Via tes propres commandes netstat(commande netstat que j'explique au dessus), tu veras justement comment Google réagi et tu trouveras tes propres règles UFW. En dernier exemple, pour ma commande IPtables suivante, j'ai remaqrué que Spotify changeait et les numéros qui se trouvent à la toute fin des adresses IP qu'il utilisait, ET AUSSI il les numéros de la série juste avant... Donc ça ne pouvait me donner que une règle de ce type (avec "...0.0/16" à la fin) :
# iptables -t filter -A OUTPUT -d 78.31.0.0/16 -j DROP
Voilou, si tu as ds questions on reste là.
Oups, j'édite mon message pour donner deux images, j'ai mis des points verts derrière les deux commandes netstat et derrière les lignes à repérer avec leur numéro, mais je mets ces deux images aussi pour montrer que mes lignes 1 et 2 (numérotée en vert) sont mélangées entre les deux photos d'écran suivantes, donc pour trouver les bonnes adresses IP à bloquer, il sera mieux que tu ne pollues pas ta connexion avec divers logiciels réseaux, ne lance que ce qui est nécessaire à la découverte de tes plages d'adresses IP de Google (que tu veux bloquer), et c'est tout, tu ne seras pa spollué, et puis je pense qu'avec les résultats dans le terminal de la seule commande suivante :
# netstat -utan
tu puisses être tout à fait capable de trouver sur Internet à quoi correspond chaque adresse IP (que te retournera la commande du dessus) afin de savoir si cela correspond à une adresse ip de chez Google ou pas. Bref, les méthodes peuvent varier, j'en présente seulement deux aspects ici, d'autres forumeurs te donneront sûrement quelque chose de plus simple. La colonne où il est écrit ESTABLISHED veut dire que en ce moment la connexion est établie !(ici on voit qu'elle est établie entre mon VPN et moi. Et pour Spotify on voit "SYN_SENT" et là ça veut dire que ce n'est pas établie, c'est ce que je recherche
Les photos d'écran :
La commande netstat en version W :
La commande netstat en version n :
Dernière modification par fruitsecrases (Le 28/07/2014, à 01:45)
Hors ligne
#15 Le 28/07/2014, à 07:00
- bruno
Re : probleme de configuration GUFW
En mettant la règle pour gufw (173.193.41.0/22, il ne veut pas la prendre: il me met 173.193.40.0/22)
Oui et ? Cela me paraît tout a fait normal dans la mesure ou 173.193.41.0/22 correspond à la plage IP 173.193.40.0 - 173.193.43.255…
La notation CIDR correcte de ce sous-réseau est donc bien 173.193.40.0/22
#16 Le 28/07/2014, à 20:43
- pires57
Re : probleme de configuration GUFW
voila ce qui se passe quand on veut faire du firewalling et qu'on a meme pas les bases du réseau, on comprend pas
Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn
Hors ligne
#17 Le 29/07/2014, à 00:16
- iro
Re : probleme de configuration GUFW
Salut,
merci bruno,j' avoue avoir oublié quelques bases mais pourquoi ça ne bloque pas les ip demandées ?
@ pires57: t'es gentil mais quand on demande le retour d'une commande et qu'on ne répond pas...
Aime la vie et vis la vie que tu aimes.
Boinc pour aider la science.
Hors ligne
#18 Le 29/07/2014, à 07:12
- pires57
Re : probleme de configuration GUFW
Il y en a qui bosse, perso j ai pas forcément le temps de répondre dans la seconde et cela m'arrive de zapper. Tu n'es pas la seul personne que j'aide ici et c'est pas parce que je lit les retours que j'ai le temps d'y répondre dans la minute.
Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn
Hors ligne
Pages : 1