Par exemple, pour ProFTPD, il me semble avoir configuré
correctement le
service, mais, le client FileZilla ne semble pas réussir à se
connecter
lors de toutes ses tentatives.
Actuellement, j'arrive régulièrement à me connecter au client
FTP, mais,
pas à 100%.
Je précise, ce n'est pas la connexion qui semble bloquer
occasionnellement, mais, la lecture des dossiers une fois
connecté,
d'après ce que je lis sur FileZilla.
Donc les connexions de données avec les ports de destination
dynamiques.
Est-ce que tu as chargé le module de suivi de connexion FTP
nf_conntrack_ftp ?
Si oui, est-ce que tu as réglé l'option nf_conntrack_helper du
module nf_conntrack à 1 puisque je ne vois pas de règle avec CT
--helper pour affecter explicitement le helper ftp aux connexions
de commande FTP ?
Alors la, bonne question !
J'ai vu passer ce mot clé " conntrack, quelques fois ses derniers
jours, mais, je ne crois pas avoir fait quoi que ce soit à ce
niveau.
Je vais chercher. Merci.
*raw
# Anti DDOS.
# Les paquets TCP avec le flag SYN à destination des ports 22,80
ou 443 ne seront pas suivi par le connexion tracker et donc
traités plus rapidement.
## Les pages ne chargent plus avec cette règle de décommentée
tout comme la connexion SSH devient impossible !
En temps normal, ce n'est pas seulement le paquet SYN mais tous
les paquets suivants (entrants et sortants) qu'il faut exclure du
suivi de connexion et accepter. Par contre j'ai vu que tu utilises
SYNPROXY qui interagit avec le suivi de connexion, mais je ne
connais pas bien.
Comme dit, pour raw, j'ai enlevé ce filtrage sur SYN, car, j'ai
un conflit avec *filter à ce moment la, et, je ne peux plus
naviguer sur les pages, ni me connecter via SSH avec ma règle Port
Knocking.
J'ai repris une règle présentée dans un tutoriel, et, je l'ai
laissée ainsi, en retirant SYN.
Idem, j'ai peu d'informations sur raw et sur ses paquets a
supprimer depuis raw.
# 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 " ?
Comme dit, avec le SYN en deuxième position, les accès sont coupés
une fois que je place la règle *filter, par contre, le site est
fonctionnel si je ne met QUE les restrictions dans la table *raw ,
de ce fait, je pense à un effet de bord entre mes règles raw et
filter.
# On pourrait interdire le ping avec icmp
directement en PREROUTING.
# Pour le moment je vais l'interdire par défaut depuis *filter
et autoriser le ping aux services OVH.
# -A PREROUTING -p icmp -j DROP
Erreur fréquente : ICMP, ce n'est pas seulement le ping mais aussi
des messages d'erreur qu'il vaut mieux ne pas bloquer si on veut
que les communications marchent bien.
Ok je prend note, j'ajoute ce commentaire au dessus de la ligne
commentée.
# Pas de filtrage sur l'interface de
loopback.
####
# Le serveur ne doit pas avoir de soucis à communiquer avec
lui-même au niveau des services internes.
# Accepter toutes les connexions de la machine locale pour
permettre aux services de communiquer entre eux.
-A INPUT -i lo -j ACCEPT
# Par la suite, la règle par défaut va DROP sur tous les OUTPUT
non autorisés.
# 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 ?
#
L'absence d'autorisation en sortie peut t'elle interférer avec
certains services attendant une communication en sortie de
loopback ?
# -A OUTPUT -o lo -j ACCEPT
OK, je décommente donc la règle OUTPUT pour le loopback. Merci.
Evidemment ça interfère. Tout paquet envoyé sur l'interface de
loopback passe successivement par les chaînes OUTPUT, POSTROUTING,
PREROUTING et INPUT et doit être accepté dans toutes pour arriver
à destination.
-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.
####
# Autoriser les services web.
####
# 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 ?
Hormis les pages web, non, donc, si je t'entend bien, je peux
supprimer les règles DNS ?
-A INPUT -p udp --sport 53 -j ACCEPT
Cette règle est une faille de sécurité en plus d'être inutile.
Ok, je supprime : -A INPUT -p udp --sport 53 -j ACCEPT
Si je comprend ton message précédent, je peux commenter toutes les
règles concernant le serveur DNS ?
# Configurer le FTP et le pare-feu pour
utiliser la plage de ports passifs entre 49152-65534 proposée
par IANA.
# Noter que la connexion de semble pas s'établir à chaque fois
et qu'il est nécessaire de retenter la connexion.
# Noter que la connexion fstp n'est pas configurée actuellement.
A faire !
Qu'est-ce que la connexion fstp ?
Oups ! sFTP
-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 ? Dans mon idée, seul le FTP
est censé passer par la, mais, je me trompe peut être ?
J'ai commenté les deux règles en OUTPUT, j'arrive toujours à me
connecter au FTP, c'est très bien.
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.
Statut : Connecté
Statut : Récupération du contenu du dossier...
Statut : Contenu du dossier "/" affiché avec succès
Statut : Récupération du contenu du dossier "/"...
Statut : Contenu du dossier "/" affiché avec succès
Statut : Déconnecté du serveur
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.
Statut : Connecté
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é
Erreur : Impossible de récupérer le contenu du dossier
Statut : Déconnecté du serveur
-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
,
Alors, je n'arrive plus à me connecter au serveur FTP via FileZilla
:/
Quoi que ? c'est la récupération du contenu du dossier qui ne se
fait pas !
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.
Statut : Le serveur ne supporte pas les caractères non-ASCII.
Statut : Connecté
Statut : Récupération du contenu du dossier "/"...
Commande : CWD /
Réponse : 250 Commande CWD exécutée avec succès
Commande : TYPE I
Réponse : 200 Type paramétré à I
Commande : PASV
Réponse : 227 Entering Passive Mode (139,99,173,195,193,218).
Commande : LIST
Erreur : Connection interrompue après 20 secondes d'inactivité
Erreur : Impossible de récupérer le contenu du dossier
En somme, j'ai ceci maintenant :
# Autoriser les connexions au serveur FTP sur le port 21.
# Une connexion FTP passive est préférable, depuis le client FileZilla Edition/Paramètres/Connexion/FTP/ décocher :
# Autoriser un retour sur un autre mode de transfert en cas d'échec
# Configurer le FTP et le pare-feu pour utiliser la plage de ports passifs entre 49152-65534 proposée par IANA.
# Noter que la connexion de semble pas s'établir à chaque fois et qu'il est nécessaire de retenter la connexion.
# Noter que la connexion sFTP n'est pas configurée actuellement. A faire !
###
# Les deux règles suivantes sont inutiles car les 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 ? NON.
###-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
-A INPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
# Je suis obligé d'autoriser la plage de ports suivants, sinon, la récupération au dossier racine suite à connexion FTP ne se fait pas depuis FileZilla.
-A INPUT -p tcp --sport 49152:65534 --dport 49152:65534 -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT
# 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 ?
# 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 ?
Poser des ports piégés est limité, c'est ce que tu confirmes ? 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 ?
########
# Limiter le nombre de connexions simultanées établies à partir
d'une adresse IP unique sur un port donné.
########
-A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above
4 -j LOG_REJECT
-A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above
4 -j LOG_REJECT
-A INPUT -p tcp --syn --dport 443 -m connlimit --connlimit-above
15 -j LOG_REJECT
Sans effet pour les ports 80 et 443 comme indiqué plus haut.
Ok, d'ou ma question, est ce que je remonte tous mes contrôles
d'optimisation, avant l'ouverture des services ?
Merci pour la relecture ! J'ai modifié certaines règles en suivant
tes propositions, et, le serveur tourne encore : ) ; )
|