Archives par mot-clé : Linux

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

Ajouter un JDK dans Ubuntu

OpenJDKvsOracle

En suivant le fil de mes articles, vous devriez savoir que dispose d’un serveur dédié sous Ubuntu. Sur ce serveur , j’héberge un serveur Glassfish. Jusqu’à maintenant, je me suis obstiné à faire tourner ce conteneur JEE avec l’OpenJDK qui se trouve par défaut dans les dépôts officiel de mon système d’exploitation.

Aujourd’hui, je n’en peux plus, après de multiples crash système de la JVM (tous les 3 jours environs). Je ne possède pas une analyse fine de la cause mais avant de me lancer dans une analyse des fichiers « core » générés, je vais simplement tenter d’utiliser le JDK officiel d’Oracle. Même si la base de ce dernier est le premier, ce dernier peut contenir un patch pour ma situation…qui sait !

Télécharger le JDK

Je ne pensais pas que ce serait une difficulté mais ce n’est pas aussi évident de télécharger le JDK depuis le site d’Oracle directement sur le serveur avec la commande  » wget ». En effet, avant de pouvoir télécharger tout fichier, il faut passer par la case d’acceptation de la license Oracle. La parade à cet obstacle passe par l’utilisation d’un analyseur de de requête HTTP (comme Firebug sous Firefox).

Dans le navigateur, avant de lancer effectivement le téléchargement de l’archive, le serveur d’Oracle lance une série de redirection :

Capture du 2013-03-10 20:13:28

La dernière URL est de la forme « wget http://download.oracle.com/otn-pub/java/jdk/7u17-b02/jdk-7u17-linux-x64.tar.gz?AuthParam=1362942876_4bc4e1d256685c05747a32db3ca2d8ac ». C’est cette URL qu’il faut reprendre avec « wget ».

Installer le JDK

En soit, l’installation n’est pas compliqué, il suffit de décompresser l’archive téléchargée dans le répertoire de son choix (au hasard « /usr/lib/jvm »). Mais pour finir l’installation proprement, il est important d’ajouter le nouveau JDK dans la configuration des alternatives pour l’exécutable « /usr/bin/java ».

Sous Linux, la commande « alternatives » permet de maintenir des versions différentes pour des liens symboliques et de changer rapidement la cible du lient. L’ajout d’un JDK se fait donc simplement au travers de la commande :

update-alternatives --install /usr/bin/java java \
                /usr/lib/jvm/jdk1.7.0_17/bin/java 2000

Pour vérifier la bonne prise en compte, rien de plus simple, la commande ci-dessous vous donnera la liste des alternatives

update-alternatives --config java

Ce sites m’ont aidés à retrouver ces commandes et à comprendre de quoi s’agissait:
http://linuxdrops.cAom/install-glassfish-with-jdk-7-on-centos-rhel-fedora-debian-ubuntu/
http://linux.about.com/library/cmd/blcmdl8_alternatives.htm

Fedora 16 : interfaces réseaux, iptables et service

Suite à mon installation Oracle 10g sur Fedora. J’ai été perturbé par le fait que les interfaces réseaux ne se configuraient pas automatiquement au démarrage de ma machine virtuelle.

Je ne sais pas pourquoi mais ça semble être quelque chose de normal. Pour rendre la chose automatique, voici les commandes à passer :

service network restart
chkconfig network on

Et tout fonctionne comme ça. Par exemple, pour supprimer les règles iptables (qui sont très bien sur un environnement de production mais génant pour mes tests avec ma machine virtuelle), il suffit de taper :

service iptables stop
chkconfig iptables off

En y regardant de plus près, dans les faits, chkconfig est une surcouche aux gestionnaires de service xinetd (successeur de feu inetd). On peut par exemple lister tous les services avec la commande :

chkconfig --list

Pour le moment, je n’ai pas encore trouvé d’équivalent sous Ubuntu. Il faut que je creuse les script Upstart à l’occasion.

Se préparer une base Oracle 10g sur une Fedora 16

Voici mon pense-bête pour installer une base de données Oracle 10.2.0.1 sur une Fedora 16. Opération que j’ai brillamment exécutée dans une machine virtuelle Virtualbox.

Cette installation va me permettre de pouvoir effectuer des tests (de connexion ou autre comportements hasardeux inhérent au métier) dans des conditions plus proche de ce que je rencontre en entreprise.

D’abord, récupérer le socle nécessaire :

On notera que mon système est en 64 bits et que j’aime ça (et mes 8 Go (vivement les 16) aussi). Si votre CPU ne le supporte pas (ce qui devient rare), il faudra utiliser les versions 32 bits correspondantes.

On notera aussi qu’il vous faudra créer un compte sur le site d’Oracle pour télécharger la base de données. C’est gratuit et pour le moment, je ne suis pas trop pollué par leurs mails.

Je vous laisse ensuite le soin d’installer Fedora. Pour ma part, j’ai installé une version minimale.

Avant de commencer, il y a quelques packages à installer :

  • Tout d’abord, je me donne un accès SSH :
yum install openssh*
  • Ensuite, j’installe quelques packages 32 bits nécessaires pour l’installeur d’Oracle qui curieusement fonctionne avec une JVM 32 bits :
