Jump to content

[TUTO][Initié]Outils d'information sur la sécurité


Recommended Posts

Il manque les règles de retour. Rajoute les lignes qui contiennent -m state ESTABLISHED,RELATED

En effet, un ami m'a expliqué juste avant ^^

Par contre, comment rendre cela actif a chaque redémarrage ? :)

Un petit moins par contre, iptables, c super lentttttttt :craint:

Et d'autant plus si on fait une faute dans la commande ! Faut attendre tout le script pour qu'a la fin ca nous dise : parametre inconnu :fou:

Mais bon, c'est efficace, alors on lui pardonne :p

Link to comment
Share on other sites

  • Replies 64
  • Created
  • Last Reply
En effet, un ami m'a expliqué juste avant ^^

Par contre, comment rendre cela actif a chaque redémarrage ? :)

Un petit moins par contre, iptables, c super lentttttttt :craint:

Et d'autant plus si on fait une faute dans la commande ! Faut attendre tout le script pour qu'a la fin ca nous dise : parametre inconnu :fou:

Mais bon, c'est efficace, alors on lui pardonne :p

Au contraire, c'est super rapide : t'est pas obligé de relancer tout ton script bash, hein, il suffit d'ajouter/retirer les filtres en live !

(et lister avec "-n", histoire que ce soit rapide aussi)

Link to comment
Share on other sites

Au contraire, c'est super rapide : t'est pas obligé de relancer tout ton script bash, hein, il suffit d'ajouter/retirer les filtres en live !

(et lister avec "-n", histoire que ce soit rapide aussi)

oui, a ce niveau la, c'est rapide, mais moi, pour chaque commande iptables, j'ai presque 1-2 min d'attente !

[EDIT] Je viens de refaire le test et iptables me torche ca en 0,2 sec ...

Je ne sais pas ce qui deconnait avant ... :craint:

J'ai l'air de quoi maintenant ? :fou:

Link to comment
Share on other sites

Pas grand chose, je crois :craint: (fallait pas insulter iptables :fou: )

Il merdait avant que je dise qu'il etait bouseux d'etre aussi lent ! Nanméhodidonc !

Par contre, si qqn a une idée pour rendre ma config iptables perenne a chaque démarrage (car il me semble que le iptables se flushe tout seul au reboot...

Link to comment
Share on other sites

tu l'insere dans un shell script que tu mettras dans init.d apres tu fera un update-rc.d nomdescript.sh defaults et ca va mettre a jour tes rc.d

Logiquement ca marche... n'oublie pas de changer tes permissions sur ton script :craint:

Merci. Mais le script doit il gérer le fait qu'on lance un script par

nomduscript start

?

Link to comment
Share on other sites

En faite je crois que finalement juste de faire un script.sh et de faire update-rc.d script.sh defaults ca suffit

Pas besoin de mettre dans init.d --> fait un essaie tu fais ton script et tu fais ca et redemarre --> si en faisant un iptables -L tu vois tes regles c'est que ces bon finalement...

Moi ca marchais en tt cas comme ca...

Link to comment
Share on other sites

En faite je crois que finalement juste de faire un script.sh et de faire update-rc.d script.sh defaults ca suffit

Pas besoin de mettre dans init.d --> fait un essaie tu fais ton script et tu fais ca et redemarre --> si en faisant un iptables -L tu vois tes regles c'est que ces bon finalement...

Moi ca marchais en tt cas comme ca...

Merci :)

