Svchost et port 443

On Thu, 09 Sep 2004 08:03:00 +0000, Michel Claveau - abstraction
meta-galactique non triviale en fuite perpetuelle. wrote:

Non. Démonstration "a contrario" : soit un trojan qui écoute un socket. Un
parefeux peut être configuré pour fermer le port concerné. On aura donc un
port fermé, et un logiciel qui écoute ce port. Donc un logiciel qui écoute
un port n'est pas ce qui caractéristique d'un port ouvert.

Mélange de termes. Relire les "TCP/IP Illustrated" ...

De toute façon, la notion de port ouvert ou fermé ne fait pas partie de
TCP/IP. C'est une notion illusoire. Il faudrait parler de niveau d'écoute.

Dommage, il manque une ligne pour le GNU !

En milieu professionnel, on n'installe pas ce genre d'outils, qui posent
beaucoup trop de problèmes. Les administrateurs n'ont pas de temps à
perdre à reconfigurer à l'infini ces trucs, alors qu'un parefeux
centralisé, et téléadministrable protège au moins aussi bien, et
avec BEAUCOUP moins de problèmes.

"NAI ePO", ça vous dit quelquechose comme produit d'administration
centralisée de pare-feux personnels ? Ca macrhe très bien pour des
millers de postes ...

En plus, là où il y a eu des tentatives d'installation, on a souvent
vu les utilisateurs désactiver ces PF, afin de pouvoir continuer à
travailler normalement.

Si les utilisateurs ont un accès de niveau Administrateur, il y a de plus
gros problèmes à résoudre que la désactivation des pare-feux locaux.

Ce qui est gros, c'est que tu n'arrives pas à faire la part des choses,
entre les risques réels et les risques supposés.

Pas trop vexé, Cédric ?
:)


Nicob

On Thu Sep 09 2004 at 10:03, Michel Claveau wrote:

Pour qu'un port soir ouvert, il faut qu'il y ait un programme en écoute
dessus. Sinon, il est fermé. Un peu de lecture sur les principe de base
TCP/IP ne vous ferais pas de mal.

Non. Démonstration "a contrario"

Rappel de logique de base :
si P => Q, alors non Q => non P
Mais pas l'inverse.

Cédric disait :
Si le port est ouvert, il y a un programme qui écoute.
On peut en déduire (ce qu'il a dit d'ailleurs) :
s'il n'y a pas de programme, le port est fermé

Vous dites :
si un programme écoute, le port peut être fermé.
Et vous en déduisez :
Si le port est ouvert, il n'y a peut-être pas de programme qui écoute.

Ce qui est _archi_ faux.

Je passe sur la suite, qui est un superbe ramassis d'âneries du même
tonneau.

Bonsoir !

Mon serveur web, c'est un développement maison.

