docker容器跨宿主机通信方法(宿主机同一2层网络下)

  1. 容器run的时候启用–network来指明host网络类型,使得容器复用host的网络空间。容器将得到和宿主机一样的网络接口及IP。这样的缺点是容器在网络上没有隔离,而且多个容器存在抢占同一端口的可能性,限制性比较大。
  2. 容器桥接到一个自定义网桥(非docker产生的网桥,而是linux中独立创建的网桥),并将该自定义网桥与宿主机物理接口进行桥接,这样将容器直接透传到外部物理网络里来,使得各个容器就像直接活在外部网络中的一个主机一样。可以通过pipework这个工具来自动化执行上述这个过程




    可以看到pipework自动为运行中的容器增加了新网卡eth1并配置IP及路由,同时将该容器内网卡命名为eth1并link到外部一个veth上,该veth落在br0上. 在容器内部删除其它缺省路由,根据命令里提供的网关地址设置缺省路由。

     

    pipework并没有对br0配置接口IP,也没有将其桥接到物理网卡上,这一步工作还需手工完成,将eno33554960加入到br0网桥,且配置br0的IP地址:

     

    在容器内ping 网关,及外部地址:

    备注:上述方法执行的pipework 默认并没有保存到容器里,容器重启后配置都会丢失,在一个生产环境下从容器本身这种结构考虑,一般不应该考虑为容器设置内部直接设置固定IP,因此对于上述方法用起来还是比较麻烦的,每次启动容器后,需要根据命名自动执行相关pipework命令,这时候如何保证服务发现,以及确保IP分配不冲突,对于某些依赖服务还需考虑提供恒定的IP。另外,在这种结构下,所有容器之间都在一个二层,容器间通信控制本身需要外部来维护控制。 docker commit是不会保存这种网络接口增加变化的。

    在另一台主机上执行同样类似的操作过程,随后不同主机上的容器即可以相互通信:

    容器目的地外网ip的通讯,数据包发给br0接口,br0接口在host中,再次查找主机路由表,将数据包路由出去。注意两台宿主机br0接口地址不一样,每个宿主机容器的网关指向本宿主机的br0的IP。 网络结构如下:

    在整个上述配置中,所有配置都未写入文件,重启容器,重启主机相关配置都会丢失。对于容器可考虑结合自动化脚本在启动容器后执行相关pipework工作,而对于主机桥接网络,实际上建议配置具体的br0接口文件,将IP以及桥接的物理接口固定配置在文件里(类似编辑一个接口网络配置文件一样)
    而如果不想通过pipework来做,则可以考虑新建br0后,修改docker daemon的缺省启动参数来使得容器run的时候默认绑定到这个br0 bridge网络上,同时将一个宿主物理网卡加入到该br0实现直接桥接到外部网络. 缺省启动文件 /usr/lib/systemd/system/docker.service 相关启动参数包含:

    注意:在centos7下,上述桥接后,还需要在主机iptables的FORWARD链中增加相关容许条目。例如:
    iptables -I FORWARD 10 -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT

     

  3. 使用路由方式互联跨宿主机容器:

继续阅读

docker 一些提示

To detach from the container1 container and leave it running, use the keyboard sequence CTRL-p CTRL-q


场景:centos7.3.1611上,docker版本Server:
Version: 17.05.0-ce
API version: 1.29 (minimum version 1.12)

连个容器A,B连接在缺省的docker0 bridge网络上,A 通过publish port方式将80映射到主机的8080上。此时从主机外部访问主机host的IP:8080端口是正常(docker自动添加了相关iptable 放行规则),此时从容器B 访问 hostip:8080则提示被拒绝。原因是:

iptable filter表中的input链里的最后拒绝rule(此时目的地址是本地ip,match input 链)

docker link and docker network

在同一台宿主机器上,docker彼此之间默认可以直接通过IP地址通信(假如启动docker dameon时候icc=true),但是每个容器的ip地址并不固定,如果单纯依赖IP地址通信局限性会很大,在传统的docker网络下可以考虑使用link特性来让各个容器之间进行业务通信。

link容器的做法是在启动一个容器时候,使用–link参数来连接一个需要被访问的容器,无论是否启用icc=true,使用link后都可以通信:

执行后,docker实际上做了:

  1. 在被启动的容器的/etc/hosts文件里加入被link容器的地址解析记录
  2. 将被连接容器的环境变量(dockerfile里配置的,或通过run命令中增加的环境变量)导入到启动的容器

