How do I protect against rootkits

Hi,

I am exploring different security enhanced versions of Linux - SELinux
and LIDS in particular. As far as I understand these help define better
access control policies, which may be effective against simple attacks
that try to modify the file system or exploit vulnerabilities in
running processes.

I do not understand how this can protect against more sophisticated
attacks like the Suckit rootkit that modifies instructions in memory of
the running kernel.

Can somebody enlighten me on this issue ? Is it possible to protect
against these sophisticated kernel modifying rootkits using
LIDS/SELinux or any other model that I am not aware of ?

thanks,
Allison

Hi,

Allison wrote:

> I am exploring different security enhanced versions of Linux - SELinux
> and LIDS in particular. As far as I understand these help define better
> access control policies, which may be effective against simple attacks
> that try to modify the file system or exploit vulnerabilities in
> running processes.

SELinux protects much more than just the filesystem, depending on the
policy.

> I do not understand how this can protect against more sophisticated
> attacks like the Suckit rootkit that modifies instructions in memory of
> the running kernel.

As I understand, a rootkit is the second stage of a attack. First the
attacker has to attack some existing exploit. Then the attacker can deploy
the rootkit, to hide his traces.

SELinux for example doesn't close a existing exploit in a service, but it
can prevent the attacker from accessing other services or the filesystem.
So only the exploited service will be in danger, not the whole system. The
attacker will not be able to deploy the rootkit. In a strict SElinux policy
it even protects against exploits in the kernel, as the access rights of
the root user are very constricted.

Sincerly,
Klaus

"Allison" <fireflyblue@gmail.com> said:
>I am exploring different security enhanced versions of Linux - SELinux
>and LIDS in particular. As far as I understand these help define better
>access control policies, which may be effective against simple attacks
>that try to modify the file system or exploit vulnerabilities in
>running processes.
>
>I do not understand how this can protect against more sophisticated
>attacks like the Suckit rootkit that modifies instructions in memory of
>the running kernel.
>
>Can somebody enlighten me on this issue? Is it possible to protect
>against these sophisticated kernel modifying rootkits using
>LIDS/SELinux or any other model that I am not aware of?

I think the issue is "how do the rootkits get installed in the first
place" -- and that is where LIDS and SELinux help. Once the system is
compromised to the kernel level (or even to the "root access" level),
you've lost the game. LIDS and SELinux may help a bit still even with
the root access compromise, but I wouldn't place too much of my trust
on that protection.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

"Allison" <fireflyblue@gmail.com> (06-07-03 15:56:13):

> I am exploring different security enhanced versions of Linux - SELinux
> and LIDS in particular. As far as I understand these help define
> better access control policies, which may be effective against simple
> attacks that try to modify the file system or exploit vulnerabilities
> in running processes.

You are misunderstanding the intention of access control. They are
useful for multi-user systems, but they cannot protect your system from
breakins. You have to establish a well thought security concept against
attackers from outside first. This includes, for example, setting up
grsecurity and PaX [1] to protect the address space of running services.
That doesn't close bugs, but it helps reducing the damage caused by
them. A buggy Apache will still crash on an attack, but it will not
allow an attacker to get access to the underlying system.


> I do not understand how this can protect against more sophisticated
> attacks like the Suckit rootkit that modifies instructions in memory
> of the running kernel.
>
> Can somebody enlighten me on this issue ? Is it possible to protect
> against these sophisticated kernel modifying rootkits using
> LIDS/SELinux or any other model that I am not aware of ?

The problem is: Once a system is compromised, you cannot trust it
anymore. Even on the most secure system, an attacker _might_ have
placed some kind of rootkit with a totally new technology. Again:
Protect against attacks from the outside as well.

However, the game changes as your system becomes a multi-user system.
In that case, things like SELinux are very useful. Users shouldn't get
more access than necessary to do their work. In particular, _never_
give someone else root access to the system. This is never necessary,
and imposes a very dangerous security risk. If you need someone to
administer your Apache server, give him access to its user account. He
won't need to be root to do this.

By the way, you may want to consider OpenBSD [2] instead of Linux. It's
much more secure by default and also had a very good security history.


Regards,
E.S.


---

[1] http://www.grsecurity.net/
[2] http://www.openbsd.org/

So, if I protect my services using grsecurity and pax, the attacker
cannot compromise any services running on my machine. If I am careful
not to visit shady websites and not download email attachments, what
are the other ways the attacker can compromise my system? I am mostly
looking at random attacks here (discovering my ip through a portscan
and finds my machine is vulnerable)

Could OS vulnerabilities can be one way ? Can people think of other
ways and how to protect against those ?

thanks,
Allison



Ertugrul Soeylemez wrote:
> "Allison" <fireflyblue@gmail.com> (06-07-03 15:56:13):
>
> > I am exploring different security enhanced versions of Linux - SELinux
> > and LIDS in particular. As far as I understand these help define
> > better access control policies, which may be effective against simple
> > attacks that try to modify the file system or exploit vulnerabilities
> > in running processes.
>
> You are misunderstanding the intention of access control. They are
> useful for multi-user systems, but they cannot protect your system from
> breakins. You have to establish a well thought security concept against
> attackers from outside first. This includes, for example, setting up
> grsecurity and PaX [1] to protect the address space of running services.
> That doesn't close bugs, but it helps reducing the damage caused by
> them. A buggy Apache will still crash on an attack, but it will not
> allow an attacker to get access to the underlying system.
>
>
> > I do not understand how this can protect against more sophisticated
> > attacks like the Suckit rootkit that modifies instructions in memory
> > of the running kernel.
> >
> > Can somebody enlighten me on this issue ? Is it possible to protect
> > against these sophisticated kernel modifying rootkits using
> > LIDS/SELinux or any other model that I am not aware of ?
>
> The problem is: Once a system is compromised, you cannot trust it
> anymore. Even on the most secure system, an attacker _might_ have
> placed some kind of rootkit with a totally new technology. Again:
> Protect against attacks from the outside as well.
>
> However, the game changes as your system becomes a multi-user system.
> In that case, things like SELinux are very useful. Users shouldn't get
> more access than necessary to do their work. In particular, _never_
> give someone else root access to the system. This is never necessary,
> and imposes a very dangerous security risk. If you need someone to
> administer your Apache server, give him access to its user account. He
> won't need to be root to do this.
>
> By the way, you may want to consider OpenBSD [2] instead of Linux. It's
> much more secure by default and also had a very good security history.
>
>
> Regards,
> E.S.
>
>
> ---
>
> [1] http://www.grsecurity.net/
> [2] http://www.openbsd.org/

