Databases, Systems & Networks

source: http://www.debianworld.org/securite.knockd

Knockd est un petit daemon qui autorise ou non une connexion à votre serveur. Pour cela il écoute les ports de votre machine et attend une séquence bien précise de connexions sur les ports que vous avez définis. Si la séquence définie est exécuté dans le bon ordre, le daemon va ouvrir le port et permettre une connexion pour un temps déterminé sur le port ssh par exemple. La séquence peut utiliser des connexions TCP ou UDP ou les deux.

Ainsi, d’un point de vue extérieur le serveur n’a aucun port d’ouverts exception faite pour les clients qui ont la séquence “magique”.

Lire la suite…

Parfois que nous avons besoin de vous connecter via SSH à un autre ordinateur, nous trouvons que cet ordinateur que nous comptions SSH dans (ce que nous allons appeler « destiny ») peuvent utiliser NAT et, par conséquent, il doesn ' t compte avec une adresse IP publique que nous pourrions utiliser pour se connecter à lui, ou il peut être derrière un pare-feu qui a gagné ' t permettent l'accès de l'extérieur.

Si le « destin » peut réussir à établir une connexion SSH vers un autre ordinateur qui n'est accessible, nous pouvons utiliser ce deuxième ordinateur afin d'établir un tunnel SSH inverse à notre ordinateur « destiny », nous allons appeler ce deuxième ordinateur « origine » (même si elle n'est pas réellement l'ordinateur que nous allons utiliser pour gérer à distance les « cibles », mais qu'un pont).

Un tunnel SSH inverse fonctionne en connectant « destinée » à « l'origine » et puis en se servant cette connexion SSH dans « destin » de n'importe quel ordinateur connecté à « l'origine ». Ce tunnel SSH inverse devrait fonctionner dans la plupart des distributions Linux sans problème.

Alors, laisse supposer que nous avons à présent deux ordinateurs :

« L'origine » IP : aaa.bbb.ccc.ddd

« Destiny » IP : inconnue ou non disponible

Tout d'abord, nous établissons la connexion SSH de "destinée" à « l'origine », qui permet la fonctionnalité SSH inverse avec le paramètre – r :

SSH r 61999:localhost:22 origin_user@aaa.bbb.ccc.ddd

Le premier nombre (61999) indique quel port on va pour utiliser « origine » pour vous connecter à « destiny », localhost est le nom de domaine que nous utiliserons pour cela aussi bien, et le dernier numéro (22) indique quel port est le « destin » écouter pour SSH.

Une fois que cette connexion est établie, et être connecté à le "origine" (peu importe si nous sommes connectés local ou à distance), nous pouvons établir la connexion au « destin » :

SSH p 61999 destiny_user@localhost

Effectivement, nous pouvons utiliser un ordinateur avec un accès SSH permanent comme un pont entre des ordinateurs qui ne sont pas autrement accessibles par l'intermédiaire de SSH. N'importe quel ordinateur connecté à le « origine » peut se connecter à autres ordinateurs avec inversion de tunneling SSH activé.

Bon, a priori vous connaissez la commande "ssh-copy-id" pour copier sa clé publique sur un serveur distant afin de s’identifier par clé et plus par mot de passe.

Le principe est d’avoir une paire de clés privée/publique, le plus souvent dans "~/.ssh/id_rsa(.pub)" et de la copier à l’intérieur du fichier "~/.ssh/authorized_keys" sur la machine distante.

$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host

Mais si la machine distante n’accepte pas les connexions sur le port 22 ou bien qu’il y a une redirection de ports sur le routeur, il faut lui indiquer ce port, par exemple :

$ ssh-copy-id -i ~/.ssh/id_rsa.pub -p 2222 user@host

Mais ça ne marche pas car ssh-copy-id ne comprend que 2 paramètres et si on met "-p 2222" en second, ça n’est pas un motif de type "[user@]host", et si on le met après, en troisième, il est ignoré.

Et bien il suffit d’entourer les infos de connexion ssh par des guillemets pour qu’ils soient vus comme un seul paramètre :

$ ssh-copy-id -i ~/.ssh/id_rsa.pub "-p 2222 user@host"

Source: Jérémy Lecour

It can be helpful to configure Mac OS X to automatically mount shared network drives, this is particularly true for those of us who regularly connect to a network drive for file sharing or backups.

Setting up automatic network drive connections in OS X is a two-step process, you must mount the drive, then you add it to your automatic login items. This should work flawlessly in most versions of OS X, but we’ll cover an alternative approach that uses Automator to mount a network drive automatically on login as well.

1) Mounting the Network Drive

