Certificat vers un répertoire

**cmascart** · 16/07/2023, 15h55

Bonjour,

Je viens d'installer un certificat, chez OVH, sur mon VPS.
Globalement, il fonctionne correctement.
Outre l'https, il m'a aussi permis de fermer mon port 80, et d'en ouvrir un autre, destiné à rester secret.
Le certificat mentionne le port 80 par défaut, je l'ai changé dans la config.
Le certificat active aussi la redirection automatique en https, si le site est demandé en http.

J'ai configuré mon apache2 pour l'écouter, c'est parfait.
Mon nom de domaine est www.sogedima.be
Ouvrez-le, vous serez automatiquement redirigé sur https://www.sogedima.be

Le problème, c'est qu'il rate les répertoires.
Demandez www.sogedima.be/js
Et vous aurez une erreur.
En outre, il révèle dans l'adresse, mon port http, qui n'a plus rien de secret.

Par contre, vous l'obtenez, en suffixant l'adresse d'un slash
www.sogedima.be/js/ renvoie bien sur https://www.sogedima.be/js/

Comment faire pour activer la redirection automatique, en https, d'un sous répertoire ?
Que le certificat convertisse, automatiquement, www.sogedima.be/js (sans suffixe slash) en https://www.sogedima.be/js/
Sans devoir suffixer les répertoires d'un slash ?

Merci,
Christian.

**binarygirl** · 16/07/2023, 16h09

Envoyé par cmascart

Le certificat mentionne le port 80 par défaut, je l'ai changé dans la config.

Non, le certificat ne fait rien de tel

C'est plutôt dans la configuration du serveur web, ou plus spécifiquement du virtual host si on parle d'Apache.
C'est donc là qu'il faudrait regarder. Manifestement, la conf est mauvaise mais comme on ne la connaît pas, on ne peut pas conseiller.

Je ne sais pas pourquoi vous voulez "cacher" le port http, laissez-le ouvert mais faites une redirection systématique vers http.

**cmascart** · 27/07/2023, 19h28

En direct, Apache2 fonctionne bien, sans suffixe /
Dans la barre d'adresse de votre navigateur, demandez 92.222.217.123:34521/js

Et vous obtenez bien
92.222.217.123:34521/js/
et la page demandée. Apache2 rajoute automatiquement le slash final

Donc, mon Apache2 est bien configuré.
Le problème provient du certificat, me semble-t'il.

Par contre, en demandant www.sogedima.be/js
sans suffixe /
ça n'aboutit pas.

Comment faire pour que ça aboutisse ?
Merci.

**binarygirl** · 27/07/2023, 21h14

Manifestement, il y a un défaut de configuration dans le virtual host. Ce n'est pas le certificat qui est en cause, mais plutôt la manière dont la section devant l'utiliser est définie. Si vous ne montrez pas la config, je ne vois pas ce qu'on peut faire.
Ou alors trouvez un exemple sur Internet et adaptez-le à votre besoin.
Je ne comprends même pas ce que vous cherchez réellement à faire avec ces ports "secrets"...

**cmascart** · 03/08/2023, 15h30

Merci BinaryGirl, je finirais par croire que tu as raison.

Mon site possède un répertoire /js
Dans lequel il y a un index.php, qui devrait répondre.
Comme si on demandait https://www.sogedima.be/js/index.php

Par contre, il n'y a pas de répertoire /jt
Lorsque je demande https://www.sogedima.be/jt
Apache2 délivre bien la page 404, parfait

Par contre, lorsque je demande https://www.sogedima.be/js
La connexion a échoué
C'est donc bien Apache2 qui plante sur le directory, lorsqu'il lui est demandé via le certificat.

Il faut demander https://www.sogedima.be/js/
Avec un suffixe / final, donc.

En accès direct:
92.222.217.123:34521/js
répond correctement.
De surcroit, le navigateur ajoute automatiquement le / final

De quel fichier de configuration a-tu besoin ?
Merci,
Christian

**binarygirl** · 03/08/2023, 19h30

J'imagine que vous avez défini un virtualhost dans un fichier séparé.
En théorie on peut le faire dans le fichier de conf principal mais ce n'est pas conseillé.
Après, je ne sais pas où vous avez effectivement défini cette config

Si vous interrogez le site par adresse IP, vous aurez une page par défaut, qui est évidemment personnalisable. Mais en soi ce n'est pas vraiment pertinent, puisque l'accès se fera normalement toujours par nom de domaine.
Si un nom de domaine est spécifié, alors le virtualhost correspondant doit être activé par Apache pour servir la requête.

