Bonjour j’arrive pas à comprendre pourquoi ca ne fonctionne pas
j’essais d’avoir une config firewall de base
j’essais de bloquer tous les port entrant SAUF ssh
alors je fais
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -P INPUT DROP
après ca je me déco, je fais un nmap pour tester je vois bien 999 ports filtré ssh ouvert
mais quand j’essais de me connecter j’obtient à chaque fois des
du coup je dois redémarrer le serveur, où est l’erreur dans le code?
dans le lien ils ne changent pas le POLICY
ce que j’essayais de faire est de mettre le comportement par défaut à DROP
et ensuite mettre les règles d’acceptation…
dans l’exemple ils laissent le POLICY à ACCEPT
mettent les règles d’acceptation
puis à la fin refusent le reste
je comprends pas trop…
Tcho,
vu de “loin” comme ça je dirais que la première règle avec Iptables est de [mono]toujours mettre les règles dans l’ordre[/mono], de les taper dans l’ordre dans le temrinal, pour que le fichier de règles Iptables les intègrent dans l’ordre et les interprètent dans l’ordre. (Iptables fonctionne comme ça).
Donc dans ton premier message ça m’interpèle, tu les donnes dans le désordre(tu as donc les bons chevaux mais dans le désordre 
). Il faut donc te logguer en ROOT bien sûr et taper les règles dans cet ordre :
[code]# iptables -P INPUT DROP
à+
mais oui mais non 
je tape les commandes “en live” pour pouvoir redémarrer à distance si jamais le firewall posait problème.
Hors là dès la première commande je me banni
du coup j’ai essayé de lancer en script
editor /etc/iptables.test.rules
iptables-restore < /etc/iptables.test.rules
j’ai obtenu
Écris un script sh avec ces deux commandes, puis exécute-le. Comme ça, même si tu es bannis, la deuxième commande est tout de même prise en compte.
je viens d’éditer, par contre les script je connais mal j’ai obtenu line 1 failed j’ai pas compris 
J’y connais rien en script, je passe la main !
Je pense qu’il te manque juste la première ligne. Le contenu exact de ton fichier doit être :
#!/bin/sh
iptables -P INPUT DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
à exécuter en root.
et ne pas oublier le OUTPUT, comme dans l’exemple que je t’ai donné.
et aussi de nettoyer les regles avant d’en faire de nouvelles.
“#!/bin/sh” c’est pour le recharger au démarage? ya un problème, c’est du testing donc je ne veux pas charger les règles au démarrage, ca m’obligerait à réinstaller le système en entier
j’aimerais pouvoir lancer le script juste une fois pour le test
c’est juste pour dire que c’est un script bash
ok merci
Tu devrais lire le tuto de ricardo sur l’approche d’iptables installation-parefeu-iptables-pour-les-nuls-t1901.html
enfait je suis tombé sur la commande netstat par hasard
j’ai fait un netstat -uta pour voir et j’obtiens plein de connexions
[quote]tcp 0 0 localhost:domain : LISTEN
tcp 0 0 :ssh : LISTEN
tcp 0 0 localhost:smtp : LISTEN
tcp 0 0 localhost:953 : LISTEN
tcp 0 0 xxxx.rev.p:ssh xxxxxx:15135 ESTABLISHED (ca c’est moi)
tcp 0 0 xxxxxx.rev.p:ssh 37.160.178.48:26691 ESTABLISHED
tcp 0 368 xxxxxxx.rev.p:ssh xxxxxx:15029 ESTABLISHED (c’est moi)
tcp6 0 0 [::]:ssh [::]: LISTEN
tcp6 0 0 localhost:smtp [::]:* LISTEN
tcp6 0 0 localhost:953 [::]:* LISTEN
udp 0 0 xxxxxxx.rev:35348 net1.web.yas-online:ntp ESTABLISHED
udp 0 0 xxxxxxx.rev:34382 seefra.casti.so:ntp ESTABLISHED
udp 0 0 xxxxxxx.rev:51804 porthos.scieron.com:ntp ESTABLISHED
udp 0 0 xxxxxxx.rev:46701 porthos.scieron.com:ntp ESTABLISHED
udp 0 0 xxxxxxx.rev:41590 y.ns.gin.ntt.net:ntp ESTABLISHED
udp 0 0 xxxxxxx.rev:56979 ntp-1.arkena.net:ntp ESTABLISHED
udp 0 0 xxxxxxx.rev:58079 ns1.hezzel.org:ntp ESTABLISHED
udp 0 0 xxxxxxx.rev:33505 host3.nuagelibre.or:ntp ESTABLISHED
udp 0 0 xxxxxxx.rev:60186 mindstudios.com:ntp ESTABLISHED
udp 0 0 localhost:domain :
udp 0 0 *:bootpc :
udp 0 0 xxxxxxx.rev:58503 spinnaker.darktech.:ntp ESTABLISHED
udp 0 0 xxxxxxx.rev:32960 v.bsod.fr:ntp ESTABLISHED
udp 0 0 xxxxxxx.rev:59592 176.31.53.204:ntp ESTABLISHED
udp 0 0 xxxxxxx.rev:51552 oods.roflcopter.fr:ntp ESTABLISHED
udp 0 0 *:30104 :
udp 0 0 xxxxxxx.rev:50585 kitty.zeroloop.net:ntp ESTABLISHED
udp 0 0 xxxxxxx.rev:37277 fra.pionica.com:ntp ESTABLISHED
udp 0 0 xxxxxxx.rev:58781 obsidian.ad-notam.n:ntp ESTABLISHED
[/quote]
comment ca se fait toutes ces connexions établies?
je saute voir le tuto de ricardo
edit : j’ai fait un shutdown -F now, je vais m’entrainer sur virtualbox d’abord -_-’
bonjour,
j’aimerais votre avis. A en croire cet article :
stdout.cowthink.org/tcp-ports-a … sed-ports/
le pare-feu n’est pas si important dans le sens où passer de ports fermé à caché n’a pas grand intérêt.
En fait le parefeu c’est juste pour prévenir une ouverture non prévu d’un port?
autrement, port bloqué, caché sont inviolable? ce sont les ports ouverts qui sont dangereux?
[quote=“vger”]bonjour,
j’aimerais votre avis. A en croire cet article :
stdout.cowthink.org/tcp-ports-a … sed-ports/
le pare-feu n’est pas si important dans le sens où passer de ports fermé à caché n’a pas grand intérêt.
En fait le parefeu c’est juste pour prévenir une ouverture non prévu d’un port?
autrement, port bloqué, caché sont inviolable? ce sont les ports ouverts qui sont dangereux?[/quote]
Pour une machine à usage domestique, une pare-feu est effectivement inutile. Ta *Box fait tout le travail.
Par contre, pour une machine connectée à un réseau potentiellement hostile (Serveur connecté à Internet, poste de travail d’entreprise ou d’université, …), les utilisateurs des autres machines du réseau peuvent potentiellement vouloir tester ou attaquer ta machine. Avec un OS parfait, des logiciels sans faille, et un administrateur omniscient, un pare-feu ne sert à rien. Mais dans la pratique, on préfère éviter qu’une connexion ne soit initiée avec un service si elle n’est pas nécessaire. Ça évite qu’une faille d’un service oublié ne soit utilisée pour attaquer ta machine.
[quote=“Dunatotatos”]Pour une machine à usage domestique, une pare-feu est effectivement inutile. Ta *Box fait tout le travail.[/quote]Bof, pas si sur… :/[quote=“vger”] En fait le pare-feu c’est juste pour prévenir une ouverture non prévu d’un port?[/quote]un port fermé est fermé, sans modification sur le fichier de configuration il restera fermé. [quote]ce sont les ports ouverts qui sont dangereux?[/quote]Les ports ne sont pas dangereux, ils permettent la communication des services entre eux, ce sont les comportements d’intrusions qui peuvent être dangereux. Dans ton cas de figure tu dois aborder le sujet simplement, tu t’apprête à installer un serveur internet, ce serveur va fournir des services, ton pare-feu doit permettre la communication de ces services avec l’extérieur. Tout le reste tu fermes! Accessoirement une doc (pas exhaustif hein) pour comprendre l’internet frameip.com/ipsec/
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
On repère trois sections :
Chain INPUT : correspond aux règles de trafic entrant ;
Chain FORWARD : correspond aux règles de la redirection du trafic ;
Chain OUTPUT : correspond aux règles du trafic sortant.Dans ce cas le pare-feu (iptables) est une vraie passoire, toutes les chaînes sont ACCEPT
je te remercie. C’était juste pour savoir si c’était pressé ou pas de régler le parefeu correctement. Parce que dans le cas d’un serveur à ip fixe, t’as beau caché les ports que tu veux yaura toujours au moins le port 80 d’ouvert donc ta présence on la voit.
par contre j’ai encore du mal à comprendre le FORWARD…
dans le nstat que j’ai copié collé plus haut, les connexions sont en forwarding? en gros on utilise mon serveur comme passerelle pour se déplacer?