Ten Suggestions for enterprise system security management and enhancement

Ten Suggestions for enterprise system security management and enhancement

Security management and O & M of enterprise systems involves anti-intrusion and leakage of the company's information systems and data. This is a basic task of great attention to CSO and COO. Although the foundation, once the processing is not in place, it will bring significant data, economic loss or reputational loss to the Enterprise. This article provides 10 practical and effective system enhancement measures for enterprise system security management, which can help enterprise system administrators to discover and handle system risks and vulnerabilities in advance, this ensures the safe operation of the enterprise system beforehand.

1. Remove "." From the running path.

In super user (root) mode, the user must specify that the command being run is what the user wants. In the following scenario, if a user logs on to a Super User, the PATH variable of the user is

.:/Usr/bin:/usr/sbin:/bin:/sbin.

You have created a script containing the following commands in the ls directory:

#! /Usr/bin/ksh

Cp/usr/bin/ksh/tmp

Chown root: bin/tmp/ksh

Chmod 6755/tmp/ksh

Rm-f ls

/Bin/ls $ *

Now A user calls and reports an issue. There are some unknown files in his home directory. As a super administrator, run the cd command to enter his directory and run the ls-l command to view the directory. Suddenly, without the user's knowledge, user A can run A shell script to obtain the user's superuser permissions!

This often happens, but it is easy to avoid. If there is no "." In the user's path, the user will see a script named ls in his/her main directory, instead of executing it.

2. Risk Avoidance script

When you write a script, you always specify the full path of the application in use. Refer to the following script:

#! /Usr/bin/ksh

Date> log

Find.-mtime + 7-ls-exec rm-rf {}\;>> log 2> & 1

Although there are only three lines and only two lines are executed, there are many security vulnerabilities:

It does not specify a path.

It does not provide the complete path of the date.

It does not provide the complete search path.

It does not provide the full path of rm.

It performs an error check.

It does not verify the correctness of the directory.

Let's take a look at how another script solves some of these problems.

#! /Usr/bin/ksh

Cd/directory | exit-1

PATH =/usr/bin; export PATH

/Usr/bin/date> log

/Usr/bin/find/directory-mtime + 7-ls-exec/usr/bin/rm-rf {}\;\

> Log 2> & 1

Line 2: cd/directory | exit-1, which tells ksh to try to use the CD command to enter/directory. If the command fails, it needs to exit the script and return a-1 code. In the Ksh command | means "if the previous command fails", & means "if the previous command succeeds ". For example, run the command touch/testfile | echo cocould not touch to create a file named/testfile, or if the file cannot be created (maybe the user does not have enough permissions to create it), "cocould not touch" is displayed on the screen ". Run the touch command

/Testfile & echo Created file to create/testfile. If the touch command is successful, only "Created file" is displayed on the screen ". The conditions for User Check determine whether the user is using | or &&.

If the script continues to run, the user enters/directory. Now you can specify the path of the user. If you forget the complete path, you can use the system SEARCH Command to lock it. The example of this method is not in this small script, but it is a good habit, especially when users write long and more complex scripts; if the user forgets to specify the complete path, the probability of the user's script calling the trojan program will be very small.

The full name of the date called by the user is/usr/bin/date. You can also specify/usr/bin/find and/usr/bin/rm. By performing this operation, you can make it more difficult for someone who wants to insert a trojan program into the user's system and run it unconsciously. After all, if they have enough permissions to modify the file/usr/bin, they may have enough permissions to do whatever they want.

When writing a script, you often need to follow these simple rules:

Always specify a path.

The full path is always used for each application.

Always run the error check, especially when running potentially destructive commands, such as rm commands.

3. Keep an eye on easy-to-ignore scheduled tasks

Does the user know what work is running without the user's system being watched? After the system is installed, Many operating systems provide a variety of automated tasks for users to automatically install and configure. Other applications that work over time will run on a regular basis.

To master the user's system, you need to be clear about the program it is running. Periodically reviews programs in the user's scheduled task list file. Many system scheduled task files are stored in/var/spool/cron. The scheduler daemon also supports hourly, weekly, monthly, and annual scheduler tasks, as well as a cron. d directory. Use the man cron command to determine the exact functions of the scheduled task daemon.

Check all files in each directory. Pay attention to the owner of each job. If your scheduled task daemon (crond Service) supports this, lock the scheduled task and make it available only to the user ID you want to use. Note that each file is running and the time it is running. If the user of the plan is not clear, study to determine what the file is and whether the user needs it. If the user is running something that the user thinks they do not need, contact them, ask the reason, and then handle it accordingly.

Keep track of your scheduled jobs and regularly check for any changes. If the user finds that something has changed, investigate and determine the cause. Continuous tracking of what your system is doing is a key step to keep your system secure.

