Reprise du message précédent :
DSub, c'est pas uniquement pour Subsonic ?

-thewizard- j'ai pas mal utilisé sonerezh et franchement c'est clairement pas mal du tout!

Si, c'est Ampache qui est compatible avec le protocole de Subsonic

Merci je vais essayer

Bon, j'ai vite fait le tour, mais pas moyen de trouver de tuto d'installation d'Ampache sur Synology sans passer par Docker. Or, Docker est pas dispo sur DS216Play
 
J'vais finir par me monter un serveur applicatif

A ce propos, il existe quoi niveau hardware pour faire un serveur sous linux avec une/des tâches assez basiques ? (comme vu ci dessus, serveur Ampache ou équivalent).
Sachant que je garderai certainement l'intégralité des datas sur le NAS.
 
Je pense qu'un pi, c'est un peu limite, surtout si je veux faire du transcodage lossless > mp3 à la volée.

Quelques exemples du plus petit au plus gros : il existe des Pi un peu plus vitaminés style bananapi, sinon dans les trucs toujours monocartes mais plus costauds il y a les odroid par exemple, dans la taille au-dessus il y a les mini-pc style pcengines qui restent très compacts/discrets/fanless, ensuite les NUC, pis ensuite on arrive sur du custom à base de mini-ITX

Franchement faudrait test, ça bouffe pas grand chose le reencodage a la volée

MP3 non en effet video c'est autre chose

faut que je me renseigne de plus près donc

Un Pi 2, 3, 3+ ça passe crème je pense. J'utilisais un Dockstar avant avec un CPU ARM vraiment anémique et le transcodage en temps réel ne passait pas avec lame mais passait avec un autre codec mp3 optimisé (sans calculs en float).
 
J'utilise maintenant un HP microserver largement sous exploité. J'utilise pas un Pi parce que mon serveur héberge 3 disques SATA et fait routeur donc je veux du gigabit. Donc c'est pour des raisons d'interfaces et pas de puissance CPU ou RAM.
 
Mais si j'avais un NAS comme toi je pense que j'utiliserais un Pi en complément.

c'est ce vers quoi je me tourne oui... pas besoin de plus.

Un orange pi c'est mieux niveau driver par rapport au banana je trouve.

comme de base j'y connais rien en pi, je vais sans doute me tourner vers un truc très officiel

bordel je me suis encore fait pirater mon serveur (debian)   ce coup ci il était à peu près à jour du coup je sais pas trop si je remonte une backup si ça va suffire

plus subtil que la dernière fois ce coup ci, process de crypto mining dans systemd et la crontab a été modifiée, pas écrasée (mais bon les 50% de CPU bouffés en permanence se remarquent vite )

 mais comment tu fais?

 
Ils sont rentré par où ?
 
Tu as quoi d'ouvert sur ce serveur ?

aucune idée de comment ils sont rentrés

en trucs ouverts je n'ai que du classique, ssh apache et 2-3 autres trucs mais que des services issus de packages debian donc maintenus à jour et a priori sécurisés. Bon j'avais un peu de retard sur les MAJ quand même, je crois que le dernier reboot datait de la première cague de patchs pour spectre/meltdown donc il est possible que des vulnérabilités mises au jour ensuite aient pu être exploitées.

J'ai fait un nettoyage de la crontab et shutté l'exécutable, on va voir s'il revient rapidement ou pas.

ton ssh est ouvert via le port 22 sur le wan?

C'est un truc que jamais je ne pigerai ça...

oui, et mon apache sur le port 443, je sais j'ai tout faux

Pourquoi ?

 
Non mais pour le SSH, déjà, fait une translation de port
 
Ensuite, la bonne pratique pour te connecter à une machine depuis le WAN c'est d'ouvrir un canal chiffré, type VPN, comme ça, n'est ouvert sur l'extérieur que le port de ton VPN et pas les ports type SSH ou autres

Ca doit faire 10 ans qu'on m'a pas piraté un serveur
 
XaT

 
Parle pas trop vite

 
Perso je vois vraiment pas le problème à avoir le port ssh ouvert:
-accès root disabled
-mdp user super fort ou mieux: auth par pubkey seulement

J'ai sécurisé y'a pas longtemps j'avoue, il m'est arrivé de traîner des années avec des mots de passes ultra faible ouvert sur le 22 et sans fail2ban
 
XaT

 
SSH est un canal chiffré    
 

 
voilà, ça c'est les vraies mesures

Perso je laisse 22 jusqu'à qu'un chinois commence à tenter de bruteforcer, à ce moment là je change parce que j'ai pas envie d'avoir des mega logs
 
XaT

la clé forte c'est déjà pas mal, mais si on peut en plus cacher la porte c'est encore mieux.
Le 443 ouvert si c'est un serveur web, pas de soucis, mais le 22... please, un open VPN est si simple à mettre en oeuvre !

Perso j'ai toujours un SSH ouvert sur le net, root autorisé
Mais dans un container et sur port autre que le 22. Ca doit faire 10 ans, jamais eu de problème, et mes logs fail2ban sont toujours vide.
 
Comme quoi suffit de mettre un autre port

J'en ai ras le cul des ports différents, putain déjà faut s'en souvenir mais en plus ssh/scp utilisent un argument différent -p pour l'un, -P pour l'autre

XaT

 
quel genre d'attaque pourrait arriver concrètement avec un ssh exposé sur internet quand on a un système à jour et une passphrase solide ?

bruteforce, mais si on ouvre le ssh sur un autre port, en plus d'avoir un mdp fort on a une porte fermée (22) mais ouvert ailleurs, et généralement les hackers ne cherchent pas, c'est 22 ou c'est pas !

Un canal chiffré dans un canal chiffré

Bah limit rate sur les nouvelles connexions en SSH ça limite déjà énormément le brute force

 
dans la pratique, aucune attaque ne va tenter de bruteforcer une passphrase, on parle de milliards d'essais, ça n'existe pas.

mais ça pourrit les logs, je suis d'accord, et ça peut ralentir le serveur, notamment sur les trucs genre raspberry/atom/...
 
Pour ma part j'ai installé pivpn sur le pi qui héberge pihole, qui fait mon dhcp/dns et compagnie.
 
Pour l'instant faut que je peaufine, en général ça marche nickel en 4G sur mon smartphone (cad quand j'ai direct une ip publique) mais sinon j'ai souvent des conflits de plage ip, du genre accéder à une machine distante (chez moi) dont l'ip est 192.168.1.2 quand je suis en wifi chez des amis chez qui les ips sont déjà en 192.168... ça ne fonctionne pas.
ça doit se configurer quelque part dans le client pour rerouter tout le trafic via le vpn et non pas essayer de mélanger tout ça... faut que je creuse... ça me fait pareil sur le macbook de Madame (autre client VPN). Sinon c'est sûr c'est pratique

renumérote chez toi, c'est probablement le plus simple.

Perso j'évite autant que possible les 192.168.0.0, je jongle entre les 172 & 10, et je préfère bien les 10.x
 
XaT

Connait pas PiVPN, mais si tu config une passerelle OpenVPN, par défaut tout le traffic du client passe dans le VPN, donc ton adresse 192.168... sera toujours celle de chez toi.
 
Celà dit, j'ai pas encore eu l'occasion de tester