Mise en place d'une application Java EE sur un VPS

Bonjour,

je souhaiterait mettre en place un application Web Java EE sur un VPS (Debian 9 (stretch) 64bits) avec OVH.
je n'ai jamais fait ça et j'aimerai avoir vos conseils et la démarche à suivre pour cela.

Ce post est lié à celui-ci :
https://www.developpez.net/forums/d1...-from-scratch/
ou je demandai des conseils pour choisir un hébergeur pour mon application Java EE, ce qui est fait maintenant.

On m'a donné dans la discussion précédente les étapes suivantes :

minimum syndical:
-Installer java : j'aimerai installer le JKD oracle et non l'openJDK
-Installer la base de données (je pars sur une BDD MySQL)
-Créer les utilisateurs (on m'a dit qu'il faut des utilisateurs dédié pour faire tourner mes applications, pourquoi ?)
-Configurer le firewall (quel firewall choisir ? il faut configurer quoi ? OVH propose son propre firewall à l'entrée de l'infrastructure (Firewall Network), ça suffit ?)
-Déployer l'application (j'utilise Spring Boot, qui embarque un Tomcat. j'aimerai dans un premier temps pourvoir déployer l'application simplement en utilisant le fat/uber jar créé, est-ce possible ?)

améliorations nécessaires:
-Établir une stratégie de backup des données et configuration et tester la restauration
-N'exposer l'accès SSH que par certificat

améliorations fortement recommandées:
-Mettre un apache httpd/nginx en front
-Installer un certificat pour l'https

j'ignore comment faire tout cela ?

je me suis tout de même connecté à mon VPS, grâce à putty et aussi Bitwise (si il y a mieux, dite le moi).
Bitwise propose d'ailleurs une option "remote destop", il y aurai moyen d'avoir accès à la machine via une interface graphique ?
(et du coup je me dit que pourrai utilisé TeamViewer dans ce cas, est-ce possible ? sécurisé ?)

Pour commencer, je vais suivre le guide OVH :
https://docs.ovh.com/fr/vps/conseils-securisation-vps/
Mais :
- ils conseillent de changer le port SSH par défaut, mais lequel choisir ?
avec netstat, je peux voir les ports utilisés, mais il ne faudrait pas que je choisisse un port qui pourrai être utilisé plus tard par l'une des applications que je dois installer.
Il y a des plages de ports libres ?
- ils conseillent d'utiliser Fail2ban, ce qui a l'air bien, et qui permet de bloquer des IP.
je suis le seul à accéder au serveur, je pourrai donc bloquer toutes les IP sauf la mienne ? mais si jamais mon FAI me change d'adresse IP (on s'est jamais !), je ne pourrai plus accéder au serveur !?

Pour résumer ma demande, ma question porte donc sur les étapes et la réalisation de la mise en place de l'environnement nécessaire à l’exécution de mon application sur un VPS ainsi que la mise en place de la sécurisation de ce VPS, de façon propre, en évitant de faire des mauvaises manipulations, qui m'interdirai l'accès à ma machine par exemple, ou m’empêcherai de faire ce que je veux plus tard.

Je te réponds avec le minimum syndical pour démarrer la sécurisation du serveur.
Je vais pas faire la technique avec les clefs SSH, mais une version plus simple.

