attaque par ssh

Deux manières :
1) Essayer de réparer les droits. Mais peut-être qu'il y a mélange des
droits si tu as fait une mise à jour d'un 10.3 en 10.4, je ne sais pas,
dans ce cas là, si il se mélange pas entre les reçus du 10.3 et ceux du
10.4. Il faudrait essayer de virer les reçus en rapport avec Mac OS X
10.3 du dossier /Library/Receipts/.

Bon je vais essayer ça pour voir si ça retombe en marche sinon je
passerai au point

2) Ou sinon, faire :
sudo chmod g+r /var/log/secure.log


La deuxième manière est plus facile, mais je pense que la première est
plus sûre.

Vu ma capacité à faire des boulettes de retranscription, et vu les
conséquances avec un sudo c'est sur que la première méthode est beaucoup
plus sûre pour un utilisateur de mon niveau.

Pour mon information peux tu m'expliquer la commande?
Sudo = je prends la main comme root le temps de la commande
chmod = change mod = changer les propriétés d'un fichier
g = ????????
+r = donne le droit en lecture sur le fichier au niveau g, je suppose
/var/log/secure.log = le fichier cible à modifier.

Par défaut, seuls les comptes admin sont dans le fichier sudoers, et
c'est normal...

Ok merci de cette information. En fait je pensai bètement que tout le
monde pouvait être sudoer du moment qu'on connait le log et le pass
admin. Finalement c'est mieux comme ça, je pense qu'au niveau sécurité
c'est meilleur.

Merci de ton aide

--
Eric

Deux manières :
1) Essayer de réparer les droits. Mais peut-être qu'il y a mélange des
droits si tu as fait une mise à jour d'un 10.3 en 10.4, je ne sais pas,
dans ce cas là, si il se mélange pas entre les reçus du 10.3 et ceux du
10.4. Il faudrait essayer de virer les reçus en rapport avec Mac OS X
10.3 du dossier /Library/Receipts/.

Je viens de faire un tour dans /library/receipts/.
C'est pas gagné. La réparation des droits ne change rien, ça fait 5 fois
que le fais sans modification. Au niveau des receipts, j'ai un peu peur
de faire des bétises, je vire que les receipts en rapport avec Mac OS
10.3.x ou il faut aussi virer les security update de cette époque et les
composants quicktime de cette époque. Merci de m'éviter de faire une
grosse bétise.

Finalement le sudo est peut être beaucoup plus facile :-(

--
Eric

eric <charpan25@etu.unige.ch> wrote:

Vu ma capacité à faire des boulettes de retranscription, et vu les
conséquances avec un sudo c'est sur que la première méthode est beaucoup
plus sûre pour un utilisateur de mon niveau.

Non, c'est pas ça :
Si tu refais une réparation des permissions, le problème reviendra.
Donc le chmod est livré sous forme d'abonnement.

g = ????????

g = groupe
u = user
o = others

Tu peux combiner, genre ug+rwx

r = read
w = write
x = eXecute

On peut aussi atribuer ça sous forme de chiffres, mais ce sera pour une
autre fois :)

Ok merci de cette information. En fait je pensai bètement que tout le
monde pouvait être sudoer du moment qu'on connait le log et le pass
admin.

Tu peux faire un "su toto" où toto est le nom d'un compte admin.
ou encore "su" tout court, mais là il faut donner le passwd root, ce qui
n'est pas possible par défaut puisque celui ci est désactivé.

Tu peux aussi faire un "sudo visudo" puis modifier la liste des
"sudoers" de façon à autoriser toto à faire un sudo, avec ou sans mot de
passe.

Finalement c'est mieux comme ça, je pense qu'au niveau sécurité
c'est meilleur.

C'est à définir, en fait.
Mais je ne vois pas trop l'intérêt d'autoriser un utilisateur à faire un
sudo sans lui donner les droits admin, à moins de limiter les droits
sudo de cet utilisateur à certaines commandes. Possible également.

--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas

Un outil que j'utilise pour mes sshd sous Solaris est "denyhost" :
http://denyhosts.sourceforge.net/

Je viens de voir qu'il est censé fonctionner sous Mac OS X, mais je n'ai pas encore
eu l'occasion de tester, n'ayant de Mac avec ce besoin :

http://denyhosts.sourceforge.net/faq.html#1_16

