sécurité, cherche moyen de choper intrus

Support Debian
#5

Merci fran.b pour les précisions sur w dans ubuntu, c’est dingue ce truc :confused:

$ apropos ^last$ ^w$ last (1) - Afficher une liste des utilisateurs dernièrement connectés w.procps (1) - Afficher les utilisateurs présents sur le système et leur activité
Si un script lance last et vérifie si il y a une nouvelle ligne depuis ton arrivée, ca peut t’aider ?

last | head pour voir les dernieres connection.

La partie 4.3 “détection d’intrusions” de ce cours de sécurité peut t’intéresser ?
http://www.inetdoc.net/guides/tutoriel-secu/

#6

debian.org/doc/manuals/secur … ion-detect

:116

#7

Ah ouai bien ton lien :slightly_smiling:
Du coup il parle aussi de prélude et snort, mais y’a des trucs sympas après !

Dis nous si tu vois ce que tu veux faire et si t’attaques un script Kriptec !
:041

#8

A la limite ce que tu cherche c’est à mettre en place une solution d’IDS, et ce genre de chose est relativement bien documenté sur la toile.

Plusieurs autre types existe chacun avec leur orientation spécifique :

Pas de traduction en français disponible si un courageux linguiste qui a un peu de temps à consacré à ça :wink:

[quote=“Wikipédia”]For the purpose of dealing with IT, there are three main types of IDS:

Network intrusion detection system (NIDS)
is an independent platform that identifies intrusions by examining network traffic and monitors multiple hosts, developed in 1986 by Pete R. Network intrusion detection systems gain access to network traffic by connecting to a network hub, network switch configured for port mirroring, or network tap. In a NIDS, sensors are located at choke points in the network to be monitored, often in the demilitarized zone (DMZ) or at network borders. Sensors capture all network traffic and analyzes the content of individual packets for malicious traffic. An example of a NIDS is Snort.

Host-based intrusion detection system (HIDS)
It consists of an agent on a host that identifies intrusions by analyzing system calls, application logs, file-system modifications (binaries, password files, capability databases, Access control lists, etc.) and other host activities and state. In a HIDS, sensors usually consist of a software agent. Some application-based IDS are also part of this category. Examples of HIDS are Tripwire and OSSEC.

Stack-based intrusion detection system (SIDS)
This type of system consists of an evolution to the HIDS systems. The packets are examined as they go through the TCP/IP stack and, therefore, it is not necessary for them to work with the network interface in promiscuous mode. This fact makes its implementation to be dependent on the Operating System that is being used.

Intrusion detection systems can also be system-specific using custom tools and honeypots.[/quote]

IDS, acronyme pour ( Intrusion Detection System ), Moi je me suis orienté vers OSSEC mais c’est très subjectif et sans doute que d’autre solution existe :033

A savoir que ce genre de produit est rarement offert, c’est un marché juteux ( a voir comment Snort est tronqué dans la version non payante ).

#9

Le lien que j’ai mis explqiue cela en français, et le lien donné par la personne après moi aussi :stuck_out_tongue:

http://www.inetdoc.net/guides/tutoriel-secu/

Ca présente prélude et snort.
Et Voila OSSEC en plus donc
Mais le cochon il a la classe !

#10

Salut,
Vos solution sont bonnes (encore que snort soit une machine à gaz pas très efficace à mon avis), mais vous parlez se stopper les intrus à priori.
Je préfère un bon fail2ban + portsentry sur quelques ports “clefs”.

A la question j’avais compris qu’il s’agissait de détecter à posteriori…

#11

Pourtant en entreprise, tout les IPS majoritairement utilisés sont des appliances à base de Snort (rebidouillé par les constructeurs ensuite, avec leur propres dépôts de signature) (Cisco, Juniper, Ibm,…)

#12

