2024-02-14 09:52:00
年底整理资料，发现很多收藏的文档都没有打开看过，虽然过去蛮久了，但我觉得还是值得一读，一方面整理过滤出自己关注的内容，另一方面给自己的收藏做一个交代。说起读材料还是挺喜欢做的一件事，小时候会去读字典，那时候每一页会有一个故事，就这样不知不觉也顺带把字典看了一遍；乌云挂了之后，也想把漏洞读一遍，就像乌云疯狗所说：“阅尽天下漏洞，心中自然无码”，每个事件型的漏洞都代表了一个场景、一个姿势，以及下面的评论也都蛮有意思，只可惜时间线拉的有点长，最终并没有坚持下来，看了几个类型漏洞后就结束了。因此这次读PDF一来趁热情高涨，速战速决，二来形成一个流程化，尽可能可持续，同时也把过程中比较有意思的tricks记录下。
梳理了大约100G左右材料，还剩23G大杂烩过程中再慢慢整理了，这次精力主要在安全会议上，虽然说是读，但最多只牵强算是泛读，感兴趣的多看一会，可能用到的标记下，不感兴趣的直接略过。
关于自动化流程，除了常规TODO外，很推荐DEVONthink 3工具，做本地文档检索、监控、管理都非常适合，比如你关注某个领域，那么构造好关键词，即可实现本地持续监控，一劳永逸。
在浏览及梳理了近几十个G会议材料后，最直接有这几个感受：
2023-11-26 18:14:00
最近接触到MasterGo这款在线设计工具，发现挺不错的。一方面类似Sketch，学习成本比较低，另一方面资源比较多，组件套用、协同配合上也比较方便，因此学习一番，便于更高效运用这款工具。
参考团队资产管理方式，团队项目可以按照业务产线区分，文件可以按照功能模块或产品版本号分组，便于内容直观查看与管理。同时可以对每个文件设置封面，以及对文件内容以层级树方式管理版本，便于内容查看与方案复用。
2022-08-25 19:46:00
最近分析一批恶意样本数据，考虑到数据量以及开箱即用的图表分析，所以决定把数据放在ES上，用Kibana来分析。因为是自己在用，所以只要能快速跑起来，撑的住小几T数据的秒级查询、分析即可。综合速度、便捷性等方面，工作流大致如下：写streaming_bulk，存es、分词ik_max_word、检索kibana、迁移elasticdump/logstash。这个过程没啥高深技术卷入其中，更多只是从众多功能项中，筛选出满足需求，适合单机快速运转的小方案，记上一笔，方便日后用到节省时间。
⚠️ 由于软硬件选用、性能调优出发点是个人单机，线上环境可能并不适合。
基本环境部署没什么好说的，跟着网上步骤走一遍即可，软件用的是ELK 7.10.1，主环境安装在windows上，同时为了方便调试本地也拉了个docker测试环境；硬件上4核CPU（性能高建议8核~16核）、HDD+SSD、24G内存（性能高建议64G）。推荐两个部署源：
https://github.com/deviantony/docker-elk
https://mirrors.huaweicloud.com/elasticsearch/根据官方给出的建议，JVM配置为机器一半的内存，不超过32G，且Xms和Xmx值尽可能保持一致。
config/jvm.options
-Xms12g
-Xmx12g# 关闭交换分区，防止内存置换降低性能。 将/etc/fstab 文件中包含swap的行注释掉
sed -i '/swap/s/^/#/' /etc/fstab
swapoff -a
# 单用户可以打开的最大文件数量，可以设置为官方推荐的65536或更大些
echo "* - nofile 655360" >> /etc/security/limits.conf
# 单用户线程数调大
echo "* - nproc 131072" >> /etc/security/limits.conf
# 单进程可以使用的最大map内存区域数量
echo "vm.max_map_count = 655360" >> /etc/sysctl.conf
# 修改立即生效
sysctl -p索引优化
Elasticsearch近实时的本质是：最快1s写入的数据可以被查询到。 如果refresh_interval设置为1s，势必会产生大量的segment，检索性能会受到影响。 所以非实时的场景可以调大，设置为30s，甚至-1。即：在写入过程中修改刷新时间和副本数来提升写入的速度，等到写入结束后再修改回去。
GET /ASM_Assets/_settings
PUT /ASM_Assets/_settings
{
"index" : {
"refresh_interval" : "-1",
"number_of_replicas": 0
}
}同时用buk或streaming_bulk批量写的方式，目前主要用的streaming_bulk基本能够达到数据录入的时间、文档的要求。根据不同场景、侧重需求情况，可以参考py-elasticsearch的stream_bulk、parallel_bulk、bulk性能对比作者给出的测试结果选择适合的批量写入的方式。
PUT index_two
{
"mappings":
{
"properties":
{
"name":
{
"type": "keyword"
}
}
},
"settings":
{
"index":
{
"number_of_shards": 1,
"number_of_replicas": 2
}
}
}# 删除索引数据，保留结构
POST index_one/_delete_by_query
{
"query": {
"match_all": {
}
}
}
# 删除索引
DELETE /index_one,index_two# 查看A开头索引
GET /_cat/indices/A*?v
# 查看索引状态
GET /_cat/indices/ASM_ips
# 查看索引设置
GET /ASM_ips/_settings
# 查看索引mapping
GET /ASM_ips/_mapping# 查询response字段中包含200的文档对象
response:200
# 模糊查询response字段中包含200的文档对象
response:*200或者response:200*
# 不区分大小精确查询某字符串
message:"hello world yes"
# 不区分大小无序查询包含其中某个字符串
message:hello world
# 关系查询
(name:jane and addr:beijing) or job:teacher
response:(200 or 404)
not response:200
response:(200 and not yes)
@timestamp < "2021"
# 查询所有包含response字段的文档对象。
response:*
# 查询搜索列machine开头，字段内容包含hello的数据记录
machine*:hello# 返回结果中需要有http_host字段
_exists_:http_host
# 不能含有http_host字段
_missing_:http_host
# 通配符模糊匹配
kiba?a, el*search
# 范围匹配
sip:["172.24.20.110" TO "172.24.20.140"]
date:{"now-6h" TO "now"}#!/usr/bin/env python
# -*- coding: utf-8 -*-
# @Author : Coco413
# @Summary : Batch import source data to elasticsearch
# @Usage : python3 import_es.py
try:
import simplejson as json
except ImportError:
import json
from elasticsearch import Elasticsearch, helpers
from datetime import datetime
import csv
ES = Elasticsearch(
hosts=[{"host": "127.0.0.1", "port": "9200"}],
http_auth=("xxx", "xxxx"),
retry_on_timeout=True,
max_retries=10)
def importdata_TXT(filename="ips.txt", index_name="xxx", count=0, all="N/A"):
with open(filename, "r", encoding="utf8") as fr:
for line in fr:
count += 1
pass # <根据自身需求，处理文本结构至base>
temp = {
"_op_type": 'index',
"_index": index_name,
"_source": base
}
print("[{}/{}]{}".format(count, all, temp))
yield temp
def importdata_CSV(filename="domains.csv", index_name="xxx", count=0, all="215612"):
with open(filename, "r", encoding="utf8") as fr:
for row in csv.DictReader(fr):
count+=1
pass # <根据自身需求，处理文本结构至base>
temp = {
"_op_type": 'index',
"_index": index_name,
"_source": base
}
print("[{}/{}]{}".format(count, all, temp))
yield temp
def importdata_JSON(filename="ioc.json", index_name="xxx", count=0, all="N/A"):
with open(filename, "r", encoding='utf-8') as fr:
for line in fp:
count+=1
pass # <根据自身需求，处理文本结构至base>
temp = {
"_op_type": 'index',
"_index": index_name,
"_source": base
}
print("[{}/{}]{}".format(count, all, temp))
yield temp
for ok, response in helpers.streaming_bulk(client=ES, max_retries=5, chunk_size=5000, actions=importdata_TXT()):
if not ok:
print(response)elasticdump --input=http://xxx:[email protected]:9200/ASM_Assets --output=./my_index_mapping.json --type=mapping
elasticdump --input=http://xxx:[email protected]:9200/ASM_Assets --output=./my_index_data.json --timeout=10 --sizeFile=1gb --type=data
elasticdump --input=http://xxx:[email protected]:9200/ASM_Assets --output=$ | gzip > ./my_index_data.json.gz --timeout=10 --type=data
elasticdump --input=./my_index_data.json.gz --output=http://xxx:[email protected]:9200/ASM_Assets --type=datainput {
elasticsearch {
hosts => ["127.0.0.1:9200"]
user => "xxxx"
password => "xxx"
index => "*"
# query => '{ "query": { "query_string": { "query": "*" } } }'
docinfo => true
size => 5000
# schedule => "0 * * * *"
}
}
output {
file {
path => "./1.json"
# path => "./test-%{+YYYY-MM-dd HH:mm:ss}.txt"
}
stdout {
codec => json_lines #console输出， 可以注释stdout部分
}
}Elastic Stack 实战手册-藏经阁-阿里云开发者社区
2022-05-22 23:43:00
在这个信息过载的时代，我既是一名知识汲取的受益者，同时也是知识反噬的焦虑者。作为一名信息安全从业者，需要具有大量的阅读和碎片知识的积累，来帮助自己完善知识体系、提升对安全认知的见解。在这个成长的过程中，同时也会伴随着反噬、焦虑，比如自己的精力和意志时常产生矛盾互相打架，收藏的paper、想做的 ideas 积压的越来越多，生活和技术分配的时间失去了平衡等等，导致陷入在信息洪流和知识焦虑中难以自拔。
之前有一段时间，我大部分信息来源渠道，甚至娱乐相关的APP几乎都被技术相关话题所淹没，我被自己困在了自己勾勒的信息茧房中，抛开技术仿佛就是一只小白懵懵糟糟，唯一换来的可能就是朋友的调侃只要发给我的paper，好像都被我提前看过了，而得到的那一丝丝“奇怪的自豪感”。
无休止的奔跑、野蛮的阅读、仅靠意志力和信息洪流正面刚，诚然量变会产生质变能够带来不少帮助，并且这种“野蛮”、“痛”的过程我一直也认为是很有必要的，只是在经历过后，需要能够把自己拽出来，进而更好更有效率的学习沉淀。当下不敢说摆脱了知识焦虑的困扰，自己偶尔也还是会出现焦虑，“禁闭”个一两天和自己作对下，但相比之前好了很多，同时在这个过程中也有了一些自己的感悟，拿出来和大家一起交流，共同捍卫我们的信息流。
无休止的奔跑，会让信息积压的更多，既给自己增添焦虑感，也不利于内容吸收。因此需要阶段性的按下暂停键，回顾整理沉淀，降低知识的焦虑感。如何降低知识焦虑感？我有如下这几个小 tips 和大家分享：
之前零碎信息管理上有个明显的问题，就是入口过多，多个信息渠道收藏、转发，甚至有时候图一时方便直接截图或粘贴备忘录，导致回顾整理起来非常耗费精力。因此开始缩减入口，减少在不同渠道平台上使用收藏功能，把过滤后的信息入口，统一都放入在 Cubox 进行回顾。
之前会有因为担心“单节点故障”漏掉了某些信息内容，所以在不同信息渠道上交叉重复订阅相同的信息源，导致阅读时候产生不少重复的内容。但其实这样意义并不大，更多只是增重了重复过滤的精力，并且有了这种“冗余机制”，在浏览的时候也会不自觉产生出一定惰性和依赖性，阅读也不够有耐心。
所以重复交叉订阅没有太多必要，就像个人知识管理体系系列 - 捕蛇者说里所说：
当第一次遇到一篇文章的时候可以不用打开，当第二次又出现在你眼前的时候再去阅读，真正重要的东西是会出现第二遍的。
乍一听鸡汤味十足，但细细想来还是挺有道理，即使信息源只保留一个，重要的内容比如某个漏洞爆发还是自然而然可以通过朋友圈、工作群等方式获取到，及时性固然重要，但重复筛选所耗费的精力也应当被呵护。因此我逐渐清理了一些没必要的群、公共号以及其他重复信息源，仅保留方便日常和较为关注的信息源做交叉订阅，把生活和技术的信息界限感划分的更清晰些，既不影响信息获取，同时也释放了一定精力跳出来，回归到生活。
之前有段时间，总想着把积压的内容一个个 check 掉，但却不断陷入在收藏-消化、再收藏-再消化的恶性循环中，归根到源头还是不够聚焦、导致信息过滤失败，处理太多“有益但无意义”的信息流，分散了精力。所以在过滤信息的时候应当更加谨慎一些，评估自己是否能够做到稍后阅读，从而适当舍弃掉一些信息流，聚焦在自己的分支上，避免被大量都是有益的信息所干扰到。比如收藏某篇文章的时候，可以问问自己是因为确实需要还是惯性收藏？最近是否有时间去研究？是否能解决当下某个问题？如果不收藏今后找不到吗？等等问题，然后给自己一个过滤信息的答案。
如何放平心态，去看待知识焦虑，我的理解就是把它当做一个件在正常不过的事情，因为这种焦虑不仅仅我们会产生，很多其他人也都有遇到过，它只是这个信息时代的一个现象，而非问题，因此只要放平心态去接纳这种现象，找到适合自己的工作流就好，当工作学习的时候就进入这个框架好好工作，非工作的时候跳就出来好好享受生活。这里摘录了几条大佬们的语录：
Project Zero （Google P0安全团队 - Blog）
ringzero猪猪侠（ringzero的个人主页 - 微博）
不爱吃鱼的蓝鲸（也许生活本该碎片化：聊聊 flomo 这款工具如何改变我的生活 - 少数派）
通过这些语录不难看出，大家都面临过相类似的困扰，也都在不断探索寻找适合自己的信息相处方式，所以对于知识焦虑，要能从心态上平静的接纳这一现象。
知识管理工作流简单来说即：从信息输入到输出的过程中，挑选顺手的工具连贯而形成一套信息管理使用流程。知识管理这类工具有很多，比如Flomo、Zotero、Obsidian、Notion等都是很好的工具，是否适合自己，需要在尝试过程中发现问题解决问题。以下是我在这个过程中挑选的一些工具，并形成适合我自己的简易工作流。流程、工具选用因人而异，仅供参考：
在RSS订阅工具上我主要使用Inoreader，在订阅一些国外Feed上速度能够更快一些，不过由于 RSS 会存在一定信息延迟，所以部分源会配合上 Distill 添加页面监控提醒。在RSS内容筛选管理上我大致有如下这几个小习惯：
关注行业内一些综合订阅源更新动态，定期去重、合并、筛检做融合补充。目前主要关注zhengjim/Chinese-Security-RSS、r0eXpeR/Security_RSS、Han0nly/SecurityRSS、zer0yu/CyberSecurityRSS这几个仓库，如果也有类似需求的小伙伴，在处理opml文件时，注意这几个小tips：（1）同订阅源，不同协议，例如http://www.example.com/rss.xml 和 https://www.example.com/rss.xml（2）同订阅源，URL路径格式，例如http://www.example.com/rss.xml 和 http://www.example.com/rss.xml/ （3）同订阅源，多订阅地址，例如http://www.example.com/rss.xml 和 http://api.example.com/rss.xml （4）同订阅源，不同烧制方式，例如同一个站点可能会出现有的用Feed43、有的用RssHub烧制。
比较关注的、高质量订阅源独立在一个目录，便于忙的时候优先取舍浏览。
一些每天更新频繁的比如 HackerNews、Freebuf 或者本身就是聚合的站点比如unsafe、doonsec等独立出来，避免积压过多，影响其他源信息查看。
Github是我比较高频的信息获取渠道，由于之前顺手 Fork 积压了不少仓库，管理起来比较麻烦，并且事后也基本都没有再看过、查找也不方便，所以 GitHub 更多只是用来项目浏览和仓库更新提醒，不做收藏。遇到感兴趣的项目打标签放到 Cubox 或者直接整理到 DEVONthink Awesome-Security，方便需要的时候能快速找到某个项目或某类项目集。
对于闪现灵感、草稿随笔这类只言片语主要用备忘录、Procreate。备忘录记录会比较随意，放飞的写写画画，然后定期再去清理。
在文档阅读流程上，我主要采用 iCloud云盘 + DEVONthink方式，需要看哪些文件通过 iCloud 云盘同步，看完后再归档到本地目录，替换新的文件到云盘。交替同步一方面不会有太多的阅读压力，另一方面也避免大量文件同步耗时、占用空间。
在文档阅读设备上，习惯用iPad看文档，周末打着dota，嚼着脆司令，再来口冰阔乐，读秒时刷刷PDF，一大乐事。
在技术类文档管理上，习惯重标签轻分类，即所有的文档都放在一个目录下，通过命名方式 + 标签进行管理，同时用标签自带的颜色区分属性大类，如红队、蓝队。
信息筛选过滤后，交由 Cubox 标记分类，作为统一的信息中转入口，承载稍后阅读和整理归档的中抠作用。
由于 DEVONthink 自带的编辑器不好用，所以内容编辑使用 Typora 或者飞书在线文档代替。
SecNavi是我一个在持续更新的安全站点导航，主要是为了简化一部分浏览器书签、方便平时资料查找，发现不错的网站就补充添加进去。
DEVONthink总的来说是一款 ALL-IN-ONE 的信息管理工具，既可以 RSS 订阅、稍后阅读，也可以文件管理、全文检索等，同时也有比较方便的同步方案，基本贯穿了输入到输出整个工作流。
从内心来说我是希望有这么一款全方位覆盖工作流 ALL-IN-ONE 的工具，但深入使用下来并不适合我，在细节、方便程度、功能覆盖上等都不够顺畅。不过DEVONthink在文件管理上非常方便，并且其标签能够和 Finder 系统标签完全同步保持一致，因此我使用 DEVONthink 主要是用于管理输出的笔记、文档等，同步Finder&iCloud归档备份。
工作流除了对输入&输出管理外，日程安排也尤为重要，目前我主要使用 Things 3 来管理工作流任务、生活琐事、重要提醒等。
工作流除了软件外，硬件设备也必不可少，我日常主力MBP，闲暇外出iPad，配合飞书的在线文档 + iCloud云盘，能够方便流畅的内容编辑&文档阅读。
适合的工作流、良好的心态，能够帮助我们更从容的面对，每天扑面而来的信息流。除此之外，还应当不断提升独立思考、信息检索的能力，反哺工作流的输入与输出，进而去完善知识体系，让自己对事物的认知理解能更趋势于准确且全面。
以上就是我的知识管理方式，希望能给你带来一些帮助。
2022-03-06 18:28:00
看到一篇笔风挺意思的文章让安全团队快速倒闭的十条建议，模仿也写了几条关于安全产品的忠告建议，行之是否有效，也请自行甄别尝试，过程所产生的一切风险责任由践行者承担~~
1、不必重视安全产品运营，交由客户自由发挥
2、不必量化指标自证产品能力，看不见的价值无需呈现
3、无需在意产品使用“安全感”，尽管强迫用户适应你的想法
4、不必方法论定战略做规划，直接一把搜就开干
5、无需明确产品定位，尽量发散尽善尽美
6、不必深入了解安全，对着标书抄抄改改即可
7、不必落地解决方案、场景流程，只要功能具备，其他依赖使用者水平就好
8、不必提高核心竞争力，产品同质化是常态
9、不必倾听一线声音，他们使用很流畅
10、不必客观展示全貌数据，片面断节数据不影响分析
11、不必透明指标定义、研判机制，懂的人自然懂
12、功能流程不必闭环，细节交互逻辑无需在意
13、尽管把故障运维压力交由研发，不必为其考虑自动化
14、不必管控产品演示质量，无需考虑演示标准化
15、不必考虑安全产品质量，安全产品自然安全