eric <charpan25@etu.unige.ch> wrote:

Vu ma capacité à faire des boulettes de retranscription, et vu les
conséquances avec un sudo c'est sur que la première méthode est beaucoup
plus sûre pour un utilisateur de mon niveau.

Non, c'est pas ça :
Si tu refais une réparation des permissions, le problème reviendra.
Donc le chmod est livré sous forme d'abonnement.

Je n'ai pas bien compris cette question d'abonnement. Si je fais chmod
je modifie de façon "permanente" i.e. qui ne sera pas modifié par le
système sauf update de celui-ci, les règles d'accés pour le dit fichier.
C'est ça que tu entends par abonnement?

g = ????????

g = groupe
u = user
o = others

OK merci. Je le note

Tu peux combiner, genre ug+rwx
OK ça j'avais compris que les commandes unix sont associables (enfin

certaines) et combinables.

r = read
w = write
x = eXecute
A force de vous lire j'avais fini par comprendre ça, mais c'est toujours

bien de préciser, ne serait-ce que pour les autres lecteurs.

On peut aussi atribuer ça sous forme de chiffres, mais ce sera pour une
autre fois :)
On va encore attendre un peu que j'ai déjà bien assimilé les points

précédent avant de compliquer avec des chiffres. Mais par curiosité quel
est l'intérêt de le faire avec des chiffres plutôt qu'avec des lettres a
peu près compréhensible?

Ok merci de cette information. En fait je pensai bètement que tout le
monde pouvait être sudoer du moment qu'on connait le log et le pass
admin.

Tu peux faire un "su toto" où toto est le nom d'un compte admin.
ou encore "su" tout court, mais là il faut donner le passwd root, ce qui
n'est pas possible par défaut puisque celui ci est désactivé.
La différence entre su et sudo est pour moi parfaitement obscure et

réservée aux initiés.

Tu peux aussi faire un "sudo visudo" puis modifier la liste des
"sudoers" de façon à autoriser toto à faire un sudo, avec ou sans mot de
passe.
D'accord, enfin on va pas trop faire joujou avec les sudo à mon niveau.

C'est à définir, en fait.
Mais je ne vois pas trop l'intérêt d'autoriser un utilisateur à faire un
sudo sans lui donner les droits admin, à moins de limiter les droits
sudo de cet utilisateur à certaines commandes. Possible également.

Donc je continu comme aujourd'hui. Un compte admin pour administrer

l'ordi et faire la maintenance et un compte utilisateur pour le reste du
temps. Pas besoin d'être admin pour ce que je fais et au moins je suis
sur d'avoir un système a peu près propre. Le seul inconvénient que je
vois à mon système c'est que dans des cas comme ici ou j'ai un soucis il
faut que jongle entre 2 sessions, mais ce n'est pas insurmontable.


Merci de ces explications.

--
Eric

eric <charpan25@etu.unige.ch> wrote:

Pour mon information peux tu m'expliquer la commande?
Sudo = je prends la main comme root le temps de la commande

Oui

chmod = change mod = changer les propriétés d'un fichier

Oui

g = ????????

Groupe

+r = donne le droit en lecture sur le fichier au niveau g, je suppose
/var/log/secure.log = le fichier cible à modifier.

On donne le droit en lecture aux membres du groupe du fichier. Le groupe
du fichier dans ce cas étant admin, on donne le droit en lecture aux
admins.

--
Anonyme ( jayce <@> mosx.org )
********* MosX.org <http://www.mosx.org/> *********
(MosX.net renaît sous le nom MosX.org...)

eric <charpan25@etu.unige.ch> wrote:

Je viens de faire un tour dans /library/receipts/.
C'est pas gagné. La réparation des droits ne change rien, ça fait 5 fois
que le fais sans modification.

Oui, mais si il s'emmêle entre les différents packages, c'est
compréhensible.

Au niveau des receipts, j'ai un peu peur
de faire des bétises, je vire que les receipts en rapport avec Mac OS
10.3.x ou il faut aussi virer les security update de cette époque et les
composants quicktime de cette époque. Merci de m'éviter de faire une
grosse bétise.

De toute façon, ce n'est pas une très grosse bêtise que de virer des
fichier Receipts, ils ne servent qu'à :
- vérifier quels sont les droits à utiliser dans la réparation des
droits.
- regarder quels logiciels sont installés pour proposer les bonnes mises
à jour automatiquement.

Enfin, tu peux toujours les déplacer dans un autre dossier plutôt que
les effacer si tu veux être sûr.

Tu peux virer tous les receipts du 10.3, des security updates et
composants systèmes (QT compris) de l'époque.

Finalement le sudo est peut être beaucoup plus facile :-(

Oui, mais ne règlera le problème qu'en apparence.
Peut-être (même si je n'y crois pas) que les autres problèmes que tu as
sont liés à un problème de droits qui ne serait pas corrigé à cause du
même problème que pour secure.log...

--
Anonyme ( jayce <@> mosx.org )
********* MosX.org <http://www.mosx.org/> *********
(MosX.net renaît sous le nom MosX.org...)

Anonyme <jayce@mosx.org> wrote:

Oui, mais si il s'emmêle entre les différents packages, c'est
compréhensible.

Il n'utilise pas tous les packages (heureusement car un package tierce
pourrait très bien avoir mis de mauvais droits et le fait de l'utiliser
pour réparer les droits ne changerait rien) mais une liste bien précise
:

$ strings
/System/Library/PrivateFrameworks/DiskManagement.framework/Resources/Dis
kManagementTool | grep .bom

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.

Tu peux virer tous les receipts du 10.3, des security updates et
composants systèmes (QT compris) de l'époque.

J'ai fait comme tu as dit j'ai viré les receipts (enfin pour le moment
ils sont au chaud dans un fichier transitoire avant la poubelle). Je
n'ai pas l'impression d'avoir un soucis. Réparation des autorisations,
mais ça n'a rien changer. Du coup j'ai fait le sudo et tout roule.

On va voir si ça s'améliore.

Finalement le sudo est peut être beaucoup plus facile :-(

Oui, mais ne règlera le problème qu'en apparence.
Peut-être (même si je n'y crois pas) que les autres problèmes que tu as
sont liés à un problème de droits qui ne serait pas corrigé à cause du
même problème que pour secure.log...

Je vais continuer à jeter un œil là dessus et vous tiendrez au courant.

Pour le moment, le point positif en plus, c'est que les applications
dashboard se relance automatiquement signe que mon LaunchD va peut être
mieux. Je vais quand même vérifier que les scripts périodique se
remettent en marche, mais là j'ai quand même plus de doute. Pour info je
n'ai jamais modifier la table Cron de ces scripts.

Merci en tout cas de ton aide et des quelques autres qui sont intervenus.

--
Eric

eric <charpan25@etu.unige.ch> wrote:

Je n'ai pas bien compris cette question d'abonnement. Si je fais chmod
je modifie de façon "permanente" i.e. qui ne sera pas modifié par le
système sauf update de celui-ci, les règles d'accés pour le dit fichier.
C'est ça que tu entends par abonnement?

A chaque réparation des privilèges, tu retrouveras les réglages system

On va encore attendre un peu que j'ai déjà bien assimilé les points
précédent avant de compliquer avec des chiffres. Mais par curiosité quel
est l'intérêt de le faire avec des chiffres plutôt qu'avec des lettres a
peu près compréhensible?

Une fois que tu as compris le système, les chiffres ne sont pas plus
compliqués que les lettres.

Avec les lettres, tu t'exprime en ajoutant ou en soustrayant des
permissions à ce qui est existant. Avec les chiffres, tu donnes le
résultat final. Donc avec les chiffres, tu n'as pas besoins de connaitre
l'état actuel des permissions, tu dis juste ce que tu veux.

C'est deux façon différentes et complémentaires de spécifier ce que tu
veux.

La différence entre su et sudo est pour moi parfaitement obscure et
réservée aux initiés.

Avec un "su toto" tu prends l'identité de toto en donnant le passwd de
toto.
Avec "sudo -s -u toto" tu prends aussi l'identité de toto mais en
entrant ton propre mot de passe.

Donc par exemple "su root" n'est possible que si root est activé,
puisque sinon root n'a pas de passwd. Tandisqu'avec "sudo -s -u root" tu
donne ton propre passwd et tu peux le faire même si root est désactivé.

C'est donc très similaire, sauf que avec sudo tu n'as qu'un seul mot de
passe à connaitre, le tien.

--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas