0x01 前言
    实际渗透中,我们经常会遇到各种ips或者waf的围追堵截,有时候,跑个目录就直接把你ip封了,因为经常会遇到这种尴尬的情况,所以就灵机一动想了个比较折中的办法,利用tor来频繁的切ip,然后用socks5代理,把常用的工具丢进去搞,注意用工具跑的时候,线程要尽量给少点,tor唯一的缺点就是慢,当然,你也可以写成分布式扫描,不过可能需要你事先准备好一大批高质量代理ip,然后随机轮训,不过咱们不需要这么麻烦,不到五分钟写了个小脚本,暂且能满足需求,将就用吧

0x02 代码如下
    随便写的,比较粗糙,大家将就着看吧,如下,有些地方还有问题,后期抽空想到好点子了,再完善下,对了,不知道为啥tor自己的切ip选项不管用,希望哪位兄弟如果找到原因麻烦也告诉我一声,谢谢……

0x01 什么是Lua

1
2
3

关于Lua,就不用多说了吧,想必朋友们应该也都非常熟悉了,众多脚本语言中的一种,不过相对于其它脚本来说,性能要略高一点
在nginx中也提供了一个nginx_lua的模块,主要是为了方便用户,可以灵活的通过lua来扩展nginx功能,比如lua_waf
有兴趣可自行深入了解,这里就不细说了,我们今天的重点主要还是想利用它来快速部署一个简易版的Waf

0x02 这里,我还是拿之前已经编译好的lnmp环境来演示,因为等会儿要重新编译nginx,所以就直接把之前nginx的整个安装目录干掉,因为是源码编译安装的,所以也不会有啥残留[源码编译安装的好处],记得在干掉之前先把nginx服务停掉,配置文件[nginx.conf]也备份一下,方便等会儿再直接拿过来用

1

php5.5.38 + mysql-5.5.32 + nginx-1.12.1 + centOS6.8_x64

1
2
3
4

# pkill nginx
# netstat -tulnp | grep "80"
# cp /usr/local/nginx/conf/nginx.conf /root/
# cp /usr/local/nginx/conf/extra/bwapp.conf /root/

0x01 其实redis跟memcached 单从功用上来讲,基本差不太多,只是在数据量非常大的情况下,memcached 就会有很多的问题,但redis在这方面却恰巧做的还不错,且redis所支持的功能更加全面,也能更好的适应一些比较复杂的业务逻辑,下面则是关于redis的一些优良特性

1
2
3
4
5

所支持的数据类型较丰富
支持持久化存储
支持主从复制
性能强悍,并发可超十万
...

此次演示环境

1
2
3
4
5

CentOS6.8_x86_64   ip: 192.168.3.42 	Oldlnmp  	root权限下的redis未授权
CentOS6.8_x86_64   ip: 192.168.3.66 	RedisMaster 	为加固过的redis
Ubuntu16.04 server ip: 192.168.3.67 	RedisSlave	root权限下的redis未授权
Ubuntu16.04 LTS	   ip: 192.168.3.12     Metasploit	为redis客户端
win7cn		   ip: 192.168.3.60	后续连webshell用

0x02 开始安装部署 redis,此处暂以最新版为例进行演示,为了避免redis自身的一些漏洞,建议使用最新版的稳定版本

1
2
3
4
5
6
7
8
9

# wget http://download.redis.io/releases/redis-4.0.6.tar.gz
# tar xf redis-4.0.6.tar.gz
# cd redis-4.0.6
# make MALLOC=jemalloc
# make PREFIX=/usr/local/redis-4.0.6 install
# ln -s /usr/local/redis-4.0.6/ /usr/local/redis
# export PATH=/usr/local/redis/bin/:$PATH
# echo "export PATH=/usr/local/redis/bin/:$PATH" >> ~/.bash_profile
# redis-server -h

0x01 利用最原始的 SSH key ,实现批量ssh管理 只适合较小规模集群场景,通常在100台机器以内,要实现的最终效果,如下:

1
2

可以批量分发文件,进行常规配置管理
可以批量执行shell命令,进行日常维护操作

演示环境:

1
2
3

SshKeyMaster 	ip: 192.168.5.11	CentOS6.8 x86_64 分发机
SshKeySlave5	ip: 192.168.5.13	CentOS5.5 i386   分发客户机
SshKeySlave7	ip: 192.168.5.12	CentOS7	  x86_64 分发客户机

0x02 基于SSH key 的批量ssh管理,具体实现过程:

以下是在这方面已经相对比较成熟的一些工具框架,后续会再专门针对每一种进行单独说明:

1

saltstack,ansible,puppet...

1

# rpm -qa openssh openssl 务必确保所有机器均已事先安装好ssh且ssh服务已正常开启

0x03 先在所有机器上 [ 注意,是所有机器,密码完全一致 ]创建一个普通用户,因为等会儿我们要用此用户身份来进行各种分发操作

切记,严禁直接用root分发,权限过高,太危险,分发机一旦被攻陷,其它的分发客户机也就随之沦陷了,建议,如果实在有需求可以用sudo或suid [其实也不推荐]来暂时性授权

1
2

# useradd sysadm
# echo "admin" | passwd --stdin sysadm

0x04 再在分发机上创建好密钥对,准备发到各个客户机上

1
2
3
4
5

# su - sysadm		切到刚刚创建的用户下
$ ssh-keygen -t dsa	一路回车即可
$ ls -l .ssh/
  -rw------- 1 sysadm sysadm 668 Nov 27 14:11 id_dsa	 私钥[钥匙]
  -rw-r--r-- 1 sysadm sysadm 609 Nov 27 14:11 id_dsa.pub 公钥[锁],把公钥分发给所有要ssh的机器

