Apache2 empecher la consultation via ip

Support Debian
#1

Bonjour à tous,

J’aurais une question qui peut sembler naïve à priori mais, peut-on bloquer l’accès d’un site via son ip ? Je possède un site et j’ai réussit à crée une redirection des que l’ip est saisit en lieu et place du domaine, mais lorsque je passe cette même ip en https, là impossible de rediriger quoique ce soit.

Je me retrouve avec un avertissement de sécurité et lorsqu’il est accepté mon site apparait en http ! J’ai beau tout faire pour le rediriger dans mon vhost impossible …

Connaitriez vous une solution pour ça ?

Merci d’avance à tous et bon week-end !

#2

Oui, il est possible de bloquer un site par son IP, il faut prendre en compte deux choses.

D’abord, comme tu as accès au site en question pour savoir comment mettre en place le blocage.

Enfin, sache que tu peux bloquer un site avec une adresse IP, mais si cette adresse IP est également l’adresse IP d’un autre site, il sera bloqué aussi, et d’autre part, si le site est hébergé sur d’autres adresse IP, le site sera toujours accessible.

#3

Qu’entends tu par là ? Tu parle au sens général du terme ? Je suis le propriétaire du site, et j’y ai accès par le biais d’un vps si c’est ça que tu voulais savoir. :slight_smile:

Oui, le vps héberge d’autres sites en sous domaine. Je ne pourrais donc pas bloquer l’adresse en tant que t’elle si j’ai bien compris ce que tu m’as dit. (ce qui parait logique, puisque il faut que le serveur puissent rester accessible d’une manière où d’une autre)

Ne puis je pas au minimum mettre en place un certificat ? Car certbot ne voudra sûrement pas me donner de certificat puisque nous parlons là d’une ip et non d’un domaine.

Et si la mise en place du certificat n’est pas possible n’y a t-il pas une règle x où y via apache que je puisse mettre en place afin de ne pas accéder au site avec aussi peu de sécurité … Car les classiques Rewrite que j’ai tenté de mettre en place ne semble pas fonctionner, ni même les directives redirect.

#4

Bonjour,

Si tu ne veux pas que le site web soit accessible par l’IP (ou une de ses IP) du serveur (si j’ai bien compris), ile plus simple est d’avoir un hôte virtuel par défaut qui renvoie une erreur quelconque, p. ex 403; avec bien sûr un autre hôte virtuel pour le nom de domaine.

#5

Bonjour @anon70622873

Oui c’est ce que j’ai déjà fait (me semble t-il) mais justement avec le https ça ne fonctionne pas. J’entends par là que oui quand on rentre l’ip de manière classique en http ça fonctionne, mais il suffit de rajouter le https suivit de l’ip et là ça redirige vers la page (avec l’avertissement du au fait que la page est autosigné ) ce qui in fine fait qu’on atterrit sur le site de manière non sécurisé malgré tout.

Voici ce que j’ai fait actuellement pour la page en http classique.

<VirtualHost *:80>
ServerName xxx.xxx.xxx
RedirectPermanent 404 /
</VirtualHost>
#6

Oui un hôte virtuel avec l’IP peut être une solution mais dans ce cas il vaut mieux faire quelque chose du type :

<VirtualHost *:80>
  ServerName xxx.xxx.xxx
  DocumentRoot /var/www/html
  <Directory /var/www/html>
    Require all denied
  </Directory>
</VirtualHost>
<VirtualHost *:443>
  ServerName xxx.xxx.xxx
  DocumentRoot /var/www/html
  <Directory /var/www/html>
    Require all denied
  </Directory>
</VirtualHost>

At si tu veux faire une redirection ne mélange pas RedirectPermanent (301) avec les autres états (404). La doc : mod_alias - Serveur HTTP Apache Version 2.4

#7

Alors j’ai reprit cette partie de ton script en l’adaptant bien évidemment

    <Directory /var/www/html>
        Require all denied
      </Directory>

car c’est la seul qu’il me manquait dans mon vhost, j’ai donc d’emblée tout refuser pour le vhost qui a pour servername mon ip et ensuite toujours avec ton bout de code j’ai tout accepté dans les autres vhost comme ceci.

