placid Posté(e) le 5 septembre 2005 Partager Posté(e) le 5 septembre 2005 Essaie un ls -s /bin/sh, il devrait pointer vers /bin/bash. Je viens d'essayer, la commande ls -s /bin/sh pointe sur /bin/sh [EDIT] je refais pas un post pour répondre à neologix (voir post suivant) Effectivement la commande pointe sur /bin/bash Lien vers le commentaire Partager sur d’autres sites More sharing options...
neologix Posté(e) le 5 septembre 2005 Partager Posté(e) le 5 septembre 2005 Oups, une coquille s'est glissée dans ma commande: c'est: # ls -l /bin/sh Lien vers le commentaire Partager sur d’autres sites More sharing options...
neologix Posté(e) le 12 février 2006 Partager Posté(e) le 12 février 2006 Salut. Je cherchais un outil simple pour générer mes règles iptables. Je me suis donc écrit mon propre script en bash, qui produit des règles simples, claires, et commentées. Il pose des questions, il suffit de répondre par y/n, les numéros de ports, et les noms des interfaces. Pour l'instant, il gère: -l'ouverture de ports "connus" style ftp/ssh, etc -l'ouverture de ports individuels -la gestion du ping -le NAT -une DMZ: redirection de ports, etc -il implémente certains mécanismes de sécurité du noyau, en utilisant le système de fichier /proc (ou sysctl) En fait, j'ai surtout fait ça pour m'amuser, je ne prétend pas concurrencer shorewall ;-) Je ne suis un expert ni en bash, ni ensécurité/réseau. Je ne garantis pas la qualité des règles produites, mais au moins vous pouvez facilement les vérifier ;-) Si ça vous intéresse, en attendant que je corrige 2/3 trucs, vous pouvez voir un exemple de règles générées: http://neologix.free.fr le fichier start_iptables neo Lien vers le commentaire Partager sur d’autres sites More sharing options...
neologix Posté(e) le 14 février 2006 Partager Posté(e) le 14 février 2006 Salut. Est-ce que certains d'entre vous utlisent le module recent d'iptables? On peut faire des trucs pas mal, du style: phoenix:/home/neo# ping localhost PING localhost.localdomain (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.156 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.094 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=64 time=0.099 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=4 ttl=64 time=0.095 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=5 ttl=64 time=0.097 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=6 ttl=64 time=0.095 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=7 ttl=64 time=0.097 ms --- localhost.localdomain ping statistics --- 7 packets transmitted, 7 received, 0% packet loss, time 5999ms rtt min/avg/max/mdev = 0.094/0.104/0.156/0.024 ms Si on fait phoenix:/home/cf# iptables -A INPUT -m recent --name nc --set phoenix:/home/cf# iptables -A INPUT -m recent --name nc --update --hitcount 5 --seconds 60 -j DROP alors phoenix:/home/cf# ping localhost PING localhost.localdomain (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.114 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.105 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=64 time=0.102 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=4 ttl=64 time=0.105 ms --- localhost.localdomain ping statistics --- 10 packets transmitted, 4 received, 60% packet loss, time 9004ms rtt min/avg/max/mdev = 0.102/0.106/0.114/0.011 ms On peut spécifier un nombre max ou un taux max de connexions venant d'une même IP. Dans le même esprit, on peut avoir des ports ouverts sans qu'ils apparaîssent sur un scan: phoenix:/home/neo# nmap -A localhost Starting Nmap 4.00 ( http://www.insecure.org/nmap/ ) at 2006-02-14 11:11 CET Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port Interesting ports on localhost.localdomain (127.0.0.1): (The 1668 ports scanned but not shown below are in state: filtered) PORT STATE SERVICE VERSION 22/tcp closed ssh 23/tcp closed telnet 113/tcp closed auth 443/tcp closed https Too many fingerprints match this host to give specific OS details Nmap finished: 1 IP address (1 host up) scanned in 305.149 seconds et pourtant: phoenix:/home/cf# netstat -pan -A inet Connexions Internet actives (serveurs et établies) Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name tcp 0 0 0.0.0.0:18 0.0.0.0:* LISTEN 1637/nc udp 0 0 0.0.0.0:68 0.0.0.0:* 902/dhclient En fait, c'est surtout utile pour les attaques en brute force, notamment ssh. Lien vers le commentaire Partager sur d’autres sites More sharing options...
naparuba Posté(e) le 14 février 2006 Partager Posté(e) le 14 février 2006 Pour nmap, mettre un -p 1- pour qu'il scanne les port de 1 à 65535 (tous quoi ), ne pas oublier un autre test -sU pour l'UDP, il n'y a pas que le TCP dans la vie Très bon tuto en tout cas Lien vers le commentaire Partager sur d’autres sites More sharing options...
theocrite Posté(e) le 14 février 2006 Partager Posté(e) le 14 février 2006 sympa cette nouvelle fonctionnalité néo On pouvait déjà faire ce genre de chose avec tc sous nux et altq sous BSD. L'avantage c'est qu'Altq est dirctement utilisable depuis pf. Par contre c'est plus lourd à mettre en place. Là c'est sympa comme tout à utiliser. http://linuxreviews.org/man/tc/ http://www.openbsd.org/cgi-bin/man.cgi?que...386&format=html Lien vers le commentaire Partager sur d’autres sites More sharing options...
neologix Posté(e) le 14 février 2006 Partager Posté(e) le 14 février 2006 Ouais, enfin c'est pas moi qui l'ai codé! Bon, à part ça je viens de terminer mon script de génération de règles iptables (NAT, DMZ, serveurs, etc) Je le mets en ligne au cas où ça intéresserait des gens: http://neologix.free.fr iptables_manager.sh start_iptables est un exemple de règle générée, pour montrer ce qu'il gère. Lien vers le commentaire Partager sur d’autres sites More sharing options...
yoda222 Posté(e) le 17 février 2006 Partager Posté(e) le 17 février 2006 Tiens, au fait, je me demandais si il y avait une raison quelconque poux que les malades de la sécurité "mainteneurs" de OpenBSD n'activent pas pf par défaut, et pourquoi pf, par défaut, ne suppose pas block in all et block out all... Sinon je trouve la syntaxe pf plus simple que iptables . Le topic est intéressant pour les non experts... qui veulent se renseigner Tiens je viens de finir un scan et apparement nmap de ma gentoo n'est pas à jour : il propose : Running: OpenBSD 3.X OS details: OpenBSD 3.5 or 3.6, OpenBSD 3.6, OpenBSD 3.7 et c'est 3.8 Faudra un jour regarder comment nmap fonctionne, car permettre de trouver cela avec un seul port ouvert... ça m'impressionne. Quelqu'un a l'explication, de façon (relativement) simple ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
theocrite Posté(e) le 17 février 2006 Partager Posté(e) le 17 février 2006 Ouais, enfin c'est pas moi qui l'ai codé! Ouais, je me doute, mais je disait merci pour avoir apporté ça à mon attention, moi qui ne suis (suivre) pas le dev d'iptables. Et aussi un peu parce que je suis poli Tiens, au fait, je me demandais si il y avait une raison quelconque poux que les malades de la sécurité "mainteneurs" de OpenBSD n'activent pas pf par défaut, et pourquoi pf, par défaut, ne suppose pas block in all et block out all... Bonne question.La non activation par défaut, je suppose que c'est pour éviter que les boulets ne saturent la ml (mon apache ne fonctionne pas, j'arrive pas à envoyer des mails, ...). Par ce que bon... des question qui se trouvent dans la faq, il y en a pas mal qui reviennent dans misc@ (bon ils se font flamer ) Par contre ne pas mettre en block all (pas besoin de préciser in et out ), ça ne me choque pas plus que ça. Si tu lance ton firewall, tu es supposé avoir édité le fichier de conf. Et normalement tu commence par mettre un block avant de mettre des allow... Ce que je n'aime pas trop dans pf par rapport à iptables, c'est le fait d'évaluer toutes les règles. Moi je met un block all au début puis ensuite toutes les règles (ou presque) comportent un quick. Je ne voit pas l'intérêt d'évaluer toute les règles pour finalement ne rien trouver. Sinon je trouve la syntaxe pf plus simple que iptables . C'est beaucoup plus simple. et c'est 3.8 Marrant, moi il me semble qu'il proposait bien 3.8... ou 3.7 je ne sais plus (et le serveur est down, je ne peux pas tester).Faudra un jour regarder comment nmap fonctionne, car permettre de trouver cela avec un seul port ouvert... ça m'impressionne. Quelqu'un a l'explication, de façon (relativement) simple ? Ça dépend du port et du soft.Dans certains cas c'est évident : soad@copernic$ HEAD free.fr200 OK Connection: close Date: Fri, 17 Feb 2006 01:06:08 GMT Accept-Ranges: bytes ETag: "b712-cbca-43f5213d" Server: Apache/1.3.33 (Debian GNU/Linux) Content-Length: 52170 Content-Type: text/html Last-Modified: Fri, 17 Feb 2006 01:05:01 GMT Client-Date: Fri, 17 Feb 2006 01:06:32 GMT Client-Peer: 213.228.0.42:80 Client-Response-Num: 1 soad@copernic$ telnet 127.0.0.1 22 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. SSH-2.0-OpenSSH_4.2p1 Debian-5 Là c'est pas dur, c'est en plain text. (même résultat avec lynx -head -dump http://free.fr). Dans le cas de mon ssh, sans le recompiler, je ne vois pas comment éviter le reconnaissance. Et puis bon, il faut le vouloir... Pour la partie OpenSSH : grep SSH openssh-4.2p1/version.h #define SSH_VERSION "OpenSSH_4.2" #define SSH_PORTABLE "p1" #define SSH_RELEASE SSH_VERSION SSH_PORTABLE Pour la partie Debian : zcat openssh_4.2p1-5.diff.gz | grep SSH_E | head -1 +SSH_EXTRAVERSION := Debian-$(shell dpkg-parsechangelog | sed -n -e '/^Version:/s/Version: //p' | sed -e 's/[^-]*-//') Dans d'autres cas, c'est moins trivial, mais ça peut se reconnaitre à certains utilitaires (ssh, postfix, apache, etc.) qui ont étés modifiés spécifiquement par les les distribs (en particulier OpenBSD avec sa politique du KISS). On a donc une info sur la distrib. On peut combiner ça à du fingerprint pour trouver le noyau (comme pour http://www.openbsd.org/faq/pf/fr/filter.html#osfp et http://www.openbsd.org/cgi-bin/man.cgi?que...ath=OpenBSD+3.8 vu qu'on parle d'OpenBSD ). Je ne retrouve plus, mais il y avait un article récent dans misc qui parlait de la reconnaissance d'OS en fonction du temps mesuré entre les envois de paquets. (Tu envoie un seul et unique paquet, puis plus rien, puis tu mesure le temps de retour du premier paquet, puis des tentatives suivantes. On peut déterminer l'OS assez finement avec ça).C'est probablement dans le numéro 22, vu que j'ai rien trouvé dans les numéros 23 et 21... Ceci dit c'est facilement spoofable avec pf justement. Il suffit d'activer syn-proxy state pour protéger les fingerprint de tout le lan. C'est bien pratique. (À condition de ne pas avoir l'OS en Plain text comme dans le cas de free bien sûr, sinon ça ne sert pas à grand chose ). Et puis tiens, tu peux aussi essayer ça echo "deny from any OS "nmap" >> /etc/pf.conf && pfctl -f /etc/pf.conf && pfctl -e puis de refaire ton nmap. Ça devrait être un peu moins précis tout à coup En tout cas, chez moi ça fonctionnait très bien (le deny pas le scan) :). PS : Bon bien sûr tout ce que j'ai dit est à mettre au conditionnel. Je ne suis pas un expert de nmap et j'ai jamais regardé le code source. Je donne juste des idées et des pistes. Lien vers le commentaire Partager sur d’autres sites More sharing options...
tuXXX Posté(e) le 17 février 2006 Partager Posté(e) le 17 février 2006 Pour faire de la détection d'OS nmap a juste besoin d'un port TCP ouvert, un port TCP fermé et un port UDP fermé. Et cela quels qu'ils soients... pas besoin que ce soit ssh ou quoi... nmap envoie des paquets TCP/IP et UDP/IP forgés d'une certaine manière et attend la réponse. Ces paquets sont spécifiques et la réponse à avoir n'est pas indéquée dans la RFC, donc chaque développeur de pile TCP/IP fait comme il veut pour implémenter ces détails. nmap compare ensuite ça à sa base de donnée pour comparer l'ensemble des réponses reçues avec les signatures connues et en déduit l'OS. Par exemple, si on prend les options des paquets TCP (cf RFC 793 et quelques autres), nmap envoie ses paquets TCP avec plein d'options (MSS, WScale, Timestamp...). L'OS en face n'active chacun de ces options que si il le supporte, et il peut les mettre dans n'importe quel ordre dans sa réponse, ce qui permet de différentier les OS différents. Cela n'est qu'un petit exemple (car il y a plein d'autres tests). En tout cas nmap n'utilise pas les informations des différents protocoles pour déterminer l'OS (il regarde derrière les ports avec le flag -sV ou -A, et c'est juste "pour le fun", il n'utilise pas ça pour faire la détection de version... en même temps si l'utilisateur voit un Windows avec un port apache ouvert et une bannière contenant "Debian", il va se poser des questions) Lien vers le commentaire Partager sur d’autres sites More sharing options...
naparuba Posté(e) le 17 février 2006 Partager Posté(e) le 17 février 2006 Pour faire de la détection d'OS nmap a juste besoin d'un port TCP ouvert, un port TCP fermé et un port UDP fermé. Et cela quels qu'ils soients... pas besoin que ce soit ssh ou quoi... nmap envoie des paquets TCP/IP et UDP/IP forgés d'une certaine manière et attend la réponse. Ces paquets sont spécifiques et la réponse à avoir n'est pas indéquée dans la RFC, donc chaque développeur de pile TCP/IP fait comme il veut pour implémenter ces détails. nmap compare ensuite ça à sa base de donnée pour comparer l'ensemble des réponses reçues avec les signatures connues et en déduit l'OS. Par exemple, si on prend les options des paquets TCP (cf RFC 793 et quelques autres), nmap envoie ses paquets TCP avec plein d'options (MSS, WScale, Timestamp...). L'OS en face n'active chacun de ces options que si il le supporte, et il peut les mettre dans n'importe quel ordre dans sa réponse, ce qui permet de différentier les OS différents. Cela n'est qu'un petit exemple (car il y a plein d'autres tests). En tout cas nmap n'utilise pas les informations des différents protocoles pour déterminer l'OS (il regarde derrière les ports avec le flag -sV ou -A, et c'est juste "pour le fun", il n'utilise pas ça pour faire la détection de version... en même temps si l'utilisateur voit un Windows avec un port apache ouvert et une bannière contenant "Debian", il va se poser des questions) Il y a aussi POF qui lui fait la détection d'OS en passif (bon là il faut un peu plus d'un paquet, car il ne forge par une demande précise) mais étudie une communication "normale" pour voir de quel OS il s'agit (enfin quelle pile, ensuite il la colle à l'OS, il y a un programme qui permet de modifier la pile OpenBSD je crois pour la faire passer pour une pile de Playstation2 mais je ne me souvient plus du nom ) car suivant les choix des windows et des numéros de séquences (plus d'autres trucs ) tu peux avoir des indices pour savoir qui parle. Lien vers le commentaire Partager sur d’autres sites More sharing options...
tuXXX Posté(e) le 17 février 2006 Partager Posté(e) le 17 février 2006 p0f c'est un peu pareil que nmap et que tous les autres outils de fingerprint... ça analyse les paquets (TCP/IP (SYN) pour p0f) et compare à une base de données... (c'est aussi exact que par exemple nmap regarde aussi la méthode de génération des ISN TCP et des ID IP pour savoir quel OS tourne) (après y'a des petites variations en fonction des outils, mais c'est relativement toujours la même chose...) Et sous Linux (2.4), il y a par exemple ippersonality ( http://ippersonality.sourceforge.net/ , c'est un patch pour iptables) qui permet de se faire passer pour d'autres OS... Lien vers le commentaire Partager sur d’autres sites More sharing options...
naparuba Posté(e) le 17 février 2006 Partager Posté(e) le 17 février 2006 Et sous Linux (2.4), il y a par exemple ippersonality ( http://ippersonality.sourceforge.net/ , c'est un patch pour iptables) qui permet de se faire passer pour d'autres OS... Merci , je vais voir ce que ca donne de nmap et nessus face à des piles de playstation2 Mais pourquoi seulement 2.4? Il y a tant de différences que ça avec le 2.6 pour netfilter? (ok on ne fait pas trop les modules de la même façon à cause (grâce?) à la préemption). Bon aller hop, une seule façon de le voir, c'est d'y aller EDIT: pas mal du tout ce ippersonality. J'ai seulement lu la doc pour l'instant, le code attendra ce soir , mais je me demande s'il est pas possible de le porter simplement sous 2.6 en "déportant" une partie de leur application en UserSpace grâce à la lib ipq... idée à creuser très sérieusement Lien vers le commentaire Partager sur d’autres sites More sharing options...
tuXXX Posté(e) le 17 février 2006 Partager Posté(e) le 17 février 2006 pas mal du tout ce ippersonality. J'ai seulement lu la doc pour l'instant, le code attendra ce soir , mais je me demande s'il est pas possible de le porter simplement sous 2.6 en "déportant" une partie de leur application en UserSpace grâce à la lib ipq... idée à creuser très sérieusement Commence un projet (avec le code sur une page web perso), si t'as un truc qui commence à marcher moi je veux bien venir aider Lien vers le commentaire Partager sur d’autres sites More sharing options...
naparuba Posté(e) le 20 février 2006 Partager Posté(e) le 20 février 2006 Commence un projet (avec le code sur une page web perso), si t'as un truc qui commence à marcher moi je veux bien venir aider Pas de problème pour ça Techniquement ca ressemble à un projet que j'ai fait Reste à voir leur histoire de Machine virtuelle pour leur code, c'est pas con du tout comme idée ca... Mode analyse de leur code ON Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.