陈钢的博客

NFS

1、NFS（网络文件系统Network File System）可能启动的进程有nfsd、rpc.mountd、rpc.statd、lockd（内核态）、rpc.idmapd、rpc.gssd、rpc.svcgssd。nfsd使用2049的TCP和2049的UDP端口，其它的端口号由portmap随机提供（portmap自己监听在111端口）；

2、NFS的各个版本概述：
a> NFS v1是SUN公司研发的，包含在Sun的操作系统里，没有单独公开发行过；
b> NFS v2是最原始的NFS协议，在RFC 1094中描述。基于UDP协议，最大单个文件4G；
c> NFS v3在RFC 1813中描述，相对于v2增加了TCP协议支持，安全的async异步写入支持，服务器端访问控制，支持大于16Y的单个文件大小（64bit），提高了一次读写的最大大小，某些版本可以为RPC开启基于kerberos的身份验证（RHEL使用的版本就可以）。v3相对于v2在性能上是一个大的跃进，但从安全的角度来看并没有多少提升；
d> NFS v4在RFC 3530中描述，相对于v3，它把lock和mount都整合进了核心协议中（原来在辅助协议），开发了新的ACL机制，引入对UTF8字符集的支持。NFS v4要求所有的实现都必须支持kerberos的身份验证（RPCSEC_GSS）（替代原有的基于UID、GID的身份验证），要求所有实现必须支持多种加密传输模式。从安全角度而言NFS v4是一个大的跃进，但目前它没有v3版本使用得广泛；

3、NFS v3的连接过程：
a> 客户端问服务器端的portmap：rpc.mount目前的用哪个端口？
b> 客户端向服务器端的rpc.mount请求挂载NFS；
c> 服务器端的rpc.mount判断权限后给客户端一个文件句柄；
d> 客户端使用这个句柄与服务器端的nfsd交流（使用TCP或UDP的2049端口），以读写文件；
e> 文件锁是由lockd和rpc.stats管理的；

4、NFSv3协议的服务器端是无状态的，所以就算机器重启了，NFS服务起来以后，客户端依然可以拿着旧文件句柄继续读写文件。但是服务器端的lockd进程是有状态的，重启就有点麻烦，解决方案是服务器端的rpc.statd让客户端报告自己手里的锁，然后重新让lockd恢复锁状态。这种锁状态机制是到v3版本才引入的；v2版本在crash之后会出现锁错误；

5、NFS v3的验证机制：
a> NFS v3及其附属协议采用标准的RPC AUTH_SYS（又称AUTH_UNIX）机制验证挂载后的客户端对具体文件的权限，服务器完全信任客户端声名的自己的权限（其实不能被称为是“验证”了）；
b> 大概过程就是客户端会在读写之前告诉服务器自己的UID和GID，然后NFS就把这些ID视同自己系统上的ID来验证权限；
c> 客户端可以很容易伪造出高权限的ID以达到攻击的目的，防御的临时解决之道是不让NFS暴露在公有网络上且不打开NFS的root权限（是比较弱的防御）；
d> 还有一个麻烦是，不同客户端上同一个username的UID想保持同步是件不容易的事；
e> 为了解决NFS 验证机制的不足，为NFS引入的解决之道就是kerberos（也就是RPCSEC_GSS验证机制）；

6、NFS的UID／GID同步问题初步讨论：
a> 最简单的办法就是用root_squash或者all_squash来做UID映射，把所有用户都映射成匿名用户。需要注意的是匿名用户的UID其实是-2，所以65534其实只是在16bit用户ID的系统上的表现，在一些32bit用户ID的系统上-2会被表现为4294967294；
b> pam_lisfile.so和pan_limits.so这两个PAM模块可以帮助我们确保NFS用户不会得到shell登录权限；
c> UID和GID在不同客户端之间不同的根治方法是使用NIS或者LDAP的方式直接把UID／GID统一掉；

7、NFS v3的安全怎么做？
a> 不要把包含配置文件的目录export出去；
b> export整个文件系统的根出去，而不是export文件系统中某个目录出去。因为即使只是export一个目录出去，攻击者也可能通过猜测的方式得到文件系统中其它目录的读写权限。比如说一个ext3挂载在/mnt/下了，用NFS export/mnt/data1/出去，攻击者就可能读写/mnt/data2/下的文件。这显然不是我们希望的，因此不如干脆共享整个文件系统（也就是/mnt/）出去。或者也可以使用NFS的substree_check来帮我们做检查来防止这种入侵，但是这个选项会较大幅度降低NFS的性能；
c> 如果一个文件系统挂载点是另一个文件系统的子目录，那么父系统开启crossmnt或者子系统开启nohide就可以把两个文件系统都共享出去，使用这个选项的时候要小心，别共享了自己不想共享的内容出去；
d> 虽然nfsd固定使用2049端口，但是lockd、mountd、statd都使用portmap随机分配的端口，这让防火墙很难配置，而且还可能占用还没起来的其它服务的端口。可以在/etc/sysconfig/nfs中把这些进程的端口都配置成固定的，这样配置防火墙（只放行自己信任的IP）就容易了；
e> NFS基于IP的认证方式让伪造身份成为可能，基于AUTH_SYS（UID／GID）的授权方式让越权变成可能，明文的、没有完整性校验（有校验网络传输完整，没有安全性完整校验）的传输协议让嗅探和篡改变成可能。要解决这些问题，就要采用NFS v4了；
f> NFS是个十分复杂的服务，很多部分要求root权限运行，还运行在内核态里。如果不是必要就尽量不要启动它，以防止未来发现的漏洞给攻击者可乘之机；

8、rpcinfo -p可以查看portmap分配出去的端口；

9、NFS v4的相对v3的变化：
a> NFS版本4把周边附属协议的lockd、rpc.mountd、rpc.statd都整合进了主协议中，进程也都整合进了nfsd里。整个服务的进程结构精简了很多，防火墙只需要开放2049和111端口NFS即可正确提供服务；
b> 新增了一个必须运行的rpc.idmapd进程（服务器端和客户端都要运行），支持RPC验证协议，用于保持username-uid的映射，解决了之前版本的那个麻烦的UID不一致问题。当然，还是可以选择AUTH_SYS的验证方式，自己去弄那麻烦；
c> NFS v4原生可以支持基于kerberos的RPCSEC_GSS安全认证，开启这个功能的话能简化配置，提高安全性，也解决了UID不一致的问题；
d> 精简的协议带来了一定的速度提升（约10％，详见http://www.fedoraforum.org/forum/showthread.php?t=219433）；
e> NFSv4仍在继续开发中，见www.nfsv4.org；

10、NFS v4引入了一个叫做pseudo filesystem（伪文件系统）的机制，网上挺多针对它的讨论的，挺多人认为这个纯属脱裤子放屁，教材上也没提它能带来什么好处。大概意思就是说要先选一个目录表明fsid＝0作为一个伪文件系统的根，然后所有需要export的目录和文件系统都挂载在这个伪文件系统的下，就如同是它的一个子目录。我翻了一下RFC3530（http://www.ietf.org/rfc/rfc3530.txt），RFC里的意思呢，主要是为了解决命名空间的问题，有了这个伪文件系统根，再加上主机名，基本命名空间就都散开不会冲突了。再一个，用了这个之后客户端直接用READDIR就能遍历服务器端的所有export，特别在服务器新export了东西以后，客户端不用做出任何更改便可直接使用新的东西（如果有权限的话）。更详细的见RFC3530 7.3.0；

11、RFC2203介绍了NFS如何利用kerberos的验证机制（又唤RPCSEC_GSS），v3和v4版本都可以用，需要在客户端使用rpc.gssd，在服务器端使用rpc.svcgssd来完成沟通。rpc.svcgssd会通过GSSAPI去获得kerberos的验证信息，而rpc.gssd则负责去向kerberos获得权限认证。它们也会帮忙解决username－uid／groupname－gid映射的麻烦。但是启用了kerberos验证就不能使用基于IP的验证了（当然iptables是可以用的）在Linux 2.6.23和nfs-utils1.1.1后变为可能；

12、kerberos有几种帮助NFS做安全的模式，这些模式需要在服务器端/etc/exports中指定：
a> krb5。仅使用kerberos来做用户身份验证；
b> krb5i。除了之上，再加上安全的数据完整性校验（基于对称密钥的签名）；
c> krb5p。除了之上，再加上把所有数据都加密；

13、目前SELinux还没有能力在NFS的服务器和客户端之间传递安全上下文，这个工作正在进行中，所以目前服务器端和客户端分别有自己的安全上下文（客户端的上下文是统一的，自己设置的）。SELinux为NFS预置了一些很有用的布尔值，如nfs_export_all_rw和use_nfs_home_dirs；

14、cat /proc/net/rpc/nfs4.idtoname/content可以看到NFSv4的名字映射；

15、客户端完全重启NFSv4模块的方法，顺序执行以下：
a> umount -at nfs4；
b> 停止rpc.gssd、rpc.idmapd、autofs；
c> 重启内核模块：modprobe -r nfs lockd fscache nfs_acl rpcsec_gss_krb5 authrpcgss autofs4；
d> 启动rpc.gssd、rpc.idmapd、autofs；
e> 重新挂载NFSv4文件系统；

16、整理一下启用kerberos验证的NFSv4的几个要素：
a> kerberos机制正常；
b> 服务器正确下载了自己principal的keytab；
c> rpc.svcgssd和rpc.gssd正常启动；
d> TGT正确且没过期（可用klist查看）；
e> rpc.idmapd正确配置了；

17、用于NFS的kerberos目前只能用des-cbc-md5的加密方式（要在kadd的时候声名）；

18、NFS v3虽然可以使用kerberos，但并没有v4支持地那么完整。由于它的MOUNT协议还是只支持AUTH_SYS，因此还是需要给未授权用户MOUNT的权限，当然把它们限制到只读是可以的；

19、在高可用的环境下，虽说NFS的句柄是服务器端无状态的，即在服务器重启之后依然可用，但如果NFS服务从一个服务器飘到另一个服务器上提供服务了，那么旧的文件句柄则可能会因为fsid的改变而变得不可用。此时，在配置文件中指定每一个export的fsid是个不错的主意；

备忘 333, kerberos, nfs, NFSv4, pseudo filesystem, RHCA, 网络安全

NIS

1、NSS（Network Security Services）网络安全服务，包含SSL v2、SSL v3、 TLS、 PKCS#5、 PKCS#7、 PKCS#11、 PKCS#12、 S/MIME、 X.509v3 certificates和其它安全协议；

2、网络登录也和其它的登录服务一样，分为验证和授权两部分。反应为密码和其它的信息（登录shell、UID、GID等）分开存放。一般的实现是用NIS（Network Information Service）存储其它信息（NIS也能存放密码，不过是明文传输的，所以不安全），用kerberos存放密码；

3、上述的“其它信息”除了NIS，还可以选择使用LDAP（Lightweight Directory Access Protocol）、DNS（Hesiod记录）；

4、我们通常说的Linux中的RPC其实是指SUN实现的Sun RPC，也叫ONC RPC（Open Network Computing Remote Procedure Call），可以建立在TCP或者UDP上，传输过程中数据会被编码成XDR（External Data Representation standard）（在RFC 1014中描述）格式；

5、RPC中每个应用程序都有一个自己的Program ID，可以在文件/etc/rpc中找到所有的ID的列表。其中最常用到的两个是NFS和NIS；

6、RPC的一个弱点是它会向其它的机器暴露自己可以提供所有基于RPC的应用的列表；

7、nmap -sR -sU -p 1-65535可以扫描目标机器的所有UDP端口，这会是个非常慢的过程，因为一般的标准Linux系统每秒只允许扫描20个UDP端口；

8、NIS服务器支持一个master，可以支持若干个slave服务器；

9、NIS协议是基于Sun RPC的，所以服务器和客户端都必须运行portmap，而且都必需加入同一个NIS域（其实就是一个预定义的统一的字符串）；

10、NIS可以的存储的东西相当于/etc/passwd、/etc/shadow、/etc/group中的内容；

11、NIS协议有1、2、3。NIS3又叫NIS+，在RHEL中只有客户端。服务器端只有版本1、2；

12、NIS虽然使用明文传输，安全性十分低下，但是由于其部署和维护简单，所以在低安全要求的企业环境中还是十分常用；

13、NIS的包名和进程名都是ypserv，同时rpc.yppasswdd和rpc.ypxfrd也是为它服务的。配置文件存在于/var/yp和/etc/yp*；

14、NIS到底不安全在哪？
a> 最大的问题是由于缺乏对客户端的认证机制和消息完整性校验机制，会泄露用户认证的信息，使用中间人的攻击方式伪装成认证服务器也不难；如果认证服务器都被伪装了，那后果的严重性可想而知（比如说更改UID为0取得root，删除已有用户防止正常人登陆，更改密码hash为已知值让自己登录）；
b> 其次，默认的配置是所有人都可以把passwd文件dump出来。而passwd采用的md5方式已经被认可为不可逆的，Linux依然使用的原因是假设passwd文件是受到保护的。因此将passwd文件的内容暴露在网上是很不安全的，是可以被反向破解出来的。这里提供一个字典破解法：openssl passwd -table -1 -salt ‘SAMESALT’ – stdin < /usr/share/dict/words | grep 'passwdhash'；
c> 最后，即使攻击者不破解密码，dump出来的用户信息也给他进行下一步攻击提供了舞台；

15、NIS的安全怎么做？
a> NIS基于UDP协议，所以不能使用TLS，只能使用IPsec（一组端对端的网络加密协议，在IPv6中是强制的，在IP4zhog是可选的，详见http://zh.wikipedia.org/wiki/IPsec）；
b> NIS绝对不能暴露在公网或者无线网络中，要严格限制在私有的可信的网络里。限制的方法可以使用tcpwrapper，或者使用/var/yp/securenets来限制网段；
c> 上述手段这样依然可以被IP伪装攻击绕过，所以在一定程度上要尽量不泄露NIS domain name（前述的那个字符串，有这个服务器才会响应你的请求）；
d> 禁用广播的方式去发现NIS Server，而是使用指定NIS的域名或者IP的方式。以防止前述恶意伪造NIS Server的行为；
e> 攻击者可以伪装NIS的响应，用已知的密码hash代替正确的NIS Server响应，这样攻击者就可以登入目标服务器了。要防止这种攻击，就要使用Kerberos（下述）来代替NIS存储密码的那部分功能了（这可以防止攻击者登入目标主机了，但这依然不能防止攻击者获取用户信息）；

Kerberos

1、Kerberos是一个基于共享密钥对称加密的安全网络认证系统，它避免了将密码（包括密码hash）在网上传输，而是将密码作为对称加密的密钥，通过能不能解密来验证用户的身份；

2、Kerberos在验证完用户身份后会发给用户Ticket，这个Ticket包含了用户的授权，用户拿着这个Ticket去享受各种服务，所以在Kerberos管理的范围内用户只需要登录一次就可以享用所有的服务；

3、如果拿Kerberos作为集群服务器的登录管理，那么每台工作机（或者是跳板机，但是sshd不提供Kerberos的ticket初始化，需要自己改造一下）都必须是Kerberos于的成员；

4、负责管理发放Ticket和记录授权的中心服务器被称为KDC（Key Distribution Center），它知道所有用户和服务的密码。这就是Kerberos服务器；

5、类似NIS 的name domian（域）在Kerboeros被称为realm，Kerberos可以管理多个realm；

6、在Kerberos域（realm）中每添加一个服务或者用户就要添加一条principal，每个principal都有一个密码。用户principal的密码用户自己记住，服务的principal密码服务自己记录在硬盘上（keytab文件中）；

7、用户principal的命名类似elis/admin@EXAMPLE.COM，形式是用户名／角色／realm域。服务principal的命名类似ftp/station1.example.com@EXAMPLE.COM，形式是服务名／地址（提供者）／realm域；

