Amélioration de la sécurité pour FreeBSD à laide dIPFW et de SSHGuard

• Étape 1. Configuration d'IPFW
• Étape 2. Installez et configurez SSHGuard
• Étape 3. Créez un script de règles
• Étape 4. Démarrage et test
• Étape 5. Rester vigilant ...

Les serveurs VPS sont fréquemment ciblés par des intrus. Un type d'attaque courant apparaît dans les journaux système comme des centaines de tentatives de connexion ssh non autorisées. La configuration d'un pare-feu est très utile, mais en elle-même peut ne pas contrôler correctement les tentatives d'intrusion perturbatrices.

Ce tutoriel montre comment construire une barrière d'intrusion améliorée pour FreeBSD en utilisant deux programmes, le ipfwpare-feu et sshguard. SSHGuard est un petit programme complémentaire qui surveille les journaux système pour les entrées "abusives". Lorsque les délinquants tentent d'accéder, sshguarddemande ipfwde bloquer le trafic provenant de l'adresse IP du délinquant. Le délinquant est alors effectivement mis à l'écart.

Une fois que vous avez compris comment ces programmes fonctionnent, la gestion de la protection du serveur est assez simple. Bien que ce guide se concentre sur la configuration de FreeBSD, certaines parties s'appliquent à d'autres systèmes d'exploitation et logiciels de pare-feu.

Étape 1. Configuration d'IPFW

FreeBSD dispose de 3 pare - feu dans sa valeur par défaut ( GENERICnoyau), ipfw, pfet ipfilter. Chacun a des avantages et des fans, mais il ipfws'agit du logiciel de pare-feu natif de FBSD et assez simple à utiliser pour nos besoins. Il convient de noter que cela ipfwfait beaucoup de choses comme le montre sa page de manuel, mais des capacités telles que NAT, la mise en forme du trafic, etc., ne sont pas nécessaires pour la situation VPS typique. Heureusement, les fonctionnalités de base du pare-feu répondent facilement à nos exigences.

Pour démarrer le pare-feu au démarrage, ajoutez ce qui suit à /etc/rc.conf:

firewall_enable="YES"
firewall_script="/usr/local/etc/IPFW.rules"
firewall_logging="YES"

La servicecommande est disponible pour démarrer / arrêter le pare-feu manuellement:

[user@vultr ~]$ sudo service ipfw start

Naturellement, ipfwne fera rien tant qu'il n'ajoutera pas de règles, souvent à partir d'un fichier, dans cet exemple situé à /usr/local/etc/IPFW.rules. Le fichier de règles pourrait en fait se trouver n'importe où ou avoir un nom, tant qu'il correspond au paramètre "firewall_script". Le fichier de règles est décrit en détail ci-dessous.

Étape 2. Installez et configurez SSHGuard

sshguardest disponible en plusieurs versions pour une utilisation avec différents pare-feu. Utilisez l' pkgutilitaire pour récupérer et installer sshguard-ipfw:

[user@vultr ~]$ sudo pkg install sshguard-ipfw

Dans la plupart des cas, c'est tout ce qu'il faut faire. La variable appropriée est automatiquement insérée dans /etc/rc.confpour démarrer au démarrage:

sshguard_enable="YES"

Les valeurs par défaut fonctionnent normalement bien. Si différentes valeurs sont nécessaires, la sshguardpage de manuel donne des informations détaillées sur les paramètres:

# sshguard--program defaults, so don't need to be in rc.conf unless assigning different value
# sshguard_pidfile="/var/run/sshguard.pid"
# sshguard_watch_logs="/var/log/auth.log:/var/log/mail"
# sshguard_blacklist="40:/var/db/sshguard/blacklist.db"
# sshguard_safety_thresh="40"
# sshguard_pardon_min_interval="420"
# sshguard_prescribe_interval="1200"

Vous pouvez commencer sshguardpar l' serviceinvocation habituelle :

[user@vultr ~]$ sudo service sshguard start

Étape 3. Créez un script de règles

La partie la plus difficile consiste à créer l'ensemble de règles de pare-feu. ipfwpeut utiliser le /etc/rc.firewallscript fourni , mais il doit être modifié pour s'adapter à SSHGuard, ainsi qu'à différents scénarios opérationnels. Un certain nombre de pages Web et le manuel FreeBSD contiennent des informations utiles à ce sujet. Cependant, l'écriture d'un fichier de règles n'est pas si difficile, en outre, un ensemble de règles personnalisé peut être plus facile à comprendre et à modifier si nécessaire.

Une caractéristique importante des ipfwrègles est que le premier match l'emporte, ce qui signifie que l'ordre des règles est important. Dans ipfw, chaque règle est une commande et le fichier de règles est un script shell exécutable. Cela permet de modifier l'ensemble de règles en modifiant les règles, puis en exécutant le fichier de règles en tant que script shell:

[user@vultr /usr/local/etc]$ sudo ./IPFW.rules

