2014-01-08 11:11:31 来源:TechTarget中国
企业系统的安全管理运维涉及到公司信息化系统和数据的防入侵、防泄露工作,这是为所有CSO、COO非常关注的基础性工作。虽然基础,但是一旦处理不到位,将会给企业带来重大数据、经济损失或者声誉损失。本文针对企业系统的安全管理,给出了10个非常实用、有效的系统强化措施,能够较好地帮助企业系统管理员发现和提前处理系统可能存在的风险和漏洞,从而在事前保证企业系统的安全运营。
1、从运行路径中去掉“。”
在超级用户(root)模式下,用户必须明确正在运行的命令是用户想要的。考虑下面的场景,用户在哪里登录了超级用户,那么用户的路径变量就是
.:/usr/bin:/usr/sbin:/bin:/sbin.
用户在ls目录下创建了一个包含如下命令的脚本:
#!/usr/bin/ksh
cp /usr/bin/ksh /tmp
chown root:bin /tmp/ksh
chmod 6755 /tmp/ksh
rm -f ls
/bin/ls $*
现在A用户呼叫并上报一个问题,在他的主目录里有些不明文件。用户作为超级管理员,使用cd命令进入他的目录并运行ls -l命令去查看。突然,在用户不知情的情况下,A用户可以运行一个shell脚本来获取用户的超级用户权限!
这样的情况经常发生,但是很容易避免。如果在用户的路径中没有“。”,用户会看到一个名为ls的脚本在他的主目录中,而不会去执行它。
2、规避风险脚本
当用户写一个脚本,总是指定正在使用的应用程序的完整路径。参考下面的脚本:
#!/usr/bin/ksh
date > log
find . -mtime +7 -ls -exec rm -rf {} ; 》 log 2>&1
虽然只有三行,并且只有两行执行命令,然而却存在很多安全漏洞:
它没有指定一个路径。
它没有给出日期的完整路径。
它没有给出查找的完整路径。
它没有给出rm的完整路径。
它执行错误检查。
它没有验证目录的正确性。
让我们再看一下另外一个脚本是如何解决其中的一些问题的。
#!/usr/bin/ksh
cd /directory || exit -1
PATH=/usr/bin; export PATH
/usr/bin/date > log
/usr/bin/find /directory -mtime +7 -ls -exec /usr/bin/rm -rf {} ;
》 log 2>&1
第二行,cd /directory || exit -1,告诉ksh的尝试使用CD命令进入/directory。如果命令失败,它需要退出脚本并且返回一个–1的代码。在Ksh命令中||意味着“如果上个命令失败”,&&则意味着“如果上个命令成功”。举一个额外的例子,使用命令touch /testfile || echo Could not touch创建一个名为/testfile的文件,或者如果文件不能被创建(也许用户没有足够的权限来创建它),那么在屏幕上会显示“Could not touch”。使用命令touch
/testfile && echo Created file来创建/testfile文件,如果touch命令成功,在屏幕上只会显示“Created file”。用户检查的条件将决定用户是使用||还是&&。
如果脚本继续运行,用户将进入/directory。现在用户可以明确指定用户的路径,如果用户忘记了完整路径可以使用系统搜索命令来锁定。这个方法的例子并没有在这个小脚本中,但它是一个很好的习惯,尤其是在当用户写长的并且更复杂的脚本时;如果用户忘了指定完整的路径,用户的脚本调用木马程序几率将会非常小。
接下来用户调用date的全名是:/usr/bin/date。用户也可以完全指定/usr/bin/find和/usr/bin/rm。通过执行此操作,用户可以让希望在用户系统中插入木马程序并且在用户不知觉的情况下运行的人更加困难。毕竟,如果他们有足够的权限来修改文件/usr/bin,他们可能就有足够的权限来做任何他们想做的事情。
当编写一个脚本,经常需要遵循这些简单的规则:
总是指定一个路径。
总是为每个应用程序使用的完整路径。
始终运行错误检查,特别是在运行具有潜在破坏性的命令时,如rm命令。
3、盯紧容易忽视的计划任务
用户知道什么工作在用户的系统无人值守下正在运行吗?当系统安装完成后,许多操作系统都提供了各种各样的自动化任务自动为用户安装和配置。其他工作随着时间推移而增加的应用程序,会定期的运行。
要掌握用户的系统,用户需要清楚的了解它正在运行的程序。定期审核用户的计划任务列表文件中哪些程序正在运行。许多系统的计划任务文件存储在/var/spool/cron中。一些计划任务守护进程另外支持每小时计划任务,每周计划任务,每月计划任务和每年计划任务的文件,以及一个cron.d目录。使用man cron命令来将确定用户的计划任务守护进程的确切功能。
在每个目录检查所有的文件。注意每个工作的所有者,如果用户的计划任务守护进程(crond服务)支持,请锁定计划任务并且只对需要使用的用户ID开放。请注意每个正在运行的文件和它所运行的时间。如果预定的计划用户不清楚,研究来确定到底是什么文件以及用户是否需要它。如果用户正在运行一些用户觉得他们不需要的东西,与他们联系,问其原因,然后进行相应处理。
持续跟踪用户的计划任务作业并且定期检查他们是否有任何的变化。如果用户发现有些事情已经改变了,进行调查并确定原因。持续跟踪用户的系统正在做什么是保持用户系统安全的一个关键步骤。
4、记录所有守护进程的日志
众所周知,如果守护进程不在第一个时间记录任何信息,那么保存和记录日志也是没用的。在默认情况下有一些守护进程会创建日志,有一些则没有。当用户审核用户的系统时,验证用户的守护进程是否记录日志信息。
任何公开的守护进程都需要配置日志,日志需要被保存。试着访问用户的一些服务,查看用户的日志服务器收集的日志。如果没有,阅读该服务的线上说明手册并查找所需的操作来激活记录。启动它,并尝试再次使用该服务。持续检查用户所有的服务直到确保记录和保存了所有的日志。
5、运行CIS扫描
互联网安全中心(CIS)创建了一个系统安全基准测试工具。用户可以从www.cisecurity.org下载这个工具,对用户的本地系统进行审计并报告其分析结果。该工具会扫描到好的和坏的结果,并在扫描结束后给出一个整体排名。扫描工具可用于Solaris, HP-UX,Linux,Windows,以及思科路由器。
CIS基准测试最好的地方是他们给出的说明,报告中并不会只是简单的提到“用户有什么,哪个不好”;它会告诉用户为什么说它不好的更深层的原因,它可以让用户自己决定是否要禁用“坏东西”或维持原样。基准工具可能会检查很多用户没有想到的地方,并且给用户一份系统的详细报告。
下载并解压缩CIS工具,阅读README文档和PDF文档。 (PDF文档针对系统安全提供了很好的参考材料。)按照README文档说明进行安装包安装,工具安装完成后,用户应该有一个目录/opt/CIS。运行命令cis-scan来了解用户的系统。这取决于用户服务器的速度和所连接的硬盘数量,扫描可能需要花很长时间才能完成。扫描完成后,用户将会有一个名为cis-ruler-log.YYYYMMDD-HH:MM:SS.PID的文档。该文档是系统的总结报告,包含了所有的测试结果。其中该文档不包详细信息--这意味着只能作为索引来参考扫描工具自带的PDF文档。逐行审阅ruler-log文件,如果有一个负面的结果,建议在PDF文档中确定是否可以执行变更。大部分变更可以在不影响服务器的操作下实现,但并不是所有。谨防漏报;用户可能需要使用PortSentry工具查看端口515是否存在lp漏洞,这会导致了CIS工具报告用户有lp漏洞的错误。在报告末尾,数字越高用户的系统越“坚固”。
这是一个很好的信息安全工具,定期在用户的服务器上运行可以保持服务器的健康。访问互联网安全中心的网站,随着关注该工具的不断发展和变化。
[page] 6、运行过程避免使用超级用户特权
许多运行在的服务器上的服务并不需要超级用户权限来执行他们的功能。通常,他们不需要任何特殊权限以外的读取和写入数据目录的能力。但由于Unix安全措施规定由超级用户权限的运行的开放的TCP / IP端口必须低于1024,加上这一事实,大多数著名的端口都低于1024,意味着用户的守护进程必须在超级用户权限下开放其端口。
这种困境有几个解决方法。第一,最安全的并不是运行所有的服务。如果守护进程没有运行,那么它不需要作为超级用户运行。然而,这并不是每次都管用的。有时候用户也需要为守护进程提供运行服务。在这种情况下,创建一个专门的用户ID来运行守护进程,并且尽可能的严格控制它。只使用这个ID写入可写的目录,并且不要给这个ID特别高的权限。然后更改启动脚本,守护进程只属于这个新的用户ID。现在如果攻击者利用漏洞攻击用户的服务器并且损害用户的守护进程,攻击者将获得非特权账户并且必须做进一步的工作来获得超级用户权限,在更多的损失发生之前将给予用户更多的时间来跟踪和阻止他或她。
7、扫描并处理高权限文件
所有系统都有设置用户ID(SUID)和设置组ID(SGID)文件。这些文件可以使用特定的用户或组来运行应用程序、脚本和守护进程,而不是个人用户ID或组ID来运行。top命令是一个很好的例子,它的运行权限较高,所以它可以扫描内核空间中的进程信息。因为大多数用户的默认权限不能读取这些信息,top需要运行更高的权限是有必要的。
许多操作系统允许用户的指定某些磁盘不支持SUID和SGID,通常是通过在用户的系统挂载文件中使用一个命令来完成。在Solaris中,用户会在/etc/vfstab中指定nosuid命令。例如,使用nosuid命令将/users安装在磁盘c2t0d0s3上,用户可以输入如下命令:
/dev/dsk/c2t0d0s3 /dev/rdsk/c2t0d0s3 /users ufs 2 yes nosuid
这个/users安装引导并禁用了SUID和SGID应用程序。应用程序仍然可以运行,但是SUID和SGID位将会被忽略。在所有的文件系统上禁用SUID和SGID是一个良好的安全实践。
不过,用户需要定期扫描用户的系统并获得一个所有存在SUID和SGID进程中的列表。查找SUID的命令是:-perms +4000,而查找SGID的命令则是:-perms +2000。在整个服务器扫描所有SUID文件,运行这个命令:
# find / -type f -perms +4000 -ls
-type f命令只是查看“常规”的文件,无法查看目录或通过其他命名管道的特殊文件等。这个命令可以列出每个文件上的SUID位设置。仔细检查和验证所有输出和真正需要SUID和SGID的文件,对于不需要的,毫不犹豫地进行清除处理。
8、掌控开放的端口
在用户向外界发布用户的系统之前,用户需要知道哪些端口是打开的并且允许连接。有些端口是在用户不知情的情况下开放的,用户应该在人们通过这些端口访问用户的服务器之前关闭它们。有一些工具可以让用户知道用户的系统是暴露的。
可以使用Netstat工具来进行排查。几乎每一个操作系统都附带Netstat命令。Netstat是一个简单的工具,可以显示用户的网络信息,如网络端口、路由表和网络连接信息。Netstat工具显示了/etc/services下所有已经被使用类似人名定义的端口,使其更容易解析和导出。这是一个确保用户系统上/etc/services持续更新的好理由。在用户的系统上使用man命令来发现netstat的能力。
下面我们将通过一个简单的例子来说明:
# netstat
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
server.smtp 192.168.3.4 6144 0 65700 0 CONNECTED
在这个例子中,有人从IP地址192.168.3.4连接到用户服务器的SMTP服务。用户应该运行SMTP吗?应该允许这个人连接到服务器吗?注意,重大漏洞。用户打开了远程连接,用户最起码应该使用TCP Wrappers安全机制来保护它。用户应该禁用它吗?
# netstat -a | more
UDP: IPv4
Local Address Remote Address State
localhost.ntp Idle
TCP: IPv4
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
*.telnet *.* 0 0 24576 0 LISTEN
建议用户花些时间去学习netstat吧。如果用户学会了如何使用,它将为用户提供丰富的网络信息,并且让用户清楚地看见是谁在什么时间连接到了用户的系统。
另一个有用的实用程序是lsof (打开的文件列表) 工具。刚开始它只是一个用来显示有哪些进程打开了文件的简单工具,但是现在已经进化到可以显示端口、通道和其他通信。一旦用户安装了lsof工具,尝试一下。只运行lsof来查看系统上打开的所有文件和端口。用户可以感受一下lsof工具能做什么,同时它也是一个快速审核系统的绝佳方式。lsof | grep TCP命令将显示系统上所有打开的TCP协议的连接。这个工具功能非常强大,当用户需要卸载文件系统,而文件系统报告忙碌时也是很有帮助的,lsof可以快速的显示那个进程正在使用该文件系统。
9、使用一个集中的日志服务器
如果用户负责维护多个服务器,那么检查每台服务器的日志将非常繁琐。为此,建立一台专用服务器来搜集其他所有服务器的日志消息。通过整合用户的日志,用户只需要扫描一台服务器,将大大节省用户的时间。在用户的服务器被攻破后,这也是一个好的归档文件;用户仍然可以在别的地方查阅这些日志文件。
创建一个核心日志服务器,使用高速CPU和大量的磁盘可用空间。关闭除syslogd之外的其他所有端口和服务,这个系统受到损害的几率降到最低,可能除了使用TCP-wrapped SSH守护进程来限制用户的工作站进行远程访问。然后验证syslogd可以从远程系统接收消息。这不同于从消息提供服务器到消息提供服务器。有些服务器默认接收消息,用户可能需要关掉它;有些默认不接收消息,用户需要打开它。
创建一个系统来归档旧日志并形成文件。如果用户的日志曾经被用作为证据,用户需要能够证明它们没有被更改过,用户需要出示他们是如何创建的。建议用户压缩一个星期以上的所有带时间戳的日志并且通过只读的媒体,例如CD光盘来复制他们。
一旦用户有了一个接收日志的服务器,用户需要启动其他服务器指向它。编辑/etc/syslog.conf并且确定用户想复制的信息。最起码,用户应该复制最高的紧急程度状态,紧急状态,重要信息,临界状态和警告信息和更多用户认为有用的信息。当用户知道什么是用户想要复制的信息,添加一个或多个像下面这样的/etc/syslog.conf命令行:
*.emerg;*.alert;*.crit;*.err;*.warning;*.notice @ip.of.log.srvr
在这个例子中,我们将所有最高的紧急程度状态,紧急状态,重要信息,临界状态,警告和出现不寻常的事情日志信息发送到远程服务器。值得注意的是:用户可以让它们在同一时间将日志归档到远程服务器。用户也可以复制到多个日志服务器。Syslog.conf扫描的是所有匹配的条目—syslogd守护进程不会在找到第一个后停止。
10、保持软件更新
每款软件都有漏洞。大多数厂商对代码进行审计并且删除发现的所有漏洞,但也有些不可避免地发布到外界。某些人花大量的时间去试图找出这些漏洞;有的人会报告给厂商,但有的人则是自己个人利用。
实际上,偶尔发现的漏洞会补丁修补程序来修正它们。除非脆弱性严重,或在外界存在一个已知的漏洞攻击,那通常不会大张旗鼓地宣布发布这些补丁。用户的责任是偶尔查看下哪些补丁适合用户并且可以从软件厂商处下载。
许多厂商会提供一个工具来帮助您保持您的系统上的补丁。HP-UX有软件更新管理软件、Solaris有patchdiag和patchpro,AIX使用SMIT,等等。至少每月运行用户的诊断工具一次,看看用户的系统可以更新的补丁,并决定是否需要安装它们。每个周日下午留出至少一个小时 (或者更多的时间) 专门作为系统维护时间,利用这段时间来安装补丁和执行其他必要的维护。
用户应该养成为一个习惯经常去网站上查看用户安装的每个应用程序是否有bug修复或安全补丁发布。使用前面创建的应用程序列表来确定是否有适用于用户的补丁。当用户更新完补丁后记得更新用户的列表信息。
免责声明:本网站(http://www.ciotimes.com/)内容主要来自原创、合作媒体供稿和第三方投稿,凡在本网站出现的信息,均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性,但不保证有关资料的准确性及可靠性,读者在使用前请进一步核实,并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏,概不负任何法律责任。
本网站刊载的所有内容(包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等)版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时,请及时通知本站,予以删除。