Practical Linux User account cleaning and security methods

Security is a huge and challenging subject, but everyone who works on the server side should know the basic steps. Cameron outlines some ways to keep your user account clean and secure. Security is a big problem. It's not going to 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 keep the doorman from seeing his annual budget, you finally believe that he needs to understand the benefits of security. Regardless of how challenging the trend is in all aspects of computing security, there are several areas that are mature enough to be systematically studied. For anyone who uses a Linux server, the first area that I recommend him to learn is account management. Note that many of your users ' first books on Linux management and programming include a chapter on user management or account management. Their meaning is very clear: how to set up and maintain calculated accounts and group relationships for people who use your host. At that time, "use" necessarily means "login". The whole job of account management is to configure the Linux account with commands such as Useradd, Chsh, and so on, so that it can be used by a user base with a majority of the department's developers. PASSWD and its APIs are the focus of Linux experts. That era is long gone, and my first recommendation to most servers is to clear most of the passwd. I mean, for historical reasons, most e-mail servers, Web servers, file servers, and so on, use passwd to manage their user access. I think it's usually a mistake. Earlier, this was a sensible way to have more than 10 or more than 20 engineers sharing a high-end workstation. However, the traditional passwd approach is a mistake when an e-mail server may have to deal with tens of thousands of of users, most of whom simply consider computing as a common facility like a water dispenser or a telephone system. It is certainly possible to rely on passwd. It has undergone enough tinkering and tweaking to cope with the surprising workload. But not necessarily. If you move user accounts to specialized data stores, 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 passwd to only a handful of developers and administrators who really need to log on. This practice has great security benefits because users of services (e-mail and WEB, etc.) are not as busy as developers. Once you have set up a new server, its passwd should not be changed frequently. Monitor if it's being updated-especially tampering-is a simple task. However, if you are running a larger server, there will be several new and expired e-mail account changes every day. These accounts need to be isolated from the larger access rights granted by passwd. is building an alternative account data store a serious and serious proposition? Indeed, it is surprising. A great deal of work has been done over the past few years to make the very large/etc/passwds, which has a majority of users without the need to log on, work properly. If you do decide to write your own account authentication and rely on traditional e-mail programs like SendMail, you probably find yourself writing changes for the SMTP, POP3, and IMAP4 servers. Those barriers 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 by these industries: I often need to customize them-for example, setting up a special message directory, logging information, or using accounting. The most important thing for me is to make security considerations modular. I want to be able to manage the developer and administrator accounts completely separately from the end user Service. By removing the latter from the passwd, I can easily lock the side without affecting the other side. Automating policies and separating developer accounts from User Services is almost as important as automating the policies. Establish clear and detailed procedures for creating and deleting accounts-both developers (passwd) and end users (e-mail, Web, databases, etc.). While incorporating these into executables is a good rule, it is not entirely necessary. It is important that the process be understandable and clear. Careless account creation and deletion always leave a security hole. You should review your process with human resources, customer support, or other relevant departments. It's hard to realize how critical this is if you don't experience the alternatives yourself. When you do not write procedures for adding and removing user accounts, there is always the result that if a new employee is reported in Monday, he or she may still not be able to access his company files by Friday. Alternatively, someone who resigned and said good-bye at a holiday party could still retrieve a special-purpose company's assets at the start of February. An incidental benefit of account automation is that it encourages more thorough validation. If developers do not have a convenient way to configure accounts with different features, they will most likely not perform those applications that are expected to make the configuration change. I have experienced this recently. I was called in for an emergency, when the implementation team actually "correctly" allows managers to view employee performance reviews-even those that are not part of their management! This is a typical security problem, although it sounds ridiculous. It was even pointed out several times during the analysis and Design review. Although everyHave reflected this problem to policymakers, but because it is part of a huge and confusing set of problems, it is ignored every time without a clear resolution. Errors get due attention only when a support expert finally establishes a concrete example of a generic instance in which several managers, each manager, have multiple employee reports. Do not cramming and periodically test the configuration of all kinds of user accounts. Stay alert. The most difficult part of security, at least for many of us, is how to avoid making mistakes. Security is one of the "weakest links" events, and a vulnerability can worthless all your current investments, however large and planned. To do a safe job, you must be alert to things that you would otherwise not consider. U.S. government websites are often the best example of the severity of that challenge. A federal agency that often appears in the news on the safety of "counter-terrorism" maintains a Web site where user passwords are displayed publicly on pages used to change user preferences. A significant number of organizations address the frequent loss of password problems by assigning passwords based on more or less public information (for example, "Your password is the first four letters of your birthplace plus the latter two digits of your year of birth"). How can you avoid such catastrophic mistakes? Unfortunately, there are few systems that can "intelligently" successfully achieve such abstract goals. However, in the useful steps that need to be taken, it is one of the useful steps to study the mandates digest and the rigorous engineering inspection. Mandates is the online newsletter that Peter G. Neumann has been editing since 1985 (see Resources below). Reading it is a good habit to think about the cause of the error in thinking about things, especially security on Linux servers. Neumann makes the digest easy to read and interesting, of course, and occasionally frightening. You should also develop the habit of letting other people test your ideas. You might think that a "software check" is just a way to find out what punctuation marks are misplaced 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, Web sites, and all other products. Please check. View your work through someone else's eyes. You will probably learn a lot about the security or insecurity of your servers. Responsible Editor: Snowflake (TEL: (010) 68476636-8008) to force (0 votes) (0 votes) of nonsense (0 Votes) Professional (0 Votes) The title of the party (0 votes) passing (0 votes) in the original: Practical Linux user account clean and safe method return to column Recycle Bin Home