Discussion :

[PhilDeDakar]

Bonjour
Je désire sécuriser le mieux possible mon serveur Ubuntu Linux 16.04.1.
(Apache2, SSH, Webmin, PostgreSQL)
j'ai donc :
1° paramétré le firewall pour n'accepter que les protocoles/ports utilisés
2° installé/paramétré DenyHosts (test de blacklistage d'une adresse effectué)
3° mis ssh sur un port différent que le port 22 et désactivé la connexion par l'utilisateur root
4° https sur le site web
5° installé rkhunter

Mes questions :
1° Existe-t-il un programme permettant de tester les failles potentielles du système (j'ai déjà testé les ports avec Advanced Port Scanner) ?
2° Es-qu'il y a d'autres actions à apporter ?

Merci d'avance

ps
je suis débutant...

[chrtophe]

En action supplémentaire :

- Ne pas démarrer webmin automatiquement
- utiliser le port knoking avec ssh
- peut-être utiliser fail2ban à la place de denyhost

[PhilDeDakar]

bonjour et merci de m'avoir répondu.
J'ai remarqué que dans le fichier /var/log/auth.log des lignes comme celles-ci:
May 13 06:25:33 seda sshd[17020]: Invalid user mg@123 from 84.45.251.243
May 13 06:25:42 seda sshd[17023]: Invalid user applgrc from 200.207.216.138

j'en conclu que l'on essayait de l'extérieur différents user afin de pénétrer le système. Heureusement pour moi denyhost fait son boulot et bloque les adresses ip.
Ma question : existe-t-il un programme faisant l'inventaire des users qui ont été testé (comme denyhost fait pour l'adresse ip)
Le must serait que lors de la création d'un user, ce programme nous alerte que cet user appartient à cette liste (juste une alerte)

Encore merci

[scamphp]

Un filtre de paquets comme nftables ne peut bloquer que des paquets en fonction de leurs caractéristiques (protocole, adresses IP source et destination, ports source et destination si applicable au protocole... et bien d'autres). Ce n'est pas toujours suffisant pour déterminer si un paquet est légitime ou pas, notamment quand il répond à un autre paquet. On doit alors utiliser d'autres informations liées aux paquets comme le suivi des "connexions" auxquelles les paquets appartiennent.

[BufferBob]

salut,

1° Existe-t-il un programme permettant de tester les failles potentielles du système (j'ai déjà testé les ports avec Advanced Port Scanner) ?

possible, mais ça ne fait pas le café de toutes façons, la meilleure façon de sécuriser c'est de comprendre les principes de sécurité et le fonctionnement de sa machine

par exemple interdire la connexion en root c'est bien, mais si on peut se connecter en user test avec un mot de passe 'toto', et que le mot de passe root est aussi un truc genre 'love1234', alors on se fera quand même pirater.

2° Es-qu'il y a d'autres actions à apporter ?

concernant sshd, restreindre l'accès par clé publique uniquement c'est une bonne solution, la seule chose à laquelle il faut faire attention c'est de ne pas perdre ses clés et ne pas laisser la clé privée accessible par quelqu'un d'autre
ce qui peut se faciliter encore une fois par l'utilisation systématique d'un gestionnaire de mots de passe (qui souvent gère aussi les clés) comme Keepass2.

bref, au delà de la technique et des fichiers de configuration, c'est avant tout avoir les bons réflexes qui va faire la différence.

autre exemple, tu vois passer des lignes (...) sshd(...) Invalid user (...) from (...), on serait tenté de vouloir mettre une alerte sur ces tentatives échouées, mais si on y réfléchit qu'est-ce que ça peut bien nous faire ?
le gars essaye et il se plante, ok, ça veut juste dire que mon système fait bien son boulot (ou que le pirate est mauvais), il serait en revanche bien plus utile d'alerter quand un utilisateur réussit à se logguer, car c'est peut-être juste nous, mais ça peut aussi être un pirate, et là pour le coup cette information on veut vraiment la connaitre.

de manière basique on pourrait imaginer un script qui tourne toutes les minutes (crontab) et qui vérifie qui s'est loggué avec succès depuis le dernier check (1 minute plus tôt donc), quand un utilisateur est identifié on envoie une notif sur le smartphone ou un mail ou autre etc. et si on veut faire ça en temps réel on peut envisager d'utiliser un outil comme sec.pl (simple events correlator) au lieu de mettre en crontab.

[Lekno]

Vous pouvez également privilégier une authentification SSH par clef publique/privé.