80-安全
漏洞类
owasp top 10 2021
- Top1 失效的访问控制(Broken Access Control)
- Top2 加密机制失效(Cryptographic Failures)
- Top3 注入
- Top4 不安全的设计
- Top5 安全配置错误
- Top6 易受攻击和过时的组件
- Top7 认证和授权失败
- Top8 软件和数据完整性故障
- Top9 安全日志记录和监控失败
- Top10 服务器端请求伪造
越权
信息安全行业关于权限有两个常见的概念,一个叫越权,一个叫提权。
- 提权指的是低权限的用户通过技术手段提升到高权限的用户。(权限一般是指计算机权限,提权是指从用户权限提升到管理员权限)。
- 越权一般是指低权限用户进行高权限的操作或平级操作,越权漏洞出现的地方一般以网页、app为主。
越权操作类型:
- 水平越权(横向越权\平行越权)是指相同权限下不同的用户互相影响。
- 垂直越权(纵向越权)是指使用权限低的用户影响到权限较高的用户。
交叉越权是指既可以水平越权又可以垂直越权。基本上只要垂直越权能做,水平越权也能做。
常见越权方法
- 修改 GET 传参来越权。
- 修改 POST 传参进行越权。
- 修改 COOKIE 传参进行越权。
越权防御
- 永远不要相信来自用户的输入,包括请求行,请求头,请求体,对于可控参数进行严格的检查与过滤。
- 前后端同时对用户输入信息进行校验,双重验证机制。
- 前端:对于没有权限的功能和数据不进行展示。
- 后端:执行操作前必须验证用户身份,然后验证用户是否具备操作数据的权限。
- 后端:对于可以表明资源信息的需要进行隐藏。使用加密的资源 ID,防止攻击者枚举ID,敏感数据特殊化处理。
- 后端:对于可以表明用户身份的需要进行隐藏。如可以从用户的加密认证 cookie 中获取当前用户 id,防止攻击者对其修改。或在 session、cookie 中加入不可预测、不可猜解的 user 信息。
SQL 注入
由于程序员的水平及经验参差不齐,大部分程序员在编写代码的时候,没有对用户输入数据的合法性进行判断。
应用程序存在安全隐患。用户可以提交一段数据库查询代码,根据程序返回的结果,获得某些他想得知的数据,这就是所谓的 SQL 注入。
SQL注入,是从正常的 WWW 端口访问,而且表面看起来跟一般的 Web 页面访问没什么区别,如果管理员没查看日志的习惯,可能 被入侵很长时间 都不会发觉。
SQL 注入的分类
- 根据参数类型:字符型,数字型、搜索型
- 根据提交方式:POST 注入,GET 注入,HTTP HEAD 注入
- 根据有无回显:联合注入,报错注入,布尔盲注,延时注入
- 其他注入:堆叠注入,宽字节注入,二次注入等
漏洞危害
SQL注入漏洞对于数据安全的影响:
数据库信息泄漏: 猜解后台数据库,这是利用最多的方式,盗取网站的敏感信息。数据库中存放的用户的隐私信息的泄露。
绕过认证: 如绕过验证登录网站后台。
数据库被恶意操作: 数据库服务器被攻击,数据库的系统管理员帐户被窜改。
网页篡改: 通过操作数据库对特定网页进行篡改。
网站被挂马,传播恶意软件: 修改数据库一些字段的值,嵌入网马链接,进行挂马攻击。
服务器被远程控制,被安装后门: 经由数据库服务器提供的操作系统支持,让黑客得以修改或控制操作系统。
破坏硬盘数据,瘫痪全系统。
如何过滤与预防?
解决 SQL注 入问题的关键是对所有可能来自用户输入的数据进行严格的检查、对数据库配置使用最小权限原则。通常修复使用的方案有:
代码层面:
对输入进行严格的转义和过滤,过滤危险字符。
正则表达式匹配危险字符,列如:union、sleep、load_file 等关键字,如果匹配到,则退出程序。使用参数化(Parameterized):目前有很多 ORM 框架会自动使用参数化解决注入问题,但其也提供了”拼接”的方式,所以使用时需要慎重!
- 如 Python 的 pymysql 库,底层其实只是把参数进行了转化。
1
2
3query = query % self._escape_args(args, conn)
for arg in args:
arg = "'" + arg.replace("'", "''") + "'"
- 如 Python 的 pymysql 库,底层其实只是把参数进行了转化。
使用 MySQL 预处理,又叫预编译 (Java、PHP 防范推荐方法)。防御 SQL注入 的最佳方式就是使用预编译语句,绑定变量,预编译可以提高数据库效率,减少编译次数和连接次数。
没有进行预处理的 SQL,在输入 SQL 语句进行执行的时候,web 服务器自己拼凑 SQL 的时候有可能会把危险的 SQL 语句拼凑进去。但如果进行了 PDO 预处理的 SQL,会让 MySQL 自己进行拼凑,就算夹带了危险的 SQL 语句,也不会进行处理只会当成参数传进去,而不是以拼接进 SQL 语句传进去,从而防止了 SQL 注入。如 Java 的 MyBatis:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23package com.lscl.test;
import org.junit.Test;
import java.sql.*;
public class Demo01 {
@Test
public void test1() throws Exception {
// 获取连接,useServerPrepStmts=true 开启预编译
Connection connection = DriverManager.getConnection("jdbc:mysql://localhost:3306/mybatis?useServerPrepStmts=true", "root", "admin");
String sql = "select * from user where id = ?";
// prepareStatement 预编译方法
PreparedStatement ps = connection.prepareStatement(sql);
ps.setInt(1, 1);
// 执行查询,获取结果集
ResultSet rs = ps.executeQuery();
//遍历查询结果集
while (rs.next()) {
System.out.println(rs.getObject("id")+"---"+rs.getObject("username"));
}
rs.close();
ps.close();
}
}MyBatis 启用了预编译功能,在 SQL 执行前,会先将上面的 SQL 发送给数据库进行编译;等到执行时,直接使用编译好的
SQL,#{id}
直接替换成占位符 “?” 就可以了。因为 SQL 注入只能对编译过程起作用,所以这种“预编译”+“占位符替换”的方式就很好地避免了 SQL 注入的问题。
使用安全函数,在接收用户输入时添加安全函数。
网络层面:
- 通过 WAF 设备启用防 SQL Inject 注入策略(或类似防护系统)
- 云端防护(如阿里云盾)
XSS
- 存储型XSS:存储型XSS,持久化,代码是存储在服务器中的,如在个人信息或发表文章等地方,插入代码,如果没有过滤或过滤不严,那么这些代码将储存到服务器中,用户访问该页面的时候触发代码执行。这种XSS比较危险,容易造成蠕虫,盗窃 Cookie
- 反射型XSS:非持久化,需要欺骗用户自己去点击链接才能触发 XSS 代码(服务器中没有这样的页面和内容),一般容易出现在搜索页面。反射型XSS大多数是用来盗取用户的 Cookie 信息。
- DOM型XSS:不经过后端,DOM-XSS 漏洞是基于文档对象模型(Document Objeet Model,DOM)的一种漏洞,DOM-XSS 是通过 url 传入参数去控制触发的,其实也属于反射型XSS。
利用 XSS 漏洞可以干什么呢?
- 劫持用户会话:通过 XSS 攻击,攻击者可以访问受害者的用户会话,从而获取用户的登录凭据或其他敏感信息。
- 修改网页内容:XSS 攻击可以用来修改网页内容,从而欺骗受害者。
- 破坏网站结构:XSS 攻击可以用来破坏网站结构,从而影响网站的正常运行。
- 获取用户数据:XSS 攻击可以用来获取用户的敏感信息,比如用户的个人信息、财务信息等。
- 执行恶意脚本:XSS 攻击可以用来执行恶意脚本,从而对网站进行攻击或进行其他恶意活动。
- 传播蠕虫:XSS 攻击可以用来传播蠕虫,从而在受害者网络中传播恶意程序。
- 劫持浏览器:XSS 攻击可以用来劫持浏览器,从而控制用户的浏览习惯。
- 弹出恶意广告:XSS 攻击可以用来弹出恶意广告,从而影响用户的正常使用。
- 注入恶意代码:XSS 攻击可以用来注入恶意代码,从而影响网站的正常运行。
- 操纵搜索结果:XSS 攻击可以用来操纵搜索结果,从而让受害者访问攻击者想要让他们访问的网站。
- 传播木马程序:XSS 攻击可以用来传播木马程序,从而攻击网站或窃取用户信息。
- 劫持网站:XSS 攻击可以用来劫持网站,从而控制网站的内容和功能。
XSS的防御
XSS防御的总体思路是:对用户的输入(和URL参数)进行过滤,对输出进行html编码。也就是对用户提交的所有内容进行过滤,对url中的参数进行过滤,过滤掉会导致脚本执行的相关内容;然后对动态输出到页面的内容进行html编码,使脚本无法在浏览器中执行
内容过滤。对输入的内容进行过滤,可以分为黑名单过滤和白名单过滤。
- 黑名单过滤虽然可以拦截大部分的XSS攻击,但是还是存在被绕过的风险。
- 白名单过滤虽然可以基本杜绝XSS攻击,但是真实环境中一般是不能进行如此严格的白名单过滤的。
对输出进行html编码,就是通过函数,将用户的输入的数据进行html编码,使其不能作为脚本运行。
如下,是使用 php 中的 htmlspecialchars 函数对用户输入的 name 参数进行 html 编码,将其转换为 html 实体
1
2#使用htmlspecialchars函数对用户输入的name参数进行html编码,将其转换为html实体
$name = htmlspecialchars( $_GET[ 'name' ] );如下,图一是没有进行html编码的,图2是进行了html编码的。经过html编码后script标签被当成了html实体。
设置 HTTP Only 属性。我们还可以服务端设置会话 Cookie 的 HTTP Only 属性,这样,客户端的 JS 脚本就不能获取 Cookie 信息了
明确输入内容。对用户输入的内容进行类型明确,比如个人信息电话或者邮箱地址等位置都过滤一些不符合的内容。
输入内容长度控制。对于不可信的内容都应该进行长度控制,比如控制电话号码的输入长度,这种防御主要是增加XSS攻击的难度。
客户端分层防御策略。客户端跨站脚本攻击的分层防御策略是基于独立分配线程和分层防御策略的安全模型,它建立在客户端(浏览器),这是它与其它模型最大的区别,客户端在接受服务器信息时,选择性执行相关的内容,这样就使防御 XSS 攻击变得更容易。
CSRF(Cross-site request forgery,跨站请求伪造)
下图简单阐述了 CSRF 攻击的思想:
从上图可以看出,要完成一次 CSRF 攻击,受害者必须依次完成两个步骤:
- 登录受信任网站 A,并在本地生成 Cookie。
- 在不登出 A 的情况下,访问危险网站 B。
看到这里,你也许会说:“如果我不满足以上两个条件中的一个,我就不会受到 CSRF 的攻击”。是的,确实如此,但你不能保证以下情况不会发生:
- 你不能保证你登录了一个网站后,不再打开一个 tab 页面并访问另外的网站。
- 你不能保证你关闭浏览器了后,你本地的 Cookie 立刻过期,你上次的会话已经结束。(事实上,关闭浏览器不能结束一个会话,但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了……)
- 上图中所谓的攻击网站,可能是一个存在其他漏洞的可信任的经常被人访问的网站。
CSRF 的防御
CSRF 的防御可以从服务端和客户端两方面着手,防御效果是从服务端着手效果比较好,现在一般的 CSRF 防御也都在服务端进行。
1.验证 HTTP Referer 字段
根据 HTTP 协议,在 HTTP 头中有一个字段叫 Referer,它记录了该 HTTP 请求的来源地址。在通常情况下,访问一个安全受限页面的请求来自于同一个网站,比如需要访问 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory
,用户必须先登陆 bank.example
,然后通过点击页面上的按钮来触发转账事件。这时,该转帐请求的 Referer 值就会是转账按钮所在的页面的 URL,通常是以 bank.example 域名开头的地址。
而如果黑客要对银行网站实施 CSRF 攻击,他只能在他自己的网站构造请求,当用户通过黑客的网站发送请求到银行时,该请求的 Referer 是指向黑客自己的网站。因此,要防御 CSRF 攻击,银行网站只需要对于每一个转账请求验证其 Referer 值,如果是以 bank.example 开头的域名,则说明该请求是来自银行网站自己的请求,是合法的。如果 Referer 是其他网站的话,则有可能是黑客的 CSRF 攻击,拒绝该请求。
这种方法的显而易见的好处就是简单易行,网站的普通开发人员不需要操心 CSRF 的漏洞,只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。特别是对于当前现有的系统,不需要改变当前系统的任何已有代码和逻辑,没有风险,非常便捷。
然而,这种方法并非万无一失。Referer 的值是由浏览器提供的,虽然 HTTP 协议上有明确的要求,但是每个浏览器对于 Referer 的具体实现可能有差别,并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法,就是把安全性都依赖于第三方(即浏览器)来保障,从理论上来讲,这样并不安全。
事实上,对于某些浏览器,比如 IE6 或 FF2,目前已经有一些方法可以篡改 Referer 值。如果 bank.example 网站支持 IE6 浏览器,黑客完全可以把用户浏览器的 Referer 值设为以 bank.example
域名开头的地址,这样就可以通过验证,从而进行 CSRF 攻击。
即便是使用最新的浏览器,黑客无法篡改 Referer 值,这种方法仍然有问题。因为 Referer 值会记录下用户的访问来源,有些用户认为这样会侵犯到他们自己的隐私权,特别是有些组织担心 Referer 值会把组织内网中的某些信息泄露到外网中。因此,用户自己可以设置浏览器使其在发送请求时不再提供 Referer。当他们正常访问银行网站时,网站会因为请求没有 Referer 值而认为是 CSRF 攻击,拒绝合法用户的访问。
2.使用 Token
CSRF 攻击之所以能够成功,是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个 CSRF 攻击者无法获取到的 Token。服务器通过校验请求是否携带正确的 Token,来把正常的请求和攻击请求区分开。跟验证码类似,只是用户无感知
步骤:
- 服务端给用户生成一个 Token, 加密后传递给用户。
- 用户在提交请求时, 需要携带这个 Token。
- 服务端验证 Token 是否正确。
1 在 HTTP 头中自定义属性并验证
这种方法把 token 放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类,可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性,并把 token 值放入其中。通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏,也不用担心 token 会透过 Referer 泄露到其他网站中去。
然而这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新,并非所有的请求都适合用这个类来发起,而且通过该类请求得到的页面不能被浏览器所记录下,从而进行前进,后退,刷新,收藏等操作,给用户带来不便。另外,对于没有进行 CSRF 防护的遗留系统来说,要采用这种方法来进行防护,要把所有请求都改为 XMLHttpRequest 请求,这样几乎是要重写整个网站,这代价无疑是不能接受的。
2.Cookie Hashing(所有表单都包含同一个伪随机值)
这可能是最简单的解决方案了,因为攻击者不能获得第三方的 Cookie(理论上),所以表单中的数据也就构造失败了。
1 |
|
在表单里增加 Hash 值,以认证这确实是用户发送的请求。
1 |
|
然后在服务器端进行 Hash 值验证
1 |
|
这个方法个人觉得已经可以杜绝 99% 的 CSRF 攻击了,那还有 1% 呢….由于用户的 Cookie 很容易由于网站的 XSS 漏洞而被盗取,这就另外的1%。一般的攻击者看到有需要算 Hash 值,基本都会放弃了,某些除外,所以如果需要 100% 的杜绝,这个不是最好的方法。
3.验证码
这个方案的思路是:每次的用户提交都需要用户在表单中填写一个图片上的随机字符串,厄….这个方案可以完全解决 CSRF,但在易用性方面似乎不是太好,还有听闻是验证码图片的使用涉及了一个被称为 MHTML 的 Bug,可能在某些版本的微软IE中受影响。
验证码能够防御 CSRF 攻击,但是我们不可能每一次交互都需要验证码,否则用户的体验会非常差,但是我们可以在转账,交易等操作时,增加验证码,确保我们的账户安全。
4.One-Time Tokens(不同的表单包含一个不同的伪随机值)
在实现 One-Time Tokens 时,需要注意一点:就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单,CSRF 保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况:用户只能成功地提交他最后打开的表单,因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保 CSRF 保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。
3.Samesite Cookie 属性
为了从源头上解决这个问题,Google 起草了一份草案来改进 HTTP 协议,为 Set-Cookie 响应头新增 Samesite 属性,它用来表明这个 Cookie 是个 “同站 Cookie”,同站 Cookie 只能作为第一方 Cookie,不能作为第三方 Cookie,Samesite 有两个属性值,分别是 Strict 和 Lax。
部署简单,并能有效防御 CSRF 攻击,但是存在兼容性问题
Samesite=Strict
被成为是严格模式,表明这个 Cookie 在任何情况都不可能作为第三方的 Cookie, 有能力阻止所有 CSRF 攻击。此时,我们在 B 站点下发起对 A 站点的任何请求,A站点的 Cookie 都不会包含在 cookie请求头中。
将 cookie 设置为 HTTP Only
CRSF 攻击很大程度上是利用了浏览器的 cookie,为了防止站内的 XSS 漏洞盗取 cookie,需要在 cookie 中设置“HTTP Only”属性,这样通过程序(如JavaScript脚本、Applet等)就无法读取到 cookie 信息,避免了攻击者伪造 cookie 的情况出现。
特殊情况
- 网站本身存在 XSS 时,验证码可完全杜绝 CSRF
- 钓鱼网站, CSRF_TOKEN 存在 cookie 中, 并把 HttpOnly 设置为 TRUE 可以杜绝
CSRF 攻击和 XSS 攻击有什么区别?
CSRF 攻击不需要将恶意代码注入用户的页面,仅仅是利用服务器的漏洞和用户的登录状态来实施攻击。
CSRF 攻击成本也比 XSS 低,用户每天都要访问大量网页,无法确认每一个网页的合法性,
什么叫 DDOS 攻击?什么叫 CC 攻击?
DOS 攻击,即通过大量合法的请求占用大量网络资源,以达到瘫痪网络的目的。
DDOS 攻击,中文名叫分布式拒绝服务攻击,指借助服务器技术将多个计算机联合起来作为攻击平台,来对一个或多个目标发动 DDOS 攻击。
CC 攻击,主要是用来攻击页面的,模拟多个用户不停的对你的页面进行访问,从而使你的系统资源消耗殆尽。
怎么预防 CC 攻击和 DDOS 攻击?
防 CC、DDOS 攻击,这些只能是用硬件防火墙做流量清洗,将攻击流量引入黑洞。流量清洗这一块,主要是买 ISP 服务商的防攻击的服务就可以,机房一般有空余流量,我们一般是买服务,毕竟攻击不会是持续长时间。
鱼叉式攻击和水坑攻击
- 鱼叉攻击是指黑客通过伪装成一个可信来源的方式来欺骗特定目标,以获取敏感信息或者进行其他恶意活动的攻击方式。这种攻击通常是通过电子邮件或社交媒体等通信方式实施的,黑客会针对某个特定的人或组织,通过伪造信任的方式来引导受害者点击链接或者下载附件等,从而让受害者泄露出机密信息或者安装恶意软件。
- 水坑攻击是指黑客通过攻击受害者经常访问的网站,以获取敏感信息或者进行其他恶意活动的攻击方式。这种攻击通常是通过对目标网站进行攻击,使得访问该网站的用户受到感染或者被重定向到恶意网站,从而让黑客获得用户的敏感信息或者控制用户的计算机。
简讲:鱼叉式攻击是一种针对个人或组织的攻击,而水坑攻击则是一种针对广泛用户的攻击。
中间人攻击
指攻击者在通信过程中窃取双方通信的数据,并尝试篡改或者重放数据的一种攻击方式。攻击者通常会在用户和服务器之间插入一个恶意的中间节点,这个节点会伪装成正常的通信节点,使得双方都认为他们在与对方直接通信。
虚拟机逃逸
指攻击者利用虚拟化软件或操作系统中的漏洞,从虚拟机(VM)环境中获得对物理主机的控制权。攻击者可以通过虚拟机逃逸攻击,绕过安全措施,获取对整个物理主机的访问权限,并访问所有存储在其中的敏感数据。
运营商(或其他)网络劫持
- 当网络劫持发生时,请求被运营商(或其他劫持者)拦截,由他们发送响应。劫持者可能会插入恶意内容,植入广告,并通过注入脚本对内容进行修改。劫持者可能会拦截特定的内容以及用户的HTTP请求,从而控制用户的浏览体验。
- 网络劫持可能会导致安全和隐私问题,因为劫持者可以收集用户的敏感信息,例如用户凭据和登录信息。它还可能导致网络流量减少,并且由于广告和注入的脚本,网页可能会变得非常缓慢。
- 要避免网络劫持,可以使用SSL/TLS协议保护通信,在发送敏感数据之前进行网站验证,并使用一款受信任的VPN来加密通信。此外,还应该定期更新设备的操作系统和浏览器,并只从可信的源下载软件或应用程序。
- 要继续防止网络劫持,应该禁用网络中的一些危险的功能,例如域名服务器(DNS)的动态更新,DNS重定向,以及远程访问功能。另外,还应设置安全软件来帮助检测潜在的网络劫持活动。最后,运营商可以设置灰度测试策略来帮助发现违规活动。
DNS欺骗是什么
DNS欺骗是一种网络攻击技术,可以改变Internet上查找Web服务器和其他Internet资源的本地DNS(域名系统)表。攻击者通过更改服务器上的DNS记录,可以将Internet流量重定向到攻击者控制的服务器,用于盗取数据,植入恶意软件,或重新定义未经授权的网络配置。
缓冲区溢出原理和防御
缓冲区溢出是一种软件漏洞,在这种漏洞中,攻击者可以利用保存数据的内存单元越界访问其他内存空间,访问此类内存导致系统崩溃或可执行恶意代码。
要防止缓冲区溢出攻击,可以采用多种措施,包括使用堆栈保护机制(如堆栈溢出保护、边界检查缓冲区),使用隔离内存技术(ASLR),以及使用深度检查技术(如恶意代码检查、反编译检查)。另外,还可以使用动态分析技术(如在线分析),以及代码审计技术来防御缓冲区溢出。
防重放攻击
加密算法类
- 哈希算法是一种用数学方法对数据生成一个固定长度的唯一标识的技术,可以用来验证数据的完整性和一致性,常见的哈希算法有
- MD 类:MD5 哈希值长度为 128
- SHA 类:SHA-1 哈希值长度为 160 、SHA-2 家族(如 SHA-256、SHA-384、SHA-512 等)、SHA-3
- MAC
- SM3
- 对称加密算法是一种加密和解密使用同一个密钥的算法,可以用来保护数据的安全性和保密性,常见的对称加密算法有:
- DES、3DES
- AES
- SM4
- 非对称加密算法是一种加密和解密使用不同的密钥的算法,可以用来实现数据的安全传输和身份认证,常见的非对称加密算法有
- RSA
- DSA
- ECC
- SM2
信息安全
CIA
在信息安全等级保护工作中,根据信息系统的机密性(Confidentiality)、完整性(Integrity)、可用性(Availability)来划分信息系统的安全等级,三个性质简称 CIA
网络安全事件应急响应
网络安全事件应急响应是指在发生网络安全事件时,企业应组织有关部门统一协调,根据网络安全应急响应计划或网络安全事件预案的要求,及时采取相应的应对措施。
它包括:
- 应急预案设计:进行安全事件预测和分析,制定网络安全应急响应计划和网络安全事件处置预案,以应对网络安全事件。
- 故障消除:组织资源进行安全故障分析,查明故障原因并消除故障源。
- 事件处理:对网络安全事件进行识别,分析和处理,以及健全后续处理流程。
- 控制措施落实:制定、落实有效的管理措施,防止网络安全事件的再次发生。
- 风险预警:建立网络安全风险预警系统,严格完善网络安全管理,从而及时防范网络安全事件。
- 数据处置:收集、处理和存储处置期间涉及的所有数据,避免安全事件再次发生。
- 应急测试:分析处理后的网络安全状态,实施应急测试,确保安全恢复后的网络安全可用性。
- 应急评估:对安全事件处置作出总结,评估应急处置效果,并采取有效的改进措施,减少安全事件的发生几率。
- 安全意识培训:对员工进行网络安全意识培训,增强员工的网络安全意识,使其熟悉网络安全技术、安全风险评估技术及网络安全威胁信息处理技术,预防网络安全事件发生。
- 复查审计:定期复查审计网络安全事件及应急响应活动,以及建立长期的安全应急响应机制。
企业内部安全
企业内部安全管理是指企业内部管理机构对企业内部安全状况的管理,包括安全管理制度、安全管理措施、安全管理机构和安全管理人员等。
- 制定安全管理制度:企业应制定安全管理制度,明确安全管理的职责、权限和程序,确保安全管理的有效实施。
- 实施安全管理措施:企业应根据安全管理制度,采取有效的安全管理措施,确保企业内部安全状况的稳定。
- 建立安全管理机构:企业应建立安全管理机构,负责安全管理工作,确保安全管理的有效实施。
- 培训安全管理人员:企业应定期对安全管理人员进行培训,使其具备安全管理的知识和技能,确保安全管理的有效实施。
- 定期检查安全状况:企业应定期检查企业内部安全状况,及时发现安全隐患,采取有效措施,确保企业内部安全状况的稳定。
- 及时处理安全事故:企业应及时处理安全事故,分析事故原因,采取有效措施,防止安全事故的发生。
- 定期评估安全管理:企业应定期评估安全管理的效果,及时发现安全管理中存在的问题,采取有效措施,确保安全管理的有效实施。
- 定期更新安全管理制度:企业应定期更新安全管理制度,使其与企业实际情况相适应,确保安全管理的有效实施。
- 定期开展安全宣传:企业应定期开展安全宣传,使员工充分了解安全管理的重要性,确保安全管理的有效实施。
- 建立安全档案:企业应建立安全档案,记录安全管理的相关信息,便于安全管理的有效实施。
场景类
一台 Linux 系统初始化环境后需要做一些什么安全工作
- 添加普通用户登陆,禁止 root 用户登陆,更改 SSH 端口号。修改 SSH 端口不一定绝对哈。当然,如果要暴露在外网,建议改下。
- 服务器使用密钥登陆,禁止密码登陆。
- 开启防火墙,关闭 SElinux ,根据业务需求设置相应的防火墙规则。
- 装 fail2ban 这种防止 SSH 暴力破击的软件。
- 设置只允许公司办公网出口 IP 能登陆服务器(看公司实际需要),也可以安装 VPN 等软件,只允许连接 VPN 到服务器上。
- 修改历史命令记录的条数为 10 条。
- 只允许有需要的服务器可以访问外网,其它全部禁止。
- 做好软件层面的防护。
- 设置 nginx_waf 模块防止 SQL 注入。
- 把 Web 服务使用 www 用户启动,更改网站目录的所有者和所属组为 www 。
什么是企业的安全运营,安全运营的概念
安全运营被定义为:以资产为核心、以安全事件管理为关键流程,采用安全域的划分思想,建立一套实时的资产风险模型,协助管理员进行事件分析、风险分析、预警管理和应急响应处理的集中安全管理系统;
安全运营以用户网络的最终安全为目的,实现运营过程上的统筹管理;
安全风险不仅仅指的是目前的互联网技术、计算机科学技术,而是将企业整个体系的安全囊括在安全运营建设上,包括:合规安全(监管机构、行业规范)、运营风险管理(在实际运营中的风所有险,例如金融行业的风险控制部门,涉及到业务、产品等);
安全运营本质上就是一个:以技术、流程和人有机结合的复杂系统过程,包含:
产品、服务、运维、研发等,已有安全工具、安全服务产出的数据进行有效分析,持续输出价值,解决安全风险
其模式:用“服务模式”开展合作,以“安全能力”进行赋能,以“安全数据”提供决策,以“运营能力”作为交付,以运营模式来发现问题、验证问题、分析问题、响应处理、解决问题并持续优化;