Le fil des beaux gosses linuxiens, v2 où comment installer LFS sur BTRFS en RAID10

[Guapo]

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 ?

[ursule15]

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.

[M0s]

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.

[ursule15]

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.

[Nattefrost]

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

[Rao]

c'est pas ce qui est décrit là :
https://superuser.com/questions/1037...s-on-nmap-scan
https://stackoverflow.com/questions/...on-of-a-second
??

Ou alors vos machines sont controlées par quelqu'un

[Wobak]

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

Edit: grillé.

[ursule15]

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).

[M0s]

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 :

"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?

[Wobak]

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

[M0s]

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.

[ursule15]

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.

[M0s]

Super, c'est exactement ce que je cherchais à savoir. Merci à toi également pour ces précisions bien utiles

[ducon]

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.

[Tilt]

Aucune idée ! un bench de chez unigine peut être ?
C'est l'occasion d'acheter une belle amd, genre une 570.

Sinon j'ai testé pleins de distributions et j'ai toujours fini par les péter au bout de deux mois maximum.
Y'a que ma archlinux qui tient !!

[2017-09-02 20:26] [PACMAN] synchronizing package lists
[2017-09-02 20:32] [ALPM] transaction started
[2017-09-02 20:32] [ALPM] installed linux-api-headers (4.10.1-1)
[2017-09-02 20:32] [ALPM] installed tzdata (2017b-1)
[2017-09-02 20:32] [ALPM] installed iana-etc (20170512-1)
[2017-09-02 20:32] [ALPM] installed filesystem (2017.03-2)
[2017-09-02 20:32] [ALPM] installed glibc (2.25-7)
[2017-09-02 20:32] [ALPM] installed gcc-libs (7.1.1-4)
[2017-09-02 20:32] [ALPM] installed ncurses (6.0+20170527-1)

Depuis septembre 2017 quand même et j'ai pas réussi à la crash bien que je sois suicidaire.
C'est que vraiment, archlinux c'est costaud pour que je n'arrive pas à la péter.

[ducon]

Ma Debian a plus de quinze ans.

[Tramb]

Ma Debian a plus de quinze ans.

