blog
blog copied to clipboard
mylamour
Your internal mediocrity is the moment when you lost the faith of being excellent. Just do it.
First, you should read this [issues](https://github.com/mylamour/blog/issues/63), then you would got a overview of it. and should able to use this docker image Now, let me show you how to modify...
In this blog, all you need is only `https://github.com/google/fuzzer-test-suite/` . First, prepare your environment, it must be installed with `docker` and `git`. Then, let's start. look at this picture, all...
In the begin at the blog, look at this picture, it was fuzzing with `readelf` ( one of `binutils` )  And nothing was found ... Now, let follow this...
In recent few days, i am gonna to thinking about "big security". So, what is "Big security"? My friend told me that was meaningless. It shouldn't be that clear. In...
关于重保这件事
简写两笔感悟，有空下次再续。 首先从管理上来看，在驱动安全落地的两种方式中： **事件驱动** 和 **管理驱动** 中，重保是一件极为有利于推动企业进行安全整改的**事件**， 属于事件驱动中的经典事件。由于一般情况下重保都是由政府或者监管机构发起的，而且随着国家对于网络安全的重视，这些策略可以说是很痛的打在企业身上，能够极为有效的推动安全部门的落地工作。至于无论是事件驱动还是管理驱动，在我的认知里，沟通才是最为重要的。不要一开始就想着事件驱动，而是应该首先做好沟通。当沟通的结果不满足预期时，此时再进行事件驱动，本着外来的和尚会念经原则，利用外部提交过来的一些问题推动内部的发展。但是注意不要把自己放在研发、运维的对立面，而应该是互相协作。共同为客户提供好的安全保障。 第二点谈一谈重保实现的形式，重保往往是注重于形式化。有时候可能不切中实际落点。和企业安全防御的建设本身有些出入。但是并不意味着重保是无效的。同时往往也能暴露出一些问题。就是**永远不要以战术上的勤奋，去掩盖战略上的懒惰**。一群人，日日加班，在重保期间，24h online， 应急止血。这从另一方面只能说明了一件事，事前的企业安全架构没有做好，检测和止血的能力也没有自动化。同样仅仅依靠重保期间的高强度工作去应付检测时不起作用的。尤其是疲于奔命的应急和毫无预演和规范的止血操作。但是如果企业能够吸收重保带来的教训，能够在接下来的时间段内提高自身的安全建设，也是值得。总的来说，不能止于形式。 第三点谈一谈相反的一种情况，就是大促和重保。大促时候的重保往往和监管的等保，政府的护网不同。大促是企业本身做出的关于营销方面的重大决定。无论是确保风控本身，还是企业安全本身。在大促期间的保障行为毫无疑问是极为重要的。但是针对大型的互联网公司，大促可能带来超大流量，不亚于一次超大型的DDOS，虽然此时有些防护是在ISP和CDN上做了清洗，同时也通过人机验证过滤掉了一批用户。但是此时的流量和用户依旧是巨大的。同时无论是反爬还是安全设备也往往在此时会进行降级，比如不再全量检测，规则也进行降级。只保留核心的waf规则等等，避免把串联在边界的安全设备打垮，同时由于业务请求量的激增，也会导致日志收集系统流量暴涨。为了避免相关联的系统崩溃，有时也会关闭日志。尽可能的把资源全部留在业务上。那么这个时候怎么办？老虎打盹的时候需要依赖边界栅栏，边界的硬抗加硬件分光，大数据的检测平台，即便常用的日志收集出现问题，也要尽可能的保障在边界的检测行为。根据大促的特点，不会是全时段的，可以针对大促的不同时段，调整对应的规则，进行降级等等。另外还有很重要的一点就是**提前做好演练**。不要降级降挂了，在真正实操的时候出现了暗坑。此时业务当先，一切都将措手不及。
2020年1月月度技术分享内容演讲纪录。由于当时没有纪录，本来想着抽空把分享内容补在博客里，但由于内容太多暂时不写了，抛几个观点： * 云背后也是IDC啊，不要太玄幻 * 云安全和云原生安全两码事 * 既然云原生那么做云原生安全尽量依托云上产品 * 云/云原生并不代表问题就解决了，越是high Level的抽象，越是难以发现和管控底层的安全问题 * 云原生安全相当于based on cloud native product 的SDL(DEV+SEC+OPS) + Operation(Data,Production)
# install & generate root CA with mkcert You can install `mkcert` by download binaray from `https://github.com/FiloSottile/mkcert/releases/download/` , then move it to your custom path. generate Root CA like that:...
# 已经做的 下面谈一谈水印，因为具体工作没有涉及过，恰好离职在家，就简单的做了一下[Wwmark](https://github.com/mylamour/Wwmark)(What Watermark), 或许有些浅显。水印（Watermark），顾名思义，给某些东西加上如同water一样的mark，但并不影响源文件的使用。水印分类的话，简单来分的可以有图片水印，视频水印，文件水印，网页水印。添加的水印可以是有图片也可以有文字。从可见与否来分，又可以分为明水印和盲水印。盲水印在CTF中常见的隐写术有一些，但不完全一样。关于图像本身的RGBA和RGB此时暂时不讲（因为PIL和OpenCV在处理文件时存储的格式不一样），只是简单的讲一讲我是怎么做的。鉴于输入源定义为视频和文件，很容易的就选型了FFMPEG和OpenCV。 采用ffmpeg进行图像和视频的明水印处理。当然使用命令行可能更加快捷，但不利于复用。 ```bash ffmpeg -i input.mp4 -i image.png -filter_complex "[0:v][1:v] overlay=x=10:y=10" -c:a copy output.mp4 ``` 针对文字水印和图片水印ffmpeg提供了`drawtext`和`overlay`两种方式。 此处[wwmark.py](https://github.com/mylamour/Wwmark/blob/master/wwmark.py)做了简要的封装（基于ffmpeg-python），使其能够支持不同文件的明暗水印加密。针对pdf时采用的方法是pdf2image，然后image加上水印再合成为pdf。 此处有三个小问题需要注意： 一是文件路径，建议采用`tempfile.TemporaryDirectory()`。 二是针对生成的文件名，需要进行排序，默认是使用的`uuid.uuid1()`做的文件名生成，再随后的合成和排序中会出现问题，此处简单更改为`lambda x: x+1`自增加一。 三是图片合成为pdf的时候会多一个首页。因为是` ims[0].save(self.o_file, "PDF", resolution=100.0,...
# Overview of Cert filetype * PEM This is a (Privacy-enhanced Electronic Mail) Base64 encoded DER certificate, enclosed between “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–“ `openssl req -newkey rsa:2048 -new -nodes...