Être prévenu d'une intrusion : possible ?

Je ne suis pas sûr que le sujet n’ait pas déjà été abordé et je vais ptet être obligé de m’engueuler :smt093
Sous Mandriva, ou iptables est installé d’office, chaque fois qu’il y a un essai d’intrusion, on est prévenu de l’intervention du firewall.
existe-t-il qq chose de semblable à installler sous Debian ?

bonjour,
firestarter, interface graphique d’iptables, comporte un onglet “évenements” où sont recensées les “connexions bloquées”, avec des infos du style protocole, service, destination, source … etc … Lorsqu’une connexion est bloquée, l’icône de firestarter dans la barre des tâches voit sa couleur passer de bleu à rouge , c’est un indicateur. Mais est-ce efficace et complet, no le sé …

Si je puis me permettre, j’ai deux ou trois petites choses à ajouter :

  • La probabilité que tu subisses une attaque réelle à partir d’un post linux client est quasi nulle… donc installer une firewall n’est pas vraiment utile.

  • Si tu veux installer un firewall pour un serveur, l’interface graphique ne te servira pas vu que tu n’es pas sensé être devant 24h/24, en revanche tu peux installer un système de mailing qui t’envois un rapport journalier de ton serveur vers ton client.

  • La plupart des gens qui disent s’être fait “attaqué” ou “hacké” ne se sont en fait que retrouvé dans une rangée d’ip qui a été scannée, et le firewall lui a alarmé l’utilisateur. En fait, la plupart des firewall sous windows par exemple emulent l’activité d’un troyan sur un port, du coup, lorsque les utilisateurs se retrouvent scanné, leur firewall les alerte et eux se sentent “protégés”, pensent que leur firewall leur est vraiment utile alors que ça n’est que de la poudre aux yeux. C’est pour cette raison que je suis parfaitement contre ce type de softs sous windows.

Tout ça pour dire que pour un particulier (qui n’utilise son poste qu’en client), qui plus est sous linux, l’utilisation d’un firewall “clef en main” est à mon avis totalement inutile. Je pense que commencer par suivre les règles élémentaires de sécurité est déjà un très bon début.

réponse du lien que tu donnes :

[quote]Décider quels sont les services dont vous avez besoin et vous limiter à ceux-là. Ceci inclut la désactivation ou la désinstallation des services indésirables et l’ajout de filtres de type pare-feu ou de tcpwrappers.
[/quote]
Celà dit, le lien est super mais il est fait pour les paranos car si tu fait tout ce qu’ils disent, tu n’as m^ plus le tps de faire de l’informatique mais seulement celui de gérer ta machine. :cry:

Usinagaz, je ne connaissais pas ce parefeu graphique sous Debian et je tenterais bien de l’installer seulement, j’ai une question préalable :
J’ai déjà configuré iptables selon la méthode simple décrite ds T&A.
Je voudrais être sûr qu’il ne va pas y avoir de conflits ???

bonjour,
ricardo, j’ai aussi suivi la Méthode de config de T&A pour iptables, je me suis aussi posé cette question … c’est une bonne question :unamused:
Je rappelle que firestarter n’est que l’interface graphique de ton iptables, voir de ton fichier de config iptables (mon_parefeu, parefeu tout court, chez moi); c’est à dire que au lieu d’ouvrir un port en ligne de commande comme tu montrais l’exemple, tu l’ouvre par click et renseignement de champs.
Apparemment, pas de conflit, j’ai toujours mon fichier parefeu d’origine, tel que tu la donné en exemple, quand aux manip d’ouverture de ports en ligne de commande, je pense qu’elles ont été modifiées oui …

jcode@debian:~$ locate parefeu /etc/config_parefeu /etc/init.d/parefeu /etc/rc0.d/K21parefeu /etc/rc1.d/K21parefeu /etc/rc2.d/S19parefeu /etc/rc3.d/S19parefeu /etc/rc4.d/S19parefeu /etc/rc5.d/S19parefeu /etc/rc6.d/K21parefeu j’ai maintenant ceci.
/etc/init.d/parefeu, c’est le fichier de T&A, inchangé.
/etc/config_parefeu, voici son contenu, je le mets ici en espérant que vous me direz si vous voyez un trou, un truc pas prudent :

[code]# Generated by iptables-save v1.3.3 on Thu Aug 10 16:48:13 2006
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

