TP Syslog + Iptables


I. Configuration simple de syslog


1) Vérifiez l'état du service syslog. Est-il démarré ? Si ce n'est pas le cas, démarrez-le.

Sous RedHat / Mandriva, vous avez deux options pour manipuler les services :

Essayez de relancer le service en utilisant ces deux méthodes. La deuxième méthode n'existe pas sous Debian.


2) Lancez un affichage continu du fichier /var/log/cron


3) en même temps, utilisez la commande logger pour envoyer un message de log à votre machine, en choisissant les bonnes facilités et priorités pour voir apparaître votre message dans l'affichage continu de /var/log/cron


Ce message doit contenir l'heure de l'enregistrement, la machine source (vous-même en fait), un tag permettant d'identifier le test, ainsi qu'un message de test.


4) Vous allez maintenant configurer syslog pour un service particulier que nous venons d'inventer : security.


Configurez syslog avec une facilité disponible pour ce service. Pour cette facilité que vous avez choisie, configurez syslog pour diriger les enregistrements :


Vérifiez avec logger. Dans les logs doit apparaître entre autres le nom du service security.


II. Déport vers un server de logs


1) Configurez maintenant syslog pour diriger les priorités “graves” définies ci-dessus, en plus du fichier local déjà défini, vers le serveur syslog de votre voisin d'en face.


2) Configurez également votre serveur pour écouter les logs de votre voisin d'en face.


Recevez-vous les logs de votre voisin ?

Si la réponse est non, pour quelle raison selon vous ?


Peut-être votre voisin ne vous envoie-t'il tout simplement pas de logs ! Pour vérifiez, utilisez le sniffer de paquet tcpdump pour vérifier le passage de paquets udp reçus sur le port syslog (quel est le numéro de ce port ? /etc/services)


Si vous voyez bien les paquets arriver, mais aucun log sauvegardé sur votre system, cela vient probablement de votre configuration.


Vérifiez par exemple que syslog écoute bien sur le réseau. Utilisez le fichier de configuration de démarrage de syslog pour ce faire.


Peut-être s'agil-il également du firewall qui empêche la réception. Essayez ça :

iptables -F INPUT ; iptables -P INPUT ACCEPT


Si vous êtes persuadé que le problème vient d'autre part, appelez le professeur.


III. Diagnostique réseau de la machine


1) Utilisez netstat pour afficher les ports ouverts :

Dans le résultat, affichez tous les ports IP qui écoutent ou qui sont déjà en session. Affichez les PID des processus serveurs responsables de l'ouverture de ces ports. N'affichez pas les sockets Unix.


2) Nous allons maintenant scanner les ports de notre machine. Pour cela, nous allons découvrir quelques types de portscans bien connus. Cela nous renseigne sur les ports ouverts de la machine, ceux qu'il faudra éventuellement fermer. Ensuite, nous tenterons de savoir quels sont les versions des serveurs qui écoutent sur ces ports, ainsi que la version de l'OS.


Tous ces renseignements sont précieux pour le hacker.


Pour tester quelques types de Scans possibles, nous allons utiliser hping, qui est un outil puissant permettant d'envoyer à peu près n'importe quel type de paquet (TCP, UDP, ICMP) à une machine. On peut modifier les en-têtes des paquets et voir la réponse des machines.


Voilà quelques options classiques de hping :

-s --baseport base source port (default random)

-p --destport [+][+]<port> destination port(default 0)

or ctrl+z inc/dec

-F --fin set FIN flag

-S --syn set SYN flag

-R --rst set RST flag

-P --push set PUSH flag

-A --ack set ACK flag

-U --urg set URG flag

-X --xmas set X unused flag (0x40)

-Y --ymas set Y unused flag (0x80)


Ainsi, en fonction des paquets que nous envoyons, nous recevrons une réponse qui nous indiqueras si le port est ouvert ou fermé.


