PXE网络全自动安装Linux [转载]

利用PXE网络全自动安装Linux,可以实现整个安装过程的无人职守,也不需要手动点击,非常方便快捷.

      在上一篇的博客中,我写了利用PXE从网络安装Linux,其中,已经架设好了一台Linux服务器,我还是用Putty登陆查看相应的服务是否已经启动:
 
可以看到,nfs服务已经启动:
 
挂载光盘,这里我们可以将光盘的内容拷贝到一个目录下,在后面输入“NFS directory”的时候可以输入这个目录:
 
这里可以看到光盘挂载的目录:
 
然后,新建一台虚拟机,先从网络手动安装一次,将其安装的过程保存起来得到一个脚本.
选择从网络安装:
 
选择NFS镜像:
 
自动获取IP地址:
 
输入NFS服务器名,就是我们刚才的Linux主机,再输入光盘挂载的目录:
 
稍等片刻,出现安装界面。之后就和我们用光盘安装是一样的,只需点击下一步,进行磁盘分区和输入root密码,最后整个安装过程完成。
 
登陆我们才装好的Linux系统,在/root目录下我们可以看到有个”anaconda-ks.cfg”的脚本:

此脚本包含了我们刚才安装Linux时的一系列信息,有安装语言,网络选择,磁盘分区等等信息,只需要将此脚本做一些改动就可以实现全自动安装:
 
 
我们在服务器上做一些配置
 
利用NFS加一个共享的目录:

新建目录:/disk 并建立一个自动控制脚本:ks.cfg 将刚才安装的Linux下的“anaconda-ks.cfg”脚本的内容拷贝进来,只需加入NFS服务器的IP地址和共享的光盘目录,其它的都不做改变:

 
然后在exports文件中加入刚才建立的目录:
 
/disk *代表任何用户都可以访问,以只读方式和只放入内存中共享:
(这里建议大家将光盘内容拷贝到一个目录并且和这个共享目录放在一起,这样安装的时候更方便,速度也更快一些)
 
下面修改引导脚本:
 
timeout 改为10
控制方式使用nfs,并加入IP地址和控制脚本:
将控制脚本默认加载在引导脚本里面了,保存退出.
 
重启NFS服务:
 
 
最后我们新建一台虚拟机再进行测试,可以看到,一切操作都是自动运行的:
到此,整个PXE网络自动安装已经完成.

以上文章摘自

http://qiulove.blog.51cto.com/516754/144776

Posted in Linux | Leave a comment

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