Everything you care about in one place
Follow feeds: blogs, news, RSS and more. An effortless way to read and digest content of your choice.
Get Feederwechat2rss.xlab.app
安全小黄鸭
Get the latest updates from 安全小黄鸭 directly as they happen.
Follow now 16 followers
Latest posts
Last updated 30 days ago
【招聘】入侵对抗工程师/专家！上海or北京！
about 2 years ago
吃瓜群众 2023-03-01 15:08 北京 上海or北京 等你来！ 入侵对抗工程师/专家岗位职责：负责美团安全攻防能力建设，包括但不限于日志/漏洞/后门分析及逆向，安全事件响应调查，安全检测策略和模型的开发设计，安全评估/渗透测试。岗位要求：1.2年以上工作经验，熟悉网络安全攻防技术和工具，熟悉常见的Web/系统安全漏洞及原理；2.有丰富的应急响应，事件调查经验，熟悉各类安全日志（如Web访问，操作系统，安全设备等日志)；3.熟悉Linux/Windows系统原理，并能以Linux/Mac作为工作平台；4.熟悉至少一种编程语言，如Python，C，Java，GO等；5.熟悉业界安全攻防动态，追踪新的安全漏洞，能够分析漏洞原理和实现POC编写；6.能够无障碍阅读英文技术Paper；7.热爱安全工作，具备优秀的逻辑思维能力，对解决挑战性问题充满热情，善于解决问题和分析问题。具备以下优先：1. 有互联网公司安全工作经验者优先；2. 有大型网络渗透经验和CTF竞赛经验者优先。岗位亮点：1. 美团自身可提供中大型企业级运营平台和基础设施，可满足各类不同企业安全方向的研究需求；2. 可以接触到安全运营，应急响应，漏洞研究，入侵溯源，情报分析等多个企业安全领域，有充足的学习机会。更多岗位点击查看原文跳转！ 阅读原文...
???与入侵检测的二三事儿
over 2 years ago
原创 Fr1d4y 2022-08-26 15:13 北京 如何从从扫描器萌新，成长为入侵检测的“青年”油条？ 总结毕业后的六年经历，从扫描器萌新，到入侵检测的“青年”油条，希望能对各位有一些参考价值。一、扫描器18年的夏天，我毕业刚满两年。每个工作日都沉浸在代码里，在扫描器的世界里挥斥方遒，poc数量和漏洞成果都越积越多，工作充实但内心的空洞却越来越大。在机械化重复的工作间隙里，我一直在思考几个问题。我是怎么走上这条路的？我没有主动选择过，但机缘巧合之下，全身都被贴满了扫描器的标签。实习的时候被安排的第一个任务是内网端口扫描，毕业后第一份工作是维护商业扫描器，后来变成自己来写扫描器。看似在不断进步——从一个模块，到整体维护，再到重构，实际上却被重复工作填满，个人成长非常有限。我真的想做扫描器吗？最一开始的时候想做，刚毕业的萌新眼里，哪里都蒙着神秘的面纱，什么都想学。但真的花了两年摸了一遍之后，祛魅环节完成，扫描器就如同墙上被拍扁的蚊子血，失去了光彩。这条路还有发展潜力吗？当然有，可以优化架构减少重复工作，也可以深入底层代码原理做性能优化。但我不想成为架构师，再继续下去，代码能力会成为束缚而非助力。是时候换一个方向了。寻觅良久，我盯上了HIDS——功能复杂繁多，历史积淀与未来发展并存，是一个绝佳的、值得深入研究的工作方向。二、转职“转职”的过程并不顺利，我原本想在Q公司内部转方向，但我所在的团队讲究“孤狼”文化：一两个人负责一个小项目，快速迭代出成果。HIDS实在不是一两个人短期内能完成的项目，数据采集和安全分析是两块儿巨大的蛋糕，很难一口吞下。于是我离职换了工作，本以为到了K公司会柳暗花明又一村，结果变成了更孤的狼。总归还是做了一些努力：开发能力不过关，那就用开源系统OSQuery；没有数据分析能力，那就从头开始学。结果还是不如人意，OSQuery虽然省去了很多工程化的工作，但各公司的基础环境不同，推动的时候遇到了非常多的阻碍，稳定性问题频发，覆盖率也一直上不去；数据分析学了一些，但巧妇难为无米之炊，没有数据谈何分析？后来我离开K公司的时候，HIDS的部署量大约还剩百十来台机器，惨惨淡淡凄凄凉凉。再往后K公司也招了几位专业的研发同学，完全抛弃了OSQuery那一套东西，纯自研迭代了几轮之后也全部覆盖上了，不过这就已经是后话了。在最迷茫的时候，我看到了一篇文章——《浅谈大型互联网的企业入侵检测及防护策略》，条理清晰、深入浅出的讲解了入侵检测中遇到的种种困境及解决思路。所以，毕业第四年，第三份工作，我选择了M公司。高中的时候有一位老师说过一段话，让我至今记忆犹新：“学习，是一个先把书读厚，再把书读薄的过程” 。读厚是指深入理解书里的原理，每页里都有厚重的故事；而读薄是指将技巧融汇贯通，摒弃招式，形成“方法论”，便能举一反三掌握各种变形。这篇文章便是一本书，来到M公司后，我先将书读厚，书里每一句精炼概要的道理，我都在工作中不断经历、实践，所以知其然知其所以然；而后将书读薄，抽象方法论，万变不离其宗。接下来便是我在M公司的“读书”小记。三、基建来M公司前，我以为HIDS的迭代路线是这样的：先把HIDS Agent该做的功能做的八九不离十，然后慢慢的灰度铺开，发几个版本修复bug，就可以开始写检测规则了。而我入职的岗位职责之一就是“写规则”，推导一下，那Agent大概成熟度已经很高了，一定是在持续稳定的采集???类数据，就等我去分析建模了。所以当我入职没几天，就发现HIDS Agent是全量挂掉的状态的时候，内心是有点儿噩梦重现的恐惧感的。尤其是挂掉的原因，又是稳定性问题——HIDS依赖的中间件故障。类似的问题，我在K公司定位了好几个月都没有解决…但噩梦还没来及展开，就光速结束了。M公司内部建设HIDS实际有两个团队，将基建与数据分析拆分开，专业的人做专业的事情。全量停机的问题看起来严重，但在专业的研发同学眼里，并不是关键的技术瓶颈。大约两三周之后，问题修复，Agent重新灰度上线。后来类似的事情又发生过几次，每次的原因都不尽相同，比如资源超限对业务产生影响、逻辑错误导致bug等等，在专业靠谱的研发团队支撑下，也都平稳度过，极少发生全量回滚/下线的情况。（研发团队指路->《保障IDC安全：分布式HIDS集群架构设计》）当然除了稳定性问题，Agent的采集能力也与我想象中的“八九不离十”相差甚远。Agent早期存在非常多的数据质量问题，比如数据关联错误、短进程数据丢失、采集逻辑不全面等，每个问题都难以预知，也对后端的数据分析有非常大的影响。数据源的问题很难一次性全部暴露出来，通常是在数据分析到一半的时候才发现问题，有时候还会影响很大。比如数据关联错误的问题，业务逻辑是A进程访问某敏感文件，但是错误关联成了B进程访问敏感文件，让行为模型的误报量飚高，只能等Agent修复后，模型的误报量才能到达上线标准。当时定位问题的过程也非常坎坷，是否取错需要人工判断，而取错又是小概率事件无法稳定复现，代码层面上看不出问题，摸黑改了一次效果有限。而Agent变更可能会影响业务，所以灰度的周期很长，每次修改验证都动辄以月计，模型的进展也阻塞在这里，情况非常紧张。无奈之下，我们用“大数据”找了一批复现概率比较高的机器和取错组合，提供给研发同学后，有了复现和验证的环境，再加上专业能力，问题很快就解决了。类似的曲折故事，在推进数据源采集能力提升的过程中发生了很多次，但总归是在各自发挥专业优势、互相协作的的情况下，不断克服困难并持续进步。几年过去，目前Agent的稳定性和采集能力都有了明显的提升，关键数据源极少再出现取错或者漏取的问题，有效支撑了安全检出能力。四、建模及告警头三年的工作经历里，我做过一些安全规则的工作，以反弹shell、提权这一类比较简单的策略为主。但在我想象中，M公司这种成熟的公司肯定会更关注高级的攻击手法，为了避免“囊中羞涩”，我还专门花时间去研究了下Rootkit、后门、进程隐藏这些“高级”手法。实际入职后，也是出乎意料的没有用武之地。因为第一件事情，还是反弹shell。接到这个任务后，我第一反应就是回忆以前反弹shell的规则是怎么写的——在命令层面加一些关键字检测，然后撸袖子准备开始干活。很快就被领导拦下来了，并且发出了一连串灵魂拷问：反弹shell一共有哪些手法？使用频次如何？哪些能在公司环境下使用？现在支持哪些手法的检测？本次要新增对哪些手法的支持？这些手法除了命令之外，有哪些维度特征？如何防止绕过？需要哪些数据源支撑？方向比努力更重要，所以在开始动工之前，按照领导的指导，我花了几天去做大盘的梳理盘点和对标：反弹shell的本质是什么？shell 通过特定的 连接方式...
我与入侵检测的二三事儿
over 2 years ago
原创 Fr1d4y 2022-08-26 15:13 北京 如何从从扫描器萌新，成长为入侵检测的“青年”油条？ 总结毕业后的六年经历，从扫描器萌新，到入侵检测的“青年”油条，希望能对各位有一些参考价值。一、扫描器18年的夏天，我毕业刚满两年。每个工作日都沉浸在代码里，在扫描器的世界里挥斥方遒，poc数量和漏洞成果都越积越多，工作充实但内心的空洞却越来越大。在机械化重复的工作间隙里，我一直在思考几个问题。我是怎么走上这条路的？我没有主动选择过，但机缘巧合之下，全身都被贴满了扫描器的标签。实习的时候被安排的第一个任务是内网端口扫描，毕业后第一份工作是维护商业扫描器，后来变成自己来写扫描器。看似在不断进步——从一个模块，到整体维护，再到重构，实际上却被重复工作填满，个人成长非常有限。我真的想做扫描器吗？最一开始的时候想做，刚毕业的萌新眼里，哪里都蒙着神秘的面纱，什么都想学。但真的花了两年摸了一遍之后，祛魅环节完成，扫描器就如同墙上被拍扁的蚊子血，失去了光彩。这条路还有发展潜力吗？当然有，可以优化架构减少重复工作，也可以深入底层代码原理做性能优化。但我不想成为架构师，再继续下去，代码能力会成为束缚而非助力。是时候换一个方向了。寻觅良久，我盯上了HIDS——功能复杂繁多，历史积淀与未来发展并存，是一个绝佳的、值得深入研究的工作方向。二、转职“转职”的过程并不顺利，我原本想在Q公司内部转方向，但我所在的团队讲究“孤狼”文化：一两个人负责一个小项目，快速迭代出成果。HIDS实在不是一两个人短期内能完成的项目，数据采集和安全分析是两块儿巨大的蛋糕，很难一口吞下。于是我离职换了工作，本以为到了K公司会柳暗花明又一村，结果变成了更孤的狼。总归还是做了一些努力：开发能力不过关，那就用开源系统OSQuery；没有数据分析能力，那就从头开始学。结果还是不如人意，OSQuery虽然省去了很多工程化的工作，但各公司的基础环境不同，推动的时候遇到了非常多的阻碍，稳定性问题频发，覆盖率也一直上不去；数据分析学了一些，但巧妇难为无米之炊，没有数据谈何分析？后来我离开K公司的时候，HIDS的部署量大约还剩百十来台机器，惨惨淡淡凄凄凉凉。再往后K公司也招了几位专业的研发同学，完全抛弃了OSQuery那一套东西，纯自研迭代了几轮之后也全部覆盖上了，不过这就已经是后话了。在最迷茫的时候，我看到了一篇文章——《浅谈大型互联网的企业入侵检测及防护策略》，条理清晰、深入浅出的讲解了入侵检测中遇到的种种困境及解决思路。所以，毕业第四年，第三份工作，我选择了M公司。高中的时候有一位老师说过一段话，让我至今记忆犹新：“学习，是一个先把书读厚，再把书读薄的过程” 。读厚是指深入理解书里的原理，每页里都有厚重的故事；而读薄是指将技巧融汇贯通，摒弃招式，形成“方法论”，便能举一反三掌握各种变形。这篇文章便是一本书，来到M公司后，我先将书读厚，书里每一句精炼概要的道理，我都在工作中不断经历、实践，所以知其然知其所以然；而后将书读薄，抽象方法论，万变不离其宗。接下来便是我在M公司的“读书”小记。三、基建来M公司前，我以为HIDS的迭代路线是这样的：先把HIDS Agent该做的功能做的八九不离十，然后慢慢的灰度铺开，发几个版本修复bug，就可以开始写检测规则了。而我入职的岗位职责之一就是“写规则”，推导一下，那Agent大概成熟度已经很高了，一定是在持续稳定的采集各类数据，就等我去分析建模了。所以当我入职没几天，就发现HIDS Agent是全量挂掉的状态的时候，内心是有点儿噩梦重现的恐惧感的。尤其是挂掉的原因，又是稳定性问题——HIDS依赖的中间件故障。类似的问题，我在K公司定位了好几个月都没有解决…但噩梦还没来及展开，就光速结束了。M公司内部建设HIDS实际有两个团队，将基建与数据分析拆分开，专业的人做专业的事情。全量停机的问题看起来严重，但在专业的研发同学眼里，并不是关键的技术瓶颈。大约两三周之后，问题修复，Agent重新灰度上线。后来类似的事情又发生过几次，每次的原因都不尽相同，比如资源超限对业务产生影响、逻辑错误导致bug等等，在专业靠谱的研发团队支撑下，也都平稳度过，极少发生全量回滚/下线的情况。（研发团队指路->《保障IDC安全：分布式HIDS集群架构设计》）当然除了稳定性问题，Agent的采集能力也与我想象中的“八九不离十”相差甚远。Agent早期存在非常多的数据质量问题，比如数据关联错误、短进程数据丢失、采集逻辑不全面等，每个问题都难以预知，也对后端的数据分析有非常大的影响。数据源的问题很难一次性全部暴露出来，通常是在数据分析到一半的时候才发现问题，有时候还会影响很大。比如数据关联错误的问题，业务逻辑是A进程访问某敏感文件，但是错误关联成了B进程访问敏感文件，让行为模型的误报量飚高，只能等Agent修复后，模型的误报量才能到达上线标准。当时定位问题的过程也非常坎坷，是否取错需要人工判断，而取错又是小概率事件无法稳定复现，代码层面上看不出问题，摸黑改了一次效果有限。而Agent变更可能会影响业务，所以灰度的周期很长，每次修改验证都动辄以月计，模型的进展也阻塞在这里，情况非常紧张。无奈之下，我们用“大数据”找了一批复现概率比较高的机器和取错组合，提供给研发同学后，有了复现和验证的环境，再加上专业能力，问题很快就解决了。类似的曲折故事，在推进数据源采集能力提升的过程中发生了很多次，但总归是在各自发挥专业优势、互相协作的的情况下，不断克服困难并持续进步。几年过去，目前Agent的稳定性和采集能力都有了明显的提升，关键数据源极少再出现取错或者漏取的问题，有效支撑了安全检出能力。四、建模及告警头三年的工作经历里，我做过一些安全规则的工作，以反弹shell、提权这一类比较简单的策略为主。但在我想象中，M公司这种成熟的公司肯定会更关注高级的攻击手法，为了避免“囊中羞涩”，我还专门花时间去研究了下Rootkit、后门、进程隐藏这些“高级”手法。实际入职后，也是出乎意料的没有用武之地。因为第一件事情，还是反弹shell。接到这个任务后，我第一反应就是回忆以前反弹shell的规则是怎么写的——在命令层面加一些关键字检测，然后撸袖子准备开始干活。很快就被领导拦下来了，并???发出了一连串灵魂拷问：反弹shell一共有哪些手法？使用频次如何？哪些能在公司环境下使用？现在支持哪些手法的检测？本次要新增对哪些手法的支持？这些手法除了命令之外，有哪些维度特征？如何防止绕过？需要哪些数据源支撑？方向比努力更重要，所以在开始动工之前，按照领导的指导，我花了几天去做大盘的梳理盘点和对标：反弹shell的本质是什么？shell 通过特定的 连接方式...
All About OSQuery (一)
about 6 years ago
Fr1day 2019-04-19 14:32 ”我还活着“系列 囤货，首发于跳跳糖。原文链接：https://tttang.com/archive/4/0x01 概述OSQuery 是一款由 facebook 开源的，面向 OSX 和 Linux...
牙齿那些事儿
almost 7 years ago
Fr1day 2018-06-08 19:28 近一年来，我的悲惨经历 (ಥ﹏ಥ) 今天不聊技术，来讲讲我这一年来的看病经历。生活是把杀猪刀，把我（这只后知后觉的猪）剁的稀碎。大学的时候，突然发现最里面的两颗牙齿黑黑的，怎么也刷不干净。跑到江苏省口腔医院挂了个号，才知道是蛀掉的智齿。当时还没意识到事情的严重性，想着反正是智齿蛀掉，也不疼不敏感，等以后有空了把智齿拔了就好。工作的第一年，挣扎在温饱线上的我，完全没顾上牙齿。工作的第二年，听说拔智齿可以瘦脸（冷漠脸，不存在的），就查了些资料，决定去拔智齿。先挂了北京口腔医院的号，拍完片子，确认下牙左右各有一颗阻生智齿。医生说我右侧临近蛀牙的磨牙也有轻度龋坏，建议先拔右侧的智齿（拔智齿创伤较大，拔完一周内无法用那一侧进食，所以只能先拔一侧）。以前在微博上看过拔智齿的视频，过程非常舒爽、流畅。但真正体验的时候，只觉得医生在拿着 “楔子”、“锤子” 在砸我的牙，期间还伴随着 “电钻” 咯吱咯吱磨牙的声音。折腾了半个多小时之后，医生终于把它拽了出来。再就是带着缝了一针的大洞（智齿的窝）和一盒止疼药、两盒消炎药回家了。麻药劲儿过去之后，疼的鼻涕眼泪口水一起流，还得小心的张嘴吞咽吃药（吞咽会有口腔负压）。磕着止疼药，挺(shua)尸(ju)了两三天。一周后拆线，就又活蹦乱跳了！一个月后，再次做好充分的心理建设后，我又挂了号。到了医院之后，才发现挂错了号。拔智齿属于口腔外科，而我莫名其妙的挂了牙体牙髓科...但俗话说得好：“来都来了”，干脆就先把龋齿补了！我就这样抱着 “从容赴死” 的心态，上了补牙的手术床，过程却出乎意料的轻松。只需要忍耐...
XSS绕过与动态扫描
almost 7 years ago
原创 Fr1day 2018-05-16 20:32 啊~~~五环~~~ 翻翻以前的笔记，看到很多绕过XSS过滤相关的内容。又想起前段时间给XSS扫描程序加的 bypass Payload。还算得上是巧（feng）妙（sao），简单分享一下~0x00 常规绕过套路JavaScript 关键字过滤、 +过滤# document.cookiedocument['coo'['CONCAT'.toLowerCase()]('kie')]括号过滤#...