📄 00000018.htm
字号:
进入系统,攻击者通常立刻修改系统日志。为此,你应该用一台专用的机器专门处理日 <BR>志信息,其他的机器将日志自动转发到它上面,这样日志信息一旦产生就立刻被扫走, <BR>可以确保攻击者的行为被正确地记录下来。 <BR> <BR> 对系统不断地patch是系统管理员的重要工作,对于GNU系统更是如此。GNU系统的特色 <BR>就是每个人都有可能发现你的系统的漏洞,同时一旦发现漏洞修补也比较容易。实际上 <BR>,不仅对于Linux,任何UNIX类型系统的安全性都要依赖于不断的patch。问题是许多用 <BR>户被厂商宣称的虚假的安全性所迷惑。要记住,安全就存在于你的努力之中。 <BR> <BR> <BR> 10.2 访问控制 <BR> <BR> 现在我们来考虑关于用户身份控制的基本问题。在Linux中存在三种与安全性相关的的 <BR>访问控制问题,首先是UNIX通过口令的对用户的身份控制问题;其次是利用一些身份认 <BR>证工具对用户连接地址的控制;另外的控制就是对用户的记账信息。 <BR> <BR> 10.2.1 保护你的口令 <BR> <BR> UNIX的用户口令是对系统的第一道屏障。最原始的攻击手段就是对口令进行猜测,然 <BR>后获取一个账号。因此,一个口令脆弱的账号将是入侵者攻击的第一跳。最常见的脆弱 <BR>口令是口令和用户名相同或者仅仅差一个数字,对于职业的密码猜测者,这种密码就是 <BR>开放着的大门。 <BR> <BR> 在Linux中,系统管理员可以任意修改用户的口令,当系统管理员给用户设置了一个脆 <BR>弱的口令的时候,Linux会出现一个警告,但是并不会拒绝这个口令: <BR> <BR> bash# passwd test <BR> <BR> Changing password for user test <BR> <BR> New UNIX password: test <BR> <BR> BAD PASSWORD: it is too short <BR> <BR> Retype new UNIX password: test <BR> <BR> passwd: all authentication tokens updated successfully <BR> <BR> 加斜体的是我们输入的内容。 <BR> <BR> 相反,当用户使用passwd程序更改自己的口令的时候,Linux将强制用户使用一个在它 <BR>看来不那么脆弱的口令: <BR> <BR> $ passwd <BR> <BR> Changing password for wanghy <BR> <BR> (current) UNIX password:wanghy <BR> <BR> New UNIX password:wanghy <BR> <BR> BAD PASSWORD: it is based on your username <BR> <BR> New UNIX password: <BR> <BR> 一般来说,Linux的passwd程序要求用户使用至少7个字符的密码,而且不能基于某个 <BR>字典单词,也不能由用户名稍做变形得到。尽管这可能会使你的用户感到困扰,但是它 <BR>确实是对愚蠢用户的一种防范措施。不过,你必须注意,这些功能并总是可用的,它依 <BR>赖于Linux中使用的一些安全性工具,例如在redhat中使用的是PAM。 <BR> <BR> PAM是一个用来对安全性进行强化的工具,它包含一些特殊的连接库,一旦系统程序启 <BR>用这些运行库就能够使用它提供的安全性保护功能。对系统程序保护的方法定义在/etc <BR>/pam.d中,例如/etc/pam.d/passwd文件定义了passwd程序启用PAM的方式,如 <BR> <BR> $ cat passwd <BR> <BR> #%PAM-1.0 <BR> <BR> auth required /lib/security/pam_pwdb.so shadow nullok <BR> <BR> account required /lib/security/pam_pwdb.so <BR> <BR> password required /lib/security/pam_cracklib.so retry=3 <BR> <BR> password required /lib/security/pam_pwdb.so use_authtok nullok <BR> <BR> 通常你无须修改这些文件。 <BR> <BR> 使用复杂的口令字的一个噩梦是用户为了避免忘记密码而把它们写下来。这样就失去 <BR>了复杂口令的意义。建议你用一句毫无意义的话来构成密码,比如itUpitn(I think Un <BR>ix Password is the Nightmare) ,Oop2Naya之类的单词组合要想破译只能依靠运气, <BR>如果这样的密码被破译那么你就怪自己运气不好吧。 <BR> <BR> 特别需要保护的是超级用户口令。由于Linux的许多管理任务都必须有超级用户权限来 <BR>完成,许多单位让多人共享root账号。这不是一个合理的选择。另外的地方让系统管理 <BR>员完成所有的工作,后果是管理员被一些简单而无聊的操作弄得晕头转向。 <BR> <BR> 我们建议使用sudo程序,这个程序可以把执行某些超级用户命令的特权赋予指定的用 <BR>户,你可以在某些Linux的发行盘上找到它,也可以自己去下载源代码并且编译。 <BR> <BR> sudo程序的格式是: <BR> <BR> sudo [-u 用户名] [命令] <BR> <BR> 执行sudo的时候,会要求你输入你自己的密码而不是超级用户的密码。-u选项是可选 <BR>的。如果使用-u选项,可以让你以别的身份登录上来执行sudo命令。这个功能把执行超 <BR>级用户命令的权利交给了普通用户,为了控制这个命令,用/etc/sudoers文件来定义哪 <BR>些用户可以执行哪些操作。 <BR> <BR> 一个典型的/etc/sudoers文件的形式是这样的: <BR> <BR> root ALL=(ALL) ALL <BR> <BR> wanghy ALL=(wanghy) /usr/sbin/tcpdump,/sbin/halt <BR> <BR> cook manager.mydomain.com=(cook,zhangfl) /sbin/halt <BR> <BR> 现在定义了三个sudo的选择。从任何地方登录的root用户都可以执行系统上的任何命 <BR>令;wanghy用户可以在任何主机上以wanghy的身份执行tcpdump和halt命令;cook用户可 <BR>以在manager主机上以cook或者zhangfl的身份执行halt命令。注意在括号中那个选项是 <BR>不必要的,这个选项只是一种保护机制,例如,在第三行中的定义表示只有manager上的 <BR>cook和zhangfl才能用sudo –u cook的方式执行sudo。另外,在sudoers文件中允许使用 <BR>别名简化配置,详细的内容请参考sudo的文档。 <BR> <BR> 设置sudo比较容易出错,因此在大部分sudo的发行中提供一个visudo命令,它可以启 <BR>动一个vi的编辑屏幕并且在你存盘退出的时候自动对sudoers文件的格式进行检查。 <BR> <BR> 设置了sudo之后,就可以使用这个功能了: <BR> <BR> $ sudo /usr/local/bin/nmap <BR> <BR> <BR> We trust you have received the usual lecture from the local System <BR> <BR> Administrator. It usually boils down to these two things: <BR> <BR> <BR> #1) Respect the privacy of others. <BR> <BR> #2) Think before you type. <BR> <BR> <BR> Password: <BR> <BR> 这里需要输入你的账号的口令,例如我们是以cook身份登录,那么输入cook的密码, <BR>就可以执行后面的命令了。 <BR> <BR> 由于某些原因,sudo缺省下被设置为只要一次sudo成功,那么以后一段时间内(大约 <BR>5分钟)同一用户执行sudo不再需要输入口令。因为这个原因,绝对不要把特殊的危险命 <BR>令用sudo分配给普通用户。 <BR> <BR> 另外一个Linux的特有问题是关于单用户模式,如同你知道的那样,任何能够接触你的 <BR>机器的人都可以通过使用单用户模式启动系统而获得超级用户权限。解决的方法是在li <BR>lo中使用password选项: <BR> <BR> password="testpass" <BR> <BR> 这样,系统在引导的时候就会要求操作者输入口令。只有给出口令的用户才能是系统 <BR>启动。如果你仅仅是想用口令控制单用户模式的进入,你可以使用restricted选项,它 <BR>使得lilo仅在有人在lilo:下面使用smp 1之类的命令行时才要求口令,否则自动引导机 <BR>器: <BR> <BR> password="testpass" <BR> <BR> restricted <BR> <BR> 这样,任何人试图在lilo:下面进入单用户模式都必须输入你在lilo.conf里面设置的 <BR>口令,而正常的启动则不受影响。由于口令是明文存放在/etc/lilo.conf中,你应该把 <BR>这个文件的属性设置成0600。 <BR> <BR> 10.2.2 setuid <BR> <BR> 除了口令以外,下一个安全性方面的传统问题是setuid程序。如同我们知道的,setu <BR>id和setgid是对正常的UNIX系统安全性开的后门,一个有缺陷的setuid程序很容易成为 <BR>入侵者的攻击目标。 <BR> <BR> 你应该定期在你的系统里面查找setuid到root的程序,下面的脚本可以完成这个工作 <BR>: <BR> <BR> find / -perm -4000 <BR> <BR> 一般来说,系统本身提供的setuid程序,例如su,passwd等等不会有什么问题,但是 <BR>你一般来说不要写一个setuid程序,如果一定要写,记住不要写一个setuid的shell程序 <BR>。而且,即使你用C来书写这种程序,如果可能,仅给用户以执行权限,不让任何人读到 <BR>你的代码。 <BR> <BR> 后一点是容易忽略的地方。如果你的setuid程序是只读的,是否这个文件是安全的? <BR>绝对不是!考虑这样的一行代码: <BR> <BR> system(“ls –l”); <BR> <BR> 看上去不会有什么问题,对吗?让我们来考虑一下一个愤怒的用户可能作什么,首先 <BR>把路径置成当前目录,然后在自己的目录里面做一个可执行程序,然后把这个程序命名 <BR>为ls,因为system调用只是简单地把命令传递给shell,所以现在这个程序执行的是用户 <BR>写出的东西。上帝保佑,但愿他没有写任何有害的东西。 <BR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -