PXE网络安装Linux {转载}

 

PXE(preboot execute environment)是由Intel公司开发的最新技术,工作于Client/Server的网络模式,支持工作站通过网络从远端服务器下载映像,并由此支持来自网络的操作系统的启动过程,其启动过程中,终端要求服务器分配IP地址,再用TFTP(trivial file transfer protocol)或MTFTP(multicast trivial file transfer protocol)协议下载一个启动软件包到本机内存中并执行,由这个启动软件包完成终端基本软件设置,从而引导预先安装在服务器中的终端操作系统。PXE可以引导多种操作系统,如:Windows 95/98/2000/xp/2003/vista/2008,linux等。
  PXE最直接的表现是,在网络环境下工作站可以省去硬盘,但又不是通常所说的无盘站的概念,因为使用该技术的PC在网络方式下的运行速度要比有盘PC快3倍以上。当然使用PXE的PC也不是传统意义上的TERMINAL终端,因为使用了PXE的PC并不消耗服务器的CPU,RAM等资源,故服务器的硬件要求极低。

  网络克隆 PXE 现在最为广泛的应用一个是网吧的无盘技术。在有盘领域的网络维护和安装中PXE可以是最好用的网吧系统统一安装和维护的引导技术,PXE的引导速度和稳定性都是一流的!
实验环境:VMware虚拟机
我们只需要一台Linux网络服务器,就可以通过PXE进行网络安装,客户端不需要光驱,不需要系统盘,也不需要软驱.为了方便操作,我用Putty登陆进行一系列的操作.
 
PXE网络安装Linux需要在服务器上安装TFTP和DHCP服务器
 
新建目录并挂载光驱:
 
安装tftp和dhcp软件包:
配置tftp文件:
将disable改为“no”,添加”-u nobody”任何用户可以访问,保存退出:
然后配置dhcp文件,由于默认安装好之后没有配置文件,所以先拷贝配置文件,再进行编辑:
保存退出:
接下来,我们配置PXE:
在根下新建目录,将PXE的引导文件拷贝至其中:
将光盘上的引导文件拷贝过来:
不同的操作系统,引导文件可能放在不同的位置。对于RedHat9来说,在光盘的“iamges/pxeboot”或”isolinux”下有两个文件:initrd.img和vmlinuz
而这里我用的是Centos3.9 server版,它的引导文件在“isolinux”下
其中,我们需要的主要是initrd.img isolinux.cfg vmlinuz以及后缀名为msg的文件,这里我们将其一并拷贝:
在/tftpboot下建立一个pxelinux.cfg目录,存放默认引导文件
将文件”isolinux.cfg”移动到其中,改名为”default”:
完成之后,我们配置nfs服务,将需要的文件进行共享
编辑/etc/exports 文件:
加上挂载的目录 共享的IP地址范围 ro:以只读方式进行共享 sync:放在内存中进行共享,不写入盘中:
 
保存退出,导出共享的目录,并启动nfs和dhcp服务:
设置xinetd和tftp运行在345级别,并立即启动:
最后,我们新建一个虚拟机进行测试:
 
选择从网络安装Linux:
 
可以看到安装成功:
 
选择”nfs image”:
 
自动获取”IP”地址:
 
 
决定主机和域名信息:
 
输入主机IP地址和共享的目录:
 
最后就是整个安装过程,和光盘安装是一样的操作:
 
 
到此,整个PXE从网络安装Linux已经完成.

 

以上文章摘自
http://qiulove.blog.51cto.com/516754/143559/

Posted in Linux | Leave a comment

刨根问“银”

网银U盾安全保护原理

      随着电子商务的迅速发展,信息安全已成为焦点问题之一,尤其是网上支付和网络银行对信息安全的要求显得更为突出。为了能在因特网上开展安全的电子商务活动,公开密钥基础设施( PKI, Public Key Infrastructure )逐步在国内外得到广泛应用。我们是否真的需要 PKI , PKI 究竟有什么用?下面通过一个案例一步步地来剖析这个问题 : 甲想将一份合同文件通过 Internet 发给远在国外的乙,此合同文件对双方非常重要,不能有丝毫差错,而且此文件绝对不能被其他人得知其内容。如何才能实现这个合同的安全发送? 
