Archives par mot-clé : Ubuntu

Bien recevoir son serveur dédié (suite : c’est jamais fini)

Je reviens sur la sécurisation de mon petit serveur.Je dois avouer que depuis le changement de port SSH, je suis plutôt tranquille. Je vais tout de même aller plus loin en réduisant la liste des users autorisés à se connecter via SSH.

Et comme toujours, c’est relativement simple. On édite le fichier /etc/ssh/sshd_config et on ajoute une ligne du type :

AllowUsers moncompte

Netbeans & Unity : ça marche presque tout seul

netbeans-ayatana-header

Dans un précédent article, je partageai un plugin Netbeans pour profiter du menu global du bureau Unity d’Ubuntu. Et bien chers amis, je vous le dis : n’installer plus ce plugin.

Ne vous inquiétez pas, je ne viens pas vous annoncer une nouvelle faille de sécurité dans ce plugin (c’est à la mode en ce moment). C’est juste que son utilisation n’est plus nécessaire car les dépôts officiels d’Ubuntu contiennent la librairie Ayatana qui s’appliquera à tout vos programme Java. Et oui, vous m’avez bien lu : « à tous vos programme Java ».

Si sur votre poste, on peut trouvez un browser Cassandra écrit en Java, un serveur bouchon SMTP écrit en Java, tous profiteront du menu centralisé et surtout de la recherche dans les menus.

Elle est pas belle la vie ? Comment on fait maintenant ?

Et bien rien si vous êtes passé à Ubuntu 15.04, c’est actif automatiquement.

Et pour les autres, restez concentré, ça va aller vite :

sudo add-apt-repository ppa:danjaredg/jayatana
sudo apt-get update
sudo apt-get install jayatana

Bien entendu, ça fonctionne aussi pour les non développeurs, ça fonctionne aussi avec jDownloader.

Netbeans ne passera pas à côté d’Unity

Si parmis les IDE gratuits, comme moi, votre préférence se porte sur Netbeans (déjà je vous aimes bien car, d’une part, je n’en rencontre pas si souvent, et d’autre part, comme tout être humain, j’aime ceux qui me ressemble 😉 ). Et si comme moi, vous avez abandonné le système aux « fenêtres » pour quelque chose d’un peu plus underground comme Ubuntu, alors cet article va vous intéresser.

Vous n’êtes pas sans savoir que le bureau officiel d’Ubuntu est maintenant, et depuis quelques versions, Unity. Et vous avez sûrement remarqué que les menus des applications sont intégrés à la barre principale de l’OS (qui fait maintenant office de barre de titre des fenêtres, menu de la fenêtre, barre de notification et menu du système). Si vous avez bien poussé la porte de la 12.04, vous devriez pas avoir loupé le nouveau système de recherche indexée HUD qui permet de rechercher dans les menus des applications sans avoir à les retenir par cœur. Bref, c’est génial mais, ça ne fonctionne pas pour les applications Java comme Netbeans.

