Serveur @ home

@moe

Heberger des fichiers illegaux surtout.

CF :
http://zythom.blogspot.fr/2012/04/le-plein-de-pr0n.html

Sachant que si c’etait du porn classique. Ca aurait pu etre bien pire.

D’abord, le sujet initial:
j’ai fait l’acquisition de ce serveur il y a genre 1 semaine, pile poil avant qu’il ne baisse de 20€ :wink:

Franchement, c’est juste de la balle pour ce prix là. Rien qu’un petit boîtier sexy pour monter une machine te coute déjà 100€ alors moi je l’ai vraiment pas trouvé cher.
Il possède 2G de ram, et un slot est dispo pour augmenter.

En NFS, je transfere à 120Mo/s, un NAS à 200 balles à ma connaissance n’est pas capable de tenir un tel débit :slight_smile:
Donc, go for it!
En plus, même si j’ai pas encore testé, le CPU supporte les instructions de virtu, donc cloisonner tes sites dans des VMs ça doit bien se faire, surtout si tu te contentes d’isolation, comme LXC. Un site par vm et pif paf pouf.
Je compte poster des trucs là dessus pour ce serveur spécifiquement, éventuellement je posterai ici.

[quote=« Moe, post:31, topic: 54770 »][/quote]

Ça ne laisse rien rentrer, par contre ça n’empêche souvent pas de sortir.
Du coup ça laisse un connect-back possible. (c’est à dire au lieu de faire 

ecouter() ; 
while (1) { 
  recv(cmd);
  send(exec(cmd);
}

ça fait 

connecter(unserveur); while (1) { recv(cmd); send(exec(cmd)); }

[quote=« LoneWolf, post:28, topic: 54770 »][/quote]

J’espère qu’ils ont corrigé les problèmes du guruplug serveur :slight_smile:

[quote=« Ewi, post:35, topic: 54770 »][/quote]
Je préviens juste :slight_smile:

[quote=« phili_b, post:36, topic: 54770 »][/quote]
Non peut être pas a ce point la, mais ce que tu rends disponible sur le net, il faut que tu ais conscience que, même si tu l’as protégé « state of the art », il existe au moins une personne « non autorisé » qui est capable:

  1. De récupérer les documents
  2. D’utiliser le serveur dispo sur le net pour voir ce qu’il y a ailleurs, typiquement qui se connecte, à partir de quelle IP, est ce que ces IP contiennent des serveurs exploitables, etc.

[quote=« Ben, post:38, topic: 54770 »][/quote]
Comme le disait Bussiere, c’est faux. Le compteur, même s’il atténue le signal du CPL, laisse quand même passer le signal pour qu’il soit utilisable a l’extérieur de chez toi. Dans le cas d’une maison, le risque est faible a cause de la longue liaison maison/edf mais pour un apart, c’est tout a fait envisageable.
J’ajouterais que ce genre de certitude est a proscrire dans le monde de la sécurité. Même si a priori c’est pas possible, il suffit que quelqu’un trouve le truc et c’est terminé. Perso, c’est ca que j’adore, si tu n’es pas capable de te remettre en question dans la secu réseau, tu n’es pas fait pour ce job.

[quote=« Moe, post:40, topic: 54770 »][/quote]
C’est le genre de truc que je n’arrive pas a faire comprendre a ma direction. Ils veulent absolument trouver une raison a un piratage éventuel alors qu’un pirate n’a pas besoin de raison.

[quote=« fser, post:42, topic: 54770 »][/quote]
A priori, oui :slight_smile:

LoneWolf
Stay Tuned!

[quote=“Moe, post:40, topic: 54770”][/quote]Si je te disais qu’il existait des scripts pour repérer les photos de nus / porn (a la base ils sont fait pour la censure) ?
https://www.google.fr/search?q=nude+picture+script&oq=nude+picture+script&aqs=chrome.0.57.3849&sourceid=chrome&ie=UTF-8#hl=fr&safe=off&tbo=d&sclient=psy-ab&q=nudity+detection+script&oq=nudity+detection+script&gs_l=serp.3…7366.13848.2.14043.27.24.3.0.0.0.90.1223.24.24.0…0.0…1c.1.Xnv1-udWg2A&psj=1&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.&bvm=bv.41524429,d.d2k&fp=dfbe5ce5cee04864&biw=1680&bih=935
Et qu’ensuite il peut juste cibler ce genre de photo ?

pour rester dans le topic :
Sinon git-annex est sortis pour tout les possesseurs de nas and co a regarder je penser

http://git-annex.branchable.com/

Si des gens ont testé je prends les retours.

[quote=« Bussiere, post:44, topic: 54770 »][/quote]Si tu me disais ça, je te dirais qu’il faut que tu développes parce que là je vois pas où tu veux en venir. :slight_smile:

[quote=“Moe, post:45, topic: 54770”][/quote]

On va dire que si jamais un jour je faisais ce genre de trucs ce qui m’attire le plus ce sont les photos/videos croustillantes.

Donc je rentre dans ton nas, je scan tes photos / videos de vacances en rapport avec du nue et je rappatrie celles la.

Avec why not une demande de bitcoin si tu ne veux pas que ca finisse sur un reseau avec ton nom / prenom / adresse email.

Pour avoir ton nom / prenom / adresse email.
Parseur d’expression reguliere sur les fichiers pour les @ ou les 06, chercher des mots cles comme facture / edf / carte / rue.

Ou sinon si tu as un site en ligne un petit whois sur le nom de domaine pour le site hebergé sur le nas pour savoir qui est derriere.

Tes photos de nus / videos ca ne prendra pas des masses de temps a rapatrier.

C’est la fin du dredi, tout le monde va effacer le pr0n de son NAS par peur du piratage. :frowning:

T’es fou, ya pas meilleur honeypot !

[quote=“AnA-l, post:48, topic: 54770”][/quote]

+1.

J’avais meme lu un truc sur comment faire un faux fichier de porn qui en fait etait un acces disquette et du coup faisait du bruit et signalait une intrusion.
C’etait rigolo

Bon ba voila en « livraison » :)  Nas et serveur web virtualisés chacun dans leurs coins sur un vieux mbp… reste a attendre la livraison pour voir se que cela donne sur l’ordi hp :slight_smile:

et y a pas de porn chez moi nan mais ho

RAID IS NOT BACKUP!

C’est la règle numéro un, et ainsi si un pirate t’empêche d’accéder à ton contenu, tu as de toute façon une sauvegarde indépendante sur un autre disque non relié au NAS.

Pour le pr0n les fichiers sensibles (personnels), il faut que je teste TrueCrypt. Actuellement, si un pirate accède à mon NAS (accessible uniquement par SSH, avec clé publique/privée (l’authentification par mot de passe est désactivée)), il a accès à mon fichier /home car il est sauvegardé toutes les heures sur le NAS, et dans /home il y a Mozilla, donc il verra tous mes mots de passe sur tous mes sites. Ce thread aura eu le mérite de me faire penser à ce problème. :expressionless:

[quote=“Moe, post:51, topic: 54770”][/quote]
une "partition"TrueCrypt sur mon NAS pour les trucs sensibles, c’est la stratégie que j’utilise, ça marche nickel, bien qu’un peu de latence… mais j’imagine que ça dépend du NAS et du type de cryptage.
Pour les mots de passe j’ai 1password, du coup bah ça empêche pas tout mais bon suis pas inquiet pour ça en tous cas  :closedeyes:

[quote=“Moe, post:51, topic: 54770”][/quote]
Ouais. Perso, je vois pas la véritable amélioration d’utiliser la cle privé en ssh depuis l’existence de fail2ban, notamment si tu désactive l’auth par mot de passe (jamais je fais un truc pareil perso, mais bon)
_Comment tu fais si tu paumes la cle prive? Tu fais une fausse manip et tu supprimes la clé “PUTAIN MERDE J’AI DELETE LA CLE!!!”
_Pour une raison X ou Y, tu te fais chourrave la cle, bah la personne peut rentrer sans problème.

Globalement, c’est surtout le risque 1 qui est maximal, car une fausse manip est facile. Tu peux toujours sauver ta clé ailleurs, mais la multiplication des copies de clés augmente le risque 2.
En ssh, j’ai plutôt tendance a:
_Bloquer l’accès direct en root
_Imposer aux users des mots de passes longs (10+) avec des règles fortes (Au moins une majuscule et un chiffre)
_fail2ban réglé a 3 essais, et blocage 100min (au lieu de 6/10 par défaut)

Si quelqu’un peut m’expliquer en quoi l’utilisation de clé privé est plus efficace niveau secu qu’un mot de passe, je suis preneur. Pour moi, pour le moment, c’est largement plus dangereux en clé privé.

LoneWolf
Password FTW

Sur des machines perso, ça se discute. Mais sur un environnement pro avec des multiples utilisateurs ça permet de pouvoir révoquer l’accès à un utilisateur (en supprimant sa clef) sans avoir à changer le mot de passe du compte (que les utilisateurs n’ont pas besoin de connaitre).

[quote=« LoneWolf, post:53, topic: 54770 »][/quote]
Au pire, je peux remettre la connexion par mot de passe en modifiant un fichier sur le NAS avec Samba, ça marche que de chez moi évidemment.

[quote=« LoneWolf, post:53, topic: 54770 »][/quote]
J’ai ptet mal compris mais pour moi ça utilise ma clé publique (placée dans ~/.ssh/id_rsa.pub), qui est chiffrée par un mot de passe. Donc tu peux avoir la clé mais tu ne pourras rien en faire sans mon mot de passe (qui est le même sur tous mes comptes importants, je sais, c’est pas très sûr). La clé privée est uniquement sur le serveur, donc s’il l’a c’est qu’il est déjà connecté ? Edit : la clé privée reste sur son poste « local ».

[quote=« LoneWolf, post:53, topic: 54770 »][/quote]
Parce que l’authentification par clé s’appuie sur un mot plus long, donc plus long à deviner ou casser ? Dites-moi si je me trompe. :slight_smile:

[quote=« TahitiBob, post:54, topic: 54770 »][/quote]
Ouais, c’est quand même un cas assez particulier car en général, on a pas plusieurs utilisateurs sur un même compte (sauf en admin ou root peut être plusieurs personnes physiques). Mais je note.

[quote=« Moe, post:55, topic: 54770 »][/quote]
Ok, my bad. Pour moi, l’auth par cle prive/publique n’était qu’une solution de confort pour ne pas avoir a s’authentifier (rentrer un pass) à chaque fois. Cette solution est souvent utilisé pour le scripting, pour pouvoir lancer des scripts (de sauvegarde) à distance, sans que le script ait besoin du mot de passe.
Donc dans ces conditions, ca peut s’envisager pour améliorer la sécurité, mais ca pose d’autres problèmes. Imagine que tu utilises ton compte ssh (de serveur dédié) que de ton pc de bureau chez toi, et que en pleine journée, genre un week end chez des amis, tu ais un gros problème sur le serveur et il faut intervenir de suite. Sans ta clé prive, c’est mort.

Parce que l'authentification par clé s'appuie sur un mot plus long, donc plus long à deviner ou casser ? Dites-moi si je me trompe. :)
C'est faux. Tout simplement parce que le mot plus long, tu peux aussi l'utiliser en password ssh classique. S'il y a une meilleure sécurité, c'est tout simplement parce que c'est (du coup) considéré comme une double authentification: clé privé et mot de passe. C'est donc mieux que juste "mot de passe".