Completed on Thu Aug 10 16:48:13 2006

Generated by iptables-save v1.3.3 on Thu Aug 10 16:48:13 2006

*nat
:PREROUTING ACCEPT [17:824]
:POSTROUTING ACCEPT [421:19697]
:OUTPUT ACCEPT [421:19697]
COMMIT

Completed on Thu Aug 10 16:48:13 2006

Generated by iptables-save v1.3.3 on Thu Aug 10 16:48:13 2006

*mangle
:PREROUTING ACCEPT [16598:4112683]
:INPUT ACCEPT [16598:4112683]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [16773:1279362]
:POSTROUTING ACCEPT [16769:1279202]
COMMIT

Completed on Thu Aug 10 16:48:13 2006

Generated by iptables-save v1.3.3 on Thu Aug 10 16:48:13 2006

*raw
:PREROUTING ACCEPT [16631:4115580]
:OUTPUT ACCEPT [16808:1281577]
COMMIT

Completed on Thu Aug 10 16:48:13 2006

[/code] car j’ai du mal avec tout ça encore … ce fichier semble actualisé à chaque ouverture de session, tous les jours .
Quant aux fichiers dans rcx.d, je sais pas trop à quoi ils correspondent, mais par exemple le dernier, K21, c’est une copie de /etc/parefeu.
Tout ce que je peux dire, c’est que :

  • je n’ai pas noté de conflit, ni de difficultés à configurer firestarter
  • je n’ai pas l’impression que ce que j’avais fait en ligne de commande en suivant Installation parefeu (iptables) de T&A constituait des règles de parefeu, puisque dans les régles (firestarter), aucune n’était spécifiée.
    Ceci dit, il y a un paquet de fichier pour firestarter :

[code]jcode@debian:~$ locate firestarter
/etc/firestarter
/etc/firestarter/configuration
/etc/firestarter/events-filter-hosts
/etc/firestarter/events-filter-ports
/etc/firestarter/firestarter.sh
/etc/firestarter/firewall
/etc/firestarter/inbound
/etc/firestarter/non-routables
/etc/firestarter/outbound
/etc/firestarter/sysctl-tuning

/etc/firestarter/user-post
/etc/firestarter/user-pre
/etc/init.d/firestarter
/etc/ppp/ip-up.d/1firestarter
/etc/rc0.d/K20firestarter
/etc/rc1.d/K20firestarter
/etc/rc2.d/S20firestarter
/etc/rc3.d/S20firestarter
/etc/rc4.d/S20firestarter
/etc/rc5.d/S20firestarter
/etc/rc6.d/K20firestarter
/usr/sbin/firestarter
/usr/share/doc/firestarter
… etc …
/usr/share/doc/firestarter/README
/usr/share/doc/firestarter/TODO
/var/lock/firestarter
[/code]
Voici quelques liens pour la config de firestarter :
wiki.alionet.org/doku.php?id=firestarter
doc.ubuntu-fr.org/applications/firestarter

heu, tu plaisantes j’espère … je serais curieux de savoir combien d’utilisateur debian, pour ne citer qu’eux, tournent avec un noyau dont iptables n’est pas activé …

[quote=“nuitnOire”]… C’est pour cette raison que je suis parfaitement contre ce type de softs sous windows.
[/quote] heu … oui mais on est pas sous windows ici … et moi je me laisse penser qu’un systême windows sans firewall, c’est comme une femme à poil dans les rues de téhéran … lapidée … ou dans les ruelles sombres du Bronx …

Il y a eu une discussion récemment sur le sujet, que je n’ai pas encore assimilée, jettes y un oeil peut-être : forum.debian-fr.org/viewtopic.php?t=3872
ps: m’étonnerait qu’on aie discutté plus de 4 pages d’une chose qui n’existe pas … si ?

J’ajoute que dans règles élémentaires de sécurité sous debian

[quote=“règles élémentaires de sécurité sous debian”]1.5 Éléments restant à écrire (FIXME/TODO)
De plus amples informations concernant les rustines spécialisées dans la sécurité du noyau dans Debian, incluant celles montrées ci-dessus et ajouter des informations spécifiques sur la façon d’activer ces rustines dans un système Debian.
Linux Intrusion Detection (kernel-patch-2.4-lids) ;
Linux Trustees (paquet trustees) ;
NSA Enhanced Linux ;
kernel-patch-2.2.18-openwall ;
kernel-patch-2.2.19-harden ;
kernel-patch-freeswan, kernel-patch-int.
[/quote] il est clair que les intrusions préocuppent certains concepteurs debian.

