Le firewall temporisé

Chaque serveur a une faille de vulnérabilité: son port SSH
* Par lequel l'administrateur en prend le contrôle à distance.
* Par lequel le pirate cherche à faire de même.

Une première précaution consiste à ne pas utiliser le port 22,
archi-connu et systématiquement attaqué, mais un autre port, secret, aléatoirement entre 10000 et 65535.

Pour me connecter sur mon VPS, dont l'IP est 12.34.56.78, j'utilise une instruction bash de type
ssh -p12345 username@12.34.56.78

La variable PHP $_SERVER['REMOTE_ADDR'] m'a révélé que mon IP commençait toujours par 123.234
Les deux derniers octets varient, d'une connexion à l'autre, à chaque redémarrage de ma box Internet, branchée sur mon multiprise à interrupteur.
Que je coupe après avoir éteint mon ordi, pour éviter les fuites d'énergie.

Sans avoir vraiment une IP fixe, elle est cependant semi-fixe, sur les deux premiers octets.

J'ai donc programmé cette règle, dans UFW (Uncomplicated FireWall)
12345/tcp LIMIT IN 123.234.0.0/16
L'accès à mon port SSH exige donc une connexion depuis une adresse IP commençant par 123.234
Le filtre /16 ne retient que les deux premiers octets. Les deux derniers sont sans importance.

OK, je sais; Si mon FAI change mon range d'IP, je suis calé. Je connais et accepte le risque.
Mais je peux toujours demander une console, depuis l'espace client de mon hébergeur, pour modifier mon UFW.
Le pirate doit donc avoir une IP du même hébergeur, commençant par les deux mêmes octets.

J'ai donc ouvert le port avec LIMIT, et non avec ALLOW, pour limiter les tentatives de connexions.
Ce qui limite déjà drastiquement les risques, mais on peut encore faire mieux.

Vous connaissez déjà la crontab.
m h dom mon dow command
50 01 1 */4 * /home/bash/faisCeci.sh

Les firewall devraient s'en inspirer, pour limiter temporellement l'accès à certains ports.
Actuellement, un port est accessible 24/7

En cet article, je propose de modifier UFW, qui n'est jamais qu'une interface simplifiée d'IpTables
Pour déterminer des plages horaires d'accessibilité.
Par exemple, le mardi(dow 3) et le samedi(dow 0), à partir de 14:00, pendant deux heures.

On reprendrait la syntaxe de la crontab, déjà connue, à laquelle on ajouterait une variable de durée, en minutes.
Par exemple:
12345/tcp LIMIT IN 123.234.0.0/16 cron 0 14 * * 0,3 120

Afin de n'ouvrir mon port SSH que pendant mes heures habituelles d'utilisation,
définies par la syntaxe fictive inspirée de cron.

La plage horaire détermine la fenêtre d'ouverture de la connexion.
Une fois connecté, je peux rester en ligne indéfiniment, même au-delà de l'heure de fermeture de 16:00.

A ma connaissance, cette limitation temporelle n'existe pas.
Je propose de la créer, en ajoutant cette fonction dans les firewalls.

Cela compliquerait gravement une attaque par scanning de ports, telle qu'NMap
Qui peuvent s'étaler sur plusieurs jours, depuis des IP différentes, pour passer inaperçu.

En effet, un port testé en-dehors de sa plage horaire, sera réputé fermé.
NMap passera donc à côté.

Cette fonction de limitation chronologique d'ouverture de ports serait aussi utile à d'autres ports qu'SSH
Par exemple, un autre port http secondaire, distinct du port 80 par défaut
Qui donnerait accès à une application de contrôle, telle qu'un CPanel.

Ou bien un port Mysql, qui ne serait accessible qu'en semaine, pendant les heures de bureau.
Dans la mesure où tous les utilisateurs de Mysql sont cantonnés dans une même timezone, cela ne devrait pas leur poser problème.

A l'heure où la sécurité informatique est primordiale,
je pense que ma proposition de limitation chronologique de ports contribuerait à la renforcer.

Simple application du principe de moindre privilège.
Pourquoi laisser ouvert, en pleine nuit, le week-end, un port SSH ou Mysql qui n'est utilisé que de jour en semaine ?

Je propose aux concepteurs d'UFW d'y ajouter cette fonction de limitation chronologique, inspirée de cron.

Oooooof

dans cette idée, fermer le service plutôt que le port sera plus facile.
Sinon, fail2ban c'est bien aussi ^^"
Et concernant la co en ssh, on limite l'accès aux users donnés dans la conf ssh et un Maxretry à 3.
Et le couple user/key c'est mieux aussi pour la sécurité.

hth,

Tu peux aussi faire du port knocking