Build a Linux desktop-based audio and video platform

Set up an audio and video platform based on the Linux desktop environment-Linux Enterprise Application-Linux server application information. The following is a detailed description. An important aspect of any computer security measure is to maintain the operation of the actual control service. This article shows you how to configure security service management on a Linux PC.

An important aspect of any computer security measure is to maintain the operation of the actual control service. receiving requests from unnecessary network services will increase the security risks of the system. Even if these network services are necessary for some functions of the server, they need to be carefully managed and configured to minimize the possibility of undesirable intrusion and login.

When configuring security for Linux systems, use the/etc/inittab file, runlevels, and two services to manage "superdaemons" such as inetd or xinetd to directly manage services.

Inittab

The/etc/inittab file is used to start system services during system initialization. In a configured system, although it generally does not include many services, many other services will be loaded in the default installation of some Linux systems. The content of the/etc/inittab file is vague. The important thing is to make service management relatively simple.

First, do not add a service to the system startup Item by using the/etc/inittab file.

Second, do not remove the first field in the/etc/inittab file before the first colon is a single-precision number, or the front part of the entire Logon Service. Lines starting with a single-precision number can open the TTY console. All services are listed one by one before they are opened, and even more important functions are listed. In some exceptions, it may be safe to change it, especially if you are not sure.

Third, the/etc/inittab is used for process management during import and runlevel selection. It is generally not used for normal system operations.

Fourth, the rc system starts adding steps during the import, instead of the init system. If you look at the/etc/inittab content, you will notice that the logon ends with a character such as rc0 to rc6. This is a description of how the initialization system handles runlevels.

Runlevels

Runlevels can be used to manage Linux-based operating systems. Different runlevels are defined as having different behaviors. Like a Windows operating system, they have normal operation mode, secure mode, and DOS mode in some cases.

Runlevel 0 is used to shut down the system. If the soft power supply is set properly, it can shut down the system power.

Runlevel 1 is a network-less mode for a single user. It is used for low-level fault repair and management operations.

Runlevel 2 to Runlevel 5 Multi-user mode for normal system operation. Runlevel2 and 3 are in command line mode. 3 has a network connection and 2 has no network connection. Runlevel 5 is used to start X Windows to provide graphical user interfaces.

Runlevel 6 is used for system restart. It is used when the entire init system or even bootloader needs to be restarted.

Other runlevels are defined by the system administrator. However, traditional UNIX systems do not have this function. In this case, they cannot be defined or used.

In shell, you can enter the runlevel command to find the previous renlevel and current runlevel. If the system runlevel is not changed, the output result of the command is the number followed by the runlevel after the capital N. Here, the N indicates that there is no front runlevel. To change the runlevel, you can use the init command, followed by the number of runlevel to be used. For example, if init 6 is input, the system is restarted, or init 1 enters the single-user mode.

The configuration of runlevel varies with version. For example, in the Debian GNU/Linux system. d service scripts are from/etc/rcN. d paths are linked to them. Here, N indicates the runlevel number to be configured. Symlinks starting with K indicate the program killed when entering runlevel, and symlinks starting with S indicate the program started when entering runlevel. The greater the number value after the letter, from 1 to 99, indicates that the start time or killing time is closer to the back.

Most RPM-based versions use the rc system used by RedHat. Compared with Debian-based systems, this system uses a more complex path structure, and different RPM-based systems are also very different. The manual provides more information about runlevel management.

Inetd


A "superdaemon" for Linux background program management is a well-known inetd, which is a command line tool for service management. It is easy to terminate the service: first, use the text editor as the root user to open the/etc/inetd. conf file. Next, find the services to be terminated in the file. Finally, add the # symbol (Other "tip" and "pound character") at the beginning of the service line, as shown below. Comment out this line, so inted will not start this service in the future.

Before editing, the service logon may be as follows:

Ident stream tcp wait identd/usr/sbin/identd

After the service is stopped, the service logon will look like the following:

# Ident stream tcp wait identd/usr/sbin/identd if you are uninstalling the background program for Logon reference, you can delete some lines in the file-whether to uninstall or delete the execution file through the Package Manager (for the above example, the/usr/sbin/identd file ).

Edit the/etc/inetd. conf file and save it. You can change it later. Once editing and saving are completed, you can enter the following command at the root to make the change take effect immediately:

Kill-HUP 'pidofinetd'

Using the modified (saved) configuration file causes inetd to restart.

Xinetd

Another superdaemon called xinetd is more novel and complex than inetd and can complete more functions. However, for service closures, their usage is similar.

When using xinetd, you must add a line to the/etc/xinetd. conf file to close the service. If you only want to delete a service, you must delete several lines of code instead of one line. Locate the block where the service is to be closed, add "disable = yes" to the block, or delete the entire block. For example, if you disable the telnet service, you need to do the following. (The ellipsis here indicates other content of the block)

Service telnet

{

...

Disable = yes

}

In some systems, service configurations for some services are not in the/etc/xinetd. conf file. For example, services such as telnet may be stored in the file/etc/xinetd. d/telnet, change the service configuration method in/etc/xinetd. the methods in the conf file are the same.

After editing and saving the/etc/xinetd. conf file or changing the service file, enter the following command to make the modification take effect immediately:

Kill-USR2 'pidofxinetd'

This will notify the xinetd program to use the changed configuration.

In addition to disabling or removing service configurations, Xinetd can also be used to control remote host login services. This will be done through several mechanisms:

You can specify an allowed host for the service. For example, you can add only_from = 192.168.0.101 to the service configuration file to restrict the host from logging on to the telnet service. Although the word "only" is used, it can only limit the number of hosts, not just one host. You can also use some addresses to specify the complete network. For example, you can use "only_from = 192.168.0.to" to indicate that any host of the local Class C can access this service.

You can specify a prohibited host for a service in the configuration file. For example, you can add "no_access = 192.168.0.102" in the configuration file to prohibit the host from Remotely accessing the telnet service. This can also be used multiple times and multiple hosts can be specified using some addresses. If a host meets the only_from and no_access restrictions, the access permission of the host will be weighed. If xinetd cannot determine which limit can be applied, the system will be more secure by default-the service will not be enabled.

Beyond Service Management

More things can be done for secure remote service access. The firewall should be properly configured to protect services from attacks. Proxy servers, pushing through gateway server ports, and network address transfer can effectively reduce the risk of service attacks. For security purposes, the service tools used to log on to the running Server should also be configured. For example, if the Secure shell is used for remote connection and the X Server is not used, it is important to downgrade X forwarding in SSH. Direct security management is an important part of Linux system security, but it is only part of a comprehensive security plan.