je suis en train de lire ceci, qui est loin d’être hors-sujet :

[quote=“Honey Net Project”]
Par exemple, disons qu’un utilisateur a un outil qui pourrait exploiter imap sur des systèmes de Linux, comme imapd_exploit.c. D’abord, ils développeraient une base de données d’adresses d’IP qu’ils pourraient scanner (càd les systèmes qui sont allumés et accessibles). Une fois que cette base de données d’adresses d’IP est faite, l’utilisateur voudra déterminer quels systèmes utilisent Linux. Beaucoup de scaanners aujourd’hui peuvent facilement déterminer ceci en envoyant des mauvais paquets à un système et en regardant comment ils répondent, comme le nmap de Fyodoror. Ensuite, ces outils vont déterminer lesquels de ces systèmes Linux utilisent imap Tout ce qui reste à faire maintenant est d’exploiter ces systèmes vulnérables.

Vous pourriez penser que faire tous ces scans serait très peu discret, que cela attire beaucoup l’attention. Cependant, beaucoup de gens ne surveillent pas leurs systèmes, et ne réalisent pas qu’ils sont en train d’être scannés. De plus, beaucoup de script kiddies recherchent tranquillement un système isolé qu’ils peuvent pénétrer. Une fois qu’ils ont pénétré un système, ils utilisent maintenant ce système comme plate-forme de lancement. Ils peuvent sans problème scaner tout le net sans crainte de se faire prendre. Si leurs scans sont détectés, c’est surtout l’administrateur système et pas le hacker qui sera concerné.[/quote]

il semblerait que psad que je vais tester ( et snort, à voir) soit le genre d’outils utiles pour détecter les intrusions … à voir, j’ai installé psad en testing ( “curieusement” moins de bugs qu’en sarge, avec tout les pkg recommandés et suggérés, notamment bastille). Avec un pti préalable :

Paramétrage de psad (1.4.6-1) ... ERR: Syslog has not been configured to send messages to /var/lib/psad/psadfifo. Please configure it as described in psad(8).

[quote=“man psad”]psad Syslog needs to be configured to write all kern.info messages to a
named pipe /var/lib/psad/psadfifo. A simple

          [code]echo -e 'kern.info\t|/var/lib/psad/psadfifo' >> /etc/syslog.conf[/code]

   will do. Remember also to restart syslog  after  the  changes  to  this
   file.

[/quote][code]# echo -e ‘kern.info\t|/var/lib/psad/psadfifo’ >> /etc/syslog.conf

/etc/init.d/sysklogd restart[/code]Je lis le man, mais si quelqu’un connait bien psad, il pourrait nous expliquer les options principales et la config … je nage un peu là …

un exemple :

[code]# psad -A
[+] Entering analysis mode. Parsing /var/log/messages
[+] Found 184 Netfilter messages out of 2870 total lines.
[+] Processed 10 packets.
[+] Processed 20 packets.
[+] Processed 30 packets.
[+] Processed 40 packets.
[+] Processed 50 packets.
[+] Processed 60 packets.
[+] Processed 70 packets.
[+] Processed 80 packets.
[+] Processed 90 packets.
[+] Processed 100 packets.
[+] Processed 110 packets.
[+] Processed 120 packets.
[+] Processed 130 packets.
[+] Processed 140 packets.
[+] Processed 150 packets.
[+] Processed 160 packets.
[+] Processed 170 packets.
[+] Processed 180 packets.
[+] Assigning danger levels.
[+] Writing /var/log/psad/ipt_analysis/ directories.
[+] Displaying status output.

[No scans detected]

Netfilter prefix counters:
    "Inbound": 140
    "Outbound": 45

Total scan sources: 0
Total scan destinations: 0

Total packet counters:
    tcp: 185
    udp: 0
    icmp: 0

[+] Finished --Analyze cycle.
[/code]
J’ai eu un message de log :

à suivre …[quote]localhost: psad: config warning; the HOME_NET variable has not been set; defaulting to a single interface config for signature matching[/quote], alors j’ai modifié :