Du coup, avec la notion de passphrase, ça prends un peu plus de son sens, mais qui n’a d’intérêt que si on utilise toujours la même machine cliente pour la connexion. Si on est susceptible d’utiliser plusieurs machines pour se connecter, c’est juste ultra reloud.

LoneWolf
Updating ssh authentification solutions: Succeeded.

Avant de couper l’authentification par mot de pase, j’ai configuré une clé publique, autorisée par mon serveur, sur mon téléphone Android (via l’appli ConnectBot). Si y’a une urgence je peux m’en servir pour me connecter directement depuis le téléphone ou pour authentifier une autre clé si je veux travailler d’un autre poste. Pour te connecter depuis plusieurs machines, tu peux peut-être mettre la clé sur une clé USB, sans risque de perte grâce à la passphrase.

[quote=« LoneWolf, post:56, topic: 54770 »][/quote]

Il y a plein de cas ou effectivement on utilise des comptes locaux uniques à chaque user réel, mais dans mon domaine (hosting web) il y a plein de contre exemples. Une base Oracle tourne via un user ‹ oracle ›, j’ai N DBA pouvant intervenir dessus, ils doivent tous pouvoir se connecter au compte en question. Idem pour root pour les sysadmins de mon équipe, etc…

[quote=« LoneWolf, post:56, topic: 54770 »][/quote]

