Joris Dedieu a écrit 1610 commentaires

Tout est dans le titre :
http://fr.wikipedia.org/wiki/Crontab

Mais plutôt que d'utiliser une pâle copie, autant utiliser l'original (http://www.rubyonrails.com).

Sauf que java est déjà utilisé/utilisable en production. Rails pas encore.

Le problème était de remplacer les permissions sans remplacer les fichiers.

Bonjour,
Pourquoi faire si compliqué ?

Tu met les répertoires en 750 ou 755 et les fichiers en 640 ou 644.

find /home/moi -type d -exec chmod 750 {} \;
find /home/moi -type f -exec chmod 640 {} \;

Il restera les exécutables. Tu peux travailler avec des patterns :
for i in pl sh py rb
do
find /home/moi -type f -name "*.$i" -exec chmod +x {} \;
done

Pense aussi a rediriger les sortie 2 >&1 vers un mail ou un fichier :)

En même temps un grep dans les access_log ça mange pas de pain. Même s'il n'a pas envie de chercher plus loin, c'est déjà ça.

Sous FreeBSD, ça se fait avec limits/ulimit et login.conf . Il faut aussi régler le securelevel a au moins 1 et utiliser sysctl.conf pour limiter quelques valeurs [1][2].

Sous Net/OpenBSD, il y a aussi systrace[3] qui permet de faire de grandes choses.

Sous Linux comme dit plus haut, il y a ulimit et bien sur selinux et grsecurity que je connais moins bien.

Dans tout les cas il te faut :
- un moyen simple d'identifier les processus (par exemple avec un uid distincte par tâche : pour le serveur web, pour php, pour la compil en C, pour l'execution ... Les ACL permettent de bien gérer celà.

- des quotas disques (pour éviter les écritures de fichier récursives ou les cat /dev/zero ... ).
- un firewalling sur le sortant pour éviter l'ouverture de socket illégitimes.

Il ne faut pas négliger les outils simples avec par exemple un cron qui fait :
- si un processus de tel utilisateur dure + de n minutes ou prends plus de n ressouces cpu (man ps) alors kill $p ; sleep 5; kill -9 $p

[1]http://www.freebsd.org/doc/en/books/handbook/users-limiting.(...)
[2]http://wiki.gcu.info/doku.php?id=freebsd:sysctl_avance&s(...)
[3]http://www.unixgarden.com/index.php/securite/systracesysjail

T'es pas fou ? Tu ne peux pas en faire un mutualisé :

- un serveur sur lequel dotclear2, joomla, gallery ... sont inutilisables sans un travail poussé d'installation et de personnalisation.
- un serveur qu'il faut rebooter pour faire des mises à jour de sécurité ou un fsck et donc avec un downtime *relativement" important.

C'est plutôt la config grand comptes avec audit de sécurité tout les 6 mois :)

Je ne vois pas ce qu'il y a de délicat à ça.
Il faut réduire le path, les ressources, et le temps maximal d'exécution.

Si tu as une machine avec des comptes en ssh. Chacun peut compiler et exécuter ce qu'il veut. Ca ne pose pas de problème particulier de sécurité. Il suffit de limiter les ressources de chaque utilisateurs. Cela se fait au niveau de l'OS.

Tu vérifie périodiquement qu'un process ne soit pas en train de dépasser les bornes et de le tuer via un cron ou autre.

Mais là, il s'agit d'utilisateurs identifiés dont tu peux surveiller l'activité et suspendre les comptes.

Ce qui est critique, c'est l'aspect web. Parce que justement tu ouvres ta machine et donne la possibilité a quelqu'un d'accéder aux ressources sans être identifié au sens unix du terme ou en usurpant une identité.

Après il y en a toujours pour croire que d'afficher /etc/passwd, faire des uname -a pose un problème de sécurité.

Moi ce que je crois c'est que tu vas avoir deux types de problèmes :
- les erreurs de code type fork bomb
- les tentatives d'intrusions et d'installation de daemons.

Pour le premier aspect l'os bien configuré sait bien géré ça tout seul.

Pour le second aspect, la réponse doit être globale au niveau de ton code, de l'os et du serveur web et c'est ce que je proposais tout à l'heure.

Mes deux cents

J'ai oublié :
pour php :
- allow_url_fopen off
- register_globals off

pour apache :
_ AllowOverwrite None


L'installation d'un ids (snort) est également indispensable.


Tout cela n'est bien sûr qu'un aperçu de ce qu'il y a a faire pour sécuriser une environnement.

En fait n'importe quel serveur Apache/Php, permet d'uploader son code et de le compiler. Surtout quand ils sont bien développer friendly :) Mais c'est un autre débat.

Pour sécuriser un serveur, il y a de nombreux outils. Le chroot en est un, mais il ne faut pas croire que c'est magique.

Déjà dans php, il y a un certain nombre de mécanismes de sécurité intéressants :
- openbasedir
- safe-mode
- limitation des ressources (memory_limit, max_execution_time)...
- interdiction de certaines fonctions (fsockopen pfsockopen..)

Pour apache :
- il faut des Timeout courts
- il faut qu'il soit exécuté par un utilisateur sans shell.
- il faut installer et paramétrer mod_security.

Au niveau réseau.
- Il faut tout interdire en entrée et en sortie. Puis juste autoriser le minimum pour que son appli fonctionne.
- Il faut détecter les paquets pourris et éventuellement bannir les IP en cause (quoique).
- Il faut surtout utiliser des ports atypiques pour les services annexes (ssh entre autre)

Au niveau système de fichier :
- il faut que / et /usr soient en lecture seule.
- il faut que tous les utilisateurs aient des quotas sur les partitions sur lesquelles ils sont susceptibles d'écrire.
- il faut que toutes les partitions (/tmp /var /home) ou rien ne doit être executé soient montées en noexec