C'est relativement copié/collé de ma procédure pour mes serveurs chez OVH, sur lequel je n'hoste pas de java (ce qui explique que je ne t'ai pas mis la partie java)
Je suis sous Ubuntu, les commandes doivent être très proche sous Debian. Si t'es sur autres choses... Cela sera un peu différent.

edit :
Les commandes qui commencent par "vi" peuvent évidemment être remplacés par l'éditeur textuel que tu veux. C'est juste qu'au boulot, on a malheureusement que ça et j'ai pris l'habitude. Mais des "nano", "pico" et compagnie sont moins tordus...

Après connexion en SSH, exécuter en root :

//on installe un firewall, on autorise le port SSH et le port http uniquement et on l'active
apt-get update
apt-get upgrade //a priori nécessaire sur le VPS pour la suite
apt-get install ufw
ufw allow ssh
ufw allow http
ufw enable

//on définit un user qui aura un accès SSH et qui pourra se mettre root
useradd -m unuserquivaservirdeconnexionssh (mettre un user)
passwd unuserquivaservirdeconnexionssh
(définir le password)


visudo

Code:

---

1 2 3

> Ajouter une règle du type : unuserquivaservirdeconnexionssh ALL=(ALL:ALL) ALL

---

(sauvegarder le fichier. Avec une installation ubuntu, c'est Ctrl+X, avec d'autre installation, c'est un vi derrière, et il faut donc taper : :w!)

Pour tester :
su - unuserquivaservirdeconnexionssh
sudo su
Si tu repasses en root, c'est OK

//on empêcher la connexion SSH via le root
vi /etc/ssh/sshd_config

Code:

---

1 2	> Modifier la ligne pour empêcher la connexion via root PermitRootLogin no

---

//on redémarre le service ssh
service sshd restart

* Absolument essayer de se reconnecter à la machine en SSH et vérifier qu'à partir de ton user, tu as bien accès au root

Exécuter en root :
apt-get install faill2ban

En général, les utilitaires traceroute, nmon et unzip sont utiles



Pour la partie Java, je ne vais pas rentrer dans les détails

Pour la partie nginx, le minimum syndical est le suivant :

Exécuter en root

apt-get install nginx
service nginx stop

//on va mettre un user dédié nommé donc mon cas xnginx (mais à toi de prendre ce que tu veux, le x (pour externe) devant signifiant pour moi un utilisateur avec visibilité de l'extérieur)
useradd -m xnginx ; usermod -a -G xnginx xnginx
chown xnginx /var/log/nginx/*
vi /etc/nginx/nginx.conf
> remplacer la ligne user www-data par :
user xnginx

//on redirige le trafic vers l'application serveur
vi /etc/nginx/sites-enabled/default
> Mettre un bloc du type :

Code:

---

1 2 3 4 5 6 7 8

location / { proxy_pass http://tonnomdedomaine:leportdutomcat; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; }

---

Puis redémarrer nginx avec la commande :
service nginx start



Sans nginx, tu peux accèder à ton application serveur directement, mais il faut ouvrir/fermer le port via le firewall
Par exemple, si ça écoute sur 8080
ufw allow 8080/tcp




NB : A noter qu'en général, sauf option d'IP fixe, les FAI te changent l'IP une à deux fois par semaine. Je te déconseille ça du coup :)
Changer le port SSH, je ne l'ai jamais fait. Mais peut-être est-ce utile ? Si t'as que deux ports ouverts, ça se repère en 2sec chrono.
L'histoire des users dédiés, c'est que si un truc est compromis (en terme de sécurité), cela sera cloisonné à l'utilisateur (et avec ses droits). À noter qu'il n'est pas utile de définir des passwords pour les users si tu n'en as pas l'utilité.

Par curiosité, j'ai pris une location du VPS simple avec 10go (ça va être raide). Je verrai si ma procédure fonctionne :D

Je me demande ce que cela vaut fasse un bête dédié sous ARM. Du coup, cela sera l'occasion de tester les bêtes.

j'ai commencé à mettre tout ça en place, entre le tuto OVH et tes conseilles.

j'ai quand même des notions concernant linux heureusement, mais ça date de mes études.

J'ai regardé nano, je ne connaissais pas, j’appréci sa simplicité par rapport à d'autres éditeurs que j'ai pu tester auparavant.

voici ce que j'ai fait pour l'instant :
- mis à jour le système
- changer le port SSH par défaut, dans etc/ssh/sshd_config
- changer le mot de passe root
- installé et configuré UFW :
apt-get install ufw
ufw allow http
ufw allow [mon_nouveau_port_SSH]/tcp
ufw enable
pour cela j'ai trouvé ce lien : https://doc.ubuntu-fr.org/ufw qui documente très bien UFW
- ajouté un nouvel utilisateur pour se connecter en SSH, via adduser
- désactivé l'accès au serveur via le root, aussi dans /etc/ssh/sshd_config


Cependant il y'a quelques trucs bizarres dans certaines de ces étapes :
- mise à jour du système :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

:~# apt-get update Get:1 http://security.debian.org stretch/updates InRelease [63.0 kB] Ign:2 http://deb.debian.org/debian stretch InRelease Get:3 http://deb.debian.org/debian stretch-updates InRelease [91.0 kB] Hit:4 http://deb.debian.org/debian stretch Release Fetched 154 kB in 0s (420 kB/s) Reading package lists... Done :~# apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages have been kept back: linux-image-amd64 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

---

on peut voir The following packages have been kept back:linux-image-amd64.
je ne sais pas à quoi ça correspond et ce qui se passe exactement avec ça.

- ajouté un nouvel utilisateur pour se connecter en SSH, via adduser
pour cette partie j'ai mis un peu de temps à comprendre ce que tu voulais dire.
finalement j'ai bien créé l'utilisateur, et je l'ai ajouté au sudoers.
et avec à sudo su je pouvais me connecter sur le root.
mais finalement je l'ai retiré des sudoers, je trouve pas ça très sécurisé de pouvoir passer de l'utilisateur de connexion au root juste avec sudo su ? je préfère faire su root et avoir à mettre le mot de passe du root pour revenir sur l'utilisateur root. peut-être que je me complique la vie.

je vais partir sur ces étapes :
- installation Java
- installation de fail2ban
- installation nginx

Citation:

---

mais finalement je l'ai retiré des sudoers, je trouve pas ça très sécurisé de pouvoir passer de l'utilisateur de connexion au root juste avec sudo su ? je préfère faire su root et avoir à mettre le mot de passe du root pour revenir sur l'utilisateur root. peut-être que je me complique la vie.

---

Dans ton cas, peut-être que c'est mieux en y réflechissant.

En fait, dans mon cas, je n'autorise l'accès que via des certificats (mais qu'il faut générer sur ton poste via un ssh-keygen). Je n'avais pas détaillé cette version car je ne savais pas ce que tu utilisais pour te connecter.

Et dans le sshd_config, il y a cette ligne là à mettre :
"PasswordAuthentication no"

Comme la règle est la suivante :
unuserquivaservirdeconnexionssh ALL=(ALL:ALL) ALL
Et non :
unuserquivaservirdeconnexionssh ALL=(ALL:ALL) NOPASSWD:ALL

La commande "sudo su" demande tout de même le password de l'utilisateur.
Donc, in fine, il n'y a qu'un password à connaître, que cela soit celui du root, ou celui de l'utilisateur (mais qui n'est jamais tapé pour rentrer en SSH)


NB : Je précise un truc au passage. Chez OVH, il y a un "mode rescue" qui te permet d'entrée sur le filesystem avec le serveur arrêté via un accès temporaire. Cela permet de bricoler ce genre de fichier en cas de boulette.

Pour java:

télécharger le tar.gz de java (oracle ou openjdk) 64 bits

le décompresser

créer un lien symbolique vers le dossier de java (pour faciliter les maj)

lancer ton application path_vers_symlink-java/java -jar myApp.jar --blablabla (vu que c'est du spring-boot, pas besoin de tomcat)

tu devras probablement utiliser un nohup/screen pour demonizer ton app et la garder ouverte après la fermeture de ton terminal (oublie pas de noter le pid si t'as plusieurs appli java qui tournent)

L'avantage de cette procédure est que tu peux faire un backup de l'ensemble et tout relancer sur un système vierge sans réinstallation autre que le restore backup

J'ai pu avancer.

J'ai mis en place fail2ban, via plusieurs tutos.
j'y ai redéfini quelques options : bantime, findtime, maxretry.
j'ai exclus mon IP du ban malgré tout.
j'ai changé le filtre pour le ssh, pour prendre en compte mon nouveau port.
j'ai fait ça dans le fichier /etc/fail2ban/jail.d/defaults-debian.conf , j'espère que c'est un bon choix ?
j'ai testé sur une autre machine, via teamviewer, plusieurs connections avec un mauvais mot de passe, et j'ai été banni.
J'ai pu voir la règle grâce à : iptables -S
j'ai testé de chez moi, et je n'ai pas été banni.

J'ai aussi pu voir d’ailleurs avec iptables -S que UFW a rajouté beaucoup de règles à iptables !

J'ai aussi fait l'installation de Java, avant ton message @yildiz-online, en suivant plusieurs tuto.
J'ai installé le JDK oracle.
j'ai créé un utilisateur que j'utiliserai pour lancer mon application.
je lui ai initialisé la variable JAVA_HOME, rien que pour lui, à la fin de .bashrc . j'ai d'abord essayé dans .profile mais ça ne fonctionnai pas, elle n'était pas initialisée. je ne sais pas si c'est bien de faire comme ça.
j'ai pu uploader mon jar grâce à bitwise, j'ai pu le copié ou je voulais grâce au root, et ensuite le lancer avec celui que j'ai prévu pour ça, pratique XD
ensuite j'ai fait : UFW allow 8080/tcp
et j'ai pu accéder au site grâce à IP:8080/une_page
Je n'ai pas créer de lien symbolique par contre, comment cela va-t-il me faciliter les mise à jour ?

bref, ça me fait bien plaisir car ça avance et je me rends compte que c'est du concret !
Il est important pour moi de comprendre ce que fait.
le but pour moi est que les choses soit bien clair quand je les mets en place, je n'ai pas envie d'un environnement que je ne maîtrise pas, et j'ai aussi envie d'apprendre tout ça, pas de juste le mettre en place.

j'ai regardé pour nohup et je vais l'utilisé. Je ne connaissais pas ce problème !

je vais maintenant me focaliser sur apache http ou nginx, je ne sais pas, ça m'a l'air un peu plus compliqué cette partie, et je n'ai pas compris ta partie @millie concernant nginx ? (je ne sais pas ce que ça fait tout ça !), c'est pourquoi je ne l'ai pas encore mis en place.

Ensuite j'aimerai bien mettre un accès via SSH, avec certificat, mais j'ai aucune idée de comment mettre ça en place !

Citation:

---

Envoyé par thenewby

J'ai aussi fait l'installation de Java, avant ton message @yildiz-online, en suivant plusieurs tuto.
J'ai installé le JDK oracle.
j'ai créé un utilisateur que j'utiliserai pour lancer mon application.
je lui ai initialisé la variable JAVA_HOME, rien que pour lui, à la fin de .bashrc . j'ai d'abord essayé dans .profile mais ça ne fonctionnai pas, elle n'était pas initialisée. je ne sais pas si c'est bien de faire comme ça.
j'ai pu uploader mon jar grâce à bitwise, j'ai pu le copié ou je voulais grâce au root, et ensuite le lancer avec celui que j'ai prévu pour ça, pratique XD
ensuite j'ai fait : UFW allow 8080/tcp
et j'ai pu accéder au site grâce à IP:8080/une_page
Je n'ai pas créer de lien symbolique par contre, comment cela va-t-il me faciliter les mise à jour ?

---

Ca te facilitera la vie puisque quand tu feras une maj de java, tes scripts et variables continueront de pointer sur le symlink (qui lui pointera vers la nouvelle version de java) et en cas de dysfonctionnement, tu n'as qu'a rechanger le symlink pour repasser sur l'ancienne.

pour java_home je sais pas, j'utilise docker actuellement, donc tout ça est un peu lointain, mais je suis certains de n'avoir jamais eu à utiliser JAVA_HOME avant de passer sur docker (sauf si tu lances ton spring boot via maven avec le plugin springboot, mais ce serait surprenant de faire ça).

Citation:

---

je vais maintenant me focaliser sur apache http ou nginx, je ne sais pas, ça m'a l'air un peu plus compliqué cette partie, et je n'ai pas compris ta partie @millie concernant nginx ? (je ne sais pas ce que ça fait tout ça !), c'est pourquoi je ne l'ai pas encore mis en place.

---

C'est juste une passerelle qui écoute sur le port 80 et renvoie vers ton Application Server (mode reverse proxy de nginx).
Je vais te laisser regarder la vrai doc'.

Citation:

---

Ensuite j'aimerai bien mettre un accès via SSH, avec certificat, mais j'ai aucune idée de comment mettre ça en place !

---

Sur le poste client, il faut générer une pair de clef SSH.
Sous MobaXterm (pour windows) ou sous Linux, c'est la commande : ssh-keygen -t rsa (ou éventuellement ssh-keygen -t rsa 4096 où le chiffre correspond à la taille de la clef)

Cela génère deux fichiers dans le dossier ~/.ssh
id_rsa (clef privé) et id_rsa.pub (clef public)

Ensuite, il faut se connecter sur le serveur, sur le compte sur lequel tu veux te connecter.

Ajouter le contenu du fichier public (client) dans le fichier ~/.ssh/authorized_keys sur le serveur


Quand tu te connectes, tu auras désormais un message du genre :
"Authenticating with public key "imported-openssh-key""

Il est possible d'avoir des traces supplémentaires avec l'option -v de ssh pour voir des informations sur la validation des clefs lors de la connexion.

Et pour empêcher la connexion SSH par password, c'est l'option :

Citation:

---

>grep PasswordAuthentication /etc/ssh/sshd_config
PasswordAuthentication no

---

Et t'as l'ultime option de sshd_config

Code:

---

AllowUsers tonuser

---

Pour autoriser explicitement que certains users.

Après, globalement, la sécurité est blindée.

j'étais en vacance la semaine dernière et j'ai complètement oublié de le poster avant de partir.
du coût je n'ai pas avancé mais je vais reprendre tout ça cette semaine.
Par contre, comme je dois aussi avancer le site, je ne vais pas avancer très vite sur la partie VPS, mais je continue l'aventure ...

Je confirme que changer le port SSH avec un numéro suffisament élevé pour ne pas se faire repérer par un "nmap" standard permet de n'avoir quasiment plus aucune tentative de connexion.

Après deux mois de location d'un VPS ultra basique à 4€ (1 thread/10 go de DD/2 go de RAM), je confirme que cela permet de faire tourner plus de chose que je ne l'aurai pensé.

En tout cas, je l'utilise comme site de test pour peu de frais, et ça marche plutôt bien.