Discussion :

[titux]

Salut à tous.

Voilà la situation :
Jusque début août de cette année, j'hébergeais chez moi sur une machine qui me servait de serveur sous Debian Jessie un petit blog que j'avais codé en php/MySQL, un serveur mail et divers autres services.
J'ai un nom de domaine qui renvoie sur mon ip.
Début août, ce serveur a été compromis, mon serveur de mail a été détourné pour envoyer un mail accompagné d'une pièce jointe en .jar.
Je ne m'en suis rendu compte que le lendemain, en lisant les journaux système. Par la suite, voulant comprendre comment fonctionne cette crasse, j'ai cherché un peu partout dans cette machine ce qui avait été fait.
Mes maigres compétences ne m'ont permis que d'extraire le mail envoyé et situer l'heure et la date de lancement de cette crasse, ainsi que la porte d'entrée : le blog que j'ai codé avec les pieds
Ce mail se fait visiblement passer pour un émis par une banque située à Dubaï. Donc j'ai éteint mon serveur et extrait le disques.

Ensuite j'ai remarqué que sur mon poste fixe qui tourne également sous Debian Jessie sur un SSD, sous Iceweasel, à chaque connexion à un site en https il m'était demandé d'accepter un nouveau certificat ssl d'une validité de 3 ou 4 mois, de mémoire.

Par la suite, pendant 15 jours j'ai eu beau me faire des réinstalls fraîches de Debian Jessie sur de nouveaux disques mécaniques sur mon poste fixe en tentant à chaque fois d'élever ma sécurité malgré mes maigres compétences en sécu via OSSEC et autres, je me suis fait pourrir mes installs, probablement par un bot. Sur plusieurs disques fraîchement installés sous Jessie quoi que je configure comme sécu, mon disque commençait au bout d'un temps variable à se remplir. Une fois le disque plein, au reboot, machine bloquée par manque de place. Pendant ces 15 jours, je loggais mon trafic avec wireshark et conserve ces captures dans des fichiers sur une clé usb.
Mon interprétation est probablement fausse mais je me souviens avoir vu passer sous wireshark des paquets RST en relation avec le port 443 juste avant que mon disque se remplisse, je ne peux que supposer l'utilisation d'une faille d'iceweasel à propos de laquelle j'avais lu quelques articles autour de cette période. Cependant, vu que je suis une quiche en réseau, ça vaut ce que ça vaut...

J'ai fait un signalement de ceci par mail à la cyber-gendarmerie de Rosny sous bois, qui en réponse m'invitait à déposer plainte. Je n'en ai pas eu le temps, j'ai dû m'absenter jusqu'il y a 1 mois.

Voilà.

Revenu depuis 1 mois, je pense qu'il est trop tard pour un dépot de plainte. J'aime pas l'idée que le mec derrière tout ça s'en sorte comme ça, mais c'est probablement trop tard.

Ce matin j'ai appelé OVH, qui est mon FAI, en souhaitant changer d'ip, malheureusement c'est impossible. Dans un premier temps, quand ma nouvelle installation sera faite, je modifierais la config de mon domaine, qu'il ne pointe plus chez moi. Je pense qu'il est référencé quelque part comme étant "fragile". Je ne le ferais que depuis ma nouvelle installation car j'ignore si l'actuelle est sécure ou pas...

Je souhaite maintenant m'attacher à relever mon niveau de sécurité et mes connaissance associées.
Pour parer au plus pressé, en revenant le mois dernier, j'ai réinstallé une debian Jessie sur mon SSD, configuré iptables, portsentry, installé chkrootkit, rkhunter et clamav.
Maintenant je m'apprête à refaire toute l'installation de mon poste fixe à partir de 0, et aimerais avoir votre aide pour le sécuriser correctement. Pour le serveur, je verrais plus tard, il est éteint.

Mes Questions :

