Bonjour à tous,

J'ai décidé de me lancer dans la compilation de mes propres exécutables en suivant ce tuto : http://benjamin-balet.info/multimedia/synology/cross-compilation-pour-synology/

J'ai bien réussi à créer le fichier shellinaboxd, pour chaque environnement grâce aux toolchains.

J'ai juste un petit souci, par rapport à la libraire openssl. Je ne compile shellinabox que sans la partie ssl, ce qui fait qu'une fois lancé, il n'écoute que sur le port 80, sans possibilité de le faire basculer sur du https.

Je suppose donc que le souci vient de la compilation et quand je regarde le résultat du configure je vois ceci :

checking openssl/bio.h usability... no
checking openssl/bio.h presence... no
checking for openssl/bio.h... no
checking openssl/err.h usability... no
checking openssl/err.h presence... no
checking for openssl/err.h... no
checking openssl/ssl.h usability... no
checking openssl/ssl.h presence... no
checking for openssl/ssl.h... no

Je suppose que le problème vient de là...

Pourtant quand je compile sans rajouter les definitions du toolchain sur la VM Ubuntu, là il prend bien les libraires openssl :

checking openssl/bio.h usability... yes
checking openssl/bio.h presence... yes
checking for openssl/bio.h... yes
checking openssl/err.h usability... yes
checking openssl/err.h presence... yes
checking for openssl/err.h... yes
checking openssl/ssl.h usability... yes
checking openssl/ssl.h presence... yes
checking for openssl/ssl.h... yes

Le souci vient donc forcément de mes déclarations ci-dessous :

export CFLAGS="-I/usr/local/arm-marvell-linux-gnueabi/include"
export LDFLAGS="-L/usr/local/arm-marvell-linux-gnueabi/lib"
export RANLIB=/usr/local/arm-marvell-linux-gnueabi/bin/arm-marvell-linux-gnueabi-ranlib
export LD=/usr/local/arm-marvell-linux-gnueabi/bin/arm-marvell-linux-gnueabi-ld
export CC=/usr/local/arm-marvell-linux-gnueabi/bin/arm-marvell-linux-gnueabi-gcc
export LD_LIBRARY_PATH=/usr/local/arm-marvell-linux-gnueabi/lib

./configure --host=arm-marvell-linux-gnueabi

Je suppose qu'il me manque un lien vers la librairie ssl pour qu'il le trouve ?

Je ne suis pas du tout expert en la matière, si quelqu'un veut bien m'aider, je pense ne pas être loin mais...

Merci d'avance :)

Essayer d'ajouter  "--disable-ssl" en argument de la commande "configure"

Compiler sans SSL et le mettre en écoute sur localhost et laisser un reverse proxy s'occuper du https

Modifié le 7 janvier 20169 a par CoolRaoul

Quel est le risque de laisser shellinabox en écoute sur le port 4200 sans https ?

 

Modifié le 7 janvier 20169 a par Lokomass

il y a 12 minutes, Lokomass a dit :

Quel est le risque de laisser shellinabox en écoute sur le port 4200 ?

Le numéro du port importe peu, de toutes façons on peut choisir ce qu'on veut en ligne de commande.

Si tu fait allusion au mode "en clair" (pas de https) suffit, comme j'ai dit, de le laisser écouter exclusivement sur localhost et y accéder via un reverse proxy qui s'occupera du SSL (c'est ma configuration perso, j'utilise nginx pour ça). Possible d'ajouter des règles de filtrage supplémentaire dans la conf proxy (via proxy_pass, allow et deny) pour serrer les boulons.

Modifié le 7 janvier 20169 a par CoolRaoul

Tu m'as perdu la :)

Du coup actuellement, j'ai http://ip_publique_du_syno:4200

J'arrive dans ma console et je me connecte en direct.

Que dois-je faire concrètement pour sécuriser ça ? Tu aurais un tuto ? J'installer nginx ?

Mon objetcif est de pouvoir accéder au terminal ssh directement depuis un navigateur web depuis n'importe ou.

Ca risque de devenir un peu complexe, jette un oeuil à mon tuto sur la conf reverse proxy par Nginx et a toi de voir si tu te sens de faire la manip.