8、Kerberos的进程有krb5kdc（主进程，也就是KDC）、kadmind（用于远程管理pricipal数据库）、kpropd（slave同步数据用）。配置文件在/etc/krb5.conf和/var/kerberos/krb5kdc/下，数据库在/var/kerberos/krb5kdc/princical；

9、Kerberos用户登录过程：
a> 用户提供用户名密码；
b> login程序（/usr/bin/login）把用户名转成princical名称，给KDC发送登录请求；
c> KDC生成一个用于对称加密的session key，也叫TGT（Ticket-granting Ticket） key。KDC自己留一份，然后复制一份用用户的密码（其实是princical的密码）加密后传给用户（login程序）；
d> login程序收到之后用刚才用户输入的密码解密，获得了TGT key。
e> 认证过程完成，之后的通信使用TGT key加密；

10、Kerberos用户获得TGT之后登录服务过程：
a> 用户向KDC请求服务授权（用户和KDC的沟通是用TGT加密的）；
b> KDC在验证princical通过后生成一个新的session key。将此key用用户的密码加密一次，再用服务的密码加密一次，把两次加密后的内容都发给用户；
c> 用户把第一份自己能解开的用TGT解密后得到session key（用于和服务沟通）。然后用此session key加密一个时间戳（作为一个对服务的验证）和自己解不开的那份用服务的密码加密的session key一并发给服务；
d> 服务用存储在keytab文件中的密码解密，也得到session key（这证明这玩意儿来自拥有自己密码的KDC）。然后解开用户加密的时间戳（这证明用户确实也拿到session key了，意即通过了KDC的允许）。这里面的时间戳用于防止重放攻击，所以所有的机器都必需使用安全的类似NTP的机制把时间同步好；
e> 登录服务过程完成，整个过程中大家都不知道对方的密码，密码也没有在网络中传输过。之后用户与服务的通信使用session key来加密；

11、可以使用DNS SRV记录来寻找realm，默认realm也可以通过DNS的TXT记录来设置。但是由于DNS还是比较容易被伪造和攻击，在配置文件中直接写上realm和默认realm是比较安全的；

12、kerberos最初创建KDC的数据库（krb5_util create）时是需要密码的，以后管理KDC或更改princical都需要这个密码。但是Kerberos在系统启动时却并不会停下来请求用户输入密码。这是因为kerberos将密码存在一个藏起来的文件里面了（当然也可以让它不这么干，创建时不使用 -s选项就行）；

13、KDC可以通过kadmin.local在本地进行管理，也可以通过kadmin远程管理。由于kadmin本身也可以视为一个服务，所以它也需要dump一份keytab（存储了它的密码）到本地来（存放在/var/kerberos/krb5kdc/kadm5.keytab），并用ktadd命令做好关联（此命令用于将KDC中的密码dump到本地）；

14、kadmin可以通过/var/kerberos/krb5kdz/kadmin5.acl设置相当灵活的（控制可否添加、删除、修改、修改密码、查询、浏览principals）ACL；

15、虽然默认使用UDP，但RHEL使用的MIT KDC也可以设置TCP端口同样监听。Kerberos服务的实现除了MIT KDC还有microsoft KDC（用于MS域）等；

16、对称加密的算法可以在配置文件里设置；

17、支持Kerberos的服务有ftp、http、NFS、login、telnet等，大多数都需要专用的服务器端程序（声名自己支持kerberos的）；

18、部署Kerberos服务只需要配置好krb5.conf（可以设置Ticket更新时间，是否forward ticket，最小UID之类的）后，在KDC中添加好princical，然后将密码dump回本地存为keytab给服务（如果服务原生不支持，但是支持pam的话可以尝试一下在pam中使用pam_krb5.so来间接支持）去用就ok了；

19、临时Ticket被存储在/tmp／目录下，名称是krb5cc_UID；

20、ktutil（其实就是一个查看keytab文件的工具）可以查看本地存储的密码的版本号（每改一次密码，版本号就会步进一次），kvno可以查看KDC中存储的密码的版本号（在客户端使用，有TGT才能用），一对比就能知道本地是否dump了最新的密码回来。这招在调试kerberos时很有用；

21、kerberos自身的安全工作如何做？
a> kerberos的安全是建立在主机都是安全的而网络不是安全的假定之上的。所以kerberos的安全其实就在于把主机的安全做好；
b> 尤其是KDC那台机器的安全。出于安全的考虑，跑KDC的机器上不能再跑别的服务，如果KDC被攻陷了，那么所有的密码就全部泄露了；
c> 如果只是服务的机器被攻陷了，那么更改服务的principal的密码即可；
d> 如果是用户的机器被攻陷了，那么在ticket超时（一般是数小时的时间里）之前，用户都是不安全的，攻击者还有可能尝试反向用户的密码；
e> Kerberos依赖其它的服务来存放用户信息（登录shell、UID、GID啥的），因此需要注意到这些信息依然是很容易遭受攻击并且泄露的；

f> 由于任何人都可以向KDC请求任何用户的TGT（使用用户密码加密的session key），那么攻击者就有可能请求一个这样的包下来尝试解密，他们有充足的时间离线去做这个工作，一旦解开了，他们也就拿到了用户的密码。简单密码几乎一解就开，所以不能设置简单密码，也不能在字典里。另外还可以打开Kerberos的预验证机制来防御这种攻击，预验证机制就是在KDC收到用户请求TGT的请求之后，要求用户先发一个用自己密码加密的时间戳过来给KDC，KDC如果确实可以用自己存储的用户密码解密，才发TGT给用户，这样攻击者在没有用户密码的时候就拿不到可用于反向的包含用户密码的TGT包了。在MIT kerberos中在配置文件中default_principal_flags = + preauth可以打开这个机制。但这个机制也并不是无懈可击的，攻击者依然可以通过嗅探的方式在正常用户请求TGT时拿到上述的那个包（这个难度显然就高了一些）；

g> 还有一个问题是攻击者可能伪造一个KDC，然后用一个伪造的实际不存在的用户向这个KDC请求验证，通过后他就得到了一个用户登录系统的shell。这种攻击需要在客户端防御，需要客户端主动去验证一下KDC是否是正确的KDC。具体来说就是客户端在得到TGT后进一步要求KDC给一个本物理机的principal（也就是一个用物理机密钥加密的串），然后尝试用物理机存储的密码去解密，由于伪造的KDC没有物理机（host／hostname）的principal密码，所以它无法给出这个包，也就被客户端认定为是伪造的KDC，认证失败。这个机制需要在客户端开启（认证服务器端么），默认是关闭的，在krb5.conf里［appdefaults］章节里pam的部分中设置validate=true来开启；

22、Kerberos可以在不同的realm之间建立信任关系，这样用户在一个realm中登录后就可以享用多个realm中的服务。简单的建立互信的方法是在2个域名都建立一条共享密码的名为krbtgt的principal。更好的建立互信的方法是多个realm都建立一条信任到自己的父realm，这样在子realm之间也能建立起信任；

23、Kerberos还能向SSL帮助网络流量套上一层加密，比如说telnet这种明文协议就可能能用上。但是跟SSL或者SSH比起来安全性仍然略低，因为它的session key是用对称加密传输的（如果TGT被盗取了，流量的加密也就失效了），这在理论上增加了被嗅探破解的可能。而SSH和SSL协商session key采用的DH算法是理论安全的（被称为PFS即Perfect forward secrecy，详见http://en.wikipedia.org/wiki/Perfect_forward_secrecy）。还有一个问题是Kerberos采用的一些加密算法是已经不安全的了（如CRC32和DES），而另一些加密算法（AES）并没有被其他的kerberos实现广泛使用，所以会有一些兼容性的麻烦，选择加密算法时要避开这些算法；

备忘 333, kerberos, NIS, NSS, RHCA

DNS Server（BIND）

1、DNS服务器的主要风险
a> DNS信息泄露（通过DNS信息猜测网络架构）；
b> 非法取得DNS配置信息；
c> 通过BIND进程获得主机权限；
d> 入侵DNS可以轻易地进一步伪装自己的身份（比如说查找没被使用的IP，某些情况下使用这些IP就可以绕过某些使用网段的验证），所以这是一个很好的first stage；

2、对应的防御手段：
a> 使用TSIG（Transaction SIGnature）事务签名控制访问；
b> 限制zone文件的传输（master只能传给slave，slave不传给任何人，并且最好使用TSIG而非IP作为限制条件）;
c> 在权威DNS服务器上限制递归式DNS查询（bind默认就是禁止的，也可以配置成对内部机器开放），让专门的Local DNS Server去响应递归式查询，这样可以防止cache注入和name伪造攻击，而且对性能优化也是很有好处的。；
d> chroot BIND的进程（RHEL上的bind-chroot包提供此功能，此包被@DNS Server包含。启用以后用ps -ef能看到named -t /var/named/chroot）；
e> 记录日志，必要的话记录到远端主机上（bind提供了非常灵活的日志功能，可以定义哪些信息category被记录到哪儿channel）；

3、BIND从版本9才开始支持DNSSEC和TSIG，重写了全部的底层代码，带来了更高的安全性和更低的性能（可参见http://my.opera.com/jlake/blog/show.dml/489422）；

4、DNS服务的结构：
a> zone文件是一个DNS服务器可以响应的命名空间，一个zone文件中通常包含一个域名和此域名下的子域名；
b> master DNS服务器包含第一手的zone文件，slave服务器通过zone transfer从master取得zone文件；
c> master和slave给前来查询的客户端做出的属于自己的zone的响应被称作“权威应答”，而被cache在Local DNS的响应被称为“非权威应答”；
d> DNS查询分为递归式和迭代式；
e> 递归式查询。通常用于权威服务器。服务器在收到查询后，如果本身不是此查询的“权威域”，则会让客户端去向另一个DNS服务器去查询（通常是root DNS）；
f> 递归式查询。DNS服务器收到客户端查询后帮助客户端完成迭代查询后直接把结果返回给客户端。这样客户端只用“一跳”就完成了DNS查询。通常用于local DNS；
g> master和slave必须响应迭代式查询。对于递归式查询，它可以选响应或者不响应；
h> cacheing-only的DNS服务器不提供任何zone文件的权威数据。通常就是local DNS服务器。一般用于帮助客户端完成递归式查询；

5、DNS同时监听53 UDP端口和53 TCP端口，UDP的优先；

6、bind的进程名称是named；配置在/etc/named.conf（root可写，其它人可读）；zone存放在/var/named/（默认所有人可写）；

7、针对DNS的攻击：
a> 第一类攻击是遍历DNS信息，为下一次攻击做准备。攻击者也许只是不断地进行DNS查询，或是请求zone transfer（嗅探得到之），或者对IP地址进行PTR反查。用于猜测网络中存在哪些IP，以及它们扮演的角色。防御的手段是限制zone的传输和使用分离的命名空间；
b> 更危险的攻击是缓存注入（cache poisoning）或者名称欺骗（name spoofing）。前者是往local DNS的缓存中注入错误的解析地址（一般会设为很长的TTL），导致用户被引向错误的服务器。后者则是抢在真正的权威应答之前伪造一个应答回给查询者，或是干脆伪装成权威应答。解决此类问题的方法是限制递归查询，并且部署DNSSEC（Domain Name System Security Extensions）（RFC2535描述）（在bind 9中实现）；
c> 第三类攻击最为危险。攻击者可能控制了更高一级的DNS Server（如root），由于较低级的权威DNS的控制者是更高一级的DNS Server指定的，如果更高级的DNS被控制了，那么较为低级的DNS Server也就被绕过去了（攻击者可以指定自己的机器作为权威的服务器）。

8、bind可以基于IP、TSIG KEY来制作ACL（Access Control List）。ACL使用匹配即退出机制。（和2－b联系起来看）；

9、TSIG：
a> TSIG（Transaction SIGnature）是一个使用对称式加密算法对消息进行签名（非加密，所以依然是明文）的协议，主要用于DNS；不使用非对称式加密的主要是出于速度的考虑，所以签名也不是通常意义上的数字签名，而是类HMAC的带密钥的摘要算法；
b> TSIG协议中带有一个时间戳来说明此消息的过期时间，用于防止重放攻击；因此通信的双方最好是配置安全的NTP服务；
c> TSIG机制在RFC2845中描述；
d> 命令行工具dnssec-keygen可以帮助我们制作TSIG KEY；由于/etc/named.conf是全局可读写的，所以最好把key单独存放在一个文件里，然后用include包含进来；
e> 虽然TSIG并不承担加密的功能，但bind仍然可以基于TSIG做访问控制；
f> TSIG的弱点一：对称密钥难于管理（每一台机器被攻破就要全部更换）这也限制了TSIG在整个互联网的使用，通常只在企业内部使用；
g> TSIG的弱点二：只能提供“Next-hop”安全，提供不了“端对端”安全（因为不是所有的DNS都部署了TSIG），所以他验证不了递归DNS查询，只能认证迭代DNS查询和master和slave之间zone文件的传输。如果要提供端对端的安全，需要使用DNSSEC；
h> TSIG的弱点三：另一个TSIG的设计目标是此过程可以被整合到标准的C gethostname和gethostbyname方法里面去，但目前标准的方法还是不支持TSIG的；

10、Domain Name System Security Extensions (DNSSEC)DNS安全扩展（http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions）的主要想法是让客户端对DNS Server（从root直到最终的权威DNS服务器）进行认证；

11、Local DNS也可以配置成某些域的权威应答，这样一来可以加快查询速度，二来也可以在Internet网断掉的时候依然提供服务；bind也可以设置只让某些IP进行查询（allow-query白名单），这样来建立一个内部的DNS Server；

12、bind可以通过bogus选项把一些DNS服务器的IP列入黑名单，从而不相信它们回答的DNS应答。也可以通过blackhole选项把一些客户端IP放进黑名单，从而不响应它们的查询请求。blackhole和allow-query的区别是前者完全没反应，后者会回复refuse响应；

13、有一种需求叫做“view”，意思是对不同来源IP的查询给予不同的应答。可用于CDN用的智能DNS解析。以前这种需求需要多个DNS Server来满足，现在bind 9中的可以给一个zone配多个view来满足此需求。view也是使用匹配即退出机制。如果一个zone使用了view，那么所有的zone都应该在view里；

14、CHAOS类记录。bind在9.4版本之后真正支持了CHAOS记录（用于提供局域网内的DNS记录，详见http://victor.se/bjorn/its/chaos-dns.php），在这之前CHAOS记录只作为查询bind版本的一个途径。可以通过查询CHAOS类的version.bind和authors.bind的TXT记录来获得bind的版本信息。但是有经验的管理员会把这些信息隐去以防御攻击。注意是隐去而不是更换成别的字符，因为若能查询出version.bind（无论结果是什么）则已经说明此bind版本大于8.2，能查出authors.bind则说明此bind大于9.1.0；

15、bind的日志十分灵活，可以指定记录15类信息（category）。而在channel中可以设定记录的错误级别，也可以指定记录到syslog或者文件或者标准错误输出中去。每个channel可以指定要记录的category，互相之间可以重复；

16、SRV（Service record）记录在RFC 2782定义。它可以指定服务的IP和端口，有一些网络服务需要SRV解析的支持，如Session Initiation Protocol (SIP) 和 the Extensible Messaging and Presence Protocol (XMPP) 。详见http://en.wikipedia.org/wiki/SRV_record；

17、Windows操作系统使用一种动态DNS更新的技术让客户端可以自己更新自己的DNS记录，包括A记录和PTR记录，域控制器甚至可以更新SRV记录，这会带来一定的风险。处理的办法是使用TSIG和bind 9中的update-policy机制，这可以让客户端只能更新zone中属于自己的记录。更好的办法是把DHCP服务器也配置上TSIG更新，以让IP和KEY更好地绑定在一起（windows中地DHCP服务器采用的是GSS-TSIG）；

18、DDNS解析。其实就相当于是动态的PTR记录。这个工作也是需要客户端来更新自己的PTR记录和A记录，如上一条所述，这个工作最好是配合DHCP服务器的TSIG校验来做；

备忘 333, bind, DNS, PTR, RHCA, 网络安全

网络加密的需求

1、网络流量加密的目的在于防止嗅探（偷听）、数据注入以及会话劫持；

2、在IP网络中数据是端对端传输的，为什么还存在信息嗅探那么一说？
a> 在无线网络环境中，无论是频分复用（如wifi）还是码分复用（如CDMA），由于信道是复用的，数据包都是可以被第三方拿到的；在hub环境中就更是如此了，甚至解复用都不用了；
b> MAC flooding。在Switch组建的有线局域网环境中，由于Switch级联的情况存在，所以一个口上可能会有多个MAC（Media Access Control）地址连接过来。攻击者可能通过MAC flooding的方式把Switch降级为hub（hub工作在网络第一层，不认得MAC，所以只会广播）；
c> MAC duplication。有些网卡支持多路径连接到同一个Switch（用以增加带宽和冗余），这样在某些模式下交换机就不能自动将端口和MAC绑定了；此时攻击者简单地伪造MAC就有可能可以达到嗅探的目的；
d> ARP攻击，浑淆网络中IP和MAC的绑定关系，这是常用的嗅探手段；

3、如何防御ARP攻击？
a> ARP用于在MAC地址和IP地址间建立关系，工作在网络第2层；
b> 朴素点的防御方法就是用静态ARP（作为只用认识网关的单台服务器而言，这办法物廉价美）；
c> 华丽点的办法是使用ARPTables（http://en.wikipedia.org/wiki/Arptables）；
d> 有些交换机支持在端口上绑定MAC，这不但可以防御ARP攻击，同样也可以防御MAC flooding和MAC duplication；

4、vice versa —— 反之亦然；

5、加密能帮我们达到什么目标？
a> 加密可以帮助我们实现验证和保密，但是攻击者还是可以知道信息被发送出去了，有时候通过流量分析的手段，攻击者还是能获得一些有用的信息；
b> 加密未必就一定能同时实现验证，但是良好的设计一般是同时实现的（http://zh.wikipedia.org/wiki/%E5%9D%97%E5%AF%86%E7%A0%81%E7%9A%84%E5%B7%A5%E4%BD%9C%E6%A8%A1%E5%BC%8F#.E8.AE.A4.E8.AF.81.E5.8A.A0.E5.AF.86）；
c> 做好通信加密的同时，别忘记如果主机本身攻破，那还是一切都完了；

6、柯克霍夫原则（Kerckhoffs’s principle）：
“除了密钥之外的所有东西（数据包和加密算法）都被攻击者得知了，攻击者也不能得知通信内容。因为加密必须防住它的发明者，而且发明新算法比发明新密钥难多了。”，
类似的还有香农箴言：
“敌人知道系统。（The enemy knows the system）”；

7、身份验证和完整性检查比加密更重要（后者只是获得信息，前者获得权力），同时别忘记防御重放攻击和阻断攻击的威胁；

8、OpenSSL套件：
a> libcrypto。提供加密功能，bind、OpenSSH、Cyrus SASL有用到；
b> libssl。提供加密信道TLS（Transport Layer Security）／SSL（Security Socket Layer）功能Sendmail、OpenLDAP、Apache、IMAP等有用到；
c> openssl。一个生成密钥和手动加密的命令行工具；
d> GNUTLS、NSS（Networks Services Software）是它的竞争对手；

加密算法

1、对称加密：
a> 顾名思义，通信双方用同一个key给信息加密解密。效率高，问题在于如何传递密钥（防止嗅探）是个问题，尤其是更换密钥的时候；
b> 对称加密算法有：DES、DES3、AES、Blowfish、Twofish、RC6、Serpent、IDEA、CAST5等；
c> 算法一般只能加密固定长度的数据，要应用到实际程序中外面还要包装一层“块加密模式”，就是把变长的数据给切开加密了，这模式就叫ECB（Electronic codebook），它的弱点在于一样明文会加密出同样的密文来，那样就可以用流量分析来破解了。另一种叫做CBC（Cipher-block chaining）的模式则避免了这个弱点，它使用加密后的前一个块异或后一个块。此外还有PCBC、CFB、OFB、CTR等模式（http://zh.wikipedia.org/wiki/%E5%9D%97%E5%AF%86%E7%A0%81%E7%9A%84%E5%B7%A5%E4%BD%9C%E6%A8%A1%E5%BC%8F）。千万别傻乎乎地去写这些模式（我就傻了一次⋯），各种语言的官方库里都有现成的；
d> 可用工具：gpg、openssl（openssl enc、man enc）；

2、加密哈希（摘要算法）：
a> 把不固定长度的明文弄成固定长度的密文。不可逆，由密文无法还原出明文。不同的明文会得出不同的密文；
b> 多用于存储密码和完整性检查；
c> 常用的摘要算法有CRC32（命令行cksum）、MD5、SHA1等。CRC32已经是不安全的算法了，只有一些很老的程序在使用。MD5是目前最常用的摘要算法，它的速度非常快。最新的程序已经开始使用SHA1算法，它比MD5慢，但是会稍稍提高安全性（MD5已经被认可冲撞可计算）；
d> 当然cksum、md5sum、sha1sum可以提供这些算法，还有一个更灵活的工具是openssl dgst（openssl dgst -sha1 /etc/passwd）；

3、消息认证码（MAC：Message Authentication Code）：
a> 有key参与的摘要算法，把不固定长度的明文弄成固定长度的密文。不可逆，由密文无法还原出明文。不同的明文会得出不同的密文；可以大概理解为带salt的MD5（其实不同），这个salt是通信双方都知道的；
b> 用于网络通信的完整性检查；
c> 一个产生MAC码的方法是这样的，用CBC模式对消息进行加密，把加密出来的最后一个块当作MAC。因为CBC是Chain的，所以一点内容的改变都会造成最后一个块的改变。使用这种方法要避免几个容易犯的错误，最常见的就是把用于CBC加密和CBC-MAC校验的key用成同一个，这很危险；
d> 另一个更简单的方法是直接使用现成的MAC算法，如RFC2104介绍的HMAC算法。它经常和MD5、SHA1结合起来一起用（http://en.wikipedia.org/wiki/Message_authentication_code）；

4、不对称加密（公钥算法）：
a> 分为公钥和私钥，任何一个钥匙加密都要用另一个钥匙去解密（一般是公钥加密，私钥解密），这就解决了密钥分发的问题；
b> 公钥算法有RSA、DSA（只为数字签名而设计）、ElGamal等，最常用的就是RSA（RSA vs DSA http://lists.gnupg.org/pipermail/gnupg-users/2006-June/028808.html）。
c> RSA规定了最多可加密数据的长度，而且公钥算法比对称加密算法要慢很多。所以比较通用的使用方法是——使用公钥算法完成对称加密的key的分发工作，随后的通信用对称加密算法来保障；
d> 常用工具：gpg、openssl rsautl；

应用实例

1、用户验证：
a> 这是摘要算法被广泛应用的一个场合，这样就不用存储用户的明文密码了；
b> 原始的UNIX密码是使用的基于DES的摘要算法，在现代的标准来看已经不安全了。Linux采用了FreeBSD开发的基于MD5的摘要算法（现在也不安全了⋯⋯）；
c> 记得加salt，而且不同的用户要用不同的salt，这样同样的明文不会hash出相同的值（另外，用户密码独立于用户信息存储是个好设计）；
d> openssl passwd（man sslpasswd）可以帮助我们产生Linux式的密码（/etc/shadow）；