Tout d'abord, aux outils iptables, portsentry, chkrootkit, rkhunter et clamav, je pensais ajouter fail2ban et OSSEC. Selon vous y a-t-il des outils autres qui pourraient m'être utile ?
Pour ce qui est de la structure de mon réseau : ma tour est connectée en ethernet directement sur ma box. Dois-je revoir ce point ?
J'envisage dans un avenir plus ou moins loin de remiser ma box OVH et investir dans un matériel sur lequel je puisse flasher un OpenWRT ou assimilé, à condition que ce soit possible dans la config OVH...
A priori, sur ma box il n'y a que 3 niveaux de réglage pour le parefeu : Désactivé, Standard (trafic entrant bloqué) et Tout bloquer. Pour le moment je suis en Standard.
Niveau mots de passes, j'envisage 10 ou 12 caractères minimum, alphanumériques, caractères exotiques et minuscules majuscules, comme souvent recommandé.
Sous Debian, quels services désactiver ? Je me sers de mon poste principalement pour surf, mail, irc, un peu de dev C/C++ à l'avenir, films/musique. Jusqu'aujourd'hui j'utilisais iceweasel (firefox) , icedove (thunderbird), kvirc, codeblocks, Vlc.

Par la suite, j'aimerais apprendre un minimum sur les réseaux et la sécu.
Pour le moment, je ne compte dans ma bibliothèque que le Tannenbaum sur les OS que je n'ai pas encore terminé.
Par la suite je pensais à des bouquins type le Pujolle sur les réseaux, le TCP/IP guide, le cahier de l'admin Debian.
Connaitriez-vous d'autres bouquins qui pourraient être indispensable ?

Enfin, niveau légal, je souhaitais connaitre d'après vos expériences la conduite à tenir dans le cas où ce genre de choses recommencerait.
J'ignore comment procéder, je débranche tout, extrais mes disques pour les transmettre aux autorités ? ou y a-t-il quelques recherches à faire avant, un dossier à établir ?

Pour conclure, je suis vraiment profondément gonflé que mes coordonnées informatiques soient associées à cet envoi de crasse sur les mails de personnes qui ont probablement eues des soucis. J'ai lu il y a des années que l'illusion de la sécu est pire que l'absence de sécu, je le savais et je me suis planté, raison pour laquelle je dois tout remanier... Cependant, c'est pas parce qu'ont voit une porte ouverte dans la rue, qu'on doit entrer et aller coller des crasses. J'abhorre ces mecs.

Merci à tous
Titux.

Je joins ma config iptables actuelle qu'on peut très certainement améliorer...
Config associée à iptables-persistent.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
 
/etc/iptables/rules.v4
 
*filter
:INPUT ACCEPT [727:573164]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [691:56160]
 
#  Allow all loopback traffic. Drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT
 
#  Accept all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
#  Allow all outbound traffic
-A OUTPUT -j ACCEPT
 
#  Uncomment the next two lines to allow HTTP and HTTPS connections
-A OUTPUT -p tcp --dport 993 -j ACCEPT
-A OUTPUT -p tcp --dport 465 -j ACCEPT
-A OUTPUT -p tcp --dport 6667 -j ACCEPT
 
 
#  Allow SSH connections. If you changed your SSH port, do same here.
#-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
 
#  Allow ping
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT
 
#  Log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
 
#  Drop all other inbound - default deny unless explicitly allowed policy
-A INPUT -j DROP
-A FORWARD -j DROP
 
COMMIT

[LittleWhite]

Bonjour,

Je n'ai que de maigres connaissances sur ce niveau, mais les bases (pour moi), sont :

• interdiction d'avoir une session root à travers SSH (dans le fichier de configuration de SSH, le root ne doit pas avoir le droit de se logguer) ;
• fail2ban obligatoire pour éviter les attaques par dictionnaire et autre bots qui cherche à s'infiltrer par SSH ;
• mettre à jour les logiciels (plateforme de blog, serveur mail et ainsi de suite) ;
• utiliser des mots de passe forts et surtout un mot de passe fort pour le root (mais c'est valable pour tout les utilisateurs) ;
• si c'est une Raspberry Pi, il faut faire attention, il y a une mise à jour qui remet un compte par défaut actif (avec mot de passe par défaut). Ceci est bien sur à desactiver ;
• avoir un système qui envoie un email lorsqu'il y a trop de requêtes (que ce soit par les formulaires du blog, ou sur SSH), ça permet d'avoir un rapport d'une attaque en temps réel (et d'avoir des infos dessus).

