[Freeipa-users] IPA over the Internet - Security Implications

[Chris Evich]

On 08/17/2012 07:02 AM, Michael Mercier wrote:
> Hi,
>
> Let us assume just the two systems directly connected to the internet. I
> am specifically interested in what the security implications would be,
> not ways to get around them (e.g. point-to-point tunnel). I have read
> that kerberos was designed for untrusted networks, just how untrusted
> can they be?
>
> Thanks,
> Mike
>
> On 16-Aug-12, at 9:43 PM, Steven Jones wrote:
>
>> Hi,
>>
>> I would assume you could do a point to point tunnel between each and
>> do the authentication via that.
>>
>>
>> regards
>>
>> Steven Jones
>>
>> Technical Specialist - Linux RHCE
>>
>> Victoria University, Wellington, NZ
>>
>> 0064 4 463 6272
>>
>> ________________________________________
>> From: freeipa-users-bounces at redhat.com
>> [freeipa-users-bounces at redhat.com] on behalf of Michael Mercier
>> [mmercier at gmail.com]
>> Sent: Friday, 17 August 2012 1:14 p.m.
>> To: freeipa-users at redhat.com
>> Subject: [Freeipa-users] IPA over the Internet - Security Implications
>>
>> Hello,
>>
>> I was wondering what the security implications would be setting up a
>> server to be a freeipa client at one site, and have it join a freeipa
>> system over the internet at another site.
>>
>> ipaclient (siteA) <-- internet --> ipaserver (siteB)
>>
>> Is there an IPA document that describes this situation?
>>
>> Thanks,
>> Mike

Don't overlook DOS/DDOS type attacks against these servers.  While it 
may not penetrate the encryption, they could limit your options for 
fixing the problem remotely, or even locally.  I'm not aware of/if/how 
well these services are validated against DOS-type attacks.  However, 
even if they are somewhat hardened, simple things like massive 
ping-floods could easily overload the networking stack.

Further, all of these services are heavily dependent on DNS.  I'd worry 
about this just as much as KDC/LDAP, for simple availability problems 
(whatever the attack vector).  This could easily bottle up all other 
traffic, and the short client-side timeouts (6-seconds) aren't helping.

Again thinking beyond just the encrypted traffic, the server processes 
are also exposed with whatever unknown flaws they have.  While they're 
certainly tighter than the average app., I'd pay particular attention to 
keeping them updated, 0-day if possible.  This again can impact 
availability, for example in the case of unknown and unrelated 
regressions in the updates themselves.

-- 
Chris Evich, RHCA, RHCE, RHCDS, RHCSS
Quality Assurance Engineer
e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214