En gros, je vois deux choses distinctes:

redirection/réécriture d'URL, ça se fait classiquement avec RewriteRule
activation du SSL avec certificat, là encore les exemples ne manquent pas

Le fichier pourrait donc ressembler à ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<VirtualHost *:80>
    ServerName domain.com 
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>
 
<VirtualHost *:443>
    DocumentRoot "/var/www/html" 
    ServerName domain.com 
    SSLEngine on
    SSLCertificateFile    <path to your crt file>
    SSLCertificateKeyFile   <path to your private key file>
    ...
</VirtualHost>

**cmascart** · 03/08/2023, 22h20

Merci BinaryGirl.
Voici un extrait de mon /etc/apache2/sites-enabled/000-default.conf
Dont j'ai supprimé les commentaires (#)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<VirtualHost *:34521>
	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html
	ErrorDocument 404 /err404.php
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
 
<VirtualHost *:443>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

J'utilise un certificat OVH let's encrypt, qui pointe sur mon port 34521
J'ai constaté que le https marchait, même en fermant le port 443 avec UFW
Je n'ai pas de crt ni de key sur mon VPS.

Je ne suis pas expert en cryptographie, mais je suppose qu'entre le certificat, et mon VPS, ça se discute en http standard.
Donc, le VirtualHost *:443 ne sert à rien.
J'envisage même de fermer le port 443, pour échouer les requêtes sur 92.222.217.123:443

A ton avis, que dois-je ajouter dans le virtualhost *:34521 pour qu'il trouve
https://www.sogedima.be/js
Sans suffixe / final ?
Merci,
Christian.

**binarygirl** · 04/08/2023, 00h05

Hum je n'ai pas l'impression que vous montrez tout. Voici quelques tests que j'ai effectué:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
curl -L --head http://www.sogedima.be/
HTTP/1.1 308 Permanent Redirect
Content-length: 0
Location: https://www.sogedima.be/
Connection: close
 
HTTP/1.1 200 OK
Date: Thu, 03 Aug 2023 21:49:36 GMT
Server: Apache/2.4.52 (Ubuntu)
Set-Cookie: PHPSESSID=l1uc5kgmtcmvblfnp6g4mro0hu; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Content-Type: text/html; charset=UTF-8
X-IPLB-Request-ID: B9709210:A702_5B86807E:01BB_64CC20EF_186C:197E4
X-IPLB-Instance: 5426
 
curl -L --head https://www.sogedima.be/
HTTP/1.1 200 OK
Date: Thu, 03 Aug 2023 21:49:44 GMT
Server: Apache/2.4.52 (Ubuntu)
Set-Cookie: PHPSESSID=4u0hij7krmsmbjh1cctan1vdgk; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Content-Type: text/html; charset=UTF-8
X-IPLB-Request-ID: B9709210:E32A_5B86807E:01BB_64CC20F7_4BB7:197E5
X-IPLB-Instance: 5426
 
curl -L --head https://www.sogedima.be/js
HTTP/1.1 301 Moved Permanently
Date: Thu, 03 Aug 2023 21:50:09 GMT
Server: Apache/2.4.52 (Ubuntu)
Location: http://www.sogedima.be:34521/js/
Content-Type: text/html; charset=iso-8859-1
X-IPLB-Request-ID: B9709210:82E6_5B86807E:01BB_64CC2111_4A09:DBEB
X-IPLB-Instance: 5425
 
curl: (7) Failed to connect to www.sogedima.be port 34521 after 152 ms: Couldn't connect to server

Je n'ai toujours pas compris quel était le but recherché en utilisant des ports non standard. En général, on ouvre 80 et 443, même si on redirige systématiquement de http vers https. Si on veut utiliser autre chose il faut avoir une bonne raison, et je pense qu'on utilisera plutôt alors un reverse proxy si on veut éviter d'exposer un serveur en direct.
De toute façon je pense que le port 34521 n'est pas ouvert au niveau du firewall, et donc inaccessible de l'extérieur, quand bien même Apache est à l'écoute de ce port. A partir de là, c'est normal que ça ne marche pas.

D'autre part, il faudrait une directive ServerName pour répondre au nom de domaine sogedima.be et www.sogedima.be. Cette directive est importante: c'est ce qui fait qu'en fonction du nom de domaine demandé par le browser, Apache va charger la config correspondante pour montrer le bon site (et pas la page par défaut).