Pour le remplissage du disque c'est bizarre. N'est ce pas vos captures Wireshark qui le remplissait ?
Sinon, après une attaque il faut voir les logs, voir les historiques dans le terminal (normalement supprimé, mais ne sait t-on jamais ), voir ce qui a été installé, voir les nouveaux fichiers créer ou modifier et ainsi de suite.

[titux]

Bonsoir et Merci LittleWhite d'avoir pris le temps de me répondre.

Suite à cette attaque j'avais en tête de mettre en place tout ceci. Sauf le dernier point auquel je n'ai pas pensé.

Dans cette optique j'ai passé une partie de la journée à réinstaller et configurer ma machine (iptables, portsentry, chkrootkit, rkhunter, clamav, fail2ban et OSSEC).
Je suis sorti faire une course puis en rentrant, impossible de surfer. Après avoir redémarré, même topo disque rempli et impossible de lancer KDE. Wireshark n'a pas tourné aujourd'hui.
Je commence à me demander si ce ne serait pas la config de OSSEC que je faisais toujours en suivant le même tuto, même ce matin qui pouvait le faire planter ou provoquer un comportement erratique.
Simple supposition.

J'ai donc réinstallé ce soir avec une config minimum pour OSSEC, on verra.

Encore Merci

à bientôt.

[vinced86]

Bonjour,
J'ai rédigé un petit tuto afin de sécuriser l'accès SSH à un serveur:

http://journaldunadminlinux.fr/tutor...son-acces-ssh/

En espérant que cela te soit utile.

[chrtophe]

Je rajouterais qu'on peut aussi ajouter l'utilisation du port knoking

[disedorgue]

Bonjour,

Quelles sont tes besoins sur tes machines ?

Si tu es capable de tout lister, il suffit de sécuriser toutes les "applications" pour les besoins de cette liste...

Exemple:
Un serveur qui ne fait que du blog avec une techno du genre "Apache+php", il suffit de mettre en cage l'utilisateur système de apache et php. Comme ça, dans le cas d'une compromission de cet utilisateur par une erreur de code php ou autre, le "pirate" ne pourra pas avoir accès à autre chose que ce compte.

Pour le ssh, peut-être ne permettre qu'une ou 2 adresse IP à y avoir accès et que celui-ci ne puisse pas se loguer sur "root".

[titux]

Hello

Désolé pour la faille spatio-temporelle. J'avais complètement oublié ce topic

Après pas mal de péripéties, je repars de 0.

J'envisage de refaire la totalité de mon réseau. Pour le moment j'ai une config minimale, box et pc portable en eth.
Je me suis rendu compte il y a qques jours que la plupart de mes soucis semblent en fait lié à mon Disque 2To de données.
A chaque nouvelle installe, je le rebranchais et me retrouvais avec un spam-bot. Là j'ai refait une installe sans le brancher pour le moment et tout semble clean. On dirait qu'il est infecté.

Pour le moment il est démonté mais à terme, j'aimerais remonter mon serveur pour en faire un IPS et/ou IDS et/ou firewall avec VPN. J'ai déjà investi dans 2 cartes réseau PCI-Express à installer dessus. Je pensais utiliser le 2 cartes réseau pour le traffic et la carte réseau de la CM du serveur pour l'interface de config, avec possiblement un Snort dans LXC/OpenVZ ou du genre (si vous connaissez mieux... ) et avec une copie externe des journaux, on verra par la suite si je me relance dans l'auto-hébergement.

Pour ce qui est de mes besoins applicatifs :
PC Portable réservé au dev électro/info, irc, un poil de bureautique au cas où.
PC Fixe un peu de jeu pas bien gourmand (Q3, Urban Terror...) en local ou en ligne, bureautique, regarder/écouter film ou musique, dev électro/info ? mais ça nécessiterait un serveur git sur mon serveur.

Merci à tous pour vos infos, je vais regarder tout ça

Edit : histoire de savoir ce que je fais, je me suis payé 2 bouquins "Les réseaux" de Pujolle et "Systèmes d'exploitations" de Tannenbaum, me reste à les terminer, voyez-vous d'autre bouquins qui me seraient utiles ?