/ # more /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.3 myningx1 170cf34abb53 mynginx
172.17.0.5 42256d1f3171
/ # env
MYNINGX1_PORT_80_TCP_PORT=80
MYNINGX1_PORT_80_TCP_PROTO=tcp
HOSTNAME=42256d1f3171
SHLVL=1
HOME=/root
MYNINGX1_PORT_80_TCP=tcp://172.17.0.3:80
MYNINGX1_ENV_NGINX_VERSION=1.13.0-1~stretch
MYNINGX1_ENV_NJS_VERSION=1.13.0.0.1.10-1~stretch
TERM=xterm
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MYNINGX1_PORT=tcp://172.17.0.3:80  —–>这条是dockerfile里expose的端口或者run -p指定的expose端口(如果-p存在,比dockerfile expose的优先)
PWD=/
MYNINGX1_NAME=/admiring_mahavira/myningx1
MYNINGX1_PORT_80_TCP_ADDR=172.17.0.3

环境变量导入是一次性的,被连接的容器如果环境变量发生变化是不会重新导入过来的,重启被连接的容器也不影响这些已导入的环境变量。但是被连接容器IP地址变化是可以自动更新过来的。

跨主机之间是无法直接link的,但是有这样一个link 代理项目,叫ambassador,可参考 http://www.tuicool.com/articles/RfQRny   但感觉意义也不是很大。

默认的这个 docker0的 bridge 网络是不支持内嵌的DNS服务发现的,使用user-defined网络可以利用内嵌的dns服务(dns服务在127.0.0.11上),但使用user-defined网络时候,在将一个container connect到user-defined网络时是不存在环境变量注入的。内嵌的dns支持设置search domain ,option等(通过在启动一个container时候增加相关参数flag),并可以支持当内嵌dns无法提供解析时候自动将解析转发到指定的外部dns上(同样通过docker run命令里的参数来传递给内嵌dns,如果不指定,则使用host上的dns做备份)详细见https://docs.docker.com/engine/userguide/networking/configure-dns/

上述,将busybox-1连接到自定义网络里,且不指定ip(将由docker自动分配),busybox-2 则指定iP,结果如下,注意诡异的docker将网络号分给了busybox-1这个容器

在busybox-1里ping busybox-2这个名称:

容器里的resolve文件:

 

同时docker0和后创建的网络彼此之间是隔离的:

 

https://docs.docker.com/engine/userguide/networking/work-with-networks/
https://docs.docker.com/engine/userguide/networking/

 

host类型网络可以让容器直接看到所有主机的网络,直接共享主机的网络设置(意味着就真的像一个主机里的普通进程一样了共享主机网络端口),注意此时要想让该容器可以通过主机的地址直接访问业务,要注意开放相关iptables条目

使用ip netns命令显示docker namespace 的方法

运行以上脚本即可:

 

Docker学习备忘2

拉取busybox镜像,并运行一个容器实例(挂载一个自命名的volume进去)

观察此时/var/lib/docker下结构:

[root@docker1 docker]# tree -L 4
.
├── containers
│   ├── 276041ef9cbefee243480ed52e5d2e0529df7a7c6c6a617f38ab6937136079f3
│   │   ├── 276041ef9cbefee243480ed52e5d2e0529df7a7c6c6a617f38ab6937136079f3-json.log
│   │   ├── checkpoints
│   │   ├── config.v2.json
│   │   ├── hostconfig.json
│   │   ├── hostname
│   │   ├── hosts
│   │   ├── resolv.conf
│   │   ├── resolv.conf.hash
│   │   └── shm
│   └── 985e538f6b25487f5944707d44db1c3f624dd83f95adf02ab901fc75e6750823
│   ├── 985e538f6b25487f5944707d44db1c3f624dd83f95adf02ab901fc75e6750823-json.log
│   ├── checkpoints
│   ├── config.v2.json
│   ├── hostconfig.json
│   ├── hostname
│   ├── hosts
│   ├── resolv.conf
│   ├── resolv.conf.hash
│   └── shm
├── image
│   └── overlay
│   ├── distribution
│   │   ├── diffid-by-digest
│   │   └── v2metadata-by-diffid
│   ├── imagedb
│   │   ├── content
│   │   └── metadata
│   ├── layerdb
│   │   ├── mounts
│   │   ├── sha256
│   │   └── tmp
│   └── repositories.json
├── network
│   └── files
│   └── local-kv.db
├── overlay
│   ├── 14d4a3283bd0fac4850cf1151a5699266e62ac0366e15d6a290fe13ab6a452cd
│   │   ├── lower-id
│   │   ├── merged
│   │   ├── upper
│   │   │   ├── dev
│   │   │   ├── etc
│   │   │   ├── proc
│   │   │   └── sys
│   │   └── work
│   │   └── work
│   ├── 14d4a3283bd0fac4850cf1151a5699266e62ac0366e15d6a290fe13ab6a452cd-init
│   │   ├── lower-id
│   │   ├── merged
│   │   ├── upper
│   │   │   ├── dev
│   │   │   ├── etc
│   │   │   ├── proc
│   │   │   └── sys
│   │   └── work
│   │   └── work
│   ├── 4ff8b86a0317b5a6bd539e51ec676395e6079f4d8a77b34ff95cb8a9451279a0
│   │   └── root
│   │   └── hello
│   ├── a626a89bd36ab93ba340eb98f01a824b1edb75082694cc8c695992b4e57e1087
│   │   └── root
│   │   ├── bin
│   │   ├── dev
│   │   ├── etc
│   │   ├── home
│   │   ├── root
│   │   ├── tmp
│   │   ├── usr
│   │   └── var
│   ├── c1eb6f4be0f4f384fe4a1645cc03e3f9c3c81c72a9f276c844f62c6d7cca0974
│   │   ├── lower-id
│   │   ├── merged
│   │   │   ├── bin
│   │   │   ├── data
│   │   │   ├── dev
│   │   │   ├── etc
│   │   │   ├── home
│   │   │   ├── proc
│   │   │   ├── root
│   │   │   ├── sys
│   │   │   ├── tmp
│   │   │   ├── usr
│   │   │   └── var
│   │   ├── upper
│   │   │   ├── data
│   │   │   ├── dev
│   │   │   ├── etc
│   │   │   ├── proc
│   │   │   ├── root
│   │   │   └── sys
│   │   └── work
│   │   └── work
│   └── c1eb6f4be0f4f384fe4a1645cc03e3f9c3c81c72a9f276c844f62c6d7cca0974-init
│   ├── lower-id
│   ├── merged
│   ├── upper
│   │   ├── dev
│   │   ├── etc
│   │   ├── proc
│   │   └── sys
│   └── work
│   └── work
├── plugins
│   ├── storage
│   │   └── blobs
│   │   └── tmp
│   └── tmp
├── swarm
├── tmp
├── tmp-old
├── trust
└── volumes
└── metadata.db

93 directories, 22 files

在busybox内查看,注意 / 的mount,与上述粗红对应

在宿主机的目录下创建一个文件,在容器里可以被看到:

 

网络方面:

启动的busybox container使用一个veth pair 连接到了 docker0网桥上,从网桥对应的网络获得IP地址,系统默认启动了 icc。 从宿主机ifconfig角度看,多了一个veth接口,该接口即连接到了docker0网桥上。在busybox内部,看到正常的一个eth0,其实它是veth pair的另一端。

 

docker inspect 查看该容器,可以看到容器的几大部分配置,config, hostconfig, networksetting, graphdirver. hostconfig是与宿主机有关联的相关配置。 网络部分中的sandbox可以理解为容器的namespace,其内包含一个endpoint,连接到相关network上,类似下图

那么如何在宿主机下进入该容器的namespace里面呢?
1. 首先通过上述输出中的State.Pid获得该容器在主机里的进程号,这里是5013
2. 将/proc/5013/ns/net link到/var/run/netns下,例如

随后就可以模拟进入该ns下查看:

 

docker run -itd 方式运行一个带sh的容器后,再次docker attach上去后并exit退出bash,此时这个容器会被stop,用docker exec -it *** sh执行后再退出则不会stop之前运行的容器,因为此时后一个命令,相当于又开了一个新进程,原来运行该容器的进程还活着

docker start命令启动的container,依旧包含有使用run命令时候所带的参数。

映射主机8080到容器的80端口后,iptables变化,可以看到多了一条目的地址/PAT转换的规则,以及多了一条接受目的地址是容器,目的端口是80的接受规则(注意match参数都是tcp)

-A DOCKER -d 172.17.0.3/32 ! -i docker0 -o docker0 -p tcp -m tcp –dport 80 -j ACCEPT
控制的是容许从宿主机外部过来的请求,input 接口是非docker0,无此规则的话将只能从宿主机本身发起到容器的访问

 

Docker学习备忘1

Centos7

[root@docker1 etc]# more system-release
CentOS Linux release 7.3.1611 (Core)
[root@docker1 etc]# uname -a
Linux docker1.f5lab.com 3.10.0-514.16.1.el7.x86_64 #1 SMP Wed Apr 12 15:04:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

[root@docker1 etc]# docker info
Containers: 1
Running: 0
Paused: 0
Stopped: 1
Images: 1
Server Version: 17.05.0-ce
Storage Driver: overlay
Backing Filesystem: xfs
Supports d_type: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9048e5e50717ea4497b757314bad98ea3763c145
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 3.10.0-514.16.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.844GiB
Name: docker1.f5lab.com
ID: 7DCC:YGQU:S2YZ:FYSL:4HMD:4GSC:5UCN:KIPQ:32QM:3TVC:YDJU:OUL6
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false

WARNING: overlay: the backing xfs filesystem is formatted without d_type support, which leads to incorrect behavior.
Reformat the filesystem with ftype=1 to enable d_type support.
Running without d_type support will not be supported in future releases.

刚启动docker后,/var/lib/docker下状态:

[root@docker1 docker]# tree -L 10
.
├── containers
├── image
│   └── overlay
│   ├── distribution
│   ├── imagedb
│   │   ├── content
│   │   │   └── sha256
│   │   └── metadata
│   │   └── sha256
│   ├── layerdb
│   └── repositories.json
├── network
│   └── files
│   └── local-kv.db
├── overlay
├── plugins
│   ├── storage
│   │   └── blobs
│   │   └── tmp
│   └── tmp
├── swarm
├── tmp
├── tmp-old
├── trust
└── volumes
└── metadata.db

23 directories, 3 files

 

[root@docker1 files]# pwd
/var/lib/docker/network/files

 

 