问题 1: 最自然的想法是,甲必须对文件加密才能保证不被其他人查看其内容,那么 , 到底应该用什么加密技术,才能使合同传送既安全又快速呢 ? 
    可以采用一些成熟的对称加密算法 , 如 DES 、 3DES 、 RC5 等对文件加密。对称加密采用了对称密码编码技术,它的特点是文件加密和解密使用相同的密钥,即加密密钥也可以用做解密密钥,这种方法在密码学中叫做对称加密算法.
问题 2: 如果黑客截获此文件,是否用同一算法就可以解密此文件呢 ? 
    不可以 , 因为加密和解密均需要两个组件 : 加密算法和对称密钥 , 加密算法需要用一个对称密钥来解密 , 黑客并不知道此密钥。 
问题 3: 既然黑客不知密钥,那么乙怎样才能安全地得到其密钥呢?用电话通知,若电话被窃听,通过 Internet 发此密钥给乙,可能被黑客截获,怎么办 ? 
    方法是用非对称密钥算法加密对称密钥后进行传送。与对称加密算法不同,非对称加密算法需要两个密钥:公开密钥( Public Key )和私有密钥( Private Key )。公开密钥与私有密钥是一对,如果用公开密钥对数据进行加密,只有用对应的私有密钥才能解密;如果用私有密钥对数据进行加密,只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥,所以这种算法叫做非对称加密算法 ( 公 / 私钥可由专门软件生成 ) 。甲乙双方各有一对公 / 私钥,公钥可在 Internet 上传送,私钥自己保存。这样甲就可以用乙的公钥加密问题 1 中提到的对称加密算法中的对称密钥。即使黑客截获到此密钥,也会因为黑客不知乙的私钥,而解不开对称密钥,因此也解不开密文,只有乙才能解开密文。 
问题 4 :既然甲可以用乙的公钥加密其对称密钥,为什么不直接用乙的公钥加密其文件呢?这样不仅简单,而且省去了用对称加密算法加密文件的步骤? 
    不可以这么做。因为非对称密码算法有两个缺点 : 加密速度慢 , 比对称加密算法慢 10 ~ 100 倍 , 因此只可用其加密小数据 ( 如对称密钥 ) ,另外加密后会导致得到的密文变长。因此一般采用对称加密算法加密其文件 , 然后用非对称算法加密对称算法所用到的对称密钥。 
问题 5 : 如果黑客截获到密文,同样也截获到用公钥加密的对称密钥,由于黑客无乙的私钥,因此他解不开对称密钥,但如果他用对称加密算法加密一份假文件 , 并用乙的公钥加密一份假文件的对称密钥,并发给乙,乙会以为收到的是甲发送的文件,会用其私钥解密假文件 , 并很高兴地阅读其内容,但却不知已经被替换。换句话说,乙并不知道这不是甲发给他的,怎么办 ? 
    答案是用数字签名证明其身份。数字签名是通过散列算法 , 如 MD5 、 SHA-1 等算法从大块的数据中提取一个摘要。而从这个摘要中不能通过散列算法恢复出任何一点原文,即得到的摘要不会透露出任何最初明文的信息,但如果原信息受到任何改动,得到的摘要却肯定会有所不同。因此甲可以对文件进行散列算法得到摘要,并用自己的私钥加密 ( 因为非对称算法可逆,即用私钥可解开公钥加密的文件,反之亦然 ) ,这样即使黑客截获也无用。因为黑客不会从摘要内获得任何信息,但乙却不一样,他可用甲的公钥解密,得到其摘要 ( 如果用甲的公钥能够解开此摘要,说明此摘要肯定是甲发的,因为只有甲的公钥才能解开用甲的私钥加密的信息 , 而甲的私钥只有甲自己知道 ) ,并对收到的文件 ( 解密后的合同文件 ) 也进行同样的散列算法,通过比较其摘要是否一样 , 就可得知此文件是否被篡改过  ( 因为若摘要相同,则肯定信息未被改动,这是散列算法的特点 ) 。这样不仅解决了证明发送人身份的问题,同时还解决了文件是否被篡改问题。 
问题 6 : 通过对称加密算法加密其文件,再通过非对称算法加密其对称密钥 , 又通过散列算法证明其发送者身份和其信息的正确性,这样是否就万无一失了 ? 
    回答是否定的。问题在于乙并不能肯定他所用的所谓甲的公钥一定是甲的 , 解决办法是用数字证书来绑定公钥和公钥所属人。 
    数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件 , 是网络通信中标识通信各方身份信息的一系列数据,它提供了一种在 Internet 上验证身份的方式,其作用类似于司机的驾驶执照或日常生活中的身份证,人们可以在交往中用它来识别对方的身份。 
    最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。一般情况下证书中还包括密钥的有效时间、发证机关 ( 证书授权中心 ) 名称、该证书的序列号等信息。它是由一个权威机构—— CA 机构,又称为证书授权 (Certificate Authority) 中心发放的。 CA 机构作为电子商务交易中受信任的第三方,承担公钥体系中公钥的合法性检验的责任。 CA 中心为每个使用公开密钥的用户发放一个数字证书,数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。 CA 机构的数字签名使得攻击者不能伪造和篡改证书, CA 是 PKI 的核心,负责管理 PKI 结构下的所有用户(包括各种应用程序)的证书,把用户的公钥和用户的其他信息捆绑在一起,在网上验证用户的身份。 
    因为数字证书是公开的,就像公开的电话簿一样,在实践中,发送者(即甲)会将一份自己的数字证书的拷贝连同密文、摘要等放在一起发送给接收者(即乙),而乙则通过验证证书上权威机构的签名来检查此证书的有效性(只需用那个可信的权威机构的公钥来验证该证书上的签名就可以了),如果证书检查一切正常,那么就可以相信包含在该证书中的公钥的确属于列在证书中的那个人(即甲)。 
问题 7 : 至此似乎很安全了。但仍存在安全漏洞,例如:甲虽将合同文件发给乙 , 但甲拒不承认在签名所显示的那一时刻签署过此文件 ( 数字签名就相当于书面合同的文字签名 ) ,并将此过错归咎于电脑,进而不履行合同,怎么办 ? 
    解决办法是采用可信的时钟服务 ( 由权威机构提供 ) ,即由可信的时间源和文件的签名者对文件进行联合签名。在书面合同中,文件签署的日期和签名一样均是十分重要的防止文件被伪造和篡改的关键性内容 ( 例如合同中一般规定在文件签署之日起生效 ) 。在电子文件中,由于用户桌面时间很容易改变 ( 不准确或可人为改变 ) ,由该时间产生的时间戳不可信赖,因此需要一个第三方来提供时间戳服务(数字时间戳服务( DTS )是网上安全服务项目,由专门的机构提供)。此服务能提供电子文件发表时间的安全保护。 
    时间戳产生的过程为 : 用户首先将需要加时间戳的文件用哈希编码加密形成摘要,然后将该摘要发送到 DTS , DTS 在加入了收到文件摘要的日期和时间信息后再对该文件加密(数字签名),然后送回用户。因此时间戳 (time-stamp) 是一个经加密后形成的凭证文档,它包括三个部分:需加时间戳的文件的摘要, DTS 收到文件的日期和时间, DTS 的数字签名。由于可信的时间源和文件的签名者对文件进行了联合签名 , 进而阻止了文档签名的那一方 ( 即甲方 ) 在时间上欺诈的可能性 , 因此具有不可否认性。 
问题 8: 有了数字证书将公 / 私钥和身份绑定 , 又有权威机构提供时钟服务使其具有不可否认性 , 是不是就万无一失了 ? 不 , 仍然有问题。乙还是不能证明对方就是甲,因为完全有可能是别人盗用了甲的私钥 ( 如别人趁甲不在使用甲的电脑 ), 然后以甲的身份来和乙传送信息 , 这怎么解决呢 ? 
    解决办法是使用强口令、认证令牌、智能卡和生物特征等技术对使用私钥的用户进行认证,以确定其是私钥的合法使用者。 
    解决这个问题之前我们先来看看目前实现的基于 PKI 的认证通常是如何工作的。以浏览器或者其他登记申请证书的应用程序为例说明,在第一次生成密钥的时候会创建一个密钥存储,浏览器用户会被提示输入一个口令,该口令将被用于构造保护该密钥存储所需的加密密钥。如果密钥存储只有脆弱的口令保护或根本没有口令保护,那么任何一个能够访问该电脑浏览器的用户都可以访问那些私钥和证书。在这种场景下 , 又怎么可能信任用 PKI 创建的身份呢 ? 正因为如此,一个强有力的 PKI 系统必须建立在对私钥拥有者进行强认证的基础之上,现在主要的认证技术有:强口令、认证令牌、智能卡和生物特征(如指纹,眼膜等认证)。 
    以认证令牌举例 : 假设用户的私钥被保存在后台服务器的加密容器里,要访问私钥,用户必须先使用认证令牌认证(如用户输入账户名、令牌上显示的通行码和 PIN 等),如果认证成功,该用户的加密容器就下载到用户系统并解密。 
通过以上问题的解决,就基本满足了安全发送文件的需求。下面总结一下这个过程 , 对甲而言整个发送过程如下 : 
1. 创建对称密钥 ( 相应软件生成,并且是一次性的 ) ,用其加密合同,并用乙的公钥打包对称密钥。 
2. 创建数字签名,对合同进行散列算法 ( 如 MD5 算法 ) 并产生原始摘要,甲用自己的私钥加密该摘要 ( 公 / 私钥既可自己创建也可由 CA 提供 ) 。 
3. 最后 , 甲将加密后的合同、打包后的密钥、加密后的摘要 , 以及甲的数字证书 ( 由权威机构 CA 签发 ) 一起发给乙。 
而乙接收加密文件后,需要完成以下动作 : 
1. 接收后,用乙的私钥解密得到对称密钥 , 并用对称密钥解开加密的合同 , 得到合同明文。 
2. 通过甲的数字证书获得属于甲的公钥 , 并用其解开摘要 ( 称做摘要 1) 。 
3. 对解密后的合同使用和发送者同样的散列算法来创建摘要 ( 称做摘要 2) 。 
4. 比较摘要 1 和摘要 2, 若相同 , 则表示信息未被篡改 , 且来自于甲。 
    甲乙传送信息过程看似并不复杂 , 但实际上它由许多基本成分组成 , 如 : 对称 / 非对称密钥密码技术、数字证书、数字签名、证书发放机构( CA )、公开密钥的安全策略等 , 这其中最重要、最复杂的是证书发放机构( CA )的构建。

Posted in 网络安全 | Tagged , , | Leave a comment

(转)Exchange2003-2010迁移系列之二,迁移前的准备工作(上)

以下文章摘自

http://yuelei.blog.51cto.com/202879/459924

