SECURITE : serveur attaqué

Salut :slightly_smiling:

Je sais que ça arrive tout le temps, mais j’aimerai votre avis.

J’ai un serveur fraichement installé qui semble très attaqué en ssh.

J’ai installé fail2ban :
voici une partie du jails.local:

[code][DEFAULT]
ignoreip = 127.0.0.1/8 192.168.1.0/24
findtime = 7200
bantime = 86400
maxretry = 3
backend = auto
destemail = xxxxxxxxxxxxx
banaction = iptables-multiport
mta = sendmail
protocol = tcp

[ssh]
enabled = true
port = ssh,sftp
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

[dropbear]
enabled = false
port = ssh
filter = sshd
logpath = /var/log/dropbear
maxretry = 3

[pam-generic]
enabled = false
filter = pam-generic
port = all
banaction = iptables-allports
port = anyport
logpath = /var/log/auth.log
maxretry = 3

[lighttpd]
enabled = true
port = http,https
filter = apache-auth
logpath = /var/log/lighttpd/*error.log
maxretry = 3

[lighttpd-noscript]
enabled = true
port = http,https
filter = apache-noscript
logpath = /var/log/lighttpd/*error.log
maxretry = 3

[lighttpd-overflows]
enabled = true
port = http,https
filter = apache-overflows
logpath = /var/log/lighttpd/*error.log
maxretry = 2

[/code]

J’ai activé l’envoie des mails pour avoir les infos en direct

Je me suis aussi fait un script que je relance dans le rc.local pour éliminer d’emblée les plages IP de certaines adresses qui reviennent très souvent dans les logs. Je remplis ce fichier ip.txt à la main.

[quote]#! /bin/bash
#voir site pour avoir les ip/masques
#https://www.countryipblocks.net/search_ip.php

for lineIP in $(sed -e ‘/^[ ]*#/d’ -e ‘/^$/d’ ip.txt)
do
echo Bannisement de : $lineIP
iptables -I INPUT -s $lineIP -j DROP

done
[/quote]

J’ai installé google_authenticator et l’ai activé sur 3 comptes qui sont membre du groupes sshusers
voilà le fichiere pam de sshd:

@include common-auth account required pam_nologin.so @include common-account session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close session required pam_loginuid.so session optional pam_keyinit.so force revoke @include common-session session optional pam_motd.so motd=/run/motd.dynamic noupdate session optional pam_motd.so # [1] session optional pam_mail.so standard noenv # [1] session required pam_limits.so session required pam_env.so # [1] session required pam_env.so user_readenv=1 envfile=/etc/default/locale session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open @include common-password auth required pam_google_authenticator.so

Et voici mon fichier sshd_config

Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key UsePrivilegeSeparation yes KeyRegenerationInterval 3600 ServerKeyBits 1024 SyslogFacility AUTH LogLevel INFO LoginGraceTime 120 PermitRootLogin no StrictModes yes RSAAuthentication yes PubkeyAuthentication yes IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication yes X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM yes AllowGroups sshusers

Et maintenant le truc qui gâche tout !!! vous allez me frapper…

J’ai un autre serveur chez un hébergeur (nommons le S2), sur lequel j’ai un serveur mercurial… Je n’ai qu’un acces ssh sur mon compte sur ce serveur.
Afin de synchroniser mes codes sources de S2 avec avec le S1… j’ai fait un script rsync sur S2 qui pour syncroniser les dépots de s1 à chaque commit… seulement pour ça, j’ai dû laissé une clef ssh sur S2… Donc, si quelqu’un pirate ce S2, et bien il a un accès à un compte de mon serveur 1… je ne vois pas trop comment faire autrement

Voilà, vous pensez que c’est assez fiable et robuste ou pas ? Merci d’avance pour vos conseils

EDIT :

Je ne vais pas modifier mes fichiers de départ sur le post, j’ajoute ci-dessous les modifs faites d’après vos conseils
J’ai changé :

  • le port ssh
  • le jails.local : ajout du port ssh, réduit à 1 le nombre de tentatives

Vite fait :
modifie le port
max retry = 1
bantime beaucoup plus long
Ça freine déjà pas mal

Voilà c’est fait… j’ai mis 7 jours de ban

Et pas un multiple simple : genre au lieu de mettre 3600 pour désigner une heure, mets un truc genre 3747.

:017 :017 :017

La raison :question:

[quote]
Et voici mon fichier sshd_config
Code:
Port 22
Protoc[/quote]

La première chose à faire pour un serveur ouvert à l’extérieur, c’est d’en modifier le port.

Je me suis posé la question aussi, la seule raison que j’ai trouvé, c’est que si on paramètre un robot pour se reconnecter, à la prochaine connexion valide, il pourrait retenir le temps de ban, et n’essayer qu’à ce moment là… ce qui économise des ressources à la machine attanquant.
Mais bon… avec un ban de 7 jours… je pense que c’est pas très utile.

Pour le port, j’avais déjà modifié

bonsoir,
en masquant ces informations (pour le port+iptables, je savais)
on peut voir le fichier config de ssh
si ce n’est pas possible, tant pis
A+
JB1

J’ai pas trop compris ce que tu voulais dire pour l’iptables.

Le fichier sshd_config est dans mon premier post

J’ai peut être quelque chose qui intéressera plus, si tu ne fait que utiliser Rsync entre les 2 machines alors met le en tant que service ! isalo.org/wiki.debian-fr/Rs … ue_service
Ça t’évitera de laisser trainer une clé SSH sur ton deuxième serveur.

Je viens de regarder, ce système ne permet pas la connexion sans identifiants.

Quand je fais un commit sur mon poste, ça déclanche un évenement sur le serveur 2, qui synchronise le dépot sur le serveur 1.

Si j’ai bien compris, la commande client de ce système va me demander le mot de passe… et ma synncro va être bloquée. Même s’il est possible de donner les identifiants en dans la commande… je préfère éviter un mot de passe écrit en clair dans un batch.

Il faut en plus ouvrir d’autres ports.

Changer le port ssh (par défaut 22) n’est que du cache misère, rien de plus.

En attendant, depuis que je l’ai fait j’ai pas eu la moindre attaque depuis 2h alors que c’était continu depuis 3 jours…

Dès le départ, [mono]fail2ban[/mono], aurait été installé ([mono]entre autres[/mono]) et configuré aux petits oignons … :033

Pourquoi tu dis ça ?? qui a dit que fail2ban n’était pas installé dès le départ ?
J’ai installé ce serveur il y a 3 jours, et j’ai remarqué ces attaques tout de suite grâce à fail2ban et autres justement.
Je viens juste poster pour voir comment améliorer la sécurité par rapport à ce que j’ai fait.

Par contre, à part critiquer les améliorations proposées par les autres, tu fais quoi ?
Tu fais pas honneur à ta signature en tous cas…

:017 :017 :017

La raison :question:[/quote]

vohu a répondu à la question, et j’ai eu l’occasion de le vérifier : avec un délai qui n’est pas rond, les tentatives de connexion s’arrêtent globalement plus vite.
Pour un ban de 7 jours, l’effet est clairement moindre.
De plus cette modification n’est pas infaillible, on est d’accord, mais cela apporte un peu plus de tranquillité, donc je l’écris pour ceux qui pourraient lire.

Tout le problème est dans l’expression minimaliste qui n’explique pas grand chose.

Oui, changer le port 22 ne protègera pas beaucoup si quelqu’un a décidé de vous attaquer, ou même pour les robots plus évolués.

Oui, changer le port 22 permet de réduire considérablement les tentatives de connexion faites par les robots par défaut.
Alors si on peut écumer 70% ( je dis ça au hasard ) des tentatives par cette modification et être un peu plus tranquille, je la fais aussi sur tous mes serveurs et ça a fait ses preuves ( je suis moins embêté ).

Pour durcir encore plus, il y a le port knocking.
Je ne suis jamais allé jusque là

Whaa, c’est trop cool ce truc :stuck_out_tongue:

port knocking :
J’avais essayé il y a quelques temps mais je ne me souviens plus pourquoi mais j’avais abandonné car il apportait d’autres inconvénients, lesquels :017