Archives de catégorie : Administration serveur

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 🙂 ).

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.