4. logs of all daemon

As we all know, if the daemon does not record any information at the first time, it is useless to save and record logs. By default, some daemon will create logs, but some will not. When the user reviews the user's system, verify that the user's daemon has logged the information.

Logs must be configured for any public daemon, and logs must be saved. Try to access some of your services and view the logs collected by your log server. If not, read the online instruction manual of the service and find the required operation to activate the record. Start it and try to use the service again. Continuously check all services of the user until all logs are recorded and saved.

5. Run CIS Scan

The Internet Security Center (CIS) has created a system Security Benchmark Testing Tool. You can download this tool from www.cisecurity.org to audit your local system and report the analysis results. This tool scans the good and bad results and gives an overall ranking after the scan. Scan tools can be used for Solaris, HP-UX, Linux, Windows, and Cisco routers.

The best part of the CIS Benchmark Test is their explanation. The report does not simply mention "What are users and what are not good "; it tells users why they say it is not good. It allows users to decide whether to disable "Bad Things" or maintain it as is. The benchmark tool may check what many users do not think of and give the user a detailed report of the system.

Download and decompress the CIS tool and read the README and PDF documents. (PDF provides good reference materials for system security .) Install the installation package according to README instructions. After the tool is installed, you should have a directory/opt/CIS. Run the command cis-scan to understand your system. This depends on the speed of the user server and the number of connected hard disks. Scanning may take a long time to complete. After the scan is complete, the user will have a document named cis-ruler-log.YYYYMMDD-HH: MM: SS. PID. This document is a summary of the system and contains all the test results. This document does not include details-this means that you can only use the index to refer to the PDF document that comes with the scanning tool. Review the raudio-log File row by row. If there is a negative result, we recommend that you check in the PDF document whether the change can be performed. Most changes can be implemented without affecting server operations, but not all. Beware of false positives. You may need to use the PortSentry tool to check whether port 515 has a lp vulnerability. This may cause the CIS tool to report that the user has an lp vulnerability. At the end of the report, the higher the number, the stronger the user's system ".

This is a good information security tool. Regular running on the user's server can keep the server healthy. Visit the website of the Internet Security Center. With the constant development and changes of this tool.

6. Avoid superuser privileges during running

Many services running on the server do not require the superuser permission to execute their functions. Generally, they do not need any special permissions to read or write data directories. However, as Unix Security Measures stipulate that the open TCP/IP ports for running with Super User Permissions must be lower than 1024, In addition, most well-known ports are lower than 1024, this means that the user's daemon must open its port with the superuser permission.

There are several solutions to this dilemma. First, the safest thing is not to run all services. If the daemon is not running, it does not need to be run as a Super User. However, this does not work every time. Sometimes users also need to provide running services for the daemon. In this case, create a dedicated user ID to run the daemon and strictly control it as much as possible. Only use this ID to write data to a writable directory, and do not grant this ID a particularly high permission. Then change the startup script. The Daemon only belongs to the new user ID. If attackers exploit this vulnerability to attack the user's server and damage the user's daemon process, the attacker will gain a non-privileged account and must do further work to obtain super user permissions, before more losses occur, the user will be given more time to track and stop him or her.

7. Scan and process high-Permission files

All systems have user ID and group ID files. These files can run applications, scripts, and daemon using specific users or groups, rather than individual user IDs or group IDs. The top command is a good example. It has high operation permissions, so it can scan process information in the kernel space. Because the default permissions of most users cannot read this information, it is necessary to run top with higher permissions.

Many operating systems allow you to specify disks that do not support SUID and SGID. This is usually done by using a command in your system mount file. In Solaris, the nosuid command is specified in/etc/vfstab. For example, if you use the nosuid command to install/users on the disk c2t0d0s3, you can enter the following command:

/Dev/dsk/c2t0d0s3/dev/rdsk/c2t0d0s3/users ufs 2 yes nosuid

This/users installs the boot and disables the SUID and SGID applications. The application can still run, but the SUID and SGID bits are ignored. Disabling SUID and SGID on all file systems is a good security practice.

However, you need to periodically scan your system and obtain a list of all processes that exist in SUID and SGID. The command for searching for SUID is-perms + 4000, while the command for searching for SGID is-perms + 2000. Scan all SUID files on the server and run the following command:

# Find/-type f-perms + 4000-ls

-The type f command is only used to view "regular" files, and cannot view directories or special files in other named pipelines. This command can list the SUID bit settings on each file. Check and verify all output files and files that actually require SUID and SGID. If not, clear the files without hesitation.

8. control open ports

Before you publish a user's system to the outside world, you need to know which ports are open and allow connection. Some ports are opened without your knowledge. Users should disable them before they access the user's server through these ports. There are some tools that let users know that their systems are exposed.

You can use the Netstat tool for troubleshooting. The Netstat command is attached to almost every operating system. Netstat is a simple tool that displays your network information, such as network ports, route tables, and network connection information. The Netstat tool displays all ports under/etc/services that have been defined by similar names, making it easier to parse and export. This is a good reason to ensure that/etc/services is continuously updated on the user system. Use the man command on your system to discover the capabilities of netstat.

The following is a simple example:

# Netstat

Local Address Remote Address Swind Send-Q Rwind Recv-Q State

Server. smtp 192.168.3.4 6144 0 65700 0 CONNECTED

In this example, someone connects to the SMTP service of the user server from the IP address 192.168.3.4. Should I run SMTP? Should this person be allowed to connect to the server? Note: major vulnerabilities. When a user opens a remote connection, the user should at least use the TCP Wrappers security mechanism to protect it. Should the user disable it?

# Netstat-a | more

UDP: IPv4

Local Address Remote Address State

Localhost. ntp Idle

TCP: IPv4

Local Address Remote Address Swind Send-Q Rwind Recv-Q State

*. Telnet *. x 0 0 24576 0 LISTEN

It is recommended that you spend some time learning netstat. If you learn how to use it, it will provide you with a wealth of network information and give you a clear picture of who is connected to your system at what time.

Another useful utility is lsof (list of opened files. At first, it was just a simple tool to show which processes opened files, but now it has evolved to display ports, channels, and other communications. Once you have installed the lsof tool, try it. Run only lsof to view all files and ports opened on the system. Users can feel what the lsof tool can do, and it is also an excellent way to quickly review the system. The lsof | grep TCP command displays all TCP protocol connections opened on the system. This tool is very powerful. It is also helpful when you need to uninstall the file system while the file system reports are busy. lsof can quickly show that the process is using the file system.

9. Use a centralized Log Server

If you are responsible for maintaining multiple servers, It is very cumbersome to check the logs of each server. Therefore, a dedicated server is created to collect logs from all other servers. By integrating user logs, you only need to scan one server, which greatly saves your time. This is also a good archive file after your server is cracked. You can still view these log files elsewhere.

Create a core log server and use high-speed CPU and a large amount of disk space. Shut down all ports and services except syslogd, and the probability of damage to the system is minimized. Besides using the TCP-wrapped SSH daemon to restrict remote access to the user's workstation. Then verify that syslogd can receive messages from the remote system. This is different from the message provider server to the Message provider server. Some servers receive messages by default, and users may need to turn it off; some do not receive messages by default, and users need to turn it on.

Create a system to archive old logs and form files. If your logs have been used as evidence, you must be able to prove that they have not been changed, and you need to show how they were created. We recommend that you compress all logs with timestamps for more than one week and copy them through read-only media, such as CD.

Once a user has a server that receives logs, the user needs to start other servers to point to it. Edit/etc/syslog. conf and confirm the information you want to copy. At the very least, users should copy the highest degree of emergency, emergency, important information, critical status and warning information and information that more users think is useful. When you know what information you want to copy, add one or more/etc/syslog. conf command lines like the following:

*. Emerg; *. alert; *. crit; *. err; *. warning; *. notice @ ip. of. log. srvr

In this example, we send all the highest degree of emergency, emergency, important information, critical status, warning and unusual event log information to the remote server. It is worth noting that users can archive logs to remote servers at the same time. You can also copy data to multiple log servers. Syslog. conf scans all matched entries. The syslogd daemon will not stop after the first entry is found.

10. Maintain software updates

Each software has vulnerabilities. Most vendors audit the code and delete all discovered vulnerabilities, but some are inevitably released to the outside world. Some people spend a lot of time trying to find these vulnerabilities. Some people report the vulnerabilities to the vendors, but some people use them by themselves.

In fact, occasionally discovered vulnerabilities are patched to fix them. Unless the vulnerability is serious or there is a known vulnerability attack in the outside world, these patches are usually not announced with great fanfare. The responsibility of the user is to occasionally check which patches are suitable for the user and can be downloaded from the software vendor.

Many manufacturers provide a tool to help you maintain patches on your system. HP-UX has software update management software, Solaris has patchdiag and patchpro, AIX uses SMIT, and so on. Run your diagnostic tools at least once a month to check the patches that can be updated by your system and determine whether to install them. Set aside at least one hour (or more time) for system maintenance every Sunday afternoon to install patches and perform other necessary maintenance.

Users should make it a habit to go to the website frequently to check whether each application installed by users has fixed bugs or released security patches. Use the Application List created earlier to determine whether patches are available for users. After the patch is updated, the user must update the user list.