Svchost et port 443

Le Wed, 08 Sep 2004 22:44:49 +0000, Michel Claveau - abstraction
meta-galactique non triviale en fuite perpetuelle. a écrit :

à quoi ça sert, de bloquer des ports non utilisés ?

De rendre injoignable une backdoor installée par un intrus ou un trojan.

Dans la cas d'un serveur, une restriction stricte des flux réseau est
souvent ce qui empêche "simple" intrusion d'un service de se transformer
en corruption totale de la machine, du brin réseau attaché et des
machines alentours.


--
BOFH excuse #62:

need to wrap system in aluminum foil to fix problem

Le Wed, 08 Sep 2004 22:44:49 +0000, Michel Claveau - abstraction
meta-galactique non triviale en fuite perpetuelle. a écrit :

ce n'est pas parce qu'un port est ouvert qu'il y a une faille. Pour
qu'il y ait un risque, il faudrait qu'il y ait un logiciel qui soit en
écoute sur ce port.

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.

- la plupart des messages sur les parefeux "personnels" font état
de problèmes d'utilisation de leur informatique, provoqués par ces
outils. C'est la cause principale de mon abandon de ces outils (hé
oui, je les ai testés, et ils ne m'ont amenés que des problèmes).

La sécurité en environnement professionnel est une affaire de
professionnels, pas de gens qui pensent savoir. Des déploiements de
milliers de pare-feu personnels se font très bien, sans soucis.

- les parefeux "personnels" sont notoirement insuffisants, pour ce
qui est du contrôle sortant. Résultat : les gens se croient protégés, à
tort, et relâchent alors leur vigilance.

Ils sont notoirement plus efficaces que rien du tout.

- les parefeux "personnels" sont souvent affreusement compliqués à
configurer, et sont donc souvent mal configurés. Et il vaut mieux
enlever un parefeux, qu'en utiliser un mal configuré.

En environnement professionnel, on pousse des politiques de sécurité qui
ont été testées auparavant.

Et pourtant, aucun virus n'est jamais rentré. Pourquoi ? Une étude a
montré qu'il n'y avait pas de risque sur les autres postes. La
génération spontanée des virus n'existe pas ; il suffit, dès lors de
contrôler les points d'entrée possibles. Un exemple : un de mes
serveurs web n'a pas d'AV, alors qu'il est ouvert sur le net
(forcément), partage des données, et démarre en Administrateur. Mais
il ne répond que sur les ports 80, 119 et 22222. Là, on tombe sur des
logiciels prévus. Les autres ports : 1) n'arrivent pas sur ce poste 2)
même s'il y arrivent (lors des DMZ), il n'y aura aucune réponse. Comme
le serveur web ne traite QUE les requêtes GET et POST, il n'y a pas de
risques, là non plus. La preuve de l'efficacité, c'est que les trames
http de tentatives d'intrusion se succèdent, à raison d'une centaine
à l'heure, pour rien.

Je ne vais même pas commenter ce tissu de conneries tellement c'est gros...


--
BOFH excuse #408:

Computers under water due to SYN flooding.

Bonsoir !

vous êtes sous le coup de toute nouvelle attaque visant un accès que
vous n'auriez pas fermé

Meuh non ; ce n'est pas parce qu'un port est ouvert qu'une attaque peut
réussir. Pour que l'attaque ait une chance de succès, il faut qu'il y ait du
logiciel qui écoute, et réponde sur ce port. Il faut également que ce
logiciel, soit présente des failles de sécurité, soit un malware.

Donc, si on ne laisse pas s'installer de malware, et si l'on a corrigé les
failles connues des logiciels, ou si on utilise des logiciels sans failles
de sécurité, on ne risque pas grand chose.

J' ai plus souvent que certains ont peur de l'inconnu, plutôt de réelles
menaces.

@-salutations
--
Michel Claveau

Le Wed, 08 Sep 2004 23:04:42 +0000, Michel Claveau - abstraction
meta-galactique non triviale en fuite perpetuelle. a écrit :

vous êtes sous le coup de toute nouvelle attaque visant un accès que
vous n'auriez pas fermé

Meuh non ; ce n'est pas parce qu'un port est ouvert qu'une attaque peut
réussir. Pour que l'attaque ait une chance de succès, il faut qu'il y ait du
logiciel qui écoute, et réponde sur ce port.