3) Par exemple, essayez d'envoyer un paquet SYN sur un port en mode “listening” de votre machine :

hping -S localhost -p port_listening

Tout de suite après apparaissent les paquets reçus de la cible.


Que devriez-vous recevoir ? Que signifie le SA que vous recevez ? Cela correspond-il ?


4) Essayez maintenant d'envoyer un paquet SYN sur un port fermé de votre machine.

Que devriez-vous recevoir ? Que signifie le RA que vous recevez ? Cela correspond-il ?


On en conclut qu'en fonction de la réponse, on peut déduire si un peu est à l'état ouvert ou fermé.


5) Mais qu'en est-il des ports gérés par des firewalls, qui ne renvoient pas de réponses ?

Essayez d'envoyer un paquet SYN vers un port de la machinedu professeur (le port sera donné pendant le TP). Quelle est la réponse ?


Pour résumer,


Ainsi, en fonction des réponses, on peut déduire 3 états de ports. Nous avons réalisé un portscan bien connu, le SYN Stealth Scan.


Vous pouvez essayer de reproduire différents types de scans listés à la page nmap :

www.nmap-tutorial.com

http://www.radarhack.com/dir/papers/hping2_v1.5.pdf


6) Il est possible de mener ce type de scan de manière automatique avec un outils puissant et célèbre : nmap


Le logiciel network mapper permet plusieurs types de scans, pour découvrir les ports sur une machine, les versions de serveurs qui tournent derrière ces ports, voire même l'OS de la cible et sa version. Il permet d'adapter le scan au type de cible, par exemple en faisant des scans furtifs en mode paranoïaques où les paquets seront envoyés avec des intervals très long, pour empêcher une corrélation par une administrateur zélé ou par un IDS.


Allez à la page nmap-tutorial ci-dessus et essayez les divers types de scans fournis par nmap.


Essayez dans un premier temps d'effectuer un balayage systématique du réseau, pour découvrir les machines allumées. Ensuite, sur une machine cible, essayez de découvrir ses ports ouverts, son OS et la version des services.


IV. Découverte de IPTables


Dans ce TP, nous allons comparer un firewall stateless et un firewall stateful. Cela nous permettra de bien comprendre le réel avantage du stateful.


Sur IPTables, on distingue :

- les flux traversant le FireWall (FORWARD)


Les chaînes ne sont pas spécifiques aux interfaces. Par exemple, TOUS les flux destinés aux processus internes au FW sont concernés par INPUT.

Vous pouvez visualiser ces 3 chaînes en tapant la commande iptables -L en root


Soit l'exemple ci-dessous :


--------------------

LAN | | INTERNET

---------------------------- | FW |--------------------------------

eth1 -------------------- eth0 194.51.3.65

192.168.1.1 \----<--------<---------<------ Flux à destination du FW

INPUT


\ \

\ \----->------>----->----->

\ Flux générés par le FW

\ OUPUT

\-----<------<-----<-------<-------<-----

\------->------>------>----->------>------>

Flux traversant le FW

FORWARD



Pour bien comprendre l'idée, dites par quelle chaîne (INPUT, OUTPUT, FORWARD) seront traités les flux suivants :

Un tentative de connexion venant d'Internet vers 194.51.3.65

Chaîne

Les flux venant d'internet à destination de la machine 192.168.1.100 sur le LAN

Chaîne :

Les flux venant de 192.168.1.243 vers 192.168.1.1 (adresse du FW)

Chaîne

Un ping généré par l'administrateur sur le FW vers une machine sur Internet

Chaîne

Un paquet venant d'Internet à destination de 192.168.1.1

Chaîne

Un ping local du FW vers sa propre adresse IP 192.168.1.1

Chaîne

Un paquet GET HTTP de 192.168.1.23 vers 192.168.1.1

Chaîne

Le paquet de réponse HTTP émis par le FW (le FW fait aussi serveur Web tiens...)

Chaîne



II. Application à notre cas avec des règles simples