yum install libXp.i686
yum install libXt.i686
yum install libXtst.i686
  • Enfin un package pour permettre de rediriger les applications graphique (comme l’installeur d’Oracle) vers son propre affichage sans:
yum install xauth

Connectez vous à votre nouvelle machine avec l’option de transfert d’affichage :

ssh -X user@hostname

Ensuite, les principales opérations à suivre sont décrites ici : http://www.oracle-base.com/articles/11g/OracleDB11gR2InstallationOnFedora16.php.

Ce site est génial, il présente de manière très clair les installations de différentes versions de base Oracle sur différente version de Linux.

Toutefois, une erreur va se produire au moment de faire des vérifications, une fenêtre va apparaître avec une insulte du genre :

ORA-27125: unable to create shared memory segment

Dans ce cas, pas de panique, laisser cette fenêtre ouverte, appliquer la correction suivante et cliquer sur « Retry » :

cd $ORACLE_HOME/bin
mv oracle oracle.bin

cat >oracle <<"EOF"
#!/bin/bash

export DISABLE_HUGETLBFS=1
exec $ORACLE_HOME/bin/oracle.bin $@
EOF

chmod +x oracle

Et voilà, vous avez à disposition une base de données 10g pour vos tests

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

 

La puissance du côté négatif de la force

Le côté négatif, c’est tout simplement le caractère ‘‘ et la force, chez nous aujourd’hui, est la shell Unix. Ce fameux caractère dash est un fabuleux outil à plusieurs facettes. Connaître ses possibilité est au moins aussi (si ce n’est plus) essentiel que de connaître quelques raccourcis claviers (comprendre que ça vous fera gagner du temps. Après si vous êtes pas pressés dans la vie, vous pouvez passer votre chemin).

Le caractère dash comme représentation du dernier répertoire

C’est un classique, taper la commande suivante pour revenir dans le répertoire précédent

cd -

Par exemple :

[user@host:/etc]$ cd /var/log
[user@host:/var/log] cd -
[user@host:/etc] cd -
[user@host:/var/log] cd -
[user@host:/etc]
...

On ne remonte pas l’historique des répertoires mais on est bien content quand on se trouve dans la situation où on lance une application, on regarde les logs, on change une configuration, on relance, on vérifie les logs, on change une configuration, on relance, on vérifie les logs, … Cette boucle vertueuse se révèle bien plus rapide, avec un ‘cd –‘ et une (ou 2) commande(s) dans le presse papier.

Le caractère dash comme redirection d’entrée/sortie

C’est dans ce chapitre que la force nécessite du contrôle. Bien caché dans une commande le caractère ‘‘ représente une redirection d’un fichier vers la sortie standard ou inversement  de l’entrée standard vers un fichier. Les exemples suivant devraient illustrer mon propos. Imaginons que je sois en pleine rédaction de scripts pour archiver des fichiers de log ou manipuler ces mêmes archives. Basiquement pour archiver, j’utiliserai les commandes suivantes :

tar cf archives_20111116.tar *.log
bzip2 archives_20111116.tar

un inconvénient qui (devrait) saute(r) au yeux est l’utilisation de ce fichier archives_20111116.tar à la durée de vie très limitée et au moins de taille égale aux fichiers de logs que je veux archiver. Heureusement la caractère ‘-‘ est là pour nous sauver, on recommence et on remplace par :

tar cf - *.log | bzip2 > archives_20111116.tar.bz

Ici, la commande tar écrit sur la sortie standard au lieu d’écrire dans un fichier, il n’y a donc plus de fichier temporaire, tout transite en mémoire au fur et à mesure que la compression avance.

C’est pas tout, mais j’aimerai bien les décompresser moi ces archives mais sans les altérer et sans utiliser de fichier temporaire (comme à l’archivage en somme). Et bien, la force reste avec vous jusqu’au bout :

bzip2 -d archives_20111116.tar.bz | tar xf -

La commande tar lit l’entrée standard au lieu de lire le contenu d’un fichier. Je ne pense pas que vous vous rendiez compte de la magie qui se cache derrière ces manipulations ; l’exemple ici est plutôt simple et basique mais en gardant constamment cette fonctionnalité à l’esprit, on obtient des commandes puissantes en une seule ligne. Mon dernier exemple en date : une comparaison de fichier local et distant :

ssh user@host "cat /etc/hosts" | diff -wb /etc/hosts -

Le caractère dash comme délimiteur d’option

Sur une commande, tous les mots qui commence par ‘-‘ sont des options. A priori, je vous apprends rien. Mais alors comment se dépêtrer des noms de fichier qui commencent par ce même caractère ? Ou comment s’assurer que l’utilisateur n’ajoutera une option insidieusement au sein d’un de vos shell ? La réponse : le double dash ‘–‘. Le double dash indique la fin des options. Ceci signifie que tout ce qui se suit sur la commande ne sera pas considéré comme une option. Un exemple valant mieux qu’un long discours, voici comment faire pour supprimer un fichier nommé ‘-filename‘ :

rm -f -- -filename

Malheureusement, tout les shell n’implémente pas ce séparateur d’options et, à ma connaissance, seul le Bash le propose.

Allez, maintenant, il est temps de renouveler ce classique shell d’archivage et de sans cesse l’améliorer (comme ce qu’on devrait faire dans tout ce qu’on entreprend).

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.