今天听说腾讯数据库也泄露了,类似GroupData1_DataMDF这样的6个下载文件总共245G。还好后来发现是用户资料数据,不是qq密码。
这里有讨论
网络时代,个人隐私全存在这些公司里,如果被公开,可能造成一些问题,比如被一些人恶意利用等等。
目前可以肯定的是,这东西是真的,而且已经在网上流传开了。最开始是xunlei离线的QQ数据库7z,然后又被人放到了百度网盘,还有在线查询网站(现在好像没了)。
泄露事故统计数字正在逐步下降,但数据仍然面临着由数据库、应用以及终端保护不当所引发的严重风险。
从多个角度来看,2013年的数据泄露趋势已经得到有效扼制,这对于安全行业来说当然是个好消息。不同于过去四到五年,今年的记录当中不再充斥着大型数据库泄露所导致的数以千万计个人身份信息的外流。根据隐私权信息交流中心的调查,本年度公开报道的泄露事故数量及记录在案的泄露事故数量双双呈下降趋势。去年同期,得到确切统计的记录泄露数量已经达到约278万条,漏洞报告则为637份。而在今年,目前为止记录在案的泄露事故约为107万条,漏洞报告则为483份。这充分证明整个安全行业在合规性与安全最佳实践方面所迎来的进步——然而这样的战绩与理想目标相比仍然相去甚远。
在对年初至今的数字进行比较时,我们发现记录在案的泄露事故数量大幅降低了617%,然而报告提及的泄露事故数量则仅降低了242%。这表明泄露事故仍然快速发生——只不过如今的犯罪活动及违规事件开始逐步扩散而非集中于一点。泄露事件影响范围更小,而且根据安全业内人士的说法,此类恶意活动的目标也更为广泛。现在犯罪分子开始更多地窃取IP或者其它数字资产,由此引发的损失可能比客户记录本身更为严重——同时这也更加难以量化,无法提供头条新闻所必需的统计结果。
通过对今年发生的泄露事故的深入钻研,我们发现安全行业明显仍有大量工作要做。2013年的追踪记录证明,有价值数据库仍然没有受到严格保护与加密、应用程序仍然存在大量安全漏洞、用户们则仍然能够从敏感数据库中下载大量信息并将其保存在缺乏保护的终端当中。为了帮助大家更好地理解当前安全形势,我们选取了几项最具代表意义的实例,希望各位能够从中吸取可资借鉴的教训。
当事企业: CorporateCarOnlinecom
泄露统计: 850,000份记录被盗
事故细节:作为全美最具知名度的专业体育、娱乐外加五百强企业,CorporateCarOnlinecom拥有大量用户个人资料、xyk号码以及其它个人身份信息,然而由于其开发出的全球豪车租赁SaaS数据库解决方案将全部信息以纯文本形式储存,最终导致这一切成为犯罪分子的囊中之物。名单中涉及不少大牌,包括汤姆·汉克斯、汤姆·达施勒以及唐纳德·特朗普等。
经验教训:最重要的教训在于认清这样一个现实:面对极具价值的财务与社会工程信息,攻击者们会爆发出极为可怕的技术能量。根据KrebsOnSecuritycom网站的调查,目前遭遇过违规活动的美国运通卡当中有四分之一为高额度甚至无限额度卡片,而且企业间谍分子或者娱乐小报记者也希望通过这类个人信息挖掘到有价值结论。与此同时,该公司在管理收支账目时完全没有考虑过信息安全性,甚至从未尝试采取任何最基本的加密措施。
当事企业: Adobe
泄露统计: 约三百万个人身份信息、超过15亿用户名/密码组合以及来自Adobe Acrobat、ColdFusion、ColdFusion Builder外加其它未说明产品的源代码惨遭窃取。
事故细节: 自最初的违规事件发生之后,接踵而来的更多攻击活动持续了一个多月之久,并最终导致了此次重大事故的发生。目前情况已经明确,Adobe正在努力恢复其失窃的大量登录凭证信息——更令人惊讶的是,连其产品源代码也一并泄露。
经验教训: 通过Adobe遭遇的这一轮震惊世界的攻击活动,我们不仅切身感受到攻击者在企业网络中建立根据地并夺取了整套业务储备控制权后所能带来的损害,同时也应学会在考虑将供应商引入软件供应链之前、考察对方在安全领域营造出了怎样的企业生态。作为此次泄露事故的后续影响,其潜在后果恐怕在很长一段时间内都无法彻底消除。
当事企业: 美国能源部
泄露统计: 53000位前任及现任能源部员工的个人身份信息遭到窃取
事故细节: 攻击者将矛头指向了DOEInfo——该机构利用ColdFusion所打造的、已经弃之不用的CFO办公室公开访问系统。能源部官员表示,此次泄露事故只限于内部员工的个人身份信息。
经验教训: 我们从中应该吸取两大教训。首先,安装补丁过去是、现在是、未来也将一直是最为重要的安全任务。其次,各机构必须通过重新审视与敏感数据库相对接的系统最大程度减少攻击面,保证只向公众开放必要的网站。
当事企业: Advocate Medical Group
泄露统计: 四百万病人记录遭到窃取
事故细节: 仅仅由于犯罪分子从办公室里偷走了四台由该公司拥有的计算机,最终导致了这起四百万病人记录丢失的事故——公司官方将此称为自2009年卫生部强制要求通告安全事故以来、美国发生过的第二大医疗信息泄露案件。
经验教训: 医疗行业的数据泄露事故在2013年的违规披露名单当中一直占据主导,但这一次的案件造成的影响显然特别恶劣。仅仅由于一台物理计算设备失窃就最终导致从上世纪九十年代至今的病人记录泄露,这充分暴露了该公司在物理安全、终端安全、加密以及数据保护等各个方面的全线失误。需要强调的是,终端设备被盗与丢失在医疗行业中已经屡见不鲜。现在这些机构可能需要尽快思考终端设备到底能够下载并保存多少来自中央数据库的信息。
1 根据日志查找;
首先,翻看系统日志,找到连接池溢出的时刻。然后,对应这个时间,查找用户正在进行的 *** 作。
这种方法适合于不启动任何监控程序或进程,不改变系统设置,就能人为的缩小可能泄露连接的代码范围。
2 利用连接池本身的utility设施;比如C3P0,以下是需要用到的两个参数(推荐):
unreturnedConnectionTimeout
Default: 0
Seconds If set, if an application checks out but then fails to check-in [ie close()] a Connection within the specified period of time, the pool will unceremoniously destroy() the Connection This permits applications with occasional Connection leaks to survive, rather than eventually exhausting the Connection pool And that's a shame Zero means no timeout, applications are expected to close() their own Connections Obviously, if a non-zero value is set, it should be to a value longer than any Connection should reasonably be checked-out Otherwise, the pool will occasionally kill Connections in active use, which is bad This is basically a bad idea, but it's a commonly requested feature Fix your $%!@% applications so they don't leak Connections! Use this temporarily in combination with debugUnreturnedConnectionStackTraces to figure out where Connections are being checked-out that don't make it back into the pool!
debugUnreturnedConnectionStackTraces
Default: false
If true, and if unreturnedConnectionTimeout is set to a positive value, then the pool will capture the stack trace (via an Exception) of all Connection checkouts, and the stack traces will be printed when unreturned checked-out Connections timeout This is intended to debug applications with Connection leaks, that is applications that occasionally fail to return Connections, leading to pool growth, and eventually exhaustion (when the pool hits maxPoolSize with all Connections checked-out and lost) This parameter should only be set while debugging, as capturing the stack trace will slow down every Connection check-out
当我们同时使用这两个参数时,比如unreturnedConnectionTimeout设为5秒,debugUnreturnedConnectionStackTraces设为true。那么,当一个连接被check out 5秒,还没有被check in的时候,连接池会抛出一个错误堆栈。有了堆栈,那我们就可以精确定位出现问题的代码位置了。
当然,这个方法中的参数并不是C3P0特有的,其他连接池配置中,应该也有类似的参数。
指的是如果在某次使用或者某段程序中没有正确地关闭Connection、Statement和ResultSet资源,那么每次执行都会留下一些没有关闭的连接,这些连接失去了引用而不能得到重新使用,因此就造成了数据库连接的泄漏。数据库连接的资源是宝贵而且是有限的,如果在某段使用频率很高的代码中出现这种泄漏,那么数据库连接资源将被耗尽,影响系统的正常运转。
邮件在服务器上,又不是在你电脑里面,所以不可能是病毒问题的了。
垃圾邮件多,一方面可能是你的邮件地址在网上暴露多了,被垃圾邮件发送者收集到数据库,从而垃圾邮件剧增。
其实有些垃圾邮件都是他们自己的广告,没有广告哪里有利润,可能是126和别人的合作
以上就是关于腾讯数据库24.5G也泄露了,什么节奏全部的内容,包括:腾讯数据库24.5G也泄露了,什么节奏、最近几年数据库泄漏事件、如何发现数据库连接泄露等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)