yw9381 最近的时间轴更新
yw9381

yw9381

V2EX 第 92775 号会员,加入于 2015-01-20 14:34:26 +08:00
求一个 1Passowrd 的车
二手交易  •  yw9381  •  2019-01-23 16:37:18 PM  •  最后回复来自 fareware
9
Office 365 家庭发车。还有俩位置
无要点  •  yw9381  •  2018-12-08 22:24:20 PM  •  最后回复来自 wiviam
1
出 13 寸 MacBook 2017 TouchBar MPXV2CH/A 全新未拆
二手交易  •  yw9381  •  2017-10-09 14:52:55 PM  •  最后回复来自 tyvqhb
12
西安电信已经进入大中华局域网了么
宽带症候群  •  yw9381  •  2017-07-13 12:29:50 PM  •  最后回复来自 bclerdx
23
yw9381 最近回复了
@gtchan13579 你要做单臂也不是不行。两个 vlan 。聚合到一个 trunk 也可以。逻辑上这是两条线路。你可以搜一下 ikuai 怎么做单臂路由
你需要在交换机上把某个端口设为 tagged 端口(即 Trunk 端口)。然后给这个端口分配多个 vlan 。最后把这个端口接到 ikuai 的某个 lan 。比如 lan2 。然后在 ikuai 的 vlan 设置里。基于 lan2 创建 vlan 。就可以了
159 天前
回复了 raysonlu 创建的主题 GitLab gitlab 被攻击了!求大佬进来分析一下
个人觉得这是一个安全配置问题。并不算是有漏洞。安全缺陷和漏洞是两码事。不过还是建议你们内部自查一下弱口令这些。还有相应的权限管控。
159 天前
回复了 raysonlu 创建的主题 GitLab gitlab 被攻击了!求大佬进来分析一下
看了下应该大概能给你复原出来攻击场景,首先你的 gitlab 应该是开放了注册或者有人有弱口令。之后攻击者创建或是修改了某个仓库,并在其中加入了.gitlab-ci.yml 。然后触发了 ci 操作。因为你 gitlab 和 gitlab runner 都在一个机器上部署。所以 runmer 是可以访问到本机的 pgsql 的。攻击者在 runner 的 ci 脚本里写了那句 sh -c xxxx 。在 4 楼的解码后也可以看到攻击者创建了一个名为 dexbcx 的管理员用户。后续的攻击动作因为没提供更多信息就不得而知了。
也有可能整个事情是个误报。你只是想创建一个名为 dexbcx 的管理员用户。结果 gitlab 对创建用户的底层实现是通过 sh -c 的形式运行命令(这条感觉不太可能)
307 天前
回复了 mingtdlb 创建的主题 问与答 问下服务器的 IPMI
所以结论是。只要能通过 ipmi 访问。就可以进行任何操作。不管是串口形式还是网络形式。但是服务器默认只开了串口形式(即程序需要跑再物理服务器上
307 天前
回复了 mingtdlb 创建的主题 问与答 问下服务器的 IPMI
楼上回复都没实际用过。我手头有 dell 服务器。也在用 ipmi 做管理。实际使用是。有个 ipmi 远程访问开关。再 idrac 设置里。如果打开了。那么可以用 ipmitools lanplus 进行管理。地址就是 idrac 地址。账号密码也是。如果关闭了。那么需要在这个物理机系统上运行 ipmitools 。例如 exsi 。如果这个物理机中有虚拟机。除非打开 ipmi 对外访问。然后通过网络。否则都是需要在宿主的物理机上跑。ipmitools 这个工具本身全平台都有
很简单一句话。你就把他当做普通电脑用就行了。接上鼠标键盘屏幕装系统(系统可能卖家给你装好了)。进系统装你们需要的仿真软件然后开始干活就行了
2020-07-21 04:44:45 +08:00
回复了 cnbattle 创建的主题 问与答 服务器/代码安全问题哪个问题更严重?
接楼上。别说给什么 debug 信息了。就算你把源代码给黑客。如果系统本身在开发过程考虑到了安全问题并在编写代码时严格检查了输入。且开发及使用人员意识一流(有种总有刁民想害朕的意识从而导致系统安全性极高)。那么。黑客拿到源代码本身进行分析。甚至自己搭建了测试环境。也只是耗费了黑客的心力。最后无功而返。可能唯一潜在隐患是。源代码泄露出去可能意味着业务逻辑的泄露。以及使用的第三方服务的各种 API KEY 泄露。可能某些操作间接导致影响生产环境。但是也只是仅此而已。不会有更大的影响。第三方服务的 Key 要更换也很容易。
2020-07-21 04:33:56 +08:00
回复了 cnbattle 创建的主题 问与答 服务器/代码安全问题哪个问题更严重?
按知乎格式。不请自来。利益相关。信息安全从业人员
先说结论。2 更严重
楼主说有个大前提是使用的基础环境都是最新组件。也更新到最新版本。那么除非是 0day 漏洞。否则是在基础组件环境这里没法下手的。而 0day 漏洞是有使用成本的。不到万不得已不会去考虑使用。(不讨论有没有的问题。这里假定有)。而默认端口。这根本不算安全问题。非常正常的使用方式。修改端口并不能带来安全性的提升。全端口扫描加服务识别很快就有结果了。
基于这个大前提。攻击面就只剩下业务系统这一个了。按照楼主描述这应当是一个后台管理系统。在没有登录的情况下。其实很难有什么操作。除非开发人员意识不到位。框架提供的功能不用。偏要自己手写 SQL 。偏要自己处理文件上传。检查。改名等一系列操作。不过我想既然都上框架了。应该很少有人这么搞
那么整个攻击思路也只剩下围绕业务逻辑处理来展开。例如逻辑漏洞(前台购买。后台确认发货)。盗窃数据(订单。用户等)。对于弱口令来说。其实就相当于后台大门打开。谁都可以进去。完成上述操作。那么在业务上。轻则产生脏数据。重则影响业务本身处理(大量假订单之类。删除业务相关数据)。甚至利用当前权限来完成合乎业务逻辑的操作(修改订单金额并发货)从而造成经济损失(假设为自动化的发货系统)。退一步也能获取到这个后台的所有业余数据。这对于业务系统开始也是比较致命的(和拖库基本差不多)
而暴露测试环境。debug 打开。trace 信息打开这些信息只是给渗透过程提供信息参考。注意仅仅是参考。最终能否渗透成功。还是取决于业务本身是否存在漏洞。假定开发人员拥有良好的开发意识。那么即使给黑客一个测试环境。各种信息一应俱全。也不见得能拿下来。
所以说。万千防护敌不过一个 123456 。安全意识要比防护本身更重要。从一开始在代码 /框架 /依赖等根源上杜绝安全隐患要比后面使用防火墙等软硬件设备阻断要好得多
因为安全问题而丢失了客户,这个本就是自己的问题。举个例子,之前的三星手机因为爆炸问题不得上飞机,而且也会危及人身安全,那么在选购手机的时候,用户是不是会去考虑手机的安全性,在某种程度上就会否决掉三星的整个产品线。这个问题也不能说是怪那个买了三星手机结果手机炸了的那个人,这一点上,我站挨打要立正的态度。自己的安全开发意识不到位,多去学习学习如何开发更加安全的功能,无论对于当下这个产品,还是以后要做的产品。对自己,对客户,都是一个负责任的交代。还是那个意思,错并不可怕。怕的是知错不改错。甚至要掩盖错误。
其实这件事情也是给自己敲响一个警钟。做产品不仅仅是吧功能完成就 OK,还要考虑到方方面面。对于客户来说他们也不想我花钱买的东西结果突然有一天出事了还得自己背锅。所以还是建议楼主在这个事情上跟客户进行协商,有些时候客户并不 care 你到底有没有问题,只仅仅是不想担责。既然吧产品卖给客户了,那么也就有义务打消客户的这些顾虑。让客户用的放心。出现安全问题第一时间通知客户,做好应急预案。紧急修补 /封禁方案,然后修复之后提供补丁包,以及相关的技术支持,我觉得这才是一个正常的处理过程
对于客户那边,可能客户对于安全的这些事情了解的没那么多,所以一听有漏洞卧槽那还得了。不行不行。类似这样的想法,其实无论是厂商,开发者,或是白帽子来说,都是挺蛋疼的一件事情。所以这更多的也是白帽子和厂商之间共同的诉求。不要把漏洞视作妖魔鬼怪,正视漏洞,正视自己的缺陷,有问题,解决问题就好了。客户那做好思想工作。认认真真的去对待问题。我相信问题还是能够圆满解决的
最后。如果楼主愿意,我倒是蛮想替楼主的产品做一个完整的安全检查。给不给钱都行,主要目的也是希望通过我的行动能够让楼主明白漏洞不是妖魔鬼怪,白帽子也不是十恶不赦。另一个角度也是为了充实自己。同时也想把我的一些安全经验带给楼主,在楼主以后的开发过程当中如果能够因为我二开发出更好的产品,那么我也是会很欢喜的
大家都只是希望这个世界变得更好而已。共勉
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1582 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 12ms · UTC 17:30 · PVG 01:30 · LAX 09:30 · JFK 12:30
♥ Do have faith in what you're doing.