2、数字签名：
a> 数字签名使用公钥算法的消息认证码（MAC）；
b> 它和公钥加密是反着的——私钥加密，公钥解密（加密是公钥加密私钥解密）；
c> 为了速度的考虑（非对称算法很慢），一般会将消息先行hash摘要过后再对摘要进行签名；
d> DSA（Digital Signature Algorithm）或叫DSS（Digital Signature Standard）是一个只能用于签名的公钥算法，它是美国国家安全局在RSA还在专利期内的时候专门为美国国家标准技术研究所开发的；
e> ElGamal和RSA既可以用于签名也可以用于加密；

3、key的分发：
a> 迪菲－赫尔曼密钥交换（Diffie–Hellman key exchange，简称“D–H”）是最初被发明的可以让双方在完全没有对方任何预先信息的条件下通过不安全信道创建起一个密钥的算法。但是由于攻击者还是可以干预密钥创建前的信息交换，所以DH一般要和DSA或RSA一起使用，目的是对消息进行认证；
b> 另一种方法是干脆使用RSA不对称加密来交换对称加密的密钥；
c> 以上两种方法都还有一个问题需要解决，那就是如何认证客户端最开始拿到的公钥确实是服务器端的公钥呢？这个问题可以交由数字证书去完成；

4、数字证书：
a> 通信的双方共同信任一个第三方（CA，Certificate Authority），CA自己的证书是自签名的；
b> 一个数字证书包含以下内容：要分发的公钥、此公钥的hash以及此hash用CA的私钥签名后的值、过期时间、公钥拥有者的信息、证书用途的信息、CA自身的信息，前两项就可以保证公钥的合法性。因为用CA的公钥可以验证hash是没问题的，然后hash没问题就说明了要分发的公钥没问题；
c> TLS证书使用X.509数字证书标准格式。发行者和证书拥有者的唯一标识使用X.500目录服务的命名法；
d> 还有另一种公钥分发模型，用“信任网络”取代了CA的角色。在这种模型里面，每个人都可以为别人签发数字证书，然后每个人选一个自己确实信任的节点作为自己信任的CA，然后展开信任关系。这种公钥分发模型为OpenPGP所用；

5、TLS（Transport Layer Security）和SSL（Secure Socket Layer）
a> TLS／SSL是一套对称和不对称加密的混合系统，用慢的不对称加密传递对称加密的key之后，后面就一直用对称加密的key传输数据，这样快；
b> TLS／SSL的问题是服务器的身份被验证过，而客户端的身份却没有被验证。一般来说，客户端用别的办法获得服务器的信任（如输入用户名密码），但实际上客户端的TLS认证也是可行的，服务器端同样可以要求客户端在进入对称加密的阶段前发送自己的CA证书来认证身份（如果客户端很多的话要签发很多证书）；

6、TLS握手过程：
a> Client向Server请求一个TLS连接，同时表明自己可以接受什么样的加密算法，完整性校验算法，想用什么样的key；
b> Server按照Client的请求回给Client一个数字证书，里面就包含了Server自己的公钥；
c> Client用CA的公钥验证数字证书的合法性，随后取得了Server的公钥；
d> Client生成对称加密要用的key，用Server的公钥加密后传给Server；
e> Server用自己的私钥解密，获得Client给它的key；
f> Client和Server开始用key和对称加密展开随后的交流；

7、给私钥配上密码好吗？
a> 确实能在一定程度上提高安全性，但是也会带来麻烦，这是一个折中的方案；
b> 自启动的服务没有私钥密码无法自动启动，想要解决这个问题，只能去掉公钥加密密码；
c> 私钥的加密只能采取对称加密算法，输入的密码是对称加密的key，这意味着这个key在系统的内存中是能被debug工具找出来的，因此这个密码阻挡不了高级的攻击者；

8、如何签发一个CA证书？
a> 想要获得一个CA证书，首先要创建一个CSR（Certificate Signing Request）。其中应该包含除了CA用它的私钥算出来的那个hash的签名之外所有的信息，包括你要分发的公钥（注意别包含私钥），你的认证信息等内容。然后把这一切发给CA，让CA去签名；
b> 这些信息要用范轨的形式（X.500／X.509）书写，openssl req能帮我做好这件事；
c> CA拿到CSR后验证身份确实和填写的身份符合，就签一个名，证书就做好了。证书会给申请者一份，以后的通信就和不和CA打交道了。CA自己也会留一份副本，用于以后撤销证书（撤销证书只能等客户端来主动更新信息）时使用；
d> openssl ca能帮我们把CSR签发成CA证书。它还能帮我们管理多个证书的结构，弄成一个简单的CA中心；

9、CA证书的过期：
a> 数字证书都有实效性，一般而言CA签发的证书1年或2年过期，而内部签发的证书可能会很短（短到1－2小时都有可能）；
b> 证书的过期主要是为了让公钥过期，这样对应的私钥也就过期了。这样即使万一私钥被盗取了，也会在过期时间过后变得不可用（过期时间内是没有办法的）；
c> 更短的过期时间提供对私钥更好的保护，但管理起来更麻烦。反之亦然；
d> 注意一下在新旧证书切换时，留出一段新旧证书同时运行的重叠期，以让客户端平滑过渡；

10、CA证书的作废：
a> 证书地作废主要也是为了保护用户的私钥。但证书的作废是件很难的事，主要的麻烦是CA很难主动通知到每个客户；
b> TLS／SSL使用的解决方案是CA生成一个包含所有作废证书的CRL（Certificate Revocation List），然后客户端定时地下载CRL，这样客户端就能知道证书作废地情况了。但实际情况是很多客户端压根就不去下载CRL，所以作废证书会继续生效到过期时间之前；
c> openssl ca -revoke可以帮我们作废证书， openssl ca -gencrl可以帮我们生成CRL，有些客户端（如Mozilla）要求DER（Distinguished Encoding Rules）而非PEM（Privacy Enhanced Mail）格式的CRL，openssl也可以帮我们做转换；
d> 另一种被Kerberos采用的解决方案是——给证书签发很短很短的过期时间（几小时），这样作废的证书只要不续签就会在很短的时间内自然过期；

11、数字证书体系在应用上仍有不足（重要性排序）：
a> 用户大多只会看证书的签发中心，不会仔细校验证书大篇幅的相关信息，这是一漏洞；
b> CRL难以分发；
c> CA中心一旦被侵入或者失误，签发了错误的证书，后果严重；
d> 由于CA中心都内置在客户端里，自建的CA中心会弹出不友好的提示信息。且默认只是引导用户信任证书。若要信任CA中心需要手动添加；
e> 还要注意的是，数字证书只是用于验证，授权要记得一定自己另弄一套；

其它

1、GnuPG（gpg）是个好工具，可以用于手工加密信息，也可以跟一些开源邮件客户端一起结合起来使用，保证信息安全；

备忘 333, CA, RHCA, 加密, 数字证书, 网络安全

ftp://mama.indstate.edu/linux/tree/

备忘 tree

kerberos建的是AD域；
samba做的是Domain域控制器，对于AD域，它只能加入，不能作为主控。

它们2个的区别其实就是
Domain Controller（http://en.wikipedia.org/wiki/Domain_controller）
和
Active Directory（http://zh.wikipedia.org/wiki/%E6%B4%BB%E5%8A%A8%E7%9B%AE%E5%BD%95）的区别。

而这两者的关系简而言之就是 —— Domain Controller是一个 Active Directory 底下的基本对象。

再更简单一点说 —— DC可以实现单点登录，AD比DC更强大。

DC做不到以下：不支持机器策略文件，不支持组策略，不能同步AD登陆脚本，不能使用AD管理工具管理Samba3，不能实现针对AD域环境的注册表配置，也不支持针对AD环境的软件特定配置（好似防毒软件在AD域中的集成等）；

参考链接1：http://www.linuxfly.org/post/103/
参考链接2：http://www.ibm.com/developerworks/cn/linux/l-lpic3-314-3/index.html?ca=drs-

备忘 Active Directory, Domain Controller, kerberos, samba

fanotify在2.6.36版本（2010-10-21）并入Linux内核（同时增加了CIFS本地缓存），它与原有的inotify的区别在于以下：

