请求：/wytz

命令注入是一种安全漏洞，发生在未对用户输入做出限制而直接拼接用户输入，攻击者可以利用命令注入漏洞执行任意命令，使用特殊符号（&、&&、|和||）绕过预期命令并执行其他命令

二、命令注入实践（DVWA）

1、级别Low

查看源码,发现这段代码在ping语句后面未做任何监测

使用命令ping 127.0.0.1 & whoami测试，在执行ping127.0.0.1的同时执行后面拼接的命令

2、级别Medium

查看源码，发现这么段代码对输入做了简单的防护，把&&和;转换成空格，使命令失效，但并未对||和|做防护，所有可以使用||或|

使用命令127.0.0.1 | whoami测试，直接执行whoami

3、级别High

查看源码，增加被限制的特殊符号，但在|处多了一个空格

使用命令127.0.0.1 |whoami测试，仍然能执行whoami（注意空格）

4、级别Impossible

查看源码，这段代码拆分了用户输入的IP地址，并分别判断每位是否是数字且是否有其他参数，然后再组合成IP地址执行相关操作，规避注入的风险。

mount -o remount,rw /sysroot
chroot /sysroot
passwd root
touch .autorelabel
exit
exit
exit

交流群：

1}PFC（部分路由计算）

2类LSA携带拓扑结构，只要2类LSA不改变，之计算计算（广播网络类型中）；在p2p网络中，通过1类LSA描述拓扑信息，1类LSA（网络类型）

2}智能定时器

LSA更新、接收定时器；呈指数的增加；网络出现频繁的up，则每次更新间隔，不断增加

华为：缺省情况下，是用智能定时器Intelligent-timer，更新LSA 的最长间隔时间是max-interval为5000毫秒，初始间隔时间start-interval为500毫秒，基数间隔时间hold-interval为1000毫秒（以毫秒为的那位的时间间隔）

3}IP FRR快速重路由

提前计算备用路径；有条件的计算备用路径

临时链路，过渡性链路

基于思路：以可提供本分链路的邻居为过根节点，利用SPF算法计算出到目的节点的最短距离。然后，按照不等式计算出开销最小且无环的备份链路

4}BFD

OSPF邻居，若直接链路之间有交换机设备，发生非直连故障。需等待邻居超时时间

工作流程

1.OSPF邻居建立

2.BFD会话根据邻居物理地址自动建立

3.BFD发现故障，通知OSPF故障

BFD联动实验

IP FRR实验

按照图示更改接口cost，ospf全宣告即可

开启frr

R1未开启后关于4.4.4.4路由frr的状态

R1开启frr后关于4.4.4.4路由的状态

2.OSPF路由控制

1.等价路由

当路由表中存在到达同一目的地址，且同一路由协议发现的多条路由时，若开销值也相同，那么这些路由就是等价的，可以实现负载分担

华为下设置负载分担的等价路由的命令以及最大条数

2.缺省路由

情况1

有区域边界路由器发布3类LSA，用来指导区域内路由器进行区域之间报文的转发

情况2

由自治系统边界路由器发布5/7leiLSA，用来指导OSPF路由器域内路由器进行域外报文的转发

3.对发送的LSA进行过滤

对OSPF接口出方向的LSA进行过滤

对ABR3类LSA继续过滤

配置对区域内出/入方向的3类LSA进行过滤

OSPF Dadabase Overflew

限制OSPF数据库中的五类LSA最大数目

3.其他特性

1.OSPF多进程

主要应用于VPN场景中

2.OSPF与BGP联动

问题：新设备加入网络或有设备重启，可能会出现在BGP收敛期间内网络流量丢失的现象。这就是IGP收敛比BGP块造成的

解决：使能OSPF与BGP联动特性的设备的会在设定的联动时间内保持为Stub路由器，该设备发布的LSA中的链路度量值为最大值（65535），从而告知其他OSPF设备不要使用这个路由器来转发数据；在特性设备上使能联动，在BGP收敛完成之前，不会有流量转发到该设备上，而是使用备份设备来转发直到该设备上的BGP路由收敛完成

3.OSPF转发地址FA

是属于5/7类LSA中包含的一个特别的字段LSA。是对到达所通告的目的地址数据包应该被转发到的地址，如果为0.0.0.0，那么数据包将被转发到始发ASBR上；FAde引入使得OSPF某些场景下可以避免次优路径问题

FA的取值

5类LSA中FA字段为0，那么数据包将被转发到始发ASBR上；若不为0则表示数据包应该发往这个FA所标识的设备

非0的条件

1.ASBR在其连接外部网络的接口激活OSPF

2.该接口没有被设置为静默接口

3.该接口的OSPF网络类型为广播或NBMA帧中继

4.该接口的IP地址在OSPF配置的network命令指定的网段范围内

5.到达FA地址的路由必须是OSPF区域内部路由或区域间路由，这样接收到该外部LSA的路由器才能够加载到LSA进入路由表，加载的外部LSA生成的路由条目下一跳与到达FA地址的下一跳相同

4.GR（平滑重启）

OSPF通过新增Grace-LSA来支持GR功能，这种LSA用于在开始FR退出GR时向邻居通告GR的时间、原因以及接口地址等内容

TLV类型

Grace Period TLV：Type=1，长度为4字节，表示邻居设备进入GR Helper处理流程的最长保持时间。如果超过这段时间GR Restarter还没有完成GR处理流程，则周边邻居不再担任GR

Graceful Restart Reason TLV：Type=2，长度为1字节，
告知邻居设备GR Restarter的重启原因。（必须携带）
 Value=0，表示原因未知；
 Value=1，表示软件重启；
 Value=2，表示软件重新加载（升级）；
 Value=3，表示GR Restarter进行主备倒换。

IP Interface Address TLV：Type=3，长度为4字节，用来告知发送Grace LSA的接口的IP地址，在网络上需要用该IP地址来唯一标识一台重启设备

GR中的概念

GR Restarter：GR重启路由器，指由管理员或故障触发而协议重启的设备，它需要具备GR能力。可以通过配置支持完全GR或者部分GR。
• GR Helper：协助重启路由器，即GR Restarter的邻居，能协助重启的GR Restarter保持路由关系的稳定，它也需要具备GR能力。可以通过配置支持有计划GR、非计划GR或者通过策略有选择支持GR。
• GR Session：GR会话，是GR Restarter和GR Helper之间的能力协商过程，包括协议重启通告，协议重启过程中的信息交互等。通过该会话，GR Restarter和GR Helper可以掌握彼此的GR能力。
• GR的持续时间：GR持续时间最长不超过1800秒。GR成功或失败都可以提前退出，不必等到超时才退出

GR的过程

GR的退出

• Helper发送的Router-LSA或Network-LSA导致
Restarter端进行双向检查时失败。
• Restarter接口状态变化。
• Restarter收到同一网段上另一台路由器产生的
Grace-LSA。同一网段同一时间只能有一台路由器
做GR。
• Restarter同一个网段的邻居之间存在DR/BDR不一
致的情况（即拓扑变化） | • 在邻居关系超时前没有收到Restarter发送的GraceLSA。
• Helper接口状态发生变化。
• 收到其它路由器发送的与Helper本地数据库不一致
的LSA。（可以通过配置不进行严格LSA检查排除这
种情况。）
• 同一网段上同一时间收到两台路由器发送的GraceLSA。
• 与其它路由器邻居关系变化 |

配置OSPF GR

1.使能opaque-LSA特性

2.Restarter端使能OSPF GR特性,并配置相应参数

period period：指定平滑重启的周期。整数形式，取值范围是1～1800，单位是秒。缺省值是120秒。
planned-only：指定路由器仅支持Planned GR。缺省情况下，路由器支持Planned GR和Unplanned GR。
partial：指定路由器支持Partial GR。缺省情况下，路由器支持Totally GR

3.配置设备重启Helper模式，并配置参数

、

period period：指定GR的周期。整数形式，取值范围是1～1800，单位是秒。缺省值是120秒。
planned-only：指定设备仅支持Planned GR。缺省情况下，设备支持Planned GR和Unplanned GR。
partial：指定设备支持Partial GR。缺省情况下，设备支持Totally GR。
ip-prefix ip-prefix-name：地址前缀列表名称。
acl-number acl-number：基本访问控制列表号。ACL参数用来配置过滤策略，只有通过过滤器策略后才能进入Helper模式。
acl-name acl-name：指定访问控制列表名称。
ignore-external-lsa：用来配置Helper不对Type5 LSA和Type7 LSA进行检查。缺省情况下，执行外部LSA检查。
never：指定设备不支持Helper模式

5.NSR.

高可靠性的解决方案包括不间断转发（Non-Stopping Forwarding，NSF）和不间断路由Non-Stopping Routing，NSR）

NSF：

通过协议的GR机制，支持系统主备倒换时，转发业务不中断。
▫ 当由于某种原因系统发生故障时，在系统重启过程中，转发平面（业务）不中断。
▫ 系统恢复后，设备能够重新建立邻居关系，从邻居处获取路由信息并重建路由表

NSR：

• 通过协议备份机制，实现主备倒换时控制平面（路由）和转
  发平面（业务）均不中断。
  • 在设备发生倒换的过程中，路由处理不中断，因为：
  ▫ 邻居和拓扑信息不丢失；
  ▫ 邻居关系不中断。
  • 优点：
  ▫ 不依赖也不影响对端设备，没有互通问题；
  ▫ 路由的收敛速度要比NSF快

NSR原理

 批量备份：NSR功能使能后，备板重启时，主用主控板将路由
信息和转发信息批量备份到备用主控板上。批量备份过程在实时备份过程之前进行，此时NSR无法实施主备倒换过程。
 实时备份：当批量备份过程结束后，系统进入实时备份阶段。任何在控制平面和转发平面的改变都将实时从主用主控板备份到备用主控板上。在该阶段，备用主控板能够随时代替主用主
