安全不仅仅是技术问题，而是人的问题。许多低级错误竟然经常是由那些应该懂更多的人犯的：系统管理员或其他IT员工。
Intermedia公司《2015内部风险报告》发现：IT专业人士才是最有可能进行“危险”安全操作的人群，比如说共享密码/登录、重复使用个人密码登录业务应用，或者将个人账户凭证交给他人。
有鉴于系统管理员对神一般的控制权限，这类过失发生在他们身上比发生在普通用户身上危险得多。IT专业人士和普通用户一样容易被网络钓鱼、恶意软件和其他攻击攻陷，被盗取的有特权的系统管理员凭证几乎总是能造成严重得多的安全事故。管理员犯错比用户犯错危害大得多。下面给您列出十大常见的安全错误，以及它们的补救措施：
1. 万事用sudo
当你用root登录，你就对面前的金属小盒子拥有了完全控制权。这是极端危险的，因为只要你的凭证被盗，攻击者可以对你的系统为所欲为。
用Windows的说法，只要不执行管理员级的任务就没必要用管理员账户登录。你可以用个人账户登录，然后在需要执行特定命令的时候用sudo，而不是直接以root账户登录系统。
一不小心，故态复萌简直不要太容易。只要一条命令需要sudo，整个脚本就会执行失败——全部都得从头再来。如果你不能搞清哪些命令需要特权而哪些不需要，就很可能又退回到万事用sudo的状态。
2. 运行来源不明的脚本
安装第三方Linux应用是另一个sudo可能被滥用的地方。你要做的仅仅是直接往终端里复制和粘贴命令来启动安装脚本——命令早已设置为利用sudo来执行了。脚本里的每一条命令都将以特权权限执行。
举例如下，直接从网页上复制过来的(URL隐去了)：
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()”
这条命令给网上其他地方托管的东西赋予了sudo权限，以及本地运行Python的权限。极端不建议这么做!!Windows系统管理员面临同样的潜在灾难——执行下载的PowerShell脚本。
即使你信任源，千万别假设从互联网上下载的脚本是安全的。一定要先仔细检查脚本的内容，确认执行这些命令不会引发不良行为。
3. 以root运行特权服务
应用程序永远不应该以root运行。为机器上运行的每个应用程序和服务都创建单独的具有特定权限的服务账户。
服务账户通常都缺少主目录，如果以服务账户登录，对文件系统的操作通常都是受限的。即使攻击者攻陷了服务账户，他/她仍然需要搞定一个本地漏洞利用才能获取更多的权限来执行代码。
每个应用程序都必须使用定制的账户访问数据库，而不是用root或管理员个人账户访问。网页应用应该归属于恰当的组和用户。给Windows应用程序分配域权限时，不要给予管理员级别的权限。
主流Linux版本都默认使用服务账户，但如果管理员手动配置第三方包，很容易就会犯错。要记得在所有的安装和配置都结束后切换许可，确保root或管理员个人账户不再是该应用程序的所有者。
4. 重复使用密码
瞪大双眼准备接受下一波惊吓吧!我们都听过太多在不同网站、系统和应用间重复使用密码的罪恶。但事实总是残酷的，这一问题到了今天依然是个大问题，而系统管理员们也不能免俗。
最近，Mozilla称某未知攻击者闯入了一名特权用户的Bugzilla漏洞跟踪数据库账户，盗取了大约33个关键漏洞的信息。事情真相是：该“特权用户”在另一个网站上重复使用了他的Bugzilla密码，而该密码已经在那个网站的泄露事件中被曝光了。
太多太多次，服务器被设置了弱管理员密码或与该网络中其他机器的密码相同。用常见密码和字典进行暴力攻击会奏效就是因为有足够多的人依然在犯这种低级错误。当多台机器密码相同，问题便叠加了。
系统管理员们不应该在所有机器上都设置相同的root密码，而应该选择使用密钥文件。每台服务器都应有个公钥文件而系统管理员的工作站上应该放有与该公钥文件相关联的私钥。采用这种方式，系统管理员可以访问网络上部署的所有机器，而在网络中横向移动的攻击者只要没有有效密钥便不能登录。而且也拦截不到密码了。
5. 共享管理员账户
管理员账户——诸如访问数据库和管理页面的，常常会在网络内共享。不通过设置环境以便管理员能在需要的时候请求特权，而是乱七八糟地共享管理员账户，那根本就是在自找麻烦。
理想状态下，应该是采用独立账户：一个root账户，然后每个管理员分发一个单独的账户。管理员账户不应该一开始就分配最高级别的访问权限——可以在执行特殊任务时请求特别访问权。Intermedia的报告发现32%的IT专业人员将自己的登录和密码凭证给了其他员工。
不清楚到底是谁在用管理员账户就已经够糟的了，更糟的是：这些密码在管理员离任后竟然还不带改的。由于密码没有经常更换，前同事大模大样地杀回来，造成破坏后从容离去无迹可寻的场景也不是不可能发生。Intermedia的调查发现，1/5的IT专业人士承认自己会在离职后还去访问原公司的信息。密码修改策略不仅仅针对终端用户。要定期修改密码，尤其是管理员和服务账户密码。而且，无论何时，只要管理员离任，请务必重置密码。
6. 故障诊断完后甩手不管
故障诊断的时候，你执行各种花招和试验来找寻并修复问题。在进行这些尝试的时候，你很可能会绕过那些常规的处理过程。问题往往出现在你修复了已发现的问题而进行到下一个任务的时候。管理员总是很匆忙，有可能忘了恢复现场而令事情陷入混乱——给潜在的滥用以可乘之机。
比如说，在试图找出为什么一个应用程序没有响应的时候，你有可能在防火墙中开启了一些端口。当问题修复，你得在这些被临时开启的端口被攻击者利用之前关上它们。同样地，如果你由于SELinux干扰了故障诊断而暂时关闭了它，记得在你完工之后重新启动它。
故障诊断之时，记录下你所做的改动，这样便能在之后将各种设置恢复到原始的状态——除了你真的需要做出的那些修改。
7. 未能跟踪日志文件
日志文件很有用，尤其是在故障诊断的时候，因为它们能让你看到最细粒度层次上发生的事情。当你不再需要这些日志文件，请停止产生它们的进程。相信我，你最不想看到的事情之一，就是调试进程一直开启，不停产生那些包含了可能对攻击者也有用的信息的日志文件。
作为最佳实践，要记得总是记录下有哪些日志被创建了，做到对其中的信息类型心中有数。
8. 在文本文件中存储密码
要记的密码太多时，很容易就会把它们都记在文本文件中。对四处窥探的攻击者而言，这简直就是叩开各种系统的天赐神物。这种做法的后果十分明显，但大家基本都听说过那么一两个将所有重要密码记录到文本文件中的例子。
如果密码必须以明文保存到某个文件中(比如某个应用程序的数据库凭证)，设置文件权限以限制能查看该文件内容的用户。另外，确保数据库账户是一个只有最低权限的服务账户。
9. 留下闲置账户
过期的，限制的账户就是些碍事的东西。可能有软件仅仅是评测了一下就卸载了，但作为安装进程的一部分而添加的账户却一直留在系统中。别那么干。攻击者很可能利用这类被遗忘的账户，尤其是它们还保留有默认密码的时候。
对那些需要留存在系统中但未来不会被使用的账户，可以通过修改密码文件，用一串字符串替换掉账户密码来禁用该账户。显然，当员工离职，必然要进行的一步就是立即撤销他们的账户。
10. 疏于打补丁
金科玉律：安全更新一出，即刻安装(当然，备份好受影响的系统先)。太多太多的服务器不是因为零日漏洞利用被攻陷，而是因为经年的补丁从未打上。
即使是关键服务器，一小段计划维护的停机时间也远比被攻击者成功入侵后的数小时乃至数天的宕机时间要好得多。补丁发布就应立即测试并创建推出更新的计划任务。
然而，不幸的是，在立即打补丁这件事上你很可能会感到挫败——通常是由于该补丁会让某个遗留应用崩溃。这种情况下，不要简单地耸耸肩，甩一句“太糟了”了事。应及时将情况上报恰当的利益相关者。升级该问题。或许就有方法将服务器隔离至最小风险或者采用新技术降低对遗留产品的依赖呢。
在实际生活中，打补丁有可能就跟政治泥潭一样恐怖。如果有级别比你高的经理级人物下令不对系统进行更新，要确保每个人都知道不打补丁的风险。
不要吝惜您的安全技术
一般情况下，安全技术能帮助阻挡已知惯犯，并在事情变得不正常时帮助将问题暴露出来。或许会有在某个特别的工作站或服务器上不宜运行反病毒或防火墙的情况，但这种情况相当罕见。
考虑到当下有多种DDoS恶意软件肆虐，就因为Linux Web服务器没有工具阻拦坏东西的入侵而感染这些服务器，安全技术应该被部署到所有终端以保护所有用户——高层管理人员、一线工人、系统管理员和其他有着特殊权限的个人，不受攻击的侵害。
尽量保持机器的干净清洁。卸载那些你用不着的应用程序以便在机器上不留下被遗忘的账户或工具。我们的目标是让系统尽可能地干净以最小化攻击界面。仅仅需要一个小错，一瞬间的疏忽大意，所有努力都可能付诸东流。
安全工具能帮你看清网络中正在发生的事件。可以使用Nmap扫描那些可能在故障诊断会话中被打开的端口。检查哪些机器缺失了哪些补丁，制订出修复计划。
有工具可以告诉你哪儿出了问题，给你在攻击者乘虚而入之前修复问题的机会。但世界上所有的安全技术都帮不了你——如果系统管理员不以身作则遵守那些他们为大家制定的规则的话。