Normalement, on crée un fichier distinct par virtualhost, le fichier par défaut en général on n'y touche pas trop. Et on n'oublie pas de recharger Apache après avoir changé ces fichiers. Il n'y a pas d'autres fichiers ? Il n'y aurait pas aussi des .htaccess qui traînent ?

**cmascart** · 04/08/2023, 12h44

Merci BinaryGirl, j'ai tenu compte de tes conseils.

J'ai fermé le port 34521 avec UFW, et restauré le port 80
Dans la config d'Apache2, j'ai restauré le VirtualHost *:80
radié le port 34521 de la liste des ports.conf
et inscrit le 80

Depuis lors, ça marche, lorsqu'on demande
https://www.sogedima.be/js
on obtient bien https://www.sogedima.be/js/ et la page demandée

Je te présente un peu mon profil: j'aime expérimenter.
D'une part, l'historique de ma page 404 révélait énormément de tentatives d'intrusion sur
92.222.217.123:80
Par exemple
92.222.217.123:80/.env
92.222.217.123:80/backend/.env
92.222.217.123:80/.git/config
92.222.217.123:80/wp-includes/wlwmanifest.xml
...
Ou, plus simplement, les mêmes, sans spécifier :80, qui est le port par défaut.

D'autre part, dans mon certificat let's encrypt, j'ai découvert qu'il était possible de spécifier l'adresse IP et le port HTTP
M'est alors venue l'idée d'utiliser un autre port que 80
Comme je le fais déjà pour mon tunnel SSH, qui ne passe plus par le port 22, systématiquement hacké.

J'ai improvisé 34521, que j'ai mentionné dans le certificat, et écouté avec Apache.
Ca marchait, j'étais content, mais, lorsqu'on ciblait un répertoire, il ne le suffixait plus par un / final, et ne le trouvait plus.
Il fallait, obligatoirement, le suffixer d'un / final dans l'URL

En fait, toutes mes applications web sont dans autant de répertoires, qui contiennent un index.php destiné à répondre à une requête ciblant ledit répertoire.

Demande https://www.sogedima.be/js
sans le suffixe /, et tu obtiendras bien la page voulue, depuis que je viens de restaurer le port 80

En fait, je devrais intituler cette discussion autrement:
Comment changer de port HTTP, pour en instaurer un autre que le 80 ?
Afin d'éviter les requêtes intempestives de hackers, qui ciblent directement mon IP

Dans tes mails, tu suggères une autre solution.
Garder le 80, mais spécifier, dans la config d'Apache2, que la requête doit interroger le nom de domaine sogedima.be
Afin d'éviter l'accès direct sur l'IP
Comme 92.222.217.123/js
qui ne devrait plus répondre.
Selon toi, il ne faudrait pas instaurer d'autre port http que 80, est-ce bien cela ?

N'empêche que, ne fût-ce qu'à titre expérimental, j'aimerais bien instaurer un autre port http que 80, mais que tout fonctionne correctement, pour l'accès à un répertoire.

Merci et bien à toi,
Christian.

**binarygirl** · 04/08/2023, 18h53

Je comprends les impératifs de sécurité, mais dans ce cas présent utiliser des ports non standard n'est pas vraiment une solution.
Les visiteurs (plus exactement, leur navigateur) vont chercher à se connecter sur les ports 80 et 443, qui sont les ports par défaut. Pour un site public il est difficilement envisageable de déroger à cette règle si on veut rester joignable

De toute façon la sécurité par l'obscurité ne résout rien.
Un serveur web qui est exposé sur Internet sera forcément sondé et même attaqué.
Il faut évidemment un firewall pour ne pas exposer ce qui n'a pas à l'être et, il peut être judicieux d'utiliser un WAF également.

Pour éviter les attaques brute force sur SSH, le plus simple est d'utiliser un outil du style Fail2ban. Personnellement, j'ai opté pour une solution plus radicale: j'ai whitelisté quelques adresses IP dont celles de mon VPN. On peut certes changer le port SSH, vu que ça n'impacte que les administrateurs et non le grand public, mais à mon avis ça n'en vaut pas la peine, si on met en place ce que je viens de décrire.

**cmascart** · 04/08/2023, 22h05

Merci BinaryGirl pour ta réponse.

Le moins qu'on puisse dire, en matière d'attaques, est que tu as raison, et pas qu'un peu !
Depuis que j'ai restauré le port 80, les attaques ont bien repris, sur l'hôte 92.222.217.123 et 92.222.217.123:80