La notion de confort elle arrive lorsque tu utilises un agent SSH pour ta connexion. Sur ton pc tu saisis une fois la passphrase de ta clef. Elle est ensuite chargée par ton agent et tu n’as plus besoin de resaisir ta passphrase durant ta session : authentification transparente sur tout ton parc de serveurs.

[quote=« LoneWolf, post:56, topic: 54770 »][/quote]

Rien ne t’oblige à n’avoir ta clef que sur une seule machine physique (en restant bien sur raisonnable, il ne faut pas non plus qu’elle se ballade n’importe ou). Ma clef est sur mon pc au bureau, sur mon pc chez moi, et sur mon téléphone.

Quand à désactiver purement l’authentification par mot de passe, c’est un peu risqué dans certains contextes. Si par erreur tu (ou un collègue) rm le authorized_keys, ça peut être un peu long de récupérer l’accès à la machine :slight_smile:

J’ai supprimé mon post qui disait que la clé est chiffrée, on a compris.

Par contre, un truc configurable facilement, c’est d’autoriser la connexion par mot de passe, sous certaines conditions; genre:

Match Address 192.168.1.0/24
PasswordAuthentication yes

[quote=« fser, post:59, topic: 54770 »][/quote]

Ca se spoof une adresse ip :confused:
et ca se forge et se bidouille.

http://fr.wikipedia.org/wiki/Usurpation_d%27adresse_IP