Langage : Python, et librairie, standard, asyncchat.
Type de programmation : procédurale
Taille du code source : 13 286 octets, dont 6424 octets de commentaires.
Analyse des requêtes HTTP : par les expressions régulières.
Gestion des directorys : pas gérés, donc erreur 404
Pages dynamiques et des bases de données : par utilisation de Paradox
(dialogue par OLE-automation. Mais les pages dynamiques ont une logique
"côté serveur" (le code source n'est pas enregistré dans les pages, ou des
fichiers textes ; pour cela, c'est différent de PHP, ou JSSS).
Nb de connexions simultanées : plusieurs. C'est difficile à dire, car j'ai
élaboré une logique de pages, sous forme de formulaires, dans laquelle
chaque page contient sa logique de cheminement/données, via des champs
cachés. Ainsi, chaque page est autonome, et je n'ai pas à m'occuper de la
persistance de la connexion. Un internaute qui met son poste en veille, puis
le remet en activité plusieurs heures après, peut très bien reprendre la
navigation en cours. En plus, les connexions sont traitées séquentiellement,
et pas en multi-thread. Si 40 internautes demandent une page strictement en
même temps, le dernier peut attendre jusqu'à 10 secondes (car le temps maxi
pour servir une page est de 0,25 seconde).
Toute requête HTTP qui ne respecte pas strictement le schéma prévu est
rejetée (erreur 400). Cela rend quasi impossible l'entrée dans le site
autrement que par la page index.htm
CGI : non
MOD : non
PHP : non
ASP : non
Commandes gérées : GET et POST, uniquement (en plus, elles sont traitées de
la même façon).
Journal des connexions/logs : non (affichage seulement)
Résolution des noms : non (trop lent)

Comme il est petit, je le fais tourner sur un vieux serveur NT-4 à 400 MHz.
Sur ce serveur, tous les services et logiciels sont désactivés, sauf : le
serveur web, un serveur de news (hamster), un serveur de télépersistance.
J'ai vérifié avec un scanner : seuls 5 ports répondent, correspondant bien
aux logiciels qui tournent.

Je pense qu'il est bien sécurisé, parce qu'il ne fait presque rien. S'il y
a un bug, le serveur 'saute' la requête HTTP en cours, ou la page en
préparation, et effectue une continuité sur le traitement suivant. Si l'on
envoie 10 000 requêtes sur le serveur, il traitera des requêtes, les unes
après les autres, sans succomber au moindre DOS (puisque qu'il ne gère pas
vraiment les connexions) ; par contre, pas mal de requêtes tomberont en
time-out ou niveau du routeur et/ou du réseau. Bref, dans ce cas, beaucoup
d'internautes n'auront plus accès aux pages. Mais, dès que l'attaque
cessera, l'accès reviendra (au time-out près).

Bien que ces informations soient succinctes, j'espère avoir répondu
(grossièrement, je m'excuse) à ta question.

Bonne soirée
--
Michel Claveau

On 09 Sep 2004 21:14:07 GMT, Michel Claveau :

Si l'on
envoie 10 000 requêtes sur le serveur, il traitera des requêtes, les unes
après les autres, sans succomber au moindre DOS (puisque qu'il ne gère pas
vraiment les connexions)

Si je me connecte à ton serveur sur le port 80, que j'envoie "GET /
HTTP/1.0rn" à raison d'un octet toutes les 20 secondes, j'ai réussi
à bloquer ton serveur pendant 10 minutes ?


--
;-)

Bonsoir !

Un admin qui ne sait pas verrouiller la conf d'un pc ou qui utilise
encore des os dont la conf n'est pas verrouillable n'a rien à faire dans une

entreprise.

Désolé, mais les administrateurs "à la Morel" (de Cointe), qui bloquent
tout, y compris les lecteurs de CD, les claviers et les souris, c'est fini.
Les entreprises préfèrent que leurs utilisateurs puissent utiliser les
ordinateurs.

Les différents vers exploitant les failles netbios ont encore de beaux
jours devant eux avec un tel raisonnement.

Rien à voir : les trames netbios sont parfaitement contrôlables par les
parefeux matériels.

Il faut aussi savoir les paramétrer, ce qu'un vrai administrateur saura
faire.

Il saura le faire, mais n'aura pas le temps. La taille moyenne de mes
clients, c'est cinquante postes. Si un administrateur doit passer une heure
par semaine sur chaque poste, cela lui fera 50 h. par semaine. Plus les
serveurs, plus les imprimantes, etc. etc. Cela va poser un risque de crise
cardiaque à Martine Aubry.
Et, si on parle d'un administrateur pour cinquante poste, cela ne se trouve
pas dans les PME.
En pratique, un administrateur ne doit pas dépasser 10mn par semaine, par
poste utilisateur (et encore, on est dans le borne haute du CIGREF).

Je n'aimerais pas faire partie de vos clients.

Je comprend ; mon objectif premier, c'est la productivité. En fait, j'aide
les gens à travailler plus. La sécurité n'est, selon moi, qu'un outil pour
maintenir cette productivité.
Je comprend, donc, que certains préfèrent travailler moins. C'est votre
choix ; je respecte.

Le cv de Cédric donne plus de poids à ses arguments qu'aux votres, ses
différentes publications en attestent, mais bon, vous pouvez continuer à

considérer que vous êtes plus doué que lui dans ce domaine, c'est juste une
illusion de plus qui tombera un jour prochain.

Son CV est certainement plus honorable que le mien. Ce qui ne veut pas dire
que le mien soit critiquable, surtout quand on n'en sait rien.

Je n'ai jamais dit que j'étais plus doué. Mais seulement qu'il existe
d'autres solutions aux problèmes de sécurité que la facilité des lieux
communs et de la pensée unique.

Eric Masson

@-salutations
--
Michel Claveau
mél : http://cerbermail.com/?6J1TthIa8B
sites : http://mclaveau.com http://bergoiata.org http://ponx.org
newsgroup : news://news.zoo-logique.org/programmation.Paradox
et : éàç`?°çïa&ô|~?§@.µ#'

Bonsoir !

Rappel de logique de base : si P => Q, alors non Q => non P Mais pas
l'inverse.

Je rectifie : on dit que P => Q ; or j'ai montré que _P => non_Q ; dont
la premier proposition n'est pas complète. Elle peut être juste ou fausse
selon le cas. Il y a rupture de discrétion logique.

Cédric disait : Si le port est ouvert, il y a un programme qui écoute.
On peut en déduire (ce qu'il a dit d'ailleurs) : s'il n'y a pas de

programme, le port est fermé Vous dites : si un programme écoute, le port
peut être fermé. Et vous en déduisez : Si le port est ouvert, il n'y a
peut-être pas de programme qui écoute. Ce qui est _archi_ faux.

NON, j'ai dit qu'un un logiciel qui écoute un port n'est pas ce qui
caractéristique un port ouvert (éventuellement, relire mon message
confirmera ce point).

Cela veut dire que la définition d'un port ouvert ne se résume pas au fait
qu'un logiciel écoute ce port. Il ne faut pas me faire dire ce que je n'ai
pas dit.

Je passe sur la suite, qui est un superbe ramassis d'âneries du même
tonneau.

Lorsque quelqu'un se met à utiliser des propos injurieux, j'ai tendance,
soit à répondre sur le même ton, soit à revoir à la baisse mon appréciation
de la personne.



@-salutations
--
Michel Claveau
mél : http://cerbermail.com/?6J1TthIa8B

Le Thu, 09 Sep 2004 22:23:27 +0000, Michel Claveau - abstraction
meta-galactique non triviale en fuite perpetuelle. a écrit :

Cela veut dire que la définition d'un port ouvert ne se résume pas au fait
qu'un logiciel écoute ce port. Il ne faut pas me faire dire ce que je n'ai
pas dit.

Alors c'est quoi qui résume le fait qu'un port soit ouvert ? En gros,
c'est quoi la définition d'un port ouvert ?


--
BOFH excuse #331:

those damn raccoons!

Bonsoir !

C'est bien vu (bien essayé). Mais, comme la requête sera incorrecte (pour
lui), il y aura envoi d'une erreur 400, ce qui ne prend que le temps de la
communication.

Si tu décomposes la requête HTTP, octet par octet, avec un octet par trame
TCP/IP, alors, il va y avoir un problème, car je n'assemble pas plus de deux
trames successives. Je sais, ce n'est pas terrible. Mais, comme le serveur
accepte les trames jusqu'à 4096 octets, et comme sur la totalité des
serveurs que j'ai installés, avec ce logiciel, les requêtes ne dépassent pas
1024 octets, ça roule.

Bref, une requête décomposée sera considérée comme plusieurs requêtes
incorrectes (mal formées), et renverra autant d'erreurs 400 que de trames
reçues.

Si tu envoies une trame par seconde, le serveur traitera les requêtes
correctes, venant d'autres connexions, entre tes trames.

Mais, si tu fais ça 1000 fois par seconde, tu vas saturer le buffer de
trames du routeur. Et, conformément aux normes IP, il y aura suppression
aléatoire des trames dans le buffer. Donc, ça saturera surtout la bande
passante.


@-salutations
--
Michel Claveau

Le Thu, 09 Sep 2004 22:53:27 +0000, Michel Claveau - abstraction
meta-galactique non triviale en fuite perpetuelle. a écrit :

Bref, une requête décomposée sera considérée comme plusieurs
requêtes incorrectes (mal formées), et renverra autant d'erreurs 400
que de trames reçues.

Et la connexion TCP ? Vous ne travaillez pas avec des sockets ? Vous avez
refait votre propre pile IP ?

Je veux dire par là qu'il est tout à fait conforme au fonctionnement de
TCP d'envoyer des segments de données contenant un octet chacun. C'est de
la fragmentation. Supposons que j'ai un PMTU de 576 octets, mais une
requête de 3000 octets à faire passer sur votre serveur, je fais comment
puisque cette requête va se retrouver éclatée sur 6 segments de
données ?

Mais, si tu fais ça 1000 fois par seconde, tu vas saturer le buffer de
trames du routeur. Et, conformément aux normes IP, il y aura
suppression aléatoire des trames dans le buffer. Donc, ça saturera
surtout la bande passante.

Il n'est pas très pêchu votre routeur si 1000 paquets/sec suffisent à
le saturer. Et pour autant que je sache, la norme IP ne spécifie pas ce
qu'un routeur doit faire lorsqu'il est saturé. En outre, en pratique, il
ne tire pas à bout portant dans la file d'attente mais détruit les
paquets reçus qu'il ne peut y placer (puisqu'il est plein) pendant qu'il
traite ceux qui y sont (ce qui a pour effet de libérer de la place). Mais
ça n'a rien d'aléatoire.

Plus je lis la description de votre serveur, plus je trouve son
comportement étrange. Le code source est disponible en quelque part ?


--
FF> Tiens, et combien de programmeurs faut-il pour changer une ampoule?
Ben, un pour appeler la maintenance et quatorze pour lui expliquer
qu'avec Linux ce serait mieux.
-+- JR in <http://neuneu.mine.nu> : Fiat lux, et tux fit.

Bonsoir !

En gros, c'est quoi la définition d'un port ouvert ?

C'est une grosse question. En fait, ça ne veut rien dire. Les trames TCP/IP
arrivent sur un ordinateur, et le port, ce n'est que quelques octets, dans
l'en-tête. Mais les trames arrivent. Ensuite, le système d'exploitation
utilise sa table de mappage, pour savoir à quel logiciel il va faire suivre
la trame. Si aucun logiciel n'est associé au port, la plupart du temps (mais
pas toujours), l'OS supprimera simplement la trame de son buffer.

On peut le voir, avec certains parefeux "personnel", lorsqu'on les paramètre
pour "fermer" des ports, et que l'on installe, ensuite, ethereal. Ce dernier
verra quand même les trames arriver, bien que le parefeux soit sensé
empêcher cela.

J'ai parlé ici, uniquement des trames entrantes.

Certaines cartes réseau ont un logique interne, qui permet d'effectuer des
traitements sur les trames. Le comportement peut alors être assimilé à celui
d'un équipement matériel externe. Mais c'est une solution efficace, car
aucun logiciel ne peux alors s'installer entre l'arrivée des trames et les
traitements effectués dessus (comme un parefeux externe).


Désolé de ne pas apporter de solution à ce niveau. Mais cela explique ma
démarche, qui vise à détecter, et à supprimer, l'origine des trames
douteuses, plutôt que de tenter de limiter la circulation de ces trames,
sans supprimer la cause (leur origine).

Bonne soirée
--
Michel Claveau