System-Linux

Aller au contenu | Aller au menu | Aller à la recherche

Port knocking sur Debian

knocking jpg

Knock Knock :)

Le concept et son implémentation dont nous allons parler aujourd'hui s'appelle le port knocking.

Un petit mot de concept :

Il s'agit de provoquer l'ouverture d'un port sur une suite d'accès à des ports fermés (UDP ou TCP). Le serveur est averti d'une suite de ports tcp ou udp qui vont être requêtés suite à quoi il ouvrira (au sens firewalling du terme) un port convenu à l'avance pour l'ip qui à composée le code.

Maintenant mettons cela en pratique :

L'implémentation proposée repose sur le démon knockd.

On installe notre démon (ici sous Debian 5) :

aptitude update && aptitude install knockd

Passons à la configuration :

vim /etc/knockd.conf

Une configuration par défaut est proposée pour OpenSSh sur le port 22.

Une séquence ouvre le port (tcp/ 7000 - 8000 - 9000), une autre le ferme (tcp / 9000 - 8000 - 7000).

Nous allons de suite tester sans rien toucher !

Pour cela activons le service knockd.

Dans /etc/default/knockd passez :

START_KNOCKD=0 
à 
START_KNOCKD=1 

Puis faites :

service knockd start

On va ensuite injecter une règle de firewall qui DROPPE TOUT le traffic entrant (y compris votre session ssh si vous l'utilisez !!) Ne le faites que si vous êtes sur de votre coup et que vous avez un accès physique au serveur (ou un kvm ip ;)) Libre à vous de configurer les ports qui doivent passer mais la n'est pas le propos.

Vous êtes sur ? bon ok on y va !!!

iptables -F
iptabes -X
iptables -P INPUT DROP

Nous allons mantenant lancer un accès ssh vers notre serveur... sans surprise ca ne passe pas, iptables faisant son boulot.

Maintenant lançons un knock vers notre serveur avec la séquence convenu. le module client utilisé ici est fourni par le package knockd, un :

dpkg -L knockd

vous en convaincra ;)

knock 192.168.0.10 7000 8000 9000

Mon ssh passe désormais. Une fois connecté sur mon systeme un iptables -L me confirme que je suis la seule ip autorisée... Une fois mes opérations achevées, je me déconnecte.

On knock alors la séquence pour fermer le port ssh.

knock 192.168.0.10 9000 8000 7000

Mon ssh ne passe plus :)

C'est tout pour ce premier billet, la suite au prochain épisode.

Big up

Merci à Vince pour cet article.

Par GanGan | le lundi, octobre 11 2010 07:00

Commentaires

1. zedtux

lundi, octobre 11 2010 | 07:26

Je connaissais la théorie, mais je n'avais jamais mis en pratique et je ne savais même pas qu'un paquet existait !

Grand merci à toi pour ces explications limpides !

2. zeojex

lundi, octobre 11 2010 | 07:55

Marrant !
Question : Le knocking ne constitue pas une faille de sécurité assez importante finalement ? Le "code" (séquence) n'étant peut-être pas très difficile à tester, via des scans par exemple ?
Merci pour l'info

3. GanGan

lundi, octobre 11 2010 | 09:59

Je laisse Wikipedia te répondre :)

