Je ne sais pas à vrai dire... il scanne sûrement les plus usités... une chose est sûre, il va au-delà de 2000 ( il repère le port 6000 )... mais j'y pense, ton port 53 apparaît alors que tu n'as pas indiqué à nmap que tu voulais scanner en UDP... l'ouvrir en TCP est inutile la plupart du temps d'après ce que je sais... essaie de serrer ta règle pour voir...

Enfin bon, de toute manière, même si tu a un port ouvert suite à un nmap localhost, c'est pas la mort, encore une fois tout dépend de comment est configuré le service derrière... par exemple chez moi le 631 ( Cups ) est ouvert, mais comme il ne fonctionne qu'en local pas de souci, tout ce qui arrive d'autre part que de lo passe par DROP

Poste le Monday 9 August 2004 11:29:04

non j'ai vrt le service minimum..
donc dhcp dns, http pour l'admin, ssh pour les corrections mais c tout.

je ne pense pas avoir quoique ce soit d'autre.

merci de ton aide.
Je ne connais linux que depuis peu et ça n'est pas toujours évident.



Jmy

Poste le Monday 9 August 2004 11:33:39

Voilà le résultat d'un test depuis un site internet.


GRC Port Authority Report created on UTC: 2004-08-09 at 10:03:47

Results from scan of ports: 0, 21-23, 25, 79, 80, 110, 113,
119, 135, 139, 143, 389, 443, 445,
1002, 1024-1030, 1720, 5000

1 Ports Open
10 Ports Closed
15 Ports Stealth
---------------------
26 Ports Tested

The port found to be OPEN was: 80

Ports found to be CLOSED were: 443, 1024, 1025, 1026, 1027,
1028, 1029, 1030, 1720, 5000

Other than what is listed above, all ports are STEALTH.

TruStealth: FAILED - NOT all tested ports were STEALTH,
- NO unsolicited packets were received,
- NO Ping reply (ICMP Echo) was received.


je pense que le résultat est plutot satisfaisant. Merci à vous tous de votre coup de pouce.

@ bientot



Jmy

Poste le Monday 9 August 2004 11:53:51