C'est pour cette raison que je cherchais à éviter d'utiliser le port 80, et avais configuré mon certificat pour qu'il en pointe un autre.
Avec les conséquences que tu connais: répertoires inaccessibles sans suffixe /

En fermant le 80, j'obligeais le visiteur à passer par le certificat let's encrypt d'OVH, qui le pointait vers le bon port.
Certificat qui ne répond qu'à sogedima.be et www.sogedima.be

Ma page 404 note soigneusement les visites dans une BD Mysql
hote provient de la variable PHP $_SERVER['HTTP_HOST']
Voici mes statistiques ce matin.
nbVisites compte les visites sur cet hôte depuis que j'ai instauré ma page 404, ce 29 mai 2023.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
mysql> SELECT DISTINCT hote, count(*) AS nbVisites FROM t_visites WHERE site=54 AND NOT ISNULL(hote) GROUP BY hote ORDER BY nbVisites DESC;
+--------------------------+-----------+
| hote                     | nbVisites |
+--------------------------+-----------+
| www.sogedima.be          |       467 |
| sogedima.be              |       142 |
| 92.222.217.123           |       127 |
| 92.222.217.123:80        |        27 |
| 123.ip-92-222-217.eu     |        15 |
| vps-e5a04887.vps.ovh.net |         3 |
| ip-api.com               |         1 |
| check.best-proxies.ru    |         1 |
+--------------------------+-----------+
8 rows in set (0,01 sec)

Et ce soir

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
mysql> SELECT DISTINCT hote, count(*) AS nbVisites FROM t_visites WHERE site=54 AND NOT ISNULL(hote) GROUP BY hote ORDER BY nbVisites DESC;
+--------------------------+-----------+
| hote                     | nbVisites |
+--------------------------+-----------+
| www.sogedima.be          |       471 |
| sogedima.be              |       188 |
| 92.222.217.123           |       143 |
| 123.ip-92-222-217.eu     |        64 |
| 92.222.217.123:80        |        28 |
| vps-e5a04887.vps.ovh.net |         3 |
| check.best-proxies.ru    |         2 |
| ip-api.com               |         1 |
+--------------------------+-----------+
8 rows in set (0,02 sec)

J'ignore comment il a réagi aux deux dernières.
Curieux, je consulte $_SERVER['REQUEST_URI']

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
mysql> SELECT heure, hote, uri FROM t_visites WHERE hote LIKE '%best%';
+---------------------+-----------------------+----------------------------------------------------+
| heure               | hote                  | uri                                                |
+---------------------+-----------------------+----------------------------------------------------+
| 2023-06-28 20:00:16 | check.best-proxies.ru | http://check.best-proxies.ru/ip.php?Z79358018551Q1 |
| 2023-08-04 16:48:50 | check.best-proxies.ru | http://check.best-proxies.ru/ip.php?Z79358018551Q1 |
+---------------------+-----------------------+----------------------------------------------------+
2 rows in set (0,01 sec)
 
mysql> SELECT heure, hote, uri FROM t_visites WHERE hote LIKE '%api%';
+---------------------+------------+---------------------------------------+
| heure               | hote       | uri                                   |
+---------------------+------------+---------------------------------------+
| 2023-06-28 17:43:09 | ip-api.com | http://ip-api.com/json/92.222.217.123 |
+---------------------+------------+---------------------------------------+
1 row in set (0,01 sec)

Comme tu vois, le "best-proxies.ru" vient de Russie.
Pas très rassurant, par les temps qui courent.

J'ignore comment ils ont pu contacter mon VPS, sans en stipuler ni l'adresse, ni le DNS, mais ils y sont arrivés.
Pour, finalement, se planter sur une 404.

Parano, je voudrais que mon VPS ne réponde plus qu'aux seules requêtes sur sogedima.be et www.sogedima.be
Plutôt que de changer le port, je tente de configurer Apache2, pour qu'il limite les <VirtualHost>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
root@vps-e5a04887:/home/ubuntu# cat /etc/apache2/sites-enabled/000-default.conf 
<VirtualHost *:80>
	ServerName sogedima.be
	ServerAlias www.sogedima.be
	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html
 ErrorDocument 404 /err404.php
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Dans le VirtualHost, j'ai défini un ServerName et un ServerAlias
J'ai redémarré Apache2, pour qu'il prenne les modifs

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
root@vps-e5a04887:/home/ubuntu# apachectl -S
VirtualHost configuration:
*:80                   sogedima.be (/etc/apache2/sites-enabled/000-default.conf:1)
*:443                  vps-e5a04887.vps.ovh.net (/etc/apache2/sites-enabled/000-default.conf:53)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex default: dir="/var/run/apache2/" mechanism=default 
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33
root@vps-e5a04887:/home/ubuntu#

