In this chapter, we will show you how to configure the 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.
This file is needed when you configure your kernel with
[*] Send security alerts through network (NEW)
"lidsadm -P"and It is nessary when you configure the kernel with
Note: you should run "lidsadm -P" before rebooting the kernel if you want to switch the lids protection level.
[*] Allow switching LIDS protections (NEW)
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:
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,
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 -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 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).
Usage lidsadm -A -s SUBJECT_PROGRAM -o OBJECT_PROGRAM -j READ/WRITE/APPEND # lidsadm -A -s /bin/login -o /etc/shadow -j READ
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
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
This type used to define an object can be write to a subject.
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
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.
LIDS can protect the process whose parent is init(pid=1), you must configurate the capability (/etc/lids/lids.cap) as below.
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
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.
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,
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.
allow ioperm/iopl and /dev/port access, allow /dev/mem and /dev/kmem access and allow raw block devices (/dev/[sh]d??) access
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.
For the security reason, we should disable this to disallow changing network configuration. When it disallow, the firewall rules will not allow to change.
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
we can enable a capability to set "+" in front of the capability name or "-" to disable the capability.
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.
### 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
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
to make XF86_SVGA has the capability of CA_SYS_RAWIO while other program is unable to obtain the CAP_SYS_RAWIO.
# lidsadm -A -s /usr/X11R6/bin/XF86_SVGA -t -o CAP_SYS_RAWIO -j INHERIT
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,
LIDS provide some network security enhancement.
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.
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.
When LIDS detect some thing violate the rules defined, it can response to the action by following method.
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.
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
In this example, the SMTP server to relay the server is 126.96.36.199, port 25. The mail source is used for EHLO identification.
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=188.8.131.52: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
When user violate the rules, the console will shutdown the user's console.