介绍两个很方便的命令,rz和sz,这两个命令能在你使用Xshell SecureCRT登录时,执行rz可以上传文件到服务器,执行sz file可以下载文件到客户端,putty不支持这两个命令。 继续阅读Xshell SecureCRT rz sz上传下载命令
分类:FAQ
关于CentOS Linux常见的问题及解决方案
varnish流程图
使用UglifyJS压缩javascript代码
之前是想通过nginx_lua模块简单地对js进行压缩,但是在第一步删除js的单行注释就难倒了我,通过正则我想是处理不了的,只好去搜索有哪些好用的js压缩软件,找到了UglifyJS这个基于node.js的js压缩引擎。这个工具可以在linux命令行使用,也提供了NodeJS的API。我们这里是通过lua的os.popen直接调用uglifyjs命令来压缩js。
一、Node.js安装
- cd /tmp
- wget http://nodejs.org/dist/v0.8.12/node-v0.8.12.tar.gz
- tar xzf node-v0.8.12.tar.gz
- cd node-v0.8.12
- ./configure && make && make install
注意:需要python的版本为2.6以上,否则会出现错误:
- File "./configure", line 330
- o[‘default_configuration’] = ‘Debug’ if options.debug else ‘Release’
- ^
- SyntaxError: invalid syntax
升级python可以参考:http://devops.webres.wang/2012/10/linux-python-upgrade/
二、安装UglifyJS
- npm install uglify-js
有可能出现的问题:
1、ImportError: No module named bz2
解决方法:
- yum -y install bzip2 bzip2-devel
- cd /tmp/Python-2.7.3/Modules/zlib
- ./configure && make && make install
- cd ../../
- python setup.py install
三、UglifyJS使用
1、使用命令行
语法:uglifyjs [ options… ] [ filename ]
详细的用法:https://github.com/mishoo/UglifyJS
2、使用node.js http
server.js脚本内容:
- var http = require("http");
- var jsp = require("uglify-js").parser;
- var pro = require("uglify-js").uglify;
- function onRequest(request, response) {
- var postData = "";
- request.setEncoding("utf8");
- request.addListener("data", function(postDataChunk) {
- postData += postDataChunk;
- });
- request.addListener("end", function() {
- var orig_code = postData;
- var ast = jsp.parse(orig_code);
- ast = pro.ast_mangle(ast);
- ast = pro.ast_squeeze(ast);
- var final_code = pro.gen_code(ast);
- response.writeHead(200, {"Content-Type": "text/plain"});
- response.write(final_code);
- response.end();
- });
- }
- http.createServer(onRequest).listen(8888,"127.0.0.1");
- console.log("Server has started.");
执行node server.js即可。
centos安装git
1、安装依赖
- yum -y install curl curl-devel zlib-devel openssl-devel perl cpio expat-devel gettext-devel autoconf
2、开始安装
- wget http://www.codemonkey.org.uk/projects/git-snapshots/git/git-latest.tar.gz
- tar xzvf git-latest.tar.gz
- cd git-`date +%F`
- autoconf
- ./configure
- make && make install
3、查看版本
- git –version
git version 1.7.12.GIT
NTP时间服务器工作原理
NTP简介
NTP(Network Time Protocol, 网络时间协议)是由RFC 1305定义的时间同步协议,用来在分布式时间服务器和客户端之间进行时间同步,NTP基于UDP保温进行传输,使用UDP端口号为123。
使用NTP的目的是对网络内所有具有时钟的设备进行时钟同步,使网络内所有设备的时钟保持一致,从而使设备能够提供基于统一时间的多种应用。
对于运行NTP的本地系统,既可以接受来自其他时钟源的同步,又可以作为时钟源同步其他的时钟,并且可以喝其他设备互相同步。
NTP工作原理
NTP的基本工作原理如图1-1所示。Device A和Device B通过网络相连,他们都有自己独立的系统时钟,需要通过NTP实现各自系统时钟的自动同步。为便于理解,作如下假设:
图1-1 NTP原理图
系统时钟同步过程如下:
这样,设备A就能够根据这些信息来设定自己的时钟,使之与设备B的时钟同步。
以上内容只是对NTP工作原理的一个粗略描述,更详细的资料可以参阅RFC 1305。
NTP工作模式
设备可以采用多种NTP工作模式进行时间同步:
用户可以根据需要选择合适的工作模式。在不能确定服务器或对等体IP地址、网络中需要同步的设备很多等情况下,可以通过广播或组播模式实现时钟同步;服务器和对等体模式中,设备从指定的服务器或对等体获得时钟同步,增加了时钟的可靠性。
1、客户端/服务器模式
在该模式下,客户端能同步到服务器,而服务器无法同步到客户端。Mode3客户模式,mode4服务模式,
适用于一台时间服务器接收上层时间服务器的时间信息,并提供时间信息给下层的用户。
2、对等模式
主动对等体和被动对等体可以互相同步。如果双方的时钟都已经同步,则以层数小的时钟为准。Mode1是主对等体模式,mode2被对等体模式,mode3客户模式,mode4是服务模式
3、广播模式
在广播模式中,服务器端周期性地向广播地址255.255.255.255发送时钟同步报文,报文中的Mode字段设置为5(广播模式)。客户端侦听来自服务器的广播报文。流程如图1-4所示。Mode3客户模式,mode4服务模式
4、组播模式
在组播模式中,服务端周期性地向组播地址发送时钟同步报文。报文中的mode5是组播模式,mode4是服务器模式,mode3是客户模式。
FTP主动模式与FTP被动模式
FTP是仅基于TCP的服务,不支持UDP。 与众不同的是FTP使用2个端口,一个数据端口和一个命令端口(也可叫做控制端口)。通常来说这两个端口是21(命令端口)和20(数据端口)。但FTP 工作方式的不同,数据端口并不总是20。这就是主动与被动FTP的最大不同之处。
(一)主动FTP
主动方式的FTP是这样的:客户端从一个任意的非特权端口N(N>1024)连接到FTP服务器的命令端口,也就是21端口。然后客户端开始监听端口N+1,并发送FTP命令“port N+1”到FTP服务器。接着服务器会从它自己的数据端口(20)连接到客户端指定的数据端口(N+1)。
针对FTP服务器前面的防火墙来说,必须允许以下通讯才能支持主动方式FTP:
1. 任何大于1024的端口到FTP服务器的21端口。(客户端初始化的连接)
2. FTP服务器的21端口到大于1024的端口。 (服务器响应客户端的控制端口)
3. FTP服务器的20端口到大于1024的端口。(服务器端初始化数据连接到客户端的数据端口)
4. 大于1024端口到FTP服务器的20端口(客户端发送ACK响应到服务器的数据端口)
(二)被动FTP
为了解决服务器发起到客户的连接的问题,人们开发了一种不同的FTP连接方式。这就是所谓的被动方式,或者叫做PASV,当客户端通知服务器它处于被动模式时才启用。
在被动方式FTP中,命令连接和数据连接都由客户端发起,这样就可以解决从服务器到客户端的数据端口的入方向连接被防火墙过滤掉的问题。
当开启一个 FTP连接时,客户端打开两个任意的非特权本地端口(N > 1024和N+1)。第一个端口连接服务器的21端口,但与主动方式的FTP不同,客户端不会提交PORT命令并允许服务器来回连它的数据端口,而是提交 PASV命令。这样做的结果是服务器会开启一个任意的非特权端口(P > 1024),并发送PORT P命令给客户端。然后客户端发起从本地端口N+1到服务器的端口P的连接用来传送数据。
对于服务器端的防火墙来说,必须允许下面的通讯才能支持被动方式的FTP:
1. 从任何大于1024的端口到服务器的21端口 (客户端初始化的连接)
2. 服务器的21端口到任何大于1024的端口 (服务器响应到客户端的控制端口的连接)
3. 从任何大于1024端口到服务器的大于1024端口 (客户端初始化数据连接到服务器指定的任意端口)
4. 服务器的大于1024端口到远程的大于1024的端口(服务器发送ACK响应和数据到客户端的数据端口)
以上关于主动和被动FTP的解释,可以简单概括为以下两点:
1、主动FTP:
命令连接:客户端 >1024端口 -> 服务器 21端口
数据连接:客户端 >1024端口 1024端口 -> 服务器 21端口
数据连接:客户端 >1024端口 -> 服务器 >1024端口
(三) 主动与被动FTP优缺点:
主动FTP对FTP服务器的管理有利,但对客户端的管理不利。因为FTP服务器企图与客户端的高位随机端口建立连接,而这个端口很有可能被客户端的防火墙阻塞掉。被动FTP对FTP客户端的管理有利,但对服务器端的管理不利。因为客户端要与服务器端建立两个连接,其中一个连到一个高位随机端口,而这个端口很有可能被服务器端的防火墙阻塞掉。
幸运的是,有折衷的办法。既然FTP服务器的管理员需要他们的服务器有最多的客户连接,那么必须得支持被动FTP。我们可以通过为FTP服务器指定一个有 限的端口范围来减小服务器高位端口的暴露。这样,不在这个范围的任何端口会被服务器的防火墙阻塞。虽然这没有消除所有针对服务器的危险,但它大大减少了危 险。
简而言之:
主动模式(PORT)和被动模式(PASV)。主动模式是从服务器端向客户端发起连接;被动模式是客户端向服务器端发起连接。两者的共同点是都使用 21端口进行用户验证及管理,差别在于传送数据的方式不同,PORT模式的FTP服务器数据端口固定在20,而PASV模式则在1025-65535之间随机
FTP主动模式与被动模式的解决与原理
FTP是File Transfer Protocol(文件传输协议)的缩写,用来在两台计算机之间互相传送文件。相比于HTTP,FTP协议要复杂得多。复杂的原因,是因为FTP协议要用到两个TCP连接,一个是命令链路,用来在FTP客户端与服务器之间传递命令;另一个是数据链路,用来上传或下载数据。
FTP协议有两种工作方式:PORT方式和PASV方式,中文意思为主动式和被动式。
PORT(主动)方式的连接过程是:客户端向服务器的FTP端口(默认是21)发送连接请求,服务器接受连接,建立一条命令链路。当需要传送数据时,客户端在命令链路上用PORT命令告诉服务器:“我打开了XXXX端口,你过来连接我”。于是服务器从20端口向客户端的XXXX端口发送连接请求,建立一条数据链路来传送数据。
PASV(被动)方式的连接过程是:客户端向服务器的FTP端口(默认是21)发送连接请求,服务器接受连接,建立一条命令链路。当需要传送数据时,服务器在命令链路上用PASV命令告诉客户端:“我打开了XXXX端口,你过来连接我”。于是客户端向服务器的XXXX端口发送连接请求,建立一条数据链路来传送数据。
概括:
——————————————————————————–
主动模式:服务器向客户端敲门,然后客户端开门
被动模式:客户端向服务器敲门,然后服务器开门
所以,如果你是如果通过代理上网的话,就不能用主动模式,因为服务器敲的是上网代理服务器的门,而不是敲客户端的门
而且有时候,客户端也不是轻易就开门的,因为有防火墙阻挡,除非客户端开放大于1024的高端端口
——————————————————————————–
要用主动模式来下载,请您把下载工具的被动模式(PASV)都不要打勾,用主动模式来下载就OK了,如果在出错,那就被动主动相互转换一下
常见的FTP客户端软件的PASV方式的关闭方法
大部分FTP客户端默认使用PASV方式,PASV模式的意式是被动模式。 在大部分FTP客户端的设置里,常见到的字眼都是“PASV”或“被动模式”。
IE: 工具 -> Internet选项 -> 高级 -> “使用被动FTP”(需要IE6.0以上才支持)。
CuteFTP: Edit -> Setting -> Connection -> Firewall -> “PASV Mode”
或 File -> Site Manager,在左边选中站点 -> Edit -> “Use PASV mode”
FlashGet: 工具 -> 选项 -> 代理服务器 -> 直接连接 -> 编辑 -> “PASV模式”
FlashFXP: 选项 -> 参数选择 -> 代理/防火墙/标识 -> “使用被动模式”
或 站点管理 -> 对应站点 -> 选项 -> “使用被动模式”
或 快速连接 -> 切换 -> “使用被动模式”
LeapFTP: Option ->Preferences -> General->Proxy->Use Pasv Mode
从上面可以看出,两种方式的命令链路连接方法是一样的,而数据链路的建立方法就完全不同。而FTP的复杂性就在于此。
数字证书原理
文中首先解释了加密解密的一些基础知识和概念,然后通过一个加密通信过程的例子说明了加密算法的作用,以及数字证书的出现所起的作用。接着对数字证书做一个详细的解释,并讨论一下windows中数字证书的管理,最后演示使用makecert生成数字证书。如果发现文中有错误的地方,或者有什么地方说得不够清楚,欢迎指出!
1、基础知识
这部分内容主要解释一些概念和术语,最好是先理解这部分内容。
1.1、公钥密码体制(public-key cryptography)
公钥密码体制分为三个部分,公钥、私钥、加密解密算法,它的加密解密过程如下:
- 加密:通过加密算法和公钥对内容(或者说明文)进行加密,得到密文。加密过程需要用到公钥。
- 解密:通过解密算法和私钥对密文进行解密,得到明文。解密过程需要用到解密算法和私钥。注意,由公钥加密的内容,只能由私钥进行解密,也就是说,由公钥加密的内容,如果不知道私钥,是无法解密的。
公钥密码体制的公钥和算法都是公开的(这是为什么叫公钥密码体制的原因),私钥是保密的。大家都以使用公钥进行加密,但是只有私钥的持有者才能解密。在实际的使用中,有需要的人会生成一对公钥和私钥,把公钥发布出去给别人使用,自己保留私钥。
1.2、对称加密算法(symmetric key algorithms)
在对称加密算法中,加密使用的密钥和解密使用的密钥是相同的。也就是说,加密和解密都是使用的同一个密钥。因此对称加密算法要保证安全性的话,密钥要做好保密,只能让使用的人知道,不能对外公开。这个和上面的公钥密码体制有所不同,公钥密码体制中加密是用公钥,解密使用私钥,而对称加密算法中,加密和解密都是使用同一个密钥,不区分公钥和私钥。
// 密钥,一般就是一个字符串或数字,在加密或者解密时传递给加密/解密算法。前面在公钥密码体制中说到的公钥、私钥就是密钥,公钥是加密使用的密钥,私钥是解密使用的密钥。
1.3、非对称加密算法(asymmetric key algorithms)
在非对称加密算法中,加密使用的密钥和解密使用的密钥是不相同的。前面所说的公钥密码体制就是一种非对称加密算法,他的公钥和是私钥是不能相同的,也就是说加密使用的密钥和解密使用的密钥不同,因此它是一个非对称加密算法。
1.4、RSA简介
RSA是一种公钥密码体制,现在使用得很广泛。如果对RSA本身有兴趣的,后面看我有没有时间写个RSA的具体介绍。
RSA密码体制是一种公钥密码体制,公钥公开,私钥保密,它的加密解密算法是公开的。 由公钥加密的内容可以并且只能由私钥进行解密,并且由私钥加密的内容可以并且只能由公钥进行解密。也就是说,RSA的这一对公钥、私钥都可以用来加密和解密,并且一方加密的内容可以由并且只能由对方进行解密。
1.5、签名和加密
我们说加密,是指对某个内容加密,加密后的内容还可以通过解密进行还原。 比如我们把一封邮件进行加密,加密后的内容在网络上进行传输,接收者在收到后,通过解密可以还原邮件的真实内容。
这里主要解释一下签名,签名就是在信息的后面再加上一段内容,可以证明信息没有被修改过,怎么样可以达到这个效果呢?一般是对信息做一个hash计算得到一个hash值,注意,这个过程是不可逆的,也就是说无法通过hash值得出原来的信息内容。在把信息发送出去时,把这个hash值加密后做为一个签名和信息一起发出去。 接收方在收到信息后,会重新计算信息的hash值,并和信息所附带的hash值(解密后)进行对比,如果一致,就说明信息的内容没有被修改过,因为这里hash计算可以保证不同的内容一定会得到不同的hash值,所以只要内容一被修改,根据信息内容计算的hash值就会变化。当然,不怀好意的人也可以修改信息内容的同时也修改hash值,从而让它们可以相匹配,为了防止这种情况,hash值一般都会加密后(也就是签名)再和信息一起发送,以保证这个hash值不被修改。至于如何让别人可以解密这个签名,这个过程涉及到数字证书等概念,我们后面在说到数字证书时再详细说明,这里您先只需先理解签名的这个概念。
2、一个加密通信过程的演化
我们来看一个例子,现在假设“服务器”和“客户”要在网络上通信,并且他们打算使用RSA(参看前面的RSA简介)来对通信进行加密以保证谈话内容的安全。由于是使用RSA这种公钥密码体制,“服务器”需要对外发布公钥(算法不需要公布,RSA的算法大家都知道),自己留着私钥。“客户”通过某些途径拿到了“服务器”发布的公钥,客户并不知道私钥。“客户”具体是通过什么途径获取公钥的,我们后面再来说明,下面看一下双方如何进行保密的通信:
2.1 第一回合:
“客户”->“服务器”:你好
“服务器”->“客户”:你好,我是服务器
“客户”->“服务器”:????
因为消息是在网络上传输的,有人可以冒充自己是“服务器”来向客户发送信息。例如上面的消息可以被黑客截获如下:
“客户”->“服务器”:你好
“服务器”->“客户”:你好,我是服务器
“客户”->“黑客”:你好 // 黑客在“客户”和“服务器”之间的某个路由器上截获“客户”发给服务器的信息,然后自己冒充“服务器”
“黑客”->“客户”:你好,我是服务器
因此“客户”在接到消息后,并不能肯定这个消息就是由“服务器”发出的,某些“黑客”也可以冒充“服务器”发出这个消息。如何确定信息是由“服务器”发过来的呢?有一个解决方法,因为只有服务器有私钥,所以如果只要能够确认对方有私钥,那么对方就是“服务器”。因此通信过程可以改进为如下:
2.2 第二回合:
“客户”->“服务器”:你好
“服务器”->“客户”:你好,我是服务器
“客户”->“服务器”:向我证明你就是服务器
“服务器”->“客户”:你好,我是服务器 {你好,我是服务器}[私钥|RSA]
// 注意这里约定一下,{} 表示RSA加密后的内容,[ | ]表示用什么密钥和算法进行加密,后面的示例中都用这种表示方式,例如上面的 {你好,我是服务器}[私钥|RSA] 就表示用私钥对“你好,我是服务器”进行加密后的结果。
为了向“客户”证明自己是“服务器”, “服务器”把一个字符串用自己的私钥加密,把明文和加密后的密文一起发给“客户”。对于这里的例子来说,就是把字符串 “你好,我是服务器”和这个字符串用私钥加密后的内容 {你好,我是服务器}[私钥|RSA] 发给客户。
“客户”收到信息后,她用自己持有的公钥解密密文,和明文进行对比,如果一致,说明信息的确是由服务器发过来的。也就是说“客户”把 {你好,我是服务器}[私钥|RSA] 这个内容用公钥进行解密,然后和“你好,我是服务器”对比。因为由“服务器”用私钥加密后的内容,由并且只能由公钥进行解密,私钥只有“服务器”持有,所以如果解密出来的内容是能够对得上的,那说明信息一定是从“服务器”发过来的。
假设“黑客”想冒充“服务器”:
“黑客”->“客户”:你好,我是服务器
“客户”->“黑客”:向我证明你就是服务器
“黑客”->“客户”:你好,我是服务器 {你好,我是服务器}[???|RSA] //这里黑客无法冒充,因为他不知道私钥,无法用私钥加密某个字符串后发送给客户去验证。
“客户”->“黑客”:????
由于“黑客”没有“服务器”的私钥,因此它发送过去的内容,“客户”是无法通过服务器的公钥解密的,因此可以认定对方是个冒牌货!
到这里为止,“客户”就可以确认“服务器”的身份了,可以放心和“服务器”进行通信,但是这里有一个问题,通信的内容在网络上还是无法保密。为什么无法保密呢?通信过程不是可以用公钥、私钥加密吗?其实用RSA的私钥和公钥是不行的,我们来具体分析下过程,看下面的演示:
2.3 第三回合:
“客户”->“服务器”:你好
“服务器”->“客户”:你好,我是服务器
“客户”->“服务器”:向我证明你就是服务器
“服务器”->“客户”:你好,我是服务器 {你好,我是服务器}[私钥|RSA]
“客户”->“服务器”:{我的帐号是aaa,密码是123,把我的余额的信息发给我看看}[公钥|RSA]
“服务器”->“客户”:{你的余额是100元}[私钥|RSA]
注意上面的的信息 {你的余额是100元}[私钥],这个是“服务器”用私钥加密后的内容,但是我们之前说了,公钥是发布出去的,因此所有的人都知道公钥,所以除了“客户”,其它的人也可以用公钥对{你的余额是100元}[私钥]进行解密。所以如果“服务器”用私钥加密发给“客户”,这个信息是无法保密的,因为只要有公钥就可以解密这内容。然而“服务器”也不能用公钥对发送的内容进行加密,因为“客户”没有私钥,发送个“客户”也解密不了。
这样问题就又来了,那又如何解决呢?在实际的应用过程,一般是通过引入对称加密来解决这个问题,看下面的演示:
2.4 第四回合:
“客户”->“服务器”:你好
“服务器”->“客户”:你好,我是服务器
“客户”->“服务器”:向我证明你就是服务器
“服务器”->“客户”:你好,我是服务器 {你好,我是服务器}[私钥|RSA]
“客户”->“服务器”:{我们后面的通信过程,用对称加密来进行,这里是对称加密算法和密钥}[公钥|RSA] //蓝色字体的部分是对称加密的算法和密钥的具体内容,客户把它们发送给服务器。
“服务器”->“客户”:{OK,收到!}[密钥|对称加密算法]
“客户”->“服务器”:{我的帐号是aaa,密码是123,把我的余额的信息发给我看看}[密钥|对称加密算法]
“服务器”->“客户”:{你的余额是100元}[密钥|对称加密算法]
在上面的通信过程中,“客户”在确认了“服务器”的身份后,“客户”自己选择一个对称加密算法和一个密钥,把这个对称加密算法和密钥一起用公钥加密后发送给“服务器”。注意,由于对称加密算法和密钥是用公钥加密的,就算这个加密后的内容被“黑客”截获了,由于没有私钥,“黑客”也无从知道对称加密算法和密钥的内容。
由于是用公钥加密的,只有私钥能够解密,这样就可以保证只有服务器可以知道对称加密算法和密钥,而其它人不可能知道(这个对称加密算法和密钥是“客户”自己选择的,所以“客户”自己当然知道如何解密加密)。这样“服务器”和“客户”就可以用对称加密算法和密钥来加密通信的内容了。
总结一下,RSA加密算法在这个通信过程中所起到的作用主要有两个:
- 因为私钥只有“服务器”拥有,因此“客户”可以通过判断对方是否有私钥来判断对方是否是“服务器”。
- 客户端通过RSA的掩护,安全的和服务器商量好一个对称加密算法和密钥来保证后面通信过程内容的安全。
如果这里您理解了为什么不用RSA去加密通信过程,而是要再确定一个对称加密算法来保证通信过程的安全,那么就说明前面的内容您已经理解了。(如果不清楚,再看下2.3和2.4,如果还是不清楚,那应该是我们说清楚,您可以留言提问。)
到这里,“客户”就可以确认“服务器”的身份,并且双方的通信内容可以进行加密,其他人就算截获了通信内容,也无法解密。的确,好像通信的过程是比较安全了。
但是这里还留有一个问题,在最开始我们就说过,“服务器”要对外发布公钥,那“服务器”如何把公钥发送给“客户”呢?我们第一反应可能会想到以下的两个方法:
a)把公钥放到互联网的某个地方的一个下载地址,事先给“客户”去下载。
b)每次和“客户”开始通信时,“服务器”把公钥发给“客户”。
但是这个两个方法都有一定的问题,
对于a)方法,“客户”无法确定这个下载地址是不是“服务器”发布的,你凭什么就相信这个地址下载的东西就是“服务器”发布的而不是别人伪造的呢,万一下载到一个假的怎么办?另外要所有的“客户”都在通信前事先去下载公钥也很不现实。
对于b)方法,也有问题,因为任何人都可以自己生成一对公钥和私钥,他只要向“客户”发送他自己的私钥就可以冒充“服务器”了。示意如下:
“客户”->“黑客”:你好 //黑客截获“客户”发给“服务器”的消息
“黑客”->“客户”:你好,我是服务器,这个是我的公钥 //黑客自己生成一对公钥和私钥,把公钥发给“客户”,自己保留私钥
“客户”->“黑客”:向我证明你就是服务器
“黑客”->“客户”:你好,我是服务器 {你好,我是服务器}[黑客自己的私钥|RSA] //客户收到“黑客”用私钥加密的信息后,是可以用“黑客”发给自己的公钥解密的,从而会误认为“黑客”是“服务器”
因此“黑客”只需要自己生成一对公钥和私钥,然后把公钥发送给“客户”,自己保留私钥,这样由于“客户”可以用黑客的公钥解密黑客的私钥加密的内容,“客户”就会相信“黑客”是“服务器”,从而导致了安全问题。这里问题的根源就在于,大家都可以生成公钥、私钥对,无法确认公钥对到底是谁的。 如果能够确定公钥到底是谁的,就不会有这个问题了。例如,如果收到“黑客”冒充“服务器”发过来的公钥,经过某种检查,如果能够发现这个公钥不是“服务器”的就好了。
为了解决这个问题,数字证书出现了,它可以解决我们上面的问题。先大概看下什么是数字证书,一个证书包含下面的具体内容:
- 证书的发布机构
- 证书的有效期
- 公钥
- 证书所有者(Subject)
- 签名所使用的算法
- 指纹以及指纹算法
证书的内容的详细解释会在后面详细解释,这里先只需要搞清楚一点,数字证书可以保证数字证书里的公钥确实是这个证书的所有者(Subject)的,或者证书可以用来确认对方的身份。也就是说,我们拿到一个数字证书,我们可以判断出这个数字证书到底是谁的。至于是如何判断的,后面会在详细讨论数字证书时详细解释。现在把前面的通信过程使用数字证书修改为如下:
2.5 第五回合:
“客户”->“服务器”:你好
“服务器”->“客户”:你好,我是服务器,这里是我的数字证书 //这里用证书代替了公钥
“客户”->“服务器”:向我证明你就是服务器
“服务器”->“客户”:你好,我是服务器 {你好,我是服务器}[私钥|RSA]
注意,上面第二次通信,“服务器”把自己的证书发给了“客户”,而不是发送公钥。“客户”可以根据证书校验这个证书到底是不是“服务器”的,也就是能校验这个证书的所有者是不是“服务器”,从而确认这个证书中的公钥的确是“服务器”的。后面的过程和以前是一样,“客户”让“服务器”证明自己的身份,“服务器”用私钥加密一段内容连同明文一起发给“客户”,“客户”把加密内容用数字证书中的公钥解密后和明文对比,如果一致,那么对方就确实是“服务器”,然后双方协商一个对称加密来保证通信过程的安全。到这里,整个过程就完整了,我们回顾一下:
2.6 完整过程:
step1: “客户”向服务端发送一个通信请求
“客户”->“服务器”:你好
step2: “服务器”向客户发送自己的数字证书。证书中有一个公钥用来加密信息,私钥由“服务器”持有
“服务器”->“客户”:你好,我是服务器,这里是我的数字证书
step3: “客户”收到“服务器”的证书后,它会去验证这个数字证书到底是不是“服务器”的,数字证书有没有什么问题,数字证书如果检查没有问题,就说明数字证书中的公钥确实是“服务器”的。检查数字证书后,“客户”会发送一个随机的字符串给“服务器”用私钥去加密,服务器把加密的结果返回给“客户”,“客户”用公钥解密这个返回结果,如果解密结果与之前生成的随机字符串一致,那说明对方确实是私钥的持有者,或者说对方确实是“服务器”。
“客户”->“服务器”:向我证明你就是服务器,这是一个随机字符串 //前面的例子中为了方便解释,用的是“你好”等内容,实际情况下一般是随机生成的一个字符串。
“服务器”->“客户”:{一个随机字符串}[私钥|RSA]
step4: 验证“服务器”的身份后,“客户”生成一个对称加密算法和密钥,用于后面的通信的加密和解密。这个对称加密算法和密钥,“客户”会用公钥加密后发送给“服务器”,别人截获了也没用,因为只有“服务器”手中有可以解密的私钥。这样,后面“服务器”和“客户”就都可以用对称加密算法来加密和解密通信内容了。
“服务器”->“客户”:{OK,已经收到你发来的对称加密算法和密钥!有什么可以帮到你的?}[密钥|对称加密算法]
“客户”->“服务器”:{我的帐号是aaa,密码是123,把我的余额的信息发给我看看}[密钥|对称加密算法]
“服务器”->“客户”:{你好,你的余额是100元}[密钥|对称加密算法]
…… //继续其它的通信
2.7 其它问题:
上面的过程已经十分接近HTTPS的真实通信过程了,完全可以按照这个过程去理解HTTPS的工作原理。但是我为了方便解释,上面有些细节没有说到,有兴趣的人可以看下这部分的内容。可以跳过不看,无关紧要。
【问题1】
上面的通信过程中说到,在检查完证书后,“客户”发送一个随机的字符串给“服务器”去用私钥加密,以便判断对方是否真的持有私钥。但是有一个问题,“黑客”也可以发送一个字符串给“服务器”去加密并且得到加密后的内容,这样对于“服务器”来说是不安全的,因为黑客可以发送一些简单的有规律的字符串给“服务器”加密,从而寻找加密的规律,有可能威胁到私钥的安全。所以说,“服务器”随随便便用私钥去加密一个来路不明的字符串并把结果发送给对方是不安全的。
〖解决方法〗
每次收到“客户”发来的要加密的的字符串时,“服务器”并不是真正的加密这个字符串本身,而是把这个字符串进行一个hash计算,加密这个字符串的hash值(不加密原来的字符串)后发送给“客户”,“客户”收到后解密这个hash值并自己计算字符串的hash值然后进行对比是否一致。也就是说,“服务器”不直接加密收到的字符串,而是加密这个字符串的一个hash值,这样就避免了加密那些有规律的字符串,从而降低被破解的机率。“客户”自己发送的字符串,因此它自己可以计算字符串的hash值,然后再把“服务器”发送过来的加密的hash值和自己计算的进行对比,同样也能确定对方是否是“服务器”。
【问题2】
在双方的通信过程中,“黑客”可以截获发送的加密了的内容,虽然他无法解密这个内容,但是他可以捣乱,例如把信息原封不动的发送多次,扰乱通信过程。
〖解决方法〗
可以给通信的内容加上一个序号或者一个随机的值,如果“客户”或者“服务器”接收到的信息中有之前出现过的序号或者随机值,那么说明有人在通信过程中重发信息内容进行捣乱,双方会立刻停止通信。有人可能会问,如果有人一直这么捣乱怎么办?那不是无法通信了? 答案是的确是这样的,例如有人控制了你连接互联网的路由器,他的确可以针对你。但是一些重要的应用,例如军队或者政府的内部网络,它们都不使用我们平时使用的公网,因此一般人不会破坏到他们的通信。
【问题3】
在双方的通信过程中,“黑客”除了简单的重复发送截获的消息之外,还可以修改截获后的密文修改后再发送,因为修改的是密文,虽然不能完全控制消息解密后的内容,但是仍然会破坏解密后的密文。因此发送过程如果黑客对密文进行了修改,“客户”和“服务器”是无法判断密文是否被修改的。虽然不一定能达到目的,但是“黑客”可以一直这样碰碰运气。
〖解决方法〗
在每次发送信息时,先对信息的内容进行一个hash计算得出一个hash值,将信息的内容和这个hash值一起加密后发送。接收方在收到后进行解密得到明文的内容和hash值,然后接收方再自己对收到信息内容做一次hash计算,与收到的hash值进行对比看是否匹配,如果匹配就说明信息在传输过程中没有被修改过。如果不匹配说明中途有人故意对加密数据进行了修改,立刻中断通话过程后做其它处理。
3. 证书的构成和原理
3.1 证书的构成和原理
之前已经大概说了一个证书由什么构成,但是没有仔细进行介绍,这里对证书的内容做一个详细的介绍。先看下一个证书到底是个什么东西,在windows下查看一个证书时,界面是这样的,我们主要关注一下Details Tab页,其中的内容比较长,我滚动内容后后抓了三个图,把完整的信息显示出来:
里面的内容比较多——Version、Serial number、Signature algorithm 等等,挑几个重要的解释一下。
◆Issuer (证书的发布机构)
指出是什么机构发布的这个证书,也就是指明这个证书是哪个公司创建的(只是创建证书,不是指证书的使用者)。对于上面的这个证书来说,就是指”SecureTrust CA”这个机构。
◆Valid from , Valid to (证书的有效期)
也就是证书的有效时间,或者说证书的使用期限。 过了有效期限,证书就会作废,不能使用了。
◆Public key (公钥)
这个我们在前面介绍公钥密码体制时介绍过,公钥是用来对消息进行加密的,第2章的例子中经常用到的。这个数字证书的公钥是2048位的,它的值可以在图的中间的那个对话框中看得到,是很长的一串数字。
◆Subject (主题)
这个证书是发布给谁的,或者说证书的所有者,一般是某个人或者某个公司名称、机构的名称、公司网站的网址等。 对于这里的证书来说,证书的所有者是Trustwave这个公司。
◆Signature algorithm (签名所使用的算法)
就是指的这个数字证书的数字签名所使用的加密算法,这样就可以使用证书发布机构的证书里面的公钥,根据这个算法对指纹进行解密。指纹的加密结果就是数字签名(第1.5节中解释过数字签名)。
◆Thumbprint, Thumbprint algorithm (指纹以及指纹算法)
这个是用来保证证书的完整性的,也就是说确保证书没有被修改过,这东西的作用和2.7中说到的第3个问题类似。 其原理就是在发布证书时,发布者根据指纹算法(一个hash算法)计算整个证书的hash值(指纹)并和证书放在一起,使用者在打开证书时,自己也根据指纹算法计算一下证书的hash值(指纹),如果和刚开始的值对得上,就说明证书没有被修改过,因为证书的内容被修改后,根据证书的内容计算的出的hash值(指纹)是会变化的。 注意,这个指纹会使用”SecureTrust CA”这个证书机构的私钥用签名算法(Signature algorithm)加密后和证书放在一起。
注意,为了保证安全,在证书的发布机构发布证书时,证书的指纹和指纹算法,都会加密后再和证书放到一起发布,以防有人修改指纹后伪造相应的数字证书。这里问题又来了,证书的指纹和指纹算法用什么加密呢?他们是用证书发布机构的私钥进行加密的。可以用证书发布机构的公钥对指纹和指纹算法解密,也就是说证书发布机构除了给别人发布证书外,他自己本身也有自己的证书。证书发布机构的证书是哪里来的呢???这个证书发布机构的数字证书(一般由他自己生成)在我们的操作系统刚安装好时(例如windows xp等操作系统),这些证书发布机构的数字证书就已经被微软(或者其它操作系统的开发机构)安装在操作系统中了,微软等公司会根据一些权威安全机构的评估选取一些信誉很好并且通过一定的安全认证的证书发布机构,把这些证书发布机构的证书默认就安装在操作系统里面了,并且设置为操作系统信任的数字证书。这些证书发布机构自己持有与他自己的数字证书对应的私钥,他会用这个私钥加密所有他发布的证书的指纹作为数字签名。
3.2 如何向证书的发布机构去申请证书
举个例子方便大家理解,假设我们公司”ABC Company”花了1000块钱,向一个证书发布机构”SecureTrust CA”为我们自己的公司”ABC Company”申请了一张证书,注意,这个证书发布机构”SecureTrust CA”是一个大家公认并被一些权威机构接受的证书发布机构,我们的操作系统里面已经安装了”SecureTrust CA”的证书。”SecureTrust CA”在给我们发布证书时,把Issuer,Public key,Subject,Valid from,Valid to等信息以明文的形式写到证书里面,然后用一个指纹算法计算出这些数字证书内容的一个指纹,并把指纹和指纹算法用自己的私钥进行加密,然后和证书的内容一起发布,同时”SecureTrust CA”还会给一个我们公司”ABC Company”的私钥给到我们。我们花了1000块钱买的这个证书的内容如下:
×××××××××××××××证书内容开始×××××××××××××××××
Issuer : SecureTrust CA
Subject : ABC Company
Valid from : 某个日期
Valid to: 某个日期
Public Key : 一串很长的数字
…… 其它的一些证书内容……
{证书的指纹和计算指纹所使用的指纹算法}[SecureTrust CA的私钥|RSA] //这个就是”SecureTrust CA”对这个证书的一个数字签名,表示这个证书确实是他发布的,有什么问题他会负责(收了我们1000块,出了问题肯定要负责任的)
×××××××××××××××证书内容结束×××××××××××××××××
// 记不记得前面的约定?{} 表示RSA加密后的内容,[ | ]表示用什么密钥和算法进行加密
我们”ABC Company”申请到这个证书后,我们把证书投入使用,我们在通信过程开始时会把证书发给对方,对方如何检查这个证书的确是合法的并且是我们”ABC Company”公司的证书呢?首先应用程序(对方通信用的程序,例如IE、OUTLook等)读取证书中的Issuer(发布机构)为”SecureTrust CA” ,然后会在操作系统中受信任的发布机构的证书中去找”SecureTrust CA”的证书,如果找不到,那说明证书的发布机构是个水货发布机构,证书可能有问题,程序会给出一个错误信息。 如果在系统中找到了”SecureTrust CA”的证书,那么应用程序就会从证书中取出”SecureTrust CA”的公钥,然后对我们”ABC Company”公司的证书里面的指纹和指纹算法用这个公钥进行解密,然后使用这个指纹算法计算”ABC Company”证书的指纹,将这个计算的指纹与放在证书中的指纹对比,如果一致,说明”ABC Company”的证书肯定没有被修改过并且证书是”SecureTrust CA” 发布的,证书中的公钥肯定是”ABC Company”的。对方然后就可以放心的使用这个公钥和我们”ABC Company”进行通信了。
★这个部分非常重要,一定要理解,您可以重新回顾一下之前的两章“1、基础知识”和“ 2、一个加密通信过程的演化”,然后再来理解这部分的内容。如果您把这节的内容看了几遍还没有搞懂证书的工作原理,您可以留言指出我没有说清楚的内容,我好方便进行修正。
3.3 证书的发布机构
前面已经初步介绍了一下证书发布机构,这里再深入讨论一下。
其实所有的公司都可以发布证书,我们自己也可以去注册一家公司来专门给别人发布证书。但是很明显,我们自己的专门发布证书的公司是不会被那些国际上的权威机构认可的,人家怎么知道你是不是个狗屁皮包公司?因此微软在它的操作系统中,并不会信任我们这个证书发布机构,当应用程序在检查证书的合法信的时候,一看证书的发布机构并不是操作系统所信任的发布机构,就会抛出错误信息。也就是说windows操作系统中不会预先安装好我们这个证书发布机构的证书,不信任我们这个发布机构。
不受信任的证书发布机构的危害
为什么一个证书发布机构受不受信任这么重要?我们举个例子。假设我们开了一个狗屁公司来为别人发布证书,并且我和微软有一腿,微软在他们的操作系统中把我设置为了受信任的证书发布机构。现在如果有个小公司叫Wicrosoft 花了10块钱让我为他们公司申请了一个证书,并且公司慢慢壮大,证书的应用范围也越来越广。然后有个奸商的公司JS Company想冒充Wicrosoft,于是给了我¥10000,让我为他们颁布一个证书,但是证书的名字(Subject)要写Wicrosoft,假如我为了这¥10000,真的把证书给了他们,那么他们以后就可以使用这个证书来冒充Wicrosoft了。
如果是一个优秀的证书发布机构,比如你要向他申请一个名字叫Wicrosoft的证书,它会让你提供很多资料证明你确实可以代表Wicrosoft这个公司,也就是说他回去核实你的身份。证书发布机构是要为他发布出的证书负法律责任的。
到这里,你可能会想,TMD,那我们自己就不能发布证书吗?就一定要花钱去申请?当然不是,我们自己也可以成立证书发布机构,但是需要通过一些安全认证等等,只是有点麻烦。另外,如果数字证书只是要在公司内部使用,公司可以自己给自己生成一个证书,在公司的所有机器上把这个证书设置为操作系统信任的证书发布机构的证书(这句话仔细看清楚,有点绕口),这样以后公司发布的证书在公司内部的所有机器上就可以通过验证了(在发布证书时,把这些证书的Issuer(发布机构)设置为我们自己的证书发布机构的证书的Subject(主题)就可以了)。但是这只限于内部应用,因为只有我们公司自己的机器上设置了信任我们自己这个所谓的证书发布机构,而其它机器上并没有事先信任我们这个证书发布机构,所以在其它机器上,我们发布的证书就无法通过安全验证。
4. 在windows中对数字证书进行管理
4.1 查看、删除、安装 数字证书
我们在上一章中说到了,我们的操作系统中会预先安装好一些证书发布机构的证书,我们看下在windows中如何找到这些证书,步骤如下:
1)开始菜单->运行,输入mmc,回车
2)在打开的窗口中选择 File-> Add/Remove Snap-in…
3)然后在弹出的对话框的 Standalone Tab页里面点击 Add… 按钮
4)在弹出的对对话框中选择 certificates 后点击 Add 按钮
具体的步骤如下图所示:
上面的步骤结束后,会又弹出一个对话框,里面有三个单选按钮如下:
- My user account
- Service account
- Computer account
可以选择第一或者第三个选项,用来查看当前用户的证书或整个计算里面安装的证书。我们这里就默认选择第一个,平时一般安装证书的时候都会给所有用户安装,所以选择第一个和第三个选项看到的证书会差不多。我们在左边的导航树中选中受信任的证书发布机构(Trusted Root Certificate Authorities),然后点击下面的证书(Certificates),在右边的区域中就可以看到所有的受信任的证书发布机构的证书。
注意上面的图片中,右边我们选中的这个证书发布机构”SecureTrust CA”,我们前面在第3章3.2节中举例子的时候,就是去向这个证书发布机构申请的证书,由于我们申请的证书是这个机构发布的,所以应用程序在检查我们的证书的发布机构时(会检查我们证书的签名,确认是该机构发布的证书),就会发现是可以信任的证书发布机构,从而就会相信我们证书的真实性。
删除数字证书很简单,直接在右边的列表中右键然后删除就可以了。
数字证书的安装也比较简单,直接双击数字证书文件,会打开数字证书,对话框下面会有一个Install Certificate按钮,点击后就可以根据向导进行安装,如下图所示:
这个证书是我自己生成的测试证书,在证书的导入向导里面,它会让你选择导入到什么位置,如果是一个我们自己信任的证书发布机构自己的证书,只要导入到Certificate Authorities就可以了。Trusted Root Certificate Authorities, Intermediate Certification Authorities, Third-Party Root Certification Authorities 都是可以的,他们只是对证书的发布机构做了一个分类,还有一些其它的证书类型,例如Personal(个人证书)等等,具体就不介绍了。安装的时候一般来说可以用默认的选择项一直”下一步”到底。
4.2 如何自己创建证书
每个证书发布机构都有自己的用来创建证书的工具,当然,具体他们怎么去创建一个证书的我也不太清楚,不同类型的证书都有一定的格式和规范,我没有仔细去研究过这部分内容。 微软为我们提供了一个用来创建证书的工具makecert.exe,在安装Visual Studio的时候会安装上。如果没有安装也无所谓,可以上网去下一个,搜索makecert就可以了。可以直接从我的博客下载,这是链接。
向一些正规的证书发布机构申请证书一般是要收费的(因为别人要花时间检查你的身份,确认有没有同名的证书等等),这里我们看下如何自己创建一个证书,为后面在IIS中配置Https做准备。
我们用到的是makecert这个工具,微软有很详细的使用帮助,我这里只做一个简单的解释,详细的各种参数和使用方法请查看MSDN的makecert的帮助。但是里面有些参数说得不够清楚,而且还有遗漏的,可以参看我后面的解释作为一个补充。
先看下makecert最简单的使用方式:
makecert.exe test.cer
上面的命令会在makecert.exe所在的目录生成一个证书文件test.cer的数字证书文件。可以双击证书打开,看看证书的内容如下:
证书的发布机构是”Root Agency”,证书的主题(证书发布给谁)是”Joe’s-Software-Emporium”,因为我们没有指定把证书发布给谁,makecert自己给我们随便生成了一个公司的名字。另外还指定了公钥、签名算法(用来解密签名)、指纹和指纹算法等。
注意,因为这个证书是由微软的工具生成的,严格来说它没什么发布机构,所以微软虚拟了一个叫做”Root Agency”的发布机构,默认情况下,windows里面安装了这个所谓的证书发布机构的证书,但是这证书默认情况下不是受信任的,原因很简单,这样做大家都可以用makecert来制作合法的数字证书了。如果我们自己硬是要,也可以把它设置为受信任的。
下面我们看下其它的参数,比如我们要给网站 devops.webres.wang 生成一个证书MyCA.cer,假设我们把makecert.exe放在C:盘下,命令行如下:
C:> makecert.exe –pe -r –n “CN=devops.webres.wang” -ss my -sr LocalMachine -a sha1 -len 2048 MyCA.cer
解释一下makecert的常用参数的意思:
- -n 指定主题的名字,这个是有固定的格式的, CN=主题名字 ,CN应该是Certificate Name的缩写。我这里的主题的名字就是我们的IIS所在机器的IP。这里可以指定一些主题的其它附加信息,例如 O= *** 表示组织信息等等。
- -r 创建自签署证书,意思就是说在生成证书时,将证书的发布机构设置为自己。
- -pe 将所生成的私钥标记为可导出。注意,服务器发送证书给客户端的时候,客户端只能从证书里面获取公钥,私钥是无法获取的。如果我们指定了这个参数,证书在安装在机器上后,我们还可以从证书中导出私钥,默认情况下是不能导出私钥的。正规的途径发布的证书,是不可能让你导出私钥的。
- -b –e 证书的有效期
- -ss 证书的存储名称,就是windows证书存储区的目录名,如果不存在在的话就创建一个。
- -sr 证书的存储位置,只有currentuser(默认值)或 localmachine两个值。
- -sv 指定保存私钥的文件,文件里面除了包含私钥外,其实也包含了证书。这个文件是需要保密的,这个文件在服务端配置时是需要用到的。
- 这个CN=10.30.146.206要与自己的服务器相对应,要不然在配置HTTPS的时候会出现错误
- -a 指定签名算法,必须是md5或rsa1。(还记得签名算法的作用不?可以看一下3章的第1节中关于签名算法的介绍)
- -in 指定证书发布机构的名称
- -len 这个参数在中文的帮助文档中好像没有提到,但是这个其实很重要,用于指定公钥的位数,越大越安全,默认值是1024,推荐2048。我试了下,这个不为1024的倍数也是可以的。
生成证书后可以进行安装,安装过程可以参看4.1节。
原文:http://www.cnblogs.com/JeffreySun/archive/2010/06/24/1627247.html
正向代理与反向代理的区别
正向代理的概念
正向代理,也就是传说中的代理,他的工作原理就像一个跳板,
简单的说,
我是一个用户,我访问不了某网站,但是我能访问一个代理服务器
这个代理服务器呢,他能访问那个我不能访问的网站
于是我先连上代理服务器,告诉他我需要那个无法访问网站的内容
代理服务器去取回来,然后返回给我
从网站的角度,只在代理服务器来取内容的时候有一次记录
有时候并不知道是用户的请求,也隐藏了用户的资料,这取决于代理告不告诉网站
结论就是 正向代理 是一个位于客户端和原始服务器(origin server)之间的服务器,为了从原始服务器取得内容,客户端向代理发送一个请求并指定目标(原始服务器),然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。
反向代理的概念
继续举例:
例用户访问 http://ooxx.me/readme
但ooxx.me上并不存在readme页面
他是偷偷从另外一台服务器上取回来,然后作为自己的内容吐给用户
但用户并不知情
这很正常,用户一般都很笨
这里所提到的 ooxx.me 这个域名对应的服务器就设置了反向代理功能
结论就是 反向代理正好相反,对于客户端而言它就像是原始服务器,并且客户端不需要进行任何特别的设置。客户端向反向代理 的命名空间(name-space)中的内容发送普通请求,接着反向代理将判断向何处(原始服务器)转交请求,并将获得的内容返回给客户端,就像这些内容 原本就是它自己的一样。
两者区别
从用途上来讲:
正向代理的典型用途是为在防火墙内的局域网客户端提供访问Internet的途径。正向代理还可以使用缓冲特性减少网络使用率。反向代理的典型用途是将 防火墙后面的服务器提供给Internet用户访问。反向代理还可以为后端的多台服务器提供负载平衡,或为后端较慢的服务器提供缓冲服务。
另外,反向代理还可以启用高级URL策略和管理技术,从而使处于不同web服务器系统的web页面同时存在于同一个URL空间下。
从安全性来讲:
正向代理允许客户端通过它访问任意网站并且隐藏客户端自身,因此你必须采取安全措施以确保仅为经过授权的客户端提供服务。
反向代理对外都是透明的,访问者并不知道自己访问的是一个代理。
原文:http://ooxx.me/reverse-proxy.orz
Linux启动过程详解
Linux启动过程简述
1、加载bios硬件信息,并获取第一个启动设备的代号
2、读取第一个启动设备的mbr到物理内存,物理内存的内容就是Boot Loader了。
3、运行Boot Loader(如grub,lilo等),初始化硬件设备,建立内存空间映射图。
4、根据Boot Loader设定的内核映像路径,系统读取内存映像,解压内核,尝试驱动所有硬件设备。
5、运行第一个程序/sbin/init。
6、执行第一个/etc/rc.d/rc.sysinit脚本程序
7、依据/etc/modules.conf装载内核模块。
8、执行不同运行级别的脚本程序
9、执行/etc/rc.d/rc.local脚本程序
10、执行/bin/login,进入等待用户登录状态。
Linux启动过程详解
启动第一步--加载BIOS
当你打开计算机电源,计算机会首先加载BIOS信息,BIOS信息是如此的重要,以至于计算机必须在最开始就找到它。这是因为BIOS中包含了CPU的相关信息、设备启动顺序信息、硬盘信息、内存信息、时钟信息、PnP特性等等。在此之后,计算机心里就有谱了,知道应该去读取哪个硬件设备了。
启动第二步--读取MBR
众所周知,硬盘上第0磁道第一个扇区被称为MBR,也就是Master Boot Record,即主引导记录,它的大小是512字节,别看地方不大,可里面却存放了预启动信息、分区表信息。
系统找到BIOS所指定的硬盘的MBR后,就会将其复制到0x7c00地址所在的物理内存中。其实被复制到物理内存的内容就是Boot Loader,而具体到你的电脑,那就是lilo或者grub了。
启动第三步--Boot Loader
Boot Loader 就是在操作系统内核运行之前运行的一段小程序。通过这段小程序,我们可以初始化硬件设备、建立内存空间的映射图,从而将系统的软硬件环境带到一个合适的状态,以便为最终调用操作系统内核做好一切准备。
Boot Loader有若干种,其中Grub、Lilo和spfdisk是常见的Loader。
我们以Grub为例来讲解吧,毕竟用lilo和spfdisk的人并不多。
系统读取内存中的grub配置信息(一般为menu.lst或grub.lst),并依照此配置信息来启动不同的操作系统。
启动第四步--加载内核
根据grub设定的内核映像所在路径,系统读取内存映像,并进行解压缩操作。此时,屏幕一般会输出“Uncompressing Linux”的提示。当解压缩内核完成后,屏幕输出“OK, booting the kernel”。
系统将解压后的内核放置在内存之中,并调用start_kernel()函数来启动一系列的初始化函数并初始化各种设备,完成Linux核心环境的建立。至此,Linux内核已经建立起来了,基于Linux的程序应该可以正常运行了。
启动第五步--用户层init依据inittab文件来设定运行等级
内核被加载后,第一个运行的程序便是/sbin/init,该文件会读取/etc/inittab文件,并依据此文件来进行初始化工作。
其实/etc/inittab文件最主要的作用就是设定Linux的运行等级,其设定形式是“:id:5:initdefault:”,这就表明Linux需要运行在等级5上。Linux的运行等级设定如下:
0:关机
1:单用户模式
2:无网络支持的多用户模式
3:有网络支持的多用户模式
4:保留,未使用
5:有网络支持有X-Window支持的多用户模式
6:重新引导系统,即重启
关于/etc/inittab文件的学问,其实还有很多,在后序文章中设计到的,卖个关子,敬请期待,呵呵
启动第六步--init进程执行rc.sysinit
在设定了运行等级后,Linux系统执行的第一个用户层文件就是/etc/rc.d/rc.sysinit脚本程序,它做的工作非常多,包括设定PATH、设定网络配置(/etc/sysconfig/network)、启动swap分区、设定/proc等等。如果你有兴趣,可以到/etc/rc.d中查看一下rc.sysinit文件,里面的脚本够你看几天的:P
启动第七步--启动内核模块
具体是依据/etc/modules.conf文件或/etc/modules.d目录下的文件来装载内核模块。
启动第八步--执行不同运行级别的脚本程序
根据运行级别的不同,系统会运行rc0.d到rc6.d中的相应的脚本程序,来完成相应的初始化工作和启动相应的服务。
启动第九步--执行/etc/rc.d/rc.local
你如果打开了此文件,里面有一句话,读过之后,你就会对此命令的作用一目了然:
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don’t
# want to do the full Sys V style init stuff.
rc.local就是在一切初始化工作后,Linux留给用户进行个性化的地方。你可以把你想设置和启动的东西放到这里。
启动第十步--执行/bin/login程序,进入登录状态
此时,系统已经进入到了等待用户输入username和password的时候了,你已经可以用自己的帐号登入系统了。:)
转自:http://roclinux.cn/?p=1301
iptables练习题
反色空白处见答案:
1.1)设定INPUT为ACCEPT
1.2)设定OUTPUT为ACCEPT
1.3)设定FORWARD为ACCEPT
答案:
- iptables -P INPUT ACCEPT
- iptables -P OUTPUT ACCEPT
- iptables -P FORWARD ACCEPT
2)定制源地址访问策略
2.1)接收来自192.168.0.3的IP访问
2.2)拒绝来自192.168.0.0/24网段的访问
- iptables -A INPUT -i eth0 -s 192.168.0.3 -j ACCEPT
- iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j DROP
3)目标地址192.168.0.3的访问给予记录,并查看/var/log/message
- iptables -A INPUT -s 192.168.0.3 -j LOG
4)定制端口访问策略
4.1)拒绝任何地址访问本机的111端口
4.2)拒绝192.168.0.0/24网段的1024-65534的源端口访问SSH
- iptables -A INPUT -i eth0 -p tcp –dport 111 -j DROP
- iptables -A INPUT -i eth0 -p tcp -s 192.168.0.0/24 –sport 1024:65534 –dport ssh -j DROP
5)定制CLIENT端的防火墙访问状态
5.1)清除所有已经存在的规则;
5.2)设定预设策略,除了INPUT设为DROP,其他为ACCEPT;
5.3)开放本机的lo可以自由访问;
5.4)设定有相关的封包状态可以进入本机;
- iptables -F
- iptables -X
- iptables -Z
- iptables -P INPUT DROP
- iptables -P OUTPUT ACCEPT
- iptables -P FORWARD ACCEPT
- iptables -A INPUT -i lo -j ACCEPT
- iptables -A INPUT -m state RELATED,ESTABLISHED -j ACCEPT
- iptables -A INPUT -m state INVALID -j DROP
6)定制防火墙的MAC地址访问策略
6.1)清除所有已存的规则
6.2)将INPUT设为DROP
6.3)将目标计算机的MAC设为ACCEPT
- iptables -F
- iptables -X
- iptables -Z
- iptables -P INPUT DROP
- iptables -A INPUT -i eth0 -m MAC –mac-source 00-C0-9F-79-E1-8A -j ACCEPT
7)设定ICMP包,状态为8的被DROP掉
- iptables -A INPUT -i eth0 -p icmp –icmp-type 8 -j DROP
8)定制防火墙的NAT访问策略
8.1)清除所有策略
8.2)重置ip_forward为1
8.3)通过MASQUERADE设定来源于192.168.6.0网段的IP通过192.168.6.217转发出去
8.4)通过iptables观察转发的数据包
- iptables -F
- iptables -X
- iptables -Z
- echo 1 > /proc/sys/net/ipv4/ip_forward
- iptables -t nat -A POSTROUTING -s 192.168.6.0/24 -o eth1 -j MASQUERADE
9)定制防火墙的NAT访问策略
9.1)清除所有NAT策略
9.2)重置ip_forward为1
9.3)通过SNAT设定来源于192.168.6.0网段通过eth1转发出去
9.4)用iptables观察转发的数据包
- iptables -F -t nat
- iptables -X -t nat
- iptables -Z -t nat
- echo 1 > /proc/sys/net/ipv4/ip_forward
- iptables -t nat -A POSTROUTING -o eth1 -j SNAT –to-source 192.168.6.217
- iptables -L -nv
10)端口转发访问策略
10.1)清除所有NAT策略
10.2)重置ip_forward为1
10.3)通过DNAT设定为所有访问192.168.6.217的22端口,都访问到192.168.6.191的22端口
10.4)设定所有到192.168.6.191的22端口的数据包都通过FORWARD转发
10.5)设定回应数据包,即通过NAT的POSTROUTING设定,使通讯正常
- iptables -F -t nat
- iptables -X -t nat
- iptables -Z -t nat
- echo 1 >/proc/sys/net/ipv4/ip_forward
- iptables -t nat -A PREROUTING -d 192.168.6.217 -p tcp –dport 22 -j DNAT –to-destination 192.168.6.191:22
- iptables -A FORWARD -p tcp -d 192.168.6.191 –dport 22 -j ACCEPT
- iptables -t nat -I POSTROUTING -p tcp –dport 22 -j MASQUERADE