Auteur Sujet: [SSH] Sécuriser SSH (par Majinboo)  (Lu 4046 fois)

0 Membres et 1 Invité sur ce sujet

Hors ligne M_le_maudit

  • Administrateur
  • Petit NAS
  • *****
  • Messages: 91
  • Sexe: Homme
  • Il vit ! Il vit !
    • Voir le profil
    • Le Petit Serveur
[SSH] Sécuriser SSH (par Majinboo)
« le: 07 Octobre 2006 à 12:29:42 »
Bon je vais commmencer par un tout petit tutorial sur comment securiser un serveur SSH. Ca peut paraitre con mais les tentatives d'accès par SSH, je me prends regulierement sur ma passerelle alors que je suis en ip dynamique sans site web sur l'IP.

La configuration du serveur SSH est stockée en general dans le fichier sshd_config (en general ce fichier est dans le dossier /etc/ssh)

La premiere directive qu'il peut être interressant de modifier est Protocol La version 2 du procotole SSH est plus sécurisée donc autant n'autoriser que cette version en mettant cette ligne dans le fichier de config :
Citer
Protocol 2

Dans le cas d'une passerelle, on peut n'avoir besoin de l'accès SSH que depuis l'interieur du LAN, dans ce cas on peut tout simplement limiter le serveur SSH aux IP locales par le biais du firewall.

Maintenant on va s'occuper de determiner qui a le droit de se logguer, l'idée et d'interdire tout le monde sauf un certain nombres d'users (dans notre cas on autorisera que toto et titi) DenyUsers et AllowUsers fonctionnent de manière similaire, on autorise ou interdit une liste d'utilisateurs separés d'un espace et pouvant contenir des caractères joker comme ? et *.
Citer
AllowUsers toto titi

Dans certains cas, on ne connait pas forcement la liste des utilisateurs à  autoriser (ou alors cette liste évolue assez rapidement) On peut quand meme interdire certains utilisateurs sans remords
Citer
DenyUsers distcc root mysql
Tout depend de la machine et des services installés mais en général l'utilisateur sous lequel s'execute un service n'aura jamais besoin de se loguer en ssh.

Pour empecher uniquement root de se loguer par ssh il suffit d'utiliser la directive suivante :
Citer
PermitRootLogin no

Normalement à  ce stade là , on a limité l'accès à  seulement quelques comptes. Maintenant, on va se proteger contre une attaque de type force brute.

Il n'existe pas de solution efficace a priori utilisant uniquement sshd_config, il convient donc d'agir au niveau du firewall en n'autorisant que certains hosts à  se connecter au port 22 ou en limitant le nombre de tentatives de connections autorisées sur ce port pendant un certains laps de temps.

Dans tout les cas, il est important en tant qu'admin consciencieux de regarder les logs de temps en temps. Les tentativs de connections infructueuses sont consignées dans /var/log/auth.log . Un petit cat /var/log/auth.log l grep Invalid de temps en temps ne fait pas de mal.

PS: certaines personnes conseillent de changer le port utilisé par sshd, ça peut éviter certaines attaques mais avec un portscan, il est assez rapide de trouver le port du demon sshd.
Serveur SOHO
Boitier HTPC
Intel Core I5 760
16 Go DDR3
4xSATA 1.5 To + 1xSATA 500 Go
Seven (Eeeeehh oui !)

Hors ligne cben76

  • Disque externe
  • *
  • Messages: 48
    • Voir le profil
Re : [SSH] Sécuriser SSH (par Majinboo)
« Réponse #1 le: 20 Novembre 2006 à 10:08:42 »
Toujours sur la securisation de SSH, je suis tombé sur un complement d'information interessant ici

Ca decrit des fonctionnalités interessantes, comme l'utilisation d'un fichier clef sur usb plutot que de mdp.
Je retranscris l'article :

====

Secure SSH
Posted by ashwoods on Mon 30 Oct 2006 at 15:52