"Allison" <fireflyblue@gmail.com> writes:

>So, if I protect my services using grsecurity and pax, the attacker
>cannot compromise any services running on my machine. If I am careful

?? No, you will simply be more protected than you are now. There is always
teh possibility for compromise.

>not to visit shady websites and not download email attachments, what
>are the other ways the attacker can compromise my system? I am mostly
>looking at random attacks here (discovering my ip through a portscan
>and finds my machine is vulnerable)

Make sure that you only run net services you really need. Put up a firewall
to limit those services only those IP addresses you really need them for.


>Could OS vulnerabilities can be one way ? Can people think of other

No idea what that means.

>ways and how to protect against those ?

Keep up to date on the patches.


>thanks,
>Allison



>Ertugrul Soeylemez wrote:
>> "Allison" <fireflyblue@gmail.com> (06-07-03 15:56:13):
>>
>> > I am exploring different security enhanced versions of Linux - SELinux
>> > and LIDS in particular. As far as I understand these help define
>> > better access control policies, which may be effective against simple
>> > attacks that try to modify the file system or exploit vulnerabilities
>> > in running processes.
>>
>> You are misunderstanding the intention of access control. They are
>> useful for multi-user systems, but they cannot protect your system from
>> breakins. You have to establish a well thought security concept against
>> attackers from outside first. This includes, for example, setting up
>> grsecurity and PaX [1] to protect the address space of running services.
>> That doesn't close bugs, but it helps reducing the damage caused by
>> them. A buggy Apache will still crash on an attack, but it will not
>> allow an attacker to get access to the underlying system.
>>
>>
>> > I do not understand how this can protect against more sophisticated
>> > attacks like the Suckit rootkit that modifies instructions in memory
>> > of the running kernel.
>> >
>> > Can somebody enlighten me on this issue ? Is it possible to protect
>> > against these sophisticated kernel modifying rootkits using
>> > LIDS/SELinux or any other model that I am not aware of ?
>>
>> The problem is: Once a system is compromised, you cannot trust it
>> anymore. Even on the most secure system, an attacker _might_ have
>> placed some kind of rootkit with a totally new technology. Again:
>> Protect against attacks from the outside as well.
>>
>> However, the game changes as your system becomes a multi-user system.
>> In that case, things like SELinux are very useful. Users shouldn't get
>> more access than necessary to do their work. In particular, _never_
>> give someone else root access to the system. This is never necessary,
>> and imposes a very dangerous security risk. If you need someone to
>> administer your Apache server, give him access to its user account. He
>> won't need to be root to do this.
>>
>> By the way, you may want to consider OpenBSD [2] instead of Linux. It's
>> much more secure by default and also had a very good security history.
>>
>>
>> Regards,
>> E.S.
>>
>>
>> ---
>>
>> [1] http://www.grsecurity.net/
>> [2] http://www.openbsd.org/

"Allison" <fireflyblue@gmail.com> (06-07-04 08:19:19):

> So, if I protect my services using grsecurity and pax, the attacker
> cannot compromise any services running on my machine. If I am careful
> not to visit shady websites and not download email attachments, what
> are the other ways the attacker can compromise my system? I am mostly
> looking at random attacks here (discovering my ip through a portscan
> and finds my machine is vulnerable)

Wrong. As Unruh pointed out already, PaX protects your services from
being compromised by exploiting most well-known bugs (including
buffer/heap overflows and some similar bugs). Grsecurity (which PaX is
part of) provides you with options to strengthen system security (mostly
local), e.g. role-based access control, trusted path execution, chroot
jail restrictions for root jails, and so on. Very handy, even for
desktops and workstations, where multiple users have access to (maybe
simultaneously, as in my case).


> Could OS vulnerabilities can be one way ? Can people think of other
> ways and how to protect against those ?

I don't understand your question, but I guess you are talking about
system vulnerabilities like kernel bugs. You can protect against
compromisation of certain bugs in user-space (like 'su', 'sudo' or
'cron' bugs), by establishing a well organized access control system
(where grsecurity or SELinux enter the game). Some bugs become
meaningless, when PaX is active. The particular program still crashes,
but does not lead to system compromisation or even information
disclosure.

The story changes for kernel bugs. Some distributions have shown to be
immune against some bugs in the past (like the mremap() bug), but mostly
your system will become insecure, if there are known kernel bugs.
Unfortunately, most severe kernel bugs lead to privilege escalation,
even beyond root level access. You can protect against them by giving
users only as much access as they really need to do their work --
including yourself.


Last, but not least: Keep your system up to date. This includes
utilizing your distribution's package manager as much as possible. Many
people rent a root server, and then install programs by downloading
their source and compiling it by hand. That's a security hazard, as
those programs don't get updated by the package manager. Don't do
this.


Regards,
E.S.