Ensure the security of server configuration files by using RCS

The following describes how to ensure the security of server configuration files-Linux Enterprise applications-Linux server applications. Have you ever been overwhelmed by server faults caused by configuration file changes? Have you ever gotten rid of a server suddenly, but you still cannot remember what kind of virus you had on the configuration file a few weeks ago? Have you ever wondered which administrator's configuration has caused a server fault? Are you afraid of Server failure and dare not modify the configuration file to experiment with the new functions of the server?

If you are confused by the problem above, you should try the RVs (Version Control System ). Similar to the CVS function, the RCS can track file changes and control shared access files when many people work. It is usually used to maintain source code. Compared with CVS, it is only used on a single machine and is very short and concise, and easier to use than CVS. The most recent Linux version of RCS is 5.7. Many releases already come with their rpm packages. If not, or you want to try the new version, you can download it at ftp://ftp.cs.purdue.edu/pub/rcs. Next let's take a look at how to maintain the security of the configuration file with the RCS.

The following uses proftpd. conf in/etc/as an example to describe how to use the RCS. First, create a directory named "RCS" under the/etc directory where proftpd. conf is located, and this directory is used as the repository by the RCS. All historical revisions will be placed under this directory. When you create a backup configuration file for the first time, use ci-I proftpd. conf is initialized. At this time, the RCS will let you enter a description. Please write a description that helps you remember to avoid forgetting it in a few months.
Root @ localhost:/etc # ci-I proftpd. conf
RCS/proftpd. conf, v <-- proftpd. conf
Enter description, terminated with single '.' or end of file:
> This is the origin version of proftpd. conf
>.
Initial revision: 1.1
Done
Root @ localhost:/etc #
After that, the RCS will replace the original proftpd. delete conf. You need to use co proftpd. conf to export it. After export, we cannot modify it. Use ls-l proftpd. conf will find that it is read-only. To modify it, you need to use co-l proftpd. conf will be exported again, then we use ls-l proftpd. conf will find that its attribute has been changed to writable. The difference between the two commands is that the latter locks the file when exporting it to prevent other users from updating it at the same time. In this case, other users attempt to import or export the file will be blocked. The process is as follows:
Root @ localhost:/etc # co proftpd. conf
RCS/proftpd. conf, v --> proftpd. conf
Revision 1.1
Done
Root @ localhost:/etc # ls-l proftpd. conf
-R -------- 1 root 1732 5 28 21:00 proftpd. conf

Root @ localhost:/etc # co-l proftpd. conf
RCS/proftpd. conf, v --> proftpd. conf
Revision 1.1 (locked)
Done
Root @ localhost:/etc # ls-l proftpd. conf
-Rw ------- 1 root 1732 5 28 proftpd. conf
Another user is blocked:
Zwz @ localhost:/etc $ co-l proftpd. conf
Co: RCS/proftpd. conf, v: Revision 1.1 is already locked by root.
Zwz @ localhost:/etc $ ci-u proftpd. conf
Ci: RCS/proftpd. conf, v: no lock set by zwz
After using co-l proftpd. conf to export, We can edit the configuration file. After editing, use ci-u proftpd. conf to import and write the description of the new version.
Root @ localhost:/etc # ci-u proftpd. conf
RCS/proftpd. conf <-- proftpd. conf
New revision: 1.2; previous revision: 1.1
Eneter log message, terminated with single '.' or end of file:
> Modified xxxxx
>.
Done
Root @ localhost:/etc #

After the import operation is complete, the file attributes are changed to read-only. To modify the attributes, you must first use co-l proftpd. conf to export the attributes. A common error is that you forget to use the-l option during the import, but use chmod to manually change the file to writable. In this case, not lock by xxx (User Name) will occur during the import). The solution is to back up the modified file, use co-l to re-export the file, and copy the backup file back to import the new file. The process is as follows:
Root @ localhost:/etc # co proftpd. conf
RCS/proftpd. conf --> proftpd. conf
Revision 1.1
Done
Root @ localhost:/etc # chmod u + w proftpd. conf <--- incorrect operation
Root @ localhost:/etc # vi proftpd. conf
Root @ localhost:/etc # ci proftpd. conf
RCS/proftpd. conf, v <-- proftpd. conf
Ci: RCS/proftpd. conf, v: no lock set by root

Root @ localhost:/etc # cp proftpd. Conf proftpd. conf. backup <-- back up the modified File
Root @ localhost:/etc # co-l proftpd. conf <-- Re-export the file
RCS/proftpd. conf, v --> proftpd. conf
Revision 1.1 (locked)
Writable proftpd. conf exists; remove it? [Ny] (n): y
Done
Root @ localhost:/etc # mv proftpd. conf. backup proftpd. conf
Root @ localhost:/etc # ci-u proftpd. conf
RCS/proftpd. conf, v <-- proftpd. conf
New revision: 1.2; previous revision: 1.1
Enter log message, terminated with single '.' or end of file:
> The 1.2 revision
>.
Done
Root @ localhost:/etc #
Note the following rule: You must use co-l to export the configuration file before editing it, and use ci-u to import the file after editing to ensure that the file is read-only under normal conditions.

You can use co-1-r1.1 proftpd to restore to the previous configuration file. conf, where-r1.x is the version number to be restored. If we modify the version number based on this version, the version number such as 1.1.1.x will be used to generate a new branch during re-import.
Root @ localhost:/etc # co-l-r1.1 proftpd. conf
RCS/proftpd. conf, v --> proftpd. conf
Revision 1.1 (locked)
Done
Root @ localhost:/etc # vi proftpd. conf
Root @ localhost:/etc # ci-u proftpd. conf
RCS/proftpd. conf, v <-- proftpd. conf
New revision: 1.1.1.1; previous revision: 1.1
Enter log message, terminated with single '.' or end of file:
> New branch
>.
Done
Root @ localhost:/etc #

If you modify the configuration file to cause a service failure, you can use rcsdiff to view the difference between the modified configuration file and the previous normal running version, as shown below:
Root @ localhost:/etc # rcsdiff proftpd. conf
RCS file: RCS/proftpd. conf, v
Retrieving revision 1.1
Diff-r1.1 proftpd. conf
15c15
---
> Part 21
Obviously, we can locate the error. In addition, we can use rcsdiff-r1.1-r1.2 proftpd. conf to compare the differences between the two versions.

When there are multiple individuals managing servers, if an exception occurs in the system, you can use rlog to determine which person has performed the operation at what time:
Root @ localhost:/etc # rlog proftpd. conf
RCS file: RCS/proftpd. conf, v
Working file: proftpd. conf
Head: 1.2
Branch:
Locks: strict
Root: 1.2
Access list:
Symbolic names:
Keyword substitution: kv
Total revisions: 2; selected revisions: 2
Description:
This is the origin version of proftpd. Conf
---------------------------
Revision 1.2 locked by: root;
Date: 12:32:22; author: root; state: Exp;
Lines: + 1-1
The 1.2 revision
---------------------------
Revision 1.1 locked by: root;
Date: 12:28:45; author: root; state: Exp;
Lines: + 2-0
The 1.1 revision
With this log, you can quickly find the responsible person for the fault and find out the cause of the fault.

By using the RCS, we can not only simply back up the configuration file, but also make a detailed and rigorous tracking of the configuration file changes, change times, and changes, and their causes. In complex systems, especially systems under the responsibility of multiple people, this information will be very valuable and greatly reduce the workload of administrators when judging and solving service faults.