哼,大家难道说认为我前边讲的frp的白讲的嘛,不会有的,那一切彻底是为了更好地msf做准备。大家来更新改造一下大家的msf,若有frp基本未知了的,请自寻上一期內容(frp:透过内网的反向代理专用工具)。
话不多说,大家各自在服务器端和手机客户端做以下更新改造,对于为何?自寻上一期附设推送內容(frp官方网汉语文本文档)。
# frps.ini
[common]
bind_port=7000
dashboard_port=7500
# dashboard 用户名密码,默认设置都为 admin
dashboard_user=admin
dashboard_pwd=admin
# frpc.ini
[common]
server_addr=*.*.*.*
server_port=7000
[ssh]
type=tcp
local_ip=127.0.0.1
local_port=22
remote_port=6000
[msf]
type=tcp
local_ip=127.0.0.1
local_port=4444
remote_port=6666
大伙儿能够去与上一期提及的基本配置做下比照,仅仅在原先基本上提升了端口转发形象化页面dashboard?,和msf端口转发配置,在其中msf默认设置监视端口号为4444。
到这儿,你的msf反代已配置进行,你能将你的shell根据frp传入内网msf上用以监视回到內容。殊不知你也应当发觉啦,frp只让你出示了shell的反向代理,殊不知攻击的数据信息還是从你的pc传出啦,因此 ,请仍然不张扬。次之,并并不是msf全部的payloads在创建sessions时都必须反向代理的,请自主挑选。
再多讲一句,到这儿你应该还发现了一件事,一切必须反向代理的实际操作,都能够根据frp进行,这不过是一个透过内网的端口转发专用工具,实际如何使用,标准由你决策。
你觉得到这儿就完毕啦?
人资的直播间就从未不车翻过!哪些出现意外都能要我给遇上!
大伙儿你是否还记得大家设定了dashboard?页面嘛。我的打开以后便是无法打开!!!
在拆换N个端口号,查验N次配置,查询N次端口号情况后。。。最后难题找到。。。
二张截屏,大伙儿见到差别了没有?懒惰的起动方法未指定配置文档,其他各类配置全是一切正常的,唯有dashboard?在帮我搞事!!!它也懒惰!!!
唉。。解决问题了,,给各位看一眼得来不易的dashboard?的页面吧。尽管我总期待眼前的你事半功倍,可是、说真的,弯道也是有它的风采的说。。。