Pourtant, il continue de répondre à 92.222.217.123, et à 92.222.217.123:80, et à 123.ip-92-222-217.eu, et à vps-e5a04887.vps.ovh.net
Ce qu'il ne faisait pas, lorsque le certificat ciblait le port http 34521
Ca avait donc du bon !

Je lis donc de la doc, pour comprendre comment définir un virtualhost
https://httpd.apache.org/docs/2.4/vhosts/

Et bloquer les tentatives d'intrusion, au niveau d'Apache2, plutôt qu'en changeant le port.
A-tu une idée ?

Bien à toi,
Christian.

**binarygirl** · 04/08/2023, 22h39

Ce que vous essayez de faire n'est pas possible, et de toute façon ça ne résout rien.
On ne peut pas empêcher un serveur web de répondre à des requêtes par adresse IP, car en réalité c'est même le principe des virtual hosts: le browser fait la résolution du nom de domaine, suite à cela il récolte une ou plusieurs adresses IPv4 et éventuellement IPv6, il en prend une au hasard, et tente de se connecter.
Donc en réalité la connexion se fait par adresse IP.

Parmi les headers que le browser envoie il y a un qui est très important: c'est le header Host, qui correspond au nom de domaine demandé.
En gros c'est comme si le browser faisait ça, avec quelques headers en plus:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

curl -L "Host: www.sogedima.be" http://92.222.217.123

C'est aussi ce qui fait qu'avec le protocole HTTP 1.1 (et suivants) une adresse IP peut héberger autant de noms de domaine qu'on le souhaite.

Pour faire simple: il ne faut pas chipoter à votre config, il faut souffrir en silence. Ou plutôt non, il faut mettre en place des mécanisme de défense.
De toute façon, vous ne pouvez pas être accessible et invisible en même temps.

Il est possible de bannir certaines adresses au niveau du firewall lorsqu'elles se comportent de manière malicieuse, on peut pour cela mettre en place en IDS et/ou un WAF par exemple.
Mais il faut aussi comprendre que beaucoup de scans sont légitimes: il y a des entreprises qui font de la veille/recherche, ou de l'indexation de services, ou même qui évaluent la présence de serveurs vulnérables. On pense à Shoddan mais il n'y a pas qu'eux. Et ce n'est pas toujours dans le but d'exploiter les failles.

De nos jours, beaucoup de sites sont sur Cloudflare pour ces raisons notamment.

**cmascart** · 05/08/2023, 03h18

Bonjour BinaryGirl,

C'est à n'y rien comprendre: je viens de restaurer le port 34521, et ça marche !
Il délivre les répertoires, sans le suffixe /
Qui m'avait tenu en haleine depuis quinze jours.
Au point d'y renoncer, faire machine arrière, et restaurer le port 80 hier.

Ce qui avait, illico, rallumé toutes les attaques sur 92.222.217.123 et 92.222.217.123:80
Et les autres hôtes listés plus haut.

Surfe sur 92.222.217.123
Tu n'auras plus rien.

Tu devras demander 92.222.217.123:34521

Par contre, si tu demandes www.sogedima.be/js
ou, plus simplement: sogedima.be/js

Tu recevras la page demandée, sans le suffixe /, que, désormais, ton browser rajoute automatiquement.
Alors qu'avant, il se plantait sur un not found.

Les visiteurs sont donc obligés de passer par mon certificat, dont l'IP est pointée par DNS
Certificat qui, à son tour, les envoie sur le port 34521 de mon VPS 92.222.217.123
Port que je changerai à l'occasion.
DNS ne pointe donc plus directement sur mon VPS.

Ces hackers sont malveillants.
Ils sniffent des pages critiques de certains logiciels, comme le login de wordpress, ou autodiscover.xml, que je n'ai pas.
Je n'ai aucun intérêt à coopérer avec eux, ni à leur donner ce qu'ils cherchent.

Si, à ton tour, tu gères un site protégé par un certificat, tu devrais aussi changer le port HTTP, et y faire pointer le certificat.
Tu épargneras toutes les intrusions sur le port 80.