N’étant pas le premier Java Geek, d’autres sont passé avant moi pour intégrer la barre de menu de Netbeans à HUD. Et c’est Dan Jared qui, après avoir indiqué sur son blog comment installer son plugin Java Ayatana pour Netbeans (http://danjared.wordpress.com/netbeans/), semble avoir finalement distribuer ce plugin dans l’update center d’Oracle (http://plugins.netbeans.org/plugin/41822/java-ayatana).

Pour rappel, Ayatana est le nom donné par la communauté Ubuntu pour unifier tous les efforts faits autour l’intégration d’Unity. Ca va du menu global dont on vient de parler dans le cas de Netbeans jusqu’au notifications (https://wiki.ubuntu.com/Ayatana). Notre ami maintient la librairie qui va vous permettre d’intégrer les menu Swing dans le menu global d’Unity : http://code.google.com/p/java-swing-ayatana/

 

 

Bien recevoir son serveur dédié (suite part 2)

J’ai dans mon panier 2 solutions à mes problèmes d’attaque de force brute sur ma connexion SSH :

  • le démon denyhosts
  • et, plus simplement, changer le port par défaut d’écoute de SSH

denyhosts

denyhosts, c’est un processus daemon qui scrute votre fichier de log où se trouve toutes les traces de tentatives de connexions. Toutes les hosts qui génèrent trop d’erreur de connexion seront blacklisté.

L’installation prend 2 secondes sous Ubuntu :

sudo apt-get install denyhosts

Et voilà, c’est fait et c’est fonctionnel. Vous trouverez les fichiers listant les tentatives suspicieuses de connexion dans :

/var/lib/denyhosts

Il ne restera plus qu’à compléter le fichier de configuration avec un serveur d’envoi des mails pour recevoir une alerte à chaque fois qu’une adresse est ostracisée.

Changer de port

Par défaut, SSH écoute sur le port 22. Il est facilement modifiable dans le fichier :

/etc/ssh/sshd_config

Puis par un simple arrêt / relance du démon SSH :

/etc/init.d/sshd restart

Vous devriez voir le nombre de tentative se réduire drastiquement.

Toutefois, il faut être vigilant sur cette dernière astuce (et sur celle qui consiste à empêcher l’utilisateur root de se connecter). Je ne sais pas comment ça se passe pour les autres hébergeur mais chez OVH, lorsqu’ils livrent un serveur, ils installent une clef pour pouvoir se connecter en root lorsqu’une intervention est nécessaire. Interdire l’utilisateur root ou changer le numéro de port rendra toute intervention de l’hébergeur impossible. Renseignez-vous bien auprès de ce dernier ou, au moins, ayez conscience que vous serez à bord et que si vous n’avez plus accès à votre machine, il n’y aura plus d’autre choix que de la réinstaller (d’où l’importance d’avoir un plan de sauvegarde bien roder 🙂 ).

Ma dernière grande passion : les souris et les Roccat

La santé d’abord

J’ai récemment accordé une importance certaine à la préservation de mon canal carpien (en particulier celui de mon poignet droit). Et même si vous êtes encore jeune, je ne saurai que trop vous conseiller d’en faire autant. Une bonne souris coûte dans les 50 euros mais votre main est tellement mieux posée dessus (que sur les espèces de mocheté qu’on nous refile au boulot). Certes ça n’apporte pas de productivité immédiate mais vous pourrez rester plus vieux devant votre écran sans vous plaindre ;p

Et pour trouver une bonne souris, rien de tel que d’aller voir du côté du matériel des joueurs professionnels. Personnellement, je me suis arrêté sur 2 modèles qui ont la particularité de présenter de la hauteur:

  • Une Razer Imperator que je conserve au bureau (et qui aura eu le mérite de faire parler mes collègues grâce à son logo lumineux).
  • Une Roccat Kone+ pour la maison (quoiqu’elle pourrait faire jaser mes collègues grâce aux réglage lumineux qu’elle propose). Mais là où elle m’a beaucoup intéressé, c’est qu’une ale généreuse fournit un pilote pour Linux.

Installation des pilotes

Ma Kone+ est donc compatible avec mon Ubuntu ; elle est pas belle la vie ! On trouve tout sur ce site : http://sourceforge.net/projects/roccat/. Quelque soit votre matériel Roccat, jetez-y un coup d’œil, il y en a pas mal de supporté.

Et comme je suis sympa, voici comment ça s’est passé pour moi. Tout d’abord, il faut bien comprendre qu’il y a 3 composants : un module pour le noyau Linux qui répond au doux nom de kmod-roccat, un paquet commun roccat et un paquet spécifique pour votre matériel (dans mon cas koneplus).

Pour le module du noyau, rien de plus simple il n’y a rien à faire pour une Ubuntu 11.10 car le noyau installé est en version 3.0 et le module kmod-roccat est intégré au noyau depuis au moins la version 2.6.39.

Pour les 2 paquets restant les étapes sont simples et similaires. Il faut tout d’abord installer quelques paquets depuis les dépôts officiels afin de compiler les sources :

sudo apt-get install libgtk2.0-dev libudev-dev libnotify-dev libcanberra-dev libunique-dev libdbus-glib-1-dev libusb-dev

Donc, pour chaque paquet, on le dé-zippe, on se place dans le répertoire fraîchement créé et on tape les commandes suivante :

mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX="/usr" ..
make
sudo make install

Si vous êtes comme moi et que vous n’aimez pas trop les installations depuis les sources (par peur de la prochaine mise à jour du système), vous serez content de trouver ici les résultats des commandes make install pour chaque paquet : Logs install Roccat

On lit bien la documentation jusqu’au bout pour remarquer qu’il nous faut aussi créer un groupe roccat et ajouter notre utilisateur dans sa liste :

sudo groupadd roccat
sudo usermod -a -G roccat $USER

C’est officiellement terminé. Sauf que ce n’est pas vrai, il y a un petit détail.Lorsque la souris est branchée sur le connecteur USB, le noyau déclenche des règles udev qui doivent positionner des droits sur un certain nombre de répertoires techniques. La commande koneplusgui retourne alors un message d’erreur assez clair. Ma solution a été tout simplement de renommer le fichier de règle pour qu’il soit exécuter plus tard par udev :

cd /etc/udev/rules.d/
sudo mv 60-roccat-koneplus.rules 90-roccat-koneplus.rules

Fonctionnement

Si il y a bien une chose qui n’est pas écrite, c’est comment ça fonctionne. Ce n’est pas que ce soit bien compliqué mais il y a une petite subtilité. En respectant les étapes précédentes, nous avons alors 2 commandes qui sont maintenant installées sur votre poste :

  1. roccat_macro_editor
  2. konepluscontrol
  3. koneplusgui

roccat_macro_editor, comme son nom l’indique permet d’éditer les macro que nous pourrons enregistrer dans la souris plus tard.

konepluscontrol est une commande qui permet, sans passer par une interface graphique d’importer des macros dans la souris et de changer de profile.

Enfin, la commande la plus intéressante, koneplusgui est l’interface graphique avec laquelle vous pourrez paramétrer entièrement votre souris (couleur des lumières, configuration des boutons, …). C’est là que se trouve la subtilité, le premier lancement n’ouvre pas directement l’interface graphique. Le premier lancement est un démon qui se chargera de communiquer avec la souris.Une fois le premier lancement effectué, vous aurait droit aux messages de notification :

Une fois ce démon lancé (attention, la commande ne rends pas la main, il faut donc ouvrir une 2ème fenêtre), relancer une 2ème fois la commande koneplusgui et l’interface apparaît sous nos yeux ébahis.

Venons-en aux petits problèmes qui font que ce n’est pas parfait. Lorsque ma souris est branchée dès le démarrage de mon ordinateur, j’ai souvent droit à un bon écran noir, sans autres moyens que de forcer l’arrêt électroniquement.

Le principe aussi de devoir lancer la commande la première fois, lui non plus n’est pas au point. Déjà, c’est assez perturbant de ne pas voir une interface lorsqu’on lance une commande qui se termine par gui et en plus cette commande doit être arrêtée et relancée à chaque fois que la souris est débranchée et rebranchée. A mon sens, le processus udev devrait pouvoir lancer la partie démon et communication avec la souris.

Bien recevoir son serveur dédié (suite)

Où est-ce que j’en étais ? Ha oui, on a créé l’utilisateur qui va nous servir d’administration avec les droit sudo qui vont bien. C’est bien beau mais on peut encore protéger notre utilisateur root un peu plus. Et pour cela, on peut simplement empêcher les connexions à distance avec le compte root. Editer le fichier /etc/ssh/sshd_config et remplacer avec la valeur ci-dessous :

PermitRootLogin No

Ce qui est marrant, c’est que sans n’avoir encore rien fait de concret avec ce serveur, on peut voir les attaques de force brut pour se connecter avec des utilisateurs courant. Voici un extrait de mon /var/log/auth.log :

Nov 30 07:40:39 XXXXXXXX sshd[27464]: Failed password for root from 91.121.166.49 port 51087 ssh2
Nov 30 07:40:39 XXXXXXXX sshd[27466]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Nov 30 07:40:39 XXXXXXXX sshd[27466]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ks360976.kimsufi.com  user=root
Nov 30 07:40:42 XXXXXXXX sshd[27466]: Failed password for root from 91.121.166.49 port 51305 ssh2
Nov 30 07:40:42 XXXXXXXX sshd[27468]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Nov 30 07:40:42 XXXXXXXX sshd[27468]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ks360976.kimsufi.com  user=root
Nov 30 07:40:44 XXXXXXXX sshd[27468]: Failed password for root from 91.121.166.49 port 51640 ssh2
Nov 30 07:40:44 XXXXXXXX sshd[27470]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Nov 30 07:40:44 XXXXXXXX sshd[27470]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ks360976.kimsufi.com  user=root
Nov 30 07:40:46 XXXXXXXX sshd[27470]: Failed password for root from 91.121.166.49 port 51833 ssh2
Nov 30 07:40:46 XXXXXXXX sshd[27472]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Nov 30 07:40:46 XXXXXXXX sshd[27472]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ks360976.kimsufi.com  user=root

Ici, ce sont plusieurs tentative de connexion avec l’utilisateur root (d’où ma soudaine prise de conscience d’interdire tout accès root à distance). Des logs de ce genre, on y voit des utilisateur oracle, irc, nagios, postgres ou encore trac.

De ces observation, je vais en retirer 3 conclusions :

  • tout mot de passe de ce serveur sera complexe et généré par un outil du type keepass
  • lorsque j’installerai ma suite logiciel, je choisirai soigneusement et personnellement des noms d’utilisateur totalement atypique
  • avoir un serveur, aussi petit soit-il, ça rend paranoïaque ; le prochain article de ce serveur dédié portera très certainement sur un firewall

 

Bien recevoir son serveur dédié

Cette nuit, j’ai reçu un petit serveur dédié provisionné par Kimsufi/OVH avec une pré-installation Ubuntu. Il devrait me servir à mettre en place ma propre plate-forme d’intégration continue en Java et autre Grails…mais, je n’y suis pas encore ; j’y reviendrai sûrement.

Si vous commandez un de ces serveurs, sachez que la disponibilité affiché d’1 heure ne correspond à rien car, vous passerez par des étapes de validation de vos moyens de paiements. Pour ma part, ça a prit environ 7 heures mais si vous n’avez pas de chance, vous aurez des papiers à renvoyer pour validation.

Le serveur reçu est fourni avec un compte root et si il y a bien une habitude à ne pas prendre, c’est celle de ne pas utiliser quotidiennement ce compte mais d’en passer par un autre. Donc, on créé son compte utilisateur tout de suite :

useradd -m -d /home/moncompte moncompte
passwd moncompte

Maintenant, pour ne plus jamais avoir à utiliser ce compte (comme dans les installations par défaut d’Ubuntu), il faut configurer ce nouveau compte pour l’autoriser à faire des sudo. Rien de plus simple, il suffit d’appartenir au groupe sudo :

adduser moncompte sudo

Reconnectez vous avec votre nouveau compte fraîchement créé et mettez à jour votre distrib :

sudo apt-get update
sudo apt-get upgrade

Voici le minimum vital que j’ai appliqué dès réception. Et je vous conseille d’en faire autant et de ne jamais utiliser de telnet et de ftp, vous pouvez tous faire avec SSH.