控板工作。
 主备倒换：在已经完成备份的NSR系统主用主控板发生故障时，备用主控板会通过硬件状态感知到主用主控板故障，并成为新的主用主控板。备用主控板升主后，该单板会切换接口板的报文上送通道。由于倒换时间足够短，路由协议在主备切换的过程中不会和邻居节点断连。

控制平面路由协议实时备份路由信息；硬件通道感知主用主控板异常，通知备用主控板升主，同时切换接口班上送报文通道

NSR批量备份过程

NSR功能使能后，备板重启时，主用主控板上的业务进程
会收到备用主控板上线的消息。业务进程开始进行内部数据的批量备份。
 批量数据备份完毕后，系统进入冗余保护状态。进入该状态后，如果主控板出现故障，备板升主后就可以利用之前从主板备份过来的数据进行升主，恢复业务。
 如果业务批量备份尚未结束时，主控板故障，备板升主后可能会因为业务数据不全而导致无法升主，因此这个种状态下无法完成NSR倒换，设备会整机重启，恢复故障前状态

1. 备板启动完成。
2. 各业务进程通过HA通道开始批量备份路由等业务数据，系统进入批量备份阶段。
3. 业务进程全部批量备份完成后，系统进入冗余保护状态

NSR实时备份过程

完成批量备份后，系统进入实时备份阶段，在该阶段当邻居状态或路由信息发生变化时，主用主控板会实时将变化信息备份到备用主控板

1.邻居状态变化或路由变化

2.主用主控板将变化信息通过HA通道备份到备用主控板

3.备用主控板答复主要主控板确认信息

NSR倒换升主过程

·完成批量备份，进入冗余保护状态的系统，当主用主控板发生软件或硬件故障后，备用主控板会从底层硬件感知到主用主控板的故障，并自行升主。
·升主后业务进程会使用之前从主用主控板备份来的数据进行工作。同时接口板也会向新的主控板发送平滑倒换期间变化的信息。实现真正的路由不中断，转发不中断。

1. 硬件通道感知主用主控板异常，通知备用主控板升主，同时切换接口板上送报文通道。
2. 备用主控板升主后，接口板会向新的AMB发送平滑倒换期间的状态变化
3. 倒换升主完成后，新的主用主控板会向新的备用主控板进行NSR备份。

配置NSR

配置命令：switchover mode nonstop-routing | nonstop-forwarding

设置系统HA的工作模式。缺省情况下，系统HA的工作模式为NSF模式。
nonstop-routing：指定系统HA的工作模式为不间断路由NSR模式。系统处于NSR模式时，能够实现路由处理及转发业务不中断。
nonstop-forwarding：指定系统HA的工作模式为不间断转发NSF模式。系统处于NSF模式时，能够大幅减少转发业务中断时间

交流群：

cd /etc/yum.repos.d/ && mkdir bak
mv * ./bak

2、配置yum源

wget -O /etc/yum.repos.d/Centps-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo
yum clean all
yum makecache

3、配置epel源

wget -O /etc/yum.repos.d/epel.repo https://mirrors.aliyun.com/repo/epel-7.repo
yum clean all
yum makecache

交流群：

metadata.name=my-service
metadata.namespace!=default
status.phase=Pending

下面这个kubectl命令将筛选出status.phase字段值为Running的所有Pod：

kubectl get pods --field-selector status.phase=Running

说明：
字段选择算符本质上是资源“过滤器（Filters）”。默认情况下，字段选择算符/过滤器是未被应用的，这意味着指定类型的所有资源都会被筛选出来。这使得kubectl get pods和kubectl get pods --field-selector""这两个kubectl查询时等价的。
支持的字段
不同的K8S资源类型支持不同的字段选择算符。所有资源类型都支持metadata.name和metadata.namespace字段。使用不被支持的字段选择算符会产生错误，如：

kubectl get ingress --field-selector foo.bar=baz

Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"

自定义资源字段
所有自定义资源类型都支持metadata.name和metadata.namespace字段
此外，CustomResourceDefinition的spec.versions[*].selectableFields字段声明了自定义资源中那些其他字段可以用于字段选择算符。
支持的操作符
可以在字段选择算符中使用=、`==``和!=(=和==的意义是相同的)操作符。，例如，下面这个kubectl命令将筛选所有不属于default命名空间的K8S服务：

kubectl get services --all-namespaces --field-selector metadata.namespace!=default

说明：
基于集合的操作符（in、notin、exists）不支持字段选择算符
链式选择算符
同标签和其他选择算符一样，字段选择算符可以通过使用都好分隔的列表组成一个选择链。下面这个kubectl命令将筛选status.phase字段不等于Running同时spec.restartPolicy字段等于Always的所有Pod：

kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always

多种资源类型
字段选择算符也可以跨多种资源类型来使用，下面这个``kubectl命令将筛选出所有不在default```命名空间中的StatefulSet和Service

kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default

交流群：