Re: Script Iptables pour serveur web Apache2 MySQL ProFTPD avec Port Knocking pour SSH
Le 25/09/2019 à 14:14, G2PC a écrit :
# J'enlève la valeur SYN et l'accès web et terminal fonctionne
correctement.
-A PREROUTING -p tcp -m multiport --dports 22,80,443 -m tcp
--tcp-flags FIN,RST,ACK SYN -j CT --notrack
Cette règle n'a aucune chance de s'appliquer puisque la combinaison
masque/drapeaux est impossible. Tu testes un drapeau qui n'est pas
dans le masque, ça ne peut pas marcher.
Hum. Bon, je te crois, je commente donc cette règle, le temps d'avoir
plus d'informations sur raw et les règles conseillées.
Est ce que le masque avec le SYN (que j'ai retiré) " FIN,SYN,RST,ACK SYN
" est plus cohérente que " FIN,RST,ACK SYN " ?
Bien sûr. C'est de l'algèbre booléenne de base. La seconde liste de
--tcp-flags doit être incluse dans la première liste.
"FIN,RST,ACK SYN" signifie "conserver les valeurs des drapeaux FIN, RST
et ACK et mettre à 0 les autres (dont SYN), puis renvoyer vrai si dans
le résultat SYN=1 (ce qui est impossible) et tous les autres à 0".
Comme dit, avec le SYN en deuxième position, les accès sont coupés une
fois que je place la règle *filter
L'état UNTRACKED doit interférer soit avec le filtrage en entrée, soit
avec le filtrage en sortie. Si un paquet SYN a été classé UNTRACKED,
alors les paquets suivants de la poignée de main (SYN+ACK sortant et ACK
entrant) sont classés par défaut dans l'état INVALID.
# Je ne sais pas si il est nécessaire d'autoriser le loopback vers
l'extérieur, voir à trouver un exemple.
Cette phrase n'a aucun sens puisque le trafic envoyé sur l'interface
de loopback ne va pas vers l'extérieur mais revient.
Tu parles de mon commentaire concernant la règle OUTPUT qui n'a pas de
sens, dès lors ?
Je parle de la phrase ci-dessus que j'ai laissée.
-A OUTPUT -m conntrack ! --ctstate INVALID -j ACCEPT
Typiquement, le paquet de réponse SYN/ACK à un paquet SYN dans l'état
UNTRACKED (à cause de -j CT --notrack) serait classé par défaut dans
l'état INVALID. Je ne connais pas l'interaction éventuelle avec SYNPROXY.
Je ne sais pas comment appréhender ce retour.
Le -j CT --notrack est dans la ligne qui a été désactivée dans la table *raw
A suivre.
Tu pourrais accepter les paquets SYN+ACK sortants ayant un des ports
source concernés par le SYNPROXY.
# Autoriser les connexions DNS.
-A INPUT -p tcp --dport 53 -j ACCEPT
La machine fait serveur DNS pour l'extérieur ?
Je ne pense pas ? C'est à dire, est ce qu'elle transmet des informations
vers un autre service extérieur ?
C'est-à-dire qu'elle répond à des requêtes DNS.
Hormis les pages web, non, donc, si je t'entend bien, je peux supprimer
les règles DNS ?
Il vaut mieux ne pas supprimer les règles qui acceptent les requêtes DNS
en sortie.
Qu'est-ce que la connexion fstp ?
Oups ! sFTP
Ça utilise SSH, donc rien à voir avec le protocole FTP.
-A OUTPUT -p tcp --sport 21 -m state --state ESTABLISHED -j LOG_ACCEPT
-A OUTPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state
--state ESTABLISHED -j LOG_ACCEPT
Inutiles puisque ces paquets ont déjà été acceptés par la règle
générique qui autorise les connexions déjà établies.
De toute façon, serait-il vraiment nécessaire de loguer ces paquets ?
ça fait beaucoup de paquets à loguer ?
Ça loguerait tous les paquets sortants des connexions de commande et de
données FTP, soit grosso modo un paquet par commande FTP et un paquet
par bloc de 1400 octets de données de fichier téléchargé ou de contenu
de répertoire lu. Je ne vois pas l'intérêt, loguer le premier paquet suffit.
Le client me dit ceci, on observe que j'arrive bien à me connecter la
première fois, puis, sur un second compte il n'arrive pas à récupérer le
contenu du dossier.
Je me reconnecte au second compte, et, il arrive alors a récupérer le
contenu du dossier. Vraiment étrange.
Statut : Connexion à 139.99.173.195:21...
Statut : Connexion établie, attente du message d'accueil...
Statut : Initialisation de TLS...
Statut : Vérification du certificat...
Statut : Connexion TLS établie.
Note : si tu utilises TLS avec FTP, alors le module de suivi de
connection nf_conntrack mentionné dans mon message précédent est aveugle
et inutile.
Statut : Récupération du contenu du dossier...
Commande : PWD
Réponse : 257 "/" est le répertoire courant
Commande : TYPE I
Réponse : 200 Type paramétré à I
Commande : PASV
Réponse : 227 Entering Passive Mode (139,99,173,195,202,139).
Commande : LIST
Erreur : Connection interrompue après 20 secondes d'inactivité
Il faudrait vérifier le port source utilisé par le client pour la
connexion de données servant au listage. Attention : si le client est
derrière un dispositif NAT (routeur, box), ce dernier peut modifier le
port source à la volée. Regarde dans les logs générés par iptables.
-A INPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j
LOG_ACCEPT
-A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state
--state ESTABLISHED,RELATED,NEW -j LOG_ACCEPT
Côté serveur, tu ne maîtrises pas la plage de ports du client.
Restreindre les ports source du client à la même plage que celle du
serveur est abusif.
Pas si sur de bien comprendre, car, j'ai pu lire sur certains tutoriels
qu'il faut au contraire ouvrir la plage de port via Iptables.
Si je commente la règle -A INPUT -p tcp --sport 49152:65534 --dport
49152:65534 -m state --state ESTABLISHED,RELATED,NEW -j LOG_ACCEPT
Il n'est pas question de supprimer la règle mais de la rendre plus
permissive en supprimant la condition sur le port source.
# Autoriser les connexions au serveur web Apache2.
-A INPUT -p tcp --dport 80 -j ACCEPT
-A OUTPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT
-A OUTPUT -p tcp --dport 443 -j ACCEPT
Maintenant que ces paquets sont acceptées, toutes les règles suivantes
censées les limiter ne s'appliqueront pas.
Dès lors, il me faut remonter les restrictions du serveur, avant
l'ouverture des services ?
A toi de décider comment tu veux organiser tes règles en sachant
qu'ACCEPT et DROP sont des cibles terminales qui interrompent la lecture
des règles suivantes de la chaîne.
# ATTENTION !
# Un attaquant qui s'en rendrait compte pourrait forger des paquets
TCP vers un de ces ports mais avec de fausses adresses IP.
Et il ne recevrait pas les réponses sauf s'il est situé à un
emplacement stratégique du réseau sur le chemin des paquets, donc
intérêt limité en pratique.
Quand tu dis qu'il est situé à un emplacement stratégique du réseau, tu
parles de sa capacité à forger des paquets TCP ?
Non. N'importe qui peut faire ça. Je parle d'un emplacement qui lui
permet de recevoir les paquets de réponse, donc sur le chemin de retour
des paquets vers le propriétaire légitime de l'adresse forgée.
Poser des ports piégés est limité, c'est ce que tu confirmes ?
Non, ce n'est pas ce que j'ai voulu dire. Je n'ai répondu que sur le
point des adresses forgées.
Si il (
l'attaquant ) ne reçoit pas de réponse, et, qu'il se fait bloquer 24h,
c'est plutôt efficace alors, non ?
Le but d'un scan de ports est normalement de recevoir des réponses
donnant des informations sur les ports ouverts et fermés. Si on fait un
scan de port avec une adresse forgée sans pouvoir recevoir les réponses
même sans filtrage, ça ne sert à rien.
Reply to: