Linux Intrusion Monitoring system LIDS principle (1)

The last time I released the linux Intrusion Monitoring system LIDS, it was very busy and messy. maybe you can't see anything. Now I am sorting out other materials. Now I have a part of it. I will show it to you later. 1. intrusion with the increase of linux hosts on the internet, more and more

The last time I released the linux Intrusion Monitoring system LIDS, it was very busy and messy. maybe you can't see anything. Now I am sorting out other materials. Now I have a part of it. I will show it to you later.

I. intrusion

With the increase of linux hosts on the internet, more and more security vulnerabilities are discovered on the current GNU/linux system. You may have heard of bugs found in linux on the internet, which may cause the system to be easily attacked by hackers.

Because linux is an open code system, it is easy to discover vulnerabilities and patch them out quickly. However, when the vulnerability is not published, the administrator is too lazy to patch the vulnerability. Hackers can easily attack the system and obtain root permissions. in the current GNU/linux environment, hackers can do anything they want. Now you can ask, what can we do now?

1. 1 What are the current GNU/linux errors?

L a super user will abuse his power and can do everything he wants to do. As root. It will change everything.

L many system files are easily changed. These files may be very important files, such as/bin/login. if a hacker enters, he can upload a login program to overwrite/bin/login, in this way, he can log on to the system without the login name and password. However, these files do not need to be changed frequently unless you want to upgrade the system.

L module modules is easily used to interrupt the kernel. The module is designed to make the Linux kernel more modular and more efficient. However, when a module is added to the kernel, it becomes a part of the kernel and can do the work that the original kernel can do. Therefore, some unfriendly code can be written as a module to be added to the kernel, and the code will redirect the system call and run as a virus.

L The process is unprotected. some processes, such as the web server in the background, are always considered as programs without strict protection. Therefore, they will be easily attacked by hackers.

1. 2. what is the idea of LIDS.

L protect important files. Because files are easily changed by the root user, why not perform strict file operations? Therefore, LIDS changes the security system calls of the file system in the kernel. If a person accesses a file at some time, he will access the system call and then we can check the file name and see if they are protected. If it has been protected, we can reject the visitor's request.

L protect important processes. This idea is not the same as that of the above process of protection. When a process runs in a system, it will have an entry in the/proc file system that uses pid as the path name. So, if you use "ps? Axf "you can display the currently running process. You can ask if you want to protect these processes. If you want to kill a process, first type "ps" to get the PID of the process, and then type "kill" pid "to kill it. However, if I don't let you see a process, how do you kill it? Therefore, LIDS uses hidden processes to protect it.