{{Une simple séquence de trois tentatives de connexion (par exemple : port 1000, 2000, 3000) requiert, pour un attaquant ne connaissant pas la séquence, d'utiliser la méthode force brute pour être découverte. Il lui faudra tester chaque combinaison avec 65535 ports à scanner, et vérifier à chaque scan si un port s'est ouvert ; cela donne approximativement 18 445 618 199 572 250 625 paquets de données possibles à envoyer, soit 655354 paquets (65535³ pour la séquence de trois ports, multiplié par 65535 tentatives à chaque fois pour découvrir un éventuel port).

Une simple séquence de trois tentatives de connexion (par exemple : port 1000, 2000, 3000) requiert, pour un attaquant ne connaissant pas la séquence, d'utiliser la méthode force brute pour être découverte. Il lui faudra tester chaque combinaison avec 65535 ports à scanner, et vérifier à chaque scan si un port s'est ouvert ; cela donne approximativement 18 445 618 199 572 250 625 paquets de données possibles à envoyer, soit 655354 paquets (65535³ pour la séquence de trois ports, multiplié par 65535 tentatives à chaque fois pour découvrir un éventuel port)

Mais tout cela n'est plus valable dans le cas où un sniffer est employé ; une écoute efficace des séquences rend alors possible l'accès sans autorisation. C'est pourquoi une séquence autrement plus complexe rendrait la tâche plus difficile.}}

4. Vince

lundi, octobre 11 2010 | 10:11

Il lui faudra tester chaque combinaison avec 65535 ports à scanner

En fait fois 2 car on peut générer des séquences couplants udp et tcp :)

Mais tout cela n'est plus valable dans le cas où un sniffer est employé ; une écoute efficace des séquences rend alors possible l'accès sans autorisation.

Exact. L'accès est ouvert, reste à s'authentifier.

5. Benjamin

lundi, octobre 11 2010 | 11:06

Merci pour l'astuce, je testerai ça très bientôt !

6. David

lundi, octobre 11 2010 | 14:39

Arrêter moi si je me trompe.

Cela ne marche que si la machine est directement joignable? soit sur un réseau local, ou sur Internet avec une IP public?

Si on a besoin d'accéder au serveur derrière un NAT, ça oblige à faire transférer les ports vers le serveur? Nan?

7. Vince

lundi, octobre 11 2010 | 15:24

Cela ne marche que si la machine est directement joignable?

En fait pas vraiment.
Il faut juste que tu puisses passer les firewalls/routeurs entre toi et la cible pour les ports requetés (ce qui ne devrait pas être le cas pour des ports lambdas tels qu'on en utilise ici)

Si on a besoin d'accéder au serveur derrière un NAT, ça oblige à faire transférer les ports vers le serveur? Nan?

Effectivement.
Concernant le NAT :

En cas de dNAT (destination) ca marche si effectivement tu nat vers le serveur sans faire de pNAT (port).
(pas testé mais ca devrait le faire, cela dit en terme de sécurité on perd toute la valeur ajoutée...)

Bref a utiliser en environnement LAN de preference :D

8. rOOT

lundi, octobre 11 2010 | 18:06

Bonjour,
Avec des règles iptables un peu plus poussé on peut ouvrir le port pdt un temps T ('ex 7 secondes') et après cela d'autorisé que le trafic déjà initialisé (pas de nouvelles connections. Le port reste donc ouvert seulement 7 secondes.

The rOOT

9. makidoko

lundi, octobre 11 2010 | 19:21

"Le serveur est averti d'une suite de ports tcp ou udp qui vont être requêtés"
"requis" fait très bien l'affaire.

10. Dju

lundi, octobre 11 2010 | 20:02

héhé.... ça sent la squeeze (ou ubuntu)
sous lenny, faudrait faire un /etc/init.d/knockd start :p
sinon, le mieux est encore d'avoir un routeur sous nux qui est en frontal. comme ca via le knocking on s'ouvre un ssh dessus, et de la on se connecte, toujours en ssh aux machines internes qui sont derriere. comme ça on s'embête pas avec le nat :)

11. Vince

mercredi, octobre 13 2010 | 12:47

on peut ouvrir le port pdt un temps T ('ex 7 secondes')

Certes mais j'ai l'habitude de filtrer aussi en sortie :) (-P OUTPUT DROP)

"requis" fait très bien l'affaire.

Non non requêtés, relis la phrase :)

ça sent la squeeze (ou ubuntu)

Je viens de retester sous Suse le script "service" existe. Il me semble que dans une install standard de Debian il est integré. Mais cela dit tu as largement raison pour des raisons de compatibilité privilegier le mécanisme de base /etc/init.d/<service> action

Je vous laisse je commence mon examen certifiant linux dans 30 minutes :) (Un papier en écriture pour bientot !!)