Y a aussi la possibilité d'utiliser le package Haproxy (y a un tuto pour ça aussi). A toi de voir.

Si c'est trop compliqué, je veux pas faire de bêtises...

Mais tu penses donc que c'est risqué de laisser ouvert : http://ip_publique_du_syno:4200

Ben, le premier script kiddie qui fait un scan de port sur ton IP publique va voir le port 4200 ouvert, si il tente une connexion au petit bonheur la chance, va tomber sur le prompt "Username:" et ça va lui donner l'envie de chercher à entrer (remarque en SSL tu ne serais pas plus protégé).

Et comme le login shellinabox n'est pas pris en compte par le blocage auto il va pouvoir essayer tant qu'il veux et aussi longtemps qu'il veux.

Avec un reverse proxy, faut déjà connaitre l'url de sous-domaine pour arriver à la connexion (sans oublier la possibilité de filtrage amont que j'ai évoqué).

Modifié le 7 janvier 20169 a par CoolRaoul

je prédit un hacking pour très bientôt ... :p

qd je vois ma parano sur mon firewall et la on laisse un shell ouvert en openbar ...

Modifié le 7 janvier 20169 a par gaetan.cambier

Au final avant, j'avais l'url https://ip_du_syno:4200, mais c'était pareil ? Si le mec vient il va avoir le prompt username =>

il y a 1 minute, Lokomass a dit :

Au final avant, j'avais l'url https://ip_du_syno:4200, mais c'était pareil ? Si le mec vient il va avoir le prompt username =>

idem à part qu'il aura les info du certificat en plus (si c'est un certificat autosigné,on se doute que c'est un particuler, si c'est le certif syno, il saura donc que c'est du materiel synology --> on peux faire une recherche de faille)

en fait, dans l'absolu, avec le https, tu donne encore plus d'info au futur hackeur que sans ...

sans oublié que mettre un shell en frontend comme ca, comme tout service en frontend, ca veux dire aussi qu'il faut suivre les update pour les failles de securité sans fautes sous peine d'augmenter encore les risques

pour etre honnete, la seule solution acceptable niveau securité pour un service aussi sensible reste le vpn (n'importe lequel sauf pptp)
et donc laisser shellinabox en local

Donc t'es en train de me dire que finalement, http c'est mieux que https ? je me fais chier pour rien alors :)

D’où l’intérêt de faire ceci dans le httpd.conf ?

 

<Location /shell>

    ProxyPass http://localhost:4200/

    Order deny,allow deny from all

</Location>

De ce fait, le mec peut pas détecter de port ?

Le détecter, ça ne changera rien

Y accéder peu de monde risque d'y accéder ainsi [emoji14]

Enfin au moins c'est plus secure

Merci mais j'ai une dernière question, en faisant ça, effectivement j'arrive à accéder via http://ip_publique_du_syno/shell mais aussi via  http://ip_publique_du_syno:4200

Du coup, je ne comprend plus vraiment l’intérêt... A moins que j'ai loupé quelque chose..

<IfModule !proxy_module> 
	LoadModule proxy_module modules/mod_proxy.so
	LoadModule proxy_connect_module modules/mod_proxy_connect.so
	LoadModule proxy_http_module modules/mod_proxy_http.so
</IfModule>

<Location /shell>
	ProxyPass http://localhost:4200/
</Location>

 

Merci mais j'ai une dernière question, en faisant ça, effectivement j'arrive à accéder via http://ip_publique_du_syno/shell mais aussi via  http://ip_publique_du_syno:4200

Du coup, je ne comprend plus vraiment l’intérêt... A moins que j'ai loupé quelque chose..

Si tu peux te connecter ainsi (direct sur le port 7200) *de l'extérieur* c'est qu'efffectivement tu as loupé ma preco précédente ou je disais de laisser shellinabox écouter uniquement sur "localhost". Ça se fait par modification de sa ligne de commande (j'ai pas la syntaxe en tête là, suis à l'extérieur sur mon téléphone)

--localhost-only ;)

Et même sans ça, tu peux maintenant supprimer la redirection du port 4200 dans le routeur, devenue inutile.