0x01 NFS 简介:
    NFS 一个比较古老[比自己的年龄都大]的网络文件系统,不过,相对比较稳定,由服务端和客户端组成 [ 即 C/S 架构 ] ,服务端主要负责提供共享目录 [一般为web的用户数据存放目录,专门用来存放用户上传的各类静态数据],而客户端则负责存取该共享目录中的数据

0x02 NFS 容易产生安全问题的几个点:

1
2
3
4

共享目录在本地文件系统中的权限问题
NFS服务用户权限设置问题
NFS客户端挂载的安全及性能问题
.....

0x03 环境部署简介 [ 所有系统均以 centOS6.8_x64 最小化安装,只带有必要的环境库 ]:

nfs服务端:

1

NfsServer	ip: 192.168.4.2

0x01 一些常见的 Nosql 数据库

1
2
3
4

memcached 基于纯内存缓存,也就是说,服务只要一重启所有数据就会丢失,但它操作简单,易于上手,相对高效
redis     既可以基于内存缓存亦可基于硬盘持久存储,另外,它所支持的数据类型相对较多,功能也较完善
MongDB 
...

此次演示环境

1
2
3

CentOS6_x86_64 ip: 192.168.3.65
OldLnmp        ip: 192.168.3.42
Ubuntu16.04.3  ip: 192.168.3.12

0x02 Memcached 缓存实际中简单的应用场景

1
2

基于纯内存缓存,速度快,同样,也是基于 C客户端 / S服务端 的工作模式,而libevent其实就是一个支持epoll/kqueue异步I/O模型的接口
Memcached 在实际生产中主要是用来存放用户经常要访问到的一些高频关键字,加快数据库命中,减轻后端数据库压力,提高数据响应速度...

关于 Rsync

1

一款开源的,功能繁多的,同时支持对本地和远程进行全量或增量的备份工具,主要用于不同服务器间进行数据同步,默认使用增量备份

0x01 rsync 演示环境 [ Rsync服务端系统为 centOS6.8_x64 最小化安装 ]

1
2

rsync 服务端:
RsyncServer	ip: 192.168.5.4

1
2
3

rsync 客户端:
RsyncClient26 	ip: 192.168.5.7	 Fedora 26 x86_64
RsyncClient14	ip: 192.168.5.8	 Ubuntu 14.04.3 LTS x86_64

0x02 对于 rsync 来讲,不管推还是拉,在此之前都会自动和之前的文件进行比对,只要有文件属性或者内容发生改变就重新备份,否则不会有任何动作,即先比较后同步,另外,rsync 默认同步时是不加密的,可使用 ssh隧道 的方式来进行加密同步

1
2
3
4
5
6
7
8

远程拷贝 [ 加密拷贝 ]: 相当于scp
# scp /root/pentest.txt root@192.168.5.4:/tmp/hacked.txt

本地拷贝: 相当于cp
# cp -R /etc/ /webbak/

删除文件: 相当于rm
# rm -fr /webbak/etc/

0x01 利用 intify 做实时同步,实现如下适合文件并发较少文件较小的备份场景中,一般并发范围在200-300个小文件,延迟基本是很小的,如果超过这个量就比较吃力了:

1

要备份的目录 + inotify  ->  inotify会一直监控该目录的变化,只要所监控的目录一有变化,就把新生成的文件或者目录自动推到备份服务器上

0x02 准备好环境:

1
2

RsyncServer   一台已经事先配置好的Rsync服务器
RsyncClient26 再准备一台已经事先配置好的Rsync客户端,因为等会儿就在这台机器上安装inotify,也就是说,只要监控到客户端一有数据更新,就自动往服务端推

0x03 开始在rsync客户端上编译安装 inotiy:

1

# ls -l /proc/sys/fs/inotify/ 	首先,查看当前内核是否支持,如果出现以下三个文件则表示支持

1
2
3
4
5
6
7
8

# wget https://jaist.dl.sourceforge.net/project/inotify-tools/inotify-tools/3.13/inotify-tools-3.13.tar.gz
# tar xf inotify-tools-3.13.tar.gz
# cd inotify-tools-3.13
# ./configure --prefix=/usr/local/inotify-tools-3.13 && make && make install
# echo $?
# ln -s /usr/local/inotify-tools-3.13/ /usr/local/inotify
# ls -l /usr/local/inotify/
# cd /usr/local/inotify-tools-3.13/bin/

0x01 前言
    不管对于web开发亦或是渗透来讲,熟练掌握http协议的核心运作要点都是入门必备科目,如果连这些最基础的东西都没掌握熟练,又何谈下一步呢,因为http会贯穿于后续整个web渗透过程,当然啦,就http协议本身来讲,还是非常非常复杂的,单单靠一篇文章就想全面透彻的掌握http协议,毕竟不太现实,所以我们今天也只是模拟站在一个专业入侵者的角度上来重新理解http协议最核心的一些点,中间也会穿插着说明这些点容易带来的一些安全问题,如果大家真的非常有兴趣,想继续深入学习http协议,建议参考 《http权威指南》,着实是本http方面的好书,起码,个人是这样觉得的,既然是说协议,也就意味着某些东西可能会有些抽象,不过大家不用担心,我会用尽量用最容易理解的方式把它说明白,废话到此为止,咱们开始

0x02 初始 http 简要工作过程
  客户端向web服务器请求所指定的资源(request) => web服务器(默认端口通常为80,8080)
  web服务器响应给客户端所请求的对应的资源数据(response) => 客户端(随机端口和目标web服务端口进行连接)
  简单来讲,http就是一套用来规定”请求(request)”和”响应(response)”的规范,以此来保证客户端和服务端能够正常的进行通信
  用白话来讲 客户端向服务器端请求,然后服务器端把被请求的东西交给客户端 这就算一次完整的http通信