```
<Directory /var/www/html>
    Require all granted
  </Directory>
```

Hélas toujours pareil, je n’ai pas accès à l’ip en http, mais j’y ai accès en rajoutant le « s »

#8

Non pas quelconque, chaque code d’erreur correspond à un type d’erreur particulier.

utilises-tu sites-available ou conf-available?
car le comportement du serveur apache n’est pas le même dans ce cas. le premier sert pour des configuration de virtual host, le premier pour des configurations globales.

la gestion d’un site par alias permet le plus souvent d’utiliser une ip, par vhost d’utiliser un FQDN.

#9

@Zargos J’utilise site-available

Donc si c’est ça mon site sera "condamner " à rester accessible en http ? :confused:

#10

non car tu peux tout simplement ne le définir qu’en HTTPS, et ne pas avoir d’entrée en HTTP. Ou de faire un rewrite pour imposer le HTTPs.

#11

Le problème étant que quand dans les vhost je définis le servername comme étant mon ip et que ce vhost je le met en http les navigateur détecte le fait qu’il n’y ai aucun nom de domaine comme étant suspect, et le certificat étant autosigné j’ai un message d’avertissement. Une fois les avertissement passé le site rebascule en http (celui là même qui est théoriquement censé être chiffré)

Et j’ai testé il est différent de l’autre qui est simplement en http, car quand je crée une redirection sur le vhost avec le port 80, la redirection fonctionne. Le soucis reste qu’on peut contourner le tout en mettant un « s » ce qui crée ce que je décris plus haut, l’avertissement puis le basculement sur le site mais en http …

Je ne sais pas si je suis bien clair ?

En somme dans mon site available j’ai ceci :

<VirtualHost *:80>
ServerName xxxx.xxxx.xxxx
Redirect / 404
</VirtualHost>

Celui ci la redirection fonctionne.

<VirtualHost *:443>
ServerName xxxx.xxxx.xxxx
</VirtualHost>

Mais celui ci malgré lui permet de contourner la redirection du premier pour accéder à celui ci sans chiffrement (alors qu’il est censé y en avoir un. Et vu que ce n’est pas un domaine je doute que certbot accepte de me signer un certifcat pour faire disparaitre l’avertissement

Donc c’est le serpent qui ce mord la queue en somme :sweat_smile:

#12

Non pas très…
Si tu veux forcer la connexion en HTTPS il faut faire une redirection permanente dans ton hôte virtuel sur le port 80 vers le site en HTTPS, exemple :

<VirtualHost *:80>
  ServerName xxxx.xxxx.xxxx
  Redirect permanent / https://xxx.xxx.xxx.xxx/
</VirtualHost>
<VirtualHost *:443>
  …
</VirtualHost>

à toi de voir s’il faut mettre la redirection vers une URL avec l’adresse IP ou avec le nom de domaine.

Mais il aurait été plus simple et plus sûr d’avoir un hôte virtuel par défaut qui interdise (ou renvoie une erreur) pour toute requête autre que le(s) nom(s) de domaine spécifiés dans les directives ServerName ou ServerAlias des autres hôtes virtuels.

#13

Ok, c’est bon ça fonctionne. Merci à vous deux @anon70622873 @Zargos

#14

Si u veux utiliser l’IP pour le HTTPs, alors il faut obligatoirement que cette IP ait été ajoutée dans la définition du certificat sinon ça ne marchera jamais ou alors systématiquement avec une erreur.

#15

Par définition du certificat tu entends dans un vhost en 443 ?

#16

non.
Quand tu fais du HTTPs, tu va créer un certificat Serveur pour le chiffrement de la communication avec les clients.
Pour que cette communication soit accceptée, il faut impérativement que les URL utilisées soient incluses dans le certificat, soit explicitement, soit par wildcard, soit par IP:

certificat www.toto.com avec ip A1.B1.C1.D1:
www.toto.com
w3.toto.com (alternate)
A1.B1.C1.D1 (IP alternate)

Exemple d’un equipement chez moi:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
…3:89:5E
X509v3 Authority Key Identifier:
keyid:B…

X509v3 Key Usage critical:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage critical:
TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:equip.net.local.net, IP Address:A1.B1.C1.D1, DNS:equip