Tags: security, ssh, ssh security
SSH is not only the secure replacement for rlogin, rsh and telnet, which has been used in the past to do remote administration work, but there are also neat tricks like port forwarding, vpn tunneling and file transfers that you can do with minimal configuration work, leaving only one port open to the internets.

If you keep your SSH server up to date and choose your passwords wisely, you can sleep well at night without worrying about all those script kiddies and bots scanning your ports and attacking your SSH server with brute force or dictionary attacks.

You will however see constant attacks in your logs like these:

Oct 20 16:03:51 server02 sshd[26405]: Illegal user ftpuser from ::ffff:81.56.195.220
Oct 20 16:03:52 server02 sshd[26407]: Illegal user ftpuser from ::ffff:81.56.195.220
Oct 20 16:03:53 server02 sshd[26409]: Illegal user ftpuser from ::ffff:81.56.195.220
Oct 20 16:03:54 server02 sshd[26411]: Illegal user ftpuser from ::ffff:81.56.195.220
Oct 20 16:03:56 server02 sshd[26413]: Illegal user ftpuser from ::ffff:81.56.195.220

This doesn't mean a hacker is trying to break in using some SSH exploit, these are normally automated attempts from zombie bots or script kiddies with dictionary attacks to break into your system, sometimes using virus infested machines to do the work. You can get hundreds of attempts every day, and this might make you feel a little bit uneasy.

Even if SSH is very secure out of the box, there are several things you can do to make it more secure and avoid all those emails logs full of bot attacks, without having to configure a full blown IDS system. The following tips apply to OpenSSH on a debian system, but should be very similar in other systems.

How you secure SSH will depend on your specific needs, so the first step is to consider your current use of SSH. Are you a roadwarrior and connecting to your servers from different computers or IP addresses, do all the users of the system really need SSH?

It is better to make the changes locally, as you might lock yourself out while reconfiguring your network.

Step 1 : Secure the default SSH configuration.

You can find more detailed information on debiansec or OpenSSH, this basic steps are:

a) Don't allow root to remote login

PermitRootLogin no

It is safer to login as another user and use su.

b) Limit the users or groups that can login in remotely.

AllowUsers me
AllowGroups mygroup
DenyUsers paul
DenyGroups paulsgroup

Unless you are a ISP you can normally limit the users that can login to a few. You can also limit your users to certain machines or hosts.
c) Allow only Protocol 2:

Protocol 2

Protocol 1 is less secure and obsolete.

d) Use PubkeyAuthentication authentication instead of passwords:

PubkeyAuthenticationPasswordAuthentication No
ChallengeResponseAuthentication no
Instead of using a password to login, a keypair is placed on the server and the client. The client can prompt for a paraphrase, but no password is sent over the network. If you connect from several computers, you have to have the key on each one or carry it around in a USB stick. Howto configure.

e) Change the default port 22 to something higher

Port 2899


I consider this security by obscurity. This makes it only one step "harder" for a determined hacker (all he has to do is scan your ports), but it does help with most automated bot attacks, most scripts check only for port 22 because scanning ports is time consuming. This trick alone will empty most of your logs of attack junk.

f) don't listen on all addresses if posible:

ListenAddress 192.168.1.5

Step 2: Re-configure your firewall - block those connections in the first place
There are several ways of doing this. The easiest way is to limit connections to certain IP's or subnets. This may not be practical if you are constantly on the road and need SSH access, more complex set ups like port knocking are also possible.

a) configure your firewall to allow only certain IP's (or subnets) if posible.

b) install some nice brute force attack detectors - there are several packages that can detect a brute force attack and block those IP's automatically.

On debian I use the aptable denyhosts python script, that automatically blocks ssh brute-force attacks by adding entries to /etc/hosts.deny. You do have to check if you are not blocking legitimate IP's, attacks can be spoofed or come from an innocent virus infested machine.

Other similar programs update your iptables configuration, like apf + bfd, that scan your log files for breakin attempts and create automatic rules blocking the IP of the attacker.

Step 3: Extra security - One time passwords and port knocking

