3 votes

Méthodes alternatives de détection de Linux pour détecter un hôte compromis

Il s'agit d'une réécriture de mon message précédent, car ce que j'essayais de faire n'était pas tout à fait clair. J'espère que cela aura plus de sens :)

En bref, ce que je recherche, ce sont des méthodes alternatives pour détecter si mon système est compromis au-delà de l'utilisation d'outils tels que tripwire/OSSEC/samhain/rkhunter et de la simple vérification générale de l'intégrité des fichiers et de la surveillance des journaux. J'essaie délibérément de ne pas être trop précis dans ma question car je cherche des idées en général pour pouvoir les mettre en œuvre sur ma propre machine. Ce sera probablement, mais pas limité à un script qui est exécuté à intervalles fixes (cronjob) et notifie l'administrateur si quelque chose a changé et invite un administrateur à enquêter davantage via (syslog / e-mail ?). Notez que je ne suis pas nécessairement après le code lui-même juste un aperçu de haut niveau de ce qu'il fait. N'hésitez pas à être aussi verbeux que vous le souhaitez.

Je peux vous donner une idée générale des idées que je recherche en énumérant les choses que je fais actuellement.

1) Générer un md5sum de la sortie de mon iptables en cours d'exécution et le comparer à un bon hash connu. Si cela change, on peut supposer que quelqu'un a ajouté/supprimé une entrée iptables.

2) J'ai certains points de montage qui sont en lecture seule (/usr, /boot etc.) parce qu'ils ne devraient pas changer très souvent. Si une partition passe de lecture seule à écriture, je veux en être informé.

3) Surveillez la sortie de netstat pour les services d'écoute uniquement. Effectuez une comparaison de fichiers (diff) par rapport à un fichier contenant de bonnes valeurs connues. Si quelque chose a été ajouté, il est possible que quelqu'un ait ajouté un nouveau service au système. Une porte dérobée possible ?

Notez que ce qui précède va générer des faux positifs si je fais de la maintenance système. Cependant, si ces données changent alors que je ne suis pas en train de le faire, je les considèrerais comme suspectes et j'enquêterais davantage. Notez qu'il ne s'agit que d'exemples et qu'il y a des défauts comme partout, mais plus il y a d'obstacles, plus les chances que quelqu'un trébuche sont élevées.

Merci d'avance.

0voto

Ali Mezgani Points 3770

Vérification de rootkit avec rkhunter ou chkrootkit

0voto

Curtis Tasker Points 169

Vous pouvez essayer Zabbix pour les services, la surveillance des journaux, l'intégrité des sommes de contrôle des fichiers et bien plus encore. Il est assez facile à installer et à configurer. Vous pouvez avoir besoin de le personnaliser pour vos besoins en ajoutant des logiciels tiers.

0voto

ComSubVie Points 1181

Je travaille beaucoup sur le projet OSSEC et je sais qu'il peut résoudre vos problèmes. Il n'est pas prêt à l'emploi, mais avec un peu d'ajustement, il fonctionnera.

Section 1 : Générer un md5sum des tables ip

L'une des nouvelles fonctionnalités d'OSSEC est le rapport sur la différence de la sortie de commande. Pour cela, il suffit d'ajouter ce qui suit dans votre etc/ossec.conf

<ossec_config> 
    <localfile> 
        <log_format>command</log_format>
        <command>iptables -L -n</command>
    </localfile>
</ossec_config>

Ensuite, créez une règle locale comme la suivante

<rule id="98989" level="10">
    <if_sid>530</if_sid>
    <match>ossec: output: iptables -L -n</match>
    <check_diff />
    <description>Change made to iptables</description>
</rule>

Pour plus de détails, voir http://www.ossec.net/doc/manual/monitoring/process-monitoring.html

Section 2 : avoir certains points de montage qui sont en lecture seule

Actuellement, rootcheck effectue quelques vérifications simples à cet effet, mais il est facile d'ajouter les vôtres.

Créez d'abord un fichier de politique de vérification des racines dans etc/shared/ pour cet exemple, je vais le nommer unix_mount_policy.txt avec le contenu suivant.

# This will make sure that the OS this file is used for pilicy is running redhat 
# and it should be changed for your environment 
[Policy - Check OS] [any required] [http://intranet.example.com/location/of/policy]
f:/etc/redhat-release -> r:^Red Hat Enterprise Linux \S+ release 5;
f:/etc/redhat-release -> r:^CentOS && r:release 5.2;

# First real rule
# This will alert if /usr does not have ro on the same line 
[Policy - Mounts read only] [any] [http://intranet.example.com/location/of/policy/readonly]
f:/etc/fstab ->  !r:^# && r:/usr && !r:ro

Section 3 : Surveiller la sortie de netstat pour les services d'écoute seulement

rootcheck exécute déjà cette fonction, mais si vous voulez voir si quelque chose change en utilisant le journal de sortie commun de ma réponse dans la section 1, cela devrait être très simple à configurer.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X