Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

hébergement mutu : ouverture des connexions sortantes bloquée

7 réponses
Avatar
bretz
Bonjour,

J'essaie d'implémenter une application rss reader (lecture) en php-mysql
chez mon hébergeur x dont par ailleurs je suis très satisfait.

Je n'y parviens pas et remarque que c'est les fopen() sur l'extérieur qui ne
fonctionnent pas chez cet hébergeur x que cela fonctionne très bien chez
d'autres.
Interrogé à ce sujet, mon hébergeur x répond :

" Et oui ... L'architecture actuelle des serveurs mutualisés empeche les
scripts PHP (ou perl) d'ouvrir des connexions sortantes, par mesure de
sécurité. Cela empeche notamment toutes les exploitations récentes de
scripts PHP (par phpBB par exemple) de récupérer des trojans à
l'extérieur et de les installer sur les machines. Ainsi par exemple lors
du virus/ver attaquant les phpBB, les exploitations ont échoué sur les
forums hébergés par x.

Cela empeche également éventuellement un utilisateur pas tres clean
ou un hébergé compromis d'attaquer d'autres machines.

Pour nous c'est un souci en moins, pour vous c'est la garantie que meme
un script PHP mal programmé n'aura pas de conséquences catastrophiques,
en tout cas pas par ce genre d'exploitation.

Le message "no route to host" est généré par la couche IP de la machine
quand elle se heurte aux regles de firewall."

N'étant pas un expert en sécurité d'hébergement je demande aux hébergeur ici
présent leur position par rapport à ce blocage des connections sortantes
qui, à tort ou à raison, me semble excessif. N'existe-t-il pas d'autres
moyens de protections pour l'hébergeur que cette solution qui a le mérite
d'être radicale.

Merci pour vos commentaires

Bretz

7 réponses

Avatar
Christophe Baegert
bretz wrote:
N'étant pas un expert en sécurité d'hébergement je demande aux hébergeur
ici présent leur position par rapport à ce blocage des connections
sortantes qui, à tort ou à raison, me semble excessif. N'existe-t-il pas
d'autres moyens de protections pour l'hébergeur que cette solution qui a
le mérite d'être radicale.


Il faut dire que faire un fopen vers l'extérieur dans un script php, c'est
une solution un peu "crade"...

Avatar
bretz
Christophe Baegert wrote:

Il faut dire que faire un fopen vers l'extérieur dans un script php,
c'est une solution un peu "crade"...


merci pour cette réponse,
comment feriez-vous en php pour tester l'existence d'un fichier (en
l'occurence un flux xml en rss) sans utiliser un fopen() ? existe-t-il un
autre moyen ?
bien à vous
Bretz

Avatar
Christophe Baegert
bretz wrote:
merci pour cette réponse,
comment feriez-vous en php pour tester l'existence d'un fichier (en
l'occurence un flux xml en rss) sans utiliser un fopen() ? existe-t-il un
autre moyen ?


Ce n'est pas le langage le problème, c'est l'appel. Faire appel à un script
distant à travers un script lui-même distant de l'appelant avec un
protocole aussi peu adapté au lancement de programme que le HTTP c'est un
peu casse-cou. Si vous lancez votre PHP en Cron sur le serveur c'est déjà
un peu plus propre. AMHA :-)

Avatar
drico
bretz wrote:
Christophe Baegert wrote:


Il faut dire que faire un fopen vers l'extérieur dans un script php,
c'est une solution un peu "crade"...



merci pour cette réponse,
comment feriez-vous en php pour tester l'existence d'un fichier (en
l'occurence un flux xml en rss) sans utiliser un fopen() ? existe-t-il
un autre moyen ?
bien à vous
Bretz
Malheureusement si la connexion sortante est bloqué au niveau du noyau

par grsecurity ou quelque chose du genre, ca echouera. sinon peut etre
avec les fonctions system ou exec et des utilitaires comme wget ou lynx.

Amicalement
CP


Avatar
FightClub!
bretz wrote:

merci pour cette réponse,
comment feriez-vous en php pour tester l'existence d'un fichier (en
l'occurence un flux xml en rss) sans utiliser un fopen() ? existe-t-il un
autre moyen ?



Ce n'est pas le langage le problème, c'est l'appel. Faire appel à un script
distant à travers un script lui-même distant de l'appelant avec un
protocole aussi peu adapté au lancement de programme que le HTTP c'est un
peu casse-cou. Si vous lancez votre PHP en Cron sur le serveur c'est déjà
un peu plus propre. AMHA :-)


C'est pourtant la base de l'aggrégation de contenu temps réel, et une
grande majorité des webservices utilisent HTTP ou HTTPS, ou est le
problème ?

Nombre d'hébergeurs empeche PHP d'ouvrir une connexion vers l'extérieur
mais autorisent perl et autres executables (wget etc.) à le faire, ça me
semble assez illogique (à part utiliser les ressources supplémentaires
pour la création d'un nouveau process je ne vois pas ??)

--

http://SurveilleTonSite.sd2i.org
Alerte gratuite par mail en cas de problème sur votre site.


Avatar
Christophe Casalegno
bretz wrote:


merci pour cette réponse,
comment feriez-vous en php pour tester l'existence d'un fichier (en
l'occurence un flux xml en rss) sans utiliser un fopen() ? existe-t-il un


Curl est votre ami :)

amicalement,

--
Christophe Casalegno | Groupe Digital Network | UIN : 153305055
http://www.digital-network.net | http://www.securite-reseaux.com
TISTC | OFREMHI | IIHEC | IICRAI | CIRET-AVT | KESAC | TIIX
Technical director | Security Intrusion techniques & infowar specialist.

Avatar
bretz
bretz wrote:

comment feriez-vous en php pour tester l'existence d'un fichier (en
l'occurence un flux xml en rss) sans utiliser un fopen() ?
existe-t-il un autre moyen ?
bien à vous
Bretz


Merci pour toutes ces réponses. Malheureusement mon rss reader qui utilise
le fopen() est un soft acheté (une extension dreamweaver) à laquelle j'ai
pas trop envie de toucher pour des problèmes de compatibilité avec les
versions ultérieures.
Je crois que le plus simple sera de prendre un autre mutu chez un hébergeur
autorisant l'ouverture de connexions extérieures et soit d'y mettre les
projets intégrant du rss soit d'y "déporter" les pages "litigieuses".
Bretz