Securisation serveur

Autogire2 · Le 02/07/2014, à 17:32

Bonjour,
J'ai un site wordpress ici : http://airyhealth.com/ sur un serveur dedie virtuel

Ce que j'ai fais :

- iptables, tous les ports sont masqués sauf le 80
- fail2ban
- droits restrictifs sur le wordpress (755)
- mot de passe admin compliqué

Est-ce que c'est sufisant pour protéger ?
Si on se fait hacker et que notre serveur envoit du spam, on risque quoi ?

merci d'avance

bruno · Le 02/07/2014, à 17:40

Bonjopur,

Autogire2 a écrit :

- iptables, tous les ports sont masqués sauf le 80
- fail2ban

Quel intérêt si tu n'as pas d'autre services actifs que le serveur web ?

Autogire2 a écrit :

- droits restrictifs sur le wordpress (755)
- mot de passe admin compliqué

Ça ne veut pas dire grand chose en terme de sécurité…

Autogire2 a écrit :

Est-ce que c'est sufisant pour protéger ?

Non. Il faut surveiller le serveur et le maintenir à jour.

Autogire2 a écrit :

Si on se fait hacker et que notre serveur envoit du spam, on risque quoi ?

Ça dépend…

Autogire2 · Le 02/07/2014, à 17:57

Merci pour ta réponse

Je mettrai d'autres services plus tard.

Les ports cachés : Ca permet que mon serveur soit inexistant aux yeux des hackers (sauf le port 80 bien sur )

Fail2ban : Pour empêcher les attaques brutes forces ( je me connecte en ssh)

D'ailleurs j'ai changé le port ssh qui etait en 22 en un autre port

Bien sur, je fais attention qu'il soit à jour

tiramiseb · Le 02/07/2014, à 18:13

Les ports cachés : Ca permet que mon serveur soit inexistant aux yeux des hackers (sauf le port 80 bien sur )

N'importe quoi. Tu crois que les pirates se diront « oh mince, je ne vois que le port 80, ça veut dire qu'il n'y a aucun ordinateur à cette adresse IP vu que les autres sont "cachés" » ?

Fail2ban : Pour empêcher les attaques brutes forces ( je me connecte en ssh)

Si ton mot de passe est assez sûr (ou, mieux, authentification par clé SSH), alors pas de crainte à avoir de ce côté-là.

j'ai changé le port ssh qui etait en 22 en un autre port

Sécurité par l'obscurité.

Tout ce que tu indiques, ce ne sont que des choses très approximatives pour cacher quelques trucs, mais ce n'est pas du tout de la sécurité efficace.

Pour que la sécurité soit efficace, il faut :
- qu'un minimum de paquets soient installés
- qu'un minimum de services soient en fonctionnement
- que les mises à jour de sécurité soient systématiquement appliquées
- que ton serveur web soit correctement configuré et restreint
- que l'authentification par SSH soit sécurisée (idéalement authentification par clé avec mot de passe désactivé, sinon mot de passe complexe)

=> SSH sur un port autre que 22, ça réduit les logs car les scanners automatiques ne s'y connectent pas.
=> fail2ban, ça ne fait que bannir des adresses IP pendant quelques temps après quelques échecs et il faut correctement le configurer pour que ça marche bien, ce n'est pas magique (par contre ça peut te foutre dans la merde si tu te fais bannir par erreur)
=> ports cachés c'est un artifice d'amateur qui ne trompera en rien un pirate qui veut entrer sur ta machine

En gros, ce sont des protections d'amateur, pour des machines montées comme des amateurs, contre des amateurs...

bruno · Le 02/07/2014, à 18:15

Autogire2 a écrit :

Les ports cachés : Ca permet que mon serveur soit inexistant aux yeux des hackers (sauf le port 80 bien sur )

Cela ne change strictement rien. Si aucun service n'est en écoute sur le port xxx, il est inaccessible…
Le pare-feu est inutile sur une machine isolée bien administrée.