Une autre astuce, que j'ai mise en pratique également est de configurer UFW pour qu'il ne réponde plus au ping.
A mon avis, les hackers commencent par pinger l'IP du VPS, avant de lui balancer des requêtes sur son port 80.
Si le ping ne répond pas, ton VPS sera plus discret.

Si si, on peut être à la fois accessible et invisible !
Ou peu visible.
C'est à dire accessible aux utilisateurs qui ciblent mon nom de domaine, et invisible à ceux qui tentent d'entrer autrement.

Bien à toi,
Christian.

**binarygirl** · 05/08/2023, 16h19

Envoyé par cmascart

C'est à n'y rien comprendre: je viens de restaurer le port 34521, et ça marche !
Il délivre les répertoires, sans le suffixe /

Si c'est juste un problème de réécriture d'URL, ça se règle avec Rewrite...
Mais ça n'a rien à voir avec les ports utilisés.

Envoyé par cmascart

Les visiteurs sont donc obligés de passer par mon certificat, dont l'IP est pointée par DNS

Ben oui, mais c'est la norme aujourd'hui de rediriger les requêtes vers https.
Ça ne supprime pas les attaques pour autant, ça ne fait que les déplacer.

Envoyé par cmascart

Certificat qui, à son tour, les envoie sur le port 34521 de mon VPS 92.222.217.123

92.222.217.123 ou 92.222.217.126 ????
sogedima.be correspond à 92.222.217.126 dans le DNS. Il y a une incohérence là.

Envoyé par cmascart

Une autre astuce, que j'ai mise en pratique également est de configurer UFW pour qu'il ne réponde plus au ping.
A mon avis, les hackers commencent par pinger l'IP du VPS, avant de lui balancer des requêtes sur son port 80.
Si le ping ne répond pas, ton VPS sera plus discret.

Le ping répond toujours pour l'instant...

Et en réalité les ports 80 et 443 ne sont pas fermés, et vous pouvez le vérifier:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
curl -L --head http://www.sogedima.be:80
curl -L --head https://www.sogedima.be:443

Ou bien:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

telnet www.sogedima.be 80

Encore une fois, je ne vois pas comment ça marcherait autrement, sans faire une redirection ouvertement sur le port 34521, ce qui en final n'est qu'une redirection et ne cache rien du tout.

**cmascart** · 05/08/2023, 17h34

Chez DNS, les domaines sogedima.be et www.sogedima.be désignent l'IP 91.134.128.126 du certificat.
Lequel désigne, à son tour, l'IP 92.222.217.123 du VPS, port 34521

Quant au certificat, il écoute certainement ses ports 80 et 443, comme tout serveur ordinaire.
Il n'est qu'un intermédiaire entre le client et le VPS.

Je ne suis pas aussi expérimenté que toi, en réseaux.
Mais, quand tu t'adresses à sogedima.be, ou son sous-domaine www, tu cibles, effectivement, un port ouvert 80 ou 443 du certificat.

DNS www.sogedima.be => Certificat 91.134.128.126:80 ou 443 => VPS 92.222.217.123:34521

Par contre, quand tu demandes 92.222.217.123, ou 92.222.217.123:80 ou :443
La requête échoue, comme je le voulais.

Le ping de sogedima.be répond aussi chez moi.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
christian@jupiter:~$ ping -i3 -c5 www.sogedima.be
PING www.sogedima.be (91.134.128.126) 56(84) bytes of data.
64 bytes from 91.134.128.126 (91.134.128.126): icmp_seq=1 ttl=49 time=31.1 ms
64 bytes from 91.134.128.126 (91.134.128.126): icmp_seq=2 ttl=49 time=54.2 ms
64 bytes from 91.134.128.126 (91.134.128.126): icmp_seq=3 ttl=49 time=57.2 ms
64 bytes from 91.134.128.126 (91.134.128.126): icmp_seq=4 ttl=49 time=154 ms
64 bytes from 91.134.128.126 (91.134.128.126): icmp_seq=5 ttl=49 time=109 ms
 
--- www.sogedima.be ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 12006ms
rtt min/avg/max/mdev = 31.097/81.060/153.868/44.420 ms

Mais pas le ping du VPS

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
christian@jupiter:~$ ping -i3 -c5 92.222.217.123
PING 92.222.217.123 (92.222.217.123) 56(84) bytes of data.
 
--- 92.222.217.123 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 12327ms