Côté sécurité globalement ça va ( pas d'ouverture inconnue )... mais par contre le nombre de ports "closed" est inquiétant...

Tu as des règles REJECT ou tout est DROP quand tu n'autorises pas la connexion ? autrement ça veut dire que les paquets envoyés ne passent pas par tes règles de firewall...

De plus le scan n'a dû tester que le tcp... autrement l'udp/53 aurait du être ouvert...

Sur quel site tu es allé, shieldUP! ?

Poste le Monday 9 August 2004 12:20:49

>tu sais si nmap ne scan que les 2000 premiers ports?

nmap prend des options, je pense que -v t'indique les ports scannés et surtout -p te permet de déterminer les ports à scanner (pour un scan complet, tu fais nmap -p 1-65535). man nmap pour plus d'infos...

pcflank n'est pas très efficace, il ne fait que scanner les ports les plus vulnérables sur un système win. Va donc voir ici plutot:
[scan.sygate.com]

Pour les ports à usage privé, petite astuce: dans la configuration de tes serveurs, tu peux changer le port d'écoute. Par exemple, demander à apache d'écouter le port 666 au lieu du 80, çe n'est pas la panacée mais c'est un truc supplémentaire: le type qui scanne tes ports aura un peu plus de difficultés à savoir quels sont les systèmes qui tournent sur ta machine. Il faut que les clients soient au courant et se connecte avec une adresse de ce type: [machin.fr] .

Une bonne adresse pour la sécurité: [www.linuxsecurity.com]

J'ai vu que tu comptais avoir un serveur ssh, je te conseille de forcer sur la sécurité à ce niveau, je fais réguliérement l'objet d'attaques en force brute sur ce service et il parait que c'est récurrent en ce moment. J'ai trouvé un début d'explication sur ce forum:
[www.linuxjunior.org]
Quant à moi, je n'autorise plus que les connections par clès.

ps: à ce propos, si quelqu'un a des renseignements la-dessus...



___________________________________________________
L'interface chaise-clavier se débuggue elle aussi...

Poste le Monday 9 August 2004 12:39:33

ola , un flot d'informations interessantes!

Alors commencons par le début .. pour te répondre Perramus, oui je suis allé sur shield-up. mais c étrange au niveau du résultat des ports fermés, j'ai l'impression que cela varie ... je v aller voir pour mes regles de DROP et de REJECT et je te dis cela dans l'am.

Concernant l'usage privé Morgan c'est interessant en effet et je n'y avais vrt pas pensé pour le serveur web...
Par contre pour le ssh ... je ne vois pas trop l'histoire d'utilisation des clefs...
Mon serveur ssh écoute déjà sur un autre port que sur le 22 et ensuite je ne sais pas trop comment faire pour l'échange des clefs. Il faudrait ke les deux partis se soient déjà échangé leur clés privés au moins une fois ...


enfin je v jeter un coup d'oeil de ce coté.


pas mal pour security scan ...
Résultats :

Operating System = Linux i686
Browser = Netscape Navigator 5.0
Unable to determine your computer name!
Trying to find out what services you are running...
Web Server Found = Server: Apache/1.3.28 (Unix)
ça fait déjà bcp d'infos ...
*********************************************************************************************
14 ports fermés : 20 - 21 - 22 - 23 - 25 - 59 - 79 - 110 - 113 - 139 - 443 - 1080 - 8080 - 32807
2 ports ouverts : 53 - 80
1 port bloqué : 445
**********************************************************************************************
Trojan SCAN
80 OPEN Executor, RingZero
**********************************************************************************************
TCP SCAN
Web 80 OPEN
**********************************************************************************************
UDP SCAN

**********************************************************************************************

Enfin c'est en cours je vous donne le reste des infos plus tard dans l'am.



Jmy

Poste le Monday 9 August 2004 13:00:54

>Il faudrait ke les deux partis se soient déjà échangé leur clés privés au moins une fois

oui mais la personne peut t'envoyer sa clef publique par mail (crypté)... Ou alors, tu lui donnes rendez-vous et tu autorise les connections par mot de passe le temps qu'il fasse la copie de sa clef. Commence par regarder ici si tu ne connais pas:
[people.via.ecp.fr]
Pour les détails, je te renvoie aux pages de manuel:
[www.openssh.org]

Comme le fait remarquer Perramus, tes ports non utilisés ne devraient pas etre ouvert mais filtrés (bloqués sur security scan), sinon, tu devras revoir tes règles iptables...



___________________________________________________
L'interface chaise-clavier se débuggue elle aussi...

Poste le Monday 9 August 2004 13:28:36

www.linux-france.org/prj/edu/archinet/SECU/ssh.pdf

voilà ce la documentation que j'utilisais jusqu'à présent pour mes connexions ssh et effectivement j'échange une clé au départ mais je ne voyais pas très bien dans quel but puisk à chq connexion une clé est générée dans know-host...



Jmy

Poste le Monday 9 August 2004 13:39:29

Il me semble que tu confonds l'échange de clé générée par le serveur pour communiquer avec le client et l'échange de clefs réalisé volontairement par le client pour réaliser l'authentification... cette clef publique publique du client doit etre copié dans un fichier ~/.ssh/authorized_keys. Pour le client, le mot de passe est alors remplacé par une pass-phrase liée a la clef (celle qui a servi pendant la génération des clefs).



___________________________________________________
L'interface chaise-clavier se débuggue elle aussi...

Poste le Monday 9 August 2004 13:49:03

OK ok ok ok
Bon je v lire la doc sur l'échange de clé parce que si je ne suis pas maintenant ça ne pourra pas aller par la suite ...

Merci



Jmy

Poste le Monday 9 August 2004 13:52:55

Pour répondre à Perramus, Je n'ai pas de regles de REJECT OU DROP ...
je dois dire ke je ne me suis pas penché dessus ...



Jmy

Poste le Monday 9 August 2004 14:33:29

En ce qui concerne les ports apparemment clos ...
rien que de 1024 à 1030 c'est utilisé par DCOM de microsoft...
je v voir pour virer ça, ça pourrait etre bon.

ensuite pareil, un port est alloué à UPnP ... no idea about it
par contre je fais de la tel sur ip alors besoin du 1720



Jmy

Poste le Monday 9 August 2004 15:08:39

Jm:
Si tu n'as pas de règles se terminant en -j DROP ou en -j REJECT, tu dois au moins avoir ta politique en INPUT qui fait du DROP ainsi que ton FORWARD... en tout cas sans aucun jump REJECT, il est anormal que tu aies des ports fermés...

Morgan:

Pour pcflank, il est possible de sélectionner les ports que tu veux ( dans advanced port scanner )... il reste meilleur que sygate... avec wanadoo mon port 445 apparaît closed chez pcflank alors qu'il est blocked ( stealthed ) chez sygate... or il n'apparaît pas dans mes logs, signe qu'il n'est pas passé pas le DROP en INPUT ( d'où c'est pcflank qui a raison... )...

Mais il est vrai que sygate à l'avantage de pouvoir tester l'UDP ( même si c'est très long... comme le tcp d'ailleurs... )et sous peu l'ICPM... un outil potentiellement intéressant donc...

Poste le Monday 9 August 2004 15:13:32

oui mais tout ça fait parti de l'initiatilisation de ma table filter...
enfin voilà ce que ça donne :

############################
# Initialisation de la table FILTER #
############################

iptables -t filter -F
iptables -t filter -X
iptables -t filter -P INPUT DROP
iptables -t filter -P OUTPUT DROP
iptables -t filter -P FORWARD DROP

***************************************************

C'est étrange pq les résultats avec shields differe de ceux ke j'ai pu avoir plus tot ... là je me retrouve avec 72 ports fermés ....



Jmy

Poste le Monday 9 August 2004 15:18:53

il est préférable de garder comme cela ou alors de faire des regles pour chq services spécifique?

Merci



Jmy

Poste le Monday 9 August 2004 15:23:31

Oui, mais en fait "-P" ça veut dire "Policy"... politique donc si un port ne rentre pas dans une règle définie, c'est la politique globale qui s'applique ( DROP )... si dans tes règles tu n'as aucun -j REJECT, tout ce qui n'est pas -j ACCEPT devrait être -j DROP...

Ah oui... peut-être n'ai-je pas été suffisament précis, désolé... Quand ton jump est DROP, les paquets arrivent puis son jetés, quand c'est en REJECT c'est la même chose sauf que ta machine envoie un paquet pour dire qu'elle a jeté le paquet... donc quand le résultat d'un scan c'est "stealthed" le scan a envoyé des paquets sans jamais obtenir de réponse puis a fini par lâcher l'affaire... quand c'est closed, ta machine a répondu... d'un point de vue sécuritaire c'est pas la mort mais ça rend ta machine plus aisément repérable sur le net ( bon tu me diras quand on a un serveur... ) le soucis c'est si ce closed n'est pas prévu par ton firewall... ça veut dire que les paquets ne sont pas traîtés selon les règles que tu as défini... c'est ça qu'il faut éclaircir...

Poste le Monday 9 August 2004 15:33:32

Oui, mais en fait "-P" ça veut dire "Policy"... politique donc si un port ne rentre pas dans une règle définie, c'est la politique globale qui s'applique ( DROP )... si dans tes règles tu n'as aucun -j REJECT, tout ce qui n'est pas -j ACCEPT devrait être -j DROP...

Ah oui... peut-être n'ai-je pas été suffisament précis, désolé... Quand ton jump est DROP, les paquets arrivent puis son jetés, quand c'est en REJECT c'est la même chose sauf que ta machine envoie un paquet pour dire qu'elle a jeté le paquet... donc quand le résultat d'un scan c'est "stealthed" le scan a envoyé des paquets sans jamais obtenir de réponse puis a fini par lâcher l'affaire... quand c'est closed, ta machine a répondu... d'un point de vue sécuritaire c'est pas la mort mais ça rend ta machine plus aisément repérable sur le net ( bon tu me diras quand on a un serveur... ) le soucis c'est si ce closed n'est pas prévu par ton firewall... ça veut dire que les paquets ne sont pas traîtés selon les règles que tu as définies... c'est ça qu'il faut éclaircir...

Poste le Monday 9 August 2004 15:33:46

J'ai tout de même l'impression que security scan est plus complet, mais je peux me tromper... dans ce cas, autant utiliser les deux, non? En matiére de sécurité...



___________________________________________________
L'interface chaise-clavier se débuggue elle aussi...

Poste le Monday 9 August 2004 15:34:53

ok ok ok ok ok .

Bon et bien j'ai encore du pain sur la planche.
Merci encore pour tout.



Jmy

Poste le Monday 9 August 2004 15:45:04

Rien que pour le scan UDP, et l'ICPM ( s'ils y vont à la dure ça va être "rigolo", effodrement de la machine en cas de mauvaise configuration de firewall... ) c'est clair... mais sur pcflank tu peux très bien indiquer 1-65535 pour le scan en tcp...

Pour la sécurité, tu as raison, mieux vaut varier les sources... reste que comme je le disais, souvent ce sont des scans hauts ( même si j'ai noté des attaques à partir de ports assez bas chez sygate ) qui peuvent passer à côté de failles... les sites de scan ça sert surtout à voir si le firewall est bien actif... pour le reste rien ne vaut un script bien fait ( un script même très simple qu'on comprend de A à Z... )...

Poste le Monday 9 August 2004 15:55:00