Remote audit clients on RHEL 5.2

Remote audit clients on RHEL 5.2

[Dan Gruhn]

[-- Attachment #1: Type: text/html, Size: 3788 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Remote audit clients on RHEL 5.2

[Steve Grubb]

On Thursday 12 February 2009 12:01:33 pm Dan Gruhn wrote:
> I'm not much of a wiz at selinux, but I can tell that the audit_port_t type
> doesn't exist.  I'm stuck here because:
>
>  1) I don;t know how to create new types in selinux
>  2) Even if I figured that out, I don't know how auditd would know to use
> that.
>
>  I've looked at the auditd executable, it has types like this:
>  -rwxr-x---  root root system_u:object_r:auditd_exec_t  /sbin/auditd
>
>  Could someone give me some pointers and/or point me to something I could
> read to get me going?

You need to be using the SE Linux policy from the 5.3 update. Before 5.3, 
auditd never had a listening port and therefore selinux policy prior to it 
wouldn't have setup that type. I also think SE Linux policy may default to 
port 60 even though that port may not be guaranteed in the future.

Another thing that you should do on this is to setup the client's localport to 
bind to a port below 1024 and then set the server's tcp_client_ports to check 
that the ports are bound to that range as a security precaution.

-Steve

Re: Remote audit clients on RHEL 5.2

[Dan Gruhn]

Steve, thanks.

My system is a stand-alone in a secure environment so I can't just run a 
piece of software and get an update, and it is currently locked into 5.2 
as we're working to get it approved by various powers.  Is there any way 
to get the SE Linux policy from the 5.3 update as a separate piece?

Dan

Steve Grubb wrote:
> On Thursday 12 February 2009 12:01:33 pm Dan Gruhn wrote:
>   
>> I'm not much of a wiz at selinux, but I can tell that the audit_port_t type
>> doesn't exist.  I'm stuck here because:
>>
>>  1) I don;t know how to create new types in selinux
>>  2) Even if I figured that out, I don't know how auditd would know to use
>> that.
>>
>>  I've looked at the auditd executable, it has types like this:
>>  -rwxr-x---  root root system_u:object_r:auditd_exec_t  /sbin/auditd
>>
>>  Could someone give me some pointers and/or point me to something I could
>> read to get me going?
>>     
>
> You need to be using the SE Linux policy from the 5.3 update. Before 5.3, 
> auditd never had a listening port and therefore selinux policy prior to it 
> wouldn't have setup that type. I also think SE Linux policy may default to 
> port 60 even though that port may not be guaranteed in the future.
>
> Another thing that you should do on this is to setup the client's localport to 
> bind to a port below 1024 and then set the server's tcp_client_ports to check 
> that the ports are bound to that range as a security precaution.
>
> -Steve
>   

-- 
Dan Gruhn
Group W Inc.
8315 Lee Hwy, Suite 303
Fairfax, VA, 22031
PH: (703) 752-5831
FX: (703) 752-5851

Central Audit Server with Prelude and Prewikka - RHEL5

[Dan Gruhn]

Greetings,

I have a 64 bit EL 5.2 system that I have built and installed all of the 
necessary packages for the latest audit (1.7.11-1), prelude and prewikka.

This all seems to be working fine on the central cluster server and I 
have set up a client in a cluster node to report its audit information 
to the server.  This seems to be working in that I see both the master 
and the node reporting their information in the master's 
/var/log/messages and /var/log/audit/audit.log.  I still have an issue 
with SELinux and the port connection, but I'm running in permissive mode 
for now.

I'm using Prelude and Prewikka to view events and I see the master as a 
sensor/source and its events, but I don't see the node.  I thought that 
once the audit/syslog information was making it to the central files the 
rest would also work but that doesn't seem to be the case.

Steve's "Audit + Prelude HOWTO" has been quite helpful, but it describes 
putting the client and server all on one machine (which I have working) 
and I'm just not getting what to change to add another client.  I don't 
have prelude-manager running on the client, but it seems as though I 
don't need that.  Could someone give me a pointer on where to look for 
the problem?

Thanks,

Dan

Re: Central Audit Server with Prelude and Prewikka - RHEL5

[Steve Grubb]

On Friday 13 February 2009 03:11:26 pm Dan Gruhn wrote:
> I'm using Prelude and Prewikka to view events and I see the master as a
> sensor/source and its events, but I don't see the node.  I thought that
> once the audit/syslog information was making it to the central files the
> rest would also work but that doesn't seem to be the case.

Prelude has its own messaging protocol. It picks things out of its 
configuration files to fill in various fields in its data packets. So, if you 
have the audit-prelude sensor reading aggregated logs, it won't know these 
are coming from all over the place.