Autogire2 a écrit :

Fail2ban : Pour empêcher les attaques brutes forces ( je me connecte en ssh)
D'ailleurs j'ai changé le port ssh qui etait en 22 en un autre port

Modifier le port d'écoute de ssh n'apporte aucune sécurité, cela empêche juste les logs de se remplir avec les tentatives de connexions venant de l'extérieur. Tentatives qui échoueront forcément si ton serveur est bien configuré : comptes autorisés à se connecter en ssh avec mots de passe forts et/ou par clé.
Quoiqu'il en soit si tu changes le port fail2ban ne servira plus à rien (ou presque) pour les tentatives de connexion ssh.

EDIT : zut, grillé par tiramiseb

Dernière modification par bruno (Le 02/07/2014, à 18:16)

Autogire2 · Le 02/07/2014, à 19:57

Merci
Je pense que je suis bon alors, mon site est un site personnelle qui n'a pas vocation à être une multinationale.
Je voulais juste m'assurer que c'etait un minimum sécurisé.
Donc si je comprends bien je mets à jour régulièrement et je mets des mots de passe ça devrait suffire.
Tout ca je l'ai fais :
qu'un minimum de paquets soient installés
- qu'un minimum de services soient en fonctionnement
- que les mises à jour de sécurité soient systématiquement appliquées
- que ton serveur web soit correctement configuré et restreint
- que l'authentification par SSH soit sécurisée (idéalement authentification par clé avec mot de passe désactivé, sinon mot de passe complexe)

pires57 · Le 02/07/2014, à 20:05

tiramiseb a écrit :

En gros, ce sont des protections d'amateur, pour des machines montées comme des amateurs, contre des amateurs...

Voila la conclusion que je tire moi aussi, la "sécurité par l'obscure" (cf tes modifications des ports par défaut) n'apporte qu'un sentiment de sécurité, en réalité il n'apporte rien contre un vrai hacker, juste contre les petits script-kiddies qui vont se contenter de suivre des pauvres tutos de hacking dont les trois quarts des infos les dépassent complètement.
Ton firewall est inutile ici, si tu avait bien configurer tes services il ne te servirais absolument a rien.
Fail2ban pourquoi pas ... a condition que tu ne suive pas un pauvre tutos et que tu cherches vraiment ce dont tu as besoin avec une vrai configuration et pas un simple ban tout les 3 echecs ...

Brunod · Le 02/07/2014, à 20:46

Si tu caches ton port ssh, je ne vais pas le divulguer mais je suis certain que tu le retrouveras facilement dans la séquence qui suit Tout ça pour dire que ça n'a pas vraiment d'intérêt et qu'il existe de nombreux outils pour trouver plein d'infos. Les versions de tes plugins sont par exemple 3.0.0 et 0.9.4. C'est avec grand plaisir que j'aimerais poursuivre mes investigations, mais il faudrait que tu m'y autorises (et me prouve que c'est bien ton site )
BD

