前期调研
nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器，一般主要功能会有两种，一种作为一个HTTP服务器进行网站的发布处理，另外一种nginx可以作为反向代理进行负载均衡的实现。所以这里填主要功能的时候就要分清。
查看Nginx版本：
如果系统有配置nginx命令的环境变量，直接 nginx -v 即可查看版本信息
若无，我们去nginx主目录下运行cmd，输入nginx -v查看版本
一、身份鉴别
由于该中间件并没有类似于Tomcat一样的管理控制台，所以个人认为以下条款均判不适用。
a）应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换
无独立的登录管理界面，通过登录到操作系统本地管理该中间件，身份鉴别由操作系统层面实现。
b）应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施
无独立的登录管理界面，通过登录到操作系统本地管理该中间件，身份鉴别由操作系统层面实现。
c）当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听
无独立的登录管理界面，通过登录到操作系统本地管理该中间件，身份鉴别由操作系统层面实现。
d）应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现
无独立的登录管理界面，通过登录到操作系统本地管理该中间件，身份鉴别由操作系统层面实现。
二、访问控制
同理判不适用。
a） 应对登录的用户分配账户和权限
无独立的登录管理界面，通过登录到操作系统本地管理该中间件，访问控制由操作系统层面实现。
b）应重命名或删除默认账户，修改默认账户的默认口令
无独立的登录管理界面，通过登录到操作系统本地管理该中间件，访问控制由操作系统层面实现。
c）应及时删除或停用多余的、过期的账户，避免共享账户的存在
无独立的登录管理界面，通过登录到操作系统本地管理该中间件，访问控制由操作系统层面实现。
d）应授予管理用户所需的最小权限，实现管理用户的权限分离
无独立的登录管理界面，通过登录到操作系统本地管理该中间件，访问控制由操作系统层面实现。
e）应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则
无独立的登录管理界面，通过登录到操作系统本地管理该中间件，访问控制由操作系统层面实现。
f）访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级
无独立的登录管理界面，通过登录到操作系统本地管理该中间件，访问控制由操作系统层面实现。
g）应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问
无独立的登录管理界面，通过登录到操作系统本地管理该中间件，访问控制由操作系统层面实现。
三、安全审计
a）应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计
针对于各类的中间件来说，日志一般会分为两种，一种是 error.log 错误日志，另一种是 access.log 网页访问日志。都开启的情况下，我们就可以判符合（前提日志级别配置正确）。
先来看一下 errlog_log：
error_log：设置服务器运行的相关日志
设置格式
error_log 路径 级别
默认值：error_log logs/error.log error；
配置段：main，http，server，location
关闭error_log：error_log off
日志的级别：
debug:调试级别，记录的信息最多；
info:普通级别；
notice:可能需要注意的信息；
warn:警告消息；
error:错误消息；
crit:严重错误消息；
access_log：
访问日志主要记录客户端访问Nginx的每一个请求，格式可以自定义。通过访问日志，你可以得到用户地域来源、跳转来源、使用终端、某个URL访问量等相关信息。
access_log:用来配置访问日志的输出格式和输出的路径；
语法: access_log path [format [buffer=size [flush=time]]];
默认值: access_log logs/access.log combined;
后续版本好像有变更，默认为 main;
配置段: http, server, location, if in location, limit_except
关闭access_log：access_log off
path：指定日志的存放位置
format：指定日志的格式。默认使用预定义的combined
buffer：用来指定日志写入时的缓存大小。默认是64k
gzip：日志写入前先进行压缩。压缩率可指定，从1到9数值越大压缩比越高，同时压缩的速度也越慢。默认是1。
flush：设置缓存的有效时间。如果超过flush指定的时间，缓存中的内容将被清空。
if：条件判断。如果指定的条件计算为0或空字符，那么当前作用域下的所有的请求日志都会被关闭。
所以我们这里先在 Nginx 主目录下找到conf文件夹
其中会有一个叫 nginx.conf 的文件
查看对应error_log和access_log配置情况，默认情况下都是为注释状态
若为注释状态，nginx 会有一个默认值，如下：
error_log logs/error.log error；
access_log logs/access.log main;
b）审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息
日志文件在nginx主目录下的log目录中
默认情况下都是满足条款要求的，比如查看一下 access.log 日志
另外考虑的点就是日志记录的时间是否准确，中间件时间一般跟随操作系统时钟，如果操作系统时间正确，那么基本也不会有问题。
或者我们可以去配置文件中，配置我们自己想要的日志记录内容。
对应参数：log_format
log_format：用来设置日志格式
nginx的log_format有很多可选的参数用于标示服务器的活动状态，默认为：
‘$remote_addr – $remote_user [$time_local] “$request” ‘ ‘$status $body_bytes_sent “$http_referer” ‘ ‘”$http_user_agent” “$http_x_forwarded_for”‘;
如果要记录更详细的信息需要自己修改log_format，具体可设置的参数格式及说明如下：
这条日志是之前实验访问应用留下的，我们可以分析一下。
192.168.21.176 - - [28/Sep/2020:14:34:48 +0800] "GET /favicon.ico HTTP/1.1" 404 555 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
|
参数 |
说明 |
示例 |
|
$remote_addr |
客户端地址 |
192.168.21.176 |
|
$remote_user |
客户端用户名称 |
-- |
|
$time_local |
访问时间和时间 |
[28/Sep/2020:14:34:48 +0800] |
|
$request |
请求的URI和HTTP协议 |
"GET /favicon.ico HTTP/1.1" |
|
$http_host |
请求地址，即浏览器中你输入的地址（域名或IP） |
192.168.0.23 |
|
$status |
HTTP请求状态 |
404 |
|
$upstream_status |
upstream状态 |
|
|
$body_bytes_sent |
服务器发送客户端的相应body字节数 |
555 |
|
$http_referer |
url跳转来源 |
- https://www.google.com/ |
|
$http_user_agent |
用户终端浏览器等信息 |
"Mozilla/5.0 (Windows NT……" |
|
$http_x_forwarded_for |
当前端有代理服务器时，设置web节点记录客户端地址的配置，此参数生效的前提是代理服务器也要进行相关的x_forwarded_for设置 |
|
|
$ssl_protocol |
SSL协议版本 |
TLSv1 |
|
$ssl_cipher |
交换数据中的算法 |
Rc4-SHA |
|
$upstream_addr |
后台upstream的地址，即真正提供服务的主机地址 |
10.36.10.80:80 |
|
$request_time |
整个请求的总时间 |
0.165 |
|
$upstream_response_time |
请求过程中，upstream响应时间 |
0.002 |
所以如果想要记录更详细，可以自己进行配置。
c）应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等
1. 确认本机的日志文件权限
确认是否仅管理员组具有日志的管理权限，其他组没有修改权限
如users组无权管理修改
Linux系统下同理，对应的日志文件不高于644
2. 是否对日志文件进行定期备份
这个好像默认自带的方式没有找到，那么就去询问一下运维人员，是否有备份措施对中间件日志进行备份。
一般有的现场看到好像是通过FTP同步，会将日志文件同步一份到备份服务器上。
3. 日志留存时间
查看日志留存时间是否达到6个月以上，满足法律法规要求。
d）应对审计进程进行保护，防止未经授权的中断
审计进程与中间件主进程关联，无法单独中断审计进程，只要开启即符合。
四、入侵防范
a）应遵循最小安装的原则，仅安装需要的组件和应用程序
该测评点在操作系统层面核查，中间件不适用该条款。
b）应关闭不需要的系统服务、默认共享和高危端口
该测评点在操作系统层面核查，中间件不适用该条款。
c）应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制
通过登录到服务器本地对Nginx 软件进行管理，该项不适用。
d）应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求
该中间件无独立的管理控制台，无对应的人机或通信接口输入功能，该项不适用。
e）应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞
1.通过漏洞扫描、渗透测试等方式核查中间件系统是否存在高风险漏洞；
2.核查是否及时修补漏洞。
询问客户，查看漏洞扫描报告，如果无漏洞可判符合
不存在高危漏洞，判部分符合
f）应能够检测到对重要节点进行入侵的行为，并在发生严重入侵事件时提供报警
该测评点在操作系统层面核查，中间件不适用该条款。
五、可信验证
a）可基于可信根对计算设备的系统引导程序、系统程序、重要配置参数和应用程序等进行可信验证，并在应用程序的关键执行环节进行动态可信验证，在检测到其可信性受到破坏后进行报警，并将验证结果形成审计记录送至安全管理中心
该测评点在设备层面核查，中间件不适用该条款。
六、数据完整性
数据完整性对于中间件来说，一般涉及鉴别数据、重要审计数据、重要配置数据这三类
a）应采用校验技术或密码技术保证重要数据在传输过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等
1. 鉴别数据、重要配置数据
无独立的登录管理界面，通过登录到操作系统本地管理该中间件，故鉴别数据、重要配置数据等无单独传输过程。
2. 审计数据
确认审计数据是否有传输，如果审计数据有备份的话就需要考虑这点。
b）应采用校验技术或密码技术保证重要数据在存储过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等
无独立的登录管理界面，通过登录到操作系统本地管理该中间件，未涉及鉴别数据的存储。
重要配置数据、重要审计数据需要询问管理人员，是否有对配置文件，日志文件等做定期的哈希完整性校验等。
七、数据保密性
数据保密性来说对于中间件这里仅涉及鉴别数据，Nginx 不涉及鉴别数据，所以均不适用。
a）应采用密码技术保证重要数据在传输过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等
无独立的登录管理界面，通过登录到操作系统本地管理该中间件，故鉴别数据无单独传输过程。
b）应采用密码技术保证重要数据在存储过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等
无独立的登录管理界面，通过登录到操作系统本地管理该中间件，未涉及鉴别数据的存储。