Salut,
Dans le cadre un peu particulier (DOSFSP) d’ordinateurs fortement sécurisés sur lesquels nous n’avons pas les droits admin’ (root) et sur lesquels tout est réinitialisé au démarrage*, je cherche malgré tout à avoir un serveur web + PHP en local pour apprendre le dev’web…
*: Il est possible de sauvegarder et récupérer un dossier utilisateur, avec travaux élève, etc. Le nécessaire pour serveur web+PHP pourrait en être un sous-dossier.
Donc, je cherche à savoir s’il est possible (…)
Bonjour,
Je suis très heureux de pouvoir adhérer à ce forum en tant que débutant sous linux.
J'ai entrepris de dockériser de nombreuses VM ubuntu server afin de gagner en ressources et facilité.
Actuelllement j'ai dockérisé : Apache Guacamole, Noip (DDNS), Nextcloud, AdGuardHome, Jellyfin et Glyde (webproxy)
Il me reste par ailleurs "ejabbered + coturn" à dockériser mais je n'y arrive pas !
Actuellement ma dernière VM est un CentOS Nethserver qui jour deux rôles :
xmpp (ejabbered server) et (…)
Dans une installation Linux-nginx-PHP classique, on a:
Bonjour,
j'ai installé nginx sur un raspberry pi avec un écran tactile pour en faire une interface web de type kiosk.
J'aimerai que ces pages web s'affichent sur l'écran du RPi (adresse http://localhost) mais soit aussi accessible du reste du réseau local par l'IP du RPi. Sauf que j'aimerai que l'accès depuis le réseau soit protégé par un mot de passe.
J'ai ajouté un .htpasswd à la racine du site et modifié en conséquence /etc/nginx/sites-available/default avec auth_basic et auth_basic_user_file
J’avais présenté ici le script ApacheCheck lors de sa première release, un script PHP qui analyse la configuration d’un serveur Apache et ses paramètres d’exécution, tels que consommation mémoire, usage CPU et accès disque.
Depuis les versions se sont enchaînées, au gré de mes idées et des retours que j’ai pu avoir ici ou là. Voici donc aujourd’hui la version 2.0, qui intègre toutes les améliorations successives, et, pour justifier ce changement de version majeur, intègre la prise (…)
Bonjour à tous!
Je viens vers vous car j'ai un petit soucis avec mon NAS et celui-ci fonctionne sous OpenMediaVault…
J'ai installé Nextcloud sur docker puis par la suite j'ai voulu tester AMP CubeCoders et je l'ai installé comme ça sur ma machine… Sauf qu'en installant AMP CubeCoders, celui-ci s'est approprié les ports 80 et 443 pour son interface d'administration sauf que j'utilisais ses ports pour Nextcloud. J'ai donc désinstallé AMP CubeCoders mais malgré tout j'ai un processus nginx qui (…)
C’est un outil qui va vous éviter de devoir suivre les bonnes pratiques de sécurité à chaque fois que vous avez besoin d’un serveur web ou d’un reverse proxy en frontal de vos services web. Bunkerized-nginx se présente sous la forme d’une image Docker et va s’occuper des paramètres et configurations pour vous. Le but final est d’atteindre une sécurité « par défaut » sans (trop) d’action de votre part.
Dans cette dépêche, nous allons faire un tour d’horizon de différentes manières de communiquer avec un serveur depuis une application Web, avec un petit peu d’histoire, avant de rentrer plus profondément dans le fonctionnement des WebSockets, que nous allons démystifier. Nous digresserons ensuite à propos de la gestion (problématique) des requêtes longues et de HTTP 2 avec Apache, et nous discuterons d’une manière de limiter la casse. La dépêche contient quelques morceaux raisonnables mais l’absurdité est latente.
Supposons que nous ayons une application Web qui a besoin de recevoir des évènements du serveur pour voir si quelque chose s’est passé. À tout hasard, un jeu de société en ligne. Ce jeu a besoin d’envoyer les coups des joueurs et joueuses, et de recevoir les coups des autres.
Le serveur ne peut pas contacter le navigateur. Celui-ci est peut-être derrière un pare-feu, et de toute façon il n’y a pas de méthode pour cela. Le modèle du web, c’est une requête HTTP de la part du navigateur, et le serveur sert cette requête. Et puis, à la base, une requête = un chargement de page.
Mais des techniques sont apparues pour abuser de ce modèle, puis les standards se sont mis à intégrer des méthodes pour mener ces abus en toute sérénité.
la société F5 (leader sur le marché des ADC) rachete NGINX pour 670 millions
l'annonce coté F5
https://www.f5.com/company/news/press-releases/f5-acquires-nginx-to-bridge-netops-devops
l'annonce coté NGINX
https://www.nginx.com/blog/nginx-joins-f5/
F5 n'est pas du tout open source, on va voir ce que va devenir NGINX
Ma société travaille depuis plusieurs mois sur un projet de WAF, ou pare‐feu applicatif, articulé autour du serveur HTTP et proxy inverse nginx. Après une foule de tests et une épreuve du feu pour le moins tendue, la première version stable de NAXSI, c’est son nom, est disponible au téléchargement en code source et en paquet Debian.
NAXSI est sous licence GPL v2 et s’utilise conjointement avec nginx. Son principal but est de bloquer de manière efficace les attaques classiques de type injection SQL, Cross‐Site Scripting, Cross‐Site Request Forgery, ou encore inclusion de sources tierces locales ou distantes.
Au contraire des WAF déjà connus, NAXSI ne se base pas sur des signatures, mais plutôt sur la détection d’attaques connues en interceptant des caractères et autres chaînes suspectes dans les requêtes HTTP. Tel un système anti‐pourriel, NAXSI affecte un score à la requête et, lorsque ce dernier est trop élevé, le client est redirigé sur une page de type 503.
Malgré ses récents faits d’armes, NAXSI reste un projet jeune, et en tant que tel, nécessite plus de tests. Aussi, n’hésitez pas à lui donner sa chance, vos retours seront grandement appréciés !