一些知识点（一）

[PyxYuYu]

He alone is poor who does not possess knowledge.

0x01 一些知识点

---

• 常见工具
  • Hackbar
  • Burpsuite
  • Fiddler
  • Nmap
  • Wireshark
  • WSI
  • Dosend
  • 菜刀
  • Metasploit
  • Awvs
  • Appscan
  • WCE
  • minikatz
  • cain
• 日志
  • 包含敏感文件，容易泄漏帐号密码接口数据等信息
• 配置文件权限
  • rw-rw-rw-
    • rw：可以读取可以写入
    • 第一个为文件所属用户、第二个为用户所在组、第三个为其他用户
    • 其他用户能够读写，可以导致非法写入和越权访问
• 解析漏洞
  • IIS
  • Apache
  • Nginx
• 反弹 shell
  • IE浏览器 使用了代理，可能 HTTP 协议会受到防火墙限制，所以 HTTP 协议的反弹会失败
  • ping 不通说明 ICMP 协议也受影响，故 HTTP/HTTPS/ICMP 协议的反弹都会失败
  • 对方挂了代理，Telnet 不通，只有通过插入挂了代理的 IE 进程反弹，或者通过代理反弹
• 一句话木马
• Linux 常用命令
  • dig
  • traceroute
  • ping
  • who
  • mv
  • grep
  • cat
  • tail
• HTTPS 中间人攻击（Android）
  • 未对 SSL证书 校验
  • 未对 主机名 校验
  • SSL证书 被泄漏
• CSRF
  • 防御
• CC 攻击
• PHP 代码审计
  • 避免 SQL 注入

     mysql_real_escape_string
     addslashes
  

• TCP 和 UDP
  • TCP 只是传输可靠
  • UDP 只是最大地交付
  • 两者不存在哪个是否更安全的对比
• 常用端口
• 用户登录安全的网络传输方案
  • 用户输入密码时，加上复杂的验证码，同时以时间戳加密生成随机数，加上 csrf_token
  • 将用户帐号密码通过前端加密传输到服务器后台，设置同源策略
  • 服务器验证客户端身份后，通过随机安全数加密 session 和 cookie 返回给客户端
  • 客户端和服务器建立连接
• 应急处理 Webshell 事件
  • 首先检查服务器上该 Webshell 存放路径，分析 Webshell 的行为
  • 清楚 Webshell 及其后门，根据 Webshell 的入侵方式（查看日志等方法），进行漏洞修补，升级程序
  • 对服务器进行安全加固，对服务器上的系统及 Web 服务进行安全设置
  • 编写安全报告
    • 什么漏洞或服务器上的运维设置错误导致被上传 Webshell
    • 清楚了哪些后门，这些后门对服务器造成了什么影响
    • 做了哪些安全加固
    • 后面的定期安全检查和维护措施
