[Freeipa-users] minimise impact compromised host

[Petr Spacek]

On 16.11.2016 18:26, Stijn De Weirdt wrote:
> hi petr,
> 
>>>>> this is a different question: what can we do such that compromised host
>>>>> can do a little as possible if the admin doesn't (yet) know the host is
>>>>> compromised.
>>>>>
>>>>> the default policy allows way too much.
>>>>
>>>> For any useful advice we need more details.
>>>>
>>>> What are the operations you want to disable?
>>> at the very least, "kvno userlogin" should fail (i.e. access to a host
>>> keytab shouldn't permit retrieval of arbitrary user token).
>>
>> I think that this is misunderstanding.
> i'll spend some more time rereading and getting a better understanding
> (again ;)
> 
>>
>> "kvno userlogin" does not allow the attacker to do anything. The result of
>> kvno command is a service ticket for particular principal (user, host).
>>
>> The attacker can use this service ticket *for authentication to the particular
>> principal* (user, host).
>>
>> So the only thing the attacker can do is to prove its identity to given (user,
>> host). This exactly matches capabilities the attacker already has - the full
>> control over the host.
> hhmm, ok. is there a way to let e.g. klist show this? it now says
> 'userlogin at REALM' in the 'Service principal' column. for the (user,host)
> combo i expected to see a userlogin/fqdn at REALM, like other service tokens.
> 
> anyway, clearly i'm missing something here.

The important field is 'Default principal:' which is above the list of
tickets. It contains name of the principal "who you are".

Rest of the list shows just service tickets which are used to authenticate you
to the services listed in the list. It just means that you tried to contact
them some time ago (or called kvno explicitly).

Please go and read some articles about Kerberos protocol, e.g. the Wikipedia
article I linked below. It will explain a lot of things.

Petr^2 Spacek

> 
> 
> stijn
> 
>>
>> Please see
>> https://en.wikipedia.org/wiki/Kerberos_(protocol)#Client_Service_Request
>> for further details on this.
>>
>> Does it explain the situation?
>>
>> Petr^2 Spacek
>>
>>>
>>> i'm assuming that retrieval of service tokens for another host is
>>> already not possible? (ie if you have keyatb of fqdn1, you shouldn't be
>>> able to retrieve a token for SERVICE/fqdn2 at REALM).
>>>
>>> stijn
>>>
>>>>
>>>> Petr^2 Spacek
>>>>
>>>>
>>>>>
>>>>> how to clean it up once you know the host is compromised is the subject
>>>>> of the other thread.
>>>>>
>>>>> stijn
>>>>>
>>>>>>
>>>>>> In the case that the host is compromised/stolen/hijacked, you can
>>>>>> host-disable it to invalidate the keytab stored there but this does not
>>>>>> prevent anyone logged on that host to bruteforce/DOS user accounts by
>>>>>> trying to guess their Kerberos keys by repeated kinit.
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>


-- 
Petr^2 Spacek