Another important method is to prevent anyone from killing the process, including the root user. LIDS can protect all processes whose parent process is init (pid = 1.

L encapsulate the kernel. Sometimes we need to add some necessary modules to the kernel for use. In addition, we also need to reject anyone, including the root user, from inserting modules into the kernel. How can we balance this contradiction? We can only insert modules when the system starts, and then encapsulate modules. after encapsulation, no one in the kernel can insert modules into the kernel. With this encapsulation function, we can use it to protect important files and processes. we can only allow necessary processes when the system is started and only change necessary files. After the kernel is encapsulated, we cannot modify the file.

II. file system protection

2.1 protecting file systems is one of the important functions of LIDS. This function is implemented at the VFS (Virtual File System) layer of the kernel. we can protect all types of file systems, such as EXT2 and FAT.

In LIDS, protected files are classified into the following types:

L read-only files or directories. Read-only files mean they are not allowed to be rewritten, for example, in the directory/usr/bin,/sbin. Most of these types of files are binary system programs or system configuration files. We do not need to change these files when upgrading the system.

L only files or directories can be added. These files are those that can only increase the size. Most of them are system Daily value files. for example, only files can be added to/var/log.

L additional files or directories, which are not protected. In general, you want to protect all files in the directory, but you still need some special files not to be protected. Therefore, we can define these files as additional read-only files.

L protects file systems from being mounted or detached. When you mount a file system at startup, you can prohibit everyone, even root, from detaching the file system. You can also prohibit anyone from attaching a file system to the current file system to overwrite it.

2.2 How does LIDS protect files in the kernel?

In this section, we will see some kernel code to understand how LIDS protects files.

Linux file system data structure program

First, we must understand the virtual file system of linux.

Every file in linux has a node inode no matter what it looks like. the file system provides the following data structure.

In/usr/src/linux/include/linux/fs. h

Struct inode {

Struct list_head I _hash;

Struct list_head I _list;

Struct list_head I _dentry;

Unsigned long I _ino; ----> inode number.

Unsigned int I _count;

Kdev_t I _dev; ----> device number.

Umode_t I _mode;

Nlink_t I _nlink;

Uid_t I _uid;

......

}

Note: it is used to identify a node inode. This means that you can use a pair to obtain the unique inode in a system.

In/ur/src/linux/cinclude/linux/dcache. h

Struct dentry {

Int d_count;

Unsigned int d_flags;

Struct inode * d_inode;/* Where the name belongs to-NULL is negative */

Struct dentry * d_parent;/* parent directory */

Struct dentry * d_mounts;/* mount information */

Struct dentry * d_covers;

Struct list_head d_hash;/* lookup hash list */

Struct list_head d_lru;/* d_count = 0 LRU list */

Struct list_head d_child;/* child of parent list */

Struct list_head d_subdirs;/* our

......

}

Dentry is the entry to a directory file. Through this portal, we can easily move under the parent directory of the file.

For example, if the inode of a file is (struct inode *) file_inode, if you can use file_inode-> d_entry to get its directory entry, and use file_inode-> d_entry-> d_parent to get the directory entry of the parent directory.

LIDS protects the data structure.

After analyzing the linux file system, let's take a look at how LIDS supports VFS to protect files and directories.

In/usr/src/linux/fs/lids. c

Struct secure_ino {

Unsigned long int ino;/* the inode number */

Kdev_t dev;/* the dev number */

Int type;/* the file type */

};

The above structure uses a pair of nodes to store and protect files or directories. "Type" indicates the file type of the protected node.

LIDS has four types

In/usr/src/linux/include/linux/fs. h

# Define LIDS_APPEND 1/* append only file */

# Define LIDS_READONLY 2/* Read Only File */

# Define LIDS_DEVICE 3/* Protect MBR Writing to device */

# Define LIDS_IGNORE 4/* Ignore the protection */

Through the secure_ino structure, we can easily implement the files that are protected or execute the following functions in the kernel.

In/usr/src/linux/fs/lids. c

Int lids_add_inode (unsigned long int inode, kdev_t dev, int type)

{

If (last_secure = (LIDS_MAX_INODE-1 ))

Return 0;

Secure [last_secure]. ino = inode;

Secure [last_secure]. dev = dev;

Secure [last_secure]. type = type;

Secure [++ last_secure]. ino = 0;

# Ifdef VFS_SECURITY_DEBUG

Printk ("lids_add_inode: return % dn", last_secure );

# Endif

Return last_secure;

}

As you can see in the code above, it is very easy to add secure_ino to a node. Protected nodes will be first activated when the system starts. The initialization program is in init_vfs_security () of/usr/src/linux/fs/lids. c.

Now, let's see how LIDS checks whether a node is protected.

In/usr/src/linux/fs/open. c

Int do_truncate (struct dentry * dentry, unsigned long length)

{

Struct inode * inode = dentry-> d_inode;

Int error;

Struct iattr newattrs;

/* Not pretty: "inode-> I _size" shouldnt really be "off_t". But it is .*/

If (off_t) length <0)

Return-EINVAL;

# Ifdef CONFIG_LIDS

If (lids_load & lids_local_load ){

Error = lids_check_base (dentry, LIDS_READONLY );

If (error ){

Lids_security_alert ("Try to truncate a protected file (dev % d, inode % ld )",

MAJOR (dentry-> d_inode-> I _dev ),

MINOR (dentry-> d_inode-> I _dev ),

Dentry-> d_inode-> I _ino );

.....................

This is an example of how to add LIDS to the kernel for detection. You will see that lids_check_base () is a core function of the LIDS protection method.

You can see that many LIDS protection methods use the lids_check_base () function, especially in linux