> 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` 时间的意义 * 让冗余的包在网络中消失，避免序列号回绕
0x01 一些知识点
常见工具HackbarBurpsuiteFiddlerNmapWiresharkWSIDosend菜刀MetasploitAwvsAppscanWCEminikatzcain日志配置文件权限rw-rw-rw-rw：可以读取可以写入解析漏洞IISApacheNginx反弹 shellIE浏览器使用了代理，可能HTTP协议会受到防火墙限制，所以HTTP协议的反弹会失败ping不通说明ICMP协议也受影响，故HTTP/HTTPS/ICMP协议的反弹都会失败Telnet不通，只有通过插入挂了代理的IE进程反弹，或者通过代理反弹一句话木马Linux 常用命令digtraceroutepingwhomvgrepcattailHTTPS 中间人攻击（Android）SSL证书校验主机名校验SSL证书被泄漏CSRFCC 攻击PHP 代码审计SQL注入TCP 和 UDPTCP只是传输可靠UDP只是最大地交付常用端口用户登录安全的网络传输方案csrf_tokensession和cookie返回给客户端应急处理 Webshell 事件Webshell存放路径，分析Webshell的行为Webshell及其后门，根据Webshell的入侵方式（查看日志等方法），进行漏洞修补，升级程序Web服务进行安全设置WebshellXSSSYN FloodTCP洪水攻击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 FloodsyslogSYN_RECV连接特别多netstat查看对方IP特征iptables临时封掉最大嫌疑攻击的IP或IP号段F5挡攻击F5三次握手，建立连接之后F5才转发到后端业务服务器F5上看到的现象F5上业务的VS模式后，F5的CPU消耗比平时多%7，攻击停止后恢复F5抵挡效果明显tcp_synack_retries = 0SYN+ACK包）给客户端IP后，如果收不到第三次握手包（ACK包）后，不进行重试，加快回收半连接，不要耗尽资源net.ipv4.tcp_max_syn_backlog = 200000Struts2TCP/IPSYN请求报文，服务端接受连接后回复ACK报文，并为这次请求分配资源，客户端接受到ACK报文后也向服务端发送ACK报文，并分配资源，这样TCP连接建立ACK的意义ACK，才能表示客户端准备好了ACK，会导致让服务器超时重发SYNFIN报文，服务端接受到FIN报文后，明白客户端没有数据要发送了，但是如果还有数据没有发送完成，则不必急着关闭连接，可以继续发送数据，所以服务端先发送ACK报文，告诉客户端，请求已经收到，但是还没准备好，请继续等待消息，客户端收到后，进入FIN_WAIT状态，继续等待服务端的FIN报文，当服务端确定数据已经发送完成，则向客户端发送FIN报文，告诉客户端，这边数据发完，准备关闭连接，客户端收到FIN报文后，知道可以关闭连接了，但是客户端仍不相信网络，怕服务端不知道要关闭，所以发送ACK报文后进入TIME_WAIT状态，如果服务端没有收到ACK报文可以重发，服务端收到ACK后，就明白可以断开连接，客户端等待2MSL后依旧没有收到回复，则证明服务端已经正常关闭，客户端也可以关闭连接了，这样TCP连接断开ACK与第三次FIN能否合并ACK表示认可主动端不发送消息了，但是被动端可能还有消息需要发送，只有确认了没有消息发送（应用层体现为close()系统调用），被动端才可以发送FINACKACK，将会重发SYN包，多次重发超时后，将会发送RST包TIME_WAIT的意义ACK2*MSL时间的意义