Comme nous n'avons pas beaucoup de machines, nous allons marcher en binômes. Une machine servira à attaquer, et sur l'autre machine on configurera le firewall. Le firewall ne servira donc pas à protéger un réseau, mais à se protéger lui-même (ce qui importe peu pour notre TP).

On aura donc cette configuration :


-------------- ----------------

| FW |---------------------------------| Hacker |

-------------- eth0 eth0 -----------------

10.10.5.81 10.10.5.82


1) Les flux provenant du hacker vont-il traverser le FW ?

Dans ce cas, va-t'on utiliser la chaîne FORWARD ?


2) On veut interdire les paquets provenant de 10.10.5.82 vers 10.10.5.81.

Sur le FW, quelle chaîne va-t'on éditer ?


3) On va d'abord faire un ping de la machine Hacker vers 10.10.5.81.

Quelle est la réponse au ping ?


4) Ajoutez une règle qui interdit les paquets provenant du hacker vers votre machine, avec une target REJECT


5) Sur la machine Hacker, faites un ping vers la 10.10.5.81.

Quelle est la réponse ?

La règle fonctionne-t'elle ?


6) Visualisez la règle


Supprimez supprime la 1ère règle de la chaîne INPUT.


7) Maintenant, ajoutez une règle qui interdit les paquets provenant du hacker vers votre machine, avec une target DROP à la place de DROP.


Relancez le ping à partir de la machine Hacker.

Quelle est la réponse au ping ?


8) Quelle est la différence entre REJECT et DROP ?


Supprimez cette règle que vous venez de créer.


III. Comparaison entre stateless et stateful


STATELESS


Nous allons prendre une configuration simple, très courante. On veut empêcher des machines d'Internet de se connecter à nos machines, mais laisser les machines de notre réseau accéder à Internet.


La politique consiste à :

- interdire tout ce qui rentre sur le réseau provenant d'Internet

- autoriser tout ce qui sort du réseau vers Internet.


1) Voyez-vous d'ores et déjà le problème que cela va poser ?


2) Transposons à notre architecture. On veut :

- autoriser tout ce qui sort du FW vers le réseau

Quelle chaîne est concernée (OUTPUT, INPUT) ?

Quelle va être l'action (ACCEPT, DROP) ?

- mais empêcher tout ce qui rentre du réseau sur notre FW.

Quelle chaîne est concernée (OUTPUT, INPUT) ?

Quelle va être l'action (ACCEPT, DROP) ?


Ces actions : TOUT INTERDIRE ou TOUT AUTORISER sont des politiques par défaut. Ce sont les actions de dernier ressort qui sont appliquées au cas où des paquets filtrés n'ont pas été filtrés par les règles. Les règles sont beaucoup plus spécifiques que les politiques par defaut.


3) Sur votre FW, définissez les politiques par défaut adaptées.

Affichez ensuite la table pour voir les politiques par défaut.


4) Maintenant, testons.

Le Hacker peut-il pinguer, ou accéder à votre machine ?

Est-ce le comportement prévu ?

Et vous, avec FW, pouvez-vous accéder aux machines du réseau comme prévu ?


5) Expliquez pourquoi..


6) Lorsque vous tentez d'accéder à des machines sur le réseau,

- soit vous faites un ping, dans ce cas, le protocole est ICMP

- soit vous tentez d'accéder à un service, protocoles TCP ou UDP.


Par exemple, lorsque vous pinguez une machine du réseau :

- votre ping (echo request) sort-il du FW ?

Pourquoi ?

- la réponse au ping (echo reply) est-elle bien reçue par votre FW ?

Pourquoi ?


7) Que faudrait-il donc faire pour que vos pings vers les machines marchent ?


8) Entrez donc une règle pour autoriser le protocole ICMP dans la chaîne INPUT


9) Pouvez-vous maintenant pinguer les machines du réseau ?


10) Victoire !?

