Les sites de Djetdail Hors service

[Ypsos]

Bonjour

Bon courage, merci d'avoir relancé le serveur et réouvert ton site .

Tu penses avoir les archives de l'ancien pour re-alimenter ou tu dois tout refaire?

(ps la page VFR l'image en bas le lien est encore actif vers Virtuel pilote)

(ps virtuel pilote c'est terminé? faut changer de nom?)
(ps j'ai refais le lien vers ton site pour nos vidéo sur mon site: http://viphoamic.free.fr/forums.html#


@+

RL

[djetdail]

Oui, oui

J'ai les fichiers et les bases de données :-) ouf

Ayant lors de mes débuts " perdu " des sites bêtement, je sauvegarde toutes les nuits mes sites et leurs bases de données.

Sans cela il me serait impossible de recréer facilement les pages tutos.

Mon soucis maintenant c'est la sécurité, j'ai viré tous ce qui était trops personnel de mon serveur.

www.virtuel-pilote.fr est toujours marqué comme malveillant ... c'est chiant.

Hervé

[taigu]

Ouf, enfin. Je tourne sur un hippodrome depuis si longtemps, me voici enfin libéré, je vais enfin savoir descendre.

[Ypsos]

Oui, oui

J'ai les fichiers et les bases de données :-) ouf

Ayant lors de mes débuts " perdu " des sites bêtement, je sauvegarde toutes les nuits mes sites et leurs bases de données.

Sans cela il me serait impossible de recréer facilement les pages tutos.

Mon soucis maintenant c'est la sécurité, j'ai viré tous ce qui était trops personnel de mon serveur.

www.virtuel-pilote.fr est toujours marqué comme malveillant ... c'est chiant.

Hervé

tu changes en Virtuel-pilotes.fr ( avec un S cela devrait passer,
Ceci étant le nom est quand même dans la nature. et avec juste un s de différence c'est proche de l'ancien

simulateur-pilote.fr?

@+

RL

[Ypsos]

Ouf, enfin. Je tourne sur un hippodrome depuis si longtemps, me voici enfin libéré, je vais enfin savoir descendre.

Si tu quittes l'hyppo, tu es bon pour un 360 degrés.

[djetdail]

Le nom de domaine virtuel-pilote est associé à mon serveur.

Il est utilisable, mais il faudrais que plusieurs personne signale ici qu'il n'est plus vérolé.

On ne change pas de nom de domaine comme cela, il sont loué pour 1 ou plusieurs année.

[PhM]

Fait .

PhM

[Ypsos]

Le nom de domaine virtuel-pilote est associé à mon serveur.

Il est utilisable, mais il faudrais que plusieurs personne signale ici qu'il n'est plus vérolé.

Salut

Fait

@+

[Telmo]

Bien joué Hervé ;-)

Idem, signalé aussi !

[djetdail]

Merci à vous messieurs

Le coté positif est que cela me permets de faire une MAJ de mes tutos, et d'avoir envie de les compléter ..... mais d'abord 15 jours en Corse, après on verras :-)

[joloize]

Signalé aussi...

[harranssor]

Signalé.

Et bonnes vacances !

[Pierre]

Bonjour;

J'ai réinitialisé le serveur, changé de CMS.
Voici le nouveau lien, le site est en construction :

http://djetdail.fr/tuto_simuvol/

J'essaie de blinder l’accès au site, si vous avez des astuces je suis preneur.

Hervé

Bonjour Hervé,

Les trucs de base : protéger l'admin par un .htaccess avec identification et pq pas renommer le dossier admin si cela est possible.

Pierre

[Pascal]

Signalé.

Dans la liste des choses faisables pour sécuriser un serveur (dédié, certains points ne sont pas applicables sur un mutualisé):

- utiliser des mots de passe aléatoires longs (au moins 8 caractères alphanumériques aléatoires) qui ne sont utilisés qu'une seule fois (nulle part ailleurs).
- maintenir à jour tous les logiciels utilisés (OS, mais aussi services, CMS, etc)
- changer le port de connexion SSH et fermer le port 22 (les logs m'ont montré beaucoup de tentatives d'attaques sur ce port)
- vérifier la config du firewall (et n'autoriser que les ports réellement utiles)
- installer et configurer fail2ban ou eq. pour éviter les recherches par dictionnaire (et réduire les saturations d'accès)
- renommer le dossier phpMyAdmin : les logs montrent d'abondantes recherches de ce dossier en vue de tests extensifs de login.
- si possible, ne pas utiliser de CMS mais un design statique ou pseudo statique
- si utilisation d'un CMS, ne pas utiliser le nom du dossier racine standard, renommer les fichiers donnant des points d'accès critiques (pages de login)
- si possible, préférer les solutions logicielles perso ou à faible diffusion aux produits à grande diffusions
- pour toute création perso, tester méticuleusement l'intégrité des données transmises par les requêtes (y compris les headers $_SERVEUR) : injections SQL, injection de script XSS, accès indirects aux fichiers systèmes, etc)

j'en oublie sûrement...

[djetdail]

Signalé.

Dans la liste des choses faisables pour sécuriser un serveur (dédié, certains points ne sont pas applicables sur un mutualisé):

- utiliser des mots de passe aléatoires longs (au moins 8 caractères alphanumériques aléatoires) qui ne sont utilisés qu'une seule fois (nulle part ailleurs).

C'est fait

- maintenir à jour tous les logiciels utilisés (OS, mais aussi services, CMS, etc)

Drupal vérivie les mises à jour ( core et modules ) tous les jours, c'est déjà çà de moins à faire ...

- changer le port de connexion SSH et fermer le port 22 (les logs m'ont montré beaucoup de tentatives d'attaques sur ce port)

Je vais le faire, l'accès au serveur est t'il toujours valide sans modif supplémentaires ?

- vérifier la config du firewall (et n'autoriser que les ports réellement utiles)

A faire, il faut que je liste tous les ports utilisé, http 80, ftp 21, ssh 21ou22, .....

- installer et configurer fail2ban ou eq. pour éviter les recherches par dictionnaire (et réduire les saturations d'accès)

Je regarde, merci

- renommer le dossier phpMyAdmin : les logs montrent d'abondantes recherches de ce dossier en vue de tests extensifs de login.

Cela ne gène pas l'accès aux bases ?
et à l’accès à l'administration ?

- si possible, ne pas utiliser de CMS mais un design statique ou pseudo statique

Je n'ai pas la connaissance nécessaire, j'ai choisie Drupal en changement de CMSmadeSimple

- si utilisation d'un CMS, ne pas utiliser le nom du dossier racine standard, renommer les fichiers donnant des points d'accès critiques (pages de login)

c'est fait pour le nom de dossier
je vais regarder pour renommer les fichiers, et modifié leur chemin d'accès.

- si possible, préférer les solutions logicielles perso ou à faible diffusion aux produits à grande diffusions

pas assez de compétence/temps

- pour toute création perso, tester méticuleusement l'intégrité des données transmises par les requêtes (y compris les headers $_SERVEUR) : injections SQL, injection de script XSS, accès indirects aux fichiers systèmes, etc)

?? dans une autre vie :-(

j'en oublie sûrement...

Merci, y a déja des pistes et du boulot

Mes dossiers sont en 555
Mes fichiers sont en 444

@Pierre
" Les trucs de base : protéger l'admin par un .htaccess avec identification et pq pas renommer le dossier admin si cela est possible."

C'est fait

Merci à vous deux pour les astuces.
Merci à tous pour le signalement

Hervé