Security is a huge and challenging topic, but everyone responsible for server-side work should be aware of the basic steps. Cameron outlines some ways to make your user account clean and secure. Security is a big problem. It won't be the same, and it's hard to know how much it needs to scale: if you're not careful, when your boss really wants to prevent the janitor from seeing his annual budget, you will eventually believe that he needs it. Understand the benefits of security. No matter how challenging it is to keep up with the trend in all aspects of computing security, there are several areas that are mature enough to be systematically studied. For anyone using a Linux server, the first area I recommend him to learn is account management. Note Your Users Many of the first books devoted to Linux administration and programming include a chapter on User Management or Account Management. Their meaning is very clear: how to set up and maintain computing account and group relationships for people who use your host. At that time, "use" necessarily meant "login." The whole job of account management is to use a command such as useradd , chsh , etc. to configure the Linux account so that it can be used by a group of developers with the same department. /etc/passwd and its API are the focus of Linux experts. //This article comes from the computer software and hardware application network www.45it.com reproduced, please indicate that the era has long been a thing of the past, my first recommendation for most servers is to clear most of /etc/passwd. What I mean is that for historical reasons, most email servers, web servers, file servers, etc., use /etc/passwd to manage their user access. I think this is usually a mistake. Earlier, it was a wise way to have a dozen or more engineers sharing a high-end workstation. However, the traditional /etc/passwd method is an error when an email server may have to handle tens of thousands of users (most of whom simply count the same utility as the drinker or phone system). . It is of course possible to rely on /etc/passwd. It has undergone enough repairs and adjustments to handle the surprising amount of work. But it doesn't have to be. If you move your user account to a dedicated data store, such as LDAP (Lightweight Directory Access Protocol) or even RDBMS (Relational Database Management System) data storage, you can benefit from scalability, security, and maintenance. Limit /etc/passwd to only a few developers and administrators who really need to log in. This practice has great benefits in terms of security because the busyness of users of services (email, web, etc.) is completely different from that of developers. Once you have set up a new server, its /etc/passwd should not be changed frequently. Monitoring whether it is being updated — especially tampering — is a simple task. However, if you are running a larger server, there will be several new and expired email account changes every day. These accounts need to be isolated from the greater access granted by /etc/passwd. Is building a replacement account data store a serious and serious recommendation? Indeed, this is really amazing. In order to make the very large /etc/passwds, which is dominated by users who do not need to log in, work properly, a lot of work has been done in the past few years. If you do decide to write your own account credentials and rely on traditional email programs like sendmail, you're likely to find yourself writing changes for SMTP, POP3, and IMAP4 servers. Those obstacles often make developers tend to use off-the-shelf software. My habit is to use a solution that someone else has written and that I can reuse. However, unlike the servers used in these industries, I often need to customize them—for example, setting up special message catalogs, logging information, or using billing. The most important thing for me is to modularize security considerations. I want to be able to manage developer and administrator accounts completely separate from end user services. By clearing the latter from /etc/passwd, I can easily lock one party without affecting the other. It is almost as important to automate the strategy and separate the developer account from the user service to automate the strategy. To create and delete accounts — both developers (/etc/passwd) and end users (email, web, database, etc.) – establish a clear and detailed process. Although it is a good rule to include these in the executable file, it is not entirely necessary. It is important that the process is understandable and clear. Careless account creation and deletion always leaves a security hole. You should check your process with human resources, customer support, or other relevant departments. If you don't experience the alternatives yourself, it's hard to realize how critical this is. When you don't write a process for adding and removing user accounts, there is always a result: assuming that a new employee reports on Monday, he or she may not be able to access his company files until Friday. Or, someone resigns and makes a goodbye at a holiday party, and can still retrieve special-purpose company assets at the beginning of February. An added benefit of account automation is that it encourages more thorough verification. If developers don't have a convenient way to configure accounts with different features, they probably won't implement those applications that are expected to change the configuration. I have personally experienced this situation recently. I was called for an emergency, when the implementation team actually "correctly" allowed the manager to review employee performance reviews - even those employees who were not under their management! Although it sounds ridiculous, it is a typical security issue. It was pointed out several times even during the analysis and design review. Although this problem is reflected to decision makers every time, because it is part of a large and confusing set of questions, it is ignored every time without a clear resolution. Only when a support specialist finally establishes a concrete example of a general case (in this example, there are several managers, each manager has multiple employee reports), the error gets the attention it deserves. Don't wear a gun; thoroughly test the configuration of all kinds of user accounts on a regular basis. Stay alert The hardest part of security, at least for many of us, is how to avoid making mistakes. Security is one of the “weakest link” events, and a loophole can make all your current investments (no matter how big and how detailed the plan is) worthless. To be safe, you must be alert to things you wouldn't have considered. US government websites are often the best example of the magnitude of the challenge. A federal agency that often appears in the "anti-terrorism" security issue news maintains a website where the user's password is publicly displayed on the page used to change user preferences. A considerable number of organizations address the frequent loss of password problems by specifying passwords based on more or less public information (for example, "Your password is the first four letters of your birth, plus the last two years of your birth year." Bit number"). How can I avoid such catastrophic mistakes? Unfortunately, there are few systematic ways to "smartly" successfully achieve such abstract goals. However, research on RISKS abstracts and rigorous engineering checks are one of the useful steps in the useful steps that need to be taken. RISKS is an online newsletter that Peter G. Neumann has been editing since 1985 (see Resources below). It's a good habit to read about the causes of errors in things (especially the security on Linux servers). Neumann makes the digest easy to read and interesting, and of course it is occasionally horrifying. You should also develop the habit of letting others experiment with your thoughts. You might think that "software checking" is just one way to find punctuation in the developer's source code, but it's actually a very interesting and efficient practice. In particular, inspections are an excellent way to organize peer reviews of requirements documents, websites, and all other products. Please check. View your work through the eyes of others. You will probably learn a lot about the security or insecurity of your server.