30选5玩法|福彩30选5开奖结果321|
 

分类:安全技术

黑客技术

CoreOS安装挖坑

No Comments 安全技术

缘由

最近在云平台中架设了三台节点的CoreOS集群,虽然对于很多云平台和虚拟化管理平台,官方都提供了安装脚本,但由于我所使用的云平台的一些原因,我无法选择使用官方的云平台部署脚本,所以本次纪录,是纪录直接在虚拟机中安装CoreOS的过程,理论上安?#23433;?#39588;适用于裸机安装。遇到了一些坑,特此记录,希望对初次接触CoreOS的童鞋有所借鉴和帮助。

步骤 & 坑
第一步 : 下载系统安装的ISO文件

你可能会觉得这一步很简单,但是,我不得不说,这个过程我花费了最多的时间。

由于官方的镜像下载源被伟大的GFW墙了,所以我无法直接下载这个ISO!

解决过程:我尝试使用迅雷下载,发现没速度,于是找同学拿了个某雷的VIP账号,把镜像下载下来了,速度奇慢

注:目前这个ISO下载地址似乎可以直接访问了CoreOS ISO

第二步?#21644;?#36807;ISO引导,进入LiveCD

第三步:SSH到LiveCD环境中

虽然这一步不是必须的,但我觉得,这一步是必须的!因为你如果你不SSH到LiveCD中,编写安装配置文件config.yaml的时候非常麻?#24120;?#27604;如,你要添加SSH-Key,你不可能一个一个?#22336;?#25970;进去,所以最好的方法当然是在SSH终端?#29616;?#25509;拷贝。

:从系统上看来,SSHD服务是开着的,我链接了老半天都连不了,排查了很久才发现,在CoreOS中,和其他Linux发行版不一样,它的SSHD的PermitRootLogin默认是no的,禁止了Root登陆,所以需要改了。

配置SSH的过程

cd /etc/ssh
mv sshd_config{,.bak}  #你不能直接编辑,因为这个文件是/usr/share/ssh/ssh_config的软链接,而/usr的整个分区,是只读的
cat sshd_config.bak > sshd_config
vim sshd_config
#...
PermitRootLogin yes  #加入这一句
systemctl restart sshd
sudo passwd root

然后就可以用ssh上去了。

第四步:编写初始化配置

填写cloud-config的配置,在官方有说明,按照自己的需求来就行,在本次的实验中,这一步当然也少不了坑。

按照网上或者官方的教程,你可能会看到类似于下面这样的例子(我就是用这个的):

#cloud-config
hostname: coreos01
coreos:
        units:
                - name: etcd2.service
                  command: start
                - name: fleet.service
                  command: start
        etcd2:
          discovery: https://discovery.etcd.io/cb33f38c16bead3a376be9bfc706987
          advertise-client-urls: http://$private_ipv4:2379,http://$private_ipv4:4001
          initial-advertise-peer-urls: http://$private_ipv4:2380
          listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001
          listen-peer-urls: http://$private_ipv4:2380,http://$private_ipv4:7001
        fleet:
          metadata: role=coreos01
users:
        - name: core
          ssh-authorized-keys:
                - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQC9Q...== KeyExample
        - groups:
               - sudo
                - docker

然而安装完之后才发现,etcd集群是失败的。经过排查,才发现etcd侦听的地址全部都是127.0.0.1

------中间广告---------

所以我果断看配置文件cat /run/systemd/system/etcd2.service/20-*,恍然大悟。

:在安装前配置cloud-config(cloud-config.yaml)的时候,如果要使用$private_ipv4或者其他$public_ipv4之类的变量的时候,要确保这些变量是存在的(一开始我以为CoreOS自动添加的,教程都那样写),一个方法是,你可以把环境变量写到/etc/environment?#23567;?br />

第五步:安装

执行安装命令:

coreos-install -d /dev/sda -c cloud-config.yaml

由于在安装过程中,系统会从官方下载更新包,如果如我现在所看到的那样,官方的镜像站是可以直接访问的,那么你的安装过程可能很顺利。然而当时我安装的时候,镜像站是访问不了的,所以,这个坑,非GFW莫属。当然解决方法也是很简单。

:由于官方镜像站点被墙,安装过程中无法下载更新包。所以:

1、用某雷(VIP)或者翻墙之类的方法下载镜像

2、?#19994;?#23433;装过程中需要下载的更新包,URL路径可以在安装脚本中?#19994;劍?code>vim /usr/bin/coreos-install,当然还有一个更好的方式是,执行安装的时候用sh -x /usr/bin/coreos-install -d /dev/sda -c /cloud-config.yaml这样就可以看到安装的过程中脚本在哪一步停住了,比如我看到的是脚本一直停在下载下面的两个文件的步骤:

http://stable.release.core-os.net/amd64-usr/899.13.0/coreos_production_image.bin.bz2

http://stable.release.core-os.net/amd64-usr/899.13.0/coreos_production_image.bin.bz2.sig

3、用某雷(VIP)或者翻墙把两个文件下载下来,自己建立HTTP服务器,然后在里面简历一个899.13.0目录,并把文件放进去,供安装脚本下载。

4、执行安装,并指定从自己的http服务器下载更新包

coreos-install -d /dev/sda -c cloud-config.yaml -b http://192.168.1.1

:从VPS下载更新包,?#25191;?#21040;内网HTTP服务器上,数据损坏,重新下一个,安装成功 T_T。

总结

折腾一番之后,总算安装成功,有了一个继续折腾的平台。

总体感觉,CoreOS的设?#35780;?#24565;是很好的,尤其是集群和精简这一点,在搭配CoreOS的几大重量级应用(fleet、etcd、Rkt等)之后,相对于传统的Linux发行版,在数据中心或者微服务架构中,简直是完爆了,我之后在测?#32536;腃oreOS上面开启docker发现其运行起来比在CentOS7运行快很多,不知道是错觉?#25925;?#38169;觉或者是错觉...特地也在某云买了一台虚拟机来玩CoreOS。但是!由于CoreOS相对?#27492;禱故?#27604;较新的东西,所以在行业上用得比较少,尤其是国内,所以学习资料、系统架构案例和问题疑难解决方案等资料在网络上都比较少,另一方面,由于CoreOS大部分时候注重大体架构,细节上比较少关注,所以对于用户而言,会有很多小坑(体验颇深)。

作者:岦_
链接:http://www.jianshu.com/p/c8684f943a7c
來源:简书
著作权归作者所?#23567;?#21830;业转载请联系作者获得授权,?#24039;?#19994;转载请注明出处。

云端安全开放?#29616;?#26550;构 评鑑服务供应商安全水準

No Comments 安全技术

花俊杰

随着云端服务的迅速发展,无论是SaaS、PaaS、IaaS服务,各种云端服务供应商都提供了消费者方便弹性、随需可用的云端服务,只是在眾多服务的背后,您是否了解厂商对於资安控管和安全责任的要求?是否可以安心地採用云端服务呢?

面对如雨后春笋般出现的云端服务,身為想要採用云端服务的消费者,到?#23376;?#35813;如何选择一个可靠安全的云端服务供应商?事实上并不容?#20303;?#23545;用户而言,公有的云端服务,其实就是一种外包服务,消费者对於厂商的了解,可能来自於?#25918;?#21360;象、其他人的推荐,或是来自於?#25945;?#20013;刊登的广告,对?#37117;?#26684;或服务的内容,也许可以有所了解,但是对於厂商的资料保护能力、服务运作能力,以及资讯安全的管理要求和实施情况呢?或许心中仍然存在着许多的问号。
基本上,由於云端服务本身有着跨越国境和许多用户同时租用的特性,而且各项行业依照其產业所属性质的不同,都有其所需要特别遵守的法律法规,再?#30001;细?#20010;云端服务供应商对於资安要求的程度不一,因此目前仍然缺乏一个统一的标準,也很难有一个容易实施的方法来进行安全?#32536;?#35780;估。
虽然有些业者强调,已经导入了资讯安全管理标準ISO 27001的安全控管要求,但是其验证的范围是否包含了云端服务?针对云端服务实施了哪些安全?#30446;?#21046;措施,整体的资讯安全水準如何?似乎缺少了一个更透明化的方式,可以让广大的消费者得知,并且可以作為选择云端服务供应商的参考。
云端安全开放?#29616;?#26550;构简介
对於以上所提到种种与安全有关的问题,云端安全联盟(CSA)已?#29616;?#21040;很难有一个单一的安全?#29616;ぃ?#23601;可以含括所有服务供应商的安全需求,但是业界又很?#38750;行?#35201;有一?#27490;?#24320;且可受公评的方式,让服务供应商可以自我揭露其安全水準,同时也让消费者获得可以参考的依据。
因此,在2012年的云端安全会议中,云端安全联盟基於各项受到產业认可的安全控制目标,提出了云端安全开放?#29616;?#26550;构(Open Certification Framework;OCF),可用来作為评估云端服务供应商的安全?#29616;ぁCF是基於云端安全联盟对於治理、风险和法规遵循(Governance, Risk and Compliance Stack)的研究专案,所发展出来?#30446;?#20449;赖云端服务?#29616;?#23433;全架构,它能够广泛地支援多个层次且来自於不同供应商和消费者的安全需求。

▲OCF採取三层式的?#29616;?#26550;构。(?#35745;?#26469;源:CSA Open Certification Framework)

云端安全开放?#29616;?#26550;构提供了一个可弹性应用的方案,透过三个渐进式的发展层次,从自我评估到外部评鑑的实施,最终的目标是希望能够?#20013;?#22320;监控,以确保各项安全控制措施的有效性,并且也能不断地改善,?#26376;?#36275;使用者的安全需求。云端安全联盟指出,服务供应商藉由实现了云端安全开放?#29616;?#26550;构的安全控制,将可以达成以下目标:
1. 让云端服务供应商可以因应各项產业标準和法规的要求,并且採取业界认同的云端安全最佳实务,同?#22791;?#26399;许经由政府机关的率先导入,為公眾使用的云端服务,指出了一个明确可行的安全?#29616;?#35201;求与方向。
2. 提供了明确的安全指引和工具,像是整合了ISO 27001的云端控制矩阵 (Cloud Controls Matrix;CCM),让云端服务供应商更易於满足多项标準的安全要求。CCM是云端安全联盟设计用来作為评估云端安全的基础,也是引导服务供应商採用业界的最佳实务作法,除了可以确保其云端服务的安全,同时也能协助云端服务的消费者,藉此来选择符合其安全要求的云端服务供应商。CCM?#30446;?#21046;措施和CSA云端安全关键?#25913;现?#30340;13项安全领域要求是一致的,并且融合了其他业界常见的安全标準,例如 HITRUST CSF、ISO 27001/27002、ISACA COBIT、PCI、HIPAA和NIST等,也呼应了服务型组织对其内部稽核控制的安全要求,预期将可减少组织同时适用各项法规时,所需要面?#32536;?#37325;复稽核问题。
3. 云端安全开放?#29616;?#26550;构可作為一项受到业界认可的体制,它能够支援ISO标準、美国会计师协会(AICPA)和其他相关安全?#29616;?#26550;构,简化并减少需要重复进行各项安全?#29616;?#30340;要求。
开放?#29616;?#26550;构的评鑑方式
云端安全开放?#29616;?#26550;?#25925;?#19968;个三层式的架构,从它的底层出发愈往上走,就愈能透明化的展现云端服务供应商的安全控管方式,并且让消费者获得更高的安全保证,评鑑的实施方式说明如下。
第一层:STAR自我评鑑(The STAR Self-Assessment)
在这一层次中,云端服务供应商可以提交两种类型的报告,一种是依据CSA STAR(Security, Trust & Assurance Registry;STAR)的自我评估问卷(Consensus Assessments Initiative Questionnaire;CAIQ),描述各项已符合安全要求的作法与因应措施,然后将它传送到CSA的註册管理单位(STAR Registry)来进行审查;而另一种则是依据云端控制矩阵中所要求的98项安全控制措施,逐条回答已经实施的作法以及现况。

