Est-ce que cela marche ???? (regle securi te iptables)

Andre wrote:

Bonjour,

Comme je ne dispose pas d'une adresse IP privé (82.120.59.80 dynamique),
je me demandais si je pouvais mettre une règle sur mon pare-feu qui
n'autoriserait que les adresses IP commençant par 82.120 à accéder à mon
SSH ????

Si je rentre cela :

/sbin/iptables -A INPUT -i eth0 -p tcp --dport 22 --source 82.120 -j ACCEPT

Ai-je une chance de pouvoir accéder à mon ssh après ? cela marcherait ?

Merci de vos lumières,

André


NB : trop peur de m'auto bloquer l'accès après ;-)

/sbin/iptables -A INPUT -i eth0 -p tcp --dport 22 --source 82.120.0.0/16
-j ACCEPT

--
Even though I walk through the valley of the shadow of death,
I will fear no evil, for you are with me;
your rod and your staff, they comfort me.

Andre a pensé très fort :

NB : trop peur de m'auto bloquer l'accès après ;-)

Dans ce genre de situation, lance un "at now + 1à minutes" qui reset
tes IPtables.

Si la modif est OK => tu cancelle le at job
Si ta modif fout la merde, tu attends 10 minutes...

Meme chose sur les cisco avec un "reload in" qui fera rebooter le
router dans le delai fixe (ce qui retablira la config antérieure à la
modif en cours)

Alain
Qui a deja coupé la branche sur laquelle il etait assis :-D

NB : trop peur de m'auto bloquer l'accès après ;-)

Dans ce genre de situation, lance un "at now + 1à minutes" qui reset tes
IPtables.

Si la modif est OK => tu cancelle le at job Si ta modif fout la merde,
tu attends 10 minutes...

Encore plus simple.
Soit un script iptables.sh qui contient l'ensemble des règles à appliquer
Soit un autre script reset.sh qui contient les quelques règles qui vident
tout et repassent le système dans un truc complétement ouvert.

Suffit de taper:
(iptables.sh ; sleep 1m ; reset.sh) &

Attendre quelques secondes qu'on récupère la main (ce n'est pas forcément
immédiat, surtout s'il y a des résolutions DNS à faire)
Si oui, on kill ce qui précède, à coup de kill %X le X étant connu
Si non, on attend 1 minute.

Quand on ne récupère pas la main ce n'est pas forcément que tout est
foiré, parce que les nouvelles règles peuvent casser les connexions en
cours.
Il faut donc aussi essayer une nouvelle connexion pour vérifier si oui ou
non on a perdu la main.

Comme autres solutions, on peut penser au port knocking en plus pour
toujours avoir une porte d'accès. On aime ou pas, selon les goûts.
Je peux proposer un web knocking aussi, car parfois on a un serveur web,
qui continue d'être accessible. Suffit d'avoir une URL spéciale (sans
lien dessus et impossible à trouver par hasard), avec un script derrière
qui vérifie même les paramètres passés si on veut, et qui ajoute une
certaine règle iptables, reboote le système, ouvre complétement le
firewall ou ce qu'on veut...

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Patrick Mevzek wrote:

NB : trop peur de m'auto bloquer l'accès après ;-)

Dans ce genre de situation, lance un "at now + 1à minutes" qui reset tes
IPtables.

Si la modif est OK => tu cancelle le at job Si ta modif fout la merde,
tu attends 10 minutes...

Encore plus simple.

toujours plus simple :

puisque tu ACCEPT la connexion, tu insère (-I) ta règle *avant* la règle
générale qui gérait le service avant.

Ensuite tu fais mumuse, tu regarde les compteurs de ta nouvelle règle et
si tout est ok tu vire l'ancienne.

Une autre solution, aussi simple :) est de remplacer le -j BIDULE de ta
règle par un -j LOG avec un préfixe quelconque, de faire mumuse, de
regarder les logs et game over.

Eric

PS : le plus raisonnable étant aussi de ne pas jouer sur les serveurs de
prod -ou d'habiter pas loin- ;)

--
L'invulnérable :
Je ne pense pas etre piratable, infectable par un trojen oui!
Vu sur fcs un jour de mars 2004.

Le Thu, 17 Feb 2005 18:07:20 +0000, Eric Razny a écrit :

PS : le plus raisonnable étant aussi de ne pas jouer sur les serveurs de
prod -ou d'habiter pas loin- ;)

Ou d'utiliser un système de test. Ça tombe bien, y'en a un pour
Netfilter qui s'appelle nfsim :

http://ozlabs.org/~jk/projects/nfsim/

À la base, ça sert à tester les modules développé, mais dans la
pratique, ça peut servir à tester un ruleset.


--
BOFH excuse #382:

Someone was smoking in the computer room and set off the halon systems.

puisque tu ACCEPT la connexion, tu insère (-I) ta règle *avant* la règle
générale qui gérait le service avant.

Ensuite tu fais mumuse, tu regarde les compteurs de ta nouvelle règle et
si tout est ok tu vire l'ancienne.

Ca impose d'attendre que du trafic matche, ce qu'on ne contrôle pas
forcément.
Si on est en train de mettre en place des sécurités, mieux vaut qu'elles
soient en place avant le trafic, non ?
Ce n'est peut-être pas significatif d'un ACCEPT, mais on ne fait pas que
des ACCEPT dans la vie :-)

Une autre solution, aussi simple :) est de remplacer le -j BIDULE de ta
règle par un -j LOG avec un préfixe quelconque, de faire mumuse, de
regarder les logs et game over.

Idem.
Elégant, mais pas toujours possible.

PS : le plus raisonnable étant aussi de ne pas jouer sur les serveurs de
prod -ou d'habiter pas loin- ;)

C'est certes le plus raisonnable, comme d'utiliser un système de tests,
ou de faire des simulations, mais en pratique ce n'est pas toujours
possible. La vie est faite de compromis...

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>