BUILD A SECURE SYSTEM WITH LIDS: Configure the LIDS system

4. Configure the LIDS system

In this chapter, we will show you how to configure the lids.

4.1 LIDS configuration directory -- "/etc/lids/"

After install lidsadm, you can find that it creates a lids configuration directory in /etc/lids/. When the kernel booting up, the configuration info will be read into the kernel to initial the LIDS system.

lids.conf This is the file to store the LIDS ACLs info. It contain the ACLs to define the object's access type. the item can be added or deleted by lidsadm.
lids.cap This file contain all the capability on the system, you can configure which capability you want to enable or disable on the system by edit this file. You can just set "+" in front of the capability name to enable the system or "-" to disable the capability. When install the system, the lids.cap came with a default value, you should change it with you need.
lids.net This file used for configuring the sending alert mail through network. You can define the SMTP server, port, Message title,etc.
This file is needed when you configure your kernel with
[*] Send security alerts through network (NEW)
lids.pw This file used for storing the password generated by "lidsadm -P" and It is nessary when you configure the kernel with
[*] Allow switching LIDS protections (NEW)
Note: you should run "lidsadm -P" before rebooting the kernel if you want to switch the lids protection level.

4.2 Protect files and directories.

Firstly, you must determine which files you will protect. In most case, you may protect the system binary files and system configuration files, such as /usr/, /sbin/, /etc/, /var/log/.

Secondly, you must decide the way to protect the files. LIDS provide 4 protection type:

DENY access to any body.

The file or directory marked as DENY means that nobody can see or modify it. The most sensity file should be configurate as DENY. For example, we can make /etc/shadow as DENY access to anybody,



Usage 
        lidsadm -A -o file_to_protected -j DENY

# lidsadm -A -o /etc/shadow -j DENY
After reboot or RELOAD the configurate files. you can see,
# ls /etc/shadow
ls: /etc/shadow: No such file or directory

After then, you can make some program can access to the files, for example, when login to the system, the /bin/login file need to read the password from the protected file /etc/shadow, but it has been labeled as DENY, so you can do,



Usage 
        lidsadm -A -s SUBJECT_PROGRAM -o OBJECT_PROGRAM -j READ/WRITE/APPEND
# lidsadm -A -s /bin/login -o /etc/shadow -j READ

After the configurate is in effect * reboot the system of RELOAD the configure file) , you can login onto the system but you can not access the /etc/shadow using other command. It is an example of MAC(mandatory access control).

Read Only Files.

The files marked with Read Only means that nobody can change the files. We can think that the following files are in this catalog, /etc/passwd, /bin/passwd, etc.



USAGE:
lidsadm -A -o file_to_protect -j READ 

example,

1. to protect the whole /sbin/ as read-only.

 # /sbin/lidsadm -A -o /sbin/ -j READ

2. to protect /etc/passwd as read-only

 # /sbin/lidsadm -A -o /etc/passwd -j READ

Append Only Files.

Most of the append only files are system log files, such as /var/log/message ,/var/log/secure. The files can only open with append mode and can not truncate or modify its previous contents.



USAGE:
lidsadm -A -o filename_to_protect -j APPEND

example,

1. to protect the system log files

# /sbin/lidsadm -A -o /var/log/message -j APPEND
# /sbin/lidsadm -A -o /var/log/secure -j APPEND

2. to protect the apache httpd log files

# /sbin/lidsadm -A -o /etc/httpd/logs/ -j APPEND

WRITE

This type used to define an object can be write to a subject.

Mandatory Access Control in file protection

You can define which subject ( program) can access which object(files) with what kind of access mode - READ, APPEND, WRITE.

For example, you can define /home/httpd/ as DENY to anybody and let /usr/sbin/httpd can READ from that directory. In this case, the Web Server can serve as public WEB Server as normal but the contect and program under the /home/httpd/ can not be seen or modified. If the intruder can get the root shell by the security bugs in httpd, he can not even seen the files in the root shell. Even if he can insert some dangerous code in the httpd server by overwrite the stack, he can only read the file under /home/httpd but he can not modified it.




# lidsadm -A -o /home/httpd -j DENY
# lidsadm -A -s /usr/sbin/httpd -o /home/httpd -j READ

Example

Here is the example from LIDS HOWTO by Philippe Biond,



lidsadm -Z
lidsadm -A -o /boot -j READ
lidsadm -A -o /vmlinuz -j READ
lidsadm -A -o /lib -j READ
lidsadm -A -o /root -j READ
lidsadm -A -o /etc -j READ
lidsadm -A -o /sbin -j READ
lidsadm -A -o /usr/sbin -j READ
lidsadm -A -o /bin -j READ
lidsadm -A -o /usr/bin -j READ
lidsadm -A -o /usr/lib -j READ
lidsadm -A -o /var/log -j APPEND

An example lids.conf came with lidsadm package in /etc/lids/ after you install lidsadm, you must run "lidsadm -U" to update the inode/dev value and re-configrate it to fit you requirement.

4.3 Protect processes.

UN-killable process

LIDS can protect the process whose parent is init(pid=1), you must configurate the capability (/etc/lids/lids.cap) as below.


-29:CAP_INIT_KILL

