Configuration

A partir de la console en mode configuration (conf t):

Il est recommandé de toujours mettre le mot de passe enable

L’admin local et son mot de passe qui effectuera la connexion SSH. Pour plus d’infos sur les privilèges voir

Le mot clé local précise d’utiliser l’utilisateur défini dans la base locale à l’étape précédente. On peut utiliser d’autres moyen d’authentifications comme TACACS, RADIUS …

On précise quelles IPs ont le droit de se connecter en SSH et depuis quelles interfaces. A répéter sur toutes les interfaces ayant besoin d’être activées.

Le temps d’inactivité autorisé avant déconnexion.

On n’autorise que la version 2 de SSH. La 1 étant deprecated pour des raisons de sécurité.

Le nom de domaine à utiliser. La clé RSA est générée en utilisant le nom de domaine plus le nom du firewall

On génére une clef SSH RSA 2048bits.

On écrit les clefs en mémoire pour ne pas les perdre après redémarrage.

Si on résume:

Visualisation

Sessions SSH en cours

Affichage de la clef RSA

Reconfiguration

Et en cas de changement de hostname ou de domain-name ? Il est alors recommandé de réinitialiser les clefs ssh.

Pour cela :

Cette information est obtenue avec NCSI ( Network Connectivity Status Indicator ). Cette fonctionnalité fonctionne de la manière suivante:

1. NCSI effectue une requête DNS sur www.msftncsi.com, puis demande la page http://www.msftncsi.com/ncsi.txt. C’est un fichier texte contenant Microsoft NCSI.
2. NCSI effectue une requête DNS sur dns.msftncsi.com. Cela résout normalement en 131.107.255.255. Si cette vérification échoue on a un problème de connectivité voire un DNS menteur. Mais cette vérification est le plus souvent utilisée lors d’une authentification requise par une page web (type FreeWifi, NeufWifi ou tout autre hotspot).

La fonction part d’une bonne intention mais on envoie quand même une requête à Microsoft avec son IP … et les logs sont gardés:

IIS logs are stored on the server at www.msftncsi.com. These logs contain the time of each access and the IP address recorded for that access. These IP addresses are not used to identify users, and in many cases, they are the address of a network address translation (NAT) computer or proxy server, not a specific client behind that NAT computer or proxy server.

Source

Si on souhaite désactiver cette fonction on peut le faire dans la base de registre:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet
Under the Internet key, double-click EnableActiveProbing, and then in Value data, type: 0. The default for this value is 1. Setting the value to 0 prevents NCSI from connecting to a site on the Internet during checks for connectivity.

On peut également créer son propre serveur pour utiliser cette fonction en modifiant les entrées du registre correspondantes.

Après recherche on tombe sur des articles plus détaillées comme Super User.

Cet article explique la possibilité qu’un attaquant aurait en mettant à jour le firmware de la carte réseau de détourner la machine. L’action se passant quasiment au niveau physique elle est indétectable. Une fois la carte infectée, l’attaquant peut lire et interagir (au prix de manœuvres succinctement expliquées dans l’article) avec le système, mots de passe, emails et infos confidentielles seraient donc « en libre-service ». L’article vous en dira plus là-dessus car il est bien écrit.

L’attaque est plus en niveau du « proof of concept » et elle est fortement dépandante du hardware mais malgré tout les implications font froid dans le dos !

Cet article m’a rappelé un autre évenement du printemps dernier : la vague de suspicion que les routeurs chinois contiendrait justement ce genre de backdoor ( un article ici ).

La sécurité d’un système d’information ne repose donc plus que sur le sytème d’exploitation, des services ou du réseau mais descend là fortement vers les couches physiques.

Le résultat du scan indique si vous avez du boulot pour changer les mots de passe ou alors le droit d’aller prendre un café !

Plus d’informations sur cette page pour l’utilisation du logiciel.

Pour Centos 5 / Red Hat Enterprise Linux 5 :

• Le guide de la NSA décrivant de façon complète la configuration et la protection du système. On doit à la NSA également le sytème de sécurisation kernel SE Linux et dans cet ouvrage elle décrit les différentes façon de sécuriser son système: des configurations générales à la description des différents services à activer ou désactiver. Accessible ici en téléchargement direct ou là sur le site de la NSA.

Pour Debian :

• Les Cahiers de l’Admin. Ce cahier de l’Admin fournit un ensemble suffisant de connaissances pour qui souhaite devenir un administrateur Debian GNU/Linux efficace et indépendant. Il traite des outils et méthodes qu’un administrateur Linux compétent maîtrise, depuis l’installation et la mise à jour du système jusqu’à la création de paquetages et la compilation d’un noyau Linux, en passant par la supervision, la sauvegarde et les migrations, sans oublier des techniques avancées telles que la mise en place de SELinux pour sécuriser des services, l’automatisation des installations ou encore la virtualisation avec Xen. En téléchargement direct ici et la page du livre chez l’auteur c’est ici.
• Le Guide de référence Debian. Un second livre complétant le premier et à garder sous la main. Et pour le lire c’est par ici.
• Sécuriser Debian. Même idée que pour le guide de la NSA mais fait par une équipe Debian ce guide vous sera utile pour sécuriser votre serveur Debian. Et c’est ici.