• XSS
• SYN Flood
  • TCP 洪水攻击
    • 当开放了一个 TCP 端口后，该端口就处于 Listening 状态，不停地监视发到该端口的 SYN 包，一旦接受到客户端发来的 SYN 包，就需要为该请求分配一个 TCB，通常一个 TCB 至少需要 280 个字节，在某些操作系统中 TCB 甚至需要 1300 个字节，并返回一个 SYN ACK 命令，立即转为 SYN-RECEIVED 即半开连接状态，而某些操作系统在 SOCK 的实现上最多开启 512 个半开连接
    • 利用 TCP 协议缺陷，发送大量伪造的 TCP 连接请求，常用假冒的 IP 或 IP 号段发来海量的请求连接的第一个握手包（SYN 包），被攻击服务器回应第二个握手包（SYN+ACK 包），因为对方是假冒 IP，对方永远收不到包且不会回应第三个握手包，导致被攻击服务器保持大量 SYN_RECV 状态的 半连接，并且会重试默认 5 次回应第二个握手包，塞满 TCP 等待连接队列，资源耗尽（CPU 满负荷或内存不足），让正常的业务请求连接不进来
  • 判断是否 SYN Flood
    • 查看系统 syslog

       SYN flooding
    

    • 查看连接数，SYN_RECV 连接特别多

       SYN_RECV 48979
    

  • 应急处理
    • 根据 netstat 查看对方 IP 特征

       netstat -na |grep SYN_RECV|more
    

    • 利用 iptables 临时封掉最大嫌疑攻击的 IP 或 IP 号段

       iptables -A INPUT -s 173.0.0.0/8 -p tcp -dport 80 -j DROP
    

    • 分析业务，解封号段内正常的子网段，不是很理想的方式
  • F5 挡攻击
    • 让客户端先和 F5 三次握手，建立连接之后 F5 才转发到后端业务服务器
    • 被攻击时 F5 上看到的现象
      • 连接数比平时多500万，攻击停止后恢复
      • 修改 F5 上业务的 VS 模式后，F5 的 CPU 消耗比平时多 %7，攻击停止后恢复
      • 用 F5 抵挡效果明显
  • 调整系统参数挡攻击
    • tcp_synack_retries = 0
      • 表示回应第二个握手包（SYN+ACK 包）给客户端 IP 后，如果收不到第三次握手包（ACK 包）后，不进行重试，加快回收 半连接，不要耗尽资源
      • 缺点
        • 网络状况差时，如果对方没收到第二个握手包，可能会连接服务器失败，但对于一般网站，用户刷新一次页面即可
    • net.ipv4.tcp_max_syn_backlog = 200000
      • 具体多少数值受限于内存
• Struts2
• TCP/IP
  • 基础
    • 三次握手

       SYN
       ACK + SYN # 被动端，服务器端，ACK是用于应答，SYN是用于同步
       ACK
    

    • 建立连接：首先客户端发送 SYN 请求报文，服务端接受连接后回复 ACK 报文，并为这次请求分配资源，客户端接受到 ACK 报文后也向服务端发送 ACK 报文，并分配资源，这样 TCP 连接建立
    • 握手中最后一次 ACK 的意义
      • 只有服务器端收到 ACK，才能表示客户端准备好了
      • 如果服务器端收不到 ACK，会导致让服务器超时重发 SYN
    • 四次分手

       FIN
       ACK # 被动关闭端，发起关闭的可以是服务端，也可以是客户端
       FIN # 被动关闭端，发起关闭的可以是服务端，也可以是客户端
       ACK
    

    • 断开连接：客户端发起中断连接请求，即发送 FIN 报文，服务端接受到 FIN 报文后，明白客户端没有数据要发送了，但是如果还有数据没有发送完成，则不必急着关闭连接，可以继续发送数据，所以服务端先发送 ACK 报文，告诉客户端，请求已经收到，但是还没准备好，请继续等待消息，客户端收到后，进入 FIN_WAIT 状态，继续等待服务端的 FIN 报文，当服务端确定数据已经发送完成，则向客户端发送 FIN 报文，告诉客户端，这边数据发完，准备关闭连接，客户端收到 FIN 报文后，知道可以关闭连接了，但是客户端仍不相信网络，怕服务端不知道要关闭，所以发送 ACK 报文后进入 TIME_WAIT 状态，如果服务端没有收到 ACK 报文可以重发，服务端收到 ACK 后，就明白可以断开连接，客户端等待 2MSL 后依旧没有收到回复，则证明服务端已经正常关闭，客户端也可以关闭连接了，这样 TCP 连接断开
    • 分手中，第二次 ACK 与第三次 FIN 能否合并
      • 不能，第二次 ACK 表示认可主动端不发送消息了，但是被动端可能还有消息需要发送，只有确认了没有消息发送（应用层体现为 close() 系统调用），被动端才可以发送 FIN
    • 分手中，最后一次 ACK
      • 表示被动端也不发送数据了，如果主动端没有收到这个 ACK，将会重发 SYN 包，多次重发超时后，将会发送 RST 包
    • 关闭过程中，TIME_WAIT 的意义
      • 用于接受重发的来自被动端的 ACK
    • 关闭过程中，最后等待 2*MSL 时间的意义
      • 让冗余的包在网络中消失，避免序列号回绕