S'il n'y a pas de logiciel en écoute sur le port, alors le port est
fermé.

Il faut également que ce logiciel, soit présente des failles de
sécurité

Ce qui est une hyptohèse loin d'être négligeable. En outre, ce n'est
pas forcément le cas. Si nous prenons le cas des serveurs Web, il suffit
que les pages dynamiques soient mal codées pour qu'on puisse corrompre le
serveur, sans pour autant avoir besoin d'un vulnérabilité de
l'applicatif en écoute sur le port.

soit un malware.

C'est également possible. Une intrusion réussie sur un service
accessible et vulnérable peut conduire à l'installation d'une backdoor.

Donc, si on ne laisse pas s'installer de malware,

Vous faites comment ? Parce que si je prends vos messages précédents,
j'ai du mal à voir ce qui peut empêcher un malware de s'installer et de
faire son travail jusqu'à ce que vous repassiez pour lancer un scan.

et si l'on a corrigé les failles connues des logiciels

Toutes les failles de sécurité exploitables (et exploitées) ne sont pas
connues. La faille RPC/DCOM (utilisée par le ver Blaster) était connue
au moins depuis février 2003 et un exploit tournait déjà en avril. La
faille a été publiée et patchée mi-juillet.

ou si on utilise des logiciels sans failles de sécurité

Qui n'existent pas...

on ne risque pas grand chose.

Oui oui... Au détail près que ce que vous appelez "pas grand chose"
puisse ne pas être acceptable pour tout le monde.


--
BOFH excuse #330:

quantum decoherence

Bonjour !

S'il n'y a pas de logiciel en écoute sur le port, alors le port est
fermé.

Non, ça n'a rien à voir. Un port peut être ouvert, sans qu'il n'y ait de
logiciel qui écoute.
Inversement, un port peut être fermé, malgré des logiciels qui restent prêts
à y répondre. C'est d'ailleurs comme cela que cela se passe, avec la
plupart des parefeux "personnels", qui, ainsi, bloquent des problèmes, mais
ne les règlent pas.

Si nous prenons le cas des serveurs Web, il suffit que les pages
dynamiques soient mal codées pour qu'on puisse corrompre le

serveur, sans pour autant avoir besoin d'un vulnérabilité de l'applicatif en
écoute sur le port.

Dans ce cas-là, le module qui prépare les pages dynamiques est en cause. En
plus, on peut considérer cela comme une extension du serveur web. Rares
sont les parefeux qui peuvent bloquer ce genre de problèmes (il y en a, mais
à des prix intéressants, et ce ne sont pas des parefeux "personnels").

Une intrusion réussie sur un service accessible et vulnérable peut
conduire à l'installation d'une backdoor.

Pas uniquement par un service. Tous les logiciels peuvent présenter des
vulnérabilités. Mais la plupart des malwares (pas seulement les backdoors)
s'installent d'une autre façon.

j'ai du mal à voir ce qui peut empêcher un malware de s'installer

Simplement parce que je n'installe pas n'importe quel logiciel. Un malware
ne s'installe pas tout seul.
De plus, fermer des ports n'empêchera pas tous les malwares de s'installer.

Toutes les failles de sécurité exploitables (et exploitées) ne sont pas
connues. La faille RPC/DCOM (utilisée par le ver Blaster) était connue au

moins depuis février 2003 et un exploit tournait déjà en avril. La faille a
été publiée et patchée mi-juillet.

Plus exactement, la faille a été dévoilée fin juin, patchée trois semaines
plus tard, et exploitée, par blaster, encore trois semaines plus tard. Aucun
des postes qui avaient été mis à jour normalement n'ont été infectés.

ou si on utilise des logiciels sans failles de sécurité

Qui n'existent pas...

Mais si. Mon serveur web, par exemple. Il ne retient que GET et POST, et ne
traite que les requêtes HTTP bien formées. Pour les autres, il retourne un
code d'erreur standard (400). Cela suffit largement pour les besoins
normaux, et c'est inattaquable. Le problème (des serveurs web) vient
souvent des centaines d'extensions qui sont ajoutées, et dont presque
personne ne se sert. Cela est vrai pour Apache et IIS, notamment.

