Re: [FRsAG] : commandes ssh resteintes
Le 12 janv. 2013 à 12:22, JC PAROLA a écrit : Je me posait la question de savoir si des systèmes MAC (Mandatory Access Control) comme SELinux/AppArmor ou les MAC de FreeBSD n'était pas prévu pour ça. Avec un Framework MAC on traiterait du coup le pb du ssh user mais aussi d'autres points.question ouverte. Je me contenterai de répondre que question charge de travail, SELinux se pose là, dès qu'on sort des sentiers battus (a.k.a. ce qui est pré-packagé) Pour ainsi dire, sa lourdeur n'a d'égal que son efficacité. Florian Maury ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] : commandes ssh resteintes
Le 10 janv. 2013 à 23:10, Emmanuel Thierry a écrit : De la même manière que la majorité des gens je suggérerais un chroot ssh (à l'intérieur desquels tu bindes les dossiers nécessaires à la bonne exécution de leurs applis (/usr, /bin, /sbin, ...). Bonjour, J'ai lu pas mal de choses qui m'ont fait sursauter, d'un point de vue sécurité lors de cet échange. Alors traitez moi de parano :) Pour autant, je réagis sur celui-ci qui est un fantôme bien connu, et commun : si vous bindez des répertoires (bind comme dans mount --bind), à fortiori des binaires, de l'extérieur d'un chroot à l'intérieur de celui-ci, vous créez un super tremplin pour l'évasion dudit chroot : une élévation de privilège à l'intérieur du chroot permettra de réécrire les binaires, qui seront tout autant affectés à l'extérieur du chroot... et plouf, le beau reverse-shell :) Concernant le problème plus général : compte tenu de la complexité de sécuriser un accès SSH, et à fortiori shell (penser à toutes les options de ssh, et de tous les programmes que l'utilisateur pourra lancer, loguer toutes les commandes sans que ce soit aisément contournable...) , je dirai que c'est une mauvaise idée d'en ouvrir un, tout court. Si je devais faire cela, je référencerai de manière exhaustive les besoins des clients (qui ne doivent pas être très nombreux, finalement...), et je ferai un menu web (accessible uniquement après une authentification forte, sur le backoffice de l'utilisateur) avec des commandes pré-générées et dont les arguments ont été correctement échappés/encodés pour éviter l'injection de commandes OS. Ces commandes seraient alors exécutées avec le droit de l'utilisateur en question (plusieurs techniques possibles...). Dans le doute, je m'inspirerai de ce qu'ont fait les grands du mutualisé, qui s'en tirent pas mal, sans donner d'accès shell. Un dernier point : il ne faut pas donner aux utilisateurs juste un répertoire qui est directement le docroot, lors des accès FTP. C'est pourri, en terme de sécurité. Toutes les bonnes pratiques conseillent de ne mettre dans le docroot que ce qui a réellement besoin d'être accessible par les internautes (oui, je sais, bcp de framework PHP eux mêmes ne le font pas... don't get me started on this, PHP, sécurité, vendredi, tout ça...). Les astuces à base de .htaccess (valable uniquement pour Apache, et je pourrais citer bon nombre de techniques permettant de prendre la main sur un serveur À CAUSE des htaccess ; d'une manière général : désactivez ces saloperies), ou de petites lignes en haut de chaque fichier PHP (oubli très facile...) sont en général super pourries. Au moins un niveau en dessous est souhaitable. Pour prévenir l'effacement du répertoire docroot qui vous ferait une erreur lors du redémarrage du serveur web, utilisez une astuce sur les droits systèmes avec le sticky bit ;) Bon courage, Florian Maury ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] cloisonnement des sites sur serveur apache mutualisé
Le 21 déc. 2012 à 22:00, Patrick Proniewski a écrit : On 21 déc. 2012, at 21:19, Mercier, Benjamin wrote: Hello, mpm-itk ? http://mpm-itk.sesse.net/ Oui bonne solution c'est un peu mieux que suPHP et suexec pour les cgi. Merci pour ces réponses rapides. Malheureusement le problème est un peu complexe : de nombreux sites partagent le même vhost. J'ai 40 vhosts pour plus de 250 sites web. Il faudrait que je change de nombreuses choses pour avoir un vhost par site. Néanmoins, c'est une piste et je peux l'explorer, voire la mettre en prod, avant d'avoir un vhost par site. Ça limiterait déjà les dégâts. Je vais regarder ça de plus près. D'après ce que je vois le port FreeBSD correspondant intègre un patch qui permet de gérer un user par path et non seulement un user par vhost. Ça pourrait bien le faire. MPM-ITK sait gérer par Directory aussi :) super alors, je t'avoue que je n'ai pas encore lu toute la doc ;) J'ai écrit un petit mémoire à ce sujet, il y a quelques temps. Il est loin d'être complet, mais je pense que tu devrais y trouver ton bonheur ;) https://x-cli.eu/secfiles/lamp.pdf A+ Florian Maury ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] cloisonnement des sites sur serveur apache mutualisé
Le 23 déc. 2012 à 20:21, Guillaume Pancak a écrit : avez vous parlé de php-fpm ? Nope :) Comme je l'ai dit, très loin d'être complet. Pour autant, j'ai entendu du bien de php-fpm, mais je ne l'ai pas mis en place personnellement. Dans le papier linké, j'évoque SuExec avec FCGI, mpm-itk, et un reverse proxy avec une instance d'apache par client/application. J'évoque aussi de nombreuses options de sécurité de PHP, et d'Apache, ainsi que quelques petits trucs systèmes autour. Ce n'est pas suffisant pour sécuriser un système, mais ça y contribue ;) ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Vos clients IRC
Le 8 avr. 2012 à 12:26, Manuel OZAN a écrit : Bonjour les sysadmin, Je souhaiterais un petit retour sur vos clients IRC (avantages/inconvénients, killer feature, licence, plateforme, % de productivité perdu...). Ma question est donc simple : Quel clients IRC utilisez-vous actuellement ? Merci pour les chocolats Plop, Le mieux, ca serait encore de demander ... sur le chan IRC de Frsag =) Pour ma part, j'utilise irssi. Ca fonctionne en console, et donc couplé avec tmux/screen et ssh c'est parfait ;) (Il y a une flopée de plugins disponibles en plus). Un troll circule sur le fait que ca permet de trainer sur IRC en donnant l'impression de travailler (un terminal avec plein de machins écrits partout, ca fait pro) :P Florian Maury ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Protéger au mieux son serveur http
Le 4 avr. 2012 à 16:49, Julien Escario a écrit : Plus sérieusement, que répondre à ça à part 'ça dépend' ? Ça dépend, ça dépasse (toute ma considération à ceux qui retrouveront la référence). J'ai écrit, il y a quelques mois, un document sur le renforcement d'une architecture mutualisée LAMP sous Debian. Bien que j'ai manqué de temps à la fin, ce qui m'a fait un peu bacler la fin du document, et trancher un peu trop net mon avis (a.k.a. j'ai trollé à fond ; ces avis n'engagent que moi), je pense qu'il pourra peut être en intéresser certains. https://x-cli.eu/secfiles/lamp.pdf Cheers, Florian Maury ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] DNS Timeout
Le 3 févr. 2012 à 10:57, Hugo Deprez a écrit : Bonjour, j'utilise deux serveurs bind9, ce sont des resolver. Un est master et un slave dans le sens où le slave récupère ses zones via le master. Effectivement j'avais pensé à faire une VIP, mais d'après moi le fonctionnement même de DNS intègre déjà cette haute disponibilité (dans resolv.conf deux serveur dns sont spécifiés, dans windows aussi). Donc je ne comprend pas pourquoi j'ai ce comportement. J'ai essayé de le reproduire sur un environnement de test en droppant le flux vers le DNS primaire mais je n'ai pas le même comportement. Bonjour, Si il y a des zones à répliquer alors ce ne sont pas des résolveurs, mais des serveurs faisant autorité sur des zones (authoritative servers *sigh traduction*). Ou alors ce sont des serveurs qui font les deux :o) Merci à Bind d'avoir permis ce genre de confusion :o( Je ne pense pas que les stub-resolveur fassent de la requête simultanée sur l'ensemble des résolveurs. Ils appellent l'un d'entre eux, si ca ne répond pas (timeout), ils appellent le suivant, et ainsi de suite. J'imagine qu'ils doivent en revanche changer la priorité des serveurs de récursion si l'un d'entre eux fait trop de timeout durant une période donnée... si ce n'est pas le cas, il faudrait y réfléchir :o) Le délai de timeout avant abandon d'un résolveur pour aller requérir l'avis du second (merci à Microsoft pour encore plus rendre cela confus avec la notion de serveur de résolution primaire et secondaire...) est assez probablement ce qui cause les lenteurs... Pour les app web qui plantent, ca ne m'étonne pas tellement... si la grande majorité des devs web savaient coder, ca se saurait (on est trolldi :o) ) ! Une appli ne devrait pas planter (500) parce qu'un récurseur met du temps à répondre. Il y a un problème d'implémentation à revoir, même si tu trouves une solution pour ton problème de récurseur, m'est avis. La solution du heartbeat est effectivement possible. La solution de raccourcir le délai de timeout comme tu l'as fait avec des options du stub-resolver est possible également (mais il faut la maintenir... à voir si on ne peut pas distribuer ces options avec le DHCP). Peut être que ton essai en environnement de test a utilisé le cache local de ta machine et n'a pas interrogé les résolveurs : essaie de faire un ipconfig /flushdns / dscacheutil -flushcache / nscd -i hosts et de monitorer ton réseau pour vérifier que la requête est réellement faite (cible LOG sous iptables ou plus simplement tcpdump 'port 53') Bon courage. Cordialement, Florian Maury ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Ipv6 interne et Ipv4 externe ?
Le 5 déc. 2011 à 14:20, cam.la...@azerttyu.net a écrit : Bonjour à tous Je me demande si cela peut avoir un sens d'avoir son infrastructure interne en full ipv6 et monter une passerelle ipv4 pour que l'exterieur accède aux services publics ? Dans le cas où cela aurait un sens, y a t'il un moyen simple d'avoir son bloc ipv6 indépendant de son fournisseur d'accès ? Bien à vous Km Bonjour, Il me semble qu'il y a eu une présentation aux JRES à ce sujet. J'ai jamais réussi à la regarder en entier à cause de petits soucis de débit chez moi... https://conf-ng.jres.org/2011/planning.html 57 : Comment vivre avec un réseau IPv6 pur Cordialement, Florian Maury ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Plusieurs instances Apache sur un même serveur
2011/4/21 Aurélien Leicknam aleick...@gmail.com: Salut, La commande qui va t'aider à créer l'environnement chrooté sous Debian c'est debootstrap. Salut, Heu c'est un peu violent debootstrap pour un simple chroot : debootstrap ca te génère un système debian complet, standalone ! Il vaut mieux regarder du coté des scripts qui fabriquent des jails en analysant les dépendances avec ldd. Il reste alors à faire les nodes pour un /dev et hop :) Cordialement, Florian ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] interface web pour syslog
2011/3/22 Clément Guivy clem...@guivy.fr: Bonjour, RTFM :) http://linux.die.net/man/5/rsyslog.conf syslogfacility the facility from the message - in numerical form syslogfacility-text the facility from the message - in text form syslogseverity severity from the message - in numerical form syslogseverity-text severity from the message - in text form Cordialement, Florian MAURY ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] [MYSQL] - Erreur Out of Memory
Bonjour, Sans répondre à la question, ca serait pas plus simple de faire une copie directe des fichiers de la base ? Non parce que envoyer 4Go à l'import, ca va être juste long, error-prone et tout et tout... Sinon, tu peux tenter de faire ton dump en ne mettant pas les extended insert pour limiter la taille d'une même ligne de ton dump, mais va grandement augmenter le temps d'insertion... c'est pour ça que je serai toi, je m'emmerderai pas et je copierai les fichiers de la base directement... en particulier si c'est du MyISAM (LOCK, copie, UNLOCK) et zou, c'est plié. Bon courage, Florian ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Exemple de flux RSS malveillant ?
2011/1/24 Nicolas Steinmetz nsteinm...@gmail.com: Hello, Pour faire plaisir à mon cher RSSI, je voudrais valider le comportement d'une application vis à vis des flux RSS qu'elle consulte. La récupération du flux est faite par le serveur et non au niveau du client. Mon RSSI ne souhaitant pas par défaut autoriser l'accès internet à ce serveur, je dois avancer sur la capacité de la solution à ne pas être comprise si par hasard un utilisateur mettrait un flux RSS malveillant... Existe-t-il des ressources de ce type sur internet ? Le but étant de pouvoir déposer ses flux RSS sur un de nos serveurs en interne et tester l'appli en mode isolé. Si vous avez la même chose pour des gadgets opensocial, je suis aussi preneur. S'il s'avère que l'appli nettoie suffisamment le code qu'elle injecte, je pourrais peut être faire réévaluer cet accès internet. Sinon ce sera tant pis pour les utilisateurs. Merci d'avance, Nicolas -- Nicolas Steinmetz http://www.steinmetz.fr - http://nicolas.steinmetz.fr/ Salut, Je pense que la question est mal posée. Tu trouveras des exploits pour tous les programmes qu'il y a un intérêt à hacker, et même pour ceux qui ne présentent pas particulièrement d'intérêt. Compte tenu qu'on peut considérer qu'il existe des failles dans tous les programmes (quasi un axiome, même si DJB s'est démené pour essayer de prouver le contraire , mais on est pas vendredi :p), si ton serveur exécute un programme pour récupérer des RSS, des MP3, ou peu importe, il existera un jour ou l'autre des exploits pour poutrer ton programme. Sans nous dire quelle application tu comptes utiliser, sans nous donner la version, et sous réserve qu'il y ait des spécialistes en sécurité applicative ici qui comptent y passer du temps, ta seule piste, c'est le history record de l'application que tu comptes utiliser, et éventuellement un fuzzer, parce que chaque application est différente, chaque compilation peut être différente, et donc chacun exploit doit être différent. Autrement dit, si ta question est bien Il y a t il des RSS malveillants in the wild ?, je répondrai : s'il n'y en a pas encore, il y en aura s'il y a un gain quelconque à avoir (qui peut n'avoir rien à voir avec ta société, comme l'envie de se faire de la publicité pour un étudiant). Autrement dit, je pense que ton RSSI pourrait bien t'avoir servi une réponse du genre va te faire voir déguisée, à moins qu'il ait vraiment le budget pour faire faire une analyse du logiciel en question par des experts :) Amicalement, Florian MAURY ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] passerelle SSH proxy / gateway
2010/12/17 Pierre-Henry Muller wall...@morkitu.org Bonjour, Je cherche à faire une passerelle ssh comme point d'entrée unique à un réseau. Le but est que tous les accès extérieurs passent par cette machine. Une fois connectée la personne peut se connecter sur les machines dont elle dispose des droits sans connaître les mots de passe des autres serveurs. J'avais croisé des projets y a quelques années, à présent tous les résultats pointent vers la solution de Wallix AdminBastion. Il y avait pourtant des alternatives, j'espère qu'elles ne sont pas mortes. Et vous comment centralisez-vous vos accès distants? Salut, Si le besoin est aussi simple, autant faire un petit programme (e.g. bash ou python) sous la forme d'un menu, qui liste les machines auxquelles le mec peut se connecter, et le laisser entrer 1, 2, 3 suivant qu'il veut se connecter à la machine 1, 2 ou 3 dans le menu. Seules précautions : un script pas troué, et un catch des signaux comme INT, QUIT, et le ctrl+Z pour prévenir qu'il mette en pause ton script ^^ Ensuite, tu leur colles ca en shell, et zou :) Pour la connexion aux autres serveurs sans mot de passe, il suffit de faire des échanges de clés SSH entre chaque user de ta passerelle et les serveurs auquel il a le droit de se connecter. -- Florian MAURY ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsaG] Technos utilisées pour les images disque s en environnement virtualisé KVM
Bonjour, Simple question autour de la virtualisation avec KVM : comment partagez vous les disques entre plusieurs systèmes hôte, afin de pouvoir faire du live-migration ou du start on failure (équivalent Vmware HA) ? NFS ? DRBD ? ISCSI ? autre système de partage de fichier ? Si vous disposez d'un SAN, prenez vous le pari d'open-iscsi, ou montez vous un opensolaris à coté qui repartage après en NFS/whatever ? Je pose cette question saugrenue car il me semble avoir entendu dire que l'implémentation de iscsi sous solaris est plus stable (est ce vrai ?) Par ailleurs, comment faites vous pour obtenir du thin provisionning ? Utilisez vous cette astuce :http://www.njcrawford.com/2010/01/21/growing-a-kvm-raw-hard-drive-image-file/ ? J'ai rencontré des problèmes avec cette méthode en cas de sauvegarde avec compression puisqu'au moment de la décompression la copie prend la place prévue et non la place thin provisionnée. Peut etre il y a t il des options de compression que j'ai raté. Le format qcow2 semble permettre ce genre de chose, mais est visiblement, d'après la documentation de KVM incompatible avec virtio, faisant perdre des performances. Merci. Florian MAURY ___ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Re: [FRsaG] Technos utilisées pour les images disque s en environnement virtuali?==?UTF8?Q?v irtualisé KVM
2010/8/6 Fabien VANEENOO frsag.mailing.l...@kathryl.net: Tu as oublié de préciser : fibré (dm multipath tout çà tout çà) Mais c'était dans le cas d'images disques pour Xen Je crois que ca ne peut pas s'appliquer a KVM, il lui faut impérativement du LVM si je dis pas de bétise ? Merci pour vos avis. Continuez à envoyer vos retours d'exp (que ce message ne vous stoppe pas) puisque visiblement il n'y a pas de concensus établi. Non, non, on peut utiliser aussi des fichiers. Pour ce qui est du thin provisionning, je viens d'apprendre que l'astuce à base de dd, ca s'appelle des sparse files, et qu'il y a plein d'outils qui peuvent le prendre en charge, sous peine qu'on mette les bonnes options. Il me manquait la dénomination officielle pour trouver tout ce qu'il me fallait :) Donc problème résolu, c'est ce dont j'avais besoin ! J'en arrive donc à la question suivante, justement : dans la mesure où l'on peut faire du thin provisionning avec des fichiers mais pas avec LVM (qui alloue tout l'espace de volume d'un coup, même si on peut le grow après coup ; et que du coup on ne peut pas provisionner plus grand que la taille du/des disques physiques) il y a t il un intérêt quelconque à utiliser LVM ? Florian MAURY ___ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Re: [FRsaG] Gestion de téléchargement de fichier - méthodes
2010/8/5 Julien Palard fr...@mandark.fr: 2010/8/5 Sky Gunning sky.gunn...@gmail.com: Les fichiers sont stockers sous la racine public_html (sécurité oblige hein) Pourquoi ne pas les stocker dans un sous dossier de public_html justement, et y accéder directement (apache saura très bien faire pour le coup) dans un dossier avec un .htaccess contenant un SetHandler default-handler ? Tu peux bien sur empêcher le directory listing, et tu peux éviter que les gens essayent de deviner les noms des fichiers en les mettant chacun dans un dossier au nom aléatoire. (mais sans renommer le fichier, l'url est plus cohérente) Security Through Obscurity Only. Pratique à bannir absolument. Florian MAURY (X_Cli sur le chan ; merci pour le hilight Sky_G) ___ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Re: [FRsaG] Analyse de logs
2010/7/21 Greg greg-fr...@duchatelet.net: Un serveur syslog-ng central, tous les serveurs apache transmettent à celui-ci. Bonjour, Il me semble que la version opensource du syslog-ng peut perdre des logs également en cas de perturbation réseau entre le syslog sender et le syslog-ng central. De plus, envoyer ses access log apache sur syslog-ng, ca veut dire forker un logger par ligne de log (seulement si on est en préfork, d'après ce que j'aurais appris hier, sans avoir vérifié), ce qui a pour conséquence sur un site avec un peu de charge de faire monter le load de ta machine à des chiffres qu'on voit rarement (ou qu'on préfèrerait voir rarement). Personnellement, la centralisation des logs, je l'ai faite avec des access log en fichiers classiques, un logtail2 pour récuperer les nouvelles lignes, toutes les 10 minutes, la mise dans un fichier à part de ces nouvelles lignes, un envoi automatisé des nouveaux fichiers vers un serveur (par ftp ou rsync, peu importe) et la refusion de tous les fichiers ainsi récupérés, depuis de multiples serveurs, avec un tri par date des lignes, pour retrouver une consistence. Avec cette méthode, je suis sur d'avoir toutes mes lignes, triées, et sans un load monstrueux. Par contre, ca demande sérieusement de l'huile de coude, parce que c'est que du bash :p Florian MAURY ___ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