1、inotify最麻烦的一点就是不能监控子目录，要自己去弄n多个监控。fanotify也不能自动监控子目录，但它有一个Global模式，可以监控整个文件系统的所有事件。这样就可以监控所有事件，然后在程序里判断，这样也算是个比之前好一些的解决方案；

2、inotify只能接受事件。fanotify不仅可以接受事件，还可以阻塞事件，甚至进一步阻止事件执行成功。并且可以持续地给这个文件设置上acl，且不用每次触发都判断一次（省去麻烦，增加性能）；

3、fanotify允许多个程序同时监控同一个文件系统对象，并且可以设置优先级（消息到达前后）。这个机制可以处理通过fanotify机制本身做出的动态文件；

4、fanotify可以指定不监控某些pid对文件的操作，这是inotify做不到的。使用场景例子：可以让监控程序自己不会触发事件，避免了让程序员自己去处理死循环的麻烦；

5、fanotify相对于inotify的致命缺陷：fanotify可以触发的事件比inotify少，尤其是缺乏MOVE、ATTRIB、CREATE、DELETE事件（有ACCESS、MODIFY、CLOSE）。

备忘 fanotify, inotify

概述

1、攻击者的计划：
a> 搜集目标系统的信息（系统信息，版本信息，网络拓扑，关联机器等），信息泄露会给攻击者计划攻击提供便利；
b> 寻找目标的弱点（可用端口，缺陷的软件版本，Man-in-Middle缺陷等）；
c> 搜集一切可以跟目标沟通的方式（Web访问，普通帐号登录，数据库访问，无用的服务等）；
d> 利用一个弱点侵入系统（提权）；
e> 抹除痕迹防止反击（删日志，种rootkit，种后门）；

2、验证和授权：安全的登录机制需要分为2步：验证身份，而后给予授权。即先确认你不是假冒的，而后根据你的身份限制你的权力；

3、攻击的大类：
a> Dos —— 使服务不可用；
b> 协议缺陷 —— 越过验证身份那一步；
c> 不正确的信任关系 —— 不越过验证的那一步，但是放大自己的权限；

4、Dos（Denial Of Service）攻击：
a> 通常因为版本BUG或者配置错误引起；
b> Dos掉一台机器的目的很可能是为了可以伪装成这台机器以发动下一步攻击；
c> Linux内核提供了一些防止Dos攻击的方法，但更重要的是保持软件更新和保持对系统的监控，尤其是对异常流量的监控；
d> DDos（Distributed denial of service）分布式拒绝服务攻击；

5、针对验证机制的攻击：
a> 密码嗅探。明文的协议是不安全的，如telnet；
b> 不恰当的授权。将自己与一个已验证或可以通过验证的用户关联起来；要将服务的授权缩到所需的最小，一个普通用户可以完成的工作就不要启用root去做；

6、输入验证攻击：
对输入是不是符合预期没有做验证。应用软件难免有BUG。
a> 一种输入验证攻击是试图去填满buffer导致溢出（buffer overflow attack），这还可以导致将数据区的代码填充到执行区导致代码执行。
b> 另一种是format string attack，利用输出执行某些超出预期的代码（SQL注入就是其中一种）；

7、Linux提供的防御机制：
a> 防火墙、proxy、包过滤。最好一起启动。包过滤（iptables）是底层的安全措施，可以很好的控制网络流量，因为它只检查包头，因此效率很高。也因为这个，它不能对包内容做检查，而这正是proxy所擅长的，所以它们经常搭档。proxy（Squid）因为要对包内容解析，一般还做做cache啥的，对机器配置要求会高些；
b> tcpwrapper（libwrap.so），httpd不支持，sshd支持；
c> xinetd内建的一些机制（只能作用与xinetd托管的服务）；
d> PAM（Pluggable Authentication Modules），可以对登陆进行包括时间段、资源占用等在内的各种限制；
e> SELinux（Security Enhanced Linux），通过上下文来保护系统。相当于即使某些进程或者用户被占领了，也还有一层ACL挡在后面。有点像是复杂化的带有规则的chroot，进程的活动被限制在某些文件／端口／连接之内。其实主要就是为了防止用户没有把权限弄好（777啥的），又加上一层权限控制；
f> ExecShield是Linux包含的隔离内存数据区和可执行区域的模块开关。也就是 sysctl -w kernel.exec-shield。当CPU支持 NX／XD技术时，它会使用CPU内建的方案，否则它会使用较为简单、效率较低的segment limit方案（纯基于软件的）；
g> 服务和应用自身的安全机制。以上做的都是传输层和系统的安全，应用层的安全需要应用层自己做好；

8、服务通常是从内部瓦解的，而且proxy和包过滤加一起也并不能完成所有的安全工作，本地安全（包括使用者的安全意识）是十分重要的。

9、最基本的安全意识：
a> 只跑需要的服务，最好能把各个服务分开部署。如果能做到隔离，那是最好，虚拟化技术在这方面有它的用武之地；；
b> 保持软件更新，包括订阅各种安全的消息；
c> 关键服务一定要加以访问限制；

SELinux

1、两种访问控制机制：DAC和MAC。Discretionary Access Control和Mandatory Access Control。前者就是我们一般的访问控制机制，资源的所有者可以设置此资源的权限，让它可以被别人使用。后者则是打开SELinux的情况，资源所有者不能完全更改其它人对资源的访问权限，需要更高级别的管理员去更改；

2、NSA实现的MAC（强制访问控制）的第一版叫做Mach，后演变为SELinux并通过红帽公司将其并入了Linux Kernel中；

3、SELinux的上下文通过ls -Z和ps -Z来察看，用chcon和restorecon来修改；

4、SELinux支持MLS（Mutil Level Security），其实也就是内置有好几套安全策略。其中最严格的叫做strict，红帽启用的这一套叫做targeted，意即只保护目标的一些进程，这一套策略是strict策略的一个子集；

5、SELinux的日志通过auditd进程写在了文件/var/log/audit/auditlog，如果此进程不在，则写在/var/log/messages。可以用sealert -a /var/log/audit/audit.log来更友好的查看日志；

6、SElinux有一些boolen的预置开关来帮助方便地调整策略（setsebool）；

基于IP的访问控制机制

1、基于IP的访问机制是整个系统的第一道防线；

2、iptables是Linux内核提供的一个包过滤机制（Netfilter），它的效率不错（在内核中实现），而且很容易配置（红帽预置了一些可用chain在里面，如RH-Firewall-1-INPUT）；

3、tcpwrapper中不能直接执行cmd（必须使用spawn或twist）的原因是RH编译tcpwrapper时开启了-DPROCESS_OPTIONS；

4、tcpwrapper中当allow与deny冲突时，以allow为准（hosts.allow和hosts.deny里面都可以写allow和deny的规则）；

5、各种服务的banner（欢迎信息）在目录/var/banners中；

6、xinetd可以帮它托管的服务做访问控制，可以控制访问时段、同时连接数，甚至可以做成一个陷阱（当用户连接他不该连接的端口时封掉他的IP一段时间）；

7、整个访问控制的流程：
a> 首先会被送到内核里检验netfilter/iptables的检验；
b> 如果应用程序包含了libwrap，则接受tcpwrapper的检验；
c> 如果是xinetd托管的服务，则检查xinetd的tcpwrapper规则和xinetd的策略；
d> 最后接受应用程序本身的检验。

备忘 333, PAM, RHCA, SELinux, tcpwarpper, 网络安全

GFS

1、GFS（Global File System）是一个无中心的，基于共享存储设备的（意味着分布式分布的主要是fs的metedata而不是data），集群式文件系统。它是建立在RHCS之上的，它依赖RHCS的集群锁机制和fencing机制；

2、GFS支持POSIX、Direct IO、磁盘配额和ACL（需在fstab中启用）；

3、分布式文件系统相比GFS的弱点：
a> 缺乏文件系统journal的故障切换功能（metedata没有做分布式）。而在GFS中，每一个节点都维护着自己的journal当一个节点失败，其它节点可以接管它的journal；
b> 分布式文件系统是基于文件的锁。GFS的锁基于block，更细；
c> 分布式文件系统一般不支持Direct IO（O_DIRECT），不能当块设备来用，一般来说对UNIX权限的支持也不好；
d> 一个典型的分布式文件系统的例子是AFS（Andrew File System）；