hidden process

You label the process as HIDDEN, so when the process startup, it can not be found by anybody used "ps" or in "/proc".



example,
        lidsadm -A -s /usr/sbin/httpd -t -o CAP_HIDDEN -j INHERIT

4.4 Protect with capability.

Capabilities are like privileges you can give a process. A root process has all the capabilities. But there exists a capabilities bounding set. In a normal kernel, when you remove a capability from the bounding set, nobody can ever use it again, until next reboot. (see http://www.netcom.com/ spoon/lcap for the normal use).

LIDS modifies this behavior to enable you to switch theses on and off, whenever you want. An access to the /proc/sys/kernel/cap_bset is trapped and raise a security alert. lidsadm performs all the job.

You can list all capability in LIDS by running lidsadm, and you can see what the exactly meaning of each capability.

system capability configuration.

The system capability value is stored in /etc/lids/lids.cap. You must edit the file to fit your requirement.

We here discuss two of them,

CAP_SYS_RAWIO With this capability on, we can
allow ioperm/iopl and /dev/port access, allow /dev/mem and /dev/kmem access and allow raw block devices (/dev/[sh]d??) access
When we disable this capability, we can make all process on the system has no any right to the raw device, such as running lilo.
But some process may want this capability to run, such as XF86_SVGA. In this case, we can let the program in the exception list when compile the kernel.

CAP_NET_ADMIN This capability get the following ability,


interface configuration 
administration of IP firewall, masquerading and accounting 
setting debug option on sockets 
modification of routing tables 
setting arbitrary process / process group ownership on sockets 
binding to any address for transparent proxying 
setting TOS (type of service) 
setting promiscuous mode 
clearing driver statistics 
multicasting 
read/write of device-specific registers

For the security reason, we should disable this to disallow changing network configuration. When it disallow, the firewall rules will not allow to change.

Configurate the lids.cap.

we can enable a capability to set "+" in front of the capability name or "-" to disable the capability.



### 0: In a system with the _POSIX_CHOWN_RESTRICTED option defined, this overrides the restriction
### 0: of changing file ownership and group ownership.
#
-0:CAP_CHOWN

### 1: Override all DAC access, including ACL execute access if _POSIX_ACL is defined. Excluding
### 1: DAC access covered by CAP_LINUX_IMMUTABLE.
#
+1:CAP_DAC_OVERRIDE

The example above is to set CAP_CHOWN to disable(-) and enable the CAP_DAC_OVERRIDE(+). You should check the file (lids.cap) carefully to determine which capability you will use and which you will not use.

Labeling individual process with capabilities.

You can labeling process with capability to make the process capable to do something that the system capability has been disable.

For example, you can make CAP_SYS_RAWIO as disable(-) in /etc/lids/lids.cap. But you still need to use X Server which must use this capability to start it. so you can do


# lidsadm -A -s /usr/X11R6/bin/XF86_SVGA -t -o CAP_SYS_RAWIO -j INHERIT

to make XF86_SVGA has the capability of CA_SYS_RAWIO while other program is unable to obtain the CAP_SYS_RAWIO.

Sealing the kernel

After booting the kernel, the system capability is not in effect until you seal the kernel. you *MUST* add the following line in /etc/rc.d/rc.local in RedHat System or other bootup initial file in other system,


#/sbin/lidsadm -I

4.5 Network Security.

LIDS provide some network security enhancement.

network security with capability

With the capability, we can enhance the network security. such as anti snifferring, can not bind to the port lower than 1024, can not change the firewall and routing rules.

so, what I suggest is to view each capability meaning carefully.

Scanner detector in kernel

LIDS provide a scanner detector in kernel in order to detect who had scan your system. The scanner can detect half-open scan, SYN stealth port scan, Stealth FIN, Xmas, or Null scan,etc. Tools like nmap, satan can be detected by the detector.

It is useful when raw socket is disable. In this case, some user space detector based on snifferring will not work. And the detector does not use any socket, it will be more secure than a user space detector.

If you want this feature, you should select it on when compile the kernel.

4.6 Intrusion Responsive system.

When LIDS detect some thing violate the rules defined, it can response to the action by following method.

Logging the message

When someone violate rules, lids_security_log will log a message the klogd, the logging also have the ability to anti_logging_flood. You can set it when compile the kernel.

Logging the message via mail server

Now, LIDS has a new feature to mail the message to your mail account. you can define the mail server IP, the out-coming mail address,etc, in the /etc/lids/lids.net, more detail please refer to that file.

Here is an example



MAIL_SWITCH=1

# MAIL_RELAY=hex IP:port
# IP11.1 of the machine that will be directly connected by LIDS
# for relaying its mails. Port is usually 25, but who knows...
MAIL_RELAY=210.73.88.149:25

# MAIL_SOURCE=source machine :
# Name of the source machine, used for the ehlo identification.
# Note that a bad name here could make the mail relay refuse your
# mails.
MAIL_SOURCE=lids.chinacluster.com

In this example, the SMTP server to relay the server is 210.73.88.149, port 25. The mail source is used for EHLO identification.

Handup the console

When user violate the rules, the console will shutdown the user's console.

Next Previous Contents