4:+2.89=
5=7_4=-2
0)7=[39&
0862<!{!
66/$3}+9
6,9>^3~5
63/;52)&
752%7^*~
74.8=$7}
2)5]7<7@
74>{5:{2
@4544#;&
;#965?(6
%?:<7569
77)/33>_
!8&6~}54
]9)%9$39
66[26/(]
7#.53&4-
6}]/559@
&)87$4%8
:62=(!83
49#*;3?6
5@4!7,3%
>859[2.~
;$>6273+
(88<,6;3
75?{(<36
%362[&@6
(253,{4:

pires57 · Le 02/07/2014, à 22:47

j'ai fait le test aussi, j'y ai trouvé mon bonheur également. merci nmap.
Edit: j'ai check aussi ton site web, tu as 8 erreur pour w3c ^^

Dernière modification par pires57 (Le 02/07/2014, à 23:15)

spinoziste · Le 03/07/2014, à 14:32

Si tu es anglophone je te conseille la lecture de ce billet pour compléter les pistes données par tiramiseb et pires57 .

http://www.cyberciti.biz/tips/linux-security.html

dudumomo · Le 08/07/2014, à 13:46

Hmmm la je suis pas trop d'accord avec vous....
Okay, changer le port SSH ne change rien pour un vrai hackeur, sauf que la majorite des hacks sont font encore trop souvent par des bots qui scannent les ports et font des combo de mot de passe a la con ou bruteforce. Du coup, ca limite un peu. (Bon ca n'augmente pas la securite, mais ca detourne les bots)
Perso je sens la difference dans les logs.

En revanche, un bon mot de passe et par cle, sera preferable et qui ne soit pas reutilise quelque part.

spinoziste · Le 08/07/2014, à 14:11

L' authentification par paire de clés en SSH est une condition sine qua non .

Si tu veux des pistes pour la sécurisation le web fourmille de blogs de sysadmin et de docs .
En effet lire des milliers de pages de man quand on est pas forcement sysadmin ça peut être fastidieux (mais à long terme tu ne peux y échapper ) .
Note que le mieux est toujours de trouver des docs , tutos , howto qui expliquent et ne donnent pas simplement des commandes et des tips .

pires57 · Le 08/07/2014, à 19:40

Ah? essayes de bruteforcer sur une auth private / public keys.
Je ne suis pas certain que ton bruteforce fonctionne...

spinoziste · Le 08/07/2014, à 20:02

@pires57 : Justement je disais qu'il faut utiliser l'authentification par paire de clés .

tiramiseb · Le 08/07/2014, à 21:05

dudumomo a écrit :

Perso je sens la difference dans les logs.

Oui, tu vois moins d'erreurs dans les logs, c'est normal. Mais bon, s'il s'agit juste d'avoir quelques Mo de logs en moins, l'avantage est limité...

En revanche, un bon mot de passe et par cle, sera preferable et qui ne soit pas reutilise quelque part.

Non, pas de mot de passe. Clé uniquement. Désactiver le mot de passe, carrément...

spinoziste · Le 09/07/2014, à 00:23

pires57 · Le 09/07/2014, à 00:32

Je sais spino ma remarque été pour dudumomo, il peut toujours essayer de bruteforcer cela

spinoziste · Le 09/07/2014, à 00:37

Au temps pour moi pires

mazarini · Le 09/07/2014, à 09:48

tiramiseb a écrit :

dudumomo a écrit :
Perso je sens la difference dans les logs.
Oui, tu vois moins d'erreurs dans les logs, c'est normal. Mais bon, s'il s'agit juste d'avoir quelques Mo de logs en moins, l'avantage est limité...

Ca permet de se concentrer sur les log restantes et éventuellement de ne pas rater un message important dans la masse.
J'utilise knockd qui permet d'ouvrir des ports pour une IP à la demande (pour le port 22 entre autre).

Je ne me fait pas trop d'illusion, si quelqu'un de compétent veut pénétrer ma machine, il y arrivera. J'essaye d'échapper à la masse des utilisateurs de scripts et de décourager les gens compétents.

tiramiseb · Le 09/07/2014, à 10:38

Ca permet de se concentrer sur les log restantes et éventuellement de ne pas rater un message important dans la masse.

« ne pas rater » ? Parce que tu passes ton temps à lire des logs ?
Les logs, on le les lit pas un à un, hein, on fait des recherches précises dedans quand on en a besoin. Qui dit "recherches précises" dit "grep" ou autres outils dans le genre, donc la quantité de logs au total importe peu...

J'utilise knockd

Moui pourquoi pas, moi je trouve ça un peu trop contraignant, sachant que SSH est de toute façon un logiciel particulièrement sécurisé...

J'essaye d'échapper à la masse des utilisateurs de scripts

Utilise une authentification par clé et désactive l'authentification par mot de passe.
Là, tu seras protégé contre toute tentative d'intrusion par force brute.

mazarini · Le 09/07/2014, à 11:22

tiramiseb a écrit :

Ca permet de se concentrer sur les log restantes et éventuellement de ne pas rater un message important dans la masse.
« ne pas rater » ? Parce que tu passes ton temps à lire des logs ?
Les logs, on le les lit pas un à un, hein, on fait des recherches précises dedans quand on en a besoin. Qui dit "recherches précises" dit "grep" ou autres outils dans le genre, donc la quantité de logs au total importe peu...

A priori, la différence entre nous se place au niveau de la compétence. Je suis incapable de faire une recherche précise. Je jette un œil aux log de temps en temps et j'essaye de comprendre puis faire disparaître si possible les message.

tiramiseb · Le 09/07/2014, à 11:44

Je jette un œil aux log de temps en temps et j'essaye de comprendre puis faire disparaître si possible les message.

Bah moi je jette jamais d'œil sur les logs... Tant que la machine tourne bien, qu'elle est correctement configurée et sécurisée, il n'y a pas grand chose à regarder dans les logs, sauf quand on recherche quelque chose de précis...

jplemoine · Le 09/07/2014, à 11:47

Regarder régulièrement les logs, c'est pas le boulot d'un système de supervision ?
Pour moi :
- vision régulière et systématique : système de supervision
- problème sur le serveur : l'humain regarde les logs.

tiramiseb · Le 09/07/2014, à 11:48

Et encore, la supervision ne regarde pas nécessairement les logs, la supervision regarde directement que les choses fonctionnent bien...

jplemoine · Le 09/07/2014, à 11:59

Ce que je veux dire, c'est que tu peux demander à la supervision de faire un grep précis à ta place et d'envoyer un avertissement et/ou un état critique s'il y a un certain nombre de détections --> dans ce cas, l'humain ne va voir les logs qu'un cas de détection.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 02/07/2014, à 17:32

Securisation serveur

#2 Le 02/07/2014, à 17:40

Re : Securisation serveur

#3 Le 02/07/2014, à 17:57

Re : Securisation serveur

#4 Le 02/07/2014, à 18:13

Re : Securisation serveur

#5 Le 02/07/2014, à 18:15

Re : Securisation serveur

#6 Le 02/07/2014, à 19:57

Re : Securisation serveur

#7 Le 02/07/2014, à 20:05

Re : Securisation serveur

#8 Le 02/07/2014, à 20:46

Re : Securisation serveur

#9 Le 02/07/2014, à 22:47

Re : Securisation serveur

#10 Le 03/07/2014, à 14:32

Re : Securisation serveur

#11 Le 08/07/2014, à 13:46

Re : Securisation serveur

#12 Le 08/07/2014, à 14:11

Re : Securisation serveur

#13 Le 08/07/2014, à 19:40

Re : Securisation serveur

#14 Le 08/07/2014, à 20:02

Re : Securisation serveur

#15 Le 08/07/2014, à 21:05

Re : Securisation serveur

#16 Le 09/07/2014, à 00:23

Re : Securisation serveur

#17 Le 09/07/2014, à 00:32

Re : Securisation serveur

#18 Le 09/07/2014, à 00:37

Re : Securisation serveur

#19 Le 09/07/2014, à 09:48

Re : Securisation serveur

#20 Le 09/07/2014, à 10:38

Re : Securisation serveur

#21 Le 09/07/2014, à 11:22

Re : Securisation serveur

#22 Le 09/07/2014, à 11:44

Re : Securisation serveur

#23 Le 09/07/2014, à 11:47

Re : Securisation serveur

#24 Le 09/07/2014, à 11:48

Re : Securisation serveur

#25 Le 09/07/2014, à 11:59

Re : Securisation serveur

Pied de page des forums