安全热点问题
1.DDOS
分布式拒绝服务攻击，是指黑客通过控制由多个肉鸡或服务器组成的僵尸网络，向目标发送大量看似合法的请求，从而占用大量网络资源使网络瘫痪，阻止用户对网络资源的正常访问
DDoS攻击技术包括：常见的流量直接攻击（如SYN/ACK/ICMP/UDP FLOOD），利用特定应用或协议进行反射型的流量攻击（如NTP/DNS/SSDP反射攻击），基于应用的CC、慢速HTTP等
DDoS防御常规套路：
++1、本地设备清洗++
抗DDoS设备（业内习惯称ADS设备）一般以盒子的形式部署在网络出口处，可串联也可旁路部署。旁路部署需要在发生攻击时进行流量牵引，其基本部署方案如图：
检测设备对镜像过来的流量进行分析，检测到DDoS攻击后通知清洗设备，清洗设备通过BGP或OSPF协议将发往被攻击目标主机的流量牵引到清洗设备，然后将清洗后的干净流量通过策略路由或者MPLS LSP等方式回注到网络中；当检测设备检测到DDoS攻击停止后，会通知清洗设备停止流量牵引
将ADS设备部署在本地，企业用户可依靠设备内置的一些防御算法和模型有效抵挡一些小规模的常见流量攻击，同时结合盒子提供的可定制化策略和服务，方便有一定经验的企业用户对攻击报文进行分析，定制针对性的防御策略。目前国内市场上，主要以绿盟的黑洞为代表
本地清洗最大的问题是当DDoS攻击流量超出企业出口带宽时，即使ADS设备处理性能够，也无法解决这个问题
++2、运营商清洗++
当本地设备清洗解决不了流量超过出口带宽的问题时，往往需要借助运营商的能力了，紧急扩容或者开启清洗服务是一般做法，前提是要采购相应的清洗服务。而且一般需要通过电话或邮件确认，有的可能还要求传真。
运营商的清洗服务基本是根据netflow抽样检测网络是否存在DDoS攻击，而且策略的颗粒度较粗，因此针对低流量特征的DDoS攻击类型检测效果往往不够理想。再加上一些流程上的操作如电话、邮件、传真等，真正攻击到来时处理可能会更慢，需要重点关注。
中国电信的云堤服务，提供了"流量压制"和"近源清洗"服务，而且还提供了自助平台供用户操作，查看流量、开启清洗也非常方便
++3、云清洗++
CDN技术的初衷是为了提高互联网用户对静态网站的访问速度，但是由于分布式、就近访问的特点，能对攻击流量进行稀释，因此，一些传统CDN厂商除了提供云加速功能外，也开始推出云清洗的服务，基本原理是：
- 在 CDN 或 DDoS 防护服务的云端，事先配置好一个 专门用于防御的域名解析记录，这个记录可以指向某个防护节点。这些节点配备了大量的带宽和强大的过滤、清洗能力，能够识别并阻挡恶意流量
- 当企业网站遭遇大规模攻击时，为了防止攻击直接打到原始服务器，企业会 修改其域名的 DNS 记录 ，将域名的 CNAME（别名）记录 指向 CDN 防护的节点
- 当 DNS 解析生效后，所有访问该企业网站的流量都会被重定向到 CDN 或云清洗服务的节点，而不是直接访问企业的原始服务器
使用云清洗需要注意以下几个问题：
- 云清洗厂商需要提前配置好相应记录
- DNS修改记录后，需要等待TTL超时才生效
- 直接针对源IP的攻击，无法使用云清洗防护，还要依靠本地和运营商清冼
- 针对HTTPS网站的防御，还涉及HTTPS证书，由此带来的数据安全风险需要考虑，市面上也有相应的Keyless方案
++4、自动化平台++
金融企业由于高可用要求，往往会有多个数据中心，一个数据中心还会接入多家运营商线路，通过广域网负载均衡系统对用户的访问进行调度，使之访问到最近最优的资源。当任何一条接入线路存在DDoS攻击时，能通过广域网负载均衡系统将该线路上的访问需求转移至其他互联网线路。为了实现快速切换，需要通过自动化运维平台来实现。当某一个业务的IP受到攻击时，可以针对性地处置，比如一键停用，让正常用户访问其他IP；也可以一键开启清洗服务
++5、更多优化++
- 某些产品在开启日志记录模块后会存在极严重的性能消耗，在可能存在攻击的环境内建议关闭
- 建议当存在大量TCP、UDP新建连接时，防火墙的最大连接数越大越好
- 多测试多对比，从对比中可以发现更优的方案，通过适当的调整优化引入更优方案
- 监控防火墙CPU和连接数，当超过一定值时开始着手优化规则，将访问量多的规则前移、减少规则数目等都是手段
- 建议在不事先通知的情况下进行演练，观察这中间的问题并做好记录，待演练完成后一并提交给服务商要求整改。这样的演练每年要不定期组织几次。
2.补丁管理
++1、Windows++
微软从2003年10月开始引入了著名的"Patch Tuesday"的概念，即把过去一个月内的安全补丁累积起来，到了下一个月的第二个星期二集中发布，这样可以让系统管理员在固定的时间点来查看有哪些补丁发布了，并决定是否要安装这些补丁。
微软提供两种安全补丁服务：一种是基于推送的付费服务SCCM；另一种是免费的可自动下载的补丁下载服务WSUS
以使用WSUS的企业为例，企业外网的WSUS指向微软网站，所有Windows更新都集中下载到内部网的WSUS服务器，而网络中的客户机通过WSUS服务器得到更新。这里有两个前提条件：一是补丁经过管理员的批准；二是客户机配置了WSUS指向企业内部WSUS服务器。这样的补丁升级方式，在很大程度上节省了网络资源，并且提高了内部网络中计算机更新的效率。
配置WSUS，网上的教程大都是通过修改注册表的方式来实现，如果企业部署了活动目录，可以使用组策略功能进行统一配置
补丁管理有以下建议：
- 补丁在允许更新前的测试、验证工作需要谨慎，以防出现诸如蓝屏、进程崩溃、与现有常用软件冲突等问题
- 办公、业务网的升级机制需要错开，比如办公网打补丁一周后再为业务网打补丁，防止出现可用性问题
- 有可用性要求的机器，在打补丁前做好意外情况下的准备工作，一旦有问题可以通过快照、快速部署等方式恢复业务，这一点需要依赖企业可用性建设方面的能力
- 不是所有补丁都需要打，优先处理安全类补丁，其他功能增强型的补丁可以不打
- 重启才能生效的补丁遇到涉及可用性的机器，需要使用"灰度"策略，在其他安全控制措施有效的情况下可以适当延后
- 采用漏洞扫描的方式跟进补丁情况，需要由专人负责这方面的工作，针对长久未打补丁的需要有相应的事件升级机制
- 必要时可以借助外部力量来推动相关工作，比如请审计相关同事重点关注某些执行不到位的分支机构或部门
++2、Linux++
Linux在安装软件的过程中涉及很多依赖性问题，所以一般正常情况下安装软件都是到yum源或apt源上。在内网不方便访问互联网的情况下，一般企业都会搭建内部的yum或apt源，以供内部Linux机器使用。在打补丁这个场合，也能用上。
使用yum update更新时，一般不建议升级内核，因为升级内核可能会带来意想不到的一些问题，比如PHP应用无法使用、硬件无法识别等，除非已经对升级内核进行了充分测试。升级内核后，要确保下次启动时使用新内核，默认情况下新安装的内核会排在第一位，如无特殊要求不应该修改grub引导配置文件
针对应用的补丁，也需要看漏洞是否真的有比较大的影响，如远程执行、本地提权等。原则上致命级别的漏洞应该立即更新；对于bug修复类补丁，如果涉及的模块涉足BUG触发条件应及时更新，其他情况则延后，比如一个月内更新；而功能增强型补丁则更延后，比如建议每6个月更新一次等。
当外界披露了某个应用存在高危漏洞，如果想快速修复漏洞，需要有个前提---如何确定哪些机器上有相应的应用及受影响的版本。安全人员的第一反应是漏洞扫描发现，但有些漏洞仅靠扫描器是发现不了的，所以这里往往又涉及企业资产管理或运维自动化方面的能力了。做得好的企业，会有一套系统用于快速查询哪些服务器运行了哪些特定的软件，以及软件的版本号，最好还能执行一些简单的指令，比如升级特定的软件，那打补丁就方便多了。
3.堡垒机管理
++1、用户与权限管理++
堡垒机的用户一般分为：系统管理员、业务或开发人员、外包人员，以及值班或应急公用账号。不同的用户，建议有不同的认证等级或启停控制
用户认证通过后，所能登录的设备以及登录设备的用户权限也需要进行统一规划和管理
以上过程中涉及账号启停的，最好实现一键化、自动化，即ITIL提单审批后，账号自动开启；系统管理员给外包人员开启账号时也是一键开启；给开发或业务人员授权的，也可以做成一键自动提权，否则太繁琐了不太容易执行。
最后，人员变动特别是员工离职，除了进行账号与权限清理外，还需要有自动化的对比机制，比如，账号每天自动与HR或AD等系统对比，若发现问题及时报警处置，防止因工作疏忽导致的离职员工账号未清理类审计问题。
++2、机器纳管与口令变更++
一台机器，需要经过哪些流程才允许上线？上线前扫描、被堡垒机纳管、采集安全日志等都是必要的。
堡垒机纳管设备，除了登记IP、机器名、所属业务系统、负责人等之外，一般还要求上收用户账号与口令。口令上收后，可以实现自动登录，无须用户再输入账号密码了。堡垒机有了账号口令，便可以进行自动化的口令变更，按照一定的规则生成复杂密码，然后定期修改口令。
为了防止堡垒机出问题而无法登录，或者因堡垒机变更密码导致系统无法登录，一般都会保留一个应急账号，密码保存在堡垒机里，当需要取出时提单申请打印密码信封即可。当有打印密码信封事件触发时，安全人员会审核是否正常。
++3、高可用架构与设计++
一般堡垒机分为访问服务器和后台服务器，访问服务器主要负责将用户的登录请求转接到后台（比如RDP和SSH），而后台服务器则保存用户权限、主机用户密码等相关信息。
这两部分都需要做好高可用架构设计。数据库的高可用（如Oracle的RAC，MySQL的主从复制读写分离等）都有成熟的技术，访问服务器则可以借助类似F5或LVS的技术实现负载均衡，由于涉及会话连接等，需要注意会话保持相关的设置。有些做得好的应用，甚至会将一些后台权限、设备口令等信息通过加密缓存到访问服务器上，这样即使整个后台服务全挂了，也能让已有用户正常登录，只是新用户、新设备等无法管理。
++4、应急通道与绕过发现++
为了防止出现堡垒机彻底用不了的情况，企业一般都会保留应急通道，比如允许固定的机器访问固定的管理服务器等。
有的管理员会尝试绕过堡垒机，比如将RDP或SSH端口监听放在别的端口，这样在网络防火墙会存在绕过的情况，绕过堡垒机就缺乏监管，管理员在目标机器上的操作也无法审计。
针对这种情况，可以利用下一代防火墙基于应用协议做规则，也可以使用事后监测手段。在终端上监测远程桌面、SecureCRT等进程的网络访问情况，也可以在网络上使用异常访问检测系统监测触发RDP和SSH协议的目标端口是否为正常端口
4.加密机管理
通常我们把金融数据密码机简称为加密机
++1、高可用架构++
设置部署位置按业务的重要程度不同而不同，重要业务系统往往同时部署在多数据中心，那配套的加密机也要与之相应。同一个数据中心，加密机要分布在不同楼层、不同网段，如果在同一个楼层，要分开部署在不同的防火区。
应用连接基本分为应用直连、应用连接加密机池VIP 两种模式；在连接方式上有长连接、短连接之分
1️⃣ 应用直连
在这种模式下，应用直接与加密机建立连接，不经过任何中间负载均衡设备。应用自身负责探测加密机的状态并进行负载均衡。如果某台加密机出现故障，应用必须识别并将其隔离，确保新的交易不再被发送到故障加密机。这种方式的灵活性较高，但要求应用具有一定的负载均衡和故障检测能力
2️⃣ 加密机池 VIP 模式
这里指的是通过一个 负载均衡设备 （例如使用 VIP，虚拟 IP 地址）来统一管理多个加密机的连接。应用不直接连接到加密机，而是连接到负载均衡器，负载均衡器根据加密机的状态进行流量分发。负载均衡器通过应用级探测模拟应用请求来检查加密机的健康状态，如果某台加密机返回异常，负载均衡器会自动隔离它，避免将新请求发送到该加密机。相比应用直连，这种方式可以减少应用的复杂度，但依赖负载均衡器的配置和能力
有些厂商提供了一个统一管理平台，作为一个中间层，所有业务系统都连接到这个平台，平台再把请求转发给后端的加密机。这种设计类似于代理，起到了集中的管理和调度作用
++2、加密机监控++
对于像加密机这种特殊设备，单纯的网络层探测（如 Ping 或 TCP 端口）可能不足以全面反映其运行状态。因此，建议深入到应用层进行更精细的监测
除了传统的设备层探测外，监控设备的可用性还应该从 网络流量 和 业务交易量 的角度进行监控。具体方法如下：
- 通过监控网络设备的流量，可以发现潜在的异常，比如连接数的突然增加或减少，这往往是问题的征兆。举例来说，短连接的业务在负载均衡设备（如 F5）上，正常情况下连接数应该很少或接近 0。若某业务上线后发现连接数增加，可能是因为开发时创建了连接但没有及时释放，导致连接泄漏
- 业务的高峰低谷在日常运行中是有规律的，可以通过历史数据设定业务交易量的上下限阈值。当交易量、响应率、响应时间或成功率等指标出现偏离时，可以作为辅助判断系统是否存在问题
++3、上下线与应急++
上线和下线是相对比较基础的工作，需要注意的是加密机管理员和密钥管理员须严格区分。很多业务往往是上线容易下线难，这就需要各种沟通协调工作了，同时还需要配合技术上的监控。比如，某开发组说应用不再连这个加密机了，管理员在下线前还需要确认是否除了监控探测外，真的没有流量再访问该加密机，否则可能会出现可用性事件。下线的设备可能还要走相应的报废流程，一定要对密钥进行销毁。
可用性架构做得好的企业，单台加密机出故障不会使业务受影响。基本的应急操作都是重启，有些时候担心重启过程有影响，可以在F5上将设备Disable或者机房拔掉网线，重启确认没问题再插上。