安全漏洞可以说是业务系统所有安全事件的源头,漏洞是一个宽泛概念,既包括安保、社工导致的意识流问题,也包含软硬件技术处理层面的缺陷问题,本文主要讨论技术方向,不涉及安保、员工意识等非技术问题。
漏洞发现是安全管理工作的前置必要条件,漏洞发现的全面性和及时性,很大程度上决定着整个漏洞治理和安全管理工作的质量,这应该是广大安全从业人员的共识,根据我浅薄的从业经验,漏洞发现途径大致可以分为人工资产匹配、漏洞扫描工具、渗透测试等三类,下面依次展开说明。
人工资产匹配方式指在不具备本文后两种发现手段执行条件(特征匹配和脚本验证)的情况下,根据现有资产信息进行漏洞匹配(大多是根据版本进行,部分会涉及具体功能),主要适用于0day或已披露、爆发时间较短的漏洞,通常由软硬件厂商或监管机构、上级单位进行发布和通报,前者一般是单位自发排查处置,但后两种通告是强制任务,甚至部分紧要漏洞会要求限时反馈、上报受影响和处置情况,安全团队如不能根据已有资产信息快速做出判断,虽说部分企业的资产管理工作不是安全团队职能,但拉扯过程中可能或多或少会给高层留下工作不力的印象,甚至扣上推诿的帽子。
其实资产是漏洞发现的基础,漏洞扫描、渗透测试都是基于资产信息(URL、端口、IP、域名等)开展的,尤其是经历了快速增长期和漫长建设期的单位,资产管理工作往往或多或少都有欠缺,资产管理细细理顺讲来又可以写一篇文章,本文就不再展开了。
漏洞扫描工具五花八门,根据其来源属性可以分为开源的、国内外商用的(含号称国产自研的硬件盒子),根据其主要作用资产对象属性又可以分为主机扫描器、WEB应用扫描器等,根据其架构可以分为C/S、网络代理等,但究其根本大致可以划分为两种技术模式,猜测式匹配检测和POC式验证机制,各有优劣,大致特点如下:
通过远程检测资产对象的网络服务和组件程序,收集返回的响应数据,根据漏洞库中的已知漏洞特征(版本、协议、响应特征等)进行模糊判断,满足组成条件则视为存在漏洞,但很多漏洞经过加固或修复后,其响应信息特征可能不会发生根本改变,这就产生了误报,我相信很多从业人士都因此挨过甲方、运维或者开发的怼。
猜测式匹配检测和上文提到的人工资产匹配有异曲同工之妙,都是在不具备脚本验证条件的情况下通过匹配版本进行的,不同之处有二,一是在于前者是根据厂商维护更新的工具半自动化进行的,通常虽更新时效不会太快,但技术成熟、漏洞信息全面,二是前者是判断维度不只有版本资产信息,还涉及协议、响应头等动态特征。
基于验证脚本的自动化过程,通过模拟已知漏洞利用手法(脚本)自动对资产对象进行仿真攻击(注意是仿真,不具有实际危害或实际危害可控),分析目标动态变化判断攻击是否成功,攻击成功则视为存在漏洞。POC式验证检测依赖验证脚本,历史已知漏洞不计其数,验证脚本覆盖不完全,会产生漏报。
猜测式匹配检测的漏洞库全面,存在误报,POC式验证检测受限于验证脚本的覆盖面,存在漏报,误报和漏报貌似是两个极端。
(1)对于采买漏扫产品的单位:
好在近年来部分厂商意识到了问题,更新迭代的漏扫产品减少了对于版本对比等简单特征判断的依赖,结合POC机制,降低了误报率,虽然扫描速度相对较慢,但鱼和熊掌皆可兼得。
另外鉴于厂商脚本的更新时效不可控,建议采买支持自定义POC脚本的漏扫产品,以备不时之需,部分厂商产品虽号称支持POC功能,但为内置脚本库,不支持自定义。
(2)对于采买漏扫服务的单位:
明确要求服务单位使用基于POC、特征库的多款产品进行交叉验证,POC检测发现的漏洞直接交付给运维、开发等下一流程使用,基于猜测检测发现的漏洞要求乙方根据IP、端口、CVE号等进行筛重后扭转到下一流程。
通常来说渗透测试也包含漏洞扫描,但前者在目标上更倾向于取得权限或数据,偏重于纵向入侵,而非仅仅发现一些漏洞,发现、组合和利用漏洞是渗透测试关键手段,漏洞即可以是常见的高风险的已披露的安全问题,也可以是独有特殊的业务逻辑扭转处理上的错误(如薅羊毛)。
在信息安全越来越重要的如今,各个互联网大厂要是没搞个众测平台,出门都不好意思打招呼的“众测”时代,渗透人员只要花时间在平台上磨,都可以获得一定的经济收益,特别是前几年,相关法律法规都尚未完善,漏洞披露平台授权没授权的一通乱炖,故此江湖上流传着很多靠挖洞发家致富、买车买房的传说,这些平台的注册用户大多是乙方专职的安全技术服务人员,趋利性催生了一种怪诞的现象“工作只是副业,上平台挖洞才是主业”,在各种渗透评估服务项目里也就草草应付了事,取得某些权限就交付报告完成渗透工作了,甚至把渗透测试做成了漏洞扫描结果验证。
(1)对于甲方单位:
市面上安全服务商都有高手,但这些高手成本很高,需要用到更有价值的地方,至少如果我是一家安全服务公司的老板,遇到对服务内容要求不明确甚至完全不懂的客户,我是肯定不会把高手长期放在这个项目上的,这甚至都无关于甲方的预算或项目大小,因为没必要浪费成本,这不是道德和品质问题,这是企业的核心任务:利益最大化,但如果甲方单位管理上对安全非常重视,技术上又能主导服务商的具体工作,对于服务商来说,在预算允许的情况下必须派出最高的高手来服务,保证交付质量,否则就有可能丢掉这个项目。
渗透测试质量固然与服务商能力有关联,但我个人认为也依赖于甲方安全团队对服务要求和验收标准的把控度,需要根据系统实际情况约定具体预期目标,达成目标则完成服务,否则不成功,还可以引入多家服务商进行质量交叉对比。
(2)对于乙方服务商:
建立渗透测试标准作业流程,细化到采用什么工具,优先进行哪些风险的挖掘和利用,兜底固定住服务质量的下限后,标准之外是加分项,不限方式给工程师留有一定的空间,最重要的是服务报告统一进行质量审核后输出给客户,审核结果纳入职称、奖金评价体系。
以最常见的网络安全问题弱密码这个话题而展开一下。
相信到目前为止,大部分企业所采用的一个最佳IT实践必定是采用复杂密码,不管是哪篇文章,哪本书籍,不管是CISSP还是CISP,要求用户使用强密码是必然存在的一个准则。而每次攻防演练中,用户弱密码或者缺省密码往往成为了攻击的最优解。
由弱口令导致的攻击事件实令人心惊胆战,弱密码,空密码,缺省密码以及明文密码等逐一被挖掘出来,涉及不乏有企业重要业务系统和核心基础设施的账号安全问题。为了解决这种问题,有些企业重刀下要求,要求员工使用12位甚至16位以上的密码,设定密码策略,必须符合大小写,数字,特殊符号齐全的强密码策略。我们今天就该问题进行一些讨论。
美国国家标准与技术研究院(National Institute of Standards and Technology,NIST)发表了一篇文章,名为“Digital Identity Guidelines“挺有意思,大家有兴趣的可以去看看原文,地址后面附上,这篇文章讲了一些身份标识的使用准则,我这里简单给大家讲讲。
这些准则为实施数字身份服务的联邦机构提供技术要求,并不打算在此目的之外限制标准的制定或使用。这些准则的重点是对通过开放网络与政府系统进行互动的主体进行认证,确定某位申请者是先前已被认证的用户。
认证过程的结果可以由执行认证的系统在本地使用,也可以在联合身份系统的其他地方宣称。该文件定义了三个认证器保证级别中每个级别的技术要求。(AAL1,AAL2,AAL3,详情见文内表格)该出版物取代了NIST特别出版物(SP)800-63-2的相应部分。
这篇文章噼里啪啦地讲了一大堆,我们主要看5.1.1.2 Memorized Secret Verifiers,中文不太好翻译,但意思应该容易理解,我直译了一下,密码验证器,文中指出几点:
密码长度需为8位以上,并允许最大长度为64位的可见字符(参考RFC20标准)
PIN码必须是6位以上
密码必须无任何“提示”信息,且不应提示任何特殊类型的信息,比如“你家的第一只宠物猫的名字是什么?”
在处理新增或变更密码请求时,将根据如下列表且不限于如下列表进行验证并排除该密码的变更请求
被列名的已知弱密码,比如qwerty
常见字典词,比如password等
重复的或连续的字符,比如aaaaaa,1234,abcd等
特定背景的词,比如服务的名称,用户名,以及其他衍生品
应向用户提供指导,如密码强度表,帮助用户选择一个容易记的强密码
应施行密码错误锁定策略
应允许使用粘贴选项,这是为了方便使用密码管理器进行密码粘贴,密码管理器在许多情况下增加了用户选择更强密码的可能性
应允许用户在输入密码的时候短暂显示每个输入的字符,以验证正确的输入,尤其适用于移动设备。一系列的点或星号输入经常导致密码输入错误,而在最后使用View查看输入的密码却又会带来其他风险
不应该对该密码强加其他组合规则(例如,要求不同字符类型的混合或禁止连续重复字符)
服务存储密码必须保证能对抗高强度的离线破解,必须采用适当的单向密钥加密函数并采用加盐散列提供,其中盐值必须为至少32位长度
请求密码时必须使用经过批准的加密和认证的受保护通道,以避免窃听和中间人攻击
使用多因素认证,并规定了软硬件单、多因素认证的标准
尽管从可用性和安全性的角度来看,密码的使用普遍令人沮丧,但它们仍然是一种广泛使用的身份验证形式。然而,在日常生活中,我们需要记忆的密码太多,线下的,线上的,社交的,企业的,各种各样的都需要密码,所以我们往往选择容易被猜中的密码,或者弱密码。
为了解决由此产生的安全问题,各种在线服务均已经出台了一些规则,以增加这些密码的复杂性。其中最值得注意的是密码组合规则,它要求用户选择使用混合字符类型(例如至少一个数字、大写字母和符号)构造的密码。然而,对被破解的密码数据库的分析显示,尽管对可用性和可记忆性的影响非常严重,但此类规则的好处并不像最初认为的那么重大。
用户选择密码的复杂性经常使用信息论中的熵概念来表征。虽然对于具有确定性分布函数的数据,熵值可以很容易地计算出来,但是对用户选择的密码的熵值进行估计是困难的,而且过去的努力并不是特别准确。出于这个原因,本文提出了一种不同的、稍微简单一些的方法,主要基于密码长度。
许多与使用密码相关的攻击不受密码复杂度和长度的影响。键盘记录器、网络钓鱼和社会工程攻击对冗长、复杂的密码和简单的密码同样有效。这些攻击不在本文讨论的范围之内。
口令长度是描述口令强度的主要因素。太短的密码会导致暴力攻击以及使用单词和常用密码的字典攻击。
所需的最小密码长度在很大程度上取决于所处理的威胁模型。通过限制允许的登录尝试的速率,可以减轻攻击者试图通过猜测密码登录的在线攻击。为了防止攻击者(或老打错字的)通过多次错误的猜测,轻易地对用户实施拒绝服务攻击,密码需要足够复杂,以便在多次错误尝试后不会出现速率限制,但确需要实施限制当发现有成功猜测的情况。
当攻击者通过数据库漏洞获得一个或多个散列密码时,有时可能发生离线攻击。攻击者确定一个或多个用户密码的能力取决于密码的存储方式。通常,密码是用一个随机值和散列处理的,最好使用一种计算代价昂贵的算法。即使有了这些措施,目前攻击者每秒计算数十亿哈希的能力,而且没有速率限制,这要求抵御此类离线攻击的密码比预计只能抵御在线攻击的密码要复杂几个数量级。
应该鼓励用户在合理范围内设置自己想要的密码长度。由于哈希密码的大小与它的长度无关,如果用户希望的话,没有理由不允许使用冗长的密码(或短语)。但过长的密码(长度可能为兆字节)可能需要过多的散列处理时间,因此有一些限制是合理的。
如上所述,密码的组合规则通常用于试图增加猜测用户选择的密码的难度。然而,研究表明,用户以非常可预测的方式响应组合规则强加的需求。例如,一个用户可能选择了“password”作为他们的密码,如果要求包含大写字母和数字,那么相对来说,他可能会选择“Password1”,或者“Password1!”如果还需要一个符号的话,我想这点很多人都干过。
当用户创建的复杂密码的尝试被拒绝时,用户一般会说“靠,这都不行,真烦“?许多应用拒绝使用空格和各种特殊字符的密码。在某些情况下,不接受特殊字符可能是为了避免依赖于这些字符的SQL注入之类的攻击。但在任何情况下,正确散列的密码都不会完好无损地发送到数据库,因此这种预防措施是不必要的。用户还应该能够包括空格字符,以允许使用短语。然而,空格本身并没有增加密码的复杂性,而且可能引入可用性问题(例如,未被发现使用两个空格而不是一个),所以在验证之前删除输入的密码中重复的空格可能是有益的。
用户的密码选择非常容易预测,所以攻击者很可能猜测过去成功使用过的密码。这些密码包括字典中的单词和以前的密码,比如“Password1!”。出于这个原因,建议将用户选择的密码与不可接受的密码的“黑名单”进行比较。这个列表应该包括来自以前的入侵泄露过的密码、字典词汇和用户可能选择的特定词汇(如服务本身的名称)。由于用户对密码的选择也将受最小长度要求的约束,因此该字典只需要包含满足该要求的条目。
高度复杂的密码引入了一个新的潜在的弱点:太复杂,记不住。而且更有可能被以不安全的方式记录下来,比如写到纸上,或者用Excel记录。虽然这些做法不一定容易受到攻击,但从统计学上讲,一些记录此类秘密的方法将会受到攻击。反过来讲,这也是一个不需要太长或太复杂的密码的另外一种考虑。
文中还提到6位数的随机生成的PIN码已经足够强壮,可以作为密码使用的一个考虑。
如果对密码的长度和复杂度要求超过了这里推荐的程度,将显著增加密码记忆的难度,并降低用户的易用性。因此,用户经常以适得其反的方式绕过这些限制。此外,其他的密码缓解措施,如黑名单、安全散列存储和速率限制,在防止现代暴力攻击方面更有效。因此,当密码验证框架完善,对该类密码而言,其实并不需要附加复杂性要求。
有的用户购买vps服务器后,去连接远程桌面,但是连不上,给服务商申报故障,服务商却回复能连接上,或其他朋友能连上自己的vps服务器的远程桌面,自己却不能连上。这是怎么回事呢?
引起这种问题的原因有多种:
1. 服务器的ip的问题,在部分城市或部分网络线路下不通。我们可以做以下尝试。我们可以重启本地路由一次(有光猫的包括光猫也得重启),然后再次尝试连接vps服务器的远程桌面;我们还可以换个网络环境,比如说你电脑连接的本地宽带的话,我们可以不使用本地宽带,把自己的手机热点开启,然后电脑连接自己的手机热点,然后再次连接vps服务器,如果电脑没无线网卡,手机有USB分享网络的功能(不懂的话,可以百度一个教程);还可以到网吧去连接vps服务器远程;我们也可以找服务器运营商处理。
2. 宽带运营商的问题。有一些小的电信宽带运营商是限制了远程桌面连接的,比如艾普宽带。这时我们可以联系宽带运营商解决。宽带运营商解决不了的话,可以让电脑连接手机的网络试试,或者换个宽带了。
3. 本地电脑mstsc(或叫“远程桌面连接工具”)版本的问题和操作系统漏洞。由于windows本身存在不少的漏洞和bug,有些用户不经常给电脑打补丁,就可能遇到不能连接服务器远程桌面的问题。还有一个原因就是本地电脑的mstsc和vps服务器的操作系统不兼容。我就遇到过一个客户,他服务器安装的win10系统,本地电脑是win7系统,本地电脑连接服务器的远程桌面就连接不上。此时,我们可以百度关键词“mstsc 下载”,多下载几个不同版本的mstsc连接服务器,总有一个版本能成功连接的!
有些用户,特别是新手用户,常犯一些比较低级的错误,导致vps不能登陆远程桌面,这里给大家例举几种。
第一,登陆远程桌面不带远程端口,登陆服务器的远程桌面都是通过一个通道进入,这个通道也就是“端口”。唯一不带端口的情况就是,这个服务器的远程端口是3389端口。比如58.221.6.2的远程端口是3389,那么我们在mstsc的“计算机”填58.221.6.2和58.221.6.2:3389都可正常登陆。登陆远程端口不是3389的必须带上端口。
第二种常犯错误就是,IP和端口之间的冒号用了中文符冒号,我们对比下 36.7.173.254:20081 和36.7.173.254:20081,前面一个是中文符冒号,后面的是英文符冒号,中文符的冒号明显占用的位置要宽得多。当我们在输入冒号的时候,注意把输入法调整为英文输入法,这就不会出错了。
第三种错误就是在输入服务器远程登陆的用户名和密码的时候在用户名和密码前后带上空格了。这个错误不容易发现,我们可以把用户名和密码全选,如果多一位,说明多的那位就是空格。
尊敬的客户:
蓝米云香港CN2四区已上架销售,免备案,CN2直连线路,100% Intel SSD云存储服务器 低延时 高吞吐 高随机IOPS的存储性能。不限流量,提供跟圣何塞同样的天机盾(联系客服配置策略),适合博客、个人网站站长订购。
当云服务器使用一段时间后可能会有数据盘空间不足的情况,那么升级数据盘大小之后就需要进行系统内部磁盘空间扩容操作,这边以数据盘20G升级为30G为例(针对此操作时需小心谨慎操作,操作失误将会导致数据丢失,请务必先备份好数据再进行操作)。
1、卸载挂载中的数据盘:
umount /dev/sdb1
2、使用parted工具读取磁盘分区表信息;先使用 p
查看可扩容磁盘大小,再通过unit s
命令定义默认使用sectors展示,获取起始位置信息:
3、创建新分区。先使用 rm 序列号
来删除老的分区表;然后使用 mkpart
命令来创建即可,这里需要注意的是parted工具里END的值,由于一般大家都不清楚具体的扇区数量,可以使用容量来替代。
unit s
的sectors
扇区模式中操作,否则将导致数据盘扩展异常rm 1mkpart primary ext4 2048 32.2G
umount /dev/sdb1
4、检测磁盘是否有错误:
e2fsck -f /dev/sdb1
5、扩展数据盘大小:(如文件格式为xfs,则使用命令:xfs_growfs /dev/sdb1
)
resize2fs /dev/sdb1
6、重新挂载磁盘并检查磁盘大小:
mount -a
尊敬的客户:
打开windows系统的“开始”->“运行”,输入“regedit”,确定,打开注册表,做两个修改(缺一不可):
1. 依次进入以下注册表路径:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TerminalServer\Wds\rdpwd\Tds\tcp
在右边窗口找到PortNamber值,其默认值是3389,修改成自己希望的端口即可(注意基数要选十进制),例如2345。
2. 依次进入以下注册表路径:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControSet\Control\Tenninal Server\WinStations\RDP-Tcp
在右边窗口也可以找到PortNumber值
3. 重启云服务器后生效。
1、下载并使用工具。 服务器远程桌面端口修改工具 。(网上有很多该类工具,例如:护卫神)
2、重启云服务器后生效。