The steps mentioned above will clear up your logs and make your system more secure. But there are certain scenarios that could benefit from some extra security work. If you have many users that must have access from anywhere in the world (including unsecured computers), and having them carry their key in a USB stick is not practical, you can make them use one time passwords, libpam-opie:

Use OPIE one time passwords for PAM authentication. A one time password is useful to avoid having your password sniffed and reused if you log in via an unencrypted channel or from a compromised system. The PAM module enables OPIE for programs such as SSH which use PAM for authentication.

Sounds interesting, but I have never set this up myself, and even if OPIE passwords are really good against keyloggers, I prefer using key-host based authentication.

Another very interesting concept is Port Knocking:

port knocking is a method of externally opening ports on a firewall by generating a connection attempt on a set of prespecified closed ports. Once a correct sequence of connection attempts is received the firewall rules are dynamically modified to allow the host which sent the connection attempts to connect over specified port(s)

In other words, your SSH port is closed, until you send a specific secret combination of packets. So even a hacker would have a hard time finding your SSH port in the first place.

Here is a list of several port knocking implementations, and a here's a shorewall config.

Some extra advice!

This advice concerns linux security in general, most people are lazy so I will repeat them.

Enforce good passwords: install libpam_cracklib: a PAM module that tests passwords to make sure they are not too weak during password change.

Read your logs! Install logcheck and/or logrotate to make your log reading life easier.

Keep your system up-to-date! For non-critical debian systems you can use something like unattended-upgrades to keep the security packages updates automatic.

There are several packages that can improve security with little effort: tiger, harden, bastille and a firewall of choice.

**** Disclaimer: Do I really need this? I am not an expert, so read all the docs anyways.***
Am I missing anything?

**** This is a copy of article I wrote for my blog, and posted it here because of its usefulness. For "current versions" (if i ever have to update it) will be here: http://www.xthought.org/blog/2006/secure-ssh ****
cheers, ashley

Hors ligne bussiere

  • Disque externe
  • *
  • Messages: 3
    • Voir le profil
Re : [SSH] Sécuriser SSH (par Majinboo)
« Réponse #2 le: 20 Novembre 2006 à 15:27:16 »
un petit tuto en plus que j'ai trouvé :
http://www.suso.org/docs/shell/ssh.sdf


Bussiere

Hors ligne DrDrakeRamore

  • Disque externe
  • *
  • Messages: 3
    • Voir le profil
Re : [SSH] Sécuriser SSH (par Majinboo)
« Réponse #3 le: 28 Mai 2007 à 10:44:38 »
Perso je fais tourner ssh sur des ports > 1024. Ca n'empêchera pas quelqu'un qui veut vous brute forcer de le faire, mais beaucoup de scripts utilisés par les script kiddies qui circulent se contentent de scanner les ports classiques.
Dans sshd_config, c'est tout simplement à la ligne "Port ##".

edit: oups je viens de voir que c'était déjà indiqué dans un poste au-dessus

Sinon pour sécuriser encore plus, mais là il faut vraiment en vouloir  :laugh: : le port knocking. C'est costaud mais pas vraiment exploitable si on administre beaucoup de machines. C'est plutot pour le particulier un peu parano ou juste curieux.
Le principe : un process écoute sur différents ports. Si il détecte une séquence particulière, (de mémoire je crois qu'il suffit d'envoyer des paquets syn), il lance un serveur associé, sshd par exemple, permettant à l'utilisateur qui a frappé aux ports de se connecter.

http://www.portknocking.org/
« Modifié: 28 Mai 2007 à 10:48:37 par DrDrakeRamore »

Hors ligne majinboo

  • Disque externe
  • *
  • Messages: 35
    • Voir le profil
Re : [SSH] Sécuriser SSH (par Majinboo)
« Réponse #4 le: 28 Septembre 2007 à 08:47:35 »
CHanger le port ne sert à rien. C'est très facile de detecter quel service repond sur quel port avec un portscan. De plus le soucis d'utiliser des ports qui ne sont pas reservés à root, c'est qu'un user peut déjà être en train de LISTEN sur ce port là.