If you’re already familiar with mapping a network drive in Mac OS X you can skip the first part of this and go straight to System Preferences in the second section.

1. From the OS X desktop, pull down the “Go” menu and select “Connect to Server”
2. Connect to the server and mount the drive you want to automatically connect to on boot
3. Choose Guest or for a specific user check the box next to “Remember this password in my keychain” – you must select to remember the password otherwise the automatic login event can not happen without logging into the network drive

Next, you add the network drive to automatically connect on OS X by bringing it into your Login Items list.

Lire la suite…

Iptables c’est quoi ?

Iptables est un firewall pour les distributions linux. Wikipédia et d’autres articles expliquent ça bien mieux que moi, du coup je ne vais pas m’attarder là dessus. Mais pour faire simple, un pare-feu système est un logiciel qui vient contrôler les flux réseaux connectés avec votre machine. Conceptuellement, le firewall va recevoir les flux réseaux, avant la socket. Il va alors appliquer différentes règles sur ce dernier, en fonction des résultats des tests par rapport à ces règles, un firewall laissera passer la connexion vers la socket ou rejettera le flux.

Les firewalls sont indispensables de nos jours en sécurité informatique, il s’agit souvent de la 1ère ligne de défense d’une machine connectée sur internet et dans le cas de réseau d’entreprise, un des éléments vraiment efficace pour limiter les rebonds d’un attaquant dans votre réseau.

Bref, les firewalls c’est bon mangez-en…

Mettre à jour Iptables en 1.6.1

Alors sur une debian 8, c’est la version 1.4.1 qui était présente sur mon serveur. J’ai profité de ce TP pour la mettre à jour vers la dernière version. Les sources officielles sont disponibles sur le site du projet :

https://www.netfilter.org/projects/iptables/index.html

Et voici comment mettre à jour votre firewall.

Dépendances

Quelques paquets sont nécessaires à la dernière version, certains sont présents dans les dépots debian :

apt-get install libbison-dev, flex

D’autres non, et sont à télécharger et installer depuis netfilter.org .

libmnl

curl -O https://www.netfilter.org/projects/libmnl/files/libmnl-1.0.4.tar.bz2
tar xvf libmnl-1.0.4.tar.bz2
cd libmnl-1.0.4/
./configure && make
make install
cd ..
rm -Rf libmnl-1.0.4*

libnftnl

curl -O https://www.netfilter.org/projects/libnftnl/files/libnftnl-1.0.8.tar.bz2
tar xvf libnftnl-1.0.8.tar.bz2
cd libnftnl-1.0.8/
./configure && make
make install
cd ..
rm -Rf libnftnl-1.0.8*

Mettre à jour iptables 1.6.1

curl -O https://www.netfilter.org/projects/iptables/files/iptables-1.6.1.tar.bz2
tar xvf iptables-1.6.1.tar.bz2
cd iptables-1.6.1
./configure && make
make install

Je vous recommande un petit reboot, suite à l’installation comme on touche à des modules kernel.

shutdown -r now

Et vous pourrez alors vérifier que la dernière version d’iptables est bien installée à l’aide de la commande :

# iptables -V
iptables v1.6.1

Pour les N00bs, quelques règles simples

Conceptuellement, iptables fonctionne avec des « tables » et des « chains« . Si vous débutez avec iptables , considérez qu’il n’existe qu’une table de règles : « filter » dans la chaîne « INPUT« , et ne vous occupez pas (encore) du reste. Et vous devez simplement vous dire qu’un paquet TCP à destination de votre serveur va être analysé par chaque règle présente dans cette table de votre firewall pour décider s’il est accepté ou rejeter. On reviendra sur les autres tables dans la partie configuration avancée du firewall iptables plus tard dans ce tutoriel.

Le b.a.-ba d’un pare-feu c’est « d’ouvrir et de fermer » des ports TCP. Comprendre, autoriser des connexions sur certains ports TCP et les refuser sur les autres.

Lire la suite…