Au niveau des utilisateurs:
- il ne faut pas que les utilisateurs qui n'en ont pas besoin aient un shell valide et que les autres aient un shell le plus limité possible.

- il faut définir (si le système le permet ) des limites en ressources basses pour chaque utilisateurs (man limits).

Au niveau de L'OS,
Il faut interdire :
- les changements de règles de firewalling
- les passages de root vers noyau (chargement de modules ...)

Puis il faut surveiller. Traquer les process au comportement anormal, débusquer les finteux, les spammeurs, les spammés. Bref administrer la bête. ..

Je pense surtout qu'ils veulent utiliser les traductions pour faire des moulinettes automatiques à traduire les phrases types, ou proposer des traductions types ...

Du coup la licence bsd s'impose.

Bon c'est pure spéculation. Je dis ça, j'ai rien dit :

We've chosen the BSD license because it’s universally compatible with projects that use other licenses.


Il me semble bien quand même qu'ils suggèrent que les traductions pourraient être utilisées pour un projet autre que l'original.

Bon, je sort ---------------->

Visiblement Mandriva perd de moins en moins d'argent.
Et c'est plutôt encourageant
http://www.mandriva.com/enterprise/fr/actualite-financiere/r(...)

Maintenant, c'est vrai qu'il manque toujours ce buzz avec les entreprises qui ferait décoller.

Pourtant avec mds et pulse, y a vraiment de quoi.

Si apache ne sert pas l'index qui est dans /var/www/html
C'est que :
_ il n'y en a pas (d'ou le 404)
_ il ne va pas le chercher là (un include dans ta conf ?)
_ il n'est pas reconnu comme un index (Directive DriectoryIndex)
_ L'acces est interdit (droit unix, Deny From All dans un .htaccess ou un fichier include dans ta conf)

Donc que donne :
ls -la /var/www/html/ est la premiere des choses à voir.
La seconde est de tout commenter dans ta conf pour voir quand ça marche et dans ça ne marche pas.

C'est pas sans espoir.
La subtilité, c'est qu'il ne faut pas en parler aux informaticiens, mais aux commerciaux.

Je pense qu'il voulait dire - non disponible sous linux

Trafic soutenu, petite config, FreeBSD 7 est ton ami

->
Mes deux cents

cp /my/procmailrc.template ~$user/.procmailrc
sed -i '' -E s/box1/$user/g ~$user/.procmailrc ou encore avec perl :
perl -i -pe 's/box1/$user/g' ~$user/.procmailrc

A mon sens la meilleure solution est d'utiliser ~ dans ton .procmailrc

SHELL=/bin/sh
PATH=/usr/bin
DEFAULT=~/mail/
MAILDIR=~
LOGFILE=$MAILDIR/.procmail.log

INCLUDEDIR=~/.procmailrc
MAILCOPY=~/copymail/

Orange met ça en place et sans prévenir ses clients :)

Pouvoir déployer des belles applications basée sur un framework ultra sympa comme Rails aussi simplement qu'une banale appli PHP, saykewl :). Aucune raison de pas switcher.

C'est trop gros, je peux pas laisser passer ça.

Mais quand tu veux gérer finement des droits sur des dizaines de répertoires avec autant d'utilisateurs, que tu as par dessus des impératifs sécurité (du style pas de shell pour apache), qu'il faut envoyer des mails qui n'arrivent pas directement dans les boîtes spam et que tu travailles avec des devs qui sont outré parce que tu refuse qu'ils fassent des exec à tout va et que de toute façon leur appli elle marche bien sur leur easyphp. Quand tu t'encaisse 18 millions de requêtes par jours, que tu est réveillé la nuit parce qu'un abruti à réussie à coder une redirection 301 récursive ou qu'Apche 2.2 (ah t'avais dit qu'il fallait la 1.3.41) c'est vautré parce qu'un cron a fait un graceful alors qu'arrivait un trop gros post ... ben figure toi que même php c'est pas simple.

L'avantage de de montgrel / BDD / frontal web, c'est que c'est un modèle 3 tiers propre et scalable. Qui t'évite justement les affres d'un mod_php tout en un.

Mes deux cents

Bonjour,
Pour ton besoin simple, je ne comprends pas pourquoi tu n'utilise pas la réplication MySQL5 qui est très simple à mettre en oeuvre et très stable.

Basculer du mode esclave au mode maitre, la resynchronistion ... c'est vraiment facile.

A mon sens MySQLCluster est une tentative pour répondre aux problématiques de performances avant tout (et pour lesquelles d'autres serveurs que mysql sont peu être plus adaptés). Ce qui n'est pas ton cas ici.

Ou find

Bonjour,
Plusieurs choses par ailleurs :

- Les variables d'environnement sont réduites dans le contexte d'un cron dont exporter un path n'est pas une mauvaise idée même si l'usage est plutôt d'invoquer des commandes par le chemin absolue.

- En redirigeant la sortie d'erreur vers ton fichier de log, tu devrais avoir quelque chose de plus verbeux (tu sais les histoires de 2>&1)

Je travaille sur des des machines à plusieurs millions de requêtes par jours qui font des access log.

On s'en sert pour débusquer les scripts plantés et toute sorte d'attaques (upload de script malicieux, utilisation de formulaires pour spammer) ...

Quand tu ne maîtrise pas le code des sites que tu héberge, il n'y a guère d'autres solutions qu'une analyse rigoureuse des access_log, maillog et ton ami netstat.

Par ailleurs, j'ai déjà eu a répondre a des requêtes judiciaires. Un gros grep leur suffit. Ils ont des gens capables d'analyser ça.

>> bzgrep -i viagra access_server.Tuesday.bz2 | wc -l
31