TCPDUMP NMAP SCANTCP IPTABLES résultats incohérents

usinagaz · Février 20, 2016, 3:17pm

Bon, j’aimerai comprendre pourquoi aucun de ces outils ne me donne le même résultats quant aux ports ouverts, fermés, etc … PIRE, ça correspond pas du tout à ce que renvoie iptables -L

[code]nmap -T4 192.168.1.100

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-11-06 01:49 CET
Interesting ports on debian.localdomain (192.168.1.100):
(The 1632 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
98/tcp open linuxconf
111/tcp open rpcbind
139/tcp open netbios-ssn
161/tcp open snmp
162/tcp open snmptrap
443/tcp open https
512/tcp open exec
513/tcp open login
514/tcp open shell
515/tcp open printer
635/tcp open unknown
1026/tcp open LSA-or-nterm
1027/tcp open IIS
1032/tcp open iad3
1433/tcp open ms-sql-s
1434/tcp open ms-sql-m
4899/tcp open radmin
5900/tcp open vnc
8888/tcp open sun-answerbook
12345/tcp open NetBus
12346/tcp open NetBus
16959/tcp open subseven
27374/tcp open subseven
31337/tcp open Elite
32771/tcp open sometimes-rpc5
32772/tcp open sometimes-rpc7
32773/tcp open sometimes-rpc9
32774/tcp open sometimes-rpc11
54320/tcp open bo2k

Nmap finished: 1 IP address (1 host up) scanned in 0.246 seconds[/code]
Déjà là, vu que :

[code]# iptables -L |grep ftp-data && iptables -L |grep ssh; \

cat /etc/services |grep ftp-data && cat /etc/services |grep ssh
ACCEPT tcp – anywhere anywhere tcp spt:ftp-data
ACCEPT tcp – anywhere anywhere tcp dpt:ftp-data
ftp-data 20/tcp
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp[/code]
Iptables me donne le port 20 ouvert et le port 22 fermé, nmap le contraire … je continue …

[quote=“Scan Tcp”]Voici les résultats du Scan de l’adresse IP 83.201.xxx.xxx entre le port 20 et 23

Le port TCP 20 est fermé
Le port TCP 21 est ouvert
Le port TCP 22 est fermé
Le port TCP 23 est fermé
[/quote]Encore mieux …
Quant à tcp dump :

# tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 02:20:37.495361 IP 202.155.58.124.2480 > debian.localdomain.radmin-port: . 2264758945:2264758946(1) ack 2228824979 win 16616 02:20:37.553798 IP debian.localdomain.radmin-port > 202.155.58.124.2480: . ack 0 win 0 02:20:37.496225 IP debian.localdomain.32800 > 192.168.1.1.domain: 10107+ PTR? 124.58.155.202.in-addr.arpa. (45) 02:20:37.553497 IP 192.168.1.1.domain > debian.localdomain.32800: 10107 NXDomain 0/1/0 (110) 02:20:37.554025 IP debian.localdomain.32800 > 192.168.1.1.domain: 22714+ PTR? 1.1.168.192.in-addr.arpa. (42) 02:20:37.608428 IP 192.168.1.1.domain > debian.localdomain.32800: 22714 NXDomain 0/1/0 (119) 02:20:42.494326 arp who-has 192.168.1.1 tell debian.localdomain 02:20:42.494845 arp reply 192.168.1.1 is-at 00:xx:xx:xx:xx:xx 02:20:53.194091 IP 24.178.107.97.1035 > debian.localdomain.radmin-port: . 142979337:142979338(1) ack 417437647 win 16616 02:20:53.194148 IP debian.localdomain.radmin-port > 24.178.107.97.1035: . ack 0 win 0 02:20:53.194390 IP debian.localdomain.32800 > 192.168.1.1.domain: 58435+ PTR? 97.107.178.24.in-addr.arpa. (44) 02:20:53.571973 IP debian.localdomain.36645 > by1msg3145606.phx.gbl.1863: P 3307095068:3307095073(5) ack 368311994 win 243 <nop,nop,timestamp 18694023 1770207> 02:20:53.781089 IP by1msg3145606.phx.gbl.1863 > debian.localdomain.36645: P 1:9(8) ack 5 win 65013 <nop,nop,timestamp 1770808 18694023> 02:20:53.781149 IP debian.localdomain.36645 > by1msg3145606.phx.gbl.1863: . ack 9 win 243 <nop,nop,timestamp 18694232 1770808> 02:20:58.193276 IP debian.localdomain.32801 > 192.168.1.1.domain: 58435+ PTR? 97.107.178.24.in-addr.arpa. (44) 02:20:58.249486 IP 192.168.1.1.domain > debian.localdomain.32800: 58435 ServFail 0/0/0 (44) 02:20:58.250294 IP 192.168.1.1.domain > debian.localdomain.32801: 58435 ServFail 0/0/0 (44) 02:20:58.250679 IP debian.localdomain.32801 > 192.168.1.1.domain: 47557+ PTR? 17.107.46.207.in-addr.arpa. (44) 02:20:58.308690 IP 192.168.1.1.domain > debian.localdomain.32801: 47557 1/0/0 (79) 02:21:02.598419 IP 202.97.238.132.35321 > debian.localdomain.1026: UDP, length: 458 02:21:02.598674 IP debian.localdomain.32801 > 192.168.1.1.domain: 50210+ PTR? 132.238.97.202.in-addr.arpa. (45) 02:21:02.657272 IP 192.168.1.1.domain > debian.localdomain.32801: 50210 NXDomain 0/1/0 (134)Disons que je comprend les lignes de dialogue entre mon poste et la livebox (192.168.1.1), ce que je ne comprend pas :

pourquoi une ip entre en connexion avec moi sur radmin-port, alors qu’il n’est pas ouvert par iptables …
idem pour tous les autres ports, qui normalement ne sont pas ouverts …
j’ai ces règles aussi pour chaque table, aprés ouverture des ports que je souhaite :

[quote]# rappel Chain INPUT (policy DROP)
ACCEPT all – anywhere anywhere state RELATED,ESTABLISHED

rappel Chain OUTPUT (policy DROP)

ACCEPT all – anywhere anywhere state NEW,ESTABLISHED[/quote]
et FORWARD, tout est ACCEPT (malgré la police par defaut qui est DROP).
Est-ce que c’est ça qui va pas ?
De plus, je comprend pas pourquoi Aucuns paquets des droppé, ça veut dire que ça drop pas, ou quoi ?
Bref, lequel dit vrai ?

mattotop · Février 20, 2016, 3:17pm

Déjà, tu ne fais pas ton nmap et ton tcpscan sur la même adresse, donc ça peut être normal de ne pas avoir les mêmes résultats.
Pour ton accés au port radmin, du coup, c’est normal que ça passe: le nmap que tu as fait etant sur le 192.168.1.100 montre bien que le port est ouvert. Ce qui prouve bien que tu n’as pas, comme semnble l’indiquer le nmap, et contrairement à ce que tu dis activé de protection sur cette interface là (et je dirais même que tout passe de ce qui va vers le 192.168.1.100).
Ne pas confondre avec l’ip 83.201.xxx.xxx qui est une interface DE TA LIVEBOX (pas de ta machine), et qui béneficie de son pare feu.
sinon, un bout d’iptables ne sert à rien: tu peux REJECTer par exemple ce qui va sur tel port, mais avoir une regle en amont qui ACCEPT pour une raison différente que tu ne vois pas si tu ne te préoccupe que des règles qui concernent le port.
Et mon but n’est pas de te pousser à rendre public ce que tu mets comme protection en place, notes bien, mais juste de dire qu’un bout d’iptables ne sert à rien.

Sinon, c’est quoi ce port backorifice ouvert (port 54320) ?

usinagaz · Février 20, 2016, 3:17pm

[quote=“MattOTop”]Déjà, tu ne fais pas ton nmap et ton tcpscan sur la même adresse, donc ça peut être normal de ne pas avoir les mêmes résultats.[/quote]trés juste, voici nmap sur l’ip de la livebox :

[quote](The 1660 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
23/tcp open telnet
80/tcp open http[/quote]c’est mieux déjà … mais je vois pas pourquoi ça ne correspond pas aux ports que j’ouvre via iptables … (ex : ssl/443 est fermé ? pas possible).

[quote=“MattOTop”]et je dirais même que tout passe de ce qui va vers le 192.168.1.100).[/quote]je suis horrifié … je te prépare la totale, la sortie de iptables -L, et le script qui m’a servi à initialiser le parefeu (c’est un script d’essai, donc on ne s’étonnera pas du résultat … mais faudrai m’aider à le corriger siouplait …)

[quote=“MattOTop”]Sinon, c’est quoi ce port backorifice ouvert (port 54320) ?[/quote]si je le savais …

fran.b · Février 20, 2016, 3:17pm

Bon,

Il faut définir ce que veut dire «port ouvert»: réponse: Rien!

Un port peut être en attente de connexion (LISTEN) ou bien initier une connexion.

Ouvrir un port en INPUT l’autorise à être en attente de connexion.
Ouvrir un port en OUTPUT l’autorise à initier une connexion.

Exemples:
Le port ftp-data initie une connexion sur le client.
Le port ftp est en attente de connexion.

Un scan de ports te donne les ports ouverts en écoute (Open) ou bien ouverts en écoute mais filtré (Filtered). En aucun cas ça ne te donnera les ports ouverts en sortie c’est à dire ceux apte à initier une connexion. Donc quand tu parles de ports ouvert, il faut préciser, usuellement c’est ouvert en écoute.

Par ailleurs, un scan local est un scan en loopback même si tu scannes ton IP 192.168.1.100. Un nmap fait en local n’a aucune signification.
Le port 443 apparait fermé parce que tu n’as sans doute pas fait le transfert de port entre la livebox et ta machine.
Fait un netstat -tpl pour voir les ports en écoute et régler cette histoire de back-o2
Pourquoi as tu du traffic sur radmin???

mattotop · Février 20, 2016, 3:17pm

[quote=“usinagaz”][quote=“MattOTop”]Déjà, tu ne fais pas ton nmap et ton tcpscan sur la même adresse, donc ça peut être normal de ne pas avoir les mêmes résultats.[/quote]trés juste, voici nmap sur l’ip de la livebox :[quote](The 1660 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
23/tcp open telnet
80/tcp open http[/quote]c’est mieux déjà … mais je vois pas pourquoi ça ne correspond pas aux ports que j’ouvre via iptables … (ex : ssl/443 est fermé ? pas possible).[/quote]Mais voyons, c’est une interface de ta livebox. Si tu ne redirige pas le port 443 de ta livebox sur ton serveur, c’est un peu normal que la livebox réponde que le port est fermé puisque c’est le cas. les ports qui apparaisent ouverts sur cette adresse sont ceux qui sont ouverts pour la livebox OU (ceux qui sont redirigés par ta livebox ET qui sont ouverts sur la machine ciblée par cette redirection).

[quote=“usinagaz”]Je pense qu’au regard de ce que je te présente ici, et en comparant avec les résultats fournis dans mon fil, tu auras une bonne vue d’ensemble de ce qui merdoie …

# iptables -L Chain INPUT (policy DROP) target prot opt source destination fail2ban-SSH tcp -- anywhere anywhere tcp dpt:ssh[/quote]Bon, ça OK.[quote=“usinagaz”]TARPIT tcp – anywhere anywhere tcp dpt:54321
(…)
TARPIT tcp – anywhere anywhere tcp dpt:www STRING match “defaut.ida” ALGO name bm TO 65535[/quote]je comprends mieux le backorifice.
Il aurait pu te venir à l’idée qu’un port en TARPIT n’est pas un port fermé: c’est un peu normal de faire apparaitre le port ouvert pour tromper l’ennemi, non ?
Ca explique un peu mieux ton nmap ?[quote=“usinagaz”]ACCEPT all -- anywhere anywhere (...)[/quote]Cherches pas plus loin, cette règle là qui est juste aprés le TARPIT fait qu’aucune des règles qui suivent ne sera jamais atteinte.
En fait avec ta config actuelle, tout ce qui n’est pas tarpité est accepté.

[quote=“usinagaz”]Remarques :

je suis pas sur que le tarpitage fonctionne, comment le tester, à partir de mon post windaube en lançant une requete http sur un port tarpité ?[/quote]Aucune idée. Fais ecouter un service sur le port que tu veux tester, essayes pour voir s’il marche, actives le tarpit, et reessayes pour voir si ça bloque ?[quote=“usinagaz”]Comme ma webcam n’est plus accessible, je me dis qu’il y a forcément des règles de rejet d’output ou input qui fonctionne,[/quote]Tu as vraiment besoin de te préoccuper de ce qui sort de ta machine ? Tu ne crois pas que commencer par règler ce qui tente d’y rentrer est déjà suffisament prise de tête pour ne pas multiplier les problêmes.quote=“usinagaz”
Enfin, ce que je veux, c’est une conf simple, efficace, qui :
1/ ouvre les ports dont j’ai besoin pour mes services[/quote]Commence par tout bloquer, et règles ouvres les un par un en vérifiant à chaque fois. C’est pas franchement compliqué, si ?[quote=“usinagaz”]2/ tarpit tous les ports notoirement utilisé de façon nuisible[/quote]Ca, les règles sont bonnes.[quote=“usinagaz”]3/ drop et/ou ulog toute tentative de connexion sur un port fermé,[/quote]C’est déjà une règle de logdrop par défaut que tu as sur l’input. Les ports qui ne sont pas spécifiquement ACCEPTés sont déjà logdroppés.[quote=“usinagaz”] ouvert,[/quote]Euh! tu es sûr que tu veux loguer aussi le traffic légitime ? Ca devrait remplir ton disque plutot vite, non ?
ou tu penses surtout à des établissements de session (ouvertures de sessions tcp) ?[quote=“usinagaz”] tarpité,[/quote]ben ça, il faut juste que tu fasse une chaine logtarpit exactement comme la chaine logdrop, qui fasse un log et un tarpit, et qu’au lieu de simplement tarpitter les paquets qui matchent tes critères, tu les envoies dans la chaine logtarpit. quote="usinagaz"
Merci d’y jeter un oeil attentif Matt.[/quote]Pour le résultat d’iptables, je t’ai dit ce que j’avais à dire (à ce sujet, iptables -L est vraiment illisible: la prochaine fois, fournis plutôt un 'iptables-save, c’est AMA salement plus lisible).
Pour le script d’ed, je n’ai pas du tout l’envie de l’analyser, d’autant plus que je ne fonctionne pas du tout comme ça (la méthode ricardo est en fait une mise au propre par ricardo de ma methode, même si je ne m’attribue pas le tuto que ça fait).
En fait, arrète de te prendre la tête avec des scripts bash complexes.
Affines ton parefeu à la main en ajoutant, supprimant les règles unes par unes, et quand tu en es content, tu fais juste un ‘iptables-save >unesauvegarde’ (fichier dump d’iptables d’ailleurs trés facile à modifier à la main si nécessaire), puis fais juste un script init qui fait un ‘iptables-restore <unesauvegarde’. Ca te permet de conserver plusieurs profils différents de configuration, et en plus, le iptables-restore met infiniment moins de temps que l’insertion une à une des règles par un script: chaque commande iptables necessite un calcul complet de la config, alors que ce calcul ne se fait qu’une fois à la fin de l’iptables-restore. quand tu n’as que dix règles, ça ne va donc que dix fois plus vite de faire un iptables-restore, mais quand tu en arrives à plusieurs centaines de règles, l’economie de plusieurs centaine de fois le même calcul (de plus en plus long au fur et à mesure du nombre de règles) devient VRAIMENT sensible.

usinagaz · Février 20, 2016, 3:17pm

ben non c’est pas normal, j’ai mis la DMZ, tous les ports sont redirigés, tout ce qui arrive sur la livebox est envoyé sur 192.168.1.100 …

usinagaz · Février 20, 2016, 3:17pm

Merci aussi pour tes précisions fran.b

Comme dit ci-dessus, ça devrait pourtant être le cas, je comprends pas( DMZ, que je viens de vérifier à l’instant sur 192.168.1.1) …

[quote=“fran.b”]
4) Fait un netstat -tpl pour voir les ports en écoute et régler cette histoire de back-o2[/quote]C’est sans doute parce que je le tarpit … je n’ai pas précisé tout à l’heure parceque je voulais me focaliser sur les ports que je trouve légitimes d’ouvrir en écoute pour mes services … Voici le netstat :

netstat -tpl (Tous les processus ne peuvent être identifiés, les infos sur les processus non possédés ne seront pas affichées, vous devez être root pour les voir toutes. ) Connexions Internet actives (seulement serveurs) Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name tcp 0 0 localhost:mysql *:* LISTEN - tcp 0 0 *:ftp *:* LISTEN - tcp 0 0 localhost:ipp *:* LISTEN - tcp 0 0 *:8888 *:* LISTEN - tcp 0 0 localhost:smtp *:* LISTEN - tcp 0 0 *:https *:* LISTEN - tcp6 0 0 *:ftp *:* LISTEN - tcp6 0 0 *:ssh *:* LISTEN -
C’est quoi ce tcp6, est-ce relatif à ipv6 ? Si oui, je pensais que la commande suggéré par MattOTop (de mettre à off dans modules_aliases, je suis en train de réaliser que modutils, c’est modutils, et que par conséquent, ce qui concerne module-init-tools doit plutôt se trouver dans /etc/modprobe.d/aliases, je commente donc la ligne là aussi).

Alors, ça, j’aimerai être sur que c’est du au tarpitage, mais je ne crois pas que ça fonctionne comme ça … fran.b, tu l’avais déjà un peu fait une fois je me souviens, tu voudrais pas traduire en langage humain ce que se disent les postes dans mon extrait de tcpdump (mis à par ce qui concerne la livebox), quand tu as un peu de temps ?

De toute façon, avec la réponse de Matt à mon mail privé, je vais tout reconfigurer pas à pas et à la main, sans me servir d’un script qui manipule un outil (iptables) que je ne maîtrise pas …

mattotop · Février 20, 2016, 3:17pm

ben non c’est pas normal, j’ai mis la DMZ, tous les ports sont redirigés, tout ce qui arrive sur la livebox est envoyé sur 192.168.1.100 …[/quote]alors c’est que ta livebox le bloque, mais ça ne vient pas de ton iptables, puisque le nmap sur l’interface 192.168.1.100 montre que le port est ouvert (puisque comme je te l’ai fait remarquer, ton parefeu est configuré pour tout accepter sauf les ports tarpités sans rien dire…

usinagaz · Février 20, 2016, 3:17pm

Oui, peut-être qu’un noob qui tente de configurer iptables derrière un routeur stupide de type livebox, ça me décrit bien en ce moment …

fran.b · Février 20, 2016, 3:17pm

Bon écoute, pour ton port 443 pour voir si ça marche, tu peux utiliser les scanneurs en lignes par exemple http://www.zebulon.fr/outils/scanports/test-securite.php, tu leur demandes un scan des ports et dans le tas, tu devrais voir passer un paquet sur le port 443 (par exemple) et voir si il transite sur ta machine 192.168.1.100 via tcpdump.

usinagaz · Février 20, 2016, 3:17pm

[code]
Ports TCP ouverts
21 ftp Utilisé pour le transfert de fichier entre ordinateurs
80 http Utilisé pour les services Web. Si vous n’utilisez pas de serveur web, il est conseillé de fermer ce port
443 https Utilisé pour sécuriser les communications HTTP. Si vous n’utilisez pas de serveur web, il est conseillé de fermer ce port. Ce port est également utilisé par AOL Instant Messenger

 Ports TCP fermés
22 	ssh 	Le shell SSH permet de se connecter à un serveur de façon sécurisée  	 
23 	telnet 	Utilisé pour obtenir un shell distant  	 
25 	smtp 	Utilisé pour le transfert de courrier électronique entre deux hôtes. Si vous n'utilisez pas de serveur de messagerie, il est conseillé de fermer ce port.  	 
79 	finger 	Permet de connaître diverses informations relatives à votre profil  	 
110 	pop3 	Utilisé par les serveurs de messagerie Internet. Si vous n'utilisez pas de serveur de messagerie, il est conseillé de fermer ce port.  	 
113 	auth 	Utilisé par certains serveurs de messagerie ou de newsgroups (MiRC - Virc...). Des problèmes de performances peuvent survenir si ce port est masqué  	 
139 	netbios-ssn 	Utilisé pour le partage de fichiers dans un réseau local  	 
143 	imap 	Utilisé par les serveurs de messagerie Internet pour l'envoi de messages électroniques. Si vous n'utilisez pas de serveur IMAP, il est conseillé de fermer ce port.  	 
1002 	N/A 	Port non standard  	 
1024 	N/A 	Port réservé  	 
1026 	N/A 	Port non standard  	 
1028 	N/A 	Port non standard  	 
1030 	N/A 	Port non standard  	 
1720 	h323hostcall 	Port non standard. Peut être utilisé par NetMeeting  	 

 Ports TCP masqués
119 	nntp 	Utilisé par les serveurs de news pour la distribution d'articles Usenet  	 
135 	N/A 	Utilisé pour les applications client/server basées sur des systèmes d'exploitation Microsoft  	 
389 	ldap 	LDAP (Lightweight Directory Access Protocol) : utilisé pour accéder automatiquement à des services d'annuaires en ligne  	 
445 	microsoft-ds 	Utilisé pour le partage des protocoles SMB. Son exploitation peut permettre d'obtenir vos mots de passe  	 
1025 	N/A 	Port non standard  	 
1027 	N/A 	Port non standard  	 
1029 	N/A 	Port non standard  	 
5000 	N/A 	Utilisé pour communiquer avec tous les périphériques UpnP reliés à votre réseau [/code]Ok merci, c'est mieux là déjà, ça correspondrait mieux à ce que me donne iptables-save :

[code]# Generated by iptables-save v1.3.5 on Mon Nov 6 21:08:47 2006
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [21455:3029737]
:LOG_DROP - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p igmp -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p udp -m udp --dport 1234 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 30000:33000 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1720 -j ACCEPT
-A INPUT -p udp -m udp --dport 5000:5006 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-port-unreachable
COMMIT

Completed on Mon Nov 6 21:08:47 2006

Generated by iptables-save v1.3.5 on Mon Nov 6 21:08:47 2006

*nat
:PREROUTING ACCEPT [79:10940]
:POSTROUTING ACCEPT [8681:354832]
:OUTPUT ACCEPT [8681:354832]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.100:443
COMMIT

Completed on Mon Nov 6 21:08:47 2006

Generated by iptables-save v1.3.5 on Mon Nov 6 21:08:47 2006

*mangle
:PREROUTING ACCEPT [20875:3867514]
:INPUT ACCEPT [20875:3867514]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [21455:3029737]
:POSTROUTING ACCEPT [21455:3029737]
COMMIT

Completed on Mon Nov 6 21:08:47 2006[/code]Le fait que le port 20 apparaisse pas comme ouvert, c’est ce que tu essayais de m’expliquer tantôt ? la nuance à saisir ?

le port 25, je dois pas l’ouvrir moi , c’est quand on a un serveur installé sur son poste ça, c’est juste ?

fran.b · Février 20, 2016, 3:17pm

[quote]# Generated by iptables-save v1.3.5 on Mon Nov 6 21:08:47 2006
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [21455:3029737]
:LOG_DROP - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p igmp -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
[/quote]
Kézako ce port 20??? Tu fais quoi dessus? tu ne confonds pas avec le port 80???

Alors là non, tu routes le port 80 vers le port 443 de ta machine, pas étonnant qu’il apparaisse fermé. Soit tu ouvre ton port 80 et ton serveur écoutera sur le port 80 avec apache-ssl. Me parait compliqué mais bon…

Soit tu écoutes sur le port 443, donc tu routes le port 443 vers ton serveur:443 (et tant qu’à faire aussi le port 80 vers ton serveur:80, Internet est une jungle c’est sur mais tu prends plus de risques en traversant la route!)

[quote]
COMMIT

Completed on Mon Nov 6 21:08:47 2006

Generated by iptables-save v1.3.5 on Mon Nov 6 21:08:47 2006

*mangle
REROUTING ACCEPT [20875:3867514]
:INPUT ACCEPT [20875:3867514]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [21455:3029737]
OSTROUTING ACCEPT [21455:3029737]
COMMIT

Completed on Mon Nov 6 21:08:47 2006[/quote]

usinagaz · Février 20, 2016, 3:17pm

Alors là je tombe des nues …

[quote=“fran.b”]
Kézako ce port 20??? Tu fais quoi dessus? tu ne confonds pas avec le port 80???[/quote]on voit partout que le port 20, c’est le port ftp-data en mode actif non ?

[quote=“fran.b”]
Alors là non, tu routes le port 80 vers le port 443 de ta machine, pas étonnant qu’il apparaisse fermé.[/quote] non mais tu as bien vu qu’il apparaissait ouvert maintenant, avec ces nouvelles règles iptables …

[quote=“fran.b”]Soit tu ouvre ton port 80 et ton serveur écoutera sur le port 80 avec apache-ssl. Me parait compliqué mais bon…[/quote]ça c’est ce que j’ai actuellement dans httpd.conf de apache-ssl (unique apache chez moi). C’est pour tenter une autre solution que j’ai testé cette règle iptables de redirection … Actuellement, en loopback, de mon post, la connection par http au serveur ssl est refusée, ce qui montre que cette règle ne semble pas fonctionner (même en faisant la même règle pour lo)

[quote=“fran.b”]
Soit tu écoutes sur le port 443, donc tu routes le port 443 vers ton serveur:443 (et tant qu’à faire aussi le port 80 vers ton serveur:80, Internet est une jungle c’est sur mais tu prends plus de risques en traversant la route!)[/quote]Alors là, sois on touche le point sensible, soit j’ai encore rien compris … pourquoi je devrais router avec iptables le 443 vers le 443 ? tu veux dire --dport 443 to mondomaine.com:443 (shématiquement) ?

fran.b · Février 20, 2016, 3:17pm

Arf pour le port 20, désolé une absence, le pire est que je viens de poster à ce sujet il y a moins d’un jour . Cela dit, ce port comme je l’ai dit plus haut (cf posts ci dessus) doit être ouvert en sortie pas en entrée:

Ce serait plutôt

 iptables -A OUTPUT  -p tcp --sport 20 -j ACCEPT

avec
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp – anywhere anywhere tcp spt:ftp-data

Si tu veux que ton serveur apparaisse normal de l’extérieur donc que

cheztoi.domaine.joli/

arrive à ton serveur, la requête va arriver sur le port 443 de la livebox qui doit le router vers le port 443.

Là, tel que c’est fait, ton serveur croit qu’il est sur le port 443 alors que les gens le voient sur le 80: pas grave, mais pour y accéder, il faudra taper

cheztoi.domaine.joli:80/

tandis que

cheztoi.domaine.joli/ et
cheztoi.domaine.joli/

vont t’envoyer paitre.

usinagaz · Février 20, 2016, 3:17pm

[quote=“fran.b”]Là, tel que c’est fait, ton serveur croit qu’il est sur le port 443 alors que les gens le voient sur le 80: pas grave, mais pour y accéder, il faudra taper
cheztoi.domaine.joli:80/[/quote]
Non non ça marche pas ça …; attends, j’explique :
apache-ssl peut écouter plusieurs ports gràce à la config :
LISTEN 80
LISTEN 443 (port par défaut évidemment, mais à spécifié si plusieurs)
LISTEN N
Mais de toute façon on redirige tout dans un bloc :

Redirect machin adresse:443

Or là, avec cette règle iptable, qui je pensais capable de remplacer ce bloc, de httpd.conf, ça ne fonctionne pas … donc oui je vais retirer cette règle.

Pour le port 20, ok je note que c’est en output, apparement on a même pas le moyen de l’ouvrir en INPUT, ou alors c’est que Scan Tcp et le test que tu m’as donné à faire ne scanne pas le port 20

ça fonctionne : cheztoi.domaine.joli/ et
ça ne fonctionne pas : cheztoi.domaine.joli/ et
ça ne fonctionne pas : cheztoi.domaine.joli:80

mattotop · Février 20, 2016, 3:17pm

au fait, tu as essayé dans tes tests des nmap plus violents (-sU -sT) ?
Parceque ce n’est pas parcequ’un scan donné te dit que le port est fermé que c’est vrai. Le syn scan ne fonctionne peut être pas dans tout les cas: c’est juste le scan nmap par defaut parcequ’il est plus discret (moins fiable ?).