[quote="/etc/psad/psad.conf"]

Specify the home network. This variable is used to identify

traffic that matches snort rules in the iptables FORWARD chain.

Traffic that is directed to, or originates from, the firewall

itself (i.e. in the INPUT or OUTPUT chains respectively) is

treated as traffic to or from the HOME_NET by default and hence

even if the HOME_NET variable is not defined, psad will still

be able to detect matching scans. A syslog and email warning

message will be generated if this variable is not defined.

Normally the network(s) specified here should match a directly

network(s) on the local machine. Multiple networks are supported

as a comma separated list. The network(s) should be specified

in CIDR notation. The following two lines provide example

definitions for the HOME_NET variable. NOTE: The HOME_NET

variable is not used if there is only one network interface on

the system (i.e. no traffic will be logged via iptables through

the FORWARD chain). If there is only one network interface on

the box, then just set this variable to “NOT_USED”.

HOME_NET 192.168.10.4/24;

HOME_NET 10.1.1.0/24, 192.168.10.4/24;

HOME_NET NOT_USED; ### only one interface on box

HOME_NET 192.168.1.x;### mon unique interface, je commente ?

[/quote] en décommentant la ligne not_used …
Ce passage aussi [quote]### Set the interval (in seconds) psad will use to sleep before

checking for new iptables log messages

CHECK_INTERVAL 5;[/quote] donc psad tourne en daemon, pourtant on a une option --no-daemonn pour recevoir l’alerte sur stdout:

[quote=“man psad”]–no-daemon
Do not run psad as a daemon. This option will display scan
alerts on STDOUT instead of emailing them out.
[/quote] C’est mieux d’être alerté dans un terminal toujours ouvert que par mail, non ? mais je comprend pas, il reste en daemon là pourtant… :confused:

puisqu’il est question de [size=125]Système de Detection d’Instrusion[/size] (IDS), psad, c’est un N-IDS ou un H-IDS ?

[quote=“ricardo”]
Celà dit, le lien est super mais il est fait pour les paranos car si tu fait tout ce qu’ils disent, tu n’as m^ plus le tps de faire de l’informatique mais seulement celui de gérer ta machine. :cry:[/quote]
:laughing:
Tres bien résumé.
La sécurité a un cout proportionnel au cout des informations à sécuriser. Roh elle est pas mal cte phrase, je vais la noter tiens :slightly_smiling:
Et
Seuls les paranos survivront
:slightly_smiling:

edit:
snort non, un honeypot(net) non. C’est à la mode, les gens arrivent sur linux la premiere chose qu’ils veulent faire c’est installer snort pour espionner les chtis n’hacker… zont vraimment que ca a foutre les gens.
En plus c’est nul, ca sert à rien concrettement… sauf pour une entreprise et encore ca prend du temps et faut vraimment avoir des trucs sensibles ou des concurrents tres determiné. La sécurtité s’evalue en terme d’argent. Les attaques s’evaluent en terme d’argent (il faut 5000$ pour pirater X.com,…) On en déduit une politique sécurité. Pas des idées parci par-la.
A.I.D.E ou samhain oui, à la limite mais bonjour le temps de lecture des logs sur un système qui evolue (different de sarge donc)

[quote=« ricardo »]Je ne suis pas sûr que le sujet n’ait pas déjà été abordé et je vais ptet être obligé de m’engueuler :smt093
[/quote]

Si la fonction rechercher n’a pas été utilisée, tu n’aurais déja pas du poster

Comme sous Debian

[quote]chaque fois qu’il y a un essai d’intrusion, on est prévenu de l’intervention du firewall.
existe-t-il qq chose de semblable à installler sous Debian ?[/quote]

Vu que ce genre de trucs n’a rien a voir avec la distribution, oui. Si tu aimes le spam:

apt-cache search firewall log

[quote]
Sous Mandriva, ou iptables est installé d’office

Comme sous Debian
[/quote]Je me suis mal exprimé, je voulais parler du signal d’alerte lors d’une intrusion : mea culpa !

Usinagaz, merci pour ts tes liens et données sur ce sujet.

[quote]ce fichier semble actualisé à chaque ouverture de session, tous les jours . [/quote] idem pour moi, c’est la preuve que l’install que ns avons faite fonctionne bien.

