bonjour, il y a une chose que j’ai du mal à comprendre
à l’installation, iptables est vide, il n’y a aucune règle. C’est logique.
Mais quand je fais un nmap sur mon ip je m’aperçois que par défaut il y a trois ports de filtrés; 25, 465, 587.
Comment ca se fait s’il n’y a pas de règle de filtrage?
Le port 587 c’est quoi ? il y a marqué submission.
quand on fait un serveur on a pas besoin de filtré ces ports là?
Tu exécutes nmap depuis où ? La machine elle-même, une autre machine du réseau local, une autre machine sur internet ?
Le protocole Submission est un sous-ensemble du protocole SMTP destiné à la soumission de mails par un MUA (“mail user agent”, client mail comme icedove/thunderbird) au lieu de la transmission de mails par un MTA (“mail transfer agent” servant de relais comme postfix, exim ou sendmail).
En bref, tous ces ports sont liés à l’envoi de mail. Certains FAI les bloquent en entrée et/ou en sortie sauf pour l’accès à leurs propres serveurs relais, pour limiter le spam.
je fais un nmap depuis un second serveur apparemment sur le réseau local puisque lorsque j’utilise un site internet pour nmaper j’obtiens la totalité des ports fermés.
Du coup je trouve que c’est très étrange. Comment ca se fait qu’ils ne sont pas accessible depuis l’extérieur? Il y a des filtres non visible par iptable?
J’essais de déterminer les règles de filtres de bases nécessaires à un serveur.
Et ce second serveur, il n’a pas de règles de filtrage, pas de pare-feu ?
c’est plus une instance ubuntu d’appoint qu’un serveur en fait. c’est pour ca que ca m’intéresse pas de le paramétrer même si en faisant un nmap sur lui-même j’ai obtenu le même filtrage.
[mono]iptables-save[/mono] t’affichera les règles iptables en place sur cette machine.
bon j’ai démarré une instance debian, nmap sur soi-même j’obtiens ssh ouvert,alors que smtp, smtps et submission filtré
iptables -L n’affiche rien tout en accept aucune règle
iptables-save
Qu’entends-tu exactement par “nmap sur soi-même” ?
nmap sur le serveur 2 à partir du serveur 2.
Ce que je remarque c’est que ce sont les même résultats qu’avec le nmap du serveur dédié à partir du serveur 2.
Ce sont des machines physiques ou virtuelles ?
Le serveur dédié est physique, pour l’autre c’est un peu particulier.
du coup le résultat sur le serveur dédié c’est
et ca c’est totalement reproductible puisque ca correspond à une netinstall sans aucune modification
Que donne nmap du serveur vers lui-même ?
Depuis une autre machine “normale” du LAN vers le serveur ?
ca je pourrais pas le dire, je n’ai qu’un serveur physique
Cela n’empêche pas de faire le nmap sur lui-même.
Et les instances d’Ubuntu et Debian dont tu parlais, d’où sortent-elles ?
autant pour moi, le nmap du serveur vers lui-même correspond au deuxième quote que j’ai publié.
les instances c’est en fait du cloud dédié, il faut voir le site de scaleway (online.net) pour comprendre, en gros ils ont une batterie de cpu+ram ARM et une batterie de disque dur, tu peux louer une qantité de stocage et un certain nombre d’IP le cloud va assembler automatiquement le tout.
Les seules citations dans tes messages contiennent les résultats d’iptables-save, pas de nmap.
Si j’ai bien compris tu testes depuis une espèce de VPS (serveur virtuel) qui n’est pas dans le même LAN que la machine cible. Il faut vraiment t’arracher les informations une par une. Je ne sais toujours pas si la machine cible est chez toi ou chez un hébergeur, mais je suis convaincu que les ports filtrés sont le fait du prestataire du VPS source ou du FAI/hébergeur de la machine cible.
serveur physique dedibox chez prestataire donc.
serveur VPS possiblement sur le même réseau car même prestataire (filiale différente).
Quand je lancais le nmap depuis un site internet j’obtenais la totalité des ports du serveur fermés.
entre temps j’ai installé le ssh sur le serveur, quand je lance un nmap sur lui-même j’obtiens le port ssh comme étant le seul port ouver.
Quand je relance le nmap depuis le “vps” j’obtiens port ssh ouvert + smtp smtps et submission filtrés.
du coup c’est bizare que ces ports filtrés n’apparaissent que depuis les “vps”
edit, j’actualise le nmap depuis pentest-tools.com
edit2 : je me rend compte que ce test depuis pentest-tool ne prenait en compte que le protocol tcp…
[quote]Starting Nmap 6.00 ( nmap.org ) at 2015-11-29 11:53 EET
Initiating Ping Scan at 11:53
Scanning xxx [4 ports]
Completed Ping Scan at 11:53, 0.06s elapsed (1 total hosts)
Initiating SYN Stealth Scan at 11:53
Scanning xxx (xxx) [5000 ports]
Discovered open port 22/tcp on xxx
Completed SYN Stealth Scan at 11:53, 0.71s elapsed (5000 total ports)
[+] Nmap scan report for xxx (xxx)
Host is up (0.0090s latency).
Not shown: 4999 closed ports
PORT STATE SERVICE
22/tcp open ssh[/quote]
Comment faisais-tu pour accéder au serveur dédié sans SSH ?
Par défaut, nmap aussi : -sS (TCP SYN scan) si exécuté en root ou -sT (TCP connect scan) si exécuté en utilisateur normal. Si tu veux un scan de ports UDP, il faut le spécifier avec -sU.
Au vu de tes derniers résultats, je maintiens : le filtrage des ports vient du VPS.
en utilisant le KVM sur IP
ok je savais pas que c’était possible, donc si un parefeu est appliqué au client, le nmap du serveur va montrer du filtrage même si tout est ouvert sur le serveur donc?
Oui, bien sûr. [mono]Nmap[/mono] ne met pas en évidence le filtrage spécifique à la cible mais tout filtrage intervenant entre la source et la cible, sans pouvoir déterminer où exactement. Pour cela, il faut utiliser un outil comme [mono]traceroute[/mono] avec le protocole et le port (figé pour UDP, sinon l’expérience est faussée par l’incrémentation automatique) bloqué.
Exemple :