Tu va bientôt pouvoir coucher avec elle (si tu n'es pas root, ce serait du détournement).

[Nattefrost]

J'ai réussi a péter du Ubuntu (desktop), openSuSe (desktop), Fedora (desktop), CentOS (serveur).
Les seules qui survivent à mes mauvais traitements et upgrades depuis > 2 ans (et encore je suis bien loin de la longévité de Ducon ) c'est ma debian (desktop) et FreeBSD (serveur).

[Tilt]

Ha debian j'en ai pété au moins 3....

[moimadmax]

Y'a t'il un moyen de voir en temps réél les fichiers créés par un processus, car j'ai mon client dropbox qui plante au démarrage (reste bloqué sur démarrage en cours) je voudrais savoir ou il écrit des données.
Car j'ai vu avec nmon et iotop que c'était lui qui grattait sur mon disque. Mais je ne sais pas où.

Merci.

[Mayalabielle]

Y'a t'il un moyen de voir en temps réél les fichiers créés par un processus, car j'ai mon client dropbox qui plante au démarrage (reste bloqué sur démarrage en cours) je voudrais savoir ou il écrit des données.
Car j'ai vu avec nmon et iotop que c'était lui qui grattait sur mon disque. Mais je ne sais pas où.

Merci.

lsof

[ducon]

Tu va bientôt pouvoir coucher avec elle (si tu n'es pas root, ce serait du détournement).

En fait, elle a un peu plus, j’ai trouvé un fichier de janvier 2002 dessus.

[M0s]

Hmm le premier truc qui me vient en tête comme ça c'est 'strace'. Même si c'est peut être un peu trop verbeux par défaut pour ce que tu cherches à faire.

Sinon je sais pas trop si c'est lié, mais ça pourra peut-être t'aider :

Since at least version 2.4.6 (see comments around 2013-11-06 on AUR), Dropbox has had an auto-update capability which downloads a new binary to the ~/.dropbox-dist/ folder. The service then attempts to hand over control to this binary and dies, causing systemd to re-start the service, generating a conflict and an endless loop of log-filling, CPU-eating misery.

A workaround is to prevent Dropbox from downloading the automatic update by creating the ~/.dropbox-dist/ folder and making it read-only:

$ rm -rf ~/.dropbox-dist
$ install -dm0 ~/.dropbox-dist

This appears to be necessary for modern Dropbox clients to operate successfully from systemd on arch.

Tiré du wiki de ArchLinux : https://wiki.archlinux.org/index.php...omatic_updates

En tout cas pour avoir testé sur Debian et Arch, je peux confirmer que le problème est présent sur les deux.

[moimadmax]

Merci pour votre aide, l'astuce si dessous n'a pas fonctionné. Par contre une fois le dossier supprimé, j'ai tenté de faire un
$ dropbox update
$ dropbox start

Et ça a fonctionné.
EDIT : Ben non ça re-merde ...

[Awake]

(Ubuntu 18.10)

Salut à tous, j'aurais besoin d'un peu d'aide et mon google-fu n'a pas donné grand chose... quelquechose (ou quelqu'un ) essaie de déverrouiller ma clef ssh. Il y a une fenêtre prompt qui me demande ma passphrase régulièrement (entre 5 et 20 minutes) depuis 3 jours. Pas d'installation de software ou de changement de config qui coïnciderais.

Un ps aux | grep ssh sort

jonathan 3809 0.0 0.0 5152 320 ? Ss 15:10 0:00 /usr/bin/ssh-agent /usr/bin/im-launch env GNOME_SHELL_SESSION_MODE=ubuntu /usr/bin/gnome-session --session=ubuntu
jonathan 11210 0.0 0.0 5152 1412 ? S 16:31 0:00 /usr/bin/ssh-agent -D -a /run/user/1000/keyring/.ssh

Cette clef sert uniquement à accéder à des serveurs ovh.

A l'aide, c'est pas bon pour ma paranoïa ce truc . Qu'est ce que je peux faire ?


-------

Edit : c'était simplement la maj PHPStorm 2019.1 qui essayait de se connecter au repo git tout seul une modif dans la config à régler le problème.

[wardog]

(Ubuntu 18.10)

Salut à tous, j'aurais besoin d'un peu d'aide et mon google-fu n'a pas donné grand chose... quelquechose (ou quelqu'un ) essaie de déverrouiller ma clef ssh. Il y a une fenêtre prompt qui me demande ma passphrase régulièrement (entre 5 et 20 minutes) depuis 3 jours. Pas d'installation de software ou de changement de config qui coïnciderais.

Un ps aux | grep ssh sort



Cette clef sert uniquement à accéder à des serveurs ovh.

A l'aide, c'est pas bon pour ma paranoïa ce truc . Qu'est ce que je peux faire ?


-------

Edit : c'était simplement la maj PHPStorm 2019.1 qui essayait de se connecter au repo git tout seul une modif dans la config à régler le problème.

les interfaces c'est pour les faibles...

[moimadmax]

Finalement pour mon problème de Drobox, j'ai juste supprimer le dossier .Dropbox et j'ai ré-associer mon compte et maintenant ça roule.
Je trouve bizarre que ça fasse cela en même temps que Dropbox impose une limite de 3 appareils associés.

[wardog]

Finalement pour mon problème de Drobox, j'ai juste supprimer le dossier .Dropbox et j'ai ré-associer mon compte et maintenant ça roule.
Je trouve bizarre que ça fasse cela en même temps que Dropbox impose une limite de 3 appareils associés.

moi c'est le fait qu'ils n'accepte plus des systemes de fichier autres que ext....
Du coup avec mon zfs je suis cuit pour dropbox. Tant pis, owncloud / nextcloud est mon ami.

[moimadmax]

C'est con qu'il n'y a pas de version raspberry pi (enfin ça existe peut être maintenant) car comme j'en ai un toujours allumé, et que pour l'utilisation que j'en fait je n'ai pas besoin de perf de ouf.
Ca me limiterai l'utilisation sur mes machines, car au boot il tape quand même pas mal sur le disque.

[moimadmax]

J'ai une question pour un adepte de cron
j'ai mis cela sur le crontab de mon user

* * * * * /home/matthieu/teleinfo/saveToDB.py
@reboot /home/matthieu/teleinfo/collectData.py
@reboot /home/matthieu/teleinfo/site.py

Le premier fonctionne mais pas ceux avec l'instruction reboot. Elle n'est peut être pas reconnu par cette version (3.0).

Sinon comment faire pour que ces 2 scripts s’exécute au démarrage ? Idéalement avec une redirection de leur sortie dans syslog.
Il me semble que j'avais déjà tenté dans le .profile sans succès.