Par contre, j'ai un autre probleme maintenant :( J'ai desinstallé firestarter hier pour tout faire a la main, seulement il a desinstallé iptables par la meme occasion :( Du coup, pas moyen d'accéder a mon poste en ssh car je crois que ipchains bloque encore des ports et je n'avais pas le temps de voir pour debloquer ca (sachant que je viens de vérifier, c la meme syntaxe que iptables presque :o )

Bon ben tant pis, pas d'acces a ma machine du week end :cartonrouge:

Link to comment
Share on other sites

  • 2 weeks later...

Très bon topic.

Je regarde de plus près /var/log/auth.log et je ne comprends pas bien ces lignes (bcp).

Mar 23 03:39:01 grattepoil CRON[5849]: (pam_unix) session opened for user root by (uid=0)
Mar 23 03:39:01 grattepoil CRON[5849]: (pam_unix) session closed for user root
Mar 23 04:09:01 grattepoil CRON[5858]: (pam_unix) session opened for user root by (uid=0)
Mar 23 04:09:01 grattepoil CRON[5858]: (pam_unix) session closed for user root
Mar 23 04:17:01 grattepoil CRON[5867]: (pam_unix) session opened for user root by (uid=0)
Mar 23 04:17:01 grattepoil CRON[5867]: (pam_unix) session closed for user root

Apparament Crontab a un problème... Si qqu pouvait m'indiquer une piste. :byebye:

Merci.

laOuine.

Link to comment
Share on other sites

J'ai l'air de quoi maintenant ? :pleure:

t'as surtout l'air d'un gars qui a corrigé sa résolution DNS ... d'où le -n suggéré par tuXXX.

tu as raison Gauret, comme je n'ai pas mis de règles de sorties, ça rend bien nécessaire la partie established ... :roll:

laOuine : tu as dans ta crontab un processus qui s'exécute à intervalle régulier (?) avec les droits root. Fais un crontab -l, tu devrais y trouver du biscuit ...

Link to comment
Share on other sites

laOuine : tu as dans ta crontab un processus qui s'exécute à intervalle régulier (?) avec les droits root. Fais un crontab -l, tu devrais y trouver du biscuit ...

Merci. Avec un crontab -l il me répond : "no crontab for root" :francais:

Donc apparament il n'y a pas de taches avec root.

Sinon dans le fichier /etc/crontab j'ai ceci (par défaut):

17 * * * * root run-parts --report /etc/cron.hourly

25 6 * * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily

47 6 * * 7 root test -x /usr/sbin/anacron || run-parts --report /etc/cron.weekly

52 6 1 * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.monthly

:D

laOuine.

Link to comment
Share on other sites

Quelques scripts dans ces dossiers, par exemple un script pour vider les sessions de php4 toute les 30 minutes, et bien d'autres pas très claire pour moi... Pas de log... C'est peut etre normal. :D

Peut etre réinstaller Cron ?!

laOuine.

Link to comment
Share on other sites

Bon, voilà ce qui se passe. Quand cron execute un de ces scripts, il ouvre une session root pour lancer les commandes. C'est ça que tu retrouves dans tes logs. C'est tout, pas d'affolement donc.

Et comme il lance des scripts "souvent" ca remplis le auth.log.

C'est tout, pas d'affolement donc.

Je m'affole pas moi, voyons... :D

Merci à toi et aux autres. :francais:

laOuine.

Link to comment
Share on other sites

  • 1 month later...
Tu vois les ports ouverts? eh bien les "1024-n" autres sont fermés (nmap ne scanne par défaut que les ports entre 1 et 1024...)

D'ailleurs, il le marque...

non, il en scanne d'autres standards.

Je vérifie:

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-05-17 20:52 CEST
Interesting ports on localhost.localdomain (127.0.0.1):
(The 1661 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
21/tcp  open  ftp
631/tcp open  ipp

Nmap finished: 1 IP address (1 host up) scanned in 0.226 seconds

En fait un peu plus :oops:

Link to comment
Share on other sites

  • 3 months later...
en cas de perte du password root

nécessite évidemment un accès physique à la machine.

avec lilo :

avec grub : rajouter init=/bin/bash, monter /etc (en général, /) en rw, utiliser la commande passwd

avec un disque de boot ...

Si comme moi vous avez passé une heure à chercher ce qu'il fallait faire ;) , voici un exemple avec GRUB sous debian:

il faut modifier la ligne suivante :

kernel /bootvmlinuz-2.4.27-2-386 root=/dev/hda1 ro

en ceci :

kernel /bootvmlinuz-2.4.27-2-386 root=/dev/hda1 rw init=/bin/bash

Vous pouvez changer cette ligne pour correspondre avec votre shell préféré, bash, tcsh, ksh, ash, sh, csh,...

confirmer avec entrée

vous revenez au menu précédent et vous lancez en appuyant sur la touche b

ensuite à l'invite root@(none):/# tapez :

passwd root rentrez un nouveau mdp et rebootez.

Link to comment
Share on other sites

kernel /bootvmlinuz-2.4.27-2-386 root=/dev/hda1 rw init=/bin/bash

Juste une petite précision: il me semble que /bin/sh est légèrement plus général que /bin/bash

Sinon, ce n'est vraiment pas idiot de mettre rw à la place de ro sur la ligne dans grub, cela évite d'avoir à faire comme ce que de nombreux sites conseillent:

#mount -o remount,rw /dev/xxx /

neo

Link to comment
Share on other sites

Juste une petite précision: il me semble que /bin/sh est légèrement plus général que /bin/bash

D'après léa-linux le bash est proposé en standard sur de nombreuses distributions, donc j'ai mis celui-ci.

Vous pouvez utiliser bash, tcsh, ksh, ash, sh, csh, etc. Néanmoins, la plupart des distributions actuelles proposent bash par défaut,...

la page en question : shell et commandes

je vais éditer mon précédent post pour précisions.

Link to comment
Share on other sites

Pour ce qui est de PHP, il y a un "safe_mode" qui limite vachement les possibilités. C'est ce qui est utilisé chez les hébergeurs. Regarde sur php.net pour savoir ce qu'il fait.

Le safe_mode php limite beaucoup les choses mais le demon apache possede d'autres wrapper notamenet les ssi ( server side include ) avec des commandes type

<!--#exec cmd="ls -al" -->

ou des handler pour les cgi ( C bash python perl php etc tt ce qui peut etre utilisé en script sur la machine a condition d'utiliser la variable QUERY_STRING )

ou encore des fichiers en rwx pour tout le monde qui peuvent etre réécrit pour recuperer des mot de passes pour aller plus loin dans l'intrusion.

Du coup meme avec le safe mode si le script a la possibilité d'ecrire dans un repertoire autorisé par le gid ( safe_mode gid ) il y a toujours possibilité d'utiliser d'autres fonctionnalités apportés par apache.

De la meme maniere les rootkit sont facilement detectable via un liveCD, mais les binaires patchés comme login (pam) ou sshd avec des "password magiques" hardcoded sont beaucoup plus difficile à detecter à moin de faire une signature sha de tout ses binaires et de les conserver sur une clef usb pour pouvoir vérifier ulterieurement si ils n'ont pas ete modifiés.

De la meme maniere grsec ow et cie sont des protections pour grosso modo mettre la stack en noexec et ainsi prévenir les attaques dues a des bug applicatif mais pas tous ! :)

Meme si depuis le 2.6.12 les eip sont randomisées il reste tjr les bug de preload accessible via un race condition, les bug de tas, fopen ...

Par exemple faire un lien symbolique pointant sur /etc/ld.so.preload lancer le suid bugger et faire le preload de getuid sur tout le systeme (merci libc) et la grsec ou pas le root y passe.

Ma solution : utiliser rsbac pour faire des polices sur chaque demon et process, enlever les droits a root par exemple donner a l'user http le droit de faire un listen sur le port 80 et spécialiser chaque user sur son process associé.

De meme enlever de maniere stricte et absolue tout ce qui n'est pas utilisé sur apache ...

Utiliser pax, compiler ses binaires avec la protection ssp, enlever les modules inutiles au noyau de l'os qui heberge le serveur, rajouter des regles netfilter, utiliser de l'arp statique sur le lan, bien concevoir la topologie reseau au depart pour limiter les risques de propagation, utiliser des switch à alertes smnp etc etc ... et surtout se mettre +/- au courant des news relative à la securitée :)

Je pense qu'avec ces 2 3 tips cela sécurisera un peu plus votre lan sans avoir la pretention d'etre vraiment sécurisé cependant, mais pour un utilisateur ne voulant pas appeler une boite spécialisée ca peut le faire :)

Link to comment
Share on other sites

D'après léa-linux le bash est proposé en standard sur de nombreuses distributions, donc j'ai mis celui-ci.

Vous pouvez utiliser bash, tcsh, ksh, ash, sh, csh, etc. Néanmoins, la plupart des distributions actuelles proposent bash par défaut,...

la page en question : shell et commandes

je vais éditer mon précédent post pour précisions.

sh est le shell original d'UNIX, qui a depuis été remplacé par bash.

Mais, pour des raisons de compatibilité, /bin/sh est un lien symbolique vers le shell utilisé, que ce soit bash, zsh, tcsh, etc. Donc c'est plus général.

En tout cas, c'est le cas sur ma debian. Essaie un ls -s /bin/sh, il devrait pointer vers /bin/bash.

neo

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...