Bonsoir,
J’ai effectué un scan nmap et j’ai ,semble-t-il, deux problèmes.
nmap -v mon_ip
Port
80/tcp /open/http
443/tcp /closed/ https
Dois-je fermer le port 80 tcp?
Comment rendre le port 443 invisible avec Iptables?
Merci.
Bonsoir,
J’ai effectué un scan nmap et j’ai ,semble-t-il, deux problèmes.
nmap -v mon_ip
Port
80/tcp /open/http
443/tcp /closed/ https
Dois-je fermer le port 80 tcp?
Comment rendre le port 443 invisible avec Iptables?
Merci.
Un DROP sur les ports en question devrait faire l’affaire pour les passé en ‘stealth’, pour fermer le port 80 c’est possible mais si tu as un service derrière il ne sera plus en écoute.
Lesquels ?
Ça dépend de son usage.
Ça dépend du jeu de règles en place.
Bonsoir,
Pour le port 80, je pense que je peux le fermer vu que je n’ai pas de serveur.
Je pensais que DROP servait seulement à rejeter les paquets?
Voici les règles dont je me suis inspirée pour créer mon pare-feu:
INT_WAN=ppp0
INT_LAN=eth0
# initialisation de la table filter
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# initialisation de la table NAT
iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT
# initialisation de la table mangle
iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P INPUT ACCEPT
iptables -t mangle -P OUTPUT ACCEPT
iptables -t mangle -P FORWARD ACCEPT
iptables -t mangle -P POSTROUTING ACCEPT
# autoriser la carte réseau à dialoguer avec elle-meme
iptables -A OUTPUT -o lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
iptables -A INPUT -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
# activer la résolution de noms (DNS). Pratique pour pouvoir surfer sur internet
# avec les noms des sites plutot qu'avec les adresses ip ! ;o)
iptables -A INPUT -i $INT_WAN --protocol udp --source-port 53 -j ACCEPT
iptables -A OUTPUT -o $INT_WAN --protocol udp --destination-port 53 -j ACCEPT
iptables -A INPUT -i $INT_WAN --protocol tcp --source-port 53 -j ACCEPT
iptables -A OUTPUT -o $INT_WAN --protocol tcp --destination-port 53 -j ACCEPT
# ouverture des ports tcp http (80) et https (443) entre le firewall et internet
# c'est ici que vous pouvez autoriser d'autres protocoles (comme ftp) en suivant
# la meme syntaxe (une ligne input et une ligne output pour chaque protocole).
# Vous pouvez indiférement mettre le nom du protocole ou le numéro de port
# correspondant (par exemple http ou 80).
# Vous pouvez voir la liste des protocoles et ports associés dans le fichier /etc/services.
iptables -A INPUT -i $INT_WAN -d 0.0.0.0/0 -p tcp --sport http -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $INT_WAN -s 0.0.0.0/0 -p tcp --dport http -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $INT_WAN -d 0.0.0.0/0 -p tcp --sport https -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $INT_WAN -s 0.0.0.0/0 -p tcp --dport https -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
# autorise les paquets icmp (ping, traceroute, etc.) de votre ordinateur vers internet
# (mais pas d'internet vers votre ordinateur)
iptables -A INPUT -i $INT_WAN -p icmp -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $INT_WAN -p icmp -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
D’après ce site
https://gist.github.com/azlux/6a70bd38bb7c525ab26efe7e3a7ea8ac, on ne doit plus utiliser l’option RELATED?
salut,
heu, il me semble que Linux n’ouvre pas un port s’il n’y a pas un service en attente derrière.
Comme l’écrit @Watael, si le port est ouvert, c’est qu’il y a un serveur derrière. On peut identifier le processus qui écoute sur le port 80 avec la commande netstat (en root) :
netstat -ltnp | grep ":80.*LISTEN"
DROP sert à bloquer (silencieusement) les paquets.
C’est REJECT qui sert à rejeter les paquets (en renvoyant un paquet de refus ou d’erreur).
iptables -A INPUT -i $INT_WAN --protocol udp --source-port 53 -j ACCEPT
iptables -A INPUT -i $INT_WAN --protocol tcp --source-port 53 -j ACCEPT
Ho ho, le beau trou béant que voilà. Grâce à ces règles, un attaquant peut atteindre n’importe quel port TCP ou UDP de la machine en utilisant le port source 53. Si tu ne me crois pas, refais le scan avec nmap en forçant le port source (option -g/–source-port).
C’est pour cela qu’on a créé le suivi de connexion (-m state ou conntrack) : pour s’assurer qu’un paquet qui ressemble à une réponse à cause de son port source est vraiment une réponse à un paquet de requête qui a été envoyé. Cf; les règles pour HTTP et HTTPS.
# ouverture des ports tcp http (80) et https (443) entre le firewall et internet
Pas étonnant que ces ports répondent ouvert ou fermé au scan au lieu de rester silencieux. Si tu les commentes ils disparaîtront du scan.
Au passage, erreur sémantique : il ne s’agit pas d’ouverture de ports mais d’autorisation de paquets. L’ouverture d’un port est du ressort du processus qui s’en sert.
# autorise les paquets icmp (ping, traceroute, etc.)
Pour rappel, les programmes traceroute traditionnels sous Unix/Linux envoient par défaut des paquets UDP et non ICMP, donc ce type de traceroute ne fonctionnera pas. Ce sont seulement les réponses qui sont en ICMP. Et c’est le programme tracert de Windows qui envoie des paquets ICMP echo.
Pas du tout. Il faut lire la page jusqu’au bout. Elle ne concerne pas l’état RELATED mais un changement de la façon d’utiliser les “helpers” de protocoles complexes pour classer les paquets dans cet état, plus sûre.
Par contre l’état RELATED est et a toujours été inutile dans bon nombre de règles car inexistant avec les protocoles concernés comme HTTP, HTTPS, ou DNS. Il reste nécessaire pour les paquets d’erreur ICMP indispensables (destination-unreachable, parameter-problem, time-exceeded) et les protocoles “complexes” comme FTP.
Bonjour,
J’ai changé mon pare-feu et j’ai suivi les règles du sitehttps://debian-facile.org/doc:reseau:iptables-pare-feu-pour-un-client:
…
Autoriser les échanges avec les serveurs DNS
iptables -t filter -A OUTPUT -p udp -m udp
–dport 53 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -p udp -m udp\
--sport 53 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Pour naviguer sur le web
iptables -t filter -A OUTPUT -p tcp -m multiport\
--dports 80,443,8000 -m conntrack --ctstate\
NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -p tcp -m multiport\
--sports 80,443,8000 -m conntrack --ctstate\
RELATED,ESTABLISHED -j ACCEPT
Pour IMAP et SMTP (utilisation de messagerie icedove)
iptables -A INPUT -m multiport -p tcp --sport 25,2525,587,465,143,993,995 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m multiport -p tcp --dport 25,2525,143,465,587,993,995 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
Mais en suivant ces règles,les ports 53/tcp, 443/tcp, 8000/tcp et d’autres ports précités sont fermés mais visibles. J’ai donc rajouté l’option DROP à la place d’ACCEPT. Pour le port 53, pas de problème, mais pour les ports 443tcp et 8000tcp, Firefox ne se connecte plus à internet.
Comment alors les mettre en stealth?
Merci
(soupir)
Alors comme ça on va se fournir chez la concurrence et on s’étonne que ça ne marche pas ?
J’ai indiqué dans mon message précédent que l’état RELATED était inutile avec DNS et HTTP, c’est fou comme j’ai l’impression d’être écouté.
Quant à remplacer ACCEPT par DROP dans une règle, c’est le pompon. Ces règles servent à ACCEPTer les paquets des flux autorisés. Si tu mets DROP à la place, ces flux seront bloqués ! Elles n’ont strictement rien à voir avec le fait que les ports locaux de ta machine apparaissent comme fermés ou masqués. Ce sont d’autres règles ou les politiques par défaut qui s’occupent de ça. Donc il faut étudier le jeu de règles complet pour en déduire son comportement.