Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 220 sur 220 PremièrePremière ... 120170210212213214215216217218219220
Affichage des résultats 6 571 à 6 584 sur 6584
  1. #6571
    Ca pourrait aussi être des ports qui sont ouverts temporairement par un serveur.
    Tu aurais peut-être des règles de type related or established qui permettent ça ?

  2. #6572
    Benh on a rien sur nos regles qui causent des ports 1 ou 2 ou 3 ou 4. Et ils se retrouvent "ouverts" certaines fois, d'apres nmap.
    Il semblerait quand meme que nmap ne soit pas deconnant... on a ce comportement sur environ 1% des serveurs... ca doit venir des serveurs.
    Et la plupart de ces serveurs (mais pas tous) sont dans un datacenter bien precis, qu'on utilise pas tellement.
    Je vais voir si un coup de tcpdump ne pourrait pas m'aider a y voir plus clair.

    ...Ca me rend fou ce truc.

  3. #6573
    Et le même problème revient même en testant avec plusieurs méthodes de scan différentes? Du style avec un "syn" scan (-sS) et un "connect" scan (-sT)?

    Sinon à part tcpdump tu as toujours la solution de lancer un "netstat -talpn" sur la machine cible si tu y a accès pour lister tous les ports en écoute et les processus qui les utilisent.
    Citation Envoyé par CaptainCheese Voir le message
    La légende dit qu'au plus profond de la forêt, un vieux panneau rouillé et branlant porte un nom maudit. Deux mots, écrits d'une main fébrile : LOS PELOS.

  4. #6574
    Oui, meme probleme avec des scans nmap -sS ou -sT.
    Et on a fait aussi le test avec netstat, on ne voit jamais les ports 1 ou 2 ou autre bizarrerie en ecoute (je prends ca en exemple, mais j'ai aussi selon nmap des 33354 ou autre 2099 ouverts).
    Les serveurs en question sont toujours a peu pres les memes... mais ca varie. Les ports exotiques sont toujours a peu pres les memes, mais ca varie.

    Je parle de tcpdump dans l'expoir de chopper un moment ou on a nmap qui fournit un resultat etrange (je peux restreindre a la liste de serveurs qui ont l'air plus a meme de donner ca).
    Et donc de regarder ce que donne le tcpdump au moment ou le nmap est farfelu. Et de voir si ca vient du serveur. En fait, ca ne va pas me donner grand-chose probablement... mais je ne sais plus trop quoi faire en fait
    Mais pour l'instant evidemment, a chaque fois, le nmap etait correct quand j'ai lance tcpdump.

    Ca me rend fou car je ne vois vraiment pas du tout ce qui peut produire ce resultat.

  5. #6575
    Aucune idée d'explication par contre quand tu la connaîtra n'hésite pas à partager, ta petite enquête m'intrigue !

  6. #6576

  7. #6577
    On dirait que y'a déjà eu un bug similaire dans le passé : https://stackoverflow.com/questions/...09841#28509841

    Edit: grillé.

  8. #6578
    Merci pour vos reponses.
    Mais oui, ca ressemble beaucoup a notre pb.

    Pour la petite histoire, un des gars de l'equipe avait identifie ce potentiel bug au debut de nos investigations, pour une raison qui m'echappe, ils n'ont pas fouille plus loin (je pense que c'est parce que ce bug est declare corrige).
    Je leur ai dit de tester avec une autre version de nmap - j'attends leurs resultats.

    edit:
    en fait la raison premiere pour laquelle ils ont ecarte ce bug, c'est que le pb ne se produit que sur certains serveurs. Et c'est vrai que du coup ca ne cadre pas trop avec le bug.
    Bref, on teste.

    edit2:
    on me fait aussi signe que ca ne correspond quand meme pas trop. Car un truc que je n'ai pas signale, c'est que certaines fois nmap ne remonte pas un port qui est rellement ouvert, comme par exemple port 22. De temps en temps... nmap ne le liste pas en port ouvert!
    C'est un cas plus rare que le precedent, je n'etais pas au courant.

    edit3:
    la commande map -sT --scan-delay 100ms <ip> donne visiblement les bons resultats tout le temps.
    Et concernant les tcpdump, resultats inattendus. Les paquets nmap generes partent bien en direction de tous les ports, mais arrivent sur la machine target sur le port 443.
    La machine target recoit donc un SYN 443, repond avec un SYNACK, et nmap finit avec un RST.
    Malgre ca, avec le delai comme indique au-dessus, le resultat semble correct (par contre, scanner des centaines de serveurs, ca prend du temps).
    Dernière modification par ursule15 ; 07/03/2019 à 17h13.

  9. #6579
    Je sais pas si c'est le bon topic pour poser cette question, mais vous arriverez sûrement à m'éclairer.

    Pour situer le contexte j'ai un serveur web (nginx) derrière lequel tourne une petite appli pour un usage perso. Et quand je regarde les logs, le trafic est constitué aux 3/4 par ce que qu'on pourrait appeler le bruit de fond d'internet :

    Code:
    "GET /db/webadmin/index.php?lang=en HTTP/1.1" 404 769 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
    "GET /db/dbweb/index.php?lang=en HTTP/1.1" 404 763 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
    "GET /phpmyadmin2019/index.php?lang=en HTTP/1.1" 404 775 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
    "GET /index.php?lang=en HTTP/1.1" 404 745 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
    "GET / HTTP/1.1" 200 4540 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64)"
    Au tout début j'utilisais fail2ban avec des regex spécifiques pour détecter les requêtes suspectes et bannir les ip associées. Mais aujourd'hui j'ai l'impression que ça demande beaucoup de temps et de ressources pour pas grand chose en fait. Puisque à part spammer les logs, dans mon cas elles sont inoffensives et génèrent une charge quasi nulle sur le serveur.

    Mais la question que je me pose c'est : Comment est-ce que vous gérez ce "bruit de fond" au quotidien dans un contexte professionnel? Est-ce que vous prenez des mesures actives contre ce genre de bots ou au contraire est-ce que vous considérez que c'est inutile de gaspiller du temps et des ressources à les détecter?
    Citation Envoyé par CaptainCheese Voir le message
    La légende dit qu'au plus profond de la forêt, un vieux panneau rouillé et branlant porte un nom maudit. Deux mots, écrits d'une main fébrile : LOS PELOS.

  10. #6580
    Firewall si tu connais tes sources IP, sinon solutions type fail2ban.

  11. #6581
    Merci pour ta réponse Wobak, mais en fait j'utilise déjà fail2ban pour filtrer les requêtes suspectes et ban les ip automatiquement via iptables.
    C'est plutôt une interrogation sur l'intérêt ou non d'appliquer un tel filtrage. Dans le sens où les bots qui constituent le "tout-venant" paraissent au final assez inoffensifs.
    Citation Envoyé par CaptainCheese Voir le message
    La légende dit qu'au plus profond de la forêt, un vieux panneau rouillé et branlant porte un nom maudit. Deux mots, écrits d'une main fébrile : LOS PELOS.

  12. #6582
    On a frequemment des regles qui vont bloquer sans log, pour gerer justement ce que tu appelles le bruit de fond.
    Il n'y a pas de reponse parfaite car avoir des logs pour tout peut rendre le systeme de log vulnerable a des attaques justement. C'est un truc que l'on voit certaines fois, quand les attaquants cherchent a dissimuler leurs traces en faisant un DoS sur les logs.
    Il y a une tech note de MS par ex qui explique qu'il ne faut pas tout logguer sur je ne sais plus quel systeme Windows.
    Mais d'un autre cote, on aime tout logguer. D'ou la reponse: il n'y a pas de reponse parfaite.

    Ca c'est ce qui se fait en entreprise.
    Pour un truc perso moi je ne logguerais pas le bruit de fond. Ca te permet de voir rapidement les trucs importants, car il n'y a pas d'equipe qui va travailler sur une revue des logs apres coup


    Et pour ceux qui veulent connaitre la suite des aventures de nmap, l'equipe fait une pause (comprendre on a d'autres trucs sur le feu).
    Mais c'est toujours dans leur backlog, je les remuerai un peu si besoin. Et je vous tiens au courant.

  13. #6583
    Super, c'est exactement ce que je cherchais à savoir. Merci à toi également pour ces précisions bien utiles
    Citation Envoyé par CaptainCheese Voir le message
    La légende dit qu'au plus profond de la forêt, un vieux panneau rouillé et branlant porte un nom maudit. Deux mots, écrits d'une main fébrile : LOS PELOS.

  14. #6584
    Avez-vous un indicateur de bonne santé d’une carte nVidia (une GTS 450) ?
    Je la soupçonne d’avoir du mal vu son âge canonique, je commence à avoir des plantages de X.org.
    une balle, un imp (Newstuff #491, Edge, Duke it out in Doom, John Romero, DoomeD again)
    Canard zizique : ?, , Φ, , ¤ , PL, 10h, , , , , , ?, , ?, ? ? ?, ?, ?, , , blues, BOF, BOJV, , ?, ?, 8, ?, ?, ?, 2, 80, ?, , , funk, fusion, ?, , ?, ?, ?, ?, ?, ? , noise, pop, , , $ $, , et ⚑, soul, , ?, (allez là si vous ne voyez pas les miquets)

Page 220 sur 220 PremièrePremière ... 120170210212213214215216217218219220

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •