System administrators must not make these ten security mistakes
mob604757044d68 2021-07-20 04:40:34

Security is not just a technical issue , It's about people . Many low-level mistakes are often made by people who should know more : System administrator or other IT staff .


 picture


Intermedia company 《2015 Internal risk reporting 》 Find out :IT Professionals are the ones most likely to “ dangerous ” People who operate safely , Like sharing passwords / Sign in 、 Log in to business application by using personal password repeatedly , Or give the personal account voucher to others .


In view of the system administrator's general control over God , It's a lot more dangerous for them than it is for ordinary users .IT Professionals are as vulnerable to phishing as ordinary users 、 Malware and other attacks , Stolen privileged system administrator credentials can almost always cause much more serious security incidents . The administrator's mistake is much more harmful than the user's mistake . Here's a list of Top ten common Security error , And their remedies


1. Everything works sudo


When you use root Sign in , You have full control of the little metal box in front of you . It's extremely dangerous , Because as long as your credentials are stolen , Attackers can do whatever they want with your system .


use Windows That's what I'm saying , As long as you don't perform administrator level tasks, you don't need to log in with an administrator account . You can log in with your personal account , Then use the sudo, Instead of just root Account login system .


carelessly , It's not easy to relapse . Just one command needs to be sudo, The entire script will fail —— It's all over again . If you can't figure out which commands need privileges and which don't , It's likely to go back to everything sudo The state of .


2. Run scripts from unknown sources


Install third party Linux Applications are another sudo Where it can be abused . All you have to do is copy and paste commands directly into the terminal to start the installation script —— The command has been set to use sudo Here we go . Every command in the script will be executed with privileges .


Examples are as follows , Copied directly from the web page (URL Hidden away ):


sudo -v && wget -nv -O- https://xxx/xxx/linux-installer.py | sudo python -c "import sys; main=lambda:sys.stderr.write('Download failed\n'); exec(sys.stdin.read()); main()"


This command gives something hosted elsewhere on the Internet sudo jurisdiction , And local operation Python Authority . It's extremely not recommended !!Windows System administrators face the same potential disaster —— Execute downloaded PowerShell Script .


Even if you believe in Ren Yuan , Never assume that scripts downloaded from the Internet are safe . Be sure to check the content of the script first , Make sure that the execution of these commands does not lead to bad behavior .


3. With root Run the privilege service


Applications should never be root function . Create a separate service account with specific permissions for each application and service running on the machine .


Service accounts usually lack a home directory , If you log in as a service account , Operations on the file system are usually limited . Even if the attacker has captured the service account , He / She still needs to fix a local exploit to get more permissions to execute code .


Each application must access the database with a custom account , Rather than using root Or administrator personal account access . Web applications should belong to the right groups and users . to Windows When an application assigns domain permissions , Don't give administrator level permission .


Main stream Linux All versions use the service account by default , But if the administrator manually configures the third-party package , It's easy to make mistakes . Remember to switch licenses after all installation and configuration is complete , Make sure root Or the administrator's personal account is no longer the owner of the application .


4. Reuse passwords


Open your eyes and get ready for the next shock ! We've all heard too much about it on different websites 、 The sin of reusing passwords between systems and applications . But the truth is always cruel , This problem is still a big one today , And system administrators are not free from vulgarity .


lately ,Mozilla Said an unknown attacker broke into a privileged user's Bugzilla Vulnerability tracking database account , Stolen about 33 Information about a key vulnerability . The truth is : The “ Privileged users ” Repeated his... On another website Bugzilla password , And the password has been exposed in the leak of that website .


Too many, too many times , The server is set with weak administrator password or the same password as other machines in the network . Violent attacks with common passwords and dictionaries work because enough people are still making such low-level mistakes . When multiple machines have the same password , The problems are superimposed .


System administrators should not set the same... On all machines root password , Instead, choose to use the key file . Each server should have a public key file, and the system administrator's workstation should have the private key associated with the public key file . In this way , System administrators can access all the machines deployed on the network , The attacker who moves horizontally in the network can't log in as long as he doesn't have a valid key . And I can't intercept the password .


5. Shared administrator account


Administrator account —— Such as accessing databases and managing pages , It's often shared within the network . Not by setting the environment so that administrators can request privileges when they need to , It's a mess of sharing administrator accounts , That's just asking for trouble .


ideally , It should be a separate account : One root Account , Then each administrator distributes a separate account . The administrator account should not be assigned the highest level of access right from the beginning —— You can request special access while performing special tasks .Intermedia Report discovery for 32% Of IT Professionals give their login and password credentials to other employees .


It's bad enough not to know who's using the administrator account , To make matters worse : These passwords did not change even after the administrator left office . Because the password doesn't change very often , The former colleagues came back in a big way , It's not impossible to leave without trace after causing damage .Intermedia 's findings ,1/5 Of IT Professionals admit that they will visit the information of the original company after leaving . Password modification policies are not just for end users . Change the password regularly , Especially administrator and service account passwords . and , No matter when , As long as the administrator leaves , Be sure to reset the password .


6. After the fault diagnosis, I'll leave it alone


When it comes to troubleshooting , You perform tricks and experiments to find and fix problems . In making these attempts , You're likely to bypass the normal processing . Problems often occur when you fix a problem you've found and move on to the next task . Administrators are always in a hurry , It's possible to forget to get back to the scene and mess things up —— Give an opportunity to potential abuse .


for instance , When trying to figure out why an application is not responding , You may have opened some ports in the firewall . When the problem is fixed , You have to close these temporarily opened ports before they can be used by attackers . similarly , If you are due to SELinux It interferes with the fault diagnosis and temporarily turns it off , Remember to restart it when you're finished .


When it comes to fault diagnosis , Record your changes , In this way, the various settings can be restored to the original state later —— Except for the changes you really need to make .


7. Failed to trace log file


Log files are useful , Especially in fault diagnosis , Because they let you see what's going on at the most fine-grained level . When you no longer need these log files , Please stop the process that generated them . believe me , One of the last things you want to see , The debugging process is always on , Keep generating log files that contain information that might be useful to attackers .


As best practice , Remember to always record which logs have been created , Be aware of the types of information .


8. Store passwords in text files


When there are too many passwords to remember , It's easy to write them all down in a text file . For attackers who snoop around , It's like tapping on the godsend of all kinds of systems . The consequences of this approach are obvious , But you've almost heard of one or two examples of recording all important passwords into a text file .


If the password has to be saved in clear text to a file ( For example, the database credentials of an application ), Set file permissions to restrict users who can view the contents of the file . in addition , Make sure that the database account is a service account with minimum privileges .


9. Leave idle accounts


overdue , Restricted accounts are just things that get in the way . There may be software that just needs to be evaluated and then unloaded , But the account added as part of the installation process remains in the system . Don't do that . Attackers are likely to take advantage of such forgotten accounts , Especially when they still have a default password .


For those accounts that need to be kept in the system but will not be used in the future , You can change the password file , Disable the account by replacing the account password with a string . obviously , When an employee leaves , The inevitable step is to cancel their accounts immediately .


10. Neglect to patch


golden rule and precious precept : A security update , Install now ( Of course , Backup the affected system first ). Too many servers are not trapped by zero day exploits , It's because it's never been patched for years .


Even critical servers , The downtime of a small period of planned maintenance is also much better than the downtime of hours or even days after the successful intrusion of the attacker . The patch release should immediately test and create a plan task to launch the update .


However , Unfortunately , You're likely to be frustrated with the immediate patching —— It's usually because the patch will crash a legacy application . In this case , Don't just shrug , Throw a word “ It's too bad ” Get things done . The situation should be reported to the appropriate stakeholders in a timely manner . Upgrade the problem . Maybe there is a way to minimize the risk of server isolation, or adopt new technology to reduce the dependence on Legacy products .


In real life , Patching can be as scary as politics . If there is a senior manager who orders not to update the system , Make sure everyone knows the risk of not patching .


Don't skimp on your security technology


In general , Security technology can help block known recidivists , And help expose problems when things go wrong . There may be situations where it is not suitable to run anti-virus or firewall on a particular workstation or server , But it's quite rare .


Considering that there are many kinds of DDoS Malware is rampant , Just because Linux Web Servers have no tools to block the intrusion of bad things and infect these servers , Security technology should be deployed to all terminals to protect all users —— Top management 、 Front line workers 、 System administrators and other individuals with special privileges , Free from attack .


Try to keep the machine clean . Uninstall apps you don't need so that you don't leave forgotten accounts or tools on the machine . Our goal is to make the system as clean as possible to minimize the attack interface . Just one small mistake , A moment of carelessness , All efforts can be wasted .


Security tools can help you see what's going on in the network . have access to Nmap Scan for ports that may be opened in a troubleshooting session . Check which machines are missing which patches , Work out a repair plan .


There are tools to tell you what's wrong , Give you a chance to fix the problem before the attacker takes advantage of it . But all the security technologies in the world can't help you —— If system administrators don't lead by example by following the rules they make for everyone .


Please bring the original link to reprint ,thank
Similar articles

2021-07-20

2021-07-20

2021-07-20