[Ran] pb ssh sur freifunk (le retour)

Didier Lebrun dl at vaour.net
Jeu 8 Mar 11:36:20 CET 2012


Pour le navigateur, le plus simple est d'utiliser deux navigateurs 
distincts dans ce genre de cas.

Le changement de port n'est à mon avis d'aucune utilité pour la 
sécurité, vu que le scan des ports fait partie de l'outillage de base 
des hackers.

Pour les stats, à partir de la version 1.6, il vaut mieux les laisser en 
/tmp pour éviter la saturation de la RAM. Si tu veux les conserver au 
delà des reboot, il faut utiliser snmpd + Cacti sur un serveur de 
monitoring.

@+


Le 07/03/2012 01:10, v rac a écrit :
> Je vais voir ce que je peux faire avec Firefox. C'était le plan foireux
> de switcher proxy/pas-proxy qui m'avait burné dans le temps (j'ai
> toujours 50 pages web ouvertes, dur dur. Il aurait fallu une option
> "Proxy pour rien sauf" au lieu de "Proxy pour tout sauf"... faut que je
> me remette à chercher des trucs sur ces fichiers .pac dont au sujet des
> quels ils causent à la 5ème ligne des options de proxy. Si je peux y
> coller une dizaine d'adresses IP, ça va le faire :) ... j'ai déjà la
> salive.
> Et je crois que c'est à toi que je dois les scripts sur vaour.net
> (S51crond, S60rdate et local.cron-rdate), bien pour ma passerelle:
> depuis qu'elle n'a plus la becquée d'une livebox pour téter du web, elle
> fout ~5mn pour se connecter chez FND en pppoe, et y'avait plus de stats
> à cause de l'heure. Merci encore. J'aurais bien aimé aussi tenter de
> garder les stats après reboot et le restartolsrd la nuit, mais c'est un
> poil trop compliqué pour mes V1.74 (enfin, plutôt pour mes capacités
> d'analyse des deltas de scripts ;)... et puis j'ai pas envie de gérer la
> pénurie d'espace flash à la mano. Et toutes ces écritures dans la flash,
> ça finit pas par la fatiguer?
>
> Allez @+
> Et PS, la ligne S45firewall d'origine 83 modifiée... et corrigée ;) ,
> c'est :
> case $(nvram get ff_wanhttps) in 1)iptables -A INPUT -i $WANDEV -p tcp
> -s my.sweet.home.ip --dport `grep "xrelayd -p"
> /etc/init.d/S70secureadmin | cut -d"
> " -f9` --syn -j ACCEPT;;esac
> (avec le chemin complet, ça marche mieux... sûrement une histoire de
> process parent, j'ai encore de choses à apprendre, té.
> et mon S51dropbear excentrique (mais ne conseille-t-on pas de changer
> les ports standards?...) c'est
> #!/bin/sh
> ln -s /etc/dropbear /tmp/.ssh
> #test -n pourri, utiliser "! -z"
> if [ ! -z `nvram get ff_pubkey | cut -c1-7` ]; then
> /usr/bin/dropbear -s -p 12345
> exit
> else
> #(ceinture ET bretelles)
> /usr/bin/dropbear
> fi
> .. et, c'est quand même plus confortable de taper ssh root at listo -p12345
> que ssh root at listo + rentrer une passphrase diceware de 10 mots, non?
> ... sauf que le parano de sécu va me dire que c'est la clé privée qui
> devrait être protégée par la passphrase et que pageant, c'est mal :) ...
> enfin
>
> Et... ça me fait repenser qu'il faut que je cherche pourquoi il y a un
> traitement spécial dans la chaîne INPUT pour les ports >1023.
>
> Allez, à la plume
> 'Nenuit
>
>
> ----- Original Message ----- From: "Didier Lebrun" <dl at vaour.net>
> To: "Reseaux ruraux" <ran at lists.vaour.net>
> Sent: Monday, March 05, 2012 10:46 PM
> Subject: Re: [Ran] pb ssh sur freifunk (le retour)
>
>
> Si tu veux faire du SSH sur les autres noeuds du réseau via la
> passerelle, ça pose en effet des problèmes de "string too long" avec
> l'option "-i CLE_RSA" d'un noeud à l'autre. Par contre, ça fonctionne
> correctement avec des connexions par mots de passe. Donc, tu pourrais
> utiliser la connexion par clé sur la passerelle, où il y a des risques
> d'agression venant de l'internet, et utiliser des connexions par mot de
> passe à l'intérieur du réseau, où les risques sont moindres.
>
> "
> moi at monposte:~$ ssh -i CLE_RSA root at WAN_DU_NOEUD_GATEWAY
>
>
> BusyBox v1.01 (2010.08.29-10:07+0000) Built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
> _______ ________ __
> ( ).-----.-----.-----.) ) ) ).----.) )
> ( - )) _ ) -__) )) ) ) )) _)) _)
> (_______)) __)_____)__)__))________))__) )____)
> )__) F R E I F U N K F I R M W A R E
>
> root at NOEUD_GATEWAY:~# ssh root at IP_NOEUD_QUELCONQUE
> root at IP_NOEUD_QUELCONQUE's password:
>
>
> BusyBox v1.01 (2010.08.29-10:07+0000) Built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
> _______ ________ __
> ( ).-----.-----.-----.) ) ) ).----.) )
> ( - )) _ ) -__) )) ) ) )) _)) _)
> (_______)) __)_____)__)__))________))__) )____)
> )__) F R E I F U N K F I R M W A R E
>
> root at NOEUD_QUELCONQUE:~#
> "
>
> Toutefois, ce que j'évoquais précédemment, c'était plutôt l'accès aux
> interfaces web des routeurs derrière la passerelle au moyen d'un proxy
> SOCKS. Cela fonctionne très bien et fait l'affaire pour l'essentiel.
> Pour ma part, je fais ça en ligne de commande avec le client SSH
> d'Ubuntu dans un terminal, mais on peut faire la même chose avec PuTTY.
>
> "
> moi at i530n:~$ ssh -i .ssh/vaournet root at vn1.vaour.net -p 22 -D 8888
>
>
> BusyBox v1.01 (2010.08.29-10:07+0000) Built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
> _______ ________ __
> ( ).-----.-----.-----.) ) ) ).----.) )
> ( - )) _ ) -__) )) ) ) )) _)) _)
> (_______)) __)_____)__)__))________))__) )____)
> )__) F R E I F U N K F I R M W A R E
>
> root at vn1-dl:~#
> "
>
> Pour la config du navigateur (Firefox par exemple):
> * Configuration manuelle du proxy
> * Hôte SOCKS: localhost port: 8888
> * SOCKS v5
> * Pas de proxy pour localhost, 127.0.0.1
>
> Il suffit alors de gérer tes routeurs via l'interface web en HTTP ou
> HTTPS comme si tu étais à l'intérieur du réseau.
>
> Avec SSH + HTTP(S), tu pourrais gérer ton réseau confortablement depuis
> l'extérieur à travers les seuls ports standards, sans avoir à faire des
> excentricités avec toutes sortes de ports non standards.
>
> @+
>
>
> Le 04/03/2012 22:35, v rac a écrit :
>> Le 23/02/2012 19:47, Didier Lebrun a écrit :
>>>
>>> Pourquoi pas simplement un tunnel dynamique à travers le ssh port 22 du
>>> routeur gateway ? Voir:
>>> * http://www.makeuseof.com/tag/how-to-tunnel-traffic-with-ssh/
>>> * http://www.dd-wrt.com/wiki/index.php/Easy_SSH_tunnels
>>
>> Salut Didier
>> Une semaine laborieuse, et un week-end consacré à ce soucy, voilà les
>> résultats: les tunnels ssh -L ne conviennent pas: impossible de se
>> connecter en ssh + clé privée à un autre routeur en faisant un jump par
>> la gateway. J'ai d'abord copié la clé privée dans les routeurs mais j'ai
>> eu des erreurs de string trop long (moins élégant que Borat, tu meurs !
>> ), et après conversion de la clé avec dropbearconvert et scp dans les
>> routeurs, une erreur style "ze serveur did not blahblah".
>> Gââve grââve, c'est un problème de clientdropbear. Je pense que si
>> j'avais un vrai client SSH dispo derrière la gw, j'aurais pu m'en servir
>> comme tu suggères grâce à un tunnel vers le serveur de sa propre machine
>> depuis chez moi. Le bear n'est pas en forme, je me prends les pieds dans
>> la bear, je compense avec une beer.
>> Bon alors je me lance dans la modif du firewall gateway:
>> Preusio, en entrée pour me chauffer les doigts, dans S70secureadmin:
>> xrelay ...-d PortPasStandard ....
>> et dans S45firewall, ligne d'origine 83 modifiée:
>> case $(nvram get ff_wanhttps) in 1)iptables -A INPUT -i $WANDEV -p tcp
>> -s mon.ip.at.home --dport `grep "xrelayd -p" ./S70secureadmin | cut -d"
>> " -f9` --syn -j ACCEPT;;esac
>>
>> Ensuite pour ssh comme j'ai bataillé la galère, je m'étais bricolé un
>> S51dropbear conditionné à la présence d'une clé publique dans ff_pubkey
>> : idée de base:
>> if clé; then dropbear -s -p xxxxx; exit
>> else (pas clé) => dropbear normal ... disons fail safe :)
>> fi
>> Pendant la mise au point, j'ai rencontre ça:
>> http://forum.ubuntu-fr.org/viewtopic.php?id=841771
>> C'est malin, dire que je faisais mes tests avec -n !... enfin, basta.
>> Maintenant j'ai plus qu'à faire marcher (correctement) ce S51 et la
>> ligne S45fw de ssh correspondante... et voir ce dont il y a besoin sur
>> les routeurs non-gateway... faut que je me méfie, en plus j'ai 2 .mid
>> wan-wan dans le réseau...
>> Je sens que je faire des petits progrès en iptables!
>>
>> Allez @+ et bonne nuit, je reviens au rapport quand j'aurai du nouveau
>>
>> Bye
>>
>> Fabrice
>>
>> _______________________________________________
>> Ran mailing list
>> Ran at lists.vaour.net
>> http://lists.vaour.net/mailman/listinfo/ran
>>
>>
>
>


-- 
Didier Lebrun
Le bourg - 81140 - Vaour (France)
tél: 05.63.53.73.41
mailto:dl at vaour.net





More information about the Ran mailing list