To use prelude the way it wants to be setup, you would have the audisp-prelude 
sensor on each machine sending to a central prelude-manager. Let audit send 
its data to its aggregator and prelude send its own data to its aggregator. 
Yes, there will be duplication...but it will work better.

-Steve

Re: Central Audit Server with Prelude and Prewikka - RHEL5

[Dan Gruhn]

Steve,

Thanks for the advice.  I was wondering about duplicating those 
information streams and needed the encouragement to go ahead.

One thing that did come up, I changed a lot of "localhost" references in 
the "Audit + Prelude HOWTO" and in the /etc/prelude/default/client.conf 
files to my actual server name (master) and I also changed a line in 
/etc/prelude-manager/prelude-manager.conf from

listen = 127.0.0.1

to

listen = master

All of these changes required me to revoke my old prelude-manager 
registrations under "localhost" and re-register all of the sensors to 
"master".  Perhaps I didn't need all of this but it is all working now 
(except for my 5.2 SELinux problem).

I'm running prelude-lml on the master and I'll be figuring out if I 
should run it on each node or it will pick up everything from the 
master's /var/log/messages file.  I'm thinking it would be better to 
keep things separate but I'll be testing.

If anyone can tell me if some of those "localhost" changes were not 
necessary it would be helpful to know for future reference.  I could 
update the "Audit + Prelude HOWTO" with what I've found and send it to 
back to Steve if that would be useful.

Dan


Steve Grubb wrote:
> On Friday 13 February 2009 03:11:26 pm Dan Gruhn wrote:
>   
>> I'm using Prelude and Prewikka to view events and I see the master as a
>> sensor/source and its events, but I don't see the node.  I thought that
>> once the audit/syslog information was making it to the central files the
>> rest would also work but that doesn't seem to be the case.
>>     
>
> Prelude has its own messaging protocol. It picks things out of its 
> configuration files to fill in various fields in its data packets. So, if you 
> have the audit-prelude sensor reading aggregated logs, it won't know these 
> are coming from all over the place.
>
> To use prelude the way it wants to be setup, you would have the audisp-prelude 
> sensor on each machine sending to a central prelude-manager. Let audit send 
> its data to its aggregator and prelude send its own data to its aggregator. 
> Yes, there will be duplication...but it will work better.
>
> -Steve
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>   

-- 
Dan Gruhn
Group W Inc.
8315 Lee Hwy, Suite 303
Fairfax, VA, 22031
PH: (703) 752-5831
FX: (703) 752-5851

Re: Remote audit clients on RHEL 5.2

[Dan Gruhn]

I talked with the folks on the fedora-selinux-list and here is the 
result of that discussion:

The text file (auditd.te) for the proper SELinux policy module is as 
follows:
-----------
module auditd 0.0.3;
require {
        class tcp_socket accept;
        type auditd_t;
        attribute reserved_port_type;
        class tcp_socket { name_bind };
}
type audit_port_t;
typeattribute audit_port_t reserved_port_type;
allow auditd_t audit_port_t:tcp_socket { name_bind };
allow auditd_t self:tcp_socket accept;
---------------

Once you have the auditd.te file, you can compile it and check it for 
any errors:

checkmodule -M -m -o auditd.mod auditd.te

If you have no errors, you can then package the .mod file:

semodule_package -o auditd.pp -m auditd.pp

After packaging, insert it into SELinux:

semodule -i auditd.pp

You should now be able to find the policy module using the 
system-config-selinux GUI.

After all of that, the port can be enable under SELinux as per the RHEL 
5.3 release notes:

semanage port -a -t audit_port_t -p tcp 60

My systems are now running clean.  Thanks for the help.

Dan

Steve Grubb wrote:
> On Thursday 12 February 2009 12:48:47 pm Dan Gruhn wrote:
>   
>> My system is a stand-alone in a secure environment so I can't just run a
>> piece of software and get an update, and it is currently locked into 5.2
>> as we're working to get it approved by various powers.  Is there any way
>> to get the SE Linux policy from the 5.3 update as a separate piece?
>>     
>
> I was hoping Dan Walsh would answer...its possible, but I don't know if the 
> selinux people pull it with a bunch of other changes into the reference 
> policy or not. You might be able to just get the 5.3 policy and look for the 
> audit files and transplant them into 5.2 policy and diff against original 52 
> policy to make a patch. You might need to ask on the Fedora-selinux mail list 
> or the NSA selinux policy mail list if no one answers soon.
>
> -Steve
>   

-- 
Dan Gruhn
Group W Inc.
8315 Lee Hwy, Suite 303
Fairfax, VA, 22031
PH: (703) 752-5831
FX: (703) 752-5851