Mon montage fait donc échouer les attaques directes sur l'IP 92.222.217.123:80 du VPS
Qui représentent la majeure partie, car très peu de hackers passent par DNS et le certificat.
Mais, effectivement, j'en subis toujours un peu.

A mon avis, le hacker commence par pinger une IP, avant d'attaquer son port 80
Si l'IP ne répond pas au ping, c'est qu'il n'y a pas de serveur derrière. Il passe à l'IP suivante.

L'IP 92.222.217.126 aboutit sur le Prestashop de TechDiscount.
Je ne gère pas cette IP et ne connais pas ce site.
Comment l'a-tu trouvée ?

En forçant tout mon trafic à passer par DNS, je me demande si je ne me place pas, aussi, sous leur protection.
Imaginons que DNS décèle une attaque massive venant d'un pays hostile (Russie, Chine, Corée du nord), sur un nom de domaine qui lui incombe.

Peuvent-ils la bloquer, ou dns.be n'est-il qu'une sorte de bottin [Nom de Domaine => IP] passif ?

Perso, je pense avoir atteint mon objectif: Déjouer les attaques sur IP directe de mon VPS, en le mettant dans l'ombre du certificat.
92.222.217.123 est sourd au ping, et ses ports 80 et 443 ne répondent plus en http(s)

Merci BinaryGirl, et bien à toi,
Christian.

**binarygirl** · 05/08/2023, 19h05

Envoyé par cmascart

L'IP 92.222.217.126 aboutit sur le Prestashop de TechDiscount.
Je ne gère pas cette IP et ne connais pas ce site.
Comment l'a-tu trouvée ?

Une simple résolution du nom de domaine sogedima.be:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
dig +short -t a sogedima.be
91.134.128.126
dig +short -t a www.sogedima.be
91.134.128.126

Techniquement, ça veut dire que le site est hébergé sur cette adresse. En tout cas, quelqu'un a bien dû configurer le DNS dans ce sens

D'ailleurs, votre ping montre bien cette adresse. J'ai donc l'impression qu'il y a une possible confusion quelque part.

Assez logiquement, c'est bien vers cette adresse 91.134.128.126 que la connexion se fait:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
curl -v --head  -L https://www.sogedima.be
* processing: https://www.sogedima.be
*   Trying 91.134.128.126:443...
* Connected to www.sogedima.be (91.134.128.126) port 443
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=www.sogedima.be
*  start date: Jun 29 10:51:07 2023 GMT
*  expire date: Sep 27 10:51:06 2023 GMT
*  subjectAltName: host "www.sogedima.be" matched cert's "www.sogedima.be"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* using HTTP/1.x
> HEAD / HTTP/1.1
> Host: www.sogedima.be
> User-Agent: curl/8.2.0
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Sat, 05 Aug 2023 16:17:47 GMT
Date: Sat, 05 Aug 2023 16:17:47 GMT
< Server: Apache/2.4.52 (Ubuntu)
Server: Apache/2.4.52 (Ubuntu)
< Set-Cookie: PHPSESSID=t8of6m5uuoct3fl59cf8qpr9f2; path=/
Set-Cookie: PHPSESSID=t8of6m5uuoct3fl59cf8qpr9f2; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
Pragma: no-cache
< Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8
< X-IPLB-Request-ID: B9709210:BD22_5B86807E:01BB_64CE762A_BD35:239FF
X-IPLB-Request-ID: B9709210:BD22_5B86807E:01BB_64CE762A_BD35:239FF
< X-IPLB-Instance: 5426
X-IPLB-Instance: 5426

Ce qui est possible, c'est que votre hébergement dispose de plusieurs adresses IP. Il peut y avoir un routage réseau interne aussi.

**cmascart** · 05/08/2023, 19h30

C'est tout à fait exact.
Chez DNS, sogedima.be et www.sogedima.be pointent sur 91.134.128.126, l'adresse du certificat.
Lequel désigne, à son tour, celle de mon VPS 92.222.217.123:34521

Par contre, dans ton message de ce jour, à 16:19, tu dis

92.222.217.123 ou 92.222.217.126 ????
sogedima.be correspond à 92.222.217.126 dans le DNS. Il y a une incohérence là.

