HOW TO Release 2 - sécurité

[Flux]

Alors ce petit HOW TO fait suite ma (petite) expérience avec la distribution gentoo d’OVH (Release 2). Elle ne se prétend pas être complète dès aujourd’hui, donc je m’excuse auparavant auprès des utilisateurs avancés qui pourraient avoir des questions sur ce tuto, au contraire toute remarque constructive sur mon manque de connaissances, je prends !

*Pourquoi mon choix vers la Release 2 ? Parce que à mon sens leur Webmin est simple d’utilisation - après avoir été sous mutualisé pendant des années, je suis arrivé à certaines contraintes de développement sur mes sites et il me fallait une étape facile de transition-.

*Evidemment, il faut au préalable lire la documentation fournie par OVH (complète, claire et simple) :
http://guides.ovh.com/guides#link16
Si vous avez déjà administré vos sites sous le manager V3 de OVH, Mysql etc, je penses que l’utilisation est aussi simple si on prend le temps de lire ces guides. (Pensez toujours à sauvegarder vos fichiers et vos bases de données)


Avoir un serveur dédié, c’est devoir faire attention à ce qu’il soit bien protégé et donc devenir un bon administrateur. Et là vient le passage obligé vers certaines notions :
-comprendre le fonctionnement de Linux, son language
http://www.linuxpourlesnuls.org/v4/m...name=wiki_lpln
-les commandes fondamentales sous linux
http://www.linux-france.org/article/...ant-linux.html
-comprendre et apprendre comment utiliser le ssh :
http://www.amen.fr/domaine_hebergeme...sation_160.htm
Après bon nombre d’autres documents sont fournis, et il faut vraiment comprendre parfaitement le fonctionnement d’un serveur, ce ne sont que des exemples que j’ai trouvé pertinents.

Pour se connecter à son serveur deux logiciels selon moi indispensables (dans le Webmin il existe deux logiciels similaires dans l’onglet « autre »,dans l’ordre « Ouverture de Session SSH/Telnet » et « Gestionnaire de Fichiers » ) :
Putty pour gérer le serveur en invite de commande
WinSCPpour gérer les dossiers et les fichiers

Maintenant si vous êtes parano comme moi mais sans beaucoup d’expérience dans l’utilisation d’un tel environnement, voici les bases à faire selon les lectures que j’ai pu avoir dans le forum et l’aide que l’on m’a fournit.

1ère Etape, changer son identifiant et son mot de passe Webmin
Pour cela vous rendre dans l’interface de votre serveur puis dans Webmin, cliquez sur « utilisateurs webmin », cliquez sur « root », puis modifié le avec un nom d'utilisateur que vous seul connaitrez et un mot de passe différent de n’importe quel autre passe que vous utiliserez (pensez a cliquer sur « Inchangé » et sélectionnez « Remplacer par »).

2ème Etape, si vous êtes toujours sur la même machine avec une adresse IP fixe fourni par votre FAI(free,Orangeetc), alors n’hésitez pas à ne permettre la connexion que par cette IP sur votre Webmin, et ajouter au cas où celle d’un ami de confiance. (renseignez vous auprès de votre fournisseur d’accès, pour trouver son IP, google est votre ami)
Pour cela, se rendre dans Webmin, cliquez sur « Configuration de Webmin » puis « Contrôle d'accès IP ». Là renseignez les IP que vous avez et cochez « Autoriser seulement à partir des adresses listées ».

3ème étape, là on passe dans l’utilisation du SSH. Sécuriser l’accès au serveur via SSH de l’utilisateur root (le super utilisateur qui à tous les droit et donc tous les pouvoirs !).
-Déjà, pour ce que j’ai lu, si vous êtes le seul à vouloir touché au serveur, ne jamais laisser un autre utilisateur faire parti du groupe « wheel ». Il pourrait en effet via la commande –su, et sous condition qu’il connaisse le passe de root, accéder aux commandes normalement utilisables uniquement par root.