云端服务供应商向STAR Registry所提交的自我评鑑报告,云端安全联盟会在其网站(https://cloudsecurityalliance.org/star/registry/)上提供已认可的註册记录,让公眾可以直接查询,这些记录将可以协助云端服务的消费者,了解并评估服务供应商的各项安全控制的作法,目前这项服务无论是註册或查询,都是可以免费进行的。
在这个评鑑阶段中,由云端安全联盟所提供可免费下载的自我评估问卷(CAIQ),提供了超过140项针对云端服务供应商、消费者和云端安全稽核人员可能想要了解的安全问题,服务供应商可以自行填答(Yes or No)并提出描述说明,透过自我揭露的各项安全作法,用来作為消费者在选择云端服务时,可评估安全风险的最佳参考资料。
服务供应商必须确保自我评鑑的更新週期,不得小於12个月,也就是说至少每年都需要重新自我评鑑一次,以确保各项安全控制措施的更新,能够及时?#20174;?#22312;评鑑的内容之?#23567;?#22914;果没有及?#22791;?#26032;,云端安全联盟会将未更新的报告註记為不认同,如果超过一年六个月都还没有更新的话,就会直接将这笔记录从註册资料库中移除。

▲CSA STAR网站提供公眾可查询的厂商註册记录。

第二层:STAR?#29616;ぁ?#31532;三方独立评鑑(STAR Certification – Third PartyAssessment)
在第二层的评鑑之中,云端安全联盟将会结合ISO 27001和云端控制矩阵的安全控制措施要求,透过第三方验证单位(目前配合的验证单位是BSI英国标準协会)来实施独立的安全查核,针对云端系统的成熟度进行评分。
这项安全查核将採用国?#26102;?#28310;普遍应用的规划、实施、检查、改善行动(PDCA)原则,并依照云端控制矩阵中对云端系统的安全要求来进行,最后所获得已量化的评分,即可作為管理阶层进行评估改善的参考。
第三层:基?#24230;现?#30340;?#20013;?#30417;控(Continuous Monitoring based Certification)
第三层是CSA STAR?#29616;?#30340;?#30001;歟?#30446;标是希望透过?#20013;?#33936;集到的稽核证据,即时地监控云端安全?#30446;?#21046;,?#20113;?#31526;合消费者的安全要求,此一阶段的实施做法,目前则还在发展之?#23567;?
云端安全开放?#29616;?#30340;实施现况
目前,云端安全开放?#29616;?#26550;构?#28304;断?#26399;的导入计画阶段,已经实施的是第一层的自我评鑑要求,已经获得许多云端服务供应商的响应参与。第二层的做法预计在2013年开始执行,至於第三层的?#20013;?#30417;控要求,预计最晚会在2015年完成。
对云端服务供应商而言,实施导入云端安全开放?#29616;?#26550;构的安全要求,不是為了?#38750;?#21478;外一项?#29616;ぃ?#32780;是能够具体的提供其云端服务安全管理的证明,同时也确认自己有能力来因应可能发生的安全事件,能够?#26723;?#20113;端服务的营运风险,建立消费者对於业者的信心。
至於对消费者?#27492;担?#21017;是获得了一个透明公开的管道,可?#32536;?#30693;云端服务供应商的安全管理要求与?#23548;?#20570;法,评估是否与自身的安全需求能够趋於一致,并且可?#26376;?#36275;组织的安全政策与要求。
<本文作者花俊杰曾任IT杂誌主编、资安顾问,拥多种资讯安全相关?#29616;ぃ?#33258;詡為资安传教士,?#19981;?#36814;读者透过[email protected]与之分享资安心得。>

企业应如何部署完整的BYOD安全策略?

1 Comment 安全技术

关键字:BYOD 安全策略 移动安全
对于企业而言,一个完整的BYOD部署策略都包含哪些方面?对此有关安全厂商又有哪些看法和建议呢?让我们来听一听有关专?#19994;?#35828;法。

赛门铁克公司中国区安全产品总监卜宪录表示,BYOD引发的担忧与驾驶汽?#26723;?#25285;忧非常相似。两者都存在潜在的危险。但是,这些危险可以通过采取恰当的防护和工具而减轻。而移动应用管理和移动设备管理是预防BYOD潜在危险的必要解决方案。

在新的安全威胁出现以后,企业总要有相应的应对措施。为此赛门铁克给企?#26723;?#24314;议是:

第一,对企业而言应该有一支专家团队,你的员工应该有良好的风险防范意识,人是最重要的基础。现在的黑客非常有组织,他很容易拿到各种精良的武器跟工具,但企?#26723;腎T人?#27604;?#38750;常有限,受到的培训跟风险的意识也是相对薄弱的,所以这一场战争在对抗性上面临着巨大差距。

第二,除了人以外很重要的是知识跟情报,或者说是企?#26723;?#39044;警系统。如果你连企?#26723;?#23433;全态势都不清楚,有如何去对抗这些新的攻击手法、对抗这些新的危险?

第三个,以前我们传统的安全防范手段都是由很多的单点的产品拼凑在一起,而我们的建议是什么呢?企业应该更多考虑那些做过整合的解决方案,转换自己的这个思维的方式。要有整体的解决方案支持,才有可能在新?#37027;?#21183;下取得安全防护。

如何才能部署一个完整的移动终端策略?对此卜宪录?#26723;潰骸?#25105;想从移动终端上应该从几个层面上来看。第一要保证设备安全,设备级的安全,包括管理层面;第二是设备之上应用的安全,APP的安全,包括它的管理安全;第三个层面是存储在这些应用跟设备上的数据的安全。设备、应用跟数据这三个层面都要有综合防范的手段跟措施,这些都是关于终端跟上面的信息的。还有一个很重要的是人,人跟信息之间的互动,包括访问控制、身份识别,这些东西全部加在一起才能保护你智能终端的一个安全。”

卜宪录表示:只要准备得当,移动应用可以对业务产生非常积极的影响,并对企业提出了具体指导方针:

可以对移动技术保持谨慎,但不能抵触,开?#21152;?#25509;移动技术。企业应采取积极措施,并仔细规划有效的移动战略部署。

从对员工有最大生产效益的应用开始部署移动应用。开始部署移动应用的最佳方式之一就是从能对业务产生即时影响的移动应用程序开始着手。

向创新型企业学习 —— 将风险最小化的同时获取利益。关键是意识到伴随移动应用而来的风险,例如信息泄露,并效仿创新型企业采取的较为成功的方法。

趋势科技中国区高级产品经理刘政平对企业部署BYOD策?#32536;目?#27861;是:“一方面,要从内?#23458;?#21892;新一代的Mobile设备安全管控、包括管理流程。另一方面,要从外部对客户的平台安全进行提升,在这两个方面采取不同的策略、新的管理流程,这是一个必然的发展趋势。”

对此,趋势科技提出建议:针对目前移动设备平台很分散、应用众多的特点,企业首先要从内部将离散的平台、非统一标准的平台集成到一个安全管控的平台上,形成统一的安全管控。

从外部来讲,也要不断强化平台的安全保护和安全管控。围绕着保护移动终端的数据安全目标,企?#26723;?#31227;动终端安全管理战略需要从移动设备管理、移动系统安全及移动应用管理这三个层面进行思考。

通过部署趋势科技移动终端安全管理企业版(Trend Micro Mobile Security),企业能够保护大量智能终端和移动设备,并拥有完全?#30446;墑有?#21644;控制管理,允许员工可以自由地在跨物理、虚拟、移动和云环境自由共享数据及网络资源。不仅能够?#26723;?#20225;业部署成本和减少管理移动设备的复杂度,避免机密数据外泄,同时确保移动设备能够安全的存取访问企业网络资源。

东软集团网络安全产品营销中心产品策划部郑玮则认为:一个完整的企业移动安全策略应包含哪些方面:终端命名(应制定单位内部的终端命名规定);终端的帐号口令管理;应用软件部署应用;补丁更新策略。

此外,还需要做到独立?#29992;?#26426;制让数据存取安全不间?#24076;?#21363;在移动设备操作系统?#29616;?#34892;?#29992;?#24212;用程序,以确保?#26029;?#20174;传送到接收的过程中,随时保持安全状态。如果通过移动设备浏览网页时,需确认页面上有如VeriSignSSL的凭证,便可多一层安全屏障。

另外郑玮还强调:要让员工使用自己熟悉的工具:“有些移动设备的防护解决方法是直接限制使用的范围,譬如企业数据只能在其规范的领域里读取,不得合并在个人习惯使用的应用程序上操作。如此不仅让员工对公司的安全政策产生排斥情绪,更抹杀了移动设备带来的便利性。”

郑玮提出:较好的做法是,?#29992;?#26082;有的应用程序,将?#29992;?#19982;数据防护巧妙地融合在用户接口与移动应用程序上,有效地将安全政策从企业内部?#30001;?#33267;移动设备上,同时也能保持员工配合安全政策的意愿。

而星网锐捷网络有限公司产品与解决方案市场部经理曲?#25226;蟮目?#27861;则是:如果移动设备已被普遍应用于办公场景,那么涉及移动设备相关的MDM,MDAC(移动设备访问授权)等应该是比较完整的移动设备安全策略。然而他强调:“当然,目前来看必要性还没有那么?#20426;!?/p>

原文出自【比特网】,转载请保留原文链接:http://sec.chinabyte.com/452/12633952.shtml

用CAIN实施ARP欺骗测试

 

首先启用嗅探

clip_image001

选择要嗅探的网卡

clip_image002

扫描网段上的所有主机的MAC地址

clip_image003

clip_image004

进入APR页面,左边?#30446;?#37324;添加要进行ARP欺骗的主机地址,在右边?#30446;?#37324;,选择那台主机的网关

clip_image005

最后启用APR

clip_image006

这是,APR会向那台主机和他的网关发送ARP相应,告诉他们APR主机的MAC地址(e9:9a:1a),就是响应的MAC地址

clip_image007

这时查看目标主机的ARP表:

网关的MAC地址已经变成了APR主机的MAC地址,而不是路由器的MAC地址(71:7b:a0),说明欺骗成功

clip_image008

这样,APR主机会拦截主机要网关或网关到主机的数据包,使他们先经过APR主机,再转发的对端,这样就能够在APR主机上进行抓包,查?#27492;?#20204;间的通信内容,密码等资料

clip_image009

轻量级调试器神器 – mimikatz – 直接抓取

No Comments 安全技术

用这个神器直接从 lsass.exe 里获取windows处于active状态账号明文密码的文章
http://pentestmonkey.net/blog/mimikatz-tool-to-recover-cleartext-passwords-from-lsass
自己尝试了下用 win2008 r2 x64 来测试


最后测试成功 wdigest 就是我的明文密码
我还测过密码复杂度在14位以上
包含数字 大小写字母 特殊?#22336;?#30340;密码
一样能抓出明文密码来
以前用 wce.exe 或 lslsass.exe 通常是只能从内存里顶多抓出active账号的 lm hash 和 ntlm hash
但用了这个神器抓出明文密码后
由此我们可以反推断 在 lsass.exe 里并不是只存有 lm hash 和 ntlm hash 而已
应?#27809;?#23384;在有你的明文密码经过某种?#29992;?#31639;法 (注意: 是?#29992;?#31639;法 而不是hash算法 ?#29992;?#31639;法是可逆的 hash算法是不可逆的)
这样这个?#29992;?#31639;法是可逆的 能被解密出明文
所以进程注入 lsass.exe 时 所调用的 sekurlsa.dll 应该包含了对应的解密算法
逆向功底比较好的童鞋可以尝试去逆向分析一下
然后这个神器的功能肯定不仅仅如此 在我看来它更像一个轻量级调试器
可以提升进程权限 注入进程 读取进程内存等等
下面?#25925;?#19968;个 读取扫雷游戏的内存的例子
我们还可以通过pause命令来挂起该进程 这个时候游戏的时间就静止了
总之这个神器相?#34987;?#20029; 还有更多能力有待各黑阔们挖掘 =..=~
站长评论:
抓取 lsass.exe 中的用户明文密码:
//提升权限privilege::debug
//注入dll
inject::process lsass.exe sekurlsa.dll
//抓取密码
@getLogonPasswords经测试,通?#20445;?/p>

Windows Server 2003
Windows Server 2008
Windows Vista
Windows 7
Windows 7 SP1

貌似只有 Windows 2000 与 Windows XP 无法使用。
不过,2000/xp 可以用以前的 FindPassword ,Windows 2003 – Windows 7 微软的这个处理机制没有变。
域?#37096;?#20197;,理论上是没问题的,登录过都在 lsass.exe 里面。
原理就是登陆的时候输入的密码,经过 lsass.exe 里的 wdigest 和 tspkg 两个模块调用后,它们对之进行?#29992;?#22788;理,而没有进行擦除,而且该?#29992;?#36890;过特征可以定位,并且按照微软的算法可逆。
只要登陆过,就可以抓出来,它进行枚举的,这一切都是微软的错。
简单地说,在 Windows 中,当用户登录时,lsass.exe 使用一个可逆的算法,?#29992;?#36807;的明文密码,并且把密文保存在内存中,没有清理,然后可以抓出来,还原。
也就是说,开机以后,只要是登陆过的用户,在没重启前(因为重启内存就清零了,这里不包括使用其他方法清理内存),都可以抓出来,注销也是无用的,因为内存中的密码并没有清除,所以?#25925;?#21487;以抓出来的。
我想微软可能会出个补丁,清理这块……
这玩意儿功能还有很多,自己看看?#38382;?#20363;如:ts,是调用 mimikatz.sys 隐藏登陆的终端。
这应该算是密码泄露,很?#29616;?#30340;漏洞,估计微软会出补丁。
在远程终端(3389、mstsc.exe)、虚拟桌面中抓取密码的方法:
通常你在远程终端中运行该程序会提示:存储空间不足,无法处理此命令。
这是因为在终端模式下,不能插入远线程,跨会?#23433;?#33021;注入,你需要使用如下方法执行该程序:
首先提取几个文件,只抓取密码的话,只需要这几个文件:

mimikatz_trunk\tools\PsExec.exe
mimikatz_trunk\Win32\mimikatz.exe
mimikatz_trunk\Win32\sekurlsa.dll

打包后上传至目标服务器,然后解?#25925;?#25918;,注意路径中绝对不能有中文(可以有空格)!否则加载DLL的时候会报错:找不到文件。
然后使用以下任?#25105;?#31181;方法即可抓取密码:
//最简单实用的方法,使用 PsExec.exe 启动。
//在本机启动交互式命令提示窗口psexec \\127.0.0.1 cmd.exe//启动 mimikatz.exeC:\mimikatz_trunk\Win32\mimikatz.exe//提升权限privilege::debug//注入dll,要用绝?#26376;?#24452;!并且路径中绝对不能有中文(可以有空格)!inject::process lsass.exe “C:\mimikatz_trunk\Win32\sekurlsa.dll”
//抓取密码
@getLogonPasswords
//?#39034;觶?#19981;要用 ctrl + c,会导致 mimikatz.exe CPU 占用达到 100%,死循环。
exit
//*********************************************************
//使用 At 启动at ***
//*********************************************************
//创建服务方法sc create getpassword binpath=
“cmd.exe /c c:\xxx\mimikatz.exe < command.txt > password.txt”sc start getpasswordsc delete getpassword//*********************************************************
//telnet 远程命令管道telnet ****部分内容转自:轻量级调试器神器 – mimikatz – 直接抓取 Windows 明文密码!?#20445;?#26469;自:Nuclear’Atk 网络安全研究中心,本文地址:http://lcx.cc/?FoxNews=2265.htmlclip_image001 _Html_d5f147c28285f55f.jpg (82.36 KB)

2012-2-26 16:10

clip_image002

clip_image001[1] _Html_a483f2caa81ffac9.jpg (43.56 KB)

2012-2-26 16:10

clip_image003

clip_image001[2] _Html_f4d4df573b315c1b.jpg (42.25 KB)

2012-2-26 16:10

clip_image004

?#31243;窪dos攻击攻击与防御

No Comments 安全技术

?#31243;窪dos攻击攻击与防御
EMail: jianxin#80sec.com
Date: 2011-2-10
From: http://www.80sec.com/
[ 目录 ]
一 背景
二 应急响应
三 常见ddos攻击及防御
四 根源及反击
五 总结
一 背景
在前几天,我们运营的某网站遭受了一次ddos攻击,我们的网站是一个公益性质的网站,为各个厂商和白帽子之间搭建一个平台以传递安全问题等信息,我们并不清楚因为什么原因会遭遇这种无耻的攻击。因为我们本身并不从事这种类型的攻击,这?#27490;?#20987;技术一般也是比较粗糙的,所以讨论得比较少,但是既然发生了这样的攻击我们觉得分享攻击发生后我们在这个过程中学到得东西,以及针对这?#27490;?#20987;我们的想法才能让这次攻击产生真正的价?#25285;?#32780;并不是这样的攻击仅仅浪费大?#19994;?#26102;间而?#36873;?
另外,我们发现大型的企业都有遭受攻击的案例,但是大?#20197;?#21463;攻击之后的应对措施及学到的经验却分享都比较少,这导致各家都是自行的摸索经验,依然停留在一家企业对抗整个互联网的攻击的?#32622;媯?#32780;对于攻击者却是此次攻击针对你,下次攻击却是针?#36816;?#20102;,而且攻击之后无论是技术?#25925;?#36164;源都没有任何的损?#27169;?#36825;也是导致这?#27490;?#20987;频繁并且肆无忌惮的原因。
我们来尝试做一些改变:)
二 应急响应
在攻击发生后,第一个现象是我们的网站上不去了,但是依然可以访问到管理界面,我们登陆上去简单执行了命令:
netstat -antp
我们看?#25509;?#22823;量的链接存在着,并且都是ESTABLISHED状态,正常状态下我们的网站访问量没有这么高,如果有这么高我们相信中国的信息安全就有希望了,对于这样?#37027;?#20917;其实处理就比较简单,这是一次四层的攻击,也就是所有ip都是真?#26723;模?#30001;于目前为止只是消耗了webserver的网络连接资源,所以我们只需要简单的将这些ip在网络层封禁就可以,很简单,用下面的命令即可:
for i in `netstat -an | grep -i ‘:80 ‘|grep ‘EST’ | awk ‘{print $5}’ | cut -d : -f 1 | sort | uniq -c | awk ‘{if($1 > 50) {print $2}}’`
echo $i
echo $i >> /tmp/banip
/sbin/iptables -A INPUT -p tcp -j DROP -s $i
done
然后作为计划任务一分钟执行一次即可,很快,iptables的封禁列表?#32479;?#26021;了大量的封禁ip,我们简单的统计了下连接数最大的一些ip发现都来自韩国。为了保证系统的性能,我们调大了系统?#30446;?#25509;受的连接数以及对Nginx进行了每个连接能够进行?#37027;?#27714;速率,系统于是?#25351;?#20102;正常的运?#23567;?
正常状态一直?#20013;?#21040;第二天,但是到中午之后我们发现访问又出现了问题,网络很慢,使用ping发现大概出现了70%左?#19994;?#20002;包,在艰难的登陆到系统?#29616;?#21518;,发现系统已经很少有TCP的正常连接,为了查明原因,我们对系统进行了抓包:
tcpdump -w tmp.pcap port not 22
tcpdump -r tmp.pcap -nnA
我们发现攻击已经从应用层的攻击调整到了网络层的攻击,大量的目标端口是80的udp和icmp包以极快的速度充满了网络,一个包大小大概在1k左右,这次占据的资源?#30475;?#26159;带宽资源了,即使在系统上做限制也解决不了这个问题,不过也没有关系,对于网络层的问题我们可以在网络层上做限制,我们只需要在网络上把到达我们ip的非TCP的所有包如UDP和ICMP等协议都禁止掉即可,但是我们没有自己的服务器也缺乏对网络设备?#30446;?#21046;权,目前是由工信部CERT提供支持的,由于临时无法协调进行相应的操作,后果如大家看到,我们的服务很慢,基本上停止了服务,在一?#38382;?#38388;之后攻击者停止了攻击,服务才进行了?#25351;矗?#24456;憋屈是么?但是同时我们得到了很多热心朋友的帮助,得到了更好的网络和服务器资源,在网络资源方面的能力得到了很大的提升,缓解了这方面的问题,这里?#36816;?#20204;表示?#34892;弧?
三 常见ddos攻击及防御
继续秉承80sec的”Know it then hack it?#20445;?#36825;里简单谈一下ddos攻击和防御方面的问题。ddos的全称是分布式拒绝服务攻击,既然是拒绝服务一定是因为某些原因而停止服务的,其中最重要的也是最常用的原因就是利用服务端方面资源的有限性,这种服务端的资源范围很广,可以简单的梳理一个请求正常完成的过程:
1        用户在客户?#34429;?#35272;器输入请求的地址
2        浏览器解析该请求,包括分析其中的dns以明确需要到达的远程服务器地址
3        明确地址后浏览器和服务器的服务尝试建立连接,尝试建立连接的数据包通过本地网络,中间路由最终艰苦到达目标网络再到达目标服务器
4        网络连接建立完成之后浏览器根据请求建立不同的数据包并且将数据包发送到服务器某个端口
5        端口?#25104;?#21040;进程,进程接受到数据包之后进行内部的解析
6        请求服务器内部的各种不同的资源,包括后端的API以及一些数据库或者文件等
7        在逻辑处理完成之后数据包按照之前建立的通道返回到用户浏览器,浏览器完成解析,请求完成。
上面各个点都可以被用来进行ddos攻击,包括:
1        某些著名?#30446;?#25143;端劫持病毒,还记得访问百度跳?#21387;?#30340;事情么?:)
2        某个大型互联网公司发生的dns劫持事件,或者直接大量的dns请求直接攻击dns服务器,这里可以使用一些专?#26723;?#31532;三方dns服务来缓解这个问题,如Dnspod
3        利用建立网络连接需要的网络资源攻击服务器带宽使得正常数据包无法到达如udp的洪水攻击,消?#37027;?#31471;设备的cpu资源以使得数据包不能有效转发如icmp和一些碎片包的洪水攻击,消耗服务器方建立正常连接需要的资源如syn flood或者就是占用大量的连接使得正常的连接无法发起,譬如这次的TCP flood
4        利用webserver的一些特点进行攻击,相比nginx?#27492;担琣pache处理一个请求的过程就比较笨重。
5        利用应用程序内部的一些特性攻击程序内部的资源如mysql,后端消耗资源大的接口等等,这也就是传统意义上的CC攻击。
这里涉及到攻防的概念,但是?#23548;?#19978;如果了解对方的攻击点和攻击手法,防御会变成简单的一个拼资源的过程,不要用你最弱的地方去抗人家最强的地方,应该从最合适的地方入手把问题解决掉,譬如在路由器等设备上解决应用层攻击就不是一个好的办法,同理,在应用层尝试解决网络层的问题也是不可能的,简单?#27492;担?#30446;标是只让正常的数据和请求进入到我们的服务,一个完善的防御体系应该考虑如?#24405;?#20010;层面:
1        作为用户请求的入口,必须有良好的dns防御
2        与你的价值相匹配的带宽资源,并且在核心节点上布置好应用层的防御策略,只允许你的正常应用的网络数据包能够进入,譬如封?#32972;?#20102;80以外的所有数据包
3        有支持你的服务价?#26723;?#26426;器集群来抵抗应用层的压力,有必要的话需要将一个http请求继续分解,将连接建立的过程压力分解到其他的集群里,这里似乎已经有一般的?#24067;?#38450;火墙能做这个事情,甚?#20004;?#27491;常的http请求解析过程都进行分解,保证到达后端的是正常?#37027;?#27714;,剔除掉畸形?#37027;?#27714;,将正常?#37027;?#27714;?#37027;?#27714;频度等行为进行记录和监控,一旦发生异常就在这里进行应用层的封杀
每个公司都有自己对自己价?#26723;?#35780;?#26469;?#32780;决定安全?#24230;?#19978;的大小,每一次攻击也会涉及到利益的存在,正如防御因为种种原因譬如?#24230;?#19978;的不足和实施过程中的不完美,有着天生的弱点一样,攻击也是有着天生的弱点的,因为每一次攻击涉及到不同的环节,每个环节都可能由不同水平的人完成,他所拥有的资源,他使用的工具和技术都不会是完美的,所以才有可能进行防御,另外,我相信进行DDOS攻击的人是一个固定的行业,会有一些固定的人群,对于其中使用的技术,工具,资源和利益链都是比较固定的,与之相?#32536;?#26159;各个企业却缺乏相应的沟通,以个人企业对抗一个产业自然是比较困难,而如果每一个企业都能将自己遭受攻击时的经验分享出来,包括僵尸网络的大小及IP分布,攻击工具的特征,甚至有能力?#30446;?#20197;去分析背后的利益点?#23433;?#20316;者,那么每一次攻击都能让大?#19994;?#25972;体防御能力上升,让攻击者的攻击能力有损失,我们很愿意来做这个事情。
四 根源及反击
我困惑的是一点,攻击我们并不能得到?#23548;?#30340;好处为什么?#25925;?#26377;人来攻击,而且听说其他公司都有被攻击?#37027;?#20917;,我觉得有一点原因就是攻击我们的确得不到什么好处,但是?#23548;?#19978;攻击者也并不损失什么,无论是资源上?#25925;?#27861;律风险上,他不会因为一次攻击而损失太多,而相比之下,服务提供者损失的东西却太多了,这从经济学角度来讲就是不平衡的,我们处于弱势。
一般而言,的确对于作恶者是没有什么惩罚措施,但是这次,我们觉得我们是可以做一些事情的,我们尝试挖掘背后的攻击者,甚至清除这个僵尸网络。
首?#26085;?#27425;攻击起源于应用层的攻击,所?#36816;?#26377;的ip都是真?#26723;模?#32463;过与CERT沟通,也发现这些ip都是韩国的,并且控制端不在国内,因为期间没有与国内有过通讯,即使在后面换成了udp+icmp的flood,但是依然是那些韩国的ip,这很有意思,正常情况下udp+icmp的数据包是可以伪造的,但是这里居然没有伪造,这在后面大概被我们证实了原因。
这些ip是真实存在的ip,而且这些ip肯定在攻击完我们之后一定依然跟攻击者保持着联系,而一般的联系方式因为需要控制的方便都是dns域名,既然如此,如果我们能挖掘到这个dns域名我们就可能间接的挖掘出真正幕后黑手在哪里。首先,我们迅速的找出了这次攻击ip中开放了80端口的机器,因为我们对80端口上的安全问题比较自信,应该很快可以获知这些ip背后的细节(80sec名称由来),我们发现大部分是一些路由器和一些web的vpn设备,我们猜测这次攻击的主要是韩国的个人用户,而个人用户的机器操作系统一般是windows所以在较高版本上发送数据包方面可能有着比较大的限制,这也解释了为什么即?#25925;莡dp+icmp的攻击我们看到的大都是真实ip。发现这些路由设备之后我们尝试深入得更多,很快用一些弱口令譬如admin/admin登陆进去,果然全世界的网民都一样,admin/admin是天生的入口。
登陆进去一些路由之后我们发现这些路由器里面存在一个功能是设置自己的dns,这意味着这下面的所有dns请求都可以被定向到我们自己设置的dns服务器,这对于我们去了解内部网络的细节会很有用,于是我们建立了一个自己的dns服务器,并且开启了dns请求的日志功能以记录所有请求的细节。我们大约控制了20台路由器的dns指向,并且都成功重定向到我们自己的服务器。
剩下的就是简单的数据分析,在这之前我们可以对僵尸网络?#30446;?#21046;域名做如下的猜测:
1        这个dns应该为了灵活?#30446;?#21046;域名的缓存时间TTL一般不会特别长
2        这个dns应该是定期的被请求,所以会在dns请求里有较大的出现比例
3        这个dns应该是为了控制而存在的,所以域名不应该在搜索引擎以及其他地方获得较高的访问指数,这与2中的规则配合起来会比较好确定,是一个天生的矛盾。
4        这个dns应该在各个路由下面都会被请求
这些通过简单的统计就很容易得出答案,我们发现了一些3322的通用恶意软件域名但是发现它并不是我们需要的,因为只有少数机器去访问到,经过一些时间之后最后我们发现一个域名访问?#22353;雗aver(韩国的一个门户)的访问量持平,workgroup001.snow****.net,看起?#27492;?#20046;对自己的僵尸网络管理很好嘛,大概有18台机器访问过这个域名,这个域名的主机托管在?#24405;?#22369;,生存时间TTL在1800也就是半小时,这个域名在所有的搜索引擎中都不存在记录,是一个韩国人在godady一年?#23433;?#27880;册的,同时我们访问这个域名指向主机的3389,简单的通过5下shift就判断出它上面存在着一个典型的windows后门,似乎我们?#19994;?#23427;了,不是么?经过后续的观察,一?#38382;?#38388;后这个域名指向到了127.0.0.1,我们确信了我们的答案,workgroup001.snow****.net,看起?#27492;?#20046;对自己的僵尸网络管理很好嘛:)
这是一次典型的ddos攻击,攻击之后我们获得了参与攻击的主机列表和控制端的域名及ip,相信中国和韩国的cert对于清理这次的攻击源很有兴趣,我们是有一些损失,但是攻击者也有损失了(大概包括一个僵尸网络及一个控制端域名,甚至可能包括一?#25991;?#37096;的法律调查),我们不再是不平等的了,不是么?
五 总结
正如一个朋友所讲的,所有的防御是不完美的正如攻击是不完美的一样,好的防御者在提升自己的防御能力趋于完美的同时也要善于寻找攻击者的不完美,寻找一次攻击中的漏洞,不要对攻击心生?#24535;澹?#23545;于Ddos攻击而言,发起一次攻击一样是存在漏洞的,如果我们都能够擅长利用其中的漏洞并?#26131;?#20303;后面的攻击者那么相信以后的ddos攻击案例将会减少很多,在针对目标发起攻击之前攻击者也会做更多的权衡,损失,利益和法律。
本站内容均为原创,转载请务必保留署名与链接!
?#31243;窪dos攻击攻击与防御:

怎麼有效的防止ARP攻击

No Comments 安全技术

ARP欺骗和攻击问题,是企业网络的心腹大患。关于这个问题的讨论已经很深入了,对ARP攻击的机理了解的很透彻,各?#22336;?#33539;措施也层出不穷。

但问题是,现在真正摆脱ARP问题困扰了吗?从用户那里了解到,虽然尝试过各种方法,但这个问题并没有根本解决。原因就在于,目前很多种ARP防范措施,一是解决措施的防范能力有限,并不是最根本的办法。二是对网络管理?#38469;?#24456;大,不方便不实用,不具备可操作性。三是某些措施对网络传输的效能有损失,网速变慢,带宽浪费,也不可取。

本文通过具体分析一下普遍流行的四?#22336;?#33539;ARP措施,去了解为什么ARP问题始终不能根治。

上篇:四种常见防范ARP措施的分析

一、双绑措施

双绑是在路由器和终端上都进行IP-MAC绑定的措施,它可以对ARP欺骗的两边,伪造网关和截获数据,都具有?#38469;?#30340;作用。这是从ARP欺骗原理上进行的防范措施,也是最普遍应用的办法。它对付最普通的ARP欺骗是有效的。

但双绑的缺陷在于3点:

1、在终端上进行的静态绑定,很容易被升级的ARP攻击所捣毁,病毒的一个ARP–d命令,就可以使静态绑定完全失效。

2、在路由器上做IP-MAC表的绑定工作,费时费力,是一项繁琐的维护工作。换个网卡或更换IP,都需要重新配置路由。对于流动?#32536;?#33041;,这个需要随时进行的绑定工作,是网络维护的巨大负担,网管员几乎无法完成。

3、双绑只是让网络的两?#35828;?#33041;和路由不接?#38556;?#20851;ARP信息,但是大量的ARP攻击数据?#25925;?#33021;发出,还要在内网传输,大幅?#26723;?#20869;网传输效率,依然会出现问题。

因此,虽然双绑曾经是ARP防范的基础措施,但因为防范能力有限,管理太麻?#24120;?#29616;在它的效果越来?#25509;?#38480;了。

二、ARP个人防火墙

在一些杀毒软件中加入了ARP个人防火墙的功能,它是通过在终?#35828;?#33041;上对网关进行绑定,保证不受网络中假网关的影响,从而保护自身数据不被窃取的措施。ARP防火墙使用范围很广,有很多人以为有了防火墙,ARP攻击就不构成威胁了,其实完全不是那么回事。

ARP个人防火墙也有很大缺陷:

1、它不能保证绑定的网关一定是正确的。如果一个网络中已经发生了ARP欺骗,有人在伪造网关,那么,ARP个人防火墙上来就会绑定这个错误的网关,这是具有极大风险的。即使配置中不默认而发出提示,缺乏网络知识的用户恐怕也无所适从。

2 、ARP是网络中的问题,ARP既能伪造网关,也能截获数据,是个“双头怪?#34180;?#22312;个人终端上做ARP防范,而不管网关那端如何,这本身就不是一个完整的办法。ARP个人防火墙起到的作用,就是防止自己的数据不会被盗取,而整个网络的问题,如掉线、卡滞等,ARP个人防火墙是无能为力的。

因此,ARP个人防火墙并没有提供可靠的保证。最重要的是,它是跟网络稳定无关的措施,它是个人的,不是网络的。

三、VLAN和交换机端口绑定

通过划分VLAN和交换机端口绑定,以图防范ARP,也是常用的防范方法。做法是细致地划分VLAN,减小广播域的范围,使ARP在小范围内起作用,而不至于发生大面积影响。同时,一些网管交换机具有MAC地?#36153;?#20064;的功能,学习完成后,再关闭这个功能,就可以把对应的MAC和端口进行绑定,避免了病毒利用ARP攻击篡改自身地址。也就是说,把ARP攻击中被截获数据的风险解除了。这种方法确?#30340;?#36215;到一定的作用。

不过,VLAN和交换机端口绑定的问题在于:

1、没有对网关的任何保护,不管如何细分VLAN,网关一旦被攻击,照样会造成全网上网的掉线和?#34987;盡?/p>

2、把每一台电脑都牢牢地固定在一个交换机端口上,这种管理太死板了。这根本不适合移动终端的使用,从办公?#19994;?#20250;议室,这台电脑恐怕就无法上网了。在无线应用下,又怎么办呢??#25925;?#38656;要其他的办法。

3、实施交换机端口绑定,必定要全部采用高级的网管交换机、三层交换机,整个交换网络的造价大大提高。

因为交换网络本身就是无条件支持ARP操作的,就是它本身的漏洞造成了ARP攻击?#30446;?#33021;,它上面的管理手段不是针对ARP的。因此,在现有的交换网络上实施ARP防范措施,属于以子之矛攻子之盾。而?#20063;?#20316;维护复杂,基本上是个费力不讨好的事情。

四、PPPoE

网络下面给每一个用户分配一个帐号、密码,上网时必须通过PPPoE?#29616;ぃ?#36825;种方法也是防范ARP措施的一种。PPPoE拨号方式对封包进行了二次封装,使其具备了不受ARP欺骗影响的使用效果,很多人认为?#19994;?#20102;解决ARP问题的终极方案。

问题主要集中在效率和实用性上面:

1、PPPoE需要对封包进行二次封装,在接入设备上再解封装,必然?#26723;?#20102;网络传输效率,造成了带宽资源的浪费,要知道在路由等设备上添加PPPoE Server的处理效能和电信接入商的PPPoE Server可不是一个数量级的。

2、PPPoE方式下局域网间无法互访,在很多网络都有局域网内部的域控服务器、DNS服务器、邮件服务器、OA系统、资料共享、打印共享等等,需要局域网间相互通信的需求,而PPPoE方式使这一切都无法使用,是无法被接受的。

3、不使用PPPoE,在进行内网访问时,ARP的问题依然存在,什么都没有解决,网络的稳定性?#25925;?#19981;?#23567;?/p>

因此,PPPoE在技术上属于避开底层协议连接,眼不见心不?#24120;?#36890;过牺牲网络效率换取网络稳定。最不能接受的,就是网络只能上网用,内部其他的共享就不能在PPPoE下进行了。

通过对以上四种普遍的ARP防范方法的分析,我们可以看出,现有ARP防范措施都存在问题。这也就是ARP即使研究很久很透,但依然在?#23548;?#20013;无法彻底解决的原因所在了。

 

 

道高一尺魔高一丈,网络问题必定需要网络的方法去解决。目前,欣全向推广的免疫网络就是彻底解决ARP问题的最?#23548;?#30340;方法。

从技术原理上,彻底解决ARP欺骗和攻击,要有三个技术要点。

1、终端对网关的绑定要坚实可靠,这个绑定能?#22351;种?#34987;病?#38236;?#27585;。

2、接入路由器或网关要对下面终端IP-MAC的识别始终保证唯一准确。

3、网络内要有一个最可依?#26723;?#26426;构,提供对网关IP-MAC最强大的保护。它既能够分发正确的网关信息,又能够对出现的假网关信息立即封?#34180;?/p>

免疫网络在这三个问题上,都有专门的技术解决手段,而且这些技术都是厂家欣全向的技术专利。下面我们会详细说明。现在,我们要先做一个免疫网络结构和实施的简单介绍。

免疫网络就是在现有的路由器、交换机、网卡、网线构成的普通交换网络基础上,加入一套安全和管理的解决方案。这样一来,在普通的网络通信中,就融合进了安全和管理的机制,保证了在网络通信过程中具有了安全管控的能力,堵上了普通网络对安全从不设防的先天漏?#30784;?/p>

clip_image001

免疫网络的结构

实施一个免疫网络不是一个很复杂的事,代价并不大。它要做的仅仅是用免疫墙路由器或免疫网关,替?#22351;?#29616;有?#30446;?#24102;接入设备。在免疫墙路由器下,需要自备一台服务器24小时运行免疫运营中心。免疫网关不需要,已?#28304;?#26381;务器。这就是方案的所需要的?#24067;?#35843;整措施。

软?#32536;?#32593;络调整是IP规划、分组策略、终端自动安装上网驱动等配置和安装工作,以保证整个的安全管理功能有效地运?#23567;?#20854;实这部分工作和网管员对网络日常的管理没有太大区别。

clip_image003

免疫网络的监控中心

免疫网络具有强大的网络基础安全和管理功能,对ARP的防范仅是其十分之一不到的能力。但本文谈的是ARP问题,所以我们需要回过头来,具体地解释免疫网络对ARP欺骗和攻击防范的机理。至于免疫网络更多?#37027;?#22823;,可以后续研?#20426;?/p>

前述治理ARP问题的三个技术要点,终端绑定、网关、机构三个环节,免疫网络分别采用了专门的技术手段。

1、终端绑定采用了看守式绑定技术。免疫网络需要每一台终端自动安装驱动,不安装或?#23545;?#23601;不能上网。在驱动中?#30446;?#23432;式绑定,就是把正确的网关信息存贮在非公开的位置加以保护,任何对网关信息的更改,由于看守程序的严密监控,都是不能成功的,这就完成了对终端绑定牢固可靠的要求。

2、免疫墙路由器或免疫网关的ARP先天免疫技术。在NAT转发过程中,由于加入了特殊的机制,免疫墙路由器根本不理会任何对终端IP-MAC的ARP申告,也就是说,谁都无法欺骗网关。与其他路由器不同,免疫墙路由器没有使用IP-MAC的列表进行工作,当然也不需要繁琐的路由器IP-MAC表绑定和维护操作。先天免疫,就是不用管也具有这个能力。

3、保证网关IP-MAC始终正确的机构,在免疫网络中是一套安全机制。首先,它能够做到把从路由器中取到的真实网关信息,分发到每一个网内终端,而安装有驱动的终端,只接受这样的信息,其他信息不能接受,保证了网关的唯一正确性。其次,在每一台终端,免疫驱动都会拦截病毒发出的错误网关传播,不使其流窜到网络内,把ARP欺骗和攻击从根源上切断。

从以上三个措施来看,免疫网络确实真正解决了困扰已久的ARP问题,技术上是严谨的,应用上是可行的,成本也是相?#32536;?#24265;。所以,与常见的四种ARP防范办法比?#24076;?#20813;疫网络是解决ARP最根本的办法

出处:红黑联盟

匿名攻擊并不匿名,小心為上

No Comments 安全技术

adware(NASDAQ: RDWR)的安全专家近?#31449;?#21311;名性DDoS攻击发布研究报告,?#39047;?#21517;工具其实并不能真正地替志愿者掩?#24039;?#20221;,他们往往会成为黑客组织的替罪羔羊。

一般情况下,操纵网络攻击的黑客组织者对目标网络防护?#37027;?#20917;相当了解,通过技术手段,他们会首先确保自身的匿名性,而那些参与攻击的普通成员及志愿者可就没能逃开专业网络安全团队的监测及法律的制裁。

与僵尸网络中用户被动成为攻击者使用的跳板或肉鸡不同,加入黑客组织就意味着主动参与了攻击行为,参与者必须为自己的行为付出代价。2013年1月,三名参与针对PayPal、Visa、MasterCard等支付机构进行DDoS攻击的嫌疑人在伦敦被?#24230;?#29425;,他们均为著名黑客组织Anonymous的成员。

来自Radware ERT(紧急响应团队)的安全专家表示,通过Radware强大的AMS(攻击缓解系统)及经验丰富的技术?#20173;?#22242;队,Radware通过对全球范围内的每一起DDoS攻击进行研究,详细分析了攻击者的匿名手法与效果,最后得出如下结论:

? 攻击者需要在有效的DDos攻击和保持匿名之间进行选择,这就意味着,如果想让攻击生效,就很难保?#27490;?#20987;者的匿名性;

? 只有顶级的黑客能够在DDoS攻击中真正隐藏他们自己;

? 自愿参与黑客攻击的民众遵从黑客组织者的指导,确信自己可隐藏真?#26723;?#36523;份,而?#23548;?#19978;他们并没有被完全隐藏,等待他们的很可能是法律的诉讼和牢狱之灾。

通常,DDoS的组织者会在网络上公布黑客教程,并提供保持参与者匿名?#32536;?#26041;法和工具,如在YouTube上发布以?#25226;蟠型貳?#21629;名的使用指导,并结合VPN等方式,让志愿者确信自己的匿名性被进一步提升。从Radware的分析看,来自这类试图隐藏自己身份的DDoS攻击流量的比重在近几年中不断攀升,这也说明志愿者在网络攻击中的匿名意识正在增?#20426;?/p>

Radware的安全专?#19968;?#25351;出了各类匿名手法及相关工具组合的弱点,为网络安全防护人员提供防御匿名性DDoS攻击的相关参考。

linux下防范arp欺骗攻击

No Comments 安全技术

前两天家里的网断断续续,发现有人在用arp欺骗,其实真正碰?#25509;?#20154;在攻击的几率不大,大部分原因都是有人在用win下的诸如“P2P终结者”这样的软件导致的。再怎么bs那人也是没有用的,问题?#25925;?#35201;解决,win下?#25925;?#22909;办,现成的软件多的是 ,linux下面就要自己动手了^^。

arp欺骗的原理不多述,基本就是利用发 ?#22270;?#30340;arp数据包,冒充网关。一般在网上通讯的时候网关的IP和MAC的绑定是放在arp 缓存里面的,假的arp包就会刷新这个缓存,导致本该发送到网关的数据包发到了欺骗 者那里。解决的办法就是静态arp。

假设网关的IP是192.168.0.1,我们要 先得到网关的正确MAC,先ping一下网关:

ping 192.168.0.1

然后运行arp查看arp缓存中的网关MAC:

localhost~$ arpAddress       HWtype  HWaddress        Flags Mask   

Interface192.168.0.1   ether  00:12:34:56:78:9A    C             eth0

这里得到的网关MAC假定 为00:12:34:56:78:9A,C代表这个绑定是保存在缓冲里的,我们要做的就是把这个IP和 MAC静态的绑定在一起,首先建立/etc/ethers文件,输入以下内容:

192.168.0.1 00:12:34:56:78:9A

保存?#39034;觶?#20043;后便是应 用这个静态绑定:

localhost~$ arp -f

再运行arp查看:

localhost~$ arpAddress       HWtype  HWaddress        Flags Mask   

Interface192.168.0.1   ether  00:12:34:56:78:9A    CM            eth0

多了个M,表示静态网关 ,OK收工~

另外,如果你不会和局域网内的用户通讯的话,那么可以干脆 把arp解析关掉,假定你的网卡是eth0,那么可以运行:

localhost~$ ifconfig eth0 -arp

这样对付那些终结者软件就可以了,但是真的有人想攻击的话,这样?#25925;?#19981;够的,因为攻击者还可?#20113;?#39575;网关,解决的办法就是在网关和 局域网内机器上做双向绑定,原理方法同上,一般网吧里面也是这样做的。

 

【责任编辑:韩密生 TEL:(010)68476606】

Cisco和H3C交换设备 ARP病毒快速解决办法

No Comments 安全技术

Cisco交换机:
在中心交换机上show logging 发现如下日志
Apr 18 10:24:16.265: %IP-4-DUPADDR: Duplicate address 172.30.30.62 on Vlan711, sourced by 0009.6b84.189e;说明有ARP病毒,
2、执行conf t,mac-address static mac地址 vlan id drop;
3、对有ARP病毒的主机进行了处理,然后在中心交换机?#29616;?#34892;
no mac-address static mac地址 vlan id drop,使主机能访问网络资源.
4.问题解决

H3C交换机:
Dis log发现如下信息:
%Apr 30 07:43:18:753 2000 Longjing ARP/3/DUPIFIP:Duplicate address 192.168.1.1 o
n interface Vlan-interface101, sourced by 001b-b970-266d

<Longjing>dis mac-address 0016-e67c-7c9f
发现该mac是从g1/0/4上来的

进入该接口:
interface GigabitEthernet1/0/4
mac-address blackhole 001b-b970-266d vlan 101

然后?#19994;?#35813;机器拔除网线杀毒,然后再取消该接口下的限制
interface GigabitEthernet1/0/4
undo mac-address blackhole 001b-b970-266d vlan 101

 

【责任编辑:赵毅 TEL:(010)68476606】

30选5玩法