A mon avis, tu t'est trompée.
Tu reprends les trois premiers octets de l'adresse du VPS (92.222.217), et le dernier de l'adresse du certificat (126), pour improviser une adresse que je ne connais pas.
---------------------------
Tant que j'y suis, j'ai une question à te poser.
Voici comment j'ai configuré mon 000-default.conf

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
<VirtualHost *:34521>
	ServerName sogedima.be
	ServerAlias www.sogedima.be
 
	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html
        ErrorDocument 404 /err404.php
 
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

En vertu des directives ServerName et ServerAlias, il ne devrait répondre qu'à cet hôte sogedima.be.
Pourtant, 92.222.217.123:34521 délivre toujours ma page d'accueil.
J'ai fermé mon port 443 et mon port 80. Seul le 34521 est ouvert

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
34521/tcp                  ALLOW IN    Anywhere

Quand tu demandes 92.222.217.123:34521
Le nom de sogedima n'apparaît pourtant nulle part dans la requête.
A quoi servent ServerName et ServerAlias ?

**binarygirl** · 05/08/2023, 22h04

Certaines choses ne sont pas claires.
Si le VPS a l'adresse IP 92.222.217.123, alors sur quel équipement est monté l'adresse 91.134.128.126
et comment est fait le lien entre les deux ?

PS: j'ai fait un petit scan de l'extérieur pour voir les ports ouverts:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
nmap -PN -n -p 80,443,34521  92.222.217.123
Starting Nmap 7.94 ( https://nmap.org ) at 2023-08-05 21:47 CEST
Nmap scan report for 92.222.217.123
Host is up (0.11s latency).
 
PORT      STATE    SERVICE
80/tcp    filtered http
443/tcp   filtered https
34521/tcp open     unknown
 
Nmap done: 1 IP address (1 host up) scanned in 2.16 seconds
 
nmap -PN -n -p 80,443,34521  91.134.128.126
Starting Nmap 7.94 ( https://nmap.org ) at 2023-08-05 21:47 CEST
Nmap scan report for 91.134.128.126
Host is up (0.094s latency).
 
PORT      STATE SERVICE
80/tcp    open  http
443/tcp   open  https
34521/tcp open  unknown
 
Nmap done: 1 IP address (1 host up) scanned in 0.18 seconds

Je ne sais pas comment tout ça est organisé, je me demande s'il n'y a pas du port forwarding quelque part.

**cmascart** · 05/08/2023, 23h16

Bonsoir BinaryGirl,

Tu me demandes où est installé la machine 91.134.128.126
Je n'en sais rien. Pas sur mon VPS, en tous cas.

Pour l'https, j'ai commandé un certificat gratuit let's encrypt chez OVH
Ils m'ont dit de faire pointer mon nom de domaine sur son IP, ce que j'ai fait.

Puis, de configurer ledit certificat, pour qu'il pointe sur mon VPS, dont je devais donner l'adresse IP 92.222.217.123
et le port 80 par défaut, que j'ai changé pour 34521, dans la config du certificat.

Après avoir lu des articles sur "Sécuriser un VPS", qui recommande de changer les ports par défaut, surtout le 22 SSH
L'historique des visites de ma page 404 n'a fait que confirmer mes craintes.

A mon avis, OVH a affecté une machine adhoc pour héberger les certificats.
Je n'y connais pas grand-chose en sécurité, et ne saurais pas te renseigner plus.

De base, je suis analyste-programmeur, pas expert en réseaux.
Mais il faut bien que j'apprenne, quand on développe une application à proposer sur le web, c'est indispensable.

En ce qui concerne mon VPS, J'ai fermé les ports 80 et 443 avec UFW, tant en ipv4 qu'en ipv6
Ton NMap les dit "Filtered".

Ce que je ne comprend toujours pas, c'est pourquoi 92.222.217.123:34521 délivre toujours ma page d'accueil
Alors que j'ai configuré ce virtualhost avec
ServerName sogedima.be
ServerAlias www.sogedima.be

En principe, si le Host ne contient pas une de ces deux expressions, il ne devrait pas délivrer la page d'accueil.
A quoi servent les ServerName et ServerAlias ?

Mon but est d'empêcher l'accès direct à l'IP 92.222.217.123 hors certificat, même en stipulant le port 34521
Si la requête ne vient pas du DNS et du certificat, pour mettre mon VPS complètement dans l'ombre du certificat.
Afin que le hacker qui lise cette page web, et prenne connaissance de mon port secret, ne puisse pas atteindre mon VPS en direct.

Port secret, que je changerai dans les prochaines semaines.

Bien à toi,
Christian.

Certificat vers un répertoire

Apache

Discussions similaires

Partager

Partager