论如何取得好成绩
这个专题我记得我将近20年前读大学的时候就看到网上传过这个玩意。核心思想是:高中课程大纲不难,但是高考是竞争性考试,题目会玩出花样,层出不穷的技巧题,陷阱题,坑题,用来提高区分度。脑筋急转弯题目多。所以高中没有好办法,人踩人,人挤人,内卷互害等等。大学课程难度高,知识水平深,但是它不是选拔性考试,而是检测性考试(同时,又没有国家考试的难度。例如公务员考试,司法考试等等,这些考试相对比高考的攀比分数制度要合理,但是它定的标准导致合格率比考大学还难。我看行政能力测试题目纯考智商,比GRE难多了,能考上中国公务员的朋友们欢迎来美国留学),而且考试的自治程度相当高,基本上就是任课老师自己决定怎么搞。这就决定了大学考试本身的不严肃性,和投机取巧的机会。
可惜本人虽然读了这篇文章,却没有认可他的观点,我觉得大学还是多学习,少耍小聪明;结果因为平时成绩不好,在保研出国之类项目上吃尽了苦头,才觉得先人板板搞得这些不道德不学术的玩意,乃是通往道德和学术的捷径。这个世界最基本的原则是道德是权威们制定的,也就是道德准则仅仅是服务于权威们的利益的。好的道德社会就是宗教神权统治式的死板社会,不好的道德社会则是“满嘴仁义道德,一肚子男盗女娼”虚伪腐化社会,官老爷们包着姨太太情妇们,却抓看黄片的小夫妻。所以有英文谚语云:“electrons conduct electricity, morons conduct morality"。至于学术,说穿了,就是一个互相拍同伴肩膀的俱乐部政治。学术圈的公正一面,是学术内容的开放性,没有保密的学术。但是评价标准仍然是小圈子的。让热爱真理的学者们欣慰的是,小圈子们只能垄断评价,但是不能垄断事实本身,因此拨云见日的事情总是会发生的,正如林肯云:“不能永远欺骗所有人”。所以,即使要通往道德和学术,也要走这些不光彩不正路的小把戏。
为何会有突击,大学生平时学习的效率问题。
大学不是高中,有一个固定的目标。有人来大学就是来混四年日子,回去靠父母关系安排工作的;有人出身贫寒,连学费都交不起,来了就要做兼职赚钱;有人还在为高考结果愤愤不平,觉得自己上的学校不好,专业不对;有的人一心想搞学术;有的人一心想出国,等等。
人是社会动物,高中时所有人都是为了高考分数而努力,因此读高中的学生,努力是常见的,想偷懒,看到同学们认真学习的劲头也不敢松。但是到了大学,人心是多种多样的,不可能有统一的目标。因此缺少了peer pressure之后很多人读书也就马虎起来,什么“选修课必逃,必修课选逃”,一个学期也就是最后两个星期上课学习之类的。所以要在大学取得好成绩,难倒是不难,关键是掌握方法。
正常情况下,大学成绩评定虽然不一定有高考的良好区分度,但是也不至于学霸学渣一个样。而因为教学评定是一个反馈过程,开学初老师的计划不等于学期末老师的方案。这也意味着,一开始认真参与教学互动过程对成绩的帮助并不是很大,考前突击对于传统的课程是有很大帮助的。
目标,突击和应试有两个目标:高级目标,搞出高GPA用于保研和出国留学。(出国留学和保研类似,只是流程更长些而已)低级目标,不挂科。不管高级还是低级目标,要点都是在于任课老师,没错,制度的最大弱点就是人的弱点。大学考试不是高考匿名改卷匿名改分的,老师可以轻易的知道是谁提交的考卷。所以和任课老师处好关系是取得高分的必要手段。一个老师都叫不上名字的学生只会取得较为平庸的分数。怎么处关系,请客送礼这种手法不一定讨老师喜欢,毕竟老师又不穷,吃点学生的贿赂估计他都看不起。最好的方法是在老师面前表现好学的一面,多抓住机会和老师交流学习问题,这样混熟了,老师也容易泄题或者给好分数。
同样,低级的也要和人搞好关系,但是就别去找老师了,平时你都不露脸的,老师对你没有印象,你到快考试了再去套磁肯定没有好结果。正确做法是向和老师关系搞得好,成绩也好的同学套磁。这个道理其实对于出国留学申请套磁的也适用。套磁的前提是研究方向匹配,所谓match,match本来就不多,只有凑巧相似的时候才可以套磁。其他情况下套磁意义不大(有些人还写格式信套磁,完全就是垃圾桶预定)。除非已经交了申请费的(交钱表明了强烈兴趣),这时候再去套磁的时候教授不大会直接扔垃圾桶,这时候套磁的主要目的并不是提高录取率,而是在录取之后,你可以有的放矢地准备跟着这个教授做科研,而不是来了再rotation,挨个挨个匹配这边的教授。
在这里对本科同学来说,上课多露面多提问,下课询问老师(不管是当面询问还是电子邮件询问都好),就是很重要的平时套磁工作。人心都是肉长的,特别是为人师表,当然欣赏那些和自己相性符合而且好学的学生。学渣呢,就应该去套这些成绩好和老师关系也处的好的学霸。这样考试完了评分,学霸吃肉,学渣喝汤,各取所需,皆大欢喜。
有些老师很好人,会划重点,每年的考试也就是改改数字就开考,所以还有一点就是和高年级同学联系,问下考试怎么考,历年试卷长什么样。哦,高年级的课程啊?都高年级还来问我这个问题?算了,问问本校保研直博的师兄师姐们吧。
细节操作。参考这里:
https://zhuanlan.zhihu.com/p/38346629
Detecting Probe-resistant Proxies, University of Colorado Boulder
TLS是一种加密隧道协议,它本身不能消除其中流量的non-content fingerprints(NCF),non-content fingerprints包括packet length和timing.
目前GFW对协议流量的阻断,主要通过protocol content(OpenVPN),主动探测(Shadowsocks),以及协议本身的漏洞。在国家级的防火墙上识别TLS的NCF是成本非常高昂的,目前没有明显的证据证明GFW使用这一手段。
当然设计不良的TLS隧道本身有所谓TLS fingerprint的问题,但这可以使用浏览器的协议栈(naiveproxy),uTLS(trojan-go),或者直接使用浏览器转发解决(v2fly) ±
高价值目标担心的不是GFW国家层面的迫害(GFW算力有限不能管太细),而是国家级黑客对其展开的攻防。
本来根本不想对那个人攻击,但是一年下来,从辱妈到攻击伤口,再到曝光私信,再到“阿里萨斯”之类的侮辱性ID出现(活跃了一年之久),再到性侵门事件,再到网警恐吓,还有今年的抹黑,实在忍无可忍。
他们这种就是刘仲敬说的,对付这些人,很难做到瑞士式中立,中立(退让)会被认为是弱小,反而会被群其攻之,使得自己难以站得住脚。你唯一的选择只有主动出击,但是这样做又会变成压迫者的角色。
虫文门July 29, 2021, 3:32am#30
@阿篱Ali
阿里萨斯?愿闻其详。我一直都挺喜欢他的,感觉他也很少主动挑起什么矛盾。
阿篱AliJuly 29, 2021, 3:35am#31
你可以去查一下魔兽争霸的故事,有一个著名人物“阿尔萨斯”,了解了这个人物后,就知道什么意思了。
另外就是他的ID注册时间,正好是去年10月的私信事件后的2天内。
虫文门July 29, 2021, 3:57am#32
了解了这个人物后
太长。不看。
提到阿尔萨斯,我想到的只是经常法国德国反复占领的阿尔萨斯-洛林。
我觉得阿里萨斯很像丁丁兄弟,还有yingzhen251。丁丁兄弟也是那种知识水平一般,但喜欢装逼的。本来这还没什么,至少比2047众弱智的平均水平强,但丁丁兄弟在站务那一块的言论真的恶心死我了,一天到晚用很肉麻的话来舔其他用户,贱不贱啊。
这个还真不能怪它们。她当时是跟学猫叫闹矛盾。而你如果看下学猫叫当时的留言,就会发现确实是学猫叫一直在挑衅她,学猫叫活该被封,不是站方责任。站方也很难办,封学猫叫就不符合程序正义,不封的话就会把豆沙馅气走,最后是把她气走之后才封,这个完全就是...太亏了吧。
在葱膜7迷x五个匿名论坛中,有几个人的破坏力惊人,荣获恐怖分子称号。下面来分析他们的战力:
第六名:东北派克笔
此人先在品葱问一些似是而非的问题,问完就跑,后在品葱和膜乎注册十几个小号,此人虽是恐怖分子,但不主动发起恐怖袭击,其危害仅仅是注册小号。
第五名:阿篱
此人以卖惨著称,有过注册一百多个小号攻击2047的辉煌战绩,骂对方“婊子”,但他在其他几个论坛都没有被赶走,故排第五。
第四名:thphd
此人极擅长PUA,爱好是在其他论坛散布drama,已被多个论坛赶走,与阿篱是冤家。
第三名:虫文门
此人被多个网站赶走,目前只有迷雾通和xsden收留他,骂人能力max。
第二名:天神九头鸟
此人先被品葱赶走,后来在其他几个论坛也都被赶走,可见其不受欢迎程度,注册过多个小号,目前在tg群活跃。
第一名:钢铁雄心
此人注册上千个小号长期骚扰品葱和膜乎,在2047封禁他以后还短暂攻击过2047,战力极强,当之无愧地排名第一。
以上排名可能不准确,有更好建议请留言
当然迷雾通无法仍然避免熵检测,换句话说就是GFW可以对无特征流量一刀切。规避熵检测,可以用最新版的V2Fly+TLS。V2Fly支持浏览器转发,避免了TLS的指纹问题,当然用TLS不能混淆packet length和timing,因此依然可能被识别出是翻墙流量,只是成本会很高。
你研究过NaiveProxy吗?它用了Chromium的栈还是什么协议来着 给Tor设置前置代理(包括VPN)时请确保同时也使用obfs4网桥,否则可能暴露你用前置代理掩盖Tor流量的意图 中说:
NaiveProxy
用这样的代理服务器,老蛤丝了
@admin 我还没用过,因为知名度没有trojan高,没人分享现成的,而且我这几年没自建过梯子
这是写推荐信的么,马良发动自书技能(于是马良就立即起草以他人的口吻给自己写了一封推荐信,孙权看后十分信服,从而恭敬待之。)。当今大学生申请入学外国高校,都要写推荐信,很多中国的老师懒于做此事(或者英文太差),故而会让学生当马良。
关于2047的瑞贝克公开投姨,本人稍微多说几句。
By 九头鸟
其实瑞贝克从一开始就是一个姨粉,在姨葱时期尤为出名,她对姨葱最大的不满,不是姨葱不公平,而是姨葱没把她供起来做人上人,不尊重她这个自以为是大粤国土皇帝。只可惜技不如人,被台湾人妻鹿给彻底卷死了。后期借着小二进监狱的秩序真空,借壳上市,没成想又遇到个自己的同类独派沪国主义者阿篱,被对方连番轰炸攻击后,终于彻底崩溃,人格扭曲,魔怔到现在这个德行。
她这几年被姨粉爆锤攻击直到今天还在被骚扰的经验恰恰说明了一个道理,就是姨粉无法形成任何的自发秩序,伤害她这个网络粤国皇帝最大的恰恰就是抱持和她同类政治观点必须分裂中国的那群人。诸夏教会就是再费拉,也能把她老人家这个清华博士网络粤国凝结核土皇帝搭便车的给彻底踢出了。而能够给她提供秩序提供人气提供批判对象的恰恰是她所一直鄙视的民主统派分子,例如陈士杰这种民运人士。
瑞贝克今天公开站出来为姨粉背书,无非是因为最近少民natasha和陈士杰的是非口角,导致后两位都被撤销管理员身份。但说到底瑞贝克是个姨左,处罚natasha已经突破她能够接受的底线。为此自然要猛烈轰击民运一番。
民运成不了事,姨学更成不了。西方特别是美国无论在什么历史条件下,在近百年中均未支持过中国分裂。这里的中国特指汉地,非如今的大中华。民国北洋时期已经是分裂最容易的时候,美国对中国态度依然是利益均沾,不支持列强分割中国。之后美国支持共产党也好支持国民党也好,不论哪种叙事都没有分裂中国的空间。
除了在认识如今中国社会的问题上具备点有限意义。姨学或者说各类分裂理论从头到尾都是错误的,经济上根本无法实现,民主派在画大饼骗人,姨学画的饼更大,骗人骗的更狠。著名的谎言例如什么:满洲一独立,十年变南韩。上海一独立,十年超香港。事实是,广东一独立,上限不过马来。还是走下坡路的马来。这也是为什么港独死活都不带广府佬,独立只带自己人走的真实原因。对于你国关起门来吹的那些漫无边际的牛逼,别人是一清二楚。而瑞贝克如此反感港独不拿她当自己人,大概率是被别人这实事求是的态度给气冒烟了。
瑞贝克今天挑明了自己的分裂态度其实挺好的,不要再吃民主中国派的秩序,大大方方的宣传姨学理论,划清界限,整天遮遮掩掩,含混不清,搞些似是而非的论述,看似高明,实际上是歹戏拖棚,越演是越难看。
将GFW的一部分负载放在省级网关上,意味着国内流量也要被审核,而由于常年的GFW建设,中国的国际流量远小于国内流量,所以省级GFW的功能恐怕是用来搞类似新疆75断网这一套。现在新疆的墙中墙也就是省级GFW的应用。
省级GFW的价值恐怕是防止失控的国内言论在国内平台上爆发式传播,由于法不责众,数亿中国人实名冲塔的话,山东审查员和中国的监狱警察都会不够用。
里面一个最让我吃惊的是Tor Browser下载文件的时候竟然向系统的临时文件目录写入临时文件(注意是系统的临时目录, 并不是Tor Browser自身的目录), 而且长达8年都没有修复这个看似低级的Bug.
更要命的是只要你点击一个下载链接, 只要弹窗出来就会立刻在系统临时目录所在的磁盘上生成对应的临时文件与数据, 你甚至连点保存都不需要就会留下磁盘痕迹.
whonix用户鹿过
虚拟机回退可破?
@cynthia-varella 简单的傻瓜式虚拟机回退破不了,我完全想不到小白可以执行的靠谱方案。
如果快照数据本身是被可靠程序加密且密钥自身绝对安全,那么敏感操作后销毁密钥就没问题了,否则照样中招。
对全盘扫描的取证软件来说存储在虚拟机内与虚拟机外没去别,就算加密,如果搞到了密钥也还是没区别。
注意密钥自身的绝对安全通常不可能,所以条件允许的情况下除了首先销毁密钥,被加密的数据本身也应该尽可能销毁(考虑到快照本身很小,彻底覆盖所用时间很短)。
此外SSD要注意磨损均衡(无法可靠的覆盖删除单个文件)的问题:https://program-think.blogspot.com/2019/02/Use-Disk-Encryption-Anti-Computer-Forensics.html#head-7
物理机veracrypt全盘加密,不要只用密码管理器或大脑记忆完整密码(不是密钥),应该记住一半,其余部分写在可食用纸上,被抓时吃下去(理论上用溶于水的墨水也可以,被抓时把纸扔到水里,二战时德国海军用此法销毁敏感资料,但不如吃掉方便)
-
支付方式:域名和服务器付款一律用加密货币。先换成XMR,再多开几个钱包,手续费调低些洗几轮。
-
域名:买域名的时候联系方式全部填假的,邮箱也要留全程tor注册的匿名邮箱,否则秒查。除此之外最好打开whois privacy,加大别人调查信息的难度。最后域名的account关闭不安全的密码恢复设置(例如用域名找回密码),打开2FA
-
服务器:服务器要支持加密货币支付,确保完全匿名,再套cloudflare隐藏IP。
-
全程tor:以上操作要全程tor完成,否则用XMR没有意义,从IP地址还是秒查。服务器当做不可靠环境对待,平时SSH维护一律前置tor.
-
隐藏服务器IP:套cloudflare不能保证100%隐藏IP,可以搜搜网上有多少找CDN背后IP的方法。
解决办法:(1) 入站IP设置白名单,仅允许cloudflare回源,防止全网扫描80,443。cf ip见:https://www.cloudflare.com/en-gb/ips/
(2) 在套cf之前不要把网站解析到自己的IP,否则会留下DNS记录
(3) 其它方面注意子域名解析记录,注意mx记录,注意网站本身的漏洞(例如phpinfo)
-
邮箱社工问题:注册域名和服务器要留邮箱,时刻假设邮箱地址已经泄露。中共安全部门最爱用的方法就是邮件钓鱼,最好拒收服务商通知意外的邮件,并且只用纯文本模式读邮件。
-
github社工问题:git在push的时候会默认带上你的系统账户名字和邮箱,如果账户用真名或者Git邮箱和现实身份有管理,也是秒查。
-
服务器安全加固:这个问题说起来太大,概括地说就是:
(1) 加固SSH:禁用root登录,禁用密码登录并启用公钥登录,安装fail2ban。有条件最好打开端口敲门。
(2) 加固Linux内核,包括加固sysconf,安装Linux Kernel Runtime Guard进行内核自我保护,打开heap randomization,shared library offset randomization防止缓冲区溢出攻击等等。
(3) 打开mandatory access control(非常重要)
(4) 其它方面:加固root,passwd,apt conf,sysctl,systemd,setuid,su等等
-
网站防cc:cc不影响网站安全,但是被一打就挂还是很惨。建议:安装应用防火墙,对API做速率限制
-
服务器备份:时刻假设服务器已经不安全,对重要数据每天做异地备份。如果服务器被撤就立刻搬家重来。
全程Tor买域名和服务器比较困难,因为很容易被当作恶意用户封号或限制,稳妥的方式是用三重代理,编程随想介绍过
另外选择靠谱的域名和服务器提供商很重要,对方真要保护你的隐私的话,应该允许通过Tor注册,少要个人信息
找出cf背后IP的方法我试过,没有成功,请帮忙找一下葱膜7迷x的真实服务器IP(划线的不用找)
门罗币本身是匿名的,这没有问题。但是门罗币客户端不支持代理,如果你在中国境内运行客户端,网监就可以看到你在使用门罗币。
这并不是危言耸听,网络管理部门可以很容易查到并且统计哪些国内IP运行加密货币节点,已经有相关报道。可以自行搜索相关新闻。
门罗币是匿名的,因此网警无法知道你的付款地址,收款人的地址,以及支付的金额,但是网警仍然可以通过监控流量知道你的交易时间。如果交易的另一方泄露了交易时间,就可以根据网络活动精确匹配到个人。
需要注意的是,国内会用门罗币的人不多,不要想着把自己隐藏在人群里。只要暴露了流量特征,网警就知道你在用门罗币,再加上交易时间等旁道信息,找到某个人不难。
当然解决办法也是有的。套一个虚拟网卡VPN就可以解决问题,这里不推荐各种让应用走代理的奇技淫巧,很可能导致安全问题。
VPN不能保证匿名,一劳永逸解决安全问题的方法是tor+双虚拟机+前置翻墙,在虚拟机里放XMR客户端。
这里其实真正要限制的是在墙国内部网上大篇幅灌水的行为,因为这样就给了国内的ai大量练习的机会。建议各种文章尽量发外网,不要给墙国ai足够的学习内容。
现在可以说以墙国的大数据,在实名制以后新发表的文章,已经被墙国ai分析过,并且可以用来抓捕任何人。所以你们要做的,是在实名制以后做徐庶,不在墙国发言。
不要没事就升级,除非是高危漏洞,而且请用长期支持版本(当然Debian好像都是长期支持)
所以辱包成了一个高风险,低收益的工作
不过我在想,你们用什么上红迪?有没有身份隔离?
"mohumo辱7“
”怎么辱“
”他把thphd的帖子截了图“
以下发表一下我的看法:
根本上来说是否值得被破获关键还是取决于领导与网警, 只要其中一个下定决心破获, 你就十有八九没得跑了.
这篇文章似乎可以提供一些模糊的借鉴.
总体来说对我们"安全"没有够用, 只要力所能及就应该追求尽可能更高的安全, 而不是不求上进以为已经够用, 这是键治最基本的要求(从某种角度来说我们都是黑客, 突破GFW的IDS, 像黑客一样, 合格的黑客都是永远学习提高自己, 不然只有等着被抓).
就目前观察到的情况, 新品葱这个禁止Tor注册的准(或者真)钓鱼网站有那么多活跃用户说明很少有人被抓, 所以我们不必太过担心自身水平, 只需积极追求安全知识与技能的提升即可(如果心态懈怠又持续高强度键政则被抓是早晚的事情).
游客海本身也是模糊发帖人让我们不值得被破获的重要手段.
毒針嘅其他成分還包括致癌物質,
汽車防凍劑,螢光劑,
墮胎嬰兒組織,
这些都是有的
汽车防冻剂:乙二醇,常用溶剂,致癌物
萤光剂:细胞物质里就有荧光物质
堕胎婴儿组织: 估计是鸡蛋胚胎吧
--但是纳米材料和5G晶片是怎么回事?
--不是英国有人说5g传播肺炎病毒,所以砸5g基站么?
疫苗用的是鸡蛋胚胎
很多疫苗不良反应上说了allergic to egg 的人打了疫苗会发生过敏反应
至于为何是堕胎婴儿,他也没说婴儿是人的啊
多几次二手翻译,不就从鸡蛋变成胎儿了么,英文里卵子就是egg啊,难道还分人鸡?
我的个妈呀,都给你们骚完了。陈士杰一天天老复读有意思吗?给高华说了半天排华,这你娘的不本末倒置吗?还不如去微博上宣传宣传煽动民粹有效果,搁这大妈左比论坛扯犊子, 这不闲得蛋疼?扯来扯去咋实现也不知道,又不跟选民直接接触,还跟斗争对象没事辩论,我你妈一个大傻X就贴你头上。最后的最后炮轰狗管理消极自导自演臊气drama,没得节目效果。
我不否认文章本身写得很好,但这些理由里面,并不包括最多的一个理由:没钱。这个理由比文中列举的那些理由加起来更充分,“贫贱不能移”描述的就是底层穷人根本不具备移民的条件。 (同意,钱能解决的问题不是问题,问题是没有钱)
李克强说过,中国有6亿人月收入1000元,这是血淋淋的事实。这些人纵有移民的想法,由于幸存者偏差,他们不会成为文章里面的讨论对象。他们大多数人没有学历,没有一技之长,在国内只能艰难度日,在国外也只能冒险打黑工,难有出头之日。(这时候就显出了社会自组织的能力了,如果要打黑工,需要的是犯罪组织,温州人福州人偷渡美国,中国蛇头组织人去日本打黑工,参考新宿事件)
投资移民针对富人,工作移民针对学历和能力都很高的人,留学又需要大量学费,即使有些地方免学费或低学费,几年下来也要十几二十万,这笔钱对底层差不多是天文数字。因此移民对底层穷人是遥不可及的梦想,他们甚至连想都不敢想。(来美国读博不要钱,而且年薪也有两万多美元,足够在美国生活了,其他国家的博士也没有谁要钱的)
请注意:移民不是偷渡,偷渡的风险相当高,可谓九死一生,搞不好把自己的命搭进去了,(对大多数人来说)不值得。(偷渡需要黑社会,亚洲人叫蛇头,墨西哥人叫coyote,没有组织是不可能偷渡的)
但是蛇头能够运作,关键不是他们在人员输入国有一套完整的体系,而是他们在人员输出国有体系。
就拿福州附近几个县的偷渡客来说吧。一个青壮劳动力,能干活,但是在福州做事不来钱,外国工资高,那就偷渡吧。不过如果我一个蛇头请他来美国,偷渡的前期费用一堆,他出不起,只能赊帐,赊账要信用,信用得由他们宗族来支付。我也要能接受这个信用,所以我蛇头自己也是福州人,所以知道他们宗族的底细,所以我就垫资把他从中国接到美国来。
到了美国,我给他安排工作,比如去中餐馆后厨做事。工时安排997. 一两年之内他就能把我给他偷渡的费用还清,以后他就自己努力了。行,他就能帮更多同乡同族人出来,而我也不用垫资了,他们先偷渡的人会付钱把后偷渡的人带起来,先富带动后富。所以即使这几十年发展,中美的差距,或者说福州和法拉盛的差距,那是大幅度缩小了,但是还是有福州人愿意偷渡,因为随着差距的缩小,偷渡的费用更加affordable,风险也大幅缩小。
但是现在问题来了,我一个甘肃人,一个宁夏人,和一个河南人,都没什么钱,经济差距和美国法拉盛,差个30-50年,和当年福州人的情况类似了。但是我怎么把他偷渡出来。第一,当地人的宗族势力本来就弱小,没法给出有力的保障,第二,我蛇头也不是熟悉当地秩序的人,没法相信当地长老们对我的承诺。所以没法垫资,用信用铺平前期道路,所以偷渡就不会成功。
在输入国那头,我蛇头没有人脉可以找当地人联系,中餐馆以外还有物流业,物流以外还有建筑工地,建筑工地以外还有农场。只要你肯出卖体力劳动,我们总有需求,但是怎么把你们从索多玛拉出来是个难事。弄不好蛇头就成盐柱子.
云服务器也可以keep data in your hands
说白了就是勤备份。
网站放在云上,云炸,数据炸。
网站放在自己的服务器上,服务器炸,数据炸。自己的服务器炸的几率还高一些。
云上的数据可以做异地备份,把数据库拖下来存到别处。论坛的数据库不过一两百MB,云上的流量以TB计算,还可以选无限流量的服务器,一天备一次并不困难。
服务器托管不管一天备份几次,只能把数据备份在本地,共产党来抄家,连服务器带数据一起抄走。服务器主人的安全都受威胁。
网站放在云上,共产党只能威胁供应商下你实例,抓不到人。带着数据,换一家供应商再起来就是不到几个小时的事。
起底一个两个就算了,天天起,你他妈螺丝起子啊?Fucking Boring,比狗站长消极还没节目效果。就一天到晚顺着俩管理记录意淫编烂文,你他妈人肉他啊,去楼下堵他啊,强奸他啊!爱他就给他你的全部!
如何让你遇见我
在我最有节目效果的时刻
为这
我已向李大师求了五百年
求它让我们结一段尘缘
大师于是把我化作一桶汽油
放在你自焚的广场
阳光下慎重地绽开火花
朵朵都是我前世的盼望
当你燃烧
请你细听
颤抖的肢体是我等待的热情
而你终于升入天庭
在你眼前落了一地的
朋友啊 那不是七十二个左逼
是我膜你的心
娜娜的毛病又犯啦。當初她一怒之下隨便把對面銷號,才搞得自己在品蔥被掛大字報。不過論濫權,杰杰也沒好到哪去,當初揭露他活動時區異常的帖子,就是被杰杰親自銷毀的
thphd給了這兩個人管理權限,純粹是出於她仇蔥恨鹿的關係,導致管理團隊被品蔥淘汰的垃圾給掌控(畢竟她自己就是)
這事兒要解決倒很簡單,只要thphd出來說清楚講明白,陳士杰的言論是不是現代納粹?是的話一概轉區刪帖。否則今天是娜塔莎,明天又是哪個誰誰誰要鬧事。按照杰杰跟娜娜的性格,肯定又手滑不小心封號
thphd現在的態度就是老子我不想管,你是蠢貨他是傻逼,最好你們全員彼此黑單,愛咋咋去。這就是沒有擔當的表現,不肯承擔任何一點責任,反正我做了這麼多事囉,再有問題就是杰杰跟娜娜要自行解決囉,跟我thphd沒關係喏
大概是這樣
「岸英,明天就要去前线镀金了,叔还真是舍不得你啊,今天就给你做几道拿手好菜,为你送行吧。」说着,周恩夹又端来了一盘热腾腾的『狮子头』放在了桌上。
岸英看着一桌子饭菜,感动极了:「叔,谢谢你啊。说真的,我也舍不得叔叔你啊。」
周恩夹坐了下来,端起了酒杯拍了拍岸英的肩膀:「岸英啊,来,干一杯,要知道叔倒不怕你去前线会有什么危险,反正都是在部队后方。就是担心啊,你在那头吃不好喝不好。」
岸英干了酒,脸有些微红,下意识的把手也搭在了周总的肩膀上:「叔,你的厨艺是天下一绝,我吃不上你做的饭菜,也肯定会想你的。」
周恩夹看了看岸英:「岸英,你看这样好不好,叔叔教你做饭菜吧,这样等你上了战场,可以自已做着吃。如何?」
岸英眼中放光:「真的啊?叔,你的手艺可是没传过别人,难道今天要传给我?可明天我就要走了,这一夜的工夫又怎么学得会?」
周恩夹摇着头笑了笑:「哈哈,大侄儿,太复杂的你是练不成了,我今晚就教你一样最简单好学的,叔也经常给你做的-------蛋炒饭。如何?」
岸英把酒一饮而尽:「叔,那太好了咱们赶紧吧。」
话不多说,叔侄二人便走进了厨房,周恩夹手把着手告诉岸英如果炒饭:「大侄儿啊,这蛋炒饭的要领就是要旺火猛炒。切记,别怕有烟,火一定要旺。而且去了部队后方,你要经常练习,方能炒得越来越好呀。」 岸英用心的学着,没一会,便炒出了一盘,脸上乐开了花:「多谢叔啊,等我回来接班以后,定不忘叔叔的这份恩情,让叔叔荣华富贵,不再这般的操劳。别的不用做,就专门为我作饭好了。哈哈哈。」 就这样,教完了炒饭,叔侄二人又小饮了一会,岸英便起身告辞了:「叔,侄儿走了啊,明天还要起早,叔叔你保重。」 送至门前,周恩夹还不忘嘱咐岸英:「大侄,记得到了部队要多练炒饭啊,切记,火要旺,炒得要猛!!」
岸英不停的摆手,满脸感动的泪水:「叔叔放心吧!!」
送走了岸英,周恩夹回到了屋中的办公室,拔通了电话,用起了满嘴的黄冈口音:「喂,壮哉我大美利坚!我是林三虎啊,目标已锁定,部队后方炊烟升起之际,便是行动之时,多派几个中队的B29,全部用凝固汽油弹。」
放了下电话,周恩夹坐在沙发上,望着天花板开始狂笑:「哈哈哈,储君?副总?都得死!!天下,已半入我手!!」
消极可能是一個經營十幾萬小生意的中年油膩個體戶,碰上疫情被迫停業,只能在家翻墻線上泡大媽。
消极答复:
中国时间大半夜地翻墙泡大妈容易嘛?
话说如果双头鸡巴xx是什么呢?
足球爱好者们高喊:齐达内!
袋鼠就有三个阴道两个鸡巴
To go with the two sperm-vaginas, male kangaroos often have two-pronged penises.
There's no pincong but one deer, and she's the messenger of the admin.
鹿儿是反刍动物,有四个胃,第一个胃没有消化液,就是一个草袋子,用来对草进行发酵处理,当我们的鹿儿姐姐看到了新鲜的品葱葱友的时候,她就会一口把葱友们吃下去,装进草袋子里,然后经过各种不可描述的化学反应,葱友们就变成了葱币,被鹿儿姐姐吸收进去,让鹿儿姐姐变得更强壮。
购买域名时,可以泄露信息的点实在太多了,这里说一下哪些地方会泄露个人信息。
- whois记录:在购买域名时留下真实信息,又没有打开whois privacy的,秒查。
- 真实付款方式:用信用卡/PayPal支付的,假如域名商里有中国内鬼,也是秒查
- IP地址:这个很多人不容易注意到。在注册账号和登录下单的时候,域名上会记下你的IP地址。假如域名商里有内鬼,自己又用了真实IP,也有被查到的可能
- 社会工程学攻击:注册域名账号的时候留下自己的常用邮箱/非匿名邮箱,很容易被社工。
- 侧信道攻击:拿着自己的域名到处搜,会在各种地方留下log
这里说一下购买域名时,防范的三个基本原则:
- 打开whois privacy:这样别人查whois,关键信息就会全部隐藏。这是第一道防线。
- 选择靠谱的注册商:有些公司保护客户隐私的意识很差,用不着法院搜查令,只要政府发信问一下,这些公司就把客户资料全交出去了。这方面例子参考雅虎师涛案和最近protonvpn上报资料的丑闻。这是第二道防线。
- 全程匿名:购买域名时全程带tor,如果注册账号需要邮箱,那么注册邮箱的时候也要全程带tor。支付方式必须用加密货币,加密货币必须事先洗过(例如xmr),参考47上的贴子。
在安全问题上我信奉【纵深防御原则】,匿名性的核心是tor+xmr,但其它纵深也不能放弃,例如whois privacy和选择信誉好的域名商。最核心的原则是尽一切办法,增加网警追踪的成本。
一、接下来说说买域名的一些准备工作。
-
价格:除了特殊的高价域名,大多数域名每年的价格在10-12美元。如果选择匿名注册商(后面会谈匿名注册商和普通注册商的区别),价格还会上涨70%左右。如果选择匿名注册商的方案,算上换钱的手续费,每年的域名费用大概需要20美刀。
-
匿名上网工具:主要是Whonix或者Tails(用来运行加密货币钱包),和tor浏览器(用来上网操作)。
-
XMR。这个洗钱教程里有,不再多说。
-
匿名电邮。在域名商注册账号要用到,这个邮箱必须在tor下面注册,邮箱的名字不要和自己有关联,而且不要在其他地方再使用。(否则会被社会工程学攻击)
-
干净的电脑:确保电脑上没有国产软件,最好都是开源软件。
二、如何选域名商
域名商必须支持加密货币支付,否则不考虑。
我把域名商分成两种:普通域名商和匿名域名商。
大多数域名商都是【普通】域名商,例如godaddy,namecheap,gandi,name。有不少普通域名商支持加密货币支付和whois privacy,但隐私保护通常不是这类域名商的重点。
有些域名商主打隐私保护,例如迷雾通站长推荐的flokinet,这种域名商同样支持whois privacy和加密货币。优点是能帮助建站者规避一些法律风险。
美国法律要求域名注册填写真实信息,如果在注册的时候填假信息,理论上注册局可以下你域名。(虽然一般不会有人管)
匿名注册商的所在地通常在美国之外的西方国家,提交到注册局的信息是匿名注册商的信息,法律上完全没有问题。缺点是价格贵50%-70%。
三、拿到域名之后的保护
匿名建站依赖cloudflare反向代理,隐藏服务器的真实IP地址。
如果没有cloudflare反代,服务器的IP地址就会暴露在公网上,轻则服务器被DDoS攻击,重则服务器被黑。知道了服务器IP,中共也可以向供应商要你的个人信息。
有一些方法可以绕过cloudflare,查到服务器真实IP。假如你的站在社会工程学上没有什么漏洞,唯一找到真实IP的办法就是全网扫描80,443端口。有很多工具可以做这件事,例如 censys.io
有一定技术水平的站长,通常会给自己的服务器配置严格的防火墙白名单,只允许cloudflare ip回源。做到这一步已经超过99%网站的安全水平了。
然而防火墙白名单在国家级别的攻击面前非常无力,有一种技术叫做ip spoofling,攻击者可以把ip伪造成cloudflare的地址,绕过防火墙,获得服务器真实ip。
要防御ip spoof,最根本的办法是服务器一侧验证cloudflare客户端证书。你需要把cloudflare证书导入自己的tls设置里,并且只允许持有合法证书的客户端建立连接。
https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/set-up
若是作为刚入门的网站管理员,你或许知道使用 CDN 来避免暴露源站 IP。同时,你或许会采取一些常用措施,诸如:修改源站的 Hostname,对非法请求不返回或返回无关/迷惑类信息。
然而,有些东西容易被忽视,例如“证书信息”。我很确信大多数人在尝试对非法请求返回空内容时,没有注意到证书信息是否也不会同时返回。还有一种容易被忽略的:忽略了默认返回块的配置(在 Nginx 中,如果在客户端请求时没有携带 Hostname,则会返回第一个从配置文件中读取的 server{} 块)。
注:如果你像下面给出的示例那样配置,你可能会觉得「服务端不会返回东西」。然而证书信息还是被返回了。
这是 nginx.conf 中仅存的 SSL 相关的块:
server {
listen 443 ssl;
server_name localhost;
ssl_certificate /root/cert.pem;
ssl_certificate_key /root/cert.key;
location / {
return 444;
}
}
然而证书信息依旧会被返回:
curl -k https://127.0.0.1 -v
* Trying 127.0.0.1:443...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=127.0.0.1
* start date: Feb 12 07:35:46 2020 GMT
* expire date: Feb 13 07:35:46 2020 GMT
* issuer: CN=127.0.0.1
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET / HTTP/1.1
> Host: 127.0.0.1
> User-Agent: curl/7.58.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host 127.0.0.1 left intact
curl: (52) Empty reply from server
在开始正文前,首先要说明一下:如果你需要完全地保护你的服务器 IP 不被泄露,仅仅是做我在本文中提到的部分是远远不够的。安全遵循短板理论。任何疏忽都会导致不可预计的的损失。所以,你需要为自己的安全负责。我在此仅仅是介绍防止源站 IP 泄露的一些方法。如果出现诸如软件设计错误导致的 IP 泄露,本文并不能帮你修正那些错误。
回到正题:如果你非常完全地、幸运地解决了其它任何可能会导致 IP 泄露的问题,那总的来说,攻击者只能通过模仿普通用户请求,扫描(请求)所有可能的 IP,并根据返回的结果进行判断。在大多数情况下,你可以借由 IP 白名单来屏蔽它们的扫描,但这是要视情况而定的。你很可能不知道 CDN 用于请求你源站服务器的 IP 范围,或者这 IP 范围是在持续变化的。使用这种策略可能会导致服务中断。
概要
- IP 白名单
- 修改 Hostname/监听端口
- 防止泄露证书信息(针对非指向性性扫描)
- 你的源站域名信息不会被列入到基于此建立的通用数据库
- 如果可能,请修改 Web 服务器(如:Nginx 等)监听的端口
- 请务必设置默认返回规则
- 通过伪造成其它真实存在的网站/CDN 节点来混淆视听
- 通过伪装成其它自制网站/返回空内容来屏蔽非法请求
- 需要结合 CDN 服务商提供的策略来完成
- 客户端证书验证作为非常见策略也是其中一种方法
- 结论
如果你在阅读过程中感到困惑,你可以先查看结论部分中的流程图,然后再继续阅读。
策略
在下文阐述中,全部假定使用 Debian/Ubuntu 作为操作系统,使用 Nginx 作为 Web 服务器。
IP 白名单
事实上,最直接、有效率阻止源站 IP 泄露的方法就是设置 IP 白名单。如果你能这么做,那就这么做。不过,请注意以下事项:
-
如果 CDN 服务商并没有提供他们使用的 IP 列表,请不要使用此方案,不然可能会造成服务中断。
-
如果你使用 HTTPS 作为回源协议,那么你应当使用 iptables 而不是 Nginx 内置的 access module,否则攻击者依旧能通过探测证书 SNI 信息来找到你的源站服务器;
-
在使用 Cloudflare 作为 CDN 的情况下,仅仅通过使用 IP 白名单可能会给攻击者机会绕过 Cloudflare 的保护找到源站服务器 IP。
如果你正在使用 iptables,请记得安装 iptables-persistent,不然你可能会在重启的时候丢失你的过滤规则:
apt-get install iptables-persistent
使用 iptables 对非白名单 IP 丢弃请求的示例:
修改 Hostname/监听端口
通常来说,带指向性的扫描器会对所有 IP 的常规端口进行带 hostname(也是你的网站域名)的扫描(http/80, https/443)。所以你如果修改 Hostname 或修改监听端口,通常就能避免这些扫描。
通过自定义请求回源站时使用的 Hostname/域名,可以防止攻击者通过 Hostname 找到你的源站 IP
一些 CDN 服务商支持设置自定义回源端口
然而,如果你不小心通过某种方式让攻击者知道了你回源用的 Hostname,或者你使用的 IP 范围,你的源站 IP 还是有被发现的风险的。所以请自行注意。
防止 SNI 信息泄露的补丁
阻止 SSL 握手的意图是防止在非指向性扫描的情形下,证书 SNI 信息的泄露(也可以简单认为是域名信息)。同时,在完成扫描后,攻击者(发起非指向性扫描的人)可以建立一个基于「网站/域名—IP」关系的数据库便于日后快捷检索。
证书内包括的域名信息,攻击者可以据此获知有什么网站正在运行(虽然不一定确实有在运行):
如果你的 Nginx 版本高于等于 1.19.4,你可以使用 ssl_reject_handshake 特性来防止 SNI 信息泄露。否则的话,你还是需要安装 strict-sni 补丁。
注:这项措施仅当在你使用 HTTPS 作为回源协议时才有效。如果你只是想使用 HTTP 作为回源协议,你可以单纯地在默认 server 块中使用 return 444;
,并且这一小段中的其它部分你可以直接跳过,或仅仅时略读即可。
SSL_REJECT_HANDSHAKE 的配置 (NGINX ≥ 1.19.4)
对于配置 ssl_reject_handshake,涉及两个部分:默认块、常规块。
server { # 如果使用了错误的 Hostname,SSL 握手会被拒绝
listen 443 ssl;
ssl_reject_handshake on;
}
server { # 对于携带正确 Hostname 的请求,服务器会继续做后续处理
listen 443 ssl;
server_name example.com;
ssl_certificate example.com.crt;
ssl_certificate_key example.com.key;
}
这个方法仅适用于 Nginx 大于等于 1.19.4 的情况。否则要想达到阻止 SNI 信息泄露的目的,你需要安装strict-sni 补丁。这个补丁是由来自南韩的 PHP 开发者 Hakase 开发的,该补丁可以使 Nginx 在 1.19.3 之前的实例针对非法请求真正地空返回。
安装 STRICT-SNI 补丁的步骤 (NGINX ≤ 1.19.3)
首先,安装必要的安装包:
apt-get install git curl gcc libpcre3-dev software-properties-common \ build-essential libssl-dev zlib1g-dev libxslt1-dev libgd-dev libperl-dev
然后,在 OpenSSL 的发布页中下载你想使用的版本。
下载仓库 openssl-patch:
git clone https://git.hakase.app/Hakase/openssl-patch.git
基于你之前选择的 OpenSSL 版本,先切换至 OpenSSL 源码的目录,然后为 OpenSSL 打上相应版本的补丁:
cd openssl patch -p1 < ../openssl-patch/openssl-equal-1.1.1d_ciphers.patch
来自开发者的备注:OpenSSL 3.x 版本有很多 API 上的改动,对于这些 OpenSSL 版本来说,这个补丁不再有用。(特指:Chacha20 和 Equal Preference 补丁)在条件允许的情况下,推荐使用 OpenSSL 1.1.x。
下载你所需版本的 Nginx 安装包。
解压 Nginx 安装包,切换目录至 Nginx,然后为其打上补丁:
cd nginx/
curl https://raw.githubusercontent.com/hakasenyang/openssl-patch/master/nginx_strict-sni_1.15.10.patch | patch -p1
在 Nginx 的配置指令中指定 OpenSSL 的目录:
./configure --with-http_ssl_module --with-openssl=/root/openssl
重要:在实际的实践中,仅使用这些参数并不能真正使网站如预期一样运行,你需要同时添加你想要和你需要的参数。例如:如果你想要你的网站支持 http/2 协议,则需要添加 --with-http_v2_module
参数。它不会主动自己把自己编译进去。
如果你意图针对非针对性扫描,相对于返回空信息,想要把自己的服务器伪装成其它真实存在的网站,以达到给扫描工具假信息的目的,你可以再添加下述参数:
./configure --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-http_ssl_module --with-openssl=/root/openssl
注:这部分是指代概要部分中「通过伪造成其它真实存在的网站/CDN 节点来混淆视听」的这一节,目的仅仅是给予发起非指向性扫描的人假信息。对于指向性扫描,它很难很好地达到目的。如果你只是想要对非授权客户端返回一个假网站,例如:手工制作的假网站、设置反向代理等等(同时也对非指向性扫描器返回空结果),你应当跳过这个部分,或者仅仅将这些参数视作「以待后用」添加。
在完成配置后,编译并安装 Nginx。
make && make install
安装到这里就结束了。
出于方便,我个人习惯会在安装完毕后执行以下参数:
ln -s /usr/lib/nginx/modules/ /usr/share/nginx
ln -s /usr/share/nginx/sbin/nginx /usr/sbin
cat > /lib/systemd/system/nginx.service <<-EOF
[Unit]
Description=The NGINX HTTP and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target
[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true
[Install]
WantedBy=multi-user.target
EOF
systemctl enable nginx
配置 STRICT-SNI 补丁的步骤 (NGINX ≤ 1.19.3)
和之前提到的 ssl_reject_handshake 的配置类似,有三个元素需要被配置:
- 控制开关
- 假的(默认)server 块
- 常规 server 块
http {
# 控制开关
strict_sni on;
strict_sni_header on;
# 假的(默认)server 块
server {
server_name localhost;
listen 80;
listen 443 ssl default_server; # "default_server" 需要被写在这里
ssl_certificate /root/cert.crt; # 可以为任意证书
ssl_certificate_key /root/cert.key; # 可以为任意证书
location / {
return 444;
}
}
# 常规 server 块
server {
server_name normal_domain.tld;
listen 80;
listen 443 ssl;
ssl_certificate /root/cert.crt; # 你的真实证书
ssl_certificate_key /root/cert/cert.key; # 你的真实证书
location / {
echo "Hello World!";
}
}
}
现在,非指向性扫描器不再能获知你在这台服务器上运行什么网站了,除非是被指向性扫描,也就是对方知道你的 Hostname 的情况。
注:使用 return 444;
意味着在返回 HTTP(并非 HTTPS)请求时就是字面意义的什么都不返回。如果没有打上 openssl-patch 补丁,当客户端尝试建立 TLS 链接时,证书信息仍会被返回。
重要:在设置 strict_sni on;
后,CDN 节点若在请求源站时不携带 SNI 信息,将会导致请求失败。参见 proxy_ssl_name.
结果
在开启对应选项后,证书信息不再会被返回。
启用前:
curl -v -k https://35.186.1.1
* Rebuilt URL to: https://35.186.1.1/
* Trying 35.186.1.1...
* TCP_NODELAY set
* Connected to 35.186.1.1 (35.186.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=normal_domain.tld
* start date: Nov 15 05:41:39 2019 GMT
* expire date: Nov 14 05:41:39 2020 GMT
* issuer: CN=normal_domain.tld
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET / HTTP/1.1
> Host: 35.186.1.1
> User-Agent: curl/7.58.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host 35.186.1.1 left intact
curl: (52) Empty reply from server
启用后:
curl -v -k https://35.186.1.1
* Rebuilt URL to: https://35.186.1.1/
* Trying 35.186.1.1...
* TCP_NODELAY set
* Connected to 35.186.1.1 (35.186.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, Server hello (2):
* error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name
* stopped the pause stream!
* Closing connection 0
curl: (35) error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name
谨防不知道,你应当了解:无论你后续怎么配置客户端校验规则(如 HTTP 头信息校验等),客户端在请求时携带目标/部署在服务端的 Hostname 时,证书信息仍会被返回。这是因为它的作用仅仅是预防非指向性扫描:这是建立在攻击者保护知道这台服务器上运行着什么网站的前提上的。如需应对指向性扫描,我强烈建议在条件允许的情况下修改在源站服务器上部署的 Hostname。
使用错误的 Hostname 请求时的结果:(证书信息不会在 Hostname 错误的情况下返回)
curl -v -k --resolve wrong_domain.tld:443:35.186.1.1 https://wrong_domain.tld
* Added wrong_domain.tld:443:35.186.1.1 to DNS cache
* Rebuilt URL to: https://wrong_domain.tld/
* Hostname wrong_domain.tld was found in DNS cache
* Trying 35.186.1.1...
* TCP_NODELAY set
* Connected to wrong_domain.tld (35.186.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, Server hello (2):
* error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name
* stopped the pause stream!
* Closing connection 0
curl: (35) error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name
使用正确的 Hostname 请求时的结果:(仅在 Hostname 正确的情况下,证书信息才会被返回)
curl -v -k --resolve normal_domain.tld:443:35.186.1.1 https://normal_domain.tld
* Added normal_domain.tld:443:35.186.1.1 to DNS cache
* Rebuilt URL to: https://normal_domain.tld/
* Hostname normal_domain.tld was found in DNS cache
* Trying 35.186.1.1...
* TCP_NODELAY set
* Connected to normal_domain.tld (35.186.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=normal_domain.tld
* start date: Nov 15 05:41:39 2019 GMT
* expire date: Nov 14 05:41:39 2020 GMT
* issuer: CN=normal_domain.tld
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET / HTTP/1.1
> Host: normal_domain.tld
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.17.5
< Date: Fri, 15 Nov 2019 05:53:19 GMT
< Content-Type: text/plain
< Transfer-Encoding: chunked
< Connection: keep-alive
<
abc
* Connection #0 to host normal_domain.tld left intact
通过伪造成其它真实存在的网站/CDN 节点来混淆视听
借由此策略,你可以通过传递假信息,以使得扫描者建立起存在错误信息的数据库。你可能想欺骗非指向性的扫描器,使其认为你的服务器是 CDN 节点服务器;你也可能同时想将你的真实站点混入其中,使得存在指向性的扫描器无法区分你的服务器究竟是 CDN 节点还是源站服务器……
个人来说,我不是很想用这种策略,因为它需要我考虑很多因素:真正的 CDN 会使用的 IDC 服务商(并把我的网站部署在相同的服务商)、其使用的 IP 对应的 AS 名称、其开放的端口、附加的头文件信息等等,以确保攻击者对此困惑。这个过程是非常烦人的。
重要:如若可能,你应当将 HTTPS 作为唯一的回源协议。如果不能,你需要注意 HTTP 端口的行为特征。例如:你想要伪装的目标服务器/网站总是会把 http/80 端口的请求转跳至 https/443,但你没有对你的网站做相同的事情。
注:实际上,伪装成 Cloudflare 的 CDN 服务器算是不上不下的选择。因为就算我们能在官网找到 Cloudflare 的 IP 范围,也是你可能会认为 Cloudflare 仅仅会使用这些 IP 的原因。然而,那些现存实际正在运行 Cloudflare 节点应用,但并没有使用 IP 列表中的 IP 地址的服务器是存在的(或者这些服务器只是在运行正向代理服务,如我将在描述的做法一样)。曾有一次,我执行了一次扫描操作并找到了一些没有使用 Cloudflare IP,但却做着我上面所说事情的服务器。所以,伪装成 Cloudflare CDN 服务器这个主意也算是个主意——因为你确实无需真的要拥有/使用 Cloudflare 的 IP 段。
然而,这么做也不是什么好的选项,这是因为你必须使用为你真实的网站部署自建(包括自签和非自签)的证书。然而我们知道,大多数 Cloudflare 用户都使用由 Cloudflare 签发的证书。如果你想把自己的服务器伪装成 Cloudflare 的 CDN 服务器,请想清楚你是出于什么目的要这么做。
配置
关于安装 ngx_stream_module 的步骤已在之前安装 strict-sni 的步骤里提到,如果你忘记了,可以回去看看。
在本配置文件中有 3 个要点:
- 在 http 块中,为 http/80 端口配置的伪装/默认块;
- 在 stream 块中,为 https/443 端口配置的伪装/默认块;
- 为你真实的域名/网站而设置的到后端的路由块。
配置文件示例:
load_module "modules/ngx_stream_module.so";
http{ # 给自己 DIY 下 http 块
server {
listen 80 default_server;
server_name localhost;
location / {
proxy_pass http://104.27.184.146:80; # 伪装成 Cloudflare CDN 节点服务器
proxy_set_header Host $host;
}
}
server {
listen 80;
server_name yourwebsite.com; # 如果你设置 https 作为唯一的回源协议,你不应该在 http{} 块中配置关于你真实域名的块,就像这里(除非你是监听在 localhost 而不是公网 IP)
location / {
proxy_pass http://127.0.0.1:8080; # 你的后端地址
proxy_set_header Host $host;
}
}
}
stream{
map $ssl_preread_server_name $name {
yourwebsite.com website-upstream; # 你的真实网站路由
default cloudflare; # 默认路由
}
upstream cloudflare {
server 104.27.184.146:443; # Cloudflare 的 IP
}
upstream website-upstream {server 127.0.0.1:8080;} # 你的真实网站后端
server {
listen 443;
proxy_pass $name;
proxy_ssl_name $ssl_preread_server_name;
proxy_ssl_protocols TLSv1.2 TLSv1.3;
ssl_preread on;
}
}
结果
它将返回携带其它网站真实存在的证书的内容:
curl -I -v --resolve www.cloudflare.com:443:127.0.0.1 https://www.cloudflare.com/
* Expire in 0 ms for 6 (transfer 0x55f3f0ae0f50)
* Added www.cloudflare.com:443:127.0.0.1 to DNS cache
* Hostname www.cloudflare.com was found in DNS cache
* Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55f3f0ae0f50)
* Connected to www.cloudflare.com (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: businessCategory=Private Organization; jurisdictionC=US; jurisdictionST=Delaware; serialNumber=4710875; C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=cloudflare.com
* start date: Oct 30 00:00:00 2018 GMT
* expire date: Nov 3 12:00:00 2020 GMT
* subjectAltName: host "www.cloudflare.com" matched cert's "www.cloudflare.com"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert ECC Extended Validation Server CA
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55f3f0ae0f50)
> HEAD / HTTP/2
> Host: www.cloudflare.com
> User-Agent: curl/7.64.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 200
HTTP/2 200
< date: Tue, 06 Oct 2020 06:26:50 GMT
* Connection #0 to host www.cloudflare.com left intact
(成功伪装成其它网站,部分结果已省略)
注:如果你知道已知的非指向性扫描器的 IP 范围,你可以将它们全部拦截,权当是再上一层保险。这里给出 Censys 扫描器的 IP 范围:
162.142.125.0/24
167.248.133.0/24
74.120.14.0/24
192.35.168.0/23
通过伪装成其它自制网站/返回空内容来屏蔽非法请求
在开始本部分前,你应当了解这个策略仅能在 CDN 节点可以返回区别鱼正常用户不同内容的前提下才能进行。下面是个例子:
在 GCP 中的回源 HTTP 头信息设置项
HTTP 头信息校验是一种常见的验证请求是否来自 CDN 节点的方式。
注:GCP(Google Cloud Platform) 的 HTTP 负载均衡服务提供了一个选项,可设置在源站服务器向 GCP CDN 节点接收请求时,GCP CDN 节点应额外给出的请求头信息。1这使得源站可以根据将请求从普通/恶意客户端中区分出来。
注:在部分产品中,有些工程师喜欢在节点服务器请求源站服务器时添加一些头信息用于 debug。然而由于他们并非是出于添加特性而这么做的,所以这也不会出现在他们的产品文档中(例如:CDN.net),客服也对此不知道。如果你想找寻在你使用的 CDN 产品中是否有什么特殊头信息,好的做法是:写一个简单的脚本来导出收到的全部头信息。这里就不具体展开了。
配置文件很直观,无需解释。
若想不作返回时的配置文件:
server {
listen 80;
server_name yourdomain.com;
if ($http_auth_tag != "here_is_the_credential") {
return 444;
}
location / {
echo "Hello World!";
}
}
若想返回虚假的网站/后端时的配置文件:
server {
listen 80;
server_name yourdomain.com;
if ($http_auth_tag != "here_is_the_credential") {
return @fake;
}
location / {
echo "Hello World!";
}
location @fake {
root /var/www/fakewebsite/; # 强烈建议自己 DIY 一个假站点
}
}
注:如果你倾向于在 https/443 端口上配置这些,我推荐你使用未知域名自签证书。使用真实且域名为公共暴露的域名可能会让攻击者更容易找到你的源站。Nginx 允许你在 SNI 信息不匹配 server_name 的情况下使用证书。
__重要:一些人可能会认为使用公共暴露域名的子域名的真实证书,而且还很可能使用 Let's Encrypt 来获取免费证书。我希望你能留心一下证书透明度这个东西。它能获知特定域名下你有哪些证书。特别地,Let's Encrypt 会递交所有其签发的证书至证书透明度日志(CT Log)。(参考:源信息, 存档)
如果你想要知道你的证书是否被收入至证书透明度日志,你可以访问crt.sh。
如果你无法确定你签发证书所依赖的 CA 是否会递交所有其签发的证书至证书透明度日志,你最好还是自签证书。
自签证书的指令如下:(为 yeet.com 自签证书的过程)
cat > csrconfig.txt <<-EOF
[ req ]
default_md = sha256
prompt = no
req_extensions = req_ext
distinguished_name = req_distinguished_name
[ req_distinguished_name ]
commonName = yeet.com
countryName = SG
[ req_ext ]
keyUsage=critical,digitalSignature,keyEncipherment
extendedKeyUsage=critical,serverAuth,clientAuth
subjectAltName = @alt_names
[ alt_names ]
DNS.0 = yeet.com
EOF
cat > certconfig.txt <<-EOF
[ req ]
default_md = sha256
prompt = no
req_extensions = req_ext
distinguished_name = req_distinguished_name
[ req_distinguished_name ]
commonName = yeet.com
countryName = SG
[ req_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
keyUsage=critical,digitalSignature,keyEncipherment
extendedKeyUsage=critical,serverAuth,clientAuth
subjectAltName = @alt_names
[ alt_names ]
DNS.0 = yeet.com
EOF
openssl genpkey -outform PEM -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out cert.key
openssl req -new -nodes -key cert.key -config csrconfig.txt -out cert.csr
openssl req -x509 -nodes -in cert.csr -days 365 -key cert.key -config certconfig.txt -extensions req_ext -out cert.pem
考虑到有人可能会拿这些指令生成 csr 用于申请真实证书,我保留了国家的字段(部分 CA 在接收 csr 文件时要求这个字段需要存在),如果不需要可以自行删除。
重要:自签证书可能会增加中间人攻击的风险,除非底层设施是可信的,或 CDN 服务商支持请求源站时携带客户端证书,在 Cloudflare 中又称经过身份验证的源服务器拉取(Authenticated Origin Pulls)。
在 Cloudflare 中启用“经过身份验证的源服务器拉取”3
客户端证书校验也是一种验证请求是否来自 CDN 节点的方式。只有少数的 CDN 服务商支持在回源请求时携带客户端证书。无论是哪家服务商具有此特性,在你的服务器上的配置几乎都是一样的。下面是示例:
listen 443;
ssl_certificate /etc/nginx/certs/cert.crt;
ssl_certificate_key /etc/nginx/certs/cert.key;
server_name yourdomain.com;
ssl_client_certificate /etc/nginx/certs/cloudflare.crt;
ssl_verify_client on;
error_page 495 496 = @444; # 用于在出现客户端证
书校验相关错误时,用自行指定的内容替代默认的错误返回信息
location @444 {return 444;}
location / {
echo "Hello World!";
}
}
此配置将会在遇到客户端证书错误时不作返回
注:伪装成其它网站/后端也是可行的,只需简单模仿“HTTP 头信息校验”部分中的配置文件即可。
重要:无论你使用何种方式,请注意“默认返回”。使“默认返回”和在遭遇非法请求时的返回一致。
使默认和针对非法请求的返回一样都是不作返回:
server {
listen 80 default_server;
listen 443 ssl default_server;
ssl_certificate /etc/nginx/certs/cert.crt;
ssl_certificate_key /etc/nginx/certs/cert.key;
server_name localhost;
location / {
return 444;
}
}
结果
curl http://127.0.0.1:80
curl: (52) Empty reply from server
curl -k https://127.0.0.1:443
curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)
结论
简单来说,要防止你的源站 IP 不被探测到,你可以:
- 在可能的情况下,设置 IP 白名单
- 尽可能地修改源站 Hostname 和监听端口
- 为不匹配的 Hostname 设置默认返回
- 为匹配的 Hostname 设置验证方式
- 放下身段去设想扫描器的视角,观察服务器的行为
整个过程可粗略地画作下方的流程图:
这篇文章和其中所有原创制图/作品以 CC BY-SA 4.0 的形式授权。转载请保留英文版本的链接,如需转载中文版需同时保留英文版本和中文版本链接。
我在以中文重写的过程中已经尽量规范用词和避免双语歧义,并尽可能使用中文语言的网页作为外链,但如果依旧存在冲突,请以英文描述为准。
作者:风间诗音
thphd:講下個人經驗。
-
想人多,服務態度要好。我另一個acc講唔到野,亦無法發PM俾admin,答呢道題嘅唯一方式係開新acc
-
想人多,要注重social,讓大家有歸屬感。people should be able to make friends on your platform.
we simply ban everyone from our platform who's incapable of making friends with others. that's how we got where we are today.
-
想人多,討論要有建設性,唔好成日嘈天巴閉。talk reason stay, ad hominem leave. 呢一項對mod要求極高。
-
唔使刻意找話題(好似亞侵咁開一堆話題系冇用),講身邊事就得喇。users are human, they won't invest if you don't invest
-
唔好養狗。
-
唔收集數據唔係賣點。pincong夠話唔收集數據咯,又唔見你去pincong
-
考試難度太高。考粵語、考香港政治,只要你地過到,我就過到。但你地又唔歡迎我,你地歡迎嘅人又話過唔到,咁考試仲有乜意義呢
-
四圍宣傳其實冇乜用,我地發展新會員主要都系靠google. you need quality content from quality users.
-
唔好因為觀點立場隨意落人地friend link. 拜登論壇新開一個月,人氣高過x登,因為我首頁廣告送人過去。迷霧通論壇ban我account,我依然繼續首頁廣告送人過去。