Le Hacker peut-il pinguer votre machine ?


GGGGRRRR, nous sommes revenus au point de départ, nous ne sommes pas protégés contre les hackers. Nous voulons pinguer les machines d'internet, mais elles peuvent également nous pinguer !


11) Une solution pourrait être d'autoriser seulement l'echo reply en INPUT

Supprimez la règle existante et autorisez seulement l'echo reply.


Ainsi, en INPUT, tout est interdit, sauf les echo-reply.


Comprenez-vous mieux la différence entre la politique par defaut et une règle ?


12) Cette solution est moyennement acceptable. Il est vrai que le Hacker ne peut pas nous envoyer d'echo request, mais rien de l'empêche d'envoyer des echo-reply qui pourrait exploiter une faille de notre réseau. Notre objectif est de ne rien laisser rentrer.


De la même manière, pour pouvoir établir des sessions TCP avec les machines du réseaux, il faudrait par exemple :

- interdire les paquets entrant vers le service de ma machine : ports 1 à 1023

--> Les hackers ne pourraient pas se connecter sur d'éventuels serveurs sur ma machine...


- autoriser les paquets entrants vers les ports dynamiques : ports 1024 à 65535

--> ...mais les retours de mes connexions sortantes seraient autorisés


Là encore, rien n'empêche au hacker de m'envoyer des paquets sur les ports autorisés, en espérant toucher une cible (par exemple en envoyant un SYN/ACK spoofé comme notre ami Kevin).


C'est là tout le problème du filtre stateless. Chaque paquet est examiné individuellement. On ne se demande pas :

- ce paquet est-il un paquet retour d'une connexion sortante ? (donc légitime)

- ce paquet est-il un paquet en dehors de toute session établie ? (donc illégitime)


STATEFUL

C'est ce que va faire un filtre statefull. Il va s'interroger sur un paquet par rapport aux autres paquets (voir les deux questions ci-dessus).


Le filtre Stateful enregistre toutes les sessions en cours (TCP, mais également UDP, ICMP, mais c'est un abus de langage, car on ne peut pas parler de session UDP ou ICMP). On parlera parfois de contexte (chez Cisco). Quand un paquet sort de notre réseau, un contexte est créé. Tous les paquets appartenants à ce contexte sont autorisés (par exemple, les paquets retours). Les autres paquets sont détruits.

En ce qui concerne IPTables, le mot clé est ESTABLISHED. La surveillance des connexions est faites par le module conntrack.


1) On va autoriser tout ce qui fait partie de connexions ESTABLISHED à rentrer, et détruire le reste.


D'abord, supprimez les règles existantes dans INPUT

On peut le faire avec iptables -D INPUT n° de règle, mais c'est assez contraignant si on a plusieurs règles.

Flusher plutôt l'ensemble des règles dans INPUT


La politique par défaut de INPUT est toujours DROP comme convenu.


2) Maintenant, autorisez (ACCEPT) sur INPUT les connexions dont l'état (module state) est ESTABLISHED.


Visualisez les règles pour voir si la règle est bien prise en compte.


3) Essayez maintenant un ping ou autre vers les machines de l'extérieur.

Cela marche-t'il ?


4) La machine Hacker peut-elle vous pinguer ou accéder à l'un de vos services ?


5) Avons-nous atteint notre objectif ?


Le problème des sessions parallèles.

Illustrons un autre problème. Il arrive que certains protocols ouvrent d'autres sessions en parallèle à la premiere session. C'est le cas par exemple de FTP. La session FTP de base (qui sert à transferer les commandes : get, put, etc.) sur le port 21 négocie une session pour les transferts de données. Des ports dynamiques sont ouverts, ces ports ne sont pas prévisibles.


Ces sessions apparentées (related) ne font pas parties des sessions d'origine. Elles ne font pas partie des contextes ESTABLISHED.


Ainsi, cela va poser problème lorsqu'une machine de notre réseau va tenter d'accéder à un serveur FTP sur Internet.