En règle générale, un fichier de règles définira une variable pour la ipfwcommande, puis effacera les règles actuelles, émettra des règles génériques, puis procédera à la définition des règles "out", suivies des règles "in". La page de manuel ipfw et d'autres ressources contiennent une mine d'informations sur la structure des règles et les options qui sont pour le moins nombreuses.

Since the FreeBSD sshguard version has been updated to version 1.6.2, the method of inserting blocking rules for offenders has changed. Now the offenders' addresses are kept in an ipfw table (table 22 to be specific), rather than inserted into the rules above 55000 as before.

Fortunately, it's pretty simple to set up the rules file to use the table. It's just a matter of putting the table rule in the right place, and making sure to use the correct syntax when writing the rule.

When sshguard finds an offender, it puts the offender's address into its blacklist, and also inserts the address into the ipfw table so it will "trigger" denying access. This rule will accomplish these purposes:

01000 deny ip from table\(22\) to any

Il est toujours nécessaire de mettre des règles autorisant les services entrants au- dessus de 01000 dans ce cas. Par exemple, disons que l'adresse 10.20.30.40est un délinquant dans le tableau 22, et nous avons cette règle ipfw:

56420 allow tcp from any to me dst-port 22 in via $vif

Depuis ipfwrencontre la règle 01000 avant la règle 56420 , 10.20.30.40est bloqué . Il ne sera jamais du tout vu par la règle "autoriser 22 pouces". Si la règle d'autorisation avait un numéro "régulier" comme 00420 , le mauvais trafic serait autorisé et jamais bloqué (parce que 00420 est inférieur à 01000 et que "le premier match l'emporte").

Une caractéristique intéressante de la version mise à jour est que maintenant, lorsque sshguard démarre, toutes les adresses de la liste noire sont ajoutées au tableau et sont disponibles pour bloquer les délinquants entrants sans délai. La liste noire est cumulative et conservée entre les sessions.

À ce stade, il est probablement judicieux de montrer un ensemble de ipfwrègles complet modifié pour sshguard. Les commentaires devraient permettre de suivre assez facilement la logique des règles:

#!/bin/sh

# ipfw config/rules
# from FBSD Handbook, rc.firewall, et. al.

# Flush all rules before we begin.
ipfw -q -f flush

# Set rules command prefix
cmd="ipfw -q add "

vif="vtnet0"

# allow all for localhost
$cmd 00010 allow ip from any to any via lo0

# checks stateful rules.  If marked as "keep-state" the packet has
# already passed through filters and is "OK" without futher
# rule matching
$cmd 00101 check-state

# allow DNS out
$cmd 00110 allow tcp from me to any dst-port 53 out via $vif setup keep-state
$cmd 00111 allow udp from me to any dst-port 53 out via $vif keep-state

# allow dhclient connection out (port numbers are important)
$cmd 00120 allow udp from me 68 to any dst-port 67 out via $vif keep-state

# allow HTTP HTTPS replies
$cmd 00200 allow tcp from any to any dst-port 80 out via $vif setup keep-state
$cmd 00220 allow tcp from any to any dst-port 443 out via $vif setup keep-state

# allow outbound mail
$cmd 00230 allow tcp from any to any dst-port 25 out via $vif setup keep-state
$cmd 00231 allow tcp from any to any dst-port 465 out via $vif setup keep-state
$cmd 00232 allow tcp from any to any dst-port 587 out via $vif setup keep-state

# allow icmp re: ping, et. al. 
# comment this out to disable ping, et.al.
$cmd 00250 allow icmp from any to any out via $vif keep-state

# alllow timeserver out
$cmd 00260 allow tcp from any to any dst-port 37 out via $vif setup keep-state

# allow ntp out
$cmd 00270 allow udp from any to any dst-port 123 out via $vif keep-state

# allow outbound SSH traffic
$cmd 00280 allow tcp from any to any dst-port 22 out via $vif setup keep-state

# otherwise deny outbound packets
# outbound catchall.  
$cmd 00299 deny log ip from any to any out via $vif

# inbound rules
# deny inbound traffic to restricted addresses
$cmd 00300 deny ip from 192.168.0.0/16 to any in via $vif
$cmd 00301 deny ip from 172.16.0.0/12 to any in via $vif
$cmd 00302 deny ip from 10.0.0.0/8 to any in via $vif
$cmd 00303 deny ip from 127.0.0.0/8 to any in via $vif
$cmd 00304 deny ip from 0.0.0.0/8 to any in via $vif
$cmd 00305 deny ip from 169.254.0.0/16 to any in via $vif
$cmd 00306 deny ip from 192.0.2.0/24 to any in via $vif
$cmd 00307 deny ip from 204.152.64.0/23 to any in via $vif
$cmd 00308 deny ip from 224.0.0.0/3 to any in via $vif

# deny inbound packets on these ports
# auth 113, netbios (services) 137/138/139, hosts-nameserver 81 
$cmd 00315 deny tcp from any to any dst-port 113 in via $vif
$cmd 00320 deny tcp from any to any dst-port 137 in via $vif
$cmd 00321 deny tcp from any to any dst-port 138 in via $vif
$cmd 00322 deny tcp from any to any dst-port 139 in via $vif
$cmd 00323 deny tcp from any to any dst-port 81 in via $vif

