突发奇想,没有正文。
1 silencefent 2019-07-16 16:02:23 +08:00 可以记录 mac 地址 |
![]() | 2 cwjokaka OP @silencefent 但一般请求服务器应该是获取不到 mac 的吧 |
3 miniliuke 2019-07-16 16:14:10 +08:00 要看谁查了,国家想查那除非几层代理,否则没用 |
4 lihongjie0209 2019-07-16 16:22:28 +08:00 @silencefent mac 地址有个鬼用, 能记录的 mac 地址只是上一级路由器的 mac 地址, 能找到个鬼 |
5 edgnoz 2019-07-16 16:46:44 +08:00 记得方校长曾经说过,7 层都能查 |
![]() | 6 xiaopang132 2019-07-16 16:50:18 +08:00 tor 都能给你扒出来 |
![]() | &nbp; 7 xiaopang132 2019-07-16 16:50:35 +08:00 不知道你说的高匿是有多高 |
![]() | 8 danmu17 2019-07-16 18:15:38 +08:00 代理的本质只是用来改善路由实现加速或绕过防火墙实现突破。 想要实现匿名的话需要额外增加好几个其他的措施。 不过考虑到这里基本不存在真正需要匿名的人,就不说关于匿名的问题了。 |
![]() | 9 adminPUBG 2019-07-16 18:17:56 +08:00 目前高匿 IP 主要是做爬虫类的吧,感觉也不会挖空心思去查你的原 ip,但是如果是搞事情的话,劝你不要动歪心思啊,网络不是法外之地 |
![]() | 10 danmu17 2019-07-16 18:20:44 +08:00 ![]() 高匿代理和非高匿代理的区别是 一个直接告诉了服务器你的真实 IP 地址,另一个没有。 但是不告诉服务器你的真实 IP 和服务器有没有办法获得你的真实 IP 是完全不同的概念。 服务器仅仅依靠自己有没有办法获得你的真实 IP 和服务器的主人通过 ISP/专业机构有没有办法获得你的真实 IP 又是完全不同的概念 希望有能看懂我在说什么的人。。。。不过如果能看懂的也不需要来看了。。。 感觉自己又浪费了好几分钟的生命。 |
![]() | 11 Buges 2019-07-16 18:27:59 +08:00 via Android ![]() 从网络层,如果你经历了多级跳板,跨地区跨国跨运营商再套上 t.o.r 和 i2p,除非你是毁灭世界的勾当否则就可以认为是安全的。 但是由于木桶效应,其他层面的短板,比如应用收集信息,请求泄漏,时区,社工还有最危险的涉及金钱的流通等等因素都可能导致你暴露。 |
![]() | 12 danmu17 2019-07-16 18:30:55 +08:00 @lihongjie0209 如果你是某国的 ISP 的话,你就可以通过自动化的系统,自动的一级一级的查下去,找个某个特定的封包对应的家庭路由器的 mac 地址以及户主的地址和姓名了。 |
13 zackwu 2019-07-16 18:31:44 +08:00 ![]() |
14 lihongjie0209 2019-07-16 18:55:08 +08:00 @danmu17 首先 一级一级查下去只能按照 IP 查, 最后查到局域网内部才能用 mac 地址查, 如果 mac 地址被伪造, 根本查不到. 其次, 你是 ISP 也没办法跨 ISP 查询, 比如对方用了美国的高匿名 IP |
![]() | 15 aWangami 2019-07-16 19:06:06 +08:00 via Android 万一是蜜罐呢? |
16 CallMeReznov 2019-07-16 19:23:51 +08:00 说记录 MAC 是搞笑的吗. |
![]() | 17 SlipStupig 2019-07-16 19:54:14 +08:00 @CallMeReznov 真不是搞笑,只是这个记录方式跟楼上说的完全不搭噶 @lihongjie0209 很多时候并不需要,你确实用了 IP 代理,但是你的 DNS 或者浏览器可能会出卖你 这里只是简单说一下,现在查这些已经超过各位的理解了 |
18 stone666 2019-07-16 20:02:04 +08:00 大佬们倒是说一下呀,很想知道自己不能理解的东西,就很好奇 |
19 exip 2019-07-16 20:08:02 +08:00 via Android 能不能查到源 ip 跟搞的事情正相关,搞大事,穿再多条裤子也能给扒的连裤衩都不剩;不搞事情,只穿个裤衩也能保住裤衩。 |
20 lihongjie0209 2019-07-16 20:37:09 +08:00 @SlipStupig 解释一下如何通过 dns 和浏览器查到一个用户 |
21 gam2046 2019-07-16 20:47:52 +08:00 @SlipStupig 三层协议已经没有 Mac 地址,而目标服务器与你之间总不可能是在二层通讯吧?我现在只知道部分特殊用途软件会支持直接在二层通讯,可以不需要 IP 进行通讯,但凡都有 IP 这个概念了,都是三层及以上。 IP 报文里就没有填写 Mac,即使通过 arp 反查,也不是目标服务器能做到的,只有你这边网络接入侧的第一个路由有这个能力。 |
22 exip 2019-07-16 20:59:55 +08:00 via Android 有成熟的技术只需浏览器就能区别出不同的用户 DNS 记录会暴露访问的网站 社工 数据分析 这些综合起来确定用户妥妥的 |
![]() | 23 SlipStupig 2019-07-16 21:02:57 +08:00 @gam2046 不要局限在协议这一侧,还有别的办法的,仔细想一下你就能想通,想不通就当我在胡说八道 @lihongjie0209 我没有义务跟你解释,你也理解不了,而且也不相信,所以你就当我在瞎扯吧! |
24 lihongjie0209 2019-07-16 21:49:47 +08:00 ![]() @SlipStupig 你不说怎么知道我理解不了 最起码浏览器的问题可以直接在虚拟机中操作, 操作之后直接销毁虚拟机. DNS 查询记录哪怕被运营商记录, 也只能记录到代理服务器的 DNS 查询, 追不到本机 |
![]() | 25 li02 2019-07-16 22:07:04 +08:00 via Android @SlipStupig 如果你愿意就解释下吧,给个关键字也可以, |
![]() | 27 gamexg 2019-07-16 22:32:44 +08:00 各种本地软件会记录 mac 地址,至少我知道银行有记录。小心被对比出来。 浏览器预读 dns 解析、webrtc 等功能可能不会经过代理,可能获取到实际 ip。 浏览器还存在一些指纹最终方案。 另外流量特征也是个问题。 |
![]() | 28 zjyl1994 2019-07-16 22:44:17 +08:00 要搞事人先出境,再挂梯子+tor 当然,你得准备一套全新的设备,最好是在境外买的 |
![]() | 30 Buges 2019-07-16 23:33:38 +08:00 via Android @SlipStupig 请讲一讲吧。可能我网原学的不太好,服务器应该没办法。ISP 的话,查路由日志不就好了。和 mac 唯一有关的我只能想到第一跳拨号 mac 被记录,但这个可以 0 成本伪造啊。 @gamexg 如果你从来不用 pc 拨号,只要拨号设备没有运行过 spyware 应该不会有问题。 另外楼上说的其他方面,应用层面也包括浏览器指纹、跨域 cookie 等泄露,确实是薄弱环节。 真要做什么的话,应该在以上做法的基础上,挂马到某几个肉鸡上,定时 7 天 /30 天后在非你所在时区时间执行脚本,这个时间差过去有些日志可能都没了。并且发作时你本人应该有不在场证明(比如在监控下睡大觉)。 以上环节只要有一跳查不到,这个线索就查不下去,你就是安全的。 |
![]() | 31 msg7086 2019-07-16 23:57:38 +08:00 @lihongjie0209 创建一个域名,上面做一个泛解析到你自己的服务器,写一个响应 DNS 消息的服务。 在网页上引用一个这个域名的资源。域名需要随机生成。 当你打开网页的时候,浏览器看到这个随机域名,会根据 whois 记录找到你的 NS 服务器并查询 NS 记录。 这时候服务器就有了随机域名<=>IP 的映射记录了。 前提是客户的 NS 请求不走代理。 |
![]() | 32 binux 2019-07-17 00:05:42 +08:00 via Android @Buges #30 别听他瞎扯蛋,你和他说 IP 代理,他和你说你发帖的时候背后站了个人看到你发了。他就是在偷换概念 |
34 trn4 2019-07-17 02:29:38 +08:00 查是能查,就是成本高。就像犯罪永远无法禁止,只能通过法律提高犯罪成本。当你把查你的成本提高到没人 /组织承受得起,你就是安全的。所有的隐藏自己的方法都是在提高追踪你的成本,想要杜绝是不可能的。 对于你的问题,那就是“高匿”有多高。 |
![]() | 35 SlipStupig 2019-07-17 08:06:58 +08:00 @binux 您说的很对,我就是在瞎扯 @lihongjie0209 您说的很对,我就是在瞎扯 --- @Buges 指纹这种只是一部分,主要用于定向目标,具体看 lulzsec 案例,这里不多说。如果你是单层代理,代理服务器就真的安全吗?还有一些其它水坑和供应链上的方法。至于 MAC 地址设备 ID,这些你想一想你是从哪里获取到这些网络设备(我只能说这么多了,你稍微想一下就能明白了),其实 MAC 真的没有那么在意,还有很多很多可以做虚拟身份 的,但是最终有一个执法成本和收益平衡的问题。至于人被逮到了,不怕你不招,毕竟人家专业就是干这个。 @li02 lulzsec 丝绸之路 |
36 wenxin667 2019-07-17 09:26:36 +08:00 |
37 ryanlid 2019-07-17 09:30:42 +08:00 查代理服务器上日志呀 |
![]() | 38 dai123456 2019-07-17 10:08:13 +08:00 这些都是模糊的问题,只要使用了代理 ip 的话,只要对象想查出来,就能查出来,但是高匿的代理 ip,相对来说隐蔽性会更好一些,需要测试高匿 ip 的可以联系我 |
![]() | 39 ryonanamizu 2019-07-17 10:38:38 +08:00 @xiaopang132 扒出 tor 得控制三个节点全是蜜罐且不设置前置代理。 |
40 Rwing 2019-07-17 11:57:55 +08:00 我用 windows 远程桌面到美国的服务器,然后再请求,这个是属于什么?会暴漏我的 ip 吗? |
![]() | 41 vv0nder 2019-07-17 12:06:39 +08:00 首先你们的想象力真的太局限了,然后还一堆抬杠的,哎!高匿 IP 确实会被查出来的,而且手段很多,高匿 IP 不是绝对的隐匿,只是会屏蔽大部分人的视野。在互联网环境中没有绝对隐匿的 IP。 |
42 zijieq 2019-07-17 12:17:55 +08:00 via Android @xiaopang132 编程随想这么多年也没见被扒出来啊 |
43 Untu 2019-07-17 14:07:27 +08:00 via Android 居然那么多人网络基础都不懂。。。三层查 mac ? |
![]() | 44 8e47e42 2019-07-17 14:33:26 +08:00 装个 360,就算你是外星人也给你扒出来 |
45 scegg 2019-07-17 14:38:41 +08:00 技术不是唯一的。最大的漏洞在用户使用习惯上。 简单说,只要你的浏览器开了允许 JS 或者 flash,或者你的电脑上装了不可信的软件,那么你开几百层都没用的。 纯技术跟踪的话,在大数据面前,定位一个人只看你资源掌握了多少。 |
46 idcspy 2019-07-17 15:53:23 +08:00 前几天那 1024 被抓的几个版主好像用的 tg。 |
49 azh7138m 2019-07-17 16:44:31 +08:00 @msg7086 也不是说 DNS 一定得传递客户端信息吧,有的公共 DNS 为了隐私也不启用 EDNS (也可能是就不支持 @SlipStupig 丝绸之路那是 flash 的漏洞 @Untu > 三层查 mac 我们校内的统一登录是支持的,锐捷的方案,每个 AC 下面是一个大二层网络,认证 web 知道用户 ip,从它的接口获得用户 mac |
![]() | 51 Sor 2019-07-18 09:19:07 +08:00 说的跟真事似的 某博主现在也没事呀 有本事去查 |
52 hamkido2000 2019-07-18 11:02:20 +08:00 via Android @danmu17 怎么检测到是美国的 ip。。。我明明用的法国的 |
![]() | 53 PlushieChicka 2019-07-18 13:24:28 +08:00 不能,现在抓黑客对于老油条来说已经很难抓了,你去看被抓的黑客的复盘很多情况都是通过其他手段来的。 |
![]() | 54 liuminghao233 2019-07-18 14:10:58 +08:00 理论上可以无限套 n 级代理,每套一层会增加查询成本,代理中继超过两次以上,查询成本基本上就无限大了 这样吧,一个简单的两层代理,落地 windows 远程桌面操作,你查给我看? |
![]() | 55 efaun 2019-07-18 15:04:16 +08:00 以上全部为名单 |
56 Untu 2019-07-18 18:20:19 +08:00 via Android @azh7138m 我是做深信服和锐捷代理商,跨三层取 mac 我知道。这个在公网中没有应用也没有什么意义,让运营商查 ip 后面用户更实际一些。mac 在网络安全要求不高的环境中可以起到简单的绑定设备设备的作用,但 mac 可以随意更改,伪造。 |
57 azh7138m 2019-07-18 19:04:45 +08:00 |