-Ensuite faire en sorte via l’utilisation de clef privé, clef public, que seul vous soyez capable d’accéder en root sur le serveur en ssh.
Sur le serveur dans /etc/ssh/ ouvrire sshd_conf puis modifier la ligne

.ssh/authorized_keys2

et remplacer par

.ssh/authorized_keys

Puis suivre le guide :
http://www.sos-dedie.com/index.php/2...ssh?spassage=1

4ème étape, il faut prendre connaissance le plus souvent possible de qui vient se connecter, et tente peut être de s’infiltrer dans ma machine, on parle alors de vérifier les log.
Les log se trouvent dans /home/log/ avec le fichier auth.log qui liste toutes les tentatives d’identification.
J’ai pue lire deux méthodes :
-Soi- même en allant l’ouvrir de temps à autre, ou en direct en faisant

cd /home/log/

puis la commande

tail -f auth.log

-Soit en utilisant Logwatch

emerge logwatch

qui vous envoie un récapitulatif par période déterminée (à compléter).

Vous remarquerez peut être comme moi, qu’à peine relié, votre kimsufi reçoit des tentatives d’entré de la même adresse IP, sous différents noms de user.

5ème étape, bloquer ces tentatives répétées d’intrusion via fail2ban.
Dans votre console, pour installer le programme :

Emerge fail2ban

Laissez l’installation se faire, puis aller dans /etc/fail2ban puis modifier le fichier jail.conf en modifiant les lignes suivantes :

[ssh-iptables]

enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
mail-whois[name=SSH, dest=votre@email.com]
logpath = /var/log/auth.log
maxretry = 3

A savoir :
bantime = changer ici le temps de bannissement en secondes (3600=1heure)
maxrentry = le nombre de tentative avant le bannissement (3 suffisant)

Enregistrez et fermez.
Puis lancer fail2ban en entrant:

fail2ban-client start

Vous pouvez utiliser ce logiciel pour vérifier les autres tentatives sur d’autres services de votre serveur (en cours/a compléter).
MAJ 24/6/08
Pour filtrer les tentative de connexion via votre serveur ftp (PROFTPD sur release 2)
Modifier dans /etc/proftpd le fichier proftpd.conf qui par défault ne contient pas les éléments nécessaire à :
-la création des log à surveiller
-les éléments de sécurité fondamentaux (sur ce point j'ai mis des lignes selon les différentes recommendations sur plusieurs forum/si vous avez d'autres recommandations, n'hésitez pas a m'en faire part)

Ouvrire donc ce fichier et remplacer le tout par :

ServerName "ProFTPD Default Installation"
ServerType standalone
DefaultServer on
RequireValidShell off
AuthPAM on
ShowSymlinks on
MultilineRFC2228 on
# Pour créer des log dans la liste des logs et faire fonctionner fail2ban sur proftpd
TransferLog /home/log/xferlog
SystemLog /home/log/proftpd.log

TimeoutNoTransfer 200
TimeoutStalled 200
TimeoutIdle 200

ListOptions "-l"
DenyFilter \*.*/

# Pour autoriser les clients à résumer les téléchargements, très utile. # Remember to set to off if you have an incoming ftp for upload.
AllowStoreRestart on

# Port 21 is the standard FTP port.
Port 21

# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask 022

# To prevent DoS attacks, set the maximum number of child processes
# to 30. If you need to allow more than 30 concurrent connections
# at once, simply increase this value. Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd).
MaxInstances 30

# Nombre maximums de tentatives de login
MaxLoginAttempts 2

# Set the user and group under which the server will run.
User nobody
Group nogroup

# To cause every FTP user to be "jailed" (chrooted) into their home
# directory, uncomment this line.
DefaultRoot ~

# Normally, we want files to be overwriteable.
AllowOverwrite on

# Message d'acceuil après une connexion réussie
AccessGrantMsg "Bienvenue %u chez Moi !"

# Pour ne pas donner d'info sur le serveur
DeferWelcome on
IdentLookups off
UseReverseDNS off

Après :

/etc/init.d/proftpd restart