Il y a beaucoup de mélange de concepts dans ce fil!
SNORT s’utilise sur une machine différente de celle qu’on veut protéger, en protection amont.
La question de départ était de détecter une intrusion sur une machine, pas de l’empêcher.
Et comme l’a dit LoL, une fois compromise, c’est trop tard. L’intrus aura les moyens de faire sauter la protections.
On peux surveiller les fichiers critiques en enregistrant leur checksum, et en vérifiant régulièrement qu’ils n’ont pas changés (il existe plusieurs outils pour ça).
Ensuite pour ralentir la compromission, on peut mettre des systèmes avec gestion fine des droits pour chaque fichiers et chaque logiciel (par ex SE linux).
Mais ne confondez pas le blocage des intrusions, et la protection de la machine une fois la compromission amorcée, qui ne sert qu’a ralentir, ou tracer la compromission.
La meilleure protection reste la mise à jour régulière, et un mot de passe root en béton.

#13

Bonjour,

Un logiciel comme rkhunter permet de détecter les modifications de certains fichiers. En général, il me prévient de chose que j’ai fait moi même, mais ca me semble une bonne alerte.

Un logiciel comme fail2ban détecte des tentatives d’intrusion et bannit les ip soupçonnée (appel d’url, tentative de connection ssh de user non autorisé, erreur de saisie de mot de passe…)

