Bonjour à tous,
Je viens car je souhaiterai avoir quelques tout petits éclaircissements par rapport aux ports réseau.
En paramétrant mon firewall pour un serveur, j'ai voulu être très restrictif.
En autorisant des entrées/sorties de packets sur un port, le 80 par exemple pour mon DynDNS, j'ai rentré ces règles :
(DROP par defaut)
INPUT -s ip_distante -d ip_local -p tcp --sport 80 --dport 80 -j ACCEPT
OUTPUT -s ip_local -d ip_distante -p tcp --sport 80 --dport 80 -j ACCEPT
Et bisarrement en loggant les DROPs pour comprendre pourquoi ca bloque :
IN=eth0 OUT= SRC=ip_distante DST=ip_local LEN=60 TOS=0x00 PREC=0x00 TTL=52 ID=35450 DF PROTO=TCP SPT=80 DPT=38109 WINDOW=65535 RES=0x00 ACK SYN URGP=0
Et la je remarque que le port interne a changé?!?
Le seul moyen de laisser passer les packets est de retirer le --dport pour INPUT et --sport pour OUTPUT.
Est-ce normal? Est-ce qu'il n'y a pas un risque que quelqu'un se connecte en 80 et passe en 21 par exemple pour un éventuel ftp non ouvert sur l'internet?
Je demande car j'ai vu quelque part qu'on pouvais depuis l'extérieur connaitre l'existante d'un port ouvert avec un nmap sur le port 80.
Voila merci d'avance pour les futurs explications.
# Oui
Posté par ChickenKiller . Évalué à 7.
Sans vouloir être méchant, un simple conseil, se lancer dans la config d'un firewall avec des connaissances aussi light en TCP/IP… je te conseille de te documenter un peu plus sur le sujet au risque de faire des grosses bétises et te retrouver avec une passoir en voulant faire une ligne Maginot. Je vais tout de même essayer de répondre.
Alors, oui le port côté client est choisi de manière aléatoire sauf cas TRES spécifique (que je n'ai jamais vu en pratique dans des softs "sérieux" même si les lib le permettent).
Niveau sécurité, il n'y a pas de problèmes: les ports serveurs sont figés. Il est souvent suffisant de vérifier ce numéro pour faire un filtrage basique. Après si tu veux être sûre que ton client n'est pas un petit malin qui a configurer sont VPN sur le port 443 (le port de https)… Il va falloir sortir un autre genre d'artillerie à base d'analyse de signature de paquets, mais je doute que ce soit ton but.
Après tu parle de nmap qui verrait des ports ouvert de l'exterieur: on parle ici de port ouvert sur ton routeur/firwall/boite à camenbert connectée directement à internet (après ce port peut avoir été forwardé, mais c'est encore une autre histoire)
Bon courage et bonne lecture.
[^] # Re: Oui
Posté par nono14 (site web personnel) . Évalué à 3.
Les ports < 1024 sont réservés à "root".
Les clients peuvent utiliser les ports entre 1024 et 65535 si dispos.
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Tuto réseau & iptables
Posté par Olivier (site web personnel) . Évalué à 3.
Il y a quelques années, j'ai écrit un tuto avec les bases de TCP/IP : http://olivieraj.free.fr/fr/linux/information/firewall/fw-01.html
Et la suite est un tuto sur iptables : http://olivieraj.free.fr/fr/linux/information/firewall/fw-03.html
Cela devrait être une bonne base assez simple pour commencer.
[^] # Re: Tuto réseau & iptables
Posté par Ovopack . Évalué à 1.
MDR!!!! la coincidence!!
J'étais justement sur ton site les deux derniers jours. Super en passant!
J'ai lu pour le moment uniquement les 2-3 pages sur la sécurité mais je comptais bien tout lire :P
[^] # Re: Tuto réseau & iptables
Posté par bubar🦥 (Mastodon) . Évalué à 2. Dernière modification le 04 octobre 2014 à 20:21.
Bonjour Olivier,
Je profite de ce fil pour insérer un grand MERCI hors sujet pour ce tuto. Une véritable petite bible pour le jeune que je fus, en 2003~4 et 5. Je sais d'où viennent ce que sont aujourd'hui mes habitudes d'usages.
[^] # Re: Oui
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
ntpd
# C'est normal
Posté par nanard . Évalué à 2.
Tu ne peux pas prévoir quel port tu vas utiliser en local pour établir une connexion vers un service ftp/www etc…
Mais iptables peux suivre les connexions avec le module conntrack
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p tcp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Ici tu accepte les connexion sur le port 80 en entrée et laisse passer le traffic relative à une connexion préalablement acceptée sur la deuxiéme régles.
Allez tous vous faire spéculer.
# rep
Posté par Ovopack . Évalué à -2. Dernière modification le 02 octobre 2014 à 18:49.
Merci pour les réponses.
Non je ne suis pas une bille en réseau mais j'ignorait ces notions de ports internes à l'ordinateurs n'ayant eu qu'à ce jour à configurer des firewalls simplistes.
Pour info, mon fichier de config:
iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6
[^] # Re: rep
Posté par nanard . Évalué à 2.
Yop,
Vite fait ce que je pense de tes régles, le module state est obsoléte voir conntrack, pour le ddos un bon ids qui rajoute des cibles tarpit peux être bien plus intéressant et chiant pour les méchants, et je limiterai les logs, tu vas en être submergé et ça sera inutilisable " -m limit --limit 3/min --limit-burst 3 ".
Allez tous vous faire spéculer.
# Salut
Posté par Marotte ⛧ . Évalué à 3. Dernière modification le 02 octobre 2014 à 16:50.
Je confirme pour l'usage d'un nombre aléatoire (généralement élevé…) pour le port client (ou sur le serveur également, par exemple pour le FTP passif), c'est comme ça pour la grande majorité des protocoles.
Tu peux voir les connexions TCP actives à l'aide de la commande
netstat -atupn
, dont voici une ligne extraite de la sortie de cette commande chez moi maintenant, correspondant à la connexion initiée par mon navigateur vers linuxfr.orgtcp 0 0 10.200.1.104:56216 88.191.250.176:443 ESTABLISHED 5128/x-www-browser
Tu as tout compris. Sauf que je dirais l'inverse. Dans le cas du paquet rejeté que tu donnes en exemple :
Ton paquet est rejeté par la règle sur la chaîne INPUT et c'est normal. (spt=80 et dpt=80 impossible)
Dans le cas de DynDNS :
Je pense que tu peux faire, sans le port source (celui de ton visiteur) mais celui de destination (celui de ton serveur que tu sais que c'est le 80) pour ce qui entre, l'inverse pour ce qui sort (les réponses que va faire ton serveur à tes clients)
INPUT -d ip_local -p tcp --dport 80 -j ACCEPT
OUTPUT -s ip_local -p tcp --sport 80 -j ACCEPT
Tu n'as pas besoin de préciser d'adresse pour tes visiteurs à priori, ils peuvent avoir n'importe quelle adresse…
EDIT: Les règles données par Elie sont mieux !
```
# rep
Posté par Ovopack . Évalué à 1.
Oui, j'ai lu que state était obselète mais qu'il appelait en réalité conntack et que si on n'avais pas besoin d'option spéciale de conntrack, on pouvait simplifier par state.
Pour les logs, effectivement j'ai retiré la limit pour faire un DEBUG, le temps de résoudre mes problème de bloquage.
Et concernant l'anti DDOS, oui il y a beaucoup mieux mais j'ai fait au plus simple. Pas grave si mon serveur est inccessible un certain temps, j'ai déjà d'autre attack SSH à régler déjà…
[^] # Re: rep
Posté par nanard . Évalué à 2.
Pour ssh ça devrais être simple à gérer, tu n'authorise que les identifications par clé plus par mot de passe (et jamais pour root!!!) et tu rajoute du port knocking, la packet knockd fait ça trés bien, la mise en place est extrèmement simple.
Allez tous vous faire spéculer.
# rep
Posté par Ovopack . Évalué à 1.
Merci Marotte pour les améliorations. Je vais regarder ca de près.
Dernière question :
Les packets entrant est-ce qu'ils ont l'ip de ma box ou l'ip des sites webs?
[^] # Re: rep
Posté par Ovopack . Évalué à 1.
non c'est bon trouvé! :P
[^] # Re: rep
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 02 octobre 2014 à 17:11.
Oui j'espère, les paquets ont deux adresses IP ;)
http://fr.wikipedia.org/wiki/IPv4#En-t.C3.AAte_IPv4
[^] # Re: rep
Posté par Ovopack . Évalué à 1.
je demandais pour l'ip source. J'ai eu un doute autorisant tout le traffic local puissant les trames internet passent par l'ip interne de la box… mais non, ca doit être une question de couche vu que le serveur voit bien les ip internet.
Sinon, il n'y a plus qu'à faire un script de routine pour ajouter les nouvelles ip de host.deny.
Et voila!
merci à tous
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.