Vous n'êtes pas identifié(e).
Et ce n'est pas les failles qui ouvrent les ports, les failles peuvent permettre d'obtenir un acces root par exemple
Exact je me suis mal exprimé, les failles correspondent à des ports, exemple la faille vnc correspond au port 5900
Il n'a pas besoin de le scanner, une fois qu'il a acces à la machine via un port entrant,
Et pour trouver une machine et un port entrant ouvert et espérer y installer une saloperie, il lui faut bien un scanner de faille non? Ce dernier lui donnera l'ip qui correspond à une machine et le/les port(s) entrant(s) ouvert(s) (correspondant à un/des services, forcément.), à moins que le hackeur sélectionne directement un port précis et donc recherche une faille précise... dans son scanneur.
Le danger se situe principalement sur les services installés sur la machine et donc au niveau du trafic entrant :
Si le pirate ne peut pas entrer, il ne peut rien faire , s'il peut entrer, il aura tout le loisir de tester les ports sortant pour en trouver un ouvert et il commencera surement par le 80..
Oui, tu redis ce que j'ai évoqué avant, mais comme nous sommes malins, nous interdisons tous (entrant et sortant) et nous autorisons que certains ports sortants uniquement, à partir de là je ne comprends plus trop comment est-ce possible pour transformer ton pc en zombie (via la saloperie qu'il a installer en pénétrant par le port entrant ouvert) pour un reseau de bot (spam, DDOS etc etc).
Évidemment, les admins d'un serveur qui ouvrent le port correspondant à un service (ex : http) soignent leur fichier de configuration de façon à limiter les failles potentielles, font les maj et ils observent leurs logs... Si des ips deviennent génantent, ils les shootent avec le pare feu.
Aucun intêret pour un hackeur que de scanner une liste d'ip sur le port 80 .
J'utilise le mot Hackeur car il y a deux catégories, les blacks Hat et les Whites hat
Tschuss!
Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.
Hors ligne
Félicitation ! Votre sécurité semble optimale !
La totalité des ports TCP testés sont masqués, votre ordinateur ne donne donc aucune réponse aux tests de ports effectués. Votre machine est donc invisible aux yeux de pirates potentiels.
Ports TCP ouverts
Aucun port détecté
Ports TCP fermés
Aucun port détecté
Ports TCP masqués
.....
S'en suit une longue liste de ports masqués.
Question (le retour ) :
j'imagine une différence entre "fermé" et "masqué". Oui mais, laquelle est-ce exactement ... ?
Un port masqué peut-il être "masqué fermé" ou "masqué ouvert" et vice/versa et inversement ?
Dernière modification par Y316 (06-12-2012 21:25:14)
Debian 9 (stretch) + la pire ICC que vous ayez probablement jamais rencontré.
Hors ligne
j'imagine une différence entre "fermé" et "masqué". Oui mais, laquelle est-ce exactement ... ?
Fermé : toc-toc, bonjour, ah mince c'est fermé ! On peut essayer de forcer la porte non? ... puisqu'elle existe!
Masqué
- toc-toc- Pas de réponse, il y a quelqu'un? Cette porte existe-t-elle?
Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.
Hors ligne
Debian 9 (stretch) + la pire ICC que vous ayez probablement jamais rencontré.
Hors ligne
Dernière modification par vince06fr (07-12-2012 01:22:38)
Hors ligne
J'ai juste fais
(qui traverse le mur client -> web,
par exemple
Le résultat n'est pas différent puisque la page web s'affiche et cela prouve bien qu'un serveur web "attend" l'ordre du visiteur. Le html est affiché directement à l'hote, le php est généré sur le serveur.
Lorus.
Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.
Hors ligne
la page web s'affiche et cela prouve bien qu'un serveur web "attend" l'ordre du visiteur.
C'est ce que j'avais plus ou moins compris en configurant iptables : la stratégie était de faire rentrer uniquement ce qui était en réponse d'une requète de l'utilisateur.
En toute logique, il est parait préférable de fermer aussi les sorties possibles mais le pirate une fois rentré, peut effectivement sortir comme il veut.
Sur ce choix, je crois que c'est une question de maîtrise de son système.
Debian 9 (stretch) + la pire ICC que vous ayez probablement jamais rencontré.
Hors ligne
Exact je me suis mal exprimé, les failles correspondent à des ports, exemple la faille VNC correspond au port 5900
Faux :
les failles correspondent à des logiciels, exemple une faille VNC serait toujours présente si VNC etait configuré pour utiliser un autre port que le 5900. Une faille correspond à un problème de sécurité (dû en général à une erreur de programmation), qui peut être exploité pour détourner l'usage d'un service ou obtenir un acces root, etc..
Et pour trouver une machine et un port entrant ouvert et espérer y installer une saloperie, il lui faut bien un scanner de faille non? Ce dernier lui donnera l'ip qui correspond à une machine et le/les port(s) entrant(s) ouvert(s) (correspondant à un/des services, forcément.),
Encore faux
Généralement la cible est connu, il est aussi possible de lancer un scan de port sur un range d'ip pour obtenir des adresses ip de machines autorisant le trafic entrant sur des ports ouvert correspondant à des services.
Une fois les services détectés, on peut utiliser un scanner de faille pour détecter des failles dans les logiciels utilisés par ces services.
à moins que le hackeur sélectionne directement un port précis et donc recherche une faille précise... dans son scanneur.
Et non!!
exemple le plus courant, un serveur web sur le port 80. un scanner de faille va detecter les failles sur ce serveur, ces failles seront en rapport avec les logiciels installé : php principalement sur un serveur web. Donc un port precis mais un paquet de failles potentiels...
et nous autorisons que certains ports sortants uniquement, à partir de là je ne comprends plus trop comment est-ce possible pour transformer ton pc en zombie (via la saloperie qu'il a installer en pénétrant par le port entrant ouvert) pour un reseau de bot (spam, DDOS etc etc).
[...]Aucun intêret pour un hackeur que de scanner une liste d'ip sur le port 80
J'ai jamais dit qu'il scannerait une liste d'ip sur le port 80
Bon le mieux c'est un exemple :
Soit 2 machines ayant VNC installé et donc le trafic entrant autorisé sur le port 5900/TCP,
la première machine est configuré comme la tienne, aucun autre trafic entrant n'est autorisé, seul quelques ports (dont le 80/tcp) sont autorisés pour le trafic sortant.
La 2eme machine est configurée comme la mienne. Aucun autre trafic entrant n'est autorisé. Le trafic sortant est autorisé dans tout les cas (donc le port 80/tcp est disponible pour le trafic sortant)
Le hacker exploite une faille sur VNC qui lui permet de prendre le contrôle de la machine dans les 2 cas. Une fois le contrôle de la machine obtenu, même sans accès root, pour faire participer la machine compromise à un DDOS, il lui suffit de lancer son attaque vers le serveur web cible en utilisant donc le port 80 en sortie, ce qui est autorisé dans les 2 cas...
Si il peut obtenir un accès root via une faille il peut ensuite bien sûr faire ce qu'il veut..
Les 2 configurations ne sont pas plus secure l'une que l'autre et il est important de se méfier des fausses impressions de sécurité...
Bon ce n'est pas le sujet du post donc pour continuer à debattre sur le sujet, le mieux serait d'ouvrir un autre post
Edit :
ma configuration est: tout fermé en entrant et quelques ports autorisés en sortant.
Parce que tu n'as pas de service installé sur ta machine, j'imagine que si tu devais installer un serveur SSH par exemple, tu autoriserais le trafic entrant sur le port 22/TCP ...
Je n'ai pas ajouter une règle dans ufw qui autorise les connexions entrantes (qui traverse le mur dans le sens web -> client) sur le port 80 :
# ufw allow in 80/tcp
J'ai juste fais
# ufw allow out 80/tcp
(qui traverse le mur client -> web,
par exemple smile
Le résultat n'est pas différent puisque la page web s'affiche et cela prouve bien qu'un serveur web "attend" l'ordre du visiteur.
En fait le résultat est complètement different :
est equivalent à
ou pour apache
ce qui autorise les connection entrante sur le port 80/TCP et est necessaire uniquement sur un serveur écoutant sur le port 80 (en principe un serveur web).
permet à une machine cliente de se connecter à un serveur qui écoute sur le port 80,(habituellement un serveur web) et est utile uniquement si le trafic sortant est interdit par défaut
Le html est affiché directement à l'hote, le php est généré sur le serveur.
Ça se passe toujours comme ça, les pages web sont servi (eventuellement généré par php ou autre) par le serveur web et affiché sur la machine cliente.
cependant si tu installes un .deb (sans le code source) et que le programme installe un serveur qui tourne en arrière plan sur un port choisit par un hackeur, la technique du tout filtrant est mieux smile Il utilisera un port bidon pour être discret ex:1024 en tcp. Et là tu ne vois trop rien... pour M et Mme Michu
Premierement, il s'agit encore une fois de trafic entrant (serveur) donc interdit dans les 2 cas et deuxièmement un bon pirate aura profité d'inclure dans le .deb une commande pour ouvrir le port dont il a besoin.
Dernière modification par vince06fr (07-12-2012 09:12:49)
Hors ligne
Faux :
les failles correspondent à des logiciels, exemple une faille VNC serait toujours présente si VNC etait configuré pour utiliser un autre port que le 5900. Une faille correspond à un problème de sécurité (dû en général à une erreur de programmation), qui peut être exploité pour détourner l'usage d'un service ou obtenir un acces root, etc..
Cela peut être vrai, tout bon administrateur changera le port d'écoute... Cependant je n'ai jamais réussi à modifier le port d'écoute pour une négociation SSL/TLS avec certificat ssl en 1024 bits d'un serveur ftp, c'est 995, sinon le protocole foire ! Si tu as une soluce, je suis preneur.
Une faille correspond à à un problème de sécurité (dépassement de tampon par exemple) ou à une mauvaise configuration... Le fameux fichier conf.
Encore faux
Généralement la cible est connu, il est aussi possible de lancer un scan de port sur un range d'ip pour obtenir des adresses ip de machines autorisant le trafic entrant sur des ports ouvert correspondant à des services.
Une fois les services détectés, on peut utiliser un scanner de faille pour détecter des failles dans les logiciels utilisés par ces services.
Et bien décidemment j'ai tout faux:)
Cela est vrai pur les serveurs connus comme Google et bien d'autre. Je crois déjà avoir évoquer ce que tu dis, le pas bô lancera un scan d'ip sur un port précis pour trouver une machine moins connue.
Et non!!
exemple le plus courant, un serveur web sur le port 80. un scanner de faille va detecter les failles sur ce serveur, ces failles seront en rapport avec les logiciels installé : php principalement sur un serveur web. Donc un port precis mais un paquet de failles potentiels...
Ah vraiment ? Que de certitudes ! Que fais-tu de Apache, SQL , LDAP,SSH et autres babioles ?:D
Vi, le port précis permet donc de détecter le service, les failles peuvent êtres logiciel ou une mauvaise configuration dudit service en laissant un trou béant:D
Dans le premier cas, une maj régulière prévient ce souci, dans le deuxième, une formation de l'admin les prévient également
Tu scannes une faille php sur quel port toi ? Il existe des scanner qui teste les formulaires php présents sur le site, et si la faille est avérée, le méchant pas bô s'en servira pour faire suer ou récupérer le nom d'utilisateur et les mdp des compte par exemple.... Donc php est bien un script qui est généré sur le serveur. La plus part du temps, c'est le programmeur qui ne sécurise pas assez ses variables dans son script.
Évidemment, le fichier de conf de php (/etc/php5/apache/php.ini sous une deb) peut aussi présenter une faille si mal configuré. Si tu écris http://lesite.fr/php.ini, tu as de forte chance de tombé sur une page erreur 403 (forbidden). C'est que les droits d'accès dudit fichier est bien paramétré et supprime une faille, sinon il peut cracher des informations pertinentes ! Et le pare feu en rie encore:lol:
Soit 2 machines ayant VNC installé et donc le trafic entrant autorisé sur le port 5900/TCP,
la première machine est configuré comme la tienne, aucun autre trafic entrant n'est autorisé, seul quelques ports (dont le 80/tcp) sont autorisés pour le trafic sortant.
La 2eme machine est configurée comme la mienne. Aucun autre trafic entrant n'est autorisé. Le trafic sortant est autorisé dans tout les cas (donc le port 80/tcp est disponible pour le trafic sortant)
Le hacker exploite une faille sur vnc qui lui permet de prendre le controle de la machine dans les 2 cas. Une fois le controle de la machine obtenu, même sans accès root, pour faire participer la machine, il lui suffit de lancer son attaque vers le serveur web de son choix en utilisant donc le port 80 en sortie, ce qui est autorisé dans les 2 cas...
Si il peut obtenir un accès root via une faille il peut ensuite bien sûr faire ce qu'il veut..
Les 2 configurations ne sont pas plus secure l'une que l'autre et il est important de se mefier des fausses impressions de sécurité...
Quel est la machine serveur ? La tienne ou la mienne ? Si c'est la tienne alors tu feras un # ufw allow in 5800/tcp et # ufw allow out 5900/tcp Alors la, effectivement mieux vaut que tu es un bon mot de passe (pour les bruts force) . Pense à le changer très régulièrement
Comme j'essaye de te le faire comprendre, une station de travail n'est pas un serveur:)
Tu n'as aucun intêret à ouvrir un port entrant (sauf si ta machine devient un serveur... FTP, VNC etc etc). J'ouvre jsute le port 5900 en sortant et c'est tout. À partir de là et comme le montre les résultats d'un scan en ligne de Y316 ou le miens, nos machines sont indétectables
Tu noteras également que le résultat du scan est bien un port qui correspond à un service.
Premierement, il s'agit encore une fois de trafic entrant (serveur) donc interdit dans les 2 cas et deuxièmement un bon pirate aura profité d'inclure dans le .deb une commande pour ouvrir le port dont il a besoin
Tu veux dire pour écouter sur le port dont il a besoin ? Donc d'un programme vérolé:D
Imagines que M et Mme Michu installe un logiciel de dessin pour ses enfants qu'ils trouvent sur un site web mais que ce dernier (le logiciel de dessin) soit vérolé. Quand il exécute l'installation du programme, en arrière plan s'installe en même temps un serveur (porte dérobée) qui donnera un accès à la machine de M et Mme Michu sur le port (par exemple 1024) à leur insu ! C'est pour cela que tout bloquer en sortant et n'ouvrir que les ports essentiels peut les préserver:D
Évidemment, si le script exécute une commande en root pour ouvrir un port iptable, c'est cuît, mais cela est réservé à la cyber criminalité comme le vers stuxnet qui provient d'une organisation importante. Cependant, un pare feu matériel préserve de ces choses, les organisations sensibles ne se suffisent pas de iptable, un cisco n'est jamais loin
J'ai « tâtonné de l'administration » pendant 3ans sur un serveur (2ans OpenBsd et 1ans sous debian), des marlous j'en ai vu passé. Les mecs scannent des ports précis pour lancer un brut force (attaque par dictionnaire de mot). Par exemple, ils lancent un scan sur le port 1433 ce qui correspond à l'administration de SQL ( cette fonctionnalité est à l'origine prévue pour permettre le contrôle distant des bases de données par les véritables administrateurs... ), X machine seront présentes dans ses résultats. L'affreux tentera de se connecter avec user et mdp... S'il peine, il fera tourné un brute force. Quand il aura le bon user et mdp, il sera admin du serveur SQL . Toutefois un bon admin filtrera se port avec iptable (ou ufw) en entrant et ne laissera que quelque ip se connectées, les autres seront éjectées;)
Il conviendra à l'admin de vérifier ses configurations logiciels (de Apache et ses modules), les scripts php avec variables bien sécurisées et les doits d'écritures desdits scripts (ne pas donner les droits root 777 Et puis quelque bricoles de php comme le safe mode, les sessions, le module apache de php, les limitations!
Dans mon cas, j'avais réalisé un script qui éjectait pendant une heure l'ip qui échouait au bout de 10 tentatives de connexions (suspicion de brut force), si c'était récursif, je le shootais avec un fichier .htaccess qui est une arme de apache.
En revanche, l'acces à mon serveur ftp Ssl/TLS était filtré par le pare feu, je n'autorisais en entrant et sortant que certaines ip, les autres étaient directement rejetées ! Bien entendu, j'avais donné les droits adéquates en lecture et écriture sur mon serveur... Et l'authentification des ip autorisés se faisaient par une base de donnée mysql (user et mdp), chacun y avait un repertoire propre à son identifiant.
Dans le cas d'une station de travail, le pare feu bloqué en flux entrant et sortant avec quelques ports sortant filtrés est un excellent compromit, proche du risque zero, je maintiens !
Pour un serveur, le pare feu n'est qu'un moyen complémentaire de filtrage, la sécurité est assurée conjointement par les fichiers de configuration et le pare feu. Mais les intrusions proviennent bien souvent d'une mauvaise configuration d'un des module qui constitue un serveur web
Voici ma modeste expérience, ce n'est pas une vérité absolue. Je ne suis pas administrateur réseau mais les quelques connaissances que je possède proviennent d'un pro, donc je partage à des fins pédagogiques
Amitié.
Lorus.
Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.
Hors ligne
Bon ce n'est pas le sujet du post donc pour continuer à debattre sur le sujet, le mieux serait d'ouvrir un autre post wink
Au contraire c'est passionnant : après la technique de base, la stratégie; continuez je vous en prie.
( je fournirais le chocolat si modo affamé ...)
Modeste contribution au passage :
Alors la, effectivement mieux vaut que tu es un bon mot de passe (pour les bruts force) big_smile . Pense à le changer très régulièrement
je ne vois pas l'intérêt à changer un mot de passe sauf si l'on a constaté une intrusion ou si on l'a partagé avec quelqu'un.
Face à une attaque "nouvelle", le mot de passe est toujours "nouveau".
Mais j'ai installé fail2ban qui parait être une excellente parade à cette "force brute" qui, si on devait la prendre en compte, nécessiterait de changer son mot de passe aussi vite qu'elle ne les tente.
Debian 9 (stretch) + la pire ICC que vous ayez probablement jamais rencontré.
Hors ligne
( je fournirais le chocolat si modo affamé ...)
Ne te gêne pas, Noël arrive, miam miam
J'ai juste précisé que l'utilité d'un pare feu est différente entre une station de travail et un serveur.
Fail2ban lit les logs mais je ne connais pas. J'ai jamais tâtonné la bestiole Je préfère filtrer (avec ce que je connais: iptable) les ip ou dns entrants et rejeter tout(e)s les autres... Mais fail2ban doit être performant quand on le connait! Fail2ban pourrait faire l'objet d'un nouveau post, n'hésite pas.
Et un mot de passe se change très régulièrement.
Tschusss l'ami.
Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.
Hors ligne
Bloquer un port
# ufw deny port
Supprimer une règle
# ufw delete <règle>
Debian 9 (stretch) + la pire ICC que vous ayez probablement jamais rencontré.
Hors ligne
Au contraire c'est passionnant : après la technique de base, la stratégie; continuez je vous en prie.
Bon alors ..
Cela peut être vrai, tout bon administrateur changera le port d'écoute... Cependant je n'ai jamais réussi à modifier le port d'écoute pour une négociation SSL/TLS avec certificat ssl en 1024 bits d'un serveur ftp
Je te donne un exemple avec VNC, tu essaye de prouver que ce que je dis est faux avec FTP. ; mon exemple reste vrai avec un paquet d'autres services (ssh, apache, nginx, serveur pop, etc... ). De plus, mon propos etait juste de te prouver que les failles etaient relatives à un/des logiciels et non à un port.
Tu noteras également que le résultat du scan est bien un port qui correspond à un service.
Je n'ai jamais dit le contraire, mais ces services correspondent à un logiciel ou un ensemble de logiciels et les failles ne correspondent pas aux ports mais à des failles dans le(s) logiciel(s) qui fournit le service.
les failles peuvent êtres logiciel ou une mauvaise configuration dudit service
Le service étant fournis par un(des) logiciel(s), il s'agit donc d'une mauvaise configuration du(des) logiciel(s)
exemple d'un serveur utilisant plusieurs logiciel : LAMP
Dans le premier cas, une maj régulière prévient ce souci, dans le deuxième, une formation de l'admin les prévient également
Mefie toi encore des fausses impressions sécurité, que fais tu des failles zero-days et de l'intervalle entre le moment ou une faille est decouverte, rendu publique et patchée?
Qui te dis que ta formation est parfaite, on peut tres bien avoir mal compris un truc, ou bien avoir compris mais faire une erreur d'inattention, le risque 0 n'existe pas.
Ah vraiment ? Que de certitudes ! Que fais-tu de Apache, SQL , LDAP, SSH et autres babioles
Je te rappelle ta phrase :
à moins que le hackeur sélectionne directement un port précis et donc recherche une faille précise... dans son scanneur.
et je maintiens qu'on ne scan pas un port precis à la recherche d'une faille precise, les bestioles dont tu parle sont des logiciels qui peuvent contenir des failles. Quels que soit le port scanné, le/les logiciels ciblés peuvent contenir un paquets de failles.
D'ailleurs un scan de port en principe, c'est la première phase d'une attaque, ce qu'on appelle la détection d'hote, cette phase va pouvoir donner des information sur la/les cibles
On pourra ensuite utiliser ces informations pour réaliser une attaque.
Un scanner de faille automatise la recherche de faille sur un hôte
[ CENSURÉ PAR LES ADMINS ]
Désolé pour ce scan que je n'aurais pas dû faire, mais cibler DF me semblait plus parlant et plus percutant. A des fins d'apprentissage et pour être en conformité avec la loi, je le remplace par un scan d'un de mes serveurs persos sur mon réseau local. Il s'agit d'un serveur virtuel sous ubuntu 12.04 propulsé par apache sans aucune configuration particulière à part l'activation de https (fraîchement installé via apt-get)
Scan de port à l'aide de nmap - phase de detection de decouverte
Scan de vulnérabilité avec nikto
interessant non?
Vu qu'on a scanné le port 80, on trouve les failles d'apache (puisque c'est ce serveur qui est utilisé)et éventuellement des divers autre logiciels utilisés par le serveur. Comme je le disais, un seul port et plusieurs failles
pour info : OSVDB signifie Open Source Vulnerability Database, c'est une base de donnee opensource qui reference les failles de sécurités. On peut constater qu'apache en comprend un paquet , bon beaucoup de ces failles ne sont pas tres graves mais elles representent un risque potentiel pour la sécurité en donnant des informations sur le serveur.
Tu scannes une faille php sur quel port toi ?
Effectivement le service correspondant au port 80 est plutôt le serveur web lui-même(apache, par exemple) mais comme celui-ci permet d'utiliser php...
La faille OSVDB-12184 ( (c'est juste un easter-egg) est bien une faille php decelable sur le port 80...
Effectivement, php n'est pas associé au port 80, mais les echange en php entre le client et le serveur à travers les fichiers .php se font bien via le port entrant utilisé par le serveur web et le port sortant utilisé par le client web (ici, apache sur le port 80). De même pour SQL ou mySQL ou autre DB, même si l'administration de la DB se fait sur un autre port. Une faille dans le logiciel de DB (sql, mySQL, coucheDB, etc...) pourra être trouvé par son utilisation par le serveur web sur le port 80
Donc php est bien un script qui est généré sur le serveur.
Ouille ça pique!
php est un langage de programmation orienté web, php est donc un logiciel et non pas un script. Comme tout logiciel php peut avoir des failles
Les script php sont exécuté par php sur le serveur afin de génerer dynamiquement des pages web qui seront lisible par le client.
La plus part du temps, c'est le programmeur qui ne sécurise pas assez ses variables dans son scrip
Tout à fait, je n'ai pas dit le contraire, il s'agit là de faille dans les script php et non pas de failles dans php
Il existe des scanner qui teste les formulaires php présents sur le site,
a ton avis ce scan se fait sur quel port? Ben celui utilisé par le serveur web, donc le port 80 en standard ou 443 pour du https. Bien sûr, on peut tres bien configurer apache (ou tout autre serveur pour ecouter sur un autre port..)
Quel est la machine serveur ? La tienne ou la mienne ? Si c'est la tienne alors tu feras un # ufw allow in 5800/tcp et # ufw allow out 5900/tcp
Tu le fait expres??
Dans les 2 cas il s'agissait d'installer un serveur VNC sur les 2 machines et pour un serveur vnc, il n'y a jamais eu besoin d'ouvrir un port sortant, c'est un serveur enfin quoi
xvnc utilise le port 5800 par defaut alors que x11vnc utilise le port 5900 par défaut.
Le port sortant est à ouvrir sur le client et ce uniquement si le trafic sortant n'est pas autorisé
J'ouvre jsute le port 5900 en sortant et c'est tout
pour autoriser la connexion à un serveur VNC, tu ouvres un port sortant toi?
Bon ok les reverse connexion toussa, mais c'est pas le sujet...
u veux dire pour écouter sur le port dont il a besoin ? Donc d'un programme vérolé:D
Imagines que M et Mme Michu installe un logiciel de dessin pour ses enfants qu'ils trouvent sur un site web mais que ce dernier (le logiciel de dessin) soit vérolé. Quand il exécute l'installation du programme, en arrière plan s'installe en même temps un serveur (porte dérobée) qui donnera un accès à la machine de M et Mme Michu sur le port (par exemple 1024) à leur insu ! C'est pour cela que tout bloquer en sortant et n'ouvrir que les ports essentiels peut les préserver:D
Ta porte dérobée, c'est un serveur et il a donc besoin d'une connection entrante et non pas d'une connexion sortante en quoi interdire le trafic sortant protegerait M et Mme Michu dans ce cas?
ce qui les protege c'est d'interdire le trafic entrant!!!!
Évidemment, si le script exécute une commande en root pour ouvrir un port iptable, c'est cuît, mais cela est réservé à la cyber criminalité comme le vers stuxnet qui provient d'une organisation importante
Ben non, si le type t'as pondu un .deb, il te faudra passer root pour l'installer, un codeur pourra sans probleme en profiter pour rajouter une commande iptable au .deb.
Cependant, un pare feu matériel préserve de ces choses
Chez Mr et Mme Michu, le pare-feu de la box fait office de pare-feu materiel. Celui-ci autorise d'ailleurs tout le traffic sortant mais interdit par défaut tout le trafic entrant (comme la config par defaut d'UFW). Cest logique, à priori le poste de Mr et Mme Michu n'est pas un serveur...
C'est d'ailleurs parce que Mr et Mme Michu se trouve derriere cette box que le pare-feu est désactivé par défaut sur Debian. Utiliser conjointement 2 pare-feu ne presente pas beaucoup d'interet pour M et Mme Michu
Comme j'essaye de te le faire comprendre, une station de travail n'est pas un serveur:)
Tu n'as aucun intêret à ouvrir un port entrant (sauf si ta machine devient un serveur... FTP, VNC etc etc)
C'est exactement ce que j'ai dis. Tu n'ouvre un port entrant que si tu en as besoin, ce qui veux dire si tu as installé un serveur
Je te rappelle que ma configuration par défaut est d'interdire tout le trafic entrant !!!
Pour le trafic sortant, tu fais bien comme tu veux, ça n'a pratiquement pas d'incidence sur ta sécurité
J'ouvre jsute le port 5900 en sortant et c'est tout. À partir de là et comme le montre les résultats d'un scan en ligne de Y316 ou le miens, nos machines sont indétectables
J'obtiens le même résultat en désactivant UFW, normal je ne suis pas en DMZ et le pare-feu de ma Box est configuré pour ne rien laisser rentrer.
J'obtiens aussi le même résultat en mettant ma machine en DMZ et en activant UFW dans sa configuration par défaut, c'est à dire Par défaut : deny (entrant), allow (sortant)
Ton scanner de port ne teste que les ports ouvert dans le sens entrant sur ta machine et c'est logique, il ne teste pas ton trafic sortant
J'ai « tâtonné de l'administration » pendant 3ans sur un serveur
et tu n'as toujours pas compris la différence entre trafic entrant(serveur => servir du contenu) et trafic sortant (client => telecharger le contenu servi par le (s) serveur(s)/ uploader du contenu sur le(s) serveur(s)) ????
Bon, je n'ai surement pas ton experience, on va dire que je n'ai jamais vraiment taté d'administration de serveur, je bricole juste 2 ou 3 serveurs perso pour l'apprentissage depuis environ 5 ans...
Dans le cas d'une station de travail, le pare feu bloqué en flux entrant et sortant avec quelques ports sortant filtrés est un excellent compromit, proche du risque zero, je maintiens !
Je maintiens que bloquer le flux sortant sur une station de tavail chez un particulier ne présente quasiment aucun interet, à part peut être limiter le risque de participation d'une machine vérolée à un botnet (et encore)..
Interdire tout le trafic entrant, utiliser un mot de passe root fort, faire les mises à jour, ne pas activer de dépôts tiers, ni de dépots contenant des logiciels dont le code source ne peut être étudié (non free), ne pas installer de .deb trouvé sur le net, ne pas cliquer n'importe ou, installer les modules complementaires no-script, coockie monster et adblock
Voila, là, sur un poste client on s'approche un petit peu plus du risque zero et même sans interdire le trafic sortant, mais on n'est quand même pas invulnerable
Dans une grosse entreprise avec plusieurs poste en reseau, effectivement c'est une autre histoire. Mais une grosse entreprise à d'autres besoins en matiere de sécurité que Mr et mme Michu.
Dans une grosse entreprise, c'est plutot tout le reseau derriere pare-feu materiel et un proxy, , les services sont sur une DMZ. Tout est fermé en entrant et en sortant sur chaque poste client et on ouvre uniquement ce dont on a besoin.
je ne vois pas l'intérêt à changer un mot de passe sauf si l'on a constaté une intrusion ou si on l'a partagé avec quelqu'un.
Face à une attaque "nouvelle", le mot de passe est toujours "nouveau".
Ce n'est pas parce qu'il n'y a pas eu detection qu'il n'y a pas eu intrusion...
Fail2ban ne lit pas les logs.
Si, Fail2ban lit les logs
http://www.fail2ban.org/wiki/index.php/FAQ_french
dans l'exemple suivant, pourquoi les signes <> à règle et pas à port ?
Bloquer un port
# ufw deny port
Supprimer une règle
# ufw delete <règle>
C'est assez evident, tu ne peux pas supprimer les port, qu'il soit ouvert ou fermé, ils existent, ce que tu peux faire c'est supprimer la regle ufw qui ouvre ou ferme le port
Amitiés à tous, maintenant on passe au chocolat
Dernière modification par vince06fr (10-12-2012 12:36:19)
Hors ligne
Dernière modification par smolski (09-12-2012 22:55:48)
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Ta porte dérobée, c'est un serveur et il a donc besoin d'une connection entrante et non pas d'une connexion sortante en quoi interdire le trafic sortant protegerait M et Mme Michu dans ce cas?
ce qui les protege c'est d'interdire le trafic entrant!!!!
Oui pour un serveur mais si c'est un keylogger (le logiciel de dessin de mon exemple installe un keylogger), seul le port sortant importe, il enverra par exemple à des intervalles réguliers par email ou tout autre moyen, le contenu qu'il a capté sur le port n°xxxx à son/ses destinataires. Elle est autonome la bestiole. C'est pour cela que je maintiens qu'une station de travail doit être tout bloquant en entrant et sortant, avec ouverture du minimum sortant. Encore une fois ce n'est pas faux ce que tu écris pour un serveur, mais les malwares sont nombreux et différents! Un keylogger, tu le classes dans la catégorie serveur toi? Moi perso j'hésite... même si je dirais (conditionnel) que oui.
No souci, Jojo, planque là c'te boite
Bonne et belle journée à toutes et tous!
Lorus
Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.
Hors ligne
Je maintiens que bloquer le flux sortant sur une station de tavail chez un particulier ne présente quasiment aucun interet, à part peut être limiter le risque de participation d'une machine vérolée à un botnet..
C'est bien cela qui m'incite à suivre cette stratégie. Même s'il existe des "opérations" auxquelles j'adhèrerais volontier, je ne peux pas (veux pas) accepter le risque d'une utilisation malveillante.
Et si je veux proposer une utilité bienveillante (ne serait-ce que la mise à disposition de la puisssance de calcul car en bon michu je dois tourner aux environs de 15% d'usage des capacités matérielles), il faut, si j'ai bien compris, protéger le TOR avec raison.
.
.
informer librement et au plus près des méthodes d'intrusions utilisées
Bien évidement, c'est nécessaire. Comment se protéger sans connaitre l'attaque ?
Mais je ne me fais aucune illusion sur les posibilités d'intrusion des machines-michus pour des professionnels (comptons pour nous rassurer que ces intrusions sont aussi le fait de "polices" sinçères et intègres). Quand au matériel physique, je sais aussi que sans Mdp bios et chiffrage de DD, autant pisser dans un violon que parler sécurité.
.
.
si c'est un keylogger
N'est-ce pas là le principal souci d'un michu en matière d'attaque (après l'ICC) ?
Mon autre souci c'est d'avoir un modem. Beaucoup de commentaires et de tutos sous-entendent que l'utilisateur et derrière une box qui le protège.
Quelles précautions particulières à ce sujet ?
.
.
je ne vois pas l'intérêt à changer un mot de passe sauf si l'on a constaté une intrusion ou si on l'a partagé avec quelqu'un.
Face à une attaque "nouvelle", le mot de passe est toujours "nouveau".Ce n'est pas parce qu'il n'y a pas eu detection qu'il n'y a pas eu intrusion...
Oui mais le premier travail de l'intru sera certainement de s'attribuer sa propre clef.
D'où l'interet de chercher l'intrus qui squate en silence. : http://debian-facile.org/viewtopic.php?id=6272
Mais face à un nouvel intrus, le Mdp est toujours "nouveau", même s'il "attend le nouvel intrus depuis x temps".
C'est là où je vois l'intérêt de Fail2ban face à la force brute. (Merci pour le lien, je vois que je connaissais bien peu ce logiciel ...).
.
.
dans l'exemple suivant, pourquoi les signes <> à règle et pas à port ?
Bloquer un port
# ufw deny port
Supprimer une règle
# ufw delete <règle>C'est assez evident, tu ne peux pas supprimer les port, qu'il soit ouvert ou fermé, ils existent, ce que tu peux faire c'est supprimer la regle ufw qui ouvre ou ferme le port wink
J'ai beau consulter man ufw, je ne vois pas que "port" est une commande ou une option.
C'est donc une indication de ce qui doit être adapté selon la configuration recherchée (une variable)
Dans ufw delete <règle> je comprends que <règle> est une syntaxe que je dois remplacer.
si cela est vrai pour "port", il faudrait écrire : ufw deny <port> .
Dernière modification par Y316 (08-12-2012 13:00:22)
Debian 9 (stretch) + la pire ICC que vous ayez probablement jamais rencontré.
Hors ligne
si c'est un keylogger
Y316 a écrit :N'est-ce pas là le principal souci d'un michu en matière d'attaque (après l'ICC) ?
Mon autre souci c'est d'avoir un modem. Beaucoup de commentaires et de tutos sous-entendent que l'utilisateur et derrière une box qui le protège.
Quelles précautions particulières à ce sujet ?
Comme évoquer dans nos posts, le keylogger s'installer souvent via un logiciel attractif, si tu restes dans les dépôts Debian main, les chances sont nulles... par cette méthode en tout cas.
Tu as un pare feu d'activer sur ton pc et configuré de manière satisfaisante, tu es bien protégé
Bien sûr, à coeur vaillant rien d'impossible Ta box ferait la même chose, mais je dirais que pour un particulier et surtout pour un pc portable, l'activation d'un pare feu logiciel lui permet, lors de ses utilisations nomades (réseau wifi public) d'être convenablement protégé.
Mais face à un nouvel intrus, le Mdp est toujours "nouveau", même s'il "attend le nouvel intrus depuis x temps".
C'est là où je vois l'intérêt de Fail2ban face à la force brute. (Merci pour le lien, je vois que je connaissais bien peu ce logiciel ...)
Fail2ban lit les logs, sinon comment est-il possible qu'il détecte des tentatives d'intrusion?
Je t'avais juste répondu que je préferais gérer les accès distants critiques (base de donnée, ftp, ssh,) d'un serveur web avec iptable qui autorise que quelques ip (ou dns )et rejette toutes les autres.
Je préfère la restriction total (dans la mesure de mes connaissances) à un logiciel qui veille (au risque qu'un vilain pas bô le trompe?) pour moi. Dans mon exemple, j'avais développé un script php qui veillait aux tentatives de log de la partie admin de mon site (exemple http://lesite.fr/admin/login.php)...
Peut-être que fail2ban aurait été plus sécure, cependant, je préfère utiliser un outil que je connais bien pour gérer la sécurité
Hé Jojo, les papillotes chocolatées compte ou non?
Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Bon si c'est comme ufw que je croyais "activé", ça m'avance pas du tout ce truc, encore du boulot .... ah les s*.... !
Allez : courage joyeux libristes et tapons en coeur : : man rakakakunter !
Bon j'arrête l'aparté, Y'a risque d'apartheid !
J'ai aussi NoScript et Ghostery et puis clamav et je crois que j'en oublie.
sinon comment est-il possible qu'il détecte des tentatives d'intrusion?
C'est vraiment curieux cette différence de vues sur Fail2ban et le Mdp en général.
Quand on tente une connexion, légitime ou non, si l'on connait le Mdp, on passe.
Sans le Mdp, on tente une première fois un Mdp, c'est bien un couple qui est comparé (login et Mdp); la force brute consiste à répeter l'opération à des vitesses records avec des couples différents.
Simplement, Fail2ban détecte (par exemple) 2 rejets (paire invalide) et décide que la troisième tentative aura lieu seulement dans 1 minute.
Perso je trouve le principe, génialement ""humain"".
Cela ne dispense pas du parefeu et de la maintenance régulière et c'est seulement un "plus".
Comme tous les "plus", il a ses propres failles.
Debian 9 (stretch) + la pire ICC que vous ayez probablement jamais rencontré.
Hors ligne
Je vais ouvrir un post sur le sujet pour recueillir les avis ou conseil!
Allez hop là.
Amitiés.
Édit:
Je viens de voir ce post là : http://debian-facile.org/viewtopic.php?id=4262 , 'vais le lire.
Dernière modification par lorus (08-12-2012 17:28:07)
Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.
Hors ligne
\o/ Le closedSource c'est tabou on a viendra tous à bout \o/
Hors ligne
histoire de retrouver un port précis (j'ai une tête de linotte)
Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.
Hors ligne
\o/ Le closedSource c'est tabou on a viendra tous à bout \o/
Hors ligne