[root@docker1 files]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 100 0 0 eno16777736
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.0.0 0.0.0.0 255.255.255.0 U 100 0 0 eno16777736
[root@docker1 files]# ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0
ether 02:42:4e:be:c2:89 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eno16777736: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.129 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::20c:29ff:fe42:d98 prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:42:0d:98 txqueuelen 1000 (Ethernet)
RX packets 3444 bytes 467959 (456.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1817 bytes 600598 (586.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eno33554960: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 00:0c:29:42:0d:a2 txqueuelen 1000 (Ethernet)
RX packets 7 bytes 1140 (1.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eno50332184: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 00:0c:29:42:0d:ac txqueuelen 1000 (Ethernet)
RX packets 7 bytes 1140 (1.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 68 bytes 5844 (5.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 68 bytes 5844 (5.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

 

[root@docker1 files]# ip netns show 为空, 实际上此时是有ns的,只是容器的ns不在该命令查找的文件夹下。方法见学习备忘2文章

 

[root@docker1 files]# docker network ls
NETWORK ID NAME DRIVER SCOPE
734c4df7548e bridge bridge local
e7f32fd414b9 host host local
206ea33a6608 none null local
[root@docker1 files]# docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
[root@docker1 files]# docker image
image images
[root@docker1 files]# docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
[root@docker1 files]# docker volume ls
DRIVER VOLUME NAME

[root@docker1 files]# docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 0 0 0B 0B
Containers 0 0 0B 0B
Local Volumes 0 0 0B 0B


[root@docker1 files]# docker run hello-world
Unable to find image ‘hello-world:latest’ locally
latest: Pulling from library/hello-world
78445dd45222: Pull complete
Digest: sha256:c5515758d4c5e1e838e9cd307f6c6a0d620b5e07e6f927b07d05f6d12a1ac8d7
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the “hello-world” image from the Docker Hub.
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
https://cloud.docker.com/

For more examples and ideas, visit:
https://docs.docker.com/engine/userguide/

 

[root@docker1 /]# docker container ls -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
276041ef9cbe hello-world “/hello” 3 hours ago Exited (0) 3 hours ago agitated_keller

[root@docker1 files]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
hello-world latest 48b5124b2768 3 months ago 1.84kB
[root@docker1 files]# docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
hello-world latest 48b5124b2768 3 months ago 1.84kB

 

 

[root@docker1 files]# docker history hello-world
IMAGE CREATED CREATED BY SIZE COMMENT
48b5124b2768 3 months ago /bin/sh -c #(nop) CMD [“/hello”] 0B
<missing> 3 months ago /bin/sh -c #(nop) COPY file:22b680a46dca70… 1.84kB
[root@docker1 files]# docker inspect hello-world
[
{
“Id”: “sha256:48b5124b2768d2b917edcb640435044a97967015485e812545546cbed5cf0233”,
“RepoTags”: [
“hello-world:latest”
],
“RepoDigests”: [
“hello-world@sha256:c5515758d4c5e1e838e9cd307f6c6a0d620b5e07e6f927b07d05f6d12a1ac8d7”
],
“Parent”: “”,
“Comment”: “”,
“Created”: “2017-01-13T22:50:56.415736637Z”,
“Container”: “d7e9f7ed9c135402fba7227d8da07c250126181eee0cfd2743b5736b80108625”,
“ContainerConfig”: {
“Hostname”: “b3e3b3843b7f”,
“Domainname”: “”,
“User”: “”,
“AttachStdin”: false,
“AttachStdout”: false,
“AttachStderr”: false,
“Tty”: false,
“OpenStdin”: false,
“StdinOnce”: false,
“Env”: [
“PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin”
],
“Cmd”: [
“/bin/sh”,
“-c”,
“#(nop) “,
“CMD [\”/hello\”]”
],
“Image”: “sha256:fba45bbdabc1ff498b7965f99d2f25c59266cfa751067951f8e965841928c843”,
“Volumes”: null,
“WorkingDir”: “”,
“Entrypoint”: null,
“OnBuild”: null,
“Labels”: {}
},
“DockerVersion”: “1.12.3”,
“Author”: “”,
“Config”: {
“Hostname”: “b3e3b3843b7f”,
“Domainname”: “”,
“User”: “”,
“AttachStdin”: false,
“AttachStdout”: false,
“AttachStderr”: false,
“Tty”: false,
“OpenStdin”: false,
“StdinOnce”: false,
“Env”: [
“PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin”
],
“Cmd”: [
“/hello”
],
“Image”: “sha256:fba45bbdabc1ff498b7965f99d2f25c59266cfa751067951f8e965841928c843”,
“Volumes”: null,
“WorkingDir”: “”,
“Entrypoint”: null,
“OnBuild”: null,
“Labels”: {}
},
“Architecture”: “amd64”,
“Os”: “linux”,
“Size”: 1840,
“VirtualSize”: 1840,
“GraphDriver”: {
“Data”: {
“RootDir”: “/var/lib/docker/overlay/4ff8b86a0317b5a6bd539e51ec676395e6079f4d8a77b34ff95cb8a9451279a0/root”
},
“Name”: “overlay”
},
“RootFS”: {
“Type”: “layers”,
“Layers”: [
“sha256:98c944e98de8d35097100ff70a31083ec57704be0991a92c51700465e4544d08”
]
}
}
]

run一个镜像之后:

Strusts S2-045 CVE 2017-5638 BIGIP 防御措施

近日国内安全公司发现Apache struts 出现基于content-type的value的远程可执行漏洞,由于漏洞不需要实质性的上传文件,普通的经过构造的请求都可以简单的实现攻击,因此危害较大。

针对此漏洞,BIGIP可以帮助客户快速部署防御措施,以下进行简单总结。

注意,由于攻击可能存在各种各样的变形特征,考虑到尽可能少的误杀,以及规避尽可能的逃逸技术,以下irule内容是在和Support安全工程师Bean以及SDM Jobs经过反复讨论及测试后的结果,非常感谢Bean搭建攻击环境及反复斟酌测试。

防御措施:

  1. 如果你正在使用ASM产品,恭喜,只要你确保在主动防御策略中启用了 illegal  meta character in header 或者在被动防御中正确启用了与系统、语言相匹配的特征库,默认即可防御。测试表明,基本配置即可阻断攻击。
  2. 如果没有使用ASM,则可以在LTM上部署irule

    备注:漏洞要被利用,value基本攻击特征包含 multipart/form-data,${…},%{….},考虑到可能的escape技术,未采用该特征。 以上特征匹配参考了ASM在防御时所匹配的特征以及漏洞实际要被使用时需包含OGNL命令。
  3. 另一个irule方法供参考

     
  4. 对于F5 设备自身是否受该漏洞影响,请参考:https://support.f5.com/csp/article/K43451236   简单的说,F5所有产品不受影响

 

 

Mitaka Openstack 排错备忘

问题1:

安装mitaka并安装F5 agent后,设置F5 agent的配置中tunnel类型为vxlan

在openstack中创建网络,并创建loadbalancer,发现在F5上自动创建的tunnel是gre的

修改 /etc/neutron/plugins/ml2/ml2_conf.ini  中的ML2段落下的租户网络类型为vxlan,发现依旧推送gre tunnel

tenant_network_types = vxlan

原因:

在创建网络的时候,tenant_network_types 配置项的第一个配置是gre,导致产生的租户网络类型是gre,这样即便后来修改了该配置,已经产生的类型依旧是gre,导致推送到F5上的tunnel始终是gre。

附,正常配置:

 

问题2:

如果通过openstack配置了一个loadbalancer,此后重启compute节点上的neutron-server,则系统提示必须先删除之前创建loadbalancer,否则启动失败

2017-01-13 18:55:38.297 24480 ERROR neutron_lbaas.services.loadbalancer.plugin [req-00e705df-f351-481a-853d-cc250a3b01a2 – – – – -] Delete associated load balancers before removing providers [u’f5networks’]

待解