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 。就可以了
328 天前
回复了 raysonlu 创建的主题 GitLab gitlab 被攻击了!求大佬进来分析一下
个人觉得这是一个安全配置问题。并不算是有漏洞。安全缺陷和漏洞是两码事。不过还是建议你们内部自查一下弱口令这些。还有相应的权限管控。
328 天前
回复了 raysonlu 创建的主题 GitLab gitlab 被攻击了!求大佬进来分析一下
看了下应该大概能给你复原出来攻击场景,首先你的 gitlab 应该是开放了注册或者有人有弱口令。之后攻击者创建或是修改了某个仓库,并在其中加入了.gitlab-ci.yml 。然后触发了 ci 操作。因为你 gitlab 和 gitlab runner 都在一个机器上部署。所以 runmer 是可以访问到本机的 pgsql 的。攻击者在 runner 的 ci 脚本里写了那句 sh -c xxxx 。在 4 楼的解码后也可以看到攻击者创建了一个名为 dexbcx 的管理员用户。后续的攻击动作因为没提供更多信息就不得而知了。
也有可能整个事情是个误报。你只是想创建一个名为 dexbcx 的管理员用户。结果 gitlab 对创建用户的底层实现是通过 sh -c 的形式运行命令(这条感觉不太可能)
2021-03-18 03:47:10 +08:00
回复了 mingtdlb 创建的主题 问与答 问下服务器的 IPMI
所以结论是。只要能通过 ipmi 访问。就可以进行任何操作。不管是串口形式还是网络形式。但是服务器默认只开了串口形式(即程序需要跑再物理服务器上
2021-03-18 03:45:21 +08:00
回复了 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 。安全意识要比防护本身更重要。从一开始在代码 /框架 /依赖等根源上杜绝安全隐患要比后面使用防火墙等软硬件设备阻断要好得多
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2830 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 63ms · UTC 14:00 · PVG 22:00 · LAX 07:00 · JFK 10:00
Developed with CodeLauncher
♥ Do have faith in what you're doing.