Au détail près que ce que vous appelez "pas grand chose" puisse ne pas
être acceptable pour tout le monde.

En tout cas, on risque moins de problèmes qu'en "bloquant tout", ce qui
constitue un DOS



@-salutations
--
Michel Claveau

Bonjour !

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" : 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.

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.
En pratique, même si un parefeux "personnel" est sensé avoir bloqué un port,
rien n'empêche un logiciel de l'écouter au niveau RAW, en amont du parefeux
(qui n'en saura rien).

en environnement professionnel... des déploiements de milliers de
pare-feu personnels se font très bien, sans soucis

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.

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.

Je vais te citer un seul exemple : une petite entreprise, 4 postes en
réseau. Le client achète, et installe, le parefeux de Norton. Résultat : le
lendemain, appel téléphonique ; les applis réseau ne fonctionnent plus. NPF
avait bloqué des soi-disant failles, qui étaient, en fait, des partages
normaux d'information. Au client, j'ai proposé l'alternative : désactiver le
parefeux, ou se payer une intervention, pour affiner la configuration du PF.
Il n'a pas mis 10 secondes pour faire son choix, celui de continuer à
pouvoir travailler.

Des exemples comme ça, j'en ai des centaines (toutes en milieu
professionnel).

Je ne vais même pas commenter ce tissu de conneries tellement c'est
gros...

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.
Et, comme tu vires vers les grossièretés, je dirais que ton comportement
ressemble à celui d'une personne qui utilise des préservatifs pour des
pratiques solitaires, afin, d'être mieux protégé.



@-salutations
--
Michel Claveau

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

Pour qu'un port soir ouvert, il faut qu'il y ait un programme en écoute
dessus. Sinon, il est fermé.

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.

Vous confondez l'ouverture/fermeture de port et le filtrage de port.

De toute façon, la notion de port ouvert ou fermé ne fait pas partie de
TCP/IP.

Et l'état TCP CLOSED n'a rien à rien à voir avec le fait que le port
soit ouvert en écoute ou connexion par un quelconque programme...

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.

Nous ne travaillons clairement pas dans les mêmes milieux professionnels.

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.

Pour qu'un utilisateur désactive son PF, il doit avoir les droit
d'administration. S'ils les a, c'est que le poste n'est pas configuré
proprement. Un simple utilisateur n'a pas à avoir les droits
d'administration sur son poste.

Je vais te citer un seul exemple : une petite entreprise, 4 postes en
réseau.

Voilà, on ne travaille pas pour les mêmes clients. J'en vois qui
déploient des PF par centaines sur des postes fixes et portables, en
poussant des politiques de sécurité validées à partir de serveurs
centraux, et ça ne pose pas de problème. Pourquoi ? Parce que c'est fait
par des gens qui savent le faire.
Votre client a voulu installer un produit grand public tout seul, il s'est
planté. Cela veut-il pour autant dire que l'outil n'est pas efficace ? Si
on devait juger l'efficacité d'un outil de sécurité à la capacité
qu'ont les gens non compétents pour les utiliser, on les jetterait par
milliers.

Des exemples comme ça, j'en ai des centaines (toutes en milieu
professionnel).

Si ces exemples sont tous de même acabit, ce sont des professionnels qui :

1. n'ont pas de compétences en sécurité
2. installent seul des outils
3. n'arrivent pas à les configurer
4. les abandonnent

Je ne vois pas là-dedans ce qui remet en question les apports de ces
outils.

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.

Je ne vais prendre qu'un exemple. Vous écrivez :

"Comme le serveur web ne traite QUE les requêtes GET et
POST, il n'y a pas de risques, là non plus."

Cette affirmation relève d'une ignorance profonde des problèmes de
sécurité liés à un servive HTTP. Exemples :

CodeRed fait un GET déclenchant un buffer overflow
Nimda fait un GET avec un encodage unicode
une SQL injection d'exploite avec un GET ou un POST
un XSS s'exploite avec un GET ou un POST
etc.

Les deux premiers font référence à des failles du serveur Web, les deux
suivants à des erreurs de programmation de l'application Web dynamique.
Tout cela peut conduire à la compromission totale du serveur, sans
utiliser autre chose que des GET et des POST. Et si là dessus le filtrage
est mal fait, l'attaquant peut :