Un logiciel comme logwatch fait un résumé de l’activité sur la machine (création de users, connexion des utilisateurs.

Un logiciel comme cron-apt permet d’être alerté en cas de mise à jour à faire.

Un logiciel comme monit permet de surveiller certain fichier et certain service. Il peut même relancer des services.

En gros, ca me permet de savoir qui se connecte (moi ?), qui essaye de se connecter (ils sont bannis) et qu’est ce qui change (c’est moi qui fait quelque chose ?)

Je jette de temps en temps un coup d’oeil aux log pour voir si je peux supprimer des messages en modifiant quelque chose ou si je doit bannir sur un message. Je fais des choses simple comme ajouter un favicon.ico ou un robots.txt pour éviter des erreurs 404 ou surveiller des appels d’url avec “wwOOtOO” pour les bannir 24H avec fail2ban.

#14

cette politique de sécurité est un minimum, mais ne protège que contre un intrus à gros sabots qui laisse des traces partout.
Un intrus compétent, efface ses traces au fur et à mesure (logs …).
Il faut éviter qu’il entre, pas d’autre solution!

#15

Merci de vos réponses.

Le but était de détecté l’intrus et de m’alerter.
Il serait primordiale d’empêcher l’intrusion, mais une fois l’intrusion réussi, je dois être au courant le plus rapidement possible et prendre des mesures.

Vos posts donnent pas mal d’idée/piste/suggestion, je vais faire des recherches approfondies.
Je vais démarrer un (gros) projet dessus (sur la protection avant-pendant-après les attaques), et normalement je partagerais cela plus tard dans un autre sujet.

#16

Je te signale juste l’existence d’un paquet surveillance (chez moi
deb boisson.homeip.net/debian squeeze divers
(ou etch, lenny, sarge, wheezy, etc…)
cf http://www.isalo.org/wiki.debian-fr/index.php?title=Surveillance
Tu peux t’intéresser à debsums qui est incomplet cependant.
Pense également aux processus cachés…

#17

Merci, je vais sûrement l’utiliser :023

#18

Il faut bien que tu comprennens que ce que tu cherches à faire ne t protègeras que contre les intrus à gros sabots (bots …).
contre un intrus aguerris, tu ne peux rien faire.
Par exemple en ce qui concerne le prog “surveille”

Un intrus expérimenté nettoie les email à root pur ne pas laisser de trace, ainsi que toutes les traces de sa connexion.
.
Mais bon, si détecter les intrus à gros sabot te suffit …
Il est à noté que ce sont aussi les plus facile à bloquer (exploitation de faille connues, et généralement corrigées par une mise à jour).
…

#19

Non, le mail est envoyé sur une adresse extérieure via les alias, il est absurbe de conserver les mails à root sur le serveur, ça n’a pas de sens. Le mail n’est donc pas interceptable. Individu expérimenté ou pas, dès qu’il modifie ton système, cela se repère et il est très dur de faire cela en un temps limité. Enfin si tu veux la protection à tout prix, tu mets les binaires de ton système sur un système de fichier en lecture seul avec éventuellement un système AUFS qui te permet de détecter le moindre changement et de revenir au système initial immédiatement. Sur un serveur mega-sensible, c’est ce que je ferais.

#20

Surveiller chaque fichier, c’est bien sur le principe, mais tu te retrouves vite coincé car certains logiciels ont besoin d’un accés en écriture sur leurs fichiers de conf. Et tu arrives à la conclusion qu’il vous contrôler qui est autoriser à écrire sur quoi. Et tu réinventes un système de type SELINX, avec toutes la complecité de paramètrage.

#21

Bonjour Fran.b,

ton script permet à n’importe qui de recalculer les hash ou il faut se munir d’un mot de passe ou d’un certificat pour le faire ? Je pense que l’idée est bonne à la condition que le prétentu “pirate” ne puisse pas lui même modifier les signatures.

Merci du retour.

SecuIP

#22

Le but est de trouver si la machine est corrompue. La corruption passe systématiquement par la modification de binaires existants ou le rajout de services au démarrage. C’est le principe. Les fichiers controlés par défaut sont ceux de /bin, /sbin, /usr/sbin, /usr/bin ainsi que les fichiers de démarrage /etc/rc*.d et /etc/init.d. On peut y rajouter les librairies, les scripts locaux. Une façon de contourner un système de ce type, quel qu’il soit, si on le connait consiste à bêtement remplacer le binaire par son propre binaire. Il faut donc relativiser ce genre de système et éventuellement en mettre plusieurs. L’intérêt de celui là est qu’il est peu diffusé et donc peu connu (550 chargement cette année). Quelqu’un de prévenu et qui a pu devenir root peut aussi reconfigurer le paquet (il suffit dans ce cas de virer /var/lib/dpkg/info/surveillance.postinst), etc. Il faut donc mesurer le degré de paranoïa voulu et adapter la configuration (celle choisie par défaut est assez lache). En serrant les choses (ce qui se fait simplement), on obtient un système difficilement contournable. Une bonne sécurité consiste à mettre les hashs sur un système en lecture seule (j’utilisais un clef USB en RO). Dans la mesure où les sources sont publiques, il est illusoire d’essayer de empêcher la surcharge du fichier contenant les md5sums par des certificats ou autres, si on admet que l’intrus a les droits root (à ce stade on est mal), il peut imposer ces propres certificats et surcharger le fichier des md5sums ou carrément modifier le binaire, la seule solution est la protection physique des fichiers. Si on ne veut pas le faire une astuce consiste à faire régulièrement un md5sum du fichier des md5sums et à le vérifier, mais ça devient pénible. Un système de sécurité trop pénible est toujours délaissé à un moment ou à un autre.

Encore une fois, pour une protection paranoïaque du système, il est à mon avis indispensable d’utiliser un système en RO plus AUFS (un peu comme clefagreg en fait quand j’y pense) qui opermet de voir immédiatement quel fichier a été modifié et de revenir à l’ancienne version.

Par curiosité, quel programme sur un serveur modifie ses propres fichiers de configuration? Sur aucun de mes serveurs le répertoire /etc n’est modifié par un programme (y compris /etc/resolv.conf, /etc/mtab, etc).

#23

merci pour cette réponse claire et détaillée.

:041

#24

tout récemment, en utilisant openzave, j’ai du autoriser le fichier en écriture. Je n’ai pas cherché pourquoi.
C’est le premier exemple qui me vient à l’esprit car le plus récent.