Des logs très suspect

[Brun-Paul]

Bonsoir à tous,

Je viens vous voir, car depuis quelque temps, je retrouve dans mes logs des choses très étranges, je ne comprends pas tous, j’aimerais donc avoir vos avis …

Avant de vous expliquer, il faut comprendre que suite à un jeu célèbre sur console des gens mauvais joueurs s’en sont prit à mon cousin, et ont menacé de lancer une ddos s’il continuer de jouer, il a pas pris ça au sérieux et pourtant, ils ont trouvé notre ip et lancé une attaque … Confirmation faite également de notre opérateur qu’il s’agissait d’une attaque … Suite à ça ils ont essayaient de brute forcer mon service ssh sans succès.

Tout ça s’est passé fin 2017, je pensais donc qu’ils étaient passé à autre chose depuis longtemps …

Pour en revenir au présent, j’ai téléchargé il y a peu lnav qui m’a permit d’y voir un peu plus clair dans mes logs, j’ai aperçu un peu interloqué que plusieurs adresses avec en source mon ip local avaient comme destination des ip que je ne connais absolument pas, et apparemment des exceptions iptables ajouté pour contourner mon parfeu …

Voici un exemple des lignes en question ->;

Feb 8 18:52:45 kali kernel: [49095.405246] iptables: IN= OUT=wlan0 SRC=192.168.0.34 DST=91.224.149.41 LEN=76 TOS=0x10 PREC=0x00 TTL=64 ID=52441 DF PROTO=UDP SPT=55689 DPT=123 LEN=56

J’ai des dizaines et des dizaines de lignes comme ça toute avec des ip différents biens évidemment un d’entre elle est carrément un nœud de sortie tor …

J’ai beau bloquer les ip en question en ajoutant des règles iptables de nouvelles réapparaissent aussitôt …

Autre chose qui est bizarre, ces ip n’apparaissent dans mes logs que quand j’active mon script iptables qui a était prit sur ce forum --> Règles iptables pour vos applications (pc de bureau)

Je n’accuse bien évidemment pas l’auteur du script, c’est juste que je me demande pourquoi …
Certaine ip sont juste incompréhensible, elles me renvoient à des ip de chez amazon …

J’ai également activé wireshark sur une des ip inconnu, mais je ne sais pas à quoi correspond "retransmission " ?

Et dernière chose en ce qui concerne le fichier auth.log, j’ai complétement oublié ce que signifie ruser ?

Feb 3 13:29:31 kali polkit-agent-helper-1[24516]: pam_unix(polkit-1:auth): authentication failure; logname= uid=1000 euid=0 tty= ruser=root rhost= user=root

Et pour le suivant, c’est la première fois que je vois logname complété … Habituellement, il n’y a rien du coup idem je ne sais pas à quoi ça correspond

Feb 4 12:46:25 kali login[1758]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty3 ruser= rhost= user=root

Je vous remercie infiniment d’avance, car ça m’inquiète beaucoup et mes connaissances sont bien modeste pour que je puisse gérer ça tout seul.

[mattotop]

Bon, attends un peu avant de t’inquièter, je pense.

apparemment des exceptions iptables ajouté pour contourner mon parfeu

Qu’est ce qui te fait dire ça ?

kali kernel

Tiens, donc tu n’es pas sous debian.

J’ai des dizaines et des dizaines de lignes comme ça toute avec des ip différents

Oui, et en quoi est ce forcément anormal que tu envoies des paquets vers des sites dont l’ip ne te dit rien ?
Tu es bien obligé d’envoyer des paquets sortants aux sites que tu visites, pour surfer par exemple.
Il faudrait que tu précise tes règles iptables un peu pour qu’on comprenne en quoi ce sont des lignes bizarres.

J’ai beau bloquer les ip en question en ajoutant des règles iptables

Comment, précisément ? Quelle syntaxe ?

Règles iptables pour vos applications (pc de bureau)

Pourrais tu fournir le résultat d’iptales-save, quand ton parefeu est actif STP, ça peut aider.

[Brun-Paul]

@mattotop

Qu’est ce qui te fait dire ça ?

Pas grand chose en fait, simplement le fait qu’il y est marqué “iptables” à chaque début de ligne où une ip inconnu est présente, et que ces même ip ne font pas parti ni des exceptions d’origine du script ni d’exception que j’aurais pu ajouter.

Feb 8 21:26:58 kali kernel: [55081.546722] iptables: IN=wlan0 OUT= SRC=163.172.90.35 DST=192.168.0.34 LEN=389 TOS=0x00 PREC=0x00 TTL=53 ID=19│

Tiens, donc tu n’es pas sous debian.

Non, comme je l’ai signalé dans un autre post, je suis beaucoup sur root-me afin de continuer à apprendre, je trouvais donc sa logique d’avoir tout les logiciels nécessaire réunit, mais j’aime venir sur ce forum, car je suis attaché à la communauté, car c’est la première à m’avoir accueillit quand j’ai sauté le pas pour du Linux puis étant donné que c’est basé sur du debian et qu’en génèral mes questions concerne des spécificitées génèral à l’informatique et non à la distribution j’ai pensé qu’il n’y aurait pas de problèmes …

Oui, et en quoi est ce forcément anormal que tu envoies des paquets vers des sites dont l’ip ne te dit rien ?
Tu es bien obligé d’envoyer des paquets sortants aux sites que tu visites, pour surfer par exemple.
Il faudrait que tu précises tes règles iptables un peu pour qu’on comprenne en quoi ce sont des lignes bizarres.

Oui, je suis d’accord, mais j’ai pris soin de vérifier avant que les ip en question n’étaient pas des ip de site justement que je visitait, et il s’avère que non ,une d’entre elle est un nœud de sortie tor, d’autres sont des sites qui me sont totalement inconnu … Comme des site de peer-to-peer des serveur nginx etc …

Si par exemple, on prend l’ip que j’ai cité plus haut http://91.224.149.41/ on arrive à un serveur luna que je ne connais absolument pas … Si on prend une nouvelle ip bizarre qui vient d’apparaître car j’ai pour les besoins de cette réponse réactivé celui ci -->

https://163.172.90.35/ on arrive à une connexion avec un certificat auto signé que je ne connais pas non plus … Et c’est comme ça pour tout ces ip on arrive toujours à des sites que je ne connais pas que je n’ai jamais visité et qui ce retrouve pourtant dans mes logs … Encore un exemple ci dessous avec un noeud de sorti tor, alors que bien entendu je n’ai pas tor d’installé, je ne m’en sert pas … On voit pourtant que la source provient de mon ip local … Sans parler des trucs bizarre dans auth.log cité ci dessus que je n’explique pas non plus, après pour ce cas spécifique j’espère me fourvoyer, mais je ne peux me tromper sur tout je préférerais pourtant …

Feb 6 22:35:55 kali kernel: [ 4708.197470] iptables: IN= OUT=wlan0 SRC=192.168.0.34 DST=178.250.210.95 LEN=76 TOS=0x10 PREC=0x00 TTL=64 ID=26081 DF PROTO=UDP SPT=44708 DPT=123 LEN=56

Comment, précisément ? Quelle syntaxe ?

iptables -A INPUT -s adresses ip suspecte -j DROP et je fait la même chose pour l'output

Pourrais tu fournir le résultat d’iptales-save, quand ton parefeu est actif STP, ça peut aider.

# Generated by xtables-save v1.8.2 on Fri Feb 8 21:38:56 2019
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -s 193.105.197.0/24 -j DROP
-A INPUT -s 195.191.244.0/23 -j DROP
-A INPUT -s 193.107.240.0/22 -j DROP
-A INPUT -s 85.116.217.200/29 -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,PSH,URG FIN,PSH,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A INPUT -i wlan0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 3/sec -j ACCEPT
-A INPUT -i wlan0 -p udp -m limit --limit 10/sec -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i wlan0 -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -j LOG --log-prefix "iptables: "
-A FORWARD -j LOG --log-prefix "iptables: "
-A OUTPUT -d 193.105.197.0/24 -j DROP
-A OUTPUT -d 195.191.244.0/23 -j DROP
-A OUTPUT -d 193.107.240.0/22 -j DROP
-A OUTPUT -d 85.116.217.200/29 -j DROP
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 21 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 1023:65535 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o wlan0 -p udp -m udp --sport 68 --dport 67 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 995 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 465 -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT
-A OUTPUT -j LOG --log-prefix "iptables: "
COMMIT
# Completed on Fri Feb 8 21:38:56 2019

Je précise n’avoir rien touché au script initial trouvé sur ce site si ce n’est d’avoir ajouté les ip ci-dessus

[mattotop]

iptables -A INPUT -s adresses ip suspecte -j DROP et je fait la même chose pour l’output

Pas bon.
Ce que tu as montré comme logdrop dans ton premier post, ce sont des ip destination (-d) où partent les paquets et là, tu DROP les paquets qui ont les ip comme source (-s).

Bon, mais je crois que j’ai trouvé, je n’avais pas regardé le port destination…
Tu n’aurais pas installé un client ou un service ntp par hasard ?
Parce que le port destination des paquets que tu montre dans tes exemples, c’est le 123:
ça peut être un port utilisé par certains trojans, mais sous windows (jusqu’ici), sinon, c’est surtout le port du service ntp.

Tes messages sont donc juste des traces de ce service que tu as installé et que tu n’as pas autorisé à envoyer des paquets.
Mais quelle idée paranoiaque idiote de bloquer le trafic sortant:
ça ne protége pas contre les attaques, ça fait juste perdre quelques secondes à d’éventuels hackers qui voudraient faire sortir les données, mais ça ne les empêche pas de le faire (un bête scp vers chez eux et ça passe) et si ça les géne, c’est qu’ils sont déjà sur ta machine.

le résultat d’iptales-save

Aucune trace d’injection de règles “hackée”, tout est clean.
Ton script est parano, incroyablement chiant pour ce genre d’ajout de service, particulièrement s’ils utilisent des ports aléatoires (vas y amuse toi à faire fonctionner le ftp, tiens).
Mais il est propre.

[Mimoza]

Mais quelle idée paranoiaque idiote de bloquer le trafic sortant:
ça ne protége pas contre les attaques, ça fait juste perdre quelques secondes à d’éventuels hackers qui voudraient faire sortir les données, mais ça ne les empêche pas de le faire (un bête scp vers chez eux et ça passe) et si ça les géne, c’est qu’ils sont déjà sur ta machine.

C’est pas une idée déconnante, c’est même une bonne pratique pour un serveur. Tant qu’il ne sont pas root pour modifier les règles ça peux éviter plein de chose, genre SPAM, communication avec des services non autorisé, etc.

[mattotop]

C’est pas une idée déconnante, c’est même une bonne pratique pour un serveur.

C’est ce qu’on répète, mais jamais aucune explication ne m’a convaincu que c’était une bonne pratique, et ce n’est pas parce qu’il y a un million de gens qui y croient que c’est vrai.

ça peux éviter plein de chose, genre SPAM, communication avec des services non autorisé, etc.

Non.
Si ton serveur envoie du SPAM ou communique avec des services non autorisé, c’est que ta machine est déjà compromise.
Ca ne PROTEGE contre rien.
Par contre, je veux bien que ça permette de détecter des malware/spyware installés dans l’espace utilisateur, mais l’intéret est limité sur un serveur où il y a peu de chance que tu ailles choper une saleté en lisant ton mail ou en surfant.

[Mimoza]

Si ton serveur envoie du SPAM ou communique avec des services non autorisé, c’est que ta machine est déjà compromise.

On est d’accord, mais il y a plusieurs niveau de compromission.
Si l’intrus est entré par une faille d’un service web (Gitlab, Wordpress, …) ou autre, alors, si l’élévation de privilège n’est pas possible, il ne peux faire QUE des actions permises par l’utilisateur compromis (pas de modif de règles IPTables).
Si tu bloque le trafic a destination du port 25 tu évite d’être un spammeur, impossible pour le spam de quitter la machine.
Certains serveur C&C étant sur des ports exotique le malware peux aussi rester inactif.

Bref limiter le traffic en sortie est une sécurité limitée aux utilisateurs non-root compromis, pas plus.