Exchange2010迁移前的准备工作(上)

         上篇博文发出后,很多博友支持得非常给力,在此一并谢过!也有一些博友反映看得不是很明白,但仍然支持…..本文中首先就环境问题再为大家解释一下,然后介绍如何进行迁移前的准备工作。还有一点要声明,这个迁移系列会写得非常真实,基本可以达到指导实践的水平,所以,内容会比较长,请大家耐心观看。

       Exchange2010和Exchange2003的架构已经发生了很大变化,Exchange2003只有前端和后端的区别,Exchange2007和Exchange2010都使用服务器角色模型来分配Exchange的任务。我们使用到的角色有CAS(客户端访问服务器),HUB(集线器传输服务器),EDGE(边缘服务器),Mailbox(邮箱服务器)。

       CAS负责接收客户端的访问请求,Exchange2010不允许用户直接连接到邮箱存储服务器,必须通过CAS才可以访问邮箱。因此大家可以想想如果CAS挂了会怎么样呢?那肯定都OVER了。因此,CAS需要使用阵列技术实现负载平衡,避免单点故障。HUB角色是负责邮件传输的中央枢纽,一般可以把CAS和HUB角色放在同一台服务器上,因此在上文的拓扑中CAS/HUB用了两台服务器,构成了一个阵列。

       Mailbox角色用于存储邮箱,重要性不言而喻,因此邮箱服务器必须要实现高可用。Exchange2007实现邮箱高可用的技术有LCR和CCR,Exchange2010中则使用了DAG(数据库高可用组)技术。DAG比起之前的容错技术是一个很大的进步,无需购买昂贵的存储就可以实现主机级的数据库容错。当然,从性能上考虑,如果要支持几千名用户,最好还是使用专业的存储设备。上了上述介绍,大家应该明白了为什么上文的拓扑中使用了两台Mailbox服务器,命名为DAG1和DAG2。

       正常情况下边缘服务器角色应该部署在DMZ区,如下图所示。边缘服务器负责接收公网邮局发来的邮件,完成垃圾邮件筛选后再把邮件转到内网的HUB服务器。由于我们的边缘服务器硬件尚未准备好,因此上文的拓扑中没有设置边缘服务器角色。外网邮局的邮件直接通过ISA发到HUB服务器,垃圾邮件筛选也是在HUB上完成的,其实我们研究了一下,把边缘服务器的反垃圾邮件功能都移植到HUB上了。具体怎么实现,后续自然一一奉上。

一   硬件

         根据微软的硬件建议以及最佳实践经验,按照支持5000用户计算,CAS/HUB,Mailbox和Edge角色分布需要的硬件配置如下表所示。

  CAS/HUB Mailbox Edge
CPU 16核 16核 8核
内存 16G 32G 8G
网卡 1 2 1

 

二  域功能级别

         Exchange2003服务器迁移到Exchange2010对域的功能级别有要求,需要域功能级别和林功能级别至少是Windows Server 2003。 

三  Exchange操作模式

         Exchange操作模式需要为纯模式,不能为混合模式。

四  Exchange服务器版本   

         Exchange2003服务器必须使用Exchange SP2版本

五  Active Directory子网检查

         确保所有Exchange2003服务器所在的子网都已经被分配给Active Directory中的站点

六     Exchange安装账号准备

         为安装Exchange2010准备一个账号exadmin,不要使用默认的administrator。Exadmin应该加入下列组:schema admins, enterprise admins, Organization Management。其中Organization Management组会在安装Exchange2010扩展架构后自动添加。

七     存储准备

         设计Exchange服务器所需要的存储空间是一件麻烦的工作,下面为大家简单介绍一下相关的计算方法。假定每个用户的邮箱空间是1G,每个用户每天收发100封邮件,每封邮件平均大小为100K。邮箱大小=邮箱空间+空白空间+垃圾站空间

空白空间=(100封/天x100)/1024MB=10MB

垃圾站=10MB x 14天+1024MB x 0.07=146MB

单个用户邮箱所占磁盘空间=1024M+10M+146M=1180MB

什么是空白空间,垃圾站的具体计算细节,可以参考http://technet.microsoft.com/zh-cn/library/ee832796.aspx

计算出单个邮箱所需的空间,再进一步计算一下数据库的空间。假定单个数据库存储150个邮箱,

单个数据库所占空间=邮箱大小 x 邮箱个数 x(1+20%) x (1+10%)

单个数据库空间 = 230GB

每用户每天收发邮件数量=100封 x 100k x 150个用户 x 7 (保留7天)x (1+20%) = 12.6GB

单个数据库日志大小 = 20GB

具体的计算细节仍然参考http://technet.microsoft.com/zh-cn/library/ee832796.aspx

准备工作还没有完成,下篇继续吧。

Posted in Windows | Leave a comment