Ken Foskey wrote:
One of Debian SysAdmins has established that the intruder "seemed to sniff.." the
I am unsure how this would have prevented the attack on the kernel that was applied? Please explain.
password of unprivileged user, use that user to access the server 'klecker', then
escalated privileges to root by exploiting a bug in Linux Kernel and then did
what he did. To avoid anxiety for those who are yet unaware, Linux Kernel
affected are those prior to 2.4.23, and this means this bug can ONLY be
exploited if an attacker has gained unpriviledge access to Linux Machine.
With the intruder having acquired unprivileged access to system, he/she could
have been confined to limited sets of functions because that is one of the things
that SELinux does. Because he/she is restricted in what can be done it will
take a bit longer to figure out ( I assume ) how to escalate privileges to root. In
the meantime the SysAdmin who does what he does will notice unusual
activities within his system and so, the intruder could have been detected before
doing damage to the Servers. I was just theorising as I am 'wiser after the
fact' as some are.
Debian SysAdmin seems to believe it is not social engineering but password sniffing.2. Would 'kerberos' have prevented this sort of break-in ?
The initial attack was by social engineering. One developers key was
compromised due to their lack of security thought. With one weak link in
the chain then it all comes down.
Now, I posed the problem without really knowing the complete details of the circumstances
because 'kerberos' is meant to be the strongest security protection against this sort of
attacks. I gather that 'ssh' which I noticed is the cryptographic security procedure used
at these Debian sites has not prevented the attacks. I note here some differences between
ssh and kerberos:
1. SSH needs local identity files whilst kerberos does not (Attacker has less info to
paly with)
2. SSH does not impose time restrictions on a session whilst kerberos does (Prevents
replay attacks)
3. In SSH the client decides what tools and application to run on the server
whilst in kerberos, the server may restrict the clients from running certain tools and
applications (Ease and simplicity of management as to who and what to allow or
disallow)
This is my understanding of SSH and Kerberos so correct me if I'm wrong.
-- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