Enfin dans /etc/fail2ban/ ouvrir fail2ban.conf et modifier les lignes suivantes:

[proftpd-iptables]

enabled = true
filter = proftpd
action = iptables[name=ProFTPD, port=ftp, protocol=tcp]
mail-whois[name=ProFTPD, dest=votre@mail.com]
logpath = /var/log/proftpd.log
maxretry = 3

Puis:

fail2ban-client stop
fail2ban-client start

Je précise qu'au moment où ce message est posté je n'ai pas eu de re-tentative de log via FTP, ayant vu dans mon auth.log des tentatives répété à J-1 j'ai voulu donc sécuriser par fail2ban les conexions via FTP.


Sur les autres infos que j’ai pu lire sur le forum et ailleurs, je continue ma recherche dans les articles que je trouve comme:
http://a-l.fr/blog/2007/07/28/kimsufi/
http://ladmin-linux.blogspot.com/200...-sa-bcane.html
Je ne donne que ces deux là car je cherche à faire étape par étape, il y a d’autres articles sous-jacents pour chaque question posée dans ces articles. Mais je souhaite ne donner au final que les solutions qui marchent et qui selon moi sont nécessaires.
Il y a aussi ce-ci : http://wiki.sos-admin.com/wiki/Accueil


Maintenant d’autres lectures comme on est dans un environnement gentoo :
http://www.gentoo.org/doc/fr/securit...y-handbook.xml

[mat00]

Excellent recueil d'infos

pour info dans la 3ème étape ce n'est pas le fichier sshd.conf mais sshd_config (en tout cas sur ma release gentoo version2)

Ma question : comment indiquer à logwatch à quelle adresse envoyer les logs?

[nemilos]

merci bcps pour ce récapitulatif

[Flux]

Envoyé par mat00

Ma question : comment indiquer à logwatch à quelle adresse envoyer les logs?

C'est en cours, dès que j'ai testé et que j'ai trouvé toutes les infos dessus je fais un petit tuto dans ce thread.

[nemilos]

mhh ok

[Flux]

up, j'ai mis à jour le tuto pour l'utilisation de fail2ban sur proftpd en dessous de MAJ du 24/6/8

Ps: mat00 j'ai corrigé en effet c'est sshd_config

[mat00]

Envoyé par Flux

MAJ 24/6/08
Pour filtrer les tentative de connexion via votre serveur ftp (PROFTPD sur release 2)
Modifier dans /etc/proftpd le fichier proftpd.conf qui par défault ne contient pas les éléments nécessaire à :
-la création des log à surveiller
-les éléments de sécurité fondamentaux (sur ce point j'ai mis des lignes selon les différentes recommendations sur plusieurs forum/si vous avez d'autres recommandations, n'hésitez pas a m'en faire part)

Ouvrire donc ce fichier et remplacer le tout par :

ServerName "ProFTPD Default Installation"
ServerType standalone
DefaultServer on
RequireValidShell off
AuthPAM on
ShowSymlinks on
MultilineRFC2228 on
# Pour créer des log dans la liste des logs et faire fonctionner fail2ban sur proftpd
TransferLog /home/log/xferlog
SystemLog /home/log/proftpd.log

TimeoutNoTransfer 200
TimeoutStalled 200
TimeoutIdle 200

ListOptions "-l"
DenyFilter \*.*/

# Pour autoriser les clients à résumer les téléchargements, très utile. # Remember to set to off if you have an incoming ftp for upload.
AllowStoreRestart on

# Port 21 is the standard FTP port.
Port 21

# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask 022

# To prevent DoS attacks, set the maximum number of child processes
# to 30. If you need to allow more than 30 concurrent connections
# at once, simply increase this value. Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd).
MaxInstances 30

# Nombre maximums de tentatives de login
MaxLoginAttempts 2

# Set the user and group under which the server will run.
User nobody
Group nogroup

# To cause every FTP user to be "jailed" (chrooted) into their home
# directory, uncomment this line.
DefaultRoot ~

# Normally, we want files to be overwriteable.
AllowOverwrite on