télécharger des outils pour conduire l'escalade
installer et joindre une backdoor

J'ai un client qui s'est fait rooté un serveur Web. Il a utilisé une
faille et installé une page lui permettant de revenir quand la faille
serait corrigé, le tout avec un script disponible à n'importe quel
script kiddy. Seulement comme le filtrage était serré, c'est à dire
respectant la règle de moindre privilège que vous décriez ici, il n'a
pas pu télécharger ses outils et a passé son chemin.

Et des exemples comme ça, d'intrusion limitées par le filtrage ou
facilitée par son absence, aussi bien en test d'intrusion qu'en analyse
post-intrusion, j'en ai des tonnes, dans les milieux professionnels type
PME et dans les grands comptes.

Mais bon, des fois, quand les client se plaignent de se qu'on leur met en
place, il faut aussi s'interroger sur sa capacité à leur fournir un
outil bien configuré et adapté à leur besoin, plutôt que de leur
conseiller de tout virer...


--
BOFH excuse #215:

High nuclear activity in your area.

"Michel" == Michel Claveau <unseulmcmcmcmc@msupprimerlepoint.claveauPOINTcom> writes:

Michel> En milieu professionnel, on n'installe pas ce genre d'outils,
Michel> qui posent beaucoup trop de problèmes.

Ah ?

La notion de défense en couches, vous connaissez ?

Michel> Les administrateurs n'ont pas de temps à perdre à reconfigurer
Michel> à l'infini ces trucs,

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.

Michel> alors qu'un parefeux centralisé, et téléadministrable protège
Michel> au moins aussi bien, et avec BEAUCOUP moins de problèmes.

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

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

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

Michel> Des exemples comme ça, j'en ai des centaines (toutes en milieu
Michel> professionnel).

Je n'aimerais pas faire partie de vos clients.

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

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.

Eric Masson

PS: Le charabia servant à encoder votre adresse est gênant dans le cadre
de la modération. En effet, un modérateur n'a pas pour vocation de
résoudre des charades débiles pour retrouver une adresse valide pour les
notifications.

--
il y a quatre mots dans votre phrase et si vous ne décelez pas les
conséquences rhétoriques de vos propres paroles, c'est facheux et vous
conduira sans doute à d'autres difficultés d'ordre communicationnelles!
-+- PG in <http://www.le-gnu.net> : C'est cela, oui. -+-

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

ou si on utilise des logiciels sans failles de sécurité

Qui n'existent pas...

Mais si. Mon serveur web, par exemple. Il ne retient que GET et POST, et ne
traite que les requêtes HTTP bien formées. Pour les autres, il retourne un
code d'erreur standard (400). Cela suffit largement pour les besoins
normaux, et c'est inattaquable.

De bien belles certitudes ....

Tout logiciel un poil complexe contient des bugs, dont certains auront
forcément des conséquences de sécurité. Et dans le cas d'applications
Web, même si le serveur HTTP est à jour, cela ne présume pas de la
sécurité du service. Perso, mon expérience d'audit/pen-test de sites
Web dynamiques doit donner du 95% de réussite (ie. compromission), sur
des composants logiciels *à jour* !

Curioisité : c'est quoi, ton serveur Web "inattaquable" ?


Nicob

"Michel Claveau - abstraction meta-galactique non triviale en fuite
perpetuelle." wrote in message <chp04f$dbs$1@news-reader1.wanadoo.fr>:

Non, ça n'a rien à voir. Un port peut être ouvert, sans qu'il n'y ait de
logiciel qui écoute.

Je pense qu'il y a un problème pour savoir de quoi on parle, là. L'état d'un
port concernant le firewall est filtré/non filtré. Du point de vue de l'OS
hôte (hors firewall, si c'est un firewall local), le port peut être ouvert
ou fermé de manière indépendante, et c'est bien le fait qu'un processus
écoute qui le détermine. Vu de l'extérieur du firewall, ça donne quelque
chose comme ça :

processus en écoute filtrage état
non non fermé
oui non ouvert
non oui filtré
oui oui filtré

En particulier, la réponse d'un port fermé (sans filtrage) n'est pas du tout
la même que celle d'un port fermé (sauf si c'est justement fait exprès).