Bonjour
Ma passerelle est une mandrake 9.2
Mon firewall (shorewall) drop tout les paquets entrants (sur les connexions
non etablies)
Sauf pour le port 22 (administration via ssh)
Vu que c'est le seul point faible (que je connaisse) de ma passerelle, je le
surveille. Et je suis souvent "attaqué" par des tentatives de connexion avec
des user et pass tres courant.
Comme je ne connais pas tout, je me dis qu'une fois que la personne a ouvert
un ssh (meme sans pass) elle peut commencer a faire des "betises"
Je me demandai si une bonne solution ne serai pas betement de changer le
port de mon ssh.
Cela aura un effet ?
Je pense qu'il est facile de faire un scan de tous ports, puis essayer une
connexion sur ceux qui repondent pour voir ce qu'ils ont a dire, mais ca
peux en décourager les jeunes hacker.
Si c'est une bonne solution, y a t'il des ports a eviter ?
Tu pourrais aussi peut-être limiter les adresses qui peuvent s'y connecter. Chez moi par exemple, je ne peux me connecter à ma machine que depuis mon bureau ou chez un copain :)
c'est un peu limitatif comme procédé:
Le jour où le service informatique de ton employeur décide de changer l'adresse ip de la passerelle sortante, tu ne pourras plus te connecter chez toi ! (ok ok, si tu es LE sce info de la boite, ça change tout..)
Et quand tu sera chez un autre pote, et que t'auras besoin de te connecter en urgence à la maison, ça ne marchera pas non plus...
Emmanuel Florac wrote:
Tu pourrais aussi peut-être limiter les adresses qui peuvent s'y
connecter. Chez moi par exemple, je ne peux me connecter à ma machine que
depuis mon bureau ou chez un copain :)
c'est un peu limitatif comme procédé:
Le jour où le service informatique de ton employeur décide de changer
l'adresse ip de la passerelle sortante, tu ne pourras plus te connecter
chez toi ! (ok ok, si tu es LE sce info de la boite, ça change tout..)
Et quand tu sera chez un autre pote, et que t'auras besoin de te
connecter en urgence à la maison, ça ne marchera pas non plus...
Tu pourrais aussi peut-être limiter les adresses qui peuvent s'y connecter. Chez moi par exemple, je ne peux me connecter à ma machine que depuis mon bureau ou chez un copain :)
c'est un peu limitatif comme procédé:
Le jour où le service informatique de ton employeur décide de changer l'adresse ip de la passerelle sortante, tu ne pourras plus te connecter chez toi ! (ok ok, si tu es LE sce info de la boite, ça change tout..)
Et quand tu sera chez un autre pote, et que t'auras besoin de te connecter en urgence à la maison, ça ne marchera pas non plus...
Emmanuel Florac
Le Sun, 15 Aug 2004 09:21:41 +0000, Laurent Bruder a écrit :
c'est un peu limitatif comme procédé:
Le jour où le service informatique de ton employeur décide de changer l'adresse ip de la passerelle sortante, tu ne pourras plus te connecter chez toi ! (ok ok, si tu es LE sce info de la boite, ça change tout..)
Oui, ça m'est déjà arrivé, cependant ça n'est pas forcément vital de pouvoir se connecter chez soi!
Et quand tu sera chez un autre pote, et que t'auras besoin de te connecter en urgence à la maison, ça ne marchera pas non plus...
En général je prévois le coup et j'ouvre le firewall avant de partir.
-- Le travail est la malédiction des classes qui boivent. O. Wilde.
Le Sun, 15 Aug 2004 09:21:41 +0000, Laurent Bruder a écrit :
c'est un peu limitatif comme procédé:
Le jour où le service informatique de ton employeur décide de changer
l'adresse ip de la passerelle sortante, tu ne pourras plus te connecter
chez toi ! (ok ok, si tu es LE sce info de la boite, ça change tout..)
Oui, ça m'est déjà arrivé, cependant ça n'est pas forcément vital de
pouvoir se connecter chez soi!
Et quand tu sera chez un autre pote, et que t'auras besoin de te connecter
en urgence à la maison, ça ne marchera pas non plus...
En général je prévois le coup et j'ouvre le firewall avant de partir.
--
Le travail est la malédiction des classes qui boivent.
O. Wilde.
Le Sun, 15 Aug 2004 09:21:41 +0000, Laurent Bruder a écrit :
c'est un peu limitatif comme procédé:
Le jour où le service informatique de ton employeur décide de changer l'adresse ip de la passerelle sortante, tu ne pourras plus te connecter chez toi ! (ok ok, si tu es LE sce info de la boite, ça change tout..)
Oui, ça m'est déjà arrivé, cependant ça n'est pas forcément vital de pouvoir se connecter chez soi!
Et quand tu sera chez un autre pote, et que t'auras besoin de te connecter en urgence à la maison, ça ne marchera pas non plus...
En général je prévois le coup et j'ouvre le firewall avant de partir.
-- Le travail est la malédiction des classes qui boivent. O. Wilde.
totoy81
"Joel" wrote in message news:<cffrls$4hs$...
Bonjour Ma passerelle est une mandrake 9.2 Mon firewall (shorewall) drop tout les paquets entrants (sur les connexions non etablies) Sauf pour le port 22 (administration via ssh) Vu que c'est le seul point faible (que je connaisse) de ma passerelle, je le surveille. Et je suis souvent "attaqué" par des tentatives de connexion avec des user et pass tres courant.
Le seul "point faible" ? Et shorewall ? Et la portion du kernel qui traite le sous système réseau ? et ... ;).
Comme je ne connais pas tout, je me dis qu'une fois que la personne a ouvert un ssh (meme sans pass) elle peut commencer a faire des "betises"
Oui, ce qui vient immédiatemment à l'esprit est le détournement du flot d'éxécution du démon sshd (via un stack/heap overflow,un format bug...), j'imagine que c ce que tu veux dire par "sans pass".
Je me demandai si une bonne solution ne serai pas betement de changer le port de mon ssh. Cela aura un effet ?
Un effet sur quoi ? A priori, aucun, si ce n'est que l'accès SSH présuppose de connaitre le port spécifique.
Je pense qu'il est facile de faire un scan de tous ports, puis essayer une connexion sur ceux qui repondent pour voir ce qu'ils ont a dire, mais ca peux en décourager les jeunes hacker.
Mouais. Si c'est un mass scan sur le port 22, tu peux éviter que ta machine soit ajoutée à la list des hôtes à hacker ;). Si le scan ne concerne que ta machine, c'est plus délicat. Nmap se base sur le fichier /etc/services pour établir la correspondance port ouvert / service correspondant. Ce qui est du fait insuffisant pour détecter des démons sur des ports non conventionnels. Sur les ports un peu louches (comme le sera celui que tu choisiras ;)), lancer un outil comme amap (www.thc.org) levera l'indétermination.
Si c'est une bonne solution, y a t'il des ports a eviter ?
A priori, éviter les ports inférieur à 1024.
Merci pour vos lumieres
Joel.
Sinon durcir ta machine, avec un patch comme grsec, et appliquer les best practices de sécurisation.
"Joel" <nospam@nospam.com> wrote in message news:<cffrls$4hs$1@news-reader4.wanadoo.fr>...
Bonjour
Ma passerelle est une mandrake 9.2
Mon firewall (shorewall) drop tout les paquets entrants (sur les connexions
non etablies)
Sauf pour le port 22 (administration via ssh)
Vu que c'est le seul point faible (que je connaisse) de ma passerelle, je le
surveille. Et je suis souvent "attaqué" par des tentatives de connexion avec
des user et pass tres courant.
Le seul "point faible" ? Et shorewall ? Et la portion du kernel qui
traite le sous système réseau ? et ... ;).
Comme je ne connais pas tout, je me dis qu'une fois que la personne a ouvert
un ssh (meme sans pass) elle peut commencer a faire des "betises"
Oui, ce qui vient immédiatemment à l'esprit est le détournement du
flot d'éxécution du démon sshd (via un stack/heap overflow,un format
bug...), j'imagine que c ce que tu veux dire par "sans pass".
Je me demandai si une bonne solution ne serai pas betement de changer le
port de mon ssh.
Cela aura un effet ?
Un effet sur quoi ? A priori, aucun, si ce n'est que l'accès SSH
présuppose de connaitre le port spécifique.
Je pense qu'il est facile de faire un scan de tous ports, puis essayer une
connexion sur ceux qui repondent pour voir ce qu'ils ont a dire, mais ca
peux en décourager les jeunes hacker.
Mouais. Si c'est un mass scan sur le port 22, tu peux éviter que ta
machine soit ajoutée à la list des hôtes à hacker ;). Si le scan ne
concerne que ta machine, c'est plus délicat. Nmap se base sur le
fichier /etc/services pour établir la correspondance port ouvert /
service correspondant. Ce qui est du fait insuffisant pour détecter
des démons sur des ports non conventionnels. Sur les ports un peu
louches (comme le sera celui que tu choisiras ;)), lancer un outil
comme amap (www.thc.org) levera l'indétermination.
Si c'est une bonne solution, y a t'il des ports a eviter ?
A priori, éviter les ports inférieur à 1024.
Merci pour vos lumieres
Joel.
Sinon durcir ta machine, avec un patch comme grsec, et appliquer les
best practices de sécurisation.
Bonjour Ma passerelle est une mandrake 9.2 Mon firewall (shorewall) drop tout les paquets entrants (sur les connexions non etablies) Sauf pour le port 22 (administration via ssh) Vu que c'est le seul point faible (que je connaisse) de ma passerelle, je le surveille. Et je suis souvent "attaqué" par des tentatives de connexion avec des user et pass tres courant.
Le seul "point faible" ? Et shorewall ? Et la portion du kernel qui traite le sous système réseau ? et ... ;).
Comme je ne connais pas tout, je me dis qu'une fois que la personne a ouvert un ssh (meme sans pass) elle peut commencer a faire des "betises"
Oui, ce qui vient immédiatemment à l'esprit est le détournement du flot d'éxécution du démon sshd (via un stack/heap overflow,un format bug...), j'imagine que c ce que tu veux dire par "sans pass".
Je me demandai si une bonne solution ne serai pas betement de changer le port de mon ssh. Cela aura un effet ?
Un effet sur quoi ? A priori, aucun, si ce n'est que l'accès SSH présuppose de connaitre le port spécifique.
Je pense qu'il est facile de faire un scan de tous ports, puis essayer une connexion sur ceux qui repondent pour voir ce qu'ils ont a dire, mais ca peux en décourager les jeunes hacker.
Mouais. Si c'est un mass scan sur le port 22, tu peux éviter que ta machine soit ajoutée à la list des hôtes à hacker ;). Si le scan ne concerne que ta machine, c'est plus délicat. Nmap se base sur le fichier /etc/services pour établir la correspondance port ouvert / service correspondant. Ce qui est du fait insuffisant pour détecter des démons sur des ports non conventionnels. Sur les ports un peu louches (comme le sera celui que tu choisiras ;)), lancer un outil comme amap (www.thc.org) levera l'indétermination.
Si c'est une bonne solution, y a t'il des ports a eviter ?
A priori, éviter les ports inférieur à 1024.
Merci pour vos lumieres
Joel.
Sinon durcir ta machine, avec un patch comme grsec, et appliquer les best practices de sécurisation.
Nicob
On Sun, 15 Aug 2004 16:26:16 +0000, anth0 wrote:
Nmap se base sur le fichier /etc/services pour établir la correspondance port ouvert / service correspondant. Ce qui est du fait insuffisant pour détecter des démons sur des ports non conventionnels.
C'est fini, cette époque :) Depuis la v3.45, Nmap intègre l'identification des services détectés :
http://www.insecure.org/nmap/versionscan.html
Nicob
On Sun, 15 Aug 2004 16:26:16 +0000, anth0 wrote:
Nmap se base sur le fichier /etc/services pour établir la
correspondance port ouvert / service correspondant. Ce qui est du fait
insuffisant pour détecter des démons sur des ports non conventionnels.
C'est fini, cette époque :)
Depuis la v3.45, Nmap intègre l'identification des services détectés :
Nmap se base sur le fichier /etc/services pour établir la correspondance port ouvert / service correspondant. Ce qui est du fait insuffisant pour détecter des démons sur des ports non conventionnels.
C'est fini, cette époque :) Depuis la v3.45, Nmap intègre l'identification des services détectés :
http://www.insecure.org/nmap/versionscan.html
Nicob
Patrice Auffret
On 15 Aug 2004 16:26:16 GMT (anth0) wrote: [..]
concerne que ta machine, c'est plus délicat. Nmap se base sur le fichier /etc/services pour établir la correspondance port ouvert / service correspondant. Ce qui est du fait insuffisant pour détecter des démons sur des ports non conventionnels. Sur les ports un peu louches (comme le sera celui que tu choisiras ;)), lancer un outil comme amap (www.thc.org) levera l'indétermination. [..]
Heu, tu connais la version 3 de Nmap ? il détecte les services sur les ports non-standard aussi.
nmap -sV ...
On 15 Aug 2004 16:26:16 GMT
totoy81@caramail.com (anth0) wrote:
[..]
concerne que ta machine, c'est plus délicat. Nmap se base sur le
fichier /etc/services pour établir la correspondance port ouvert /
service correspondant. Ce qui est du fait insuffisant pour détecter
des démons sur des ports non conventionnels. Sur les ports un peu
louches (comme le sera celui que tu choisiras ;)), lancer un outil
comme amap (www.thc.org) levera l'indétermination.
[..]
Heu, tu connais la version 3 de Nmap ? il détecte les services sur
les ports non-standard aussi.
concerne que ta machine, c'est plus délicat. Nmap se base sur le fichier /etc/services pour établir la correspondance port ouvert / service correspondant. Ce qui est du fait insuffisant pour détecter des démons sur des ports non conventionnels. Sur les ports un peu louches (comme le sera celui que tu choisiras ;)), lancer un outil comme amap (www.thc.org) levera l'indétermination. [..]
Heu, tu connais la version 3 de Nmap ? il détecte les services sur les ports non-standard aussi.
nmap -sV ...
VANHULLEBUS Yvan
(anth0) writes:
"Joel" wrote in message news:<cffrls$4hs$... [SSH sur un autre port]
Je pense qu'il est facile de faire un scan de tous ports, puis essayer une connexion sur ceux qui repondent pour voir ce qu'ils ont a dire, mais ca peux en décourager les jeunes hacker.
Mouais. Si c'est un mass scan sur le port 22, tu peux éviter que ta machine soit ajoutée à la list des hôtes à hacker ;). Si le scan ne concerne que ta machine, c'est plus délicat. Nmap se base sur le fichier /etc/services pour établir la correspondance port ouvert / service correspondant.
Plus maintenant, il y a maintenant l'option -sV qui fait une connexion sur chaque port ouvert pour essayer de determiner quel service tourne dessus, voire quel programme, quelle version et parfois meme des informations sur la configuration.
A +
VANHU.
totoy81@caramail.com (anth0) writes:
"Joel" <nospam@nospam.com> wrote in message news:<cffrls$4hs$1@news-reader4.wanadoo.fr>...
[SSH sur un autre port]
Je pense qu'il est facile de faire un scan de tous ports, puis essayer une
connexion sur ceux qui repondent pour voir ce qu'ils ont a dire, mais ca
peux en décourager les jeunes hacker.
Mouais. Si c'est un mass scan sur le port 22, tu peux éviter que ta
machine soit ajoutée à la list des hôtes à hacker ;). Si le scan ne
concerne que ta machine, c'est plus délicat. Nmap se base sur le
fichier /etc/services pour établir la correspondance port ouvert /
service correspondant.
Plus maintenant, il y a maintenant l'option -sV qui fait une connexion
sur chaque port ouvert pour essayer de determiner quel service tourne
dessus, voire quel programme, quelle version et parfois meme des
informations sur la configuration.
"Joel" wrote in message news:<cffrls$4hs$... [SSH sur un autre port]
Je pense qu'il est facile de faire un scan de tous ports, puis essayer une connexion sur ceux qui repondent pour voir ce qu'ils ont a dire, mais ca peux en décourager les jeunes hacker.
Mouais. Si c'est un mass scan sur le port 22, tu peux éviter que ta machine soit ajoutée à la list des hôtes à hacker ;). Si le scan ne concerne que ta machine, c'est plus délicat. Nmap se base sur le fichier /etc/services pour établir la correspondance port ouvert / service correspondant.
Plus maintenant, il y a maintenant l'option -sV qui fait une connexion sur chaque port ouvert pour essayer de determiner quel service tourne dessus, voire quel programme, quelle version et parfois meme des informations sur la configuration.
A +
VANHU.
Michel Arboi
On Mon Aug 16 2004 at 09:34, Nicob wrote:
Depuis la v3.45, Nmap intègre l'identification des services détectés : http://www.insecure.org/nmap/versionscan.html
Je ne suis pas convaincu par la technique mise en oeuvre et n'ai pas été épaté par le résultat. Par exemple : PORT STATE SERVICE VERSION 23/tcp open telnet Linux telnetd 873/tcp open rsync (protocol version 27) 1080/tcp open socks?
Si rsync est le nom du port venant /etc/services, je m'attends à retrouver le nom dans la colonne VERSION. Et socks n'a pas été identifié, alors que ce n'est bien pas difficile.
J'ai modifié récemment le wrapper Nmap de Nessus pour gérer l'option sV mais je me demande par quel bout je vais attraper l'information crachée.
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/ NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/
On Mon Aug 16 2004 at 09:34, Nicob wrote:
Depuis la v3.45, Nmap intègre l'identification des services détectés :
http://www.insecure.org/nmap/versionscan.html
Je ne suis pas convaincu par la technique mise en oeuvre et n'ai pas
été épaté par le résultat. Par exemple :
PORT STATE SERVICE VERSION
23/tcp open telnet Linux telnetd
873/tcp open rsync (protocol version 27)
1080/tcp open socks?
Si rsync est le nom du port venant /etc/services, je m'attends à
retrouver le nom dans la colonne VERSION.
Et socks n'a pas été identifié, alors que ce n'est bien pas difficile.
J'ai modifié récemment le wrapper Nmap de Nessus pour gérer l'option sV
mais je me demande par quel bout je vais attraper l'information
crachée.
Depuis la v3.45, Nmap intègre l'identification des services détectés : http://www.insecure.org/nmap/versionscan.html
Je ne suis pas convaincu par la technique mise en oeuvre et n'ai pas été épaté par le résultat. Par exemple : PORT STATE SERVICE VERSION 23/tcp open telnet Linux telnetd 873/tcp open rsync (protocol version 27) 1080/tcp open socks?
Si rsync est le nom du port venant /etc/services, je m'attends à retrouver le nom dans la colonne VERSION. Et socks n'a pas été identifié, alors que ce n'est bien pas difficile.
J'ai modifié récemment le wrapper Nmap de Nessus pour gérer l'option sV mais je me demande par quel bout je vais attraper l'information crachée.
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/ NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/
Nicob
On Mon, 16 Aug 2004 11:05:57 +0000, Michel Arboi wrote:
23/tcp open telnet Linux telnetd
OK
873/tcp open rsync (protocol version 27)
Bizarre. Que dit " --version_trace" ? Mieux, cette machine est-elle publique, afin de tester ?
1080/tcp open socks?
Après lecture des fichiers fournis avec la 3.55, il semble qu'il n'y ait *aucune* signature (que ce soit en 'match' ou 'softmatch') pour Socks. D'où ce comportment ...
Si le service a renvoyé la moindre donnée, z'avez gagné un voyage vers http://www.insecure.org/cgi-bin/servicefp-submit.cgi
Nicob
On Mon, 16 Aug 2004 11:05:57 +0000, Michel Arboi wrote:
23/tcp open telnet Linux telnetd
OK
873/tcp open rsync (protocol version 27)
Bizarre. Que dit " --version_trace" ?
Mieux, cette machine est-elle publique, afin de tester ?
1080/tcp open socks?
Après lecture des fichiers fournis avec la 3.55, il semble qu'il
n'y ait *aucune* signature (que ce soit en 'match' ou 'softmatch') pour
Socks. D'où ce comportment ...
Si le service a renvoyé la moindre donnée, z'avez gagné un voyage vers
http://www.insecure.org/cgi-bin/servicefp-submit.cgi
On Mon, 16 Aug 2004 11:05:57 +0000, Michel Arboi wrote:
23/tcp open telnet Linux telnetd
OK
873/tcp open rsync (protocol version 27)
Bizarre. Que dit " --version_trace" ? Mieux, cette machine est-elle publique, afin de tester ?
1080/tcp open socks?
Après lecture des fichiers fournis avec la 3.55, il semble qu'il n'y ait *aucune* signature (que ce soit en 'match' ou 'softmatch') pour Socks. D'où ce comportment ...
Si le service a renvoyé la moindre donnée, z'avez gagné un voyage vers http://www.insecure.org/cgi-bin/servicefp-submit.cgi
Nicob
Michel Arboi
On Mon Aug 16 2004 at 23:15, Nicob wrote:
873/tcp open rsync (protocol version 27)
Bizarre. Que dit " --version_trace" ?
----------------------------------------------------------------------------- We got a ping packet back from 192.168.1.254: id = 27185 seq = 15883 checksum = 22467 Hostupdate called for machine 192.168.1.254 state UNKNOWN/COMBO -> HOST_UP (trynum 0, dotimeadj: yes time: 506) Finished block: srtt: 416 rttvar: 5000 timeout: 300000 block_tries: 1 up_this_block: 1 down_this_block: 0 group_sz: 1 massping done: num_hosts: 1 num_responses: 1 Starting pos_scan (Connect() Scan) Finished round #1. Current stats: numqueries_ideal: 30; min_width: 1; max_width: 1020; packet_incr: 4; senddelay: 0us; fallback: 69% NSOCK (0.3340s) TCP connection requested to 192.168.1.254:873 (IOD #1) EID 8 NSOCK (0.3340s) nsock_loop() started (no timeout). 1 events pending NSOCK (0.3350s) Callback: CONNECT SUCCESS for EID 8 [192.168.1.254:873] NSOCK (0.3350s) Read request from IOD #1 [192.168.1.254:873] (timeout: 5000ms) EID 18 NSOCK (0.3370s) Callback: READ SUCCESS for EID 18 [192.168.1.254:873] (12 bytes): @RSYNCD: 27. Starting pos_scan (RPCGrind Scan) Interesting ports on passoire (192.168.1.254): PORT STATE SERVICE VERSION 873/tcp open rsync (protocol version 27) -----------------------------------------------------------------------------
Mieux, cette machine est-elle publique, afin de tester ?
Elle est publique, mais rsync écoute sur une patte interne.
Dans la série des choses qui écoutent sur la patte publique, on trouve: PORT STATE SERVICE VERSION 25/tcp open smtp Postfix smtpd 80/tcp open http thttpd 2.25b 29dec2003
C'est vrai, mais je parie qu'il s'est contenté de me renvoyer la bannière pour le 25 et le 80
D'ailleurs, ce n'est pas tout à fait exact : [www_fingerprinting_hmap.nasl] This web server was fingerprinted as thttpd/2.25b through pound reverse proxy which is consistent with the displayed banner: thttpd/2.25b 29dec2003 [smtpscan.nasl] This server could be fingerprinted as being Postfix 2.0.16-2.1.3
Si le service a renvoyé la moindre donnée, z'avez gagné un voyage vers http://www.insecure.org/cgi-bin/servicefp-submit.cgi
Oui mais non. Je ne vais pas me casser le trognon à faire tomber en marche un truc que je crois voué à l'échec.
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/ NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/
On Mon Aug 16 2004 at 23:15, Nicob wrote:
873/tcp open rsync (protocol version 27)
Bizarre. Que dit " --version_trace" ?
-----------------------------------------------------------------------------
We got a ping packet back from 192.168.1.254: id = 27185 seq = 15883 checksum = 22467
Hostupdate called for machine 192.168.1.254 state UNKNOWN/COMBO -> HOST_UP (trynum 0, dotimeadj: yes time: 506)
Finished block: srtt: 416 rttvar: 5000 timeout: 300000 block_tries: 1 up_this_block: 1 down_this_block: 0 group_sz: 1
massping done: num_hosts: 1 num_responses: 1
Starting pos_scan (Connect() Scan)
Finished round #1. Current stats: numqueries_ideal: 30; min_width: 1; max_width: 1020; packet_incr: 4; senddelay: 0us; fallback: 69%
NSOCK (0.3340s) TCP connection requested to 192.168.1.254:873 (IOD #1) EID 8
NSOCK (0.3340s) nsock_loop() started (no timeout). 1 events pending
NSOCK (0.3350s) Callback: CONNECT SUCCESS for EID 8 [192.168.1.254:873]
NSOCK (0.3350s) Read request from IOD #1 [192.168.1.254:873] (timeout: 5000ms) EID 18
NSOCK (0.3370s) Callback: READ SUCCESS for EID 18 [192.168.1.254:873] (12 bytes): @RSYNCD: 27.
Starting pos_scan (RPCGrind Scan)
Interesting ports on passoire (192.168.1.254):
PORT STATE SERVICE VERSION
873/tcp open rsync (protocol version 27)
-----------------------------------------------------------------------------
Mieux, cette machine est-elle publique, afin de tester ?
Elle est publique, mais rsync écoute sur une patte interne.
Dans la série des choses qui écoutent sur la patte publique, on trouve:
PORT STATE SERVICE VERSION
25/tcp open smtp Postfix smtpd
80/tcp open http thttpd 2.25b 29dec2003
C'est vrai, mais je parie qu'il s'est contenté de me renvoyer la
bannière pour le 25 et le 80
D'ailleurs, ce n'est pas tout à fait exact :
[www_fingerprinting_hmap.nasl]
This web server was fingerprinted as thttpd/2.25b through pound reverse proxy
which is consistent with the displayed banner: thttpd/2.25b 29dec2003
[smtpscan.nasl]
This server could be fingerprinted as being Postfix 2.0.16-2.1.3
Si le service a renvoyé la moindre donnée, z'avez gagné un voyage vers
http://www.insecure.org/cgi-bin/servicefp-submit.cgi
Oui mais non. Je ne vais pas me casser le trognon à faire tomber en
marche un truc que je crois voué à l'échec.
----------------------------------------------------------------------------- We got a ping packet back from 192.168.1.254: id = 27185 seq = 15883 checksum = 22467 Hostupdate called for machine 192.168.1.254 state UNKNOWN/COMBO -> HOST_UP (trynum 0, dotimeadj: yes time: 506) Finished block: srtt: 416 rttvar: 5000 timeout: 300000 block_tries: 1 up_this_block: 1 down_this_block: 0 group_sz: 1 massping done: num_hosts: 1 num_responses: 1 Starting pos_scan (Connect() Scan) Finished round #1. Current stats: numqueries_ideal: 30; min_width: 1; max_width: 1020; packet_incr: 4; senddelay: 0us; fallback: 69% NSOCK (0.3340s) TCP connection requested to 192.168.1.254:873 (IOD #1) EID 8 NSOCK (0.3340s) nsock_loop() started (no timeout). 1 events pending NSOCK (0.3350s) Callback: CONNECT SUCCESS for EID 8 [192.168.1.254:873] NSOCK (0.3350s) Read request from IOD #1 [192.168.1.254:873] (timeout: 5000ms) EID 18 NSOCK (0.3370s) Callback: READ SUCCESS for EID 18 [192.168.1.254:873] (12 bytes): @RSYNCD: 27. Starting pos_scan (RPCGrind Scan) Interesting ports on passoire (192.168.1.254): PORT STATE SERVICE VERSION 873/tcp open rsync (protocol version 27) -----------------------------------------------------------------------------
Mieux, cette machine est-elle publique, afin de tester ?
Elle est publique, mais rsync écoute sur une patte interne.
Dans la série des choses qui écoutent sur la patte publique, on trouve: PORT STATE SERVICE VERSION 25/tcp open smtp Postfix smtpd 80/tcp open http thttpd 2.25b 29dec2003
C'est vrai, mais je parie qu'il s'est contenté de me renvoyer la bannière pour le 25 et le 80
D'ailleurs, ce n'est pas tout à fait exact : [www_fingerprinting_hmap.nasl] This web server was fingerprinted as thttpd/2.25b through pound reverse proxy which is consistent with the displayed banner: thttpd/2.25b 29dec2003 [smtpscan.nasl] This server could be fingerprinted as being Postfix 2.0.16-2.1.3
Si le service a renvoyé la moindre donnée, z'avez gagné un voyage vers http://www.insecure.org/cgi-bin/servicefp-submit.cgi
Oui mais non. Je ne vais pas me casser le trognon à faire tomber en marche un truc que je crois voué à l'échec.
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/ NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/
Cyril
Et mettre derrière un IDS qui va détecter les port scan et DROP tout ce qui vient des machines coupables de ces actions. Et le hackers va blocker tout internet...
Cyril
Et mettre derrière un IDS qui va détecter les port scan et DROP tout ce
qui vient des machines coupables de ces actions.
Et le hackers va blocker tout internet...
Et mettre derrière un IDS qui va détecter les port scan et DROP tout ce qui vient des machines coupables de ces actions. Et le hackers va blocker tout internet...
