Sécuriser un outil de travail collaboratif en ligne

Pause Café
#1

Bonjour à tous.

JE suis en train de mettre en place un outil de partage collaboratif pour permettre principalement l’échange documentaire entre un cabinet de programmation architecturale et ses clients ( 3 universités ). C’est un coup de main pour faciliter la vie de ma chère et tendre architecte de femme :wink:. La plateforme doit être à dispo durant 3 mois

Pour cela je vais utiliser Agora-project ( : du classique php + mysql ) agora-project.net/ … dont les fonctionnalités leurs vont très bien.

Donc j’ai monté un hébergement spécifique à la plateforme ( aucun autre service ne tourne à part le ssh + le LAMP ) sur serveur VPS chez Gandi :

  • Debian 6.0 , accès ssh sur un autre port que le 22 et fail2ban … pas de connexion root possible en ssh
  • LAMP complet configuré pour utiliser la plateforme en https ( certificat pour le nom de domaine acheté chez Gandi )

En l’état je pense que ça doit suffire ( ? ) ) mais j’aimerais bien en profiter pour faire les choses comme “un pro” si vous me passez l’expression.

Du coup j’ai quelques avis à vous demander :

  • Que feriez vous pour “blinder” la sécurité globale du serveur ? j’ai quelques idées grapillées ici ou là mais j’aimerais avoir quelques avis de gens habitués et qualifiés et je sais qu’i y en a ici :023 … Pour le moment j’y panne rien au pare feu par exemple :smiley:

  • Et surtout , je voudrais avoir des idées pour mettre en place une surveillance antivirus. En effet , mes utilisateurs vont utiliser des macs et mais aussi des windows … A priori “sécurisés” (?) par les dispositifs habituels des services informatiques de l’université mais je préfère faire comme si je ne pouvais compter sur personne d’autre que moi pour assurer la sécurité antivirus des documents échangés.

Donc dans les faits il va circuler du fichier divers tous formats qui va aller se loger dans un dossier stock_fichiers , je pensais tout bêtement à faire un scan régulier de ce dossier via clamav et une tâche cron avec suppression automatique des fichiers infectés mais Auriez vous une idées pour faire en sorte que les fichiers uploadés soient scannés et refusé/détruit avant d’arriver dans le dossier concerné ?

En espérant avoir été clair .

PS : Dans la mesure où c’est plus du conseil et de la discussion que du véritable support , j’ai préféré ouvrir mon post ici plutot qu’en section support . Si la modération estime que sa place est plutot en support , elle peut déplacer :slightly_smiling:

#2

Je en fais pas parti de ces gens là, mais je ne permettrais pas la connexion par mot de passe sur le serveur SSH.

#3

ça, ç’est déjà prévu :wink:

#4

Ma question est si mal posée qu’elle n’attire aucun conseil :blush: ?

#5

Non, disons que la question à été traitée; heureusement, c’est centralisé sur le wiki maintenant…

Dans l’ordre:

iptables: isalo.org/wiki.debian-fr/ind … lifi%C3%A9 C’est simple et efficace (Attention de te laisser un accès à SSH avant de tout bloquer…)
sécurisation du serveur: isalo.org/wiki.debian-fr/ind … urit%C3%A9
sécurisation de apache: isalo.org/wiki.debian-fr/ind … er_Apache2

Et bien sur portsentry qui est redoutable contre les scans de ports: isalo.org/wiki.debian-fr/ind … Portsentry

J’ai appliqué ces recettes à mon dédié, et franchement je suis content du résultat…
Attention de ne pas céder à le tentation du trop sécuritaire… Loreleil en a fait les frais… :wink:

#6

Salut,

Pour le scan antivirus à l’upload… php-clamav.sourceforge.net/
Je n’ai jamais essayé, apparemment, il faut juste ajouter à ton php le code clamav.

Le mieux est l’interdiction des fichiers potentiellement dangereux… :wink:

#7

D’ailleurs,
Au sujet de php-clamav un retour serait le bienvenu… :wink:

#8

Pour le moment je n’ai ni les compétences ni le temps pour tester php-clamav malgré son intérêt :wink: … J’y reviendrai plus tard

Donc en matière d’antivirus j’ai pour le moment choisi de scanner les dossiers de dépôt de fichiers … une suppression d’élément est non bloquante pour le fonctionnement de l’outil donc sans problème pour les utilisateurs.

Sinon pour le reste , outre la sécurisation de ssh déjà faite , Là j’en suis à Apache avec les sécurisations de base du tuto du wiki que j’appliquais déjà en partie et l’activation de mod_evasive. Je vais bientôt passer à la sécurité générale réseau avec iptables ou un autre outil ( shorewall ) et portsentry.

Enfin , je vais finaliser ma stratégie de sauvegarde et le plan de reprise assorti … vu que je travaille sur un VPS , j’ai toujours la “béquille” des snapshots de VM mais je vais tâcher de faire le travail correctement jusqu’au bout quitte à faire :slightly_smiling:

#9

Je en fais pas parti de ces gens là, mais je ne permettrais pas la connexion par mot de passe sur le serveur SSH.[/quote]

Pour la sécurisation du ssh la premiere chose est de changer le port du ssh donc ne pas utiliser le port 21 + fail2ban pour bannir les ip voulant entrer en force

Fail2ban permet aussi de sécuriser la partie apache, ftp, email etc… en virant les curieux.

Enfin, un iptable bien torché qui n’ouvre que les ports dont on a reellement besoin.

#10

21 v’la les keufs! :005

Minus 1 ? :wink:

#11

21 v’la les keufs! :005

Minus 1 ? :wink:[/quote]

j’espere aussi que c’est une faute de frappe … :005 :005 :005

#12

21 v’la les keufs! :005

Minus 1 ? :wink:[/quote]

j’espere aussi que c’est une faute de frappe … :005 :005 :005[/quote]

Oups :whistle:

:033

faute de frappe oui :mrgreen:

c’est le port 22 bien sur :text-imsorry:

#13

Mon port ssh n’est jamais le 22. et là je suis passé en identification par paire de clés . Interdiction des connexion par password .

Cette semaine j’ai mis en place le backup via un serveur backuppc. que j’ai du coup découvert avec beaucoup d’intérêt. Je pense que je vais profiter de ce WE pour faire des tests de restauration: soit globale , soit à la demande ( restauration d’un fichier précis à date/heure précise) … j’ai des interrogations sur la méthode à adopter pour faire coïncider l’état de la BDD et du stock de fichiers en cas de restauration d’un fichier unique.

Là je sauvegarde à la fois un dump journalier de bdd réalisé par automysqlbackup mais aussi la BDD complète.

J’en ai profité pour mettre en place un autre serveur de backup en VM sur ma machine à la maison pour faire quelques tests et sauvegarder le serveur de backup en fait :laughing:

J’ai aussi installé munin-node et mis en place la communication avec un grapheur munin sur une autre machine … je ne l’avais jamais fait… Je pense qu’il va falloir penser à adapter le parefeu pour laisser ouvert le port dédié à Munin d’ailleurs

Ce WE je me colle au parefeu … je vais voir si le fais via iptables à l’aide du wiki ou via shorewall par exemple. Après je ferme le tout avec des passwords classés AAA par moody’s et Finch ocazou et ça devrait bien le faire.

Bref , c’est bien intéressant :slightly_smiling: