Bonjour, J'ai eu cette nuit la désagréable surprise de recevoir un mail automatique de mon hébergeur. Mon serveur serait apparemment à l'origine d'une attaque vers d'autres machines. Dans ce contexte, ils ont passé mon serveur en accès restreint pour la nuit. Contactés aujourd'hui, je viens de récupérer le plein accès mais aimerait comprendre comment cela a pu arriver et savoir si je peux encore sécuriser ou si c'est trop tard et dois repartir sur une install "propre". Je ne met pas l'IP ou l'extrait de log reçu pour l'instant mais au besoin je le ferais passer en MP. Je ne sais pour le coup pas trop où chercher sur le serveur ni de quelles infos vous avez besoin donc je reste ouvert à la discussion Merci d'avance

Salut, Malheuresement le plus serieux serait de repartir sur une install propre. Si tu ne t'y connais pas trop, il est compliqué de nettoyer a 100% une install qui a était infecté. Les intrus ont pu placer plusieurs backdoor et effacé certain accès pourrait ne pas servir a grand chose au final. Par contre, il serait bien de s'assurer qu'il y a eu intrusion, pour cela, peut tu nous dire qu'elle système de sécurité avais tu mis en place a la base ? Merci.

Je vais essayer mais étant donné que le serveur tourne depuis plus d'un an comme une horloge et que j'ai installé des trucs au fur et à mesure, j'espère que ma mémoire ne va pas me jouer de tours. La base du serveur est basé sur le script Bonobox Rutorrent qui filtre déjà pas mal via Fail2Ban. J'avais par la suite installé PeerGuardian pour filtre par plage ip / pays mais c'était trop instable, je suis donc revenu à IPTables qui marchait très bien. Pour monitorer tout ça, un Webmin et Logwatch qui ne m'ont rien remonté d'alarmant ces derniers mois. Le moteur web est Nginx. Apparemment l'attaque est parti du port 80.

Salut Le plus courant, c'est souvent en rapport avec un cms pas super à jour et/ou des plugins pas top, soit mal foutu/soit obsolète aussi. T'avais un wordpress ou autre ? Si oui faut vraiment être au taquet dessus et limiter les plugins au minimum vital pour être tranquille. J'ai morflé un jour avec un joomla, j'ai compris la leçon depuis.................... Ex.

Du tout, pas de CMS. Il y a sur le serveur 💯 Un rutorrent Un plex Un plexpy Un Webmin Un TS Un Sickrage Un Owncloud Un serveur Ark En dehors du rutorrent, rien de "sensible" selon moi; je comprend vraiment pas comment cela a pu arriver vu que je fais assez gaffe à la sécu quand même.

Et ton hébergeur ne t'as pas donner plus d'information ? C'est peut être eux qui se sont trompé dans leur diag ... Si tu as quelques logs qui te semble suspect à partager ce serait bien. (tu peux virer ton ip des logs).

Je les a eu au téléphone ce matin et "ils ne peuvent pas me donner l'intégralité du log, juste l'extrait présent dans le mail". En substance, ça donne : Votre serveur XXX représentant une trop grande menace pour notre réseau, nous n'avons eu d'autre choix que de le placer dans le mode 'rescue FTP'. Un identifiant et un mot de passe vous ont été communiqués par email afin que vous puissiez récupérer simplement vos données encore présente sur son espace de stockage. N'hésitez pas à vous rapprocher du support technique afin que cette situation ne devienne pas critique. Vous pourrez retrouver ci-dessous les logs remontés par notre système qui ont conduit à cette alerte. DEBUT DES INFORMATIONS COMPLEMENTAIRES - Attack detail : 15Kpps/7Mbps dateTime srcIp:srcPort dstIp:dstPort protocol flags bytes reason 2016.10.31 02:08:22 CET IP: PORT Serveur 209.10.41.84:80 (je sais pas ce que représente cette ip) TCP SYN 60 ATTACK:TCP_SYN La même ligne une 20 aine de fois FIN DES INFORMATIONS COMPLEMENTAIRES -

bah deja as tu laisser root en connexion par MDP ? si oui c'est pas bien As tu des mots de passes forts sur tes comptes user ?

Oui, c'est pas bien j'avoue, mais si il y a une méthode pour changer ça, je suis preneur (et si il n'est pas trop tard) Tous les mots de passes sont complexes et relativement aléatoires. Rien qu'un brute force pourrait trouver facilement

pour le root, perso j'utilise un certificat SSH, ce qui fait que j'ai pas besoin de MDP, mais sans ce certif impossible de se co, mais les plus extrême desactive purement et simplement le ROOT en SSH

Il me semble avoir vu passer à l'époque un tuto de sécurisation poussé, je jetterai un oeil. La j'aimerai surtout savoir si je peux continuer à fonctionner comme ça ou si je dois tout réinstaller, et si c'est bel et bien le cas, aller pleurer un peu, parce que j'ai vraiment pas envie de me refaire l'install d'owncloud >_<

Serveur "Piraté" : Page 2

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Serveur "Piraté"

Nono

jean-luc Iptables, quasiment aucune règle, mis à part pour obliger de se connecter sur le 80 ou le 443 via le domaine et non l'ip

Salut,
Tu peux les poster car les recherches que j'ai faites me donne plutôt des règles pour interdire des domaines;
Merci

jean-luc

Nono
Salut;
Les voici:

#!/bin/bash
echo 1 > /proc/sys/net/ipv4/ip_forward
systemctl stop fail2ban.service
systemctl stop portsentry.service
netfilter-persistent flush
iptables -F
iptables -X
ip6tables -F
ip6tables -X
##########@hadopi-tmg
iptables -N LOG_BANNED
iptables -A LOG_BANNED -j LOG --log-prefix '** BANNED HADOPI **' --log-level info
iptables -A LOG_BANNED -j DROP
IPS="65.81.86.128/29 66.212.230.112/28 74.63.108.0/22 74.63.120.0/23 74.63.122.0/24 74.63.123.0/25 74.63.123.128/28 74.63.123.144/30 74.63.123.148/31 74.63.123.150 76.73.14.0/23 76.73.16.0/23 81.210.17.240/29 82.138.70.128/26 82.138.74.0/25 82.138.81.0/24 82.138.88.0/22 85.233.218.96/27 88.191.92.0/23 88.191.201.0/24 88.191.202.0/23 88.191.204.0/23 88.191.206.0/24 88.208.202.0/30 88.208.202.4 88.208.236.12/30 88.208.236.16/29 91.189.104.0/21 94.23.100.208/28 94.23.103.176/28 94.23.103.192/28 94.23.113.160/28 94.23.113.176/28 94.23.113.208/28 94.23.117.128/28 94.23.117.144/28 94.23.117.160/28 94.75.223.176/28 94.75.229.208/28 130.117.41.0/24 130.117.115.128/25 149.6.80.196/30 149.6.114.136/30 149.7.96.128/25 154.45.216.128/25 193.105.197.0/24 193.107.240.0/22 194.119.136.116/30 195.101.90.136 195.102.95.128/26 195.191.244.0/23 199.125.208.0/24 207.86.66.192/27 210.7.70.20/30 212.200.44.128/25 213.17.245.32/30 218.103.89.88/29 90.80.100.192/28 195.5.217.72/29 5.23.42.12/30 194.79.189.240/29"
for ip in $IPS; do
iptables  -I  INPUT  -s   $ip   -j LOG_BANNED
iptables  -I  OUTPUT  -d   $ip   -j LOG_BANNED
done
###########@connexion par domaine: xxx.xxx.xxx.xxx = ip du serveur
iptables -I INPUT -d xxx.xxx.xxx.xxx -p tcp --dport 80 -m string --to 700 --algo bm --string 'Host: xxx.xxx.xxx.xxx' -j DROP
iptables -I INPUT -d xxx.xxx.xxx.xxx -p tcp --dport 443 -m string --to 700 --algo bm --string 'Host: xxx.xxx.xxx.xxx' -j DROP
#####goip basée sur ce tuto :https://terminal28.com/how-to-block-countries-using-iptables-debian
iptables -N LOG_BANNED_GEOIP
iptables -A LOG_BANNED_GEOIP -j LOG --log-prefix '** BANNED GEOIP **' --log-level info
iptables -A LOG_BANNED_GEOIP -j DROP
iptables -A INPUT -m geoip --src-cc CN,TW,HK,ID,IN,KH,KP,KR -j LOG_BANNED_GEOIP
iptables -A INPUT -m geoip --src-cc LA,MO,MY,PH,RU,VN,TH,MM,UA -j LOG_BANNED_GEOIP
########
#vpn
iptables -I FORWARD -i tun0 -j ACCEPT
iptables -I FORWARD -o tun0 -j ACCEPT
iptables -I OUTPUT -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 172.16.8.0/24 -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -p tcp --dport 51411 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 51411 -j DNAT --to 172.16.8.5:51411
iptables -A FORWARD -i eth0 -p tcp --dport 51412 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 51412 -j DNAT --to 172.16.8.5:51412
iptables -A FORWARD -i eth0 -p tcp --dport 50401 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 50401 -j DNAT --to 172.16.8.9:50401
iptables -A FORWARD -i eth0 -p tcp --dport 50402 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 50402 -j DNAT --to 172.16.8.9:50402
iptables -A FORWARD -i eth0 -p tcp --dport 29561 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29561 -j DNAT --to 172.16.8.9:29561
#############
iptables-save >/etc/iptables/rules.v4
ip6tables-save >/etc/iptables/rules.v6
systemctl start fail2ban.service
systemctl start portsentry.service

A++

Hardware

C'est possible aussi que ton serveur n'ait pas été compromis, tu peux faire du SYN flood de manière involontaire en ouvrant un trop grand nombre de connexion sur un serveur distant, c'est arrivé quelque fois à des membres à cause de la fonctionnalité de découverte réseau (GDM) de Plex.

Selon ton hébergeur, tu as fait du SYN flood vers un ou plusieurs serveurs de gracenote.com, utilises-tu ce service ? J'imagine que oui, ton Plex doit requêter Gracenote pour récupérer les informations de certains médias, peut-être que tu as trop de médias ou qu'il faudrait réduire l'interval de mise à jour de ta librairie ?

Plex :

For Plex Pass subscribers, we've added data from Gracenote, the leader in music metadata, recognition, and discovery technologies, with metadata for more than 200 million tracks. We've also added Gracenote's sonic fingerprinting capabilities to ensure we accurately identify music in your library, and download rich information and high resolution artwork. Regardless of the original source and associated tags (or lack thereof), songs can be appropriately identified.

Je te conseil de monitorer ce que ton serveur envoie vers 209.10.32.0/20 (annonce de l'AS40913, Gracenote semble être hébergé chez QTS) sur le port 80 avec un tcpdump par exemple :

tcpdump -i eth0 host 209.10.32.0/20 and port 80

Donc pas besoin de remettre à zéro ton serveur, dans un tel cas ce n'est pas vraiment nécessaire puisque c'est toi qui "attaque" un serveur externe involontairement 😉

http://www.gracenote.com/
https://support.plex.tv/hc/en-us/articles/205568637-Overview-of-Premium-Music-Libraries

Nono

Ok merci je vais regarder ça

edit: c'est nickel 😃

kolgate

Le syn_flood comme ça n'est pas forcément une compromission mais peut-être un attaque en miroir. Mais la plupart du temps pour les bots c'est dû à un trop grand nombre de requête sur où de ton serveur. Le bot d'hetzner me détecte souvent puis après vérification me dis "oups pardon " donc...

Oppenheimer

Bonjour à tous,

Désolé de ne répondre que maintenant, j'ai été un peu pris.

Ce que tu écrit me rassure un peu Hardware, et je vais regarder du côté des réglages de Plex, sachant que j'ai une très grosse librairie Plex mais que je n'utilise pas Gracenote de façon "manuelle".

La requête que tu m'a suggéré me renvoi : tcpdump: Mask syntax for networks only

Bien que ton post m'ai rassuré, j'ai cependant remarqué un truc ce matin en regardant en détail mon log Logwatch :

Dans les requests with error response codes :

   http://ip/2phpmyadmin/: 4 Time(s)
   http://ip/MyAdmin/: 4 Time(s)
   http://ip/PMA/: 4 Time(s)
   http://ip/admin/db/: 4 Time(s)
   http://ip/admin/phpMyAdmin/: 4 Time(s)
   http://ip/admin/phpmyadmin/: 4 Time(s)
   http://ip/admin/sqladmin/: 4 Time(s)
   http://ip/admin/sysadmin/: 4 Time(s)
   http://ip/admin/web/: 4 Time(s)
   http://ip/db/: 4 Time(s)

Et la liste se poursuit. Cela pourrait-il être une attaque ?

Hardware

Oppenheimer je ne suis pas certain de la syntaxe de tcpdump, regarde le manuel. Sinon Gracenote n'est pas utilisé de manière manuelle, c'est Plex qui l'utilise en interne pour gérer ta bibliothèque. Je vois 3 solutions pour éviter que ton problème se reproduise :

Désactiver Gracenote au sein de Plex (aucune idée de la faisabilité)
Bloquer les IPs de Gracenote avec Iptables (pas très propre)
Réduire le délai de mise à jour de ta bibliothèque musicale

Je pense que la 3ième solution est la meilleur, il me semble que Plex a prévu une option à activer lorsqu'il a trop de musique à traiter.

Pour logwatch c'est rien comme l'a dit ex_rat, pas d'inquiétude à avoir.

ex_rat

Salut
Pour logwatch c'est rien. C'est juste des bots qui tapent au hasard ça, c'est habituel

kolgate

Hardware Normalement par defaut cela ne scanne pas la musique en cas de scan générale à moins que tu coche l'option.

Oppenheimer

C'est ce que je voulais dire par Manuel Hardware, je n'avais pas sciemment tenté d'accéder au site 🙂.
En effet, Plex est configuré par défaut pour faire une mise à jour nocturne de la bibliothèque. Vu que j'ai d'autres sources, j'ai désactivé Gracenote dans Plex pour voir si le problème se reproduit ou non. Après en toute logique, je ne vois pas en quoi un hacker aurait intérêt à utiliser mon serveur pour Syn Gracenote; à mon avis c'est juste Plex qui a débloqué...

Silence radio du côté de mon hébergeur d'ailleurs. Le prix est très correct, la qualité du serveur encore plus, mais ils sont un peu à la ramasse >_<

kolgate

Pour le syn flood sinon :
http://www.tux-planet.fr/contrer-une-attaque-ddos-de-type-syn-flood-sous-linux/
+ iptable et normalement c'est bon.

Oppenheimer

Je viens d'appliquer l'ensemble du tuto (modification du noyau + iptable).

Merci beaucoup pour le lien à la fois très intéressant et très utile. Je vais surveiller tout ça de près

« Page précédente