[quote]Vu que ce genre de trucs n’a rien a voir avec la distribution, oui. Si tu aimes le spam: [/quote] Ed, Je ne comprends pas la mise en garde de fin de phrase ? Il y a un danger plus important d’être “spamé” si on installe ce genre d’indicateur d’intrusion ?

[quote=“BorisTheButcher”]edit:
snort non, un honeypot(net) non. C’est à la mode, les gens arrivent sur linux la premiere chose qu’ils veulent faire c’est installer snort pour espionner les chtis n’hacker… zont vraimment que ca a foutre les gens.
En plus c’est nul, ca sert à rien concrettement… sauf pour une entreprise et encore ca prend du temps et faut vraimment avoir des trucs sensibles ou des concurrents tres determiné. La sécurtité s’evalue en terme d’argent.[/quote] :blush: pas d’accord !! ou alors ça c’est de l’intox ? :

Est-ce qu’on a pas un peu trop tendance à considerer que la cible est une fin en soi, alors qu’elle ne représente qu’un moyen d’accèder sans se faire tracer à une cible véritable qui vaut son pesant de $ ?
je veux pas être une vulgaire target moi lol !!!

hello,

Snort est IDS intrusion detection systeme, et comme dit plus, firewall+log.

si un système détecte une INTRUSION, c’est que soit, c’est faux, soit le logiciel en question est une grosse daube infame. Parceque le système est DEJA corrompu.

=> Poubelle.

merci stonfi, mais quel genre d’IDS, h-ids ou n-ids ?
ps: aie, c’est un firewall snort ?

[quote=“ed”]si un système détecte une INTRUSION, c’est que soit, c’est faux, soit le logiciel en question est une grosse daube infame. Parceque le système est DEJA corrompu.
=> Poubelle.[/quote]
Justement, comment savoir si notre système est déjà corrompu, par exemple à l’installation même de debian, pour le cas où on aurait pas respecter les règles d’usage pour éviter cela : [quote=“http://www.debian.org/doc/manuals/securing-debian-howto/ch3.fr.html”]
3.3 Ne pas se connecter à l’Internet tant que tout n’est pas prêt

Le système ne devrait pas être connecté à l’Internet pendant l’installation. Ceci peut paraître stupide mais il faut savoir que l’installation par le réseau est une méthode d’installation habituelle. Étant donné que le système va installer et activer les services immédiatement, si le système est connecté à Internet et que les services ne sont pas configurés correctement, vous les exposez à des attaques. [/quote]

entreelibre.com/scastro/debian-s … ecinst.txt

On formatte, on installe des sources officiels, on verifie les signatures md5 ou sha (primordiale pour un firewall d’entreprise ou un ids!!) et on passe une couche de A.I.D.E.
Et là, on a une base, on branche le cable reseau.

Le coup de snort je suis pas trop pour, je m’explique:
Déja il y a bcp de methode pour dupper un snort-like. Ca s’est considérablement amélioré mais perso j’ai peur qu’il soit encore possible de le dupper. C’est un antivirus réseau en quelque sorte. J’aime pas les antivirus, c’est facile de les dupper quand on prend le temps de les etudier.
En plus un snort-like detecte une phase d une attaque: la recherche d’information et admettons, la compromission. Après ca, le systeme cible est modifié et le NIDS ne verra quepouic. Un AIDE verra qqchose et est impossible a dupper, il permet de detecter une compromission, pas une recherche d’info (m’en fout de savoir si on essaye de me pirater, je suis pas une banque, j’attend de voir les faits concrets).
Super, tu vas voir des mssql rpc , des port 135, des ports 137 toute la journée…

C’est pareil avec les honeypot. Ca sert pour les chercheurs white hats qui sont constamment depassé par les blackhats alors ils posent des honeypots parci parla comme ca ils étudient les techniques. Mais pour un pékin moyen, il installe une machine avec un trou de sécurité et ensuite il regarde le pirate travailler. A quoi ca sert franchement? C’est de la curiosité stupide et si jamais un pirate callé detecte le honeypot (c’est possible et on touche a du domaine tres tres pointu) alors ca va etre votre fete.
Enfin, c’est mon avis. En sécurité rien n’est acquis et il n’y a pas de pensée unique, c’est une histoire de discussion pour echanger les idées.

Le lien de stonfi a l’air pas mal, j’ai juste regardé la liste des personnes remerciées.