Voilà en espérant que cela vous sera utile.

Celles-ci portent sur 3 chaînes : INPUT (en entrée), FORWARD (dans le cas d’un routage réseau) et OUPUT (en sortie). Les actions à entreprendre sont ACCEPT (accepter le paquet), DROP (le jeter), QUEUE et RETURN.

Arguments utilisés :

* i : interface d’entrée (input)
* i : interface de sortie (output)
* t : table (par défaut filter contenant les chaînes INPUT, FORWARD, OUTPUT)
* j : règle à appliquer (Jump)
* A : ajoute la règle à la fin de la chaîne (Append)
* I : insère la règle au début de la chaîne (Insert)
* R : remplace une règle dans la chaîne (Replace)
* D : efface une règle (Delete)
* F : efface toutes les règles (Flush)
* X : efface la chaîne
* P : règle par défaut (Policy)

# lo : localhost (ou 127.0.0.1, machine locale)

Nous allons créer un script qui sera lancé à chaque démarrage pour mettre en place des règles de base

vi /etc/init.d/firewall

#!/bin/sh

# Vider les tables actuelles
iptables -t filter -F

# Vider les règles personnelles
iptables -t filter -X

# Interdire toute connexion entrante et sortante
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP

# —

# Ne pas casser les connexions etablies
iptables -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state –state RELATED,ESTABLISHED -j ACCEPT

# Autoriser loopback
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

# ICMP (Ping)
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT

# —

# SSH In
iptables -t filter -A INPUT -p tcp –dport 2222 -j ACCEPT

# SSH Out
iptables -t filter -A OUTPUT -p tcp –dport 2222 -j ACCEPT

# DNS In/Out
iptables -t filter -A OUTPUT -p tcp –dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp –dport 53 -j ACCEPT
iptables -t filter -A INPUT -p tcp –dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp –dport 53 -j ACCEPT

# NTP Out
iptables -t filter -A OUTPUT -p udp –dport 123 -j ACCEPT

#Si vous hébergez un sevreur web (Apache) :

# HTTP + HTTPS Out
iptables -t filter -A OUTPUT -p tcp –dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp –dport 443 -j ACCEPT

# HTTP + HTTPS In
iptables -t filter -A INPUT -p tcp –dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp –dport 443 -j ACCEPT
iptables -t filter -A INPUT -p tcp –dport 8443 -j ACCEPT

#Si vous hébergez un serveur FTP :

# FTP Out
iptables -t filter -A OUTPUT -p tcp –dport 20:21 -j ACCEPT

# FTP In
modprobe ip_conntrack_ftp
iptables -t filter -A INPUT -p tcp –dport 20:21 -j ACCEPT
iptables -t filter -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

#Si vous hébergez un serveur de mail avec SMTP, POP3 et IMAP :

# Mail SMTP:25
iptables -t filter -A INPUT -p tcp –dport 25 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp –dport 25 -j ACCEPT

# Mail POP3:110
iptables -t filter -A INPUT -p tcp –dport 110 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp –dport 110 -j ACCEPT

# Mail IMAP:143
iptables -t filter -A INPUT -p tcp –dport 143 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp –dport 143 -j ACCEPT

# Mail POP3S:995
iptables -t filter -A INPUT -p tcp –dport 995 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp –dport 995 -j ACCEPT

Lorsque vous avez défini toutes les règles, rendez ce fichier exécutable :

chmod +x /etc/init.d/firewall

Vous pourrez le tester en l’exécutant directement en ligne de commande. Assurez-vous d’avoir toujours le contrôle de votre machine (reconnectez-vous en SSH, vérifiez la disponibilité des services web, ftp, mail…). En cas d’erreur, redémarrez le serveur, les règles seront oubliées et vous permettront de reprendre la main. En revanche, si les tests s’avèrent concluants, ajoutez le script au démarrage pour que celui-ci protège le serveur dès le boot.

Afin de l’ajouter aux scripts appelés au démarrage :

update-rc.d firewall defaults (DEBIAN)
chkconfig –levels 345 firewall on (CENTOS,RHEL)

Pour le retirer, vous pouvez utiliser la commande suivante :

update-rc.d -f firewall remove
chkconfig –levels 345 firewall off (CENTOS,RHEL)

Redémarrez, ou exécutez /etc/init.d/firewall pour activer le filtrage.

N’oubliez pas de tester vos règles. Un mauvais choix peut entraîner une indisponibilité de votre serveur ou une perte de contrôle sur celui-ci avec le blocage de votre connexion SSH.

Vous pouvez utiliser IPtables sans passer par un script de démarrage et entrer directement les instructions en mode console. Pour bannir temporairement une adresse IP en cas de nécessité, utilisez la commande iptables -A INPUT -s adresse_ip -j DROP

via Alsa Créations