Démontrons.


1) Tout d'abord, installez un serveur FTP sur la machine Hacker (qui se transforme maintenant en machine Server) :


2) A partir de FW, tentez maintenant de vous connecter au server FTP et entrez le login / password du guest de la machine


3) Une fois connecté, tapez ls pour visualiser le contenu du répértoire distant.


Que se passe-t'il ?

Pour quelle raison ?


4) Si le FTP se fige, ouvrez une autre console et tuez le bash en cours qui s'est figé.


Nous allons maintenant accepter les connexions RELATED. En général, on met ESTABLISHED et RELATED ensemble.

Supprimez le règle ESTABLISHED existante.


Maintenant, autorisez sur INPUT les connexions dont l'état est ESTABLISHED et RELATED (qui nous intéresse)


Au passage, sur quelle couche se fait la négociation d'un port FTP-DATA dans le protocole FTP ? Couche 3 ? Couche 4 ?


Un firewall en standard ne peux examiner les données de négociation de port échangées dans la couche application de FTP.


Pour activer cette possibilité, il faut charger le module de suivi de connexion FTP :

modprobe ip_conntrack_ftp


5) Tentez maintenant de vous reconnecter au serveur FTP.


Tapez ls

Cela marche-t'il ?


Rapatriez un fichier affiché dans le ls.


Le téléchargement du fichier est-il OK ?


6) Vous voulez autoriser la connexion en ssh sur FW à partir du réseau, pour pouvoir administrer FW à partir d'une autre machine.


Ajoutez la règle nécessaire dans IPTables pour autoriser la connexion ssh sur FW.

Vérifiez que votre règle fonctionne.


7) Nous allons maintenant définir quelques logs.

D'abord, définissez un log qui va enregistrer tous les paquets qui n'ont correspondu à aucune règle et qui sont donc à la fin de la chaîne (donc à la politique par défaut).


Ces logs doivent préciser autre autres le nom du processus, avoir un marqueur du style : INPUT_NOT_MATCHED, suivi du message.


Il est bien également de positionner des limites sur les logs pour qu'ils ne chargent pas trop nos fichiers de logs. A vous de décider des paramètres.


Dirigez ces logs vers votre fichiers /var/log/security.grave défini plus haut avec une facilité et une priorité appripriés, ainsi que vers votre serveur de logs (une machine distante)


Créez également des logs qui vont enregistrer les connexions ssh et dirigez les vers /var/log/security.pasgrave, ainsi que vers le serveur distant.


Testez.


Userchains


1) Créez un userchain pour le traitement des paquets IP.


2) Redirigez tout les paquets TCP vers ce userchain. Dedans, autorisez simplement, disons euh, ssh et un autre protocole en place sur votre système.


3) Faites de même avec UDP.


Faites des tests en faisait diverses connexions TCP/UDP et vérifiez avec les compteurs que vos userchains sont bien atteints par les paquets. Eventuellement, définissez un petit enregistrement à la fin des userchains pour voir les userchains matchés dans vos logs (vers /var/log/security.pasgrave)


NAT


1) Vous allez créér un réseau IP logique entre vous et votre camarade d'en face. Définissez une adresse que seul vous deux aurez. Avec ifconfig, créez une deuxième interface virtuelle sur votre machine eth0:1

avec l'adresse de votre réseau


2) Nattez en masquerading tout ce qui vient de cette interface vers votre eth0 sur le réseau public.


Avec quelle adresse vous voit un 3eme camarade sur le réseau public (par exemple, avec tcpdump, ou essayez une connexion ssh vers un 3eme camarade qui regardera l'adresse connectée)


N'oubliez pas d'activer le port forwarding, sinon les paquets ne seront même pas relayés !


Maintenant, laissez aller votre imagination. Par exemple, imaginez des filtres contre le SYN FLOODING sur internet (ou jetez un coup à des docs sur le net).