4、GFS目前版本2，最多支持8EB大小的文件系统（RedHat只对25T之内的做支持，据说目前中国最大的GFS是60T），最多支持16个节点；

5、RHCS中提供了分布式的lvm，CLVM（lvm2原生：locking_type=3）以配合GFS使用。当然，不使用CLVM，GFS本身也是可以当作块设备独立使用的（同样可以支持Device mapper）；

6、GFS创建多个文件系统journal，journal的数量至少应该大于节点的数量；

7、GFS中提供了高效的分布式锁机制（其实是RHCS提供的）（但中软同学说效率仍然不咋的，此锁机制依然可能占用大量CPU资源）；

8、GFS有inode节点空间自动分配的能力（就是说不用为inode预先分配磁盘空间，GFS自己会去动态分配）；

9、GFS有一些参数放不进fstab，放rc.loacl吧；

10、fsync系统调用用于将脏数据写回磁盘。但它返回地很快，因为一旦启用了journal，那么journal记录成功，此调用就返回成功了。这也是增进应用程序性能的一个办法（指启用journal的好处）（另：启用journal还可以使得fsck更快）；

11、GFS中journal的启用可以是全局的也可以是基于文件或者目录的；

12、增进磁盘效率的另一个办法是禁止atime的更新或者是增加atime同步的周期（同步仅指在GFS中），这一技巧在GFS中依然有效；

13、Linux命令行下转换时间戳：date -d “1970-01-01 UTC 1133427369 sec”；

14、跟RAID建议没事就fscheck一下（因为会隐藏错误）不同，文件系统一般没事不要去fsck它；

15、GFS支持给某个文件或者目录加上O_DIRECT属性，这样对于它的操作默认就会是DIRECT IO；

16、Quotas机制会较大影响性能，因此GFS只是周期性地同步和检查Quotas（默认是60s）；

17、GFS可以在本地cache住statfs调用的返回以增进df命令的速度；

18、GFS的inode有4K（默认）一个那么大（普通的fs在2K左右），为了增进效率，如果文件内容足够小，会被直接存放在inode内；

19、在我理解，GFS其实就是一个比NAS性能更好的一个集中管理SAN或者iSCSI存储的方案，但由于它基于RHCS，所以它确实是有够复杂的（而且还没封装太好）；

20、一般“磁盘页”的大小是以512byte为单位的（其实就是一个扇区），所以支持多大的磁盘就决定于SCSI命令中地址的大小，linux kernel在2.6之后才支持了64位的地址大小。要支持超过2TB的话，HBA也同样必须支持64位寻址；

21、如果设置GFS为nolock的话，它会使用OS中VFS层的文件锁；

22、GFS中，其实每个节点都分别管理着一些块以及之上的journal和lock（我拿lock就是master lock，别人再来就要在本地lock完以后再来请求我的lock。而如果我自己用，那就跟本地lock一样了）。而别的节点如果使用到这些块才会走网络。这样，通过倾向于保存自己常用的块的管理权在本地的方式，GFS在分布式和性能之间做到了一定程度的兼顾；

23、GFS的DLM（分布式锁管理）是完全在内核中实现的；

Device Mapper

1、LVM、软RAID还有多路径功能都是通过Device Mapper实现的。Device Mapper功能是在内核（2.6+）中实现的功能，但提供了工具（dmsetup，libdm）在用户态下管理；

2、Device Mapper创建的设备通常在/dev/mapper目录下；

3、Device Mapper可以把物理设备的某些sector拿出来组成一个逻辑的块设备，组成的方式有如下：
a> linear。线性的。把硬盘直接串起来，其实就是跨pv的vg。这里可以看出lvm要是跨硬盘的话还是有点风险的；
b> striped，条带化的。就是每个盘写一点，然后交换。就是round－robin，而不像linear那样先找一个狂写。其实就是RADI 0，当然也会跟RAID 0一样要求大小一样，也会获得RAID 0一样的并行写入带来的性能提升，当然数据也就分开了，损坏的风险提升；
c> error，错误。把逻辑盘上的某些扇区标记为错误，此上的IO会错误，可以当作隔离带来用。可以用于测试和产生超时。可以参考http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/device_mapper.html的A.1.5. 章节；
d> snapshot，快照。一般和楼下联合使用，LVM2的快照即用这个实现。同时指明一个被快照的设备A和一个COW（Copy On Write）设备B，未改变的数据存在A上，改变了的和需要改变的数据去B读写；
e> snapshot-origin。用于注明被快照了的设备，一般和楼上联合使用；
f> zero，反应和/dev/zero一样，但是是个块设备（/dev/zero是个字符设备），意味着可以格式化之。读的时候总返回0，默默丢掉写操作。可以用于创造不存在的超大块设备，也一般用于测试；zero可以和snapshot一起变出超大的可读可写的块设备来，实际的读写都存储在snapshot设备中；
g> multipath，多路径。下面有详述，此处略；
h> crypt，加密。可以使用内核的cryptAPI把这个块设备上的内容都加密掉，这样就做成一个加密盘。可以参考http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/device_mapper.html的A.1.8. 章节；

4、blockdev命令可以数出块设备上有多少个扇区sector；

5、dmsetup命令可以简单的创建Device Mapper设备，内核会动态地载入它们（软RAID的命令是mdadm）；

6、DM设备是可以堆叠的，就是说DM设备本身可以再拿去组成DM设备；

7、dmraid就是通过DM机制实现的软RAID；

8、LVM2快照一下会自动整出4个DM设备：快照、快照－original、真实设备（加了一个linear）、还有一个COW设备；

9、可以看看这个slide，讲DM的：http://www.aka-kernel.org/news/downloads/devicemapper.pdf；

MultiPath

1、为了存储的高可用，线路啊接口卡啊啥的都用了双份，这样系统如何使用这双份的链路就成了一个软件问题，也就是多路径问题。这个问题可以通过Devic Mapper来解决的，各家厂商也都有自己的多路径软件，都不大便宜；

2、由于存储连到主机的多个路径会被认别为多个块设备，因为在其上需要一个逻辑层把它们还原成一个设备，这个逻辑层就是Multipath去实现的事情（通过Device Mapper）；

3、连到同一个设备的多条链路可以被分为若干组，组内可以选择轮询策略（组内都是同时生效的），组间可以设置启用优先级（数字越小的优先级越高），同一个时刻只有一个组能是活动的（当然，可以把所有的链路全分到一个大组里去）。组内和组间都是会自动进行故障切换的；

4、有一个multipathd的进程需要开机启动，它的任务是不断检测每个链路的状态，并汇报给kernel；

5、重做链路scan的命令：
a> SCSI：echo “—” > /sys/class/scsi_host/host0/scan；
b> FC：echo “1″ > /sys/class/fc_host/host0/issue_lip；

6、iSCSI也可以使用多路径技术，跟FC差不多，但是使用网卡bonding技术其实能做到更方便更好（这是得益于ip协议强大的路由能力）（所以说multipath几乎是FC only了）；

7、在线路时断时续的情况下不要把failback设置为auto（失败线路恢复之后就切回来），那就会导致不停切，性能就下降；

8、WWID（World Wide Identifier）通常新硬盘都有一个WWID，是全球唯一的。但是老一点的硬盘就没有了。 同时，这个WWID的实现是厂商自闭的，不象MAC地址，为了相互通讯，而必须相互兼容；

9、Linux中设置multipath的命令叫“multipath”。

备忘 436, Device Mapper, fsync, GFS, multipath, RHCA, statfs, wwid, 多路径, 磁盘加密

.yuv：

mplayer -demuxer rawvideo -rawvideo w=176:h=144 suzie_qcif.yuv

.264：

mplayer -fps 30 test.264

附送：
mac下编译好的mplayer（32位）

备忘 264, mplayer, yuv