[Freeipa-users] minimise impact compromised host

Petr Spacek pspacek at redhat.com
Wed Nov 16 16:59:02 UTC 2016


On 16.11.2016 17:47, Stijn De Weirdt wrote:
>>> 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.

"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.

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




More information about the Freeipa-users mailing list