Linux hook函数简单实践

#起因 最近对hook函数比较感兴趣,希望能捕获所有某种系统调用,看网上有一篇文章(http://opensourceforu.com/2011/08/lets-hook-a-library-function/) 介绍hook malloc函数,但可能内核实现不同,4.4.0上有问题。特写一篇文章进行更新。 原文中,hook函数中调用printf,其实printf、fprintf等函数都会再调用malloc函数,导致segment fault。正确的方式应该是用snprintf写入内存,然后调用write函数输出。同理,如果在hook open函数的时候,调用了open函数,也会造成segment fault的问题。 #示例 a.c:  C |   copy code |?0102#include&lt;stdio.h>03#include&lt;malloc.h>04#include&lt;stdlib.h>05int main(void)06{07 int <em>p;08 printf("calling from main…\n");09 p=(int *)malloc(10);10 if(!p)11 {12 printf("Got allocation error…\n");13 exit(1);14 }15 printf("returning to main…\n");16 free(p); /</em> freeing memory from heap … Continue reading

Kubernetes对外服务

Kuberntets介绍 Kubernets是一个Google主导的机群管理系统,目前底层可以使用Docker,实现Docker实例的应用编排。Kubernets的介绍很多,本文简单介绍安装和使用的过程。更多资料可参考Kerbernets官网。 Kuberntets安装 Kubernets可以在虚拟机VM或安装Linux的服务器上安装,本文以Ubuntu Server服务器为例,详细可参见官网的Ubuntu安装指南。 先下载Kubernets源码,目前最新版为1.4.1

本文中存在两个节点,node3(192.168.200.13)和node4(192.168.200.14),node3作为控制节点和计算节点,node4作为计算节点。于是修改kubernetes/cluster/ubuntu/config-default.sh

以上就是对配置文件的全部改动,请放置在相应位置。然后进行安装:

如果不出错则会提示安装完毕。此时将Kubernets的命令放于PATH中。

然后安装dashboard和dns组件:

可能存在的问题: 如果需要重装,请运行KUBERNETES_PROVIDER=ubuntu ./kube-down.sh,停掉相关服务,然后要还原/etc/default/docker配置文件。 Kubernets会从Google的镜像仓库(gcr.io)获取某些镜像,但国内被墙了,所以可以选择一个http代理服务器,并在需要启动这些镜像的主机上为docker添加代理,方法是在/etc/default/docker中的开头添加:

然后重启docker:

完毕需要将代理去掉再重启docker,具体可参考这篇文章。 确保所有需运行这些镜像的节点本地都要有这些镜像!!,可以先在一个节点上用代理下载所有镜像,然后上传到私有仓库,再在其他节点上下载这些镜像即可。 在运行带有运行 google镜像时,如果本地已经有该镜像的时候,但配置文件中带有 imagePullPolicy: Always 时,则仍会从Google仓库去获取,一种方法是将其变为:

另一种方法是放到私有仓库中。 * 如果配置文件中没有指定imagePullPolicy,老版本会优先从本地找该版本的镜像,如有则直接启动;但发现1.4.1版本会优先pull。测试需要在配置文件中加入: 然后再运行安装或其他的命令。 Kubernetes会修改/etc/default/docker,请注意不要被覆盖原来的一些配置,否则docker … Continue reading

Django国际化

本文在django 1.7验证过 1 在项目settings.py中添加两行(+表示添加行):  Python |   copy code |?0102+ LOCALE_PATHS = (BASE_DIR+ "/locale",)03 04MIDDLEWARE_CLASSES = ( 05 ‘django.middleware.common.CommonMiddleware’,06 ‘django.contrib.sessions.middleware.SessionMiddleware’,07+ ‘django.middleware.locale.LocaleMiddleware’,08 ‘django.middleware.csrf.CsrfViewMiddleware’,09)10 2 在views.py中标记要翻译的字符串,格式为{% trans ‘字符串’%} 如  HTML |   copy code |?1{% load i18n %}2<!– 在页面最顶端加上load i18n–>3<!DOCTYPE html>4<!– 其他内容略去–>5<li id="menu-item-1810" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-has-children"><a href="/ui/users/login">{% … Continue reading

创新沙盒:“软件定义安全”不再是实验室产物

自从著名咨询机构Gartner在《The Impact of Software-Defined Data Centers on Information Security》 一文中提出软件定义安全(Software Defined Security,SDS)的概念后,软件定义与安全的结合已成为业界的前沿发展热点。背后的原因很直观:软件定义安全强调了安全控制平面与数据平面分离,从而在控制平面上可灵活调整应用策略,快速变更安全业务。 在安全可被软件定义后,新的安全业务可在企业网络中可新上线,特别是在数据中心中,可实现计算、存储、网络和安全的弹性控制,实现软件定义的数据中心SDDC。正是因为这些优秀的特性,解决了企业客户长期面临的安全管理和运营“痛点”,软件定义安全自从开始就引起了学术界和工业界极大的关注。 各大厂商都开始做相关的研究和研发工作,RSA大会一直是厂商们展现自己最新工作的舞台。如Check Point在RSA 2014大会上宣布推出软件定义防护(Software Defined Protection,SDP)革新性安全架构,可在当今日新月异的IT和威胁环境中为企业提供虚拟化的边界防护。赛门铁克也在RSA 2015提出使用软件定义网络技术对APT攻击进行取证的话题也提供了一种安全事件事后快速分析的新思路 。 而RSA大会开到了第25个年头时,我们惊喜地发现更多的公司在展示在软件定义安全的领域的工作,特别是在体现创新的Innovation Sandbox(创新沙盒)竞赛中,10家经过专业评审的公司,居然有3家与这个话题有关,分别在不同的方面做出了开创性的工作。 如Versa Networks公司,强调在软件定义广域网(SD-WAN)和分支(Branch)网络的环境中,通过虚拟化网络功能(VNF)技术,将各种各样异构的网络功能编程通用的组件,可快速在相应的网络中部署,大大减少了企业部署相应业务的开销,提高了整个过程的敏捷程度。 Skyport Systems公司同样也是为企业提供高效的安全计算基础设施,但按照传统建立边界思维,攻击者在进入系统内部后就容易进一步攻击内部其他重要资源。该公司的逻辑是,所有的资源都是零信任,这样即便内部某资源被攻破,那么从该点作为跳板进一步攻击也是困难的。那么这里就涉及到软件定义的访问控制,例如如何做到“零信任”条件下各处的访问控制策略快速调整。该公司在B轮融资中获得3000万美元。 再如Phantom Cyber公司认为在大量出现攻击的场景下,花费大量的人力去发现解决问题已不太现实。与前两个公司不同,Phantom Cyber从应用层入手,构建自动化、可编排的安全应用体系。它支持多种主流的数据分析平台,可利用较为高层的脚本实现安全运维自动化。 当然除了这些初创公司,还有很多公司也在基于自身产品做相关的工作。如在29日的Session环节,VMWare的安全产品部门SVP Tom Corn就演示了在NSX的环境中,如何可按需定义微分段(MicroSegmentation),并对任意APP间快速添加加密处理。厂商展示区域,Catbird公司的软件定义安全架构 通过微分区(Micro-Segmentation)在虚拟环境中划分不同的区域,并通过编排将安全策略下发给多种类型的安全设备,并作用在区域级别或虚拟机级别。这些工作都体现了各家在成熟产品线通过软件定义做了很多延展性的工作。 绿盟科技自2013年开始研究SDN和软件定义安全,研发了包括软件定义的抗DDoS、流量异常检测和Web安全等原型系统,并在2015年发布了软件定义安全的白皮书,探讨在该领域的进展。 创新沙盒中10个产品中出现了三个能体现SDS的产品,笔者认为其背后的原因有几个:其一,作为软件定义安全的支撑技术,如VNF/NFV、SDN方案,在国外已经有一些成熟的应用,如NSX已经代替Vsphere成为VMWare成长最快的产品,Cisco的ACI方案也与很多安全厂商有合作;其二,企业的高效安全运营需求,直接催生了安全编排这些应用层面的创新;其三,也是最重要的,出于企业对降低成本的天然需求,软件定义的理念转换为实际产品的动力十足。 … Continue reading

ssh翻墙简单说明

1 购买vps。设置用户名user和密码pass 2 新建ssh profile。以xshell为例,新建一个profile,输入vps的ip、port、user和pass 3 建立隧道。在profile属性->连接->SSH->隧道->添加,类型为Dynamic,侦听端口1080。同时启用转发x11(不知是否需要),保存profile。 4 连接vps,默认情况下连接成功。存在两 会等时候,可能被封掉… 5 安装浏览器扩展,如firefox的foxyproxy 6 以foxyproxy为例,新建一个proxy,URL匹配模式为要翻墙的url,如*google*,代理服务器细节中选择手动配置代理服务器,主机为127.0.0.1,端口1080,socks代理。确认 7 启用该proxy,即可正常翻墙

使用cloud-init实现虚拟机信息管理

为什么要用cloud-init 不同种类的设备VM启动总是一件非常麻烦的事情,例如安全设备有WAF、IPS等,每种设备的网络接口、启动脚本互不一样,即便同一种设备,其主机名、网络地址等也不一样。那么如何对这些VM启动过程进行管理,并完成所有数据的配置呢? 在这之前,我的实习生是怎么做的:将一台VM的管理口网络地址设置为192.168.2.100,然后每次启动实例之后定时访问http://192.168.2.100/somepath,当成功访问这个页面之后,使用REST接口配置该机器的IP地址为所需的新地址(如200.0.0.2);这个时候网络会短暂不同,然后在访问http://200.0.0.2/somepath,当成功访问之后,接下来配置各种值。 整个过程比较麻烦,所有的配置都需要实现REST接口,无法做到自定义启动脚本的更新;最不可接受的是,这个过程是串行的,当要启动100个VM时,只能一个VM一个VM顺序启动,否则两个VM都有同一个地址(192.168.2.100),那么网络访问就可能出现问题了。 不过受到各种Stack管理虚拟机用到cloud-init的启发,我认为我们也可以使用这套工具实现上述过程的。 什么是cloud-init cloud-init(简称ci)在AWS、Openstack和Cloudstack上都有使用,所以应该算是事实上的云主机元数据管理标准。那么问题来了,google相关的文档,发现中文这方面几乎没有,Stacker你们再搞虾米呢?当然话说回来英文的资料除了官网外几乎也没有什么,我花了近一周的时间才弄明白了。 首先要明确的是cloud-init在工作之前,VM是从DHCP服务器获取到了IP,所有DHCP发现不是cloud-init的事情。当你在Openstack中用ubuntu cloud VM启动卡在cloud-init界面时,多半是因为DHCP还没获取IP,而不是cloud-init本身的问题。那么cloud-init主要走什么呢?它向一台数据服务器获取元数据(meta data)和用户数据(user data),前者是指VM的必要信息,如主机名、网络地址等;后者是系统或用户需要的数据和文件,如用户组信息、启动脚本等。当cloud-init获取这些信息后,开始使用一些模块对数据进行处理,如新建用户、启动脚本等。 cloud-init工作原理 首先,数据服务器开启HTTP服务,cloud-init会向数据服务器发送请求,确认数据源模块,依次获取版本、数据类型和具体数据内容信息。 确认数据源模块 cloud-init会查找/etc/cloud/cloud.cfg.d/90_dpkg.cfg中的datasource_list变量,依次使用其中的数据源模块,选择一个可用的数据源模块。如我的配置文件中:datasource_list: [ Nsfocus, NoCloud, AltCloud, CloudStack, ConfigDrive, Ec2, MAAS, OVF, None ],那么ci首先调用$PYTHON_HOME/dist-packages/cloudinit/sources/DataSourceNsfocus.py中类DataSourceNsfocus的get_data函数,当且仅当访问链接DEF_MD_URL为正常时,这个数据源被认为是OK的。 在我的实践中,CloudStack的DEF_MD_URL为DHCP的服务器ip,而Openstack和AWS则为一个常值169.254.169.254,然后在宿主机的中做一个iptables重定向,这样就到了我们的服务器监听端口8807:

一些系统假设 需要说明的是,虽然每个数据源访问的入口都是get_data,但每个数据服务的格式和位置是不一样的,元数据可能在/nsfocus/latest/metadata/,也可能在/latest/metadata.json,也就是说数据源模块根据自己系统的规定,访问相应的数据,并根据ci的规定,指定如何将这些数据与ci接下来的处理模块对应上。 那么我们的数据访问地址是这样的:

其中,namespace为nsfocus,meta_data.json是一个json文件,里面包含所有元数据。 其次,我们的数据服务器IP为111.0.0.2 … Continue reading

Openstack中构造伪造源地址攻击

前一篇是将防御,这一篇简单说一下openstack下如何发动伪造源ip的DoS攻击 1 修改iptables和ebtables的设定,例如攻击vm为100.0.0.17,那么查询相应的iptables规则:

找到iptables中含有091f121f-8的链:neutron-openvswi-s091f121f-8,neutron-openvswi-i091f121f-8,neutron-openvswi-o091f121f-8,和nova-instance-xxx(与该vm对应的)插入一条优先级最高的ACCEPT链 找到ebtables中nat表中091f121f-8的链:I-tap091f121f-8c-arp-ip,I-tap091f121f-8c-ipv4-ip,插入一条优先级最高的ACCEPT链 2 安装ruby,下载pentibox 3 启动pentibox,选择Network tools->Net DoS Tester -> 任意一种即可发动攻击 如果第1步中加了规则还是不通,请检查源主机和目的主机的安全组是否允许 下面的我写的脚本,希望对大家有所帮助  Bash |   copy code |?12#!/bin/bash3 4ip=$15echo $ip6id=<code>neutron port-list |grep "$ip"|awk ‘{print $2}’ echo $id if [ -z $id ] then echo “id null” … Continue reading

Floodlight的流量控制

floodlight在bigswitch退出opendaylight后算是活过来了,新的版本在负载均衡中加入了一些机制,可以参见net.floodlight.loadbalancer 不过我关心的是FL对流量的控制,特别是判断packet_in速率的机制,这个在前几个月的Floodlight是没有的。 现在FL的处理机制是在收到packet_in数据包后,首先判断是否超过阈值,在inputThrottled方法中,计算每1000个数据包所花的时间,得出速率。如果速率超过packetInRateThresholdHigh阈值,则进入监控限制流量模式(enablePacketInThrottle) 在该模式下,依次检查packet_in数据包的src mac(频率为每50个packet_in一次)和in port(频率为每100个packet_in一次),如果近期(1s内)有该类数据包则将其禁止。 这种方法的初衷应该是防止controller的负载过高,例如禁止mac是为了防止host发送过多包,禁止in port是为了禁止sw转发过多包。但后者有可能出现在恶意vm发动DDoS攻击(一个in port,但无数src mac),客观上却使控制器免受DDoS攻击,自然也让域内的VM被DDoS。 贴一下主干代码:

让我们计算一下这种机制的效率,由于阈值packetInRateThresholdHigh设置的是1000,那么now-lastMessageTime应为1000ms=1s;考虑到controller每1000个packet_in进行判断,也就是说入包的极限是每秒1000个packet_in数据包,即1000条新流。这个在小范围内是没问题的,但Nick McKeown等人在经典文章“OpenFlow: Enabling Innovation in Campus Networks”中提到Preliminary results suggested that an Ethane controller based on a low-cost desktop PC could process over 10,000 … Continue reading

Floodlight路由机制解析

路由部分是floodlight最核心的机制,这两天仔细读了一下floodlight这部分的代码,总算有了大体上的了解,与各位分享。 本文中的floodlight(FL)与控制器/网络控制器(NC, nework controller ) 等术语等同,交换机(SW)默认为openflow-enabled switch,不再赘述。 首先谈一下SDN控制器的路由原理:当交换机收到一个不能被当前流表各条流匹配的数据包时,会把这个数据包以openflow的格式(PACKET_IN)发送给控制器。控制器经过路由决策后,同样以openflow的格式(PACKET_OUT)的方式将该数据包的下一跳信息回给该交换机。 如果学过最短路径计算的同学一定知道,两点之间的最短路径计算首先要知道任意两点之间是否相连,如果两者间有link相连还需知道其长度。所以总体而言,FL路由包括两部分:拓扑更新和路由计算,前者是定时事先完成的,形成一个全局的拓扑结构,后者是收到数据包后运行时完成的,根据拓扑生成路由策略。 首先看拓扑更新。SDN环境中拓扑是集中控制的,故FL需要了解全局的拓扑环境,所以FL在链路更新时自动更新拓扑。 1 链路更新 当交换机加入SDN环境后,控制器通过LLDP协议定时地获得该交换机与其他设备连接的link信息,然后添加或更新这些link(LinkDiscoveryManager.addOrUpdateLink()),最后将这些link更新的事件添加到updates队列中(LinkDiscoveryManager.handleLldp())。 2 拓扑更新 计算路由的关键在于路径更新和路由计算,该过程为: 2.1 启动 首先拓扑管理启动(TopologyManager.startUp())时新起一个线程UpdateTopologyWorker,间隔500ms重复运行 。 2.2 更新拓扑 如果之前在第一步中有一些链路、交换机等更新,那么LDUpdates队列中会有元素,那么依次取出这些链路更新的元素(TopologyManager.updateTopology()/TopologyManager.applyUpdates()),判断其类型(如链路更新/删除、端口增加/删除),进行响应处理。 以链路更新为例,调用TopologyManager.addOrUpdateLink()方法,判断链路类型(多跳、单跳或隧道),再把link添加到相应交换机的端口中,如果是多跳的则再删除可能的单跳link 2.3 计算拓扑路径 每次新建一个实例(TopologyManager.createNewInstance()),初始化过程中计算拓扑路径(TopologyInstance.compute()),具体地: 2.3.1 归类 将现有所有相连的link置于同一个簇中,从而形成多个簇结构(identifyOpenflowDomains()) 2.3.2 建簇 遍历所有link(addLinksToOpenflowDomains()),如果link连接的是同一个簇,则将其加入该簇,所以该方法统计了所有簇内的link。FL这么做也是减少路由计算的开销,不然若干个大二层网络中共有n个节点,就需要n平方的存储开销,计算效率也会下降,如果将不相连的节点分开就减少了上述开销。 2.3.3 遍历所有簇 … Continue reading