# Message d'acceuil après une connexion réussie
AccessGrantMsg "Bienvenue %u chez Moi !"

# Pour ne pas donner d'info sur le serveur
DeferWelcome on
IdentLookups off
UseReverseDNS off

Après :

/etc/init.d/proftpd restart

Enfin dans /etc/fail2ban/ ouvrir fail2ban.conf et modifier les lignes suivantes:

[proftpd-iptables]

enabled = true
filter = proftpd
action = iptables[name=ProFTPD, port=ftp, protocol=tcp]
mail-whois[name=ProFTPD, dest=votre@mail.com]
logpath = /var/log/proftpd.log
maxretry = 3

Puis:

fail2ban-client stop
fail2ban-client start

Bonjour Flux
J'ai colorié en vert ce qui me semble bizarre. Apparemment tu mets les logs proftpd dans /home/log/ mais le fail2ban va les chercher dans /var/log/...

Est-ce normal? Si non, où vaut-il mieux les mettre (/home/ ou /var/)?

Excellent tuto

[Flux]

Effectivement j'aurais du expliquer ce-ci...
En fait sous release 2, /var/log/ est un raccourci dossier vers /home/log/
Donc "normalement" pas de souci, en effet pour la vérification de ssh, fail2ban fait son œuvre, en revanche sur proftpd, je n'ai pas encore eu de tentative multiple de la part d'une même ip....donc j'attends de voir si il fait aussi son œuvre...

[Flux]

Correction j'ai un individu qui tente de rentrer via proftpd et qui après plusieurs tentatives au delà du quota, mais à quelques heures de différence toutefois, ne se fait pas bannir....
Il tente d'entrer via anonymous...


Je ne sais pas d'ailleurs si c'est écris dans un des articles que je donne en référence, mais pour l'avoir lu je l'ai fait immédiatement, ne souhaitant pas d'accès en ftp anonyme, j'ai ajouté dans la liste ftpusers (situé dans /etc/):
anonymous
ftp

Car apparement c'est la liste noire pour proftpd:

# /etc/ftpusers: list of users disallowed FTP access

Ajouté la liste des users que vous ne souhaitez pas pouvoir se connecter en ftp...

[Bruno]

Salut,

Très bon howto, juste quelques remarques :

2ème Etape, si vous êtes toujours sur la même machine avec une adresse IP fixe fourni par votre hébergeur, alors n’hésitez pas à ne permettre la connexion que par cette IP sur votre Webmin, et ajouter au cas où celle d’un ami de confiance. (renseignez vous auprès de votre fournisseur d’accès, pour trouver son IP, google est votre ami)

Il y a confusion entre FAI et hébergeur, j'ai peur qu'un débutant se dise "mon hébergeur [OVH] m'a fourni une adresse statique sur ma machine" et donc il va mettre l'IP de son serveur... et être bloqué. Enfin, il faut faire attention avec ce genre de blocage : certains FAI fournissent des IP qu'ils disent statiques mais en réalité elles ne font que changer moins souvent. N'autoriser que l'accès avec l'IP d'un amis, bof : il va falloir aller cher lui pour administrer sa machine ?? Selon moi, si on veut mettre en place de genre de blocage avec l'IP en dur, il suffit d'utiliser un VPN et de n'autoriser que le réseau du VPN (VPN + proxy sur le vpn), même si ça demande plus de connaissances (ça devrait pas être dur pour toi, mais vu la majorité des posts...). Mon propos s'applique aussi pour le SSH (même si le TCP over TCP c'est "le mal"), le système de clés restant un compromis.

Pour logwatch : je l'avais essayé, et au bout d'une semaine je ne lisais plus (trop long), pour finir par me rendre compte qu'un hack root de la machine faisait dire à logwatch ce qu'il voulait.

Enfin, les manips que tu proposes te font sortir de la release (tu es "hors release"), tu devras donc décortiquer les patchs d'OVH (ça demande des connaissances avancées là). Ça serait bien de le signaler (appliquer un patch à une hors-release peut se transformer en catastrophe pour un débutant).