# deny partial packets
$cmd 00330 deny ip from any to any frag in via $vif
$cmd 00332 deny tcp from any to any established in via $vif

# allowing icmp re: ping, etc.
$cmd 00310 allow icmp from any to any in via $vif

# allowing inbound mail, dhcp, http, https
$cmd 00350 allow udp from any 53 to me in via $vif
$cmd 00360 allow tcp from any 53 to me in via $vif
$cmd 00370 allow udp from any 67 to me dst-port 68 in via $vif keep-state

$cmd 00400 allow tcp from any to me dst-port 80 in via $vif setup limit src-addr 2
$cmd 00410 allow tcp from any to me dst-port 443 in via $vif setup limit src-addr 2

# SSHguard puts offender addresses in table 22. Set up the table rule
# Please note the '\(22\)' syntax, necessary since it's run as shell command
$cmd 01000 deny ip from table\(22\) to any

# allow inbound ssh, mail. PROTECTED SERVICES: numbered ABOVE sshguard blacklist range 
$cmd 56420 allow tcp from any to me dst-port 22 in via $vif setup limit src-addr 2
$cmd 56530 allow tcp from any to any dst-port 25 in via $vif setup keep-state
$cmd 56531 allow tcp from any to any dst-port 465 in via $vif setup keep-state
$cmd 56532 allow tcp from any to any dst-port 587 in via $vif setup keep-state

# deny everything else, and log it
# inbound catchall
$cmd 56599 deny log ip from any to any in via $vif

# ipfw built-in default, don't uncomment
# $cmd 65535 deny ip from any to any

Étape 4. Démarrage et test

Les besoins du système varient et différents choix de ports à bloquer ou à débloquer sont reflétés dans l'ensemble de règles. Une fois l'ensemble de règles terminé, enregistrez le fichier dans /usr/local/etc/IPFW.ruleset démarrez les services FBSD:

 # service ipfw start
 # service sshguard start

Le pare-feu augmenté devrait maintenant fonctionner! Vérifier sshguard:

 [user@vultr ~]$ sudo pgrep -lfa ssh

Si sshguardest en cours d'exécution, son pid et sa ligne de commande complète s'affichent:

720 /usr/local/sbin/sshguard -b 40:/var/db/sshguard/blacklist.db -l /var/log/auth.log -l /var/log/maillog -a 40 -p 420 -s 1200 -w /usr/local/etc/sshguard.whitelist -i /var/run/sshguard.pid

Cela montre l'ensemble de règles du pare-feu avec des statistiques et la dernière fois qu'un paquet correspond à la règle:

 [user@vultr ~]$ sudo ipfw -cat list

Après des heures ou des jours, les adresses des délinquants sont ajoutées à la liste noire et au tableau 22. Pour afficher toutes les adresses du tableau, utilisez cette commande:

ipfw table 22 list

Le résultat est imprimé comme:

10.10.10.118/32 0
10.10.10.72/32 0
...

Comme décrit ci-dessus, les connexions à partir de ces adresses sont interdites. Bien sûr, lors de la première exécution, sshguardil n'y aura pas d'adresses dans la liste, mais avec le temps, cela peut devenir assez long. Une option consiste à créer des règles de blocage distinctes pour les adresses avec plusieurs entrées dans le tableau, puis à les supprimer de la liste noire.

Étape 5. Rester vigilant ...

C'est une bonne idée de vérifier occasionnellement les journaux pour vous assurer que les intrusions sont contrôlées. Généralement /var/log/auth.loget /var/log/securitysont informatifs. Des lacunes ou des erreurs dans la couverture des services réseau peuvent apparaître. La modification de l'ensemble de règles du pare-feu selon les besoins fait partie de l'administration normale du serveur.

Dans les versions précédentes de sshguard, lorsque le /var/db/sshguard/blacklist.dbfichier était devenu volumineux, il pouvait empêcher sshguardde démarrer au démarrage du système. La suppression ou le changement de nom du fichier de liste noire a pu sshguardcommencer. Ce problème semble être résolu dans la dernière version de sshguard, donc cette solution de contournement n'est probablement plus nécessaire.

Assurez-vous de mettre en liste blanche l'adresse IP à partir de laquelle vous êtes connecté à la session SSH. Si vous vous verrouillez accidentellement, vous pouvez toujours vous connecter à la console noVNC sur https://my.vultr.com et mettre votre IP en liste blanche.

En résumé, en utilisant la combinaison de ipfwet sshguardaide à garder votre système FreeBSD sécurisé et à faire son travail. La réduction de l'activité réseau intrusive présente un avantage supplémentaire: moins de «bruit» facilite le suivi et le réglage du fonctionnement du système, contribuant à un serveur plus sûr et plus performant.

Protéger efficacement un système / serveur FreeBSD n'est pas particulièrement compliqué. Bien qu'un effort modeste soit nécessaire pour le mettre en service, il est rentable en termes de VPS et de sécurité de projet beaucoup plus importants.