Articles avec les mots clés ’iptables’
Installation d’OpenNebula sous Archlinux (partie 2)
Dans cet article nous allons poursuivre l’installation de notre plateforme cloud utilisant OpenNebula sur une distribution Archlinux.
Nous avons vu que, par défaut, sunstone écoute sur le port 9869/tcp. Pour faciliter l’utilisation, nous allons mettre un reverse-proxy nginx en place. Ce dernier écoutera sur le port 80/tcp et enverra les requêtes à sunstone.
Mise en place de Nginx
L’installation se fait de manière classique sous Archlinux :
pacman -S nginx
La configuration se fait en éditant le fichier /etc/nginx/nginx.conf et en inserant un bloc server dans la section http :
http { … server { listen 80 default_server; server_name _; # A regler en fonction des images qcow2 que l'on souhaite uploader dans sunstone client_max_body_size 29G; location / { proxy_pass http://127.0.0.1:9869; } } … }
Le démarrage de nginx se fait à l’aide des commandes :
systemctl enable nginx systemctl start nginx
Nous pouvons maintenant dire à sunstone de n’autoriser des requêtes que depuis le localhost.
Il nous faut éditer le fichier /etc/one/sunstone-server.conf et modifier la ligne :
:host: 0.0.0.0
en
:host: 127.0.0.1
et relancer le service :
systemctl stop opennebula-sunstone.service systemctl start opennebula-sunstone.service
A présent si nous effectuons une requête depuis un navigateur web sur http://192.168.0.136 sans spécifier de port (a modifier bien sur en fonction de l’adresse de votre serveur opennebula),
nous obtenons la page d’accueil de sunstone :
Installation d’OpenVPN
Vu que les VMs deployées par OpenNebula seront reliées à un switch virtuel n’ayant aucune connexion avec un quelconque réseau physique, nous devons installer un service VPN sur notre serveur OpenNebula qui nous permettra accéder aux machines.
Pour simplifier les choses, openvpn sera configuré pour authentifier les utilisateurs via leur compte système via les PAM. Nous allons d’abord créer un groupe « vpn » :
groupadd vpn
Nous allons donc créer le compte d’un utilisateur (ici beroot qui pourra se connecter au vpn :
useradd -s /usr/bin/nologin -M -g vpn beroot passwd beroot
Installons OpenVPN :
pacman -S openvpn iptables easy-rsa
Créons le fichier de configuration d’OpenVPN /etc/openvpn/server.conf :
port 1194 proto udp dev tun0 ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/server.crt key /etc/openvpn/keys/server.key dh /etc/openvpn/keys/dh2048.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt client-to-client keepalive 10 120 comp-lzo max-clients 100 user nobody group nobody persist-key persist-tun status /var/log/openvpn-status.log log-append /var/log/openvpn.log verb 4 client-cert-not-required plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn push "route 192.168.1.0 255.255.255.0"
Créons le fichier /etc/pam.d/openvpn :
auth required pam_listfile.so onerr=fail item=group sense=allow file=/etc/pam.d/openvpn.allowed auth sufficient pam_unix.so try_first_pass likeauth nullok auth required pam_deny.so account required pam_unix.so session required pam_unix.so
et le fichier /etc/pam.d/openvpn.allowed qui contient juste le nom du groupe unix autorisé à se connecter au vpn :
vpn
Il nous faut maintenant préparer l’environnement qui va nous permettre de créer les clés de cryptage :
mkdir -p /etc/openvpn/keys cp -r /usr/share/easy-rsa /etc/openvpn/
Nous éditons ensuite le fichier vars et le modifions en fonction de notre localisation.
cd /etc/openvpn/easy-rsa vim vars
Nous générons ensuite les clés :
. ./vars ./clean-all ./build-ca ./build-key-server server ./build-dh
Puis nous les copions à l’endroit approprié :
cp keys/ca.crt /etc/openvpn/keys/ cp keys/ca.key /etc/openvpn/keys/ cp keys/server.crt /etc/openvpn/keys/ cp keys/server.key /etc/openvpn/keys/ cp keys/dh2048.pem /etc/openvpn/keys/
Vous pouvez déjà exporter le fichier /etc/openvpn/keys/ca.crt car il sera à installer sur les clients vpn par la suite.
Nous pouvons alors démarrer le service openvpn :
systemctl enable openvpn@server.service systemctl start openvpn@server.service
Le serveur vpn est en service mais il faut que nous paramétrions quelques règles iptables pour rendre le système utilisable.
Mise en place de règles iptables
Créons le fichier /etc/iptables/iptables.rules (remplacez eno1 par le nom de votre interface réseau) :
*nat :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE COMMIT *filter :INPUT DROP [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i lo -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A INPUT -i br0 -j ACCEPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --match multiport --dports 5900:6000 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 29876 -j ACCEPT -A INPUT -i eno1 -p udp --dport 1194 -j ACCEPT COMMIT
Créons un fichier /etc/sysctl.d/iptables.conf :
net.ipv4.ip_forward = 1
Démarrons l’ensemble :
systemctl enable iptables.service systemctl start iptables.service sysctl -p
Ce deuxième article sur la configuration de notre plateforme OpenNebula s’achève ici. Le système est utilisable dans l’état mais nous irons encore plus loin dans un prochain article …
Fedora 17 : le pare-feu dynamique firewalld
Fedora 17 permet de remplacer le pare-feu traditionnel statique (outils iptables et fichier /etc/sysconfig/iptables) par un pare-feu dynamique nommé firewalld possédant une interface d-bus. Il est ainsi possible de modifier les règles à la volée sans avoir à redémarrer le daemon.
Installation :
Firewalld n’est pas actif par défaut sous Fedora 17. A priori, cela est prévu pour Fedora 18, le temps pour les développeurs de finaliser les outils spécifiques et d’adapter ceux existants à ce nouveau pare-feu.
L’installation se fait simplement à l’aide de la commande :
yum install firewalld
Il convient alors de désactiver le lancement du pare-feu statique installé par défaut afin que celui-ci n’interfère pas avec firewalld :
systemctl stop iptables.service systemctl disable iptables.service
Nous pouvons ensuite permettre le démarrage automatique de firewalld :
systemctl start firewalld.service systemctl enable firewalld.service
La commande firewall-cmd :
La commande firewall-cmd permet de contrôler le pare-feu dynamiquement (liste des règles actives, ouverture/fermeture de port, …)
firewalld supporte le concept de « zone de réseau » permettant de gérer des profils de règles à appliquer en fonction du réseau sur lequel on se trouve ( par exemple tout fermer lorsque l’on est sur un réseau
public et ouvrir ssh et samba lorque l’on est sur un réseau professionnel).
Pour connaître la zone par défaut, il faut utiliser la commande :
firewall-cmd --get-default-zone
Par défaut, sous Fedora, la commande retournera public.
La zone a lancer par défaut est fixée dans le fichier /etc/firewalld/ firewalld.conf :
# default zone # The default zone used if an empty zone string is used. # Default: public DefaultZone=public
Pour connaître la zone en cours d’exécution, nous pouvons utiliser la commande :
firewall-cmd --get-active-zones
La réponse fournie ici est « public: em1 » ce qui signifie que le profil public est en cours d’execution sur l’interface réseau em1.
Pour obtenir la liste des services autorisés pour le profil public, il suffit de taper :
firewall-cmd --zone=public --list-service
Pour obtenir la liste des ports ouvert pourle profil public, il suffit de taper :
firewall-cmd --zone=public --list=port
L’ensemble des profils définis s’obtient avec la commande :
firewall-cmd --get-zones
Par défaut, sous Fedora les profils drop work internal external trusted home dmz public block sont présents.
Le liste des services pré-définis se trouve sous le répertoire /usr/lib/firewalld/services :
Ce sont de simples fichiers xml. Il nous est donc possible de créer un fichier de services par exemple pour une application fonctionnant sur le port 9000 en créant le fichier /etc/firewalld/services/monappli.xml :
<?xml version="1.0" encoding="utf-8"?> <service name="monappli"> <short>MonAppli (9000)</short> <description>Mon serveur d'applications.</description> <port protocol="tcp" port="9000"/> </service>
Pour que firewalld prenne connaissance de ce nouveau service, il est nécessaire de le redémarrer :
systemctl restart firewalld.service
Pour activer le service monappli dans le profil home, il suffit ensuite de faire :
firewall-cmd --zone=home --add --service=monappli
Pour connaître l’ensemble des services actifs sous le profil home :
firewall-cmd --zone=home --list=service
Pour retirer un service d’un profil (par exemple ipp-client du profil home), il faut taper :
firewall-cmd --zone=home --remove --service=ipp-client
Plutôt que de passer par des services prédéfinis, nous pouvons également ouvrir des ports directement :
firewall-cmd --zone=home --add --port=9000/tcp
Pour activer le profil home, il suffit de faire :
firewall-cmd --set-default-zone=home
Attention, ceci est un changement permanent (cela modifie le fichier /etc/firewalld/firewalld.conf). Lors du prochain redémarrage de firewalld, le profil chargé par défaut sera home
Cependant, les services/ports activés ou désactivés à l’aide de la commande firewall-cmd seront perdus. En effet, cette commande n’impacte que la session courante du service firewalld.
Si nous voulons effectuer des modifications permanentes, il faut modifier les fichiers de configurations des zones.
Par exemple pour rajouter de manière permanent le service monappli au profil de zone home, il faut tout d’abord copier le fichier par défaut de cette zone dans le répertoire /etc/firewalld/zones :
cp /usr/lib/firewalld/zones/home.xml /etc/firewalld/zones/
Puis modifier le fichier /etc/firewalld/zones/home.xml :
<?xml version="1.0" encoding="utf-8"?> <zone name="home"> <short>Home</short> <description>For use in home areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description> <service name="ssh"/> <service name="ipp-client"/> <service name="mdns"/> <service name="samba-client"/> <service name="dhcpv6-client"/> <service name="monappli"/> </zone>
Comme nous l’avons vu, le nouveau pare-feu firewalld permet de changer les règles à la volée mais nous sommes dans l’obligation de modifier les fichiers de configuration à la main dés que nous voulons que les changements opérés soient permanents. Cependant, le concept de zone peut être utile pour les ordinateurs mobiles. firewalld permet également, via l’option –timeout, d’ouvrir un port/service pour une durée determinée.
Par exemple, pour autoriser le service monappli sur le profil home (en cours d’execution) pendant 10s il faut faire:
firewall-cmd --zone=home --add --service=monappli --timeout=10
Ainsi s’achève ce tour d’horizon de firewalld …
Mise en place du port knocking sous CentOS
Le port Knocking est une méthode permettant d’ouvrir dynamiquement des ports protégés par un pare-feu. Pour cela, une suite de connexion sur plusieurs ports doit être effectuée. Un processus tourne alors en arrière-plan et vérifie régulièrement le journal de connexion du pare-feu pour ouvrir un port spécifique si une séquence est détectée.
Cette technique est notamment utilisée pour protéger l’accès au port 22 (SSH) d’une machine.
Pour mettre en place le port knocking sous CentOS, nous allons utiliser le démon knockd disponible à cette adresse. L’installation à partir des sources consistent à installer tout d’abord les dépendances puis le démon knockd.
– yum install gcc libpcap-devel
– cd /usr/local/src/
– wget http://www.zeroflux.org/proj/knock/files/knock-0.5.tar.gz
– tar -xzvf knock-0.5.tar.gz
– ./configure
– make
– make install
Ensuite, il vous faut supprimer la règle autorisant SSH en entrée sur le serveur.
– vi /etc/sysconfig/iptables
#-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
– Redémarrez le pare-feu : service iptables restart
Il vous faut maintenant définir la séquence de port à « frapper » pour ouvrir le port SSH. Dans notre exemple, nous choisissons les ports 2222, 3333 et 4444.
– vi /etc/knockd.conf
[options] UseSyslog PidFile = /var/run/knockd.pid Interface = eth0 [opencloseSSH] sequence = 2222,3333,4444 seq_timeout = 15 tcpflags = syn start_command = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 22 -j ACCEPT cmd_timeout = 60 stop_command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
La séquence doit être effectuée dans les 15 secondes et vous avez 60 secondes pour vous connecter en SSH sur le serveur.
Il ne vous reste plus qu’à lancer le démon knockd.
– /usr/sbin/knockd -d
Depuis votre client, essayez maintenant de vous connecter en SSH sur votre serveur. La connexion est maintenant impossible puisque le pare-feu n’autorise plus le port 22 en entrée. Par contre le serveur SSH est toujours à l’écoute. Récupérez par exemple le client Knock pour Windows.
Depuis un poste sous Windows, en ligne de commande, « frappez les ports » : knock.exe 192.168.0.100 2222 3333 4444
Vous pouvez maintenant vous connecter normalement en SSH sur votre serveur dans un certain laps de temps.