cisco dhcp snoop and arp inspect

最近在调整网络设置,因此重温了下DHCP SNOOP 和ARP INSPECT 的原理和设置

一 DHCP SNOOPING

简单来说,dhcp snooping通过能过滤非法的dhcp信息,并维护着一个mac-ip的数据库

1.启用dhcp snooping

(config)#ip dhcp snooping  (启用)

(config)#ip dhcp snooping vlan 4,8,16( 你要监视的vlan)

(config)#ip dhcp snooping database flash:dhcp.db (维护的那个DB,这里是放在闪存里边)

(config-if)#ip dhcp snooping trust  (对上联端口或者DHCP服务器端口启用trust)

默认状态下,所有的非trust端口都无法响应DHCP请求,因此:非法的DHCP Server就给block掉了

二 ARP INSPECT

启用了dhcp snooping之后就建立了mac-ip的对应表,因此能在此基础上开启arp inspection,屏蔽非法的mac-ip通信请求

(config)#ip arp inspection vlan 4,8,16
(config)#ip arp inspection validate src-mac ip
(config-if)#ip arp inspection trust  (对上联端口或者静态IP端口启用trust)

启用以上设置后,所有非trust端口的数据包都需要跟数据库中的mac-ip(flash:dhcp.db)校验,这里只校验了源mac和ip,对目标mac-ip不做校验(为什么?因为目标如果在其他交换机,这里的dhcp.db是没有记录的)

三 注意点

需要特别指出:dhcp snooping的数据库有个learning的过程,这个对应着dhcp请求的ack应答报文

如果在客户端已经获取IP后再启用arp inspection,会导致该客户端因没有mac-ip的对应而给屏蔽!

ddos 与 黑洞路由

通常遇到ddos或者其他攻击,简单想到的办法是iptable,比如

iptable -A INPUT -s IP -j DROP

实际上,超大规模的攻击使用iptable过滤会非常耗CPU,一般建议使用黑洞路由

从这个网址: http://www.cyberciti.biz/tips/how-do-i-drop-or-block-attackers-ip-with-null-routes.html 可以看到

假设需要屏蔽掉202.33.8.49,有三种不同做法:

1. # route add 202.33.8.49 gw 127.0.0.1 lo

2.#ip route add blackhole 202.33.8.49

3.#route add -host 202.33.8.49 reject

当然,文中没有解释这三种做法的区别与优劣,这里简单说说个人看法

第一种,是把这个ip的路由导向lo 127.0.0.1,其实是相当犯傻的行为,系统会自动的尝试往lo发送数据(tcpdump可见)

第二种,是加入黑洞路由,意思就是直接就丢弃了,当然也不会有对应的应用层程序收到数据包尝试回包了

第三种,先看看man里边怎么说: “reject install a blocking route, which will force a route lookup to fail.  This is for example used to mask out networks before using the default route.  This is NOT for firewalling.”  reject是阻止了”到”这个IP的网络,通常用于在使用默认路由前标识网络,不适用于防火墙,为什么呢?因为应用层程序能收到数据包,只不过尝试回包时会知道网络不可达而已

由此可见,从性能来说使用blackhole是最好的办法

参考:http://en.wikipedia.org/wiki/Null_route

ESXI 控制台热键的问题

最近发现esxi 退出控制台的热键不起作用,Ctrl+ALT按下去鼠标还是出不来

查了下资料,据说是要Ctrl+ALT+Space,hold 住CTRL+ALT放开SPACE,然后按ESC,嗯,这个办法可行

其实还有个更简单的办法,按住CTRL+ALT,再点下鼠标,嗯,好了…嘿嘿

infobright

一 简介

infobright 是基于mysql二次开发的数据仓库,目前社区版免费

二 缺点

不过只能使用“LOAD DATA INFILE”的方式导入数据,不支持INSERT、UPDATE、DELETE, 不支持高并发:只能支持10多个并发查询

三 安装

四 简单实用

五 问题

mogodb 时间日期问题

使用mogonDB遇到了时间日期的问题,之前的sql查询是”select * from table_name where ts between A AND B”

当然mongoDB也有类似的查询办法:
var start = new Date(2011, 3, 1);
var end = new Date(2011, 4, 1);
db.posts.find({ts: {$gte: start, $lt: end}});

而实际去查询的时候,结果总是空的,发现在mongodb里边并未正确的存储为datetime格式
“ts” : “2011-04-19 00:01:00” 这个应该是import的时候当字符存储了,自然没有办法使用日期的范围查询了
正确的格式应该是: “ts” : ISODate(“2010-04-30T16:00:00Z”)
mongodb的import 文档告诉我们: 可以在insert的时候设置{“$date” : 1285679232000} 设置json格式

实际上,使用date格式会非常缓慢,
http://search.cpan.org/~kristina/MongoDB-0.37/lib/MongoDB/DataTypes.pod#Dates
可以看到:”Warning: creating DateTime objects is extremely slow. Consider saving dates as numbers and converting the numbers to DateTimes when needed. A single DateTime field can make deserialization up to 10 times slower.”

因此,把数据转换成时间戳会是比较明智的选择

思科交换机查看状态

#sh ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/1 unassigned YES unset down down
FastEthernet0/2 unassigned YES unset up up
能看到端口状态,主要是链路状态

#sh interfaces status
Port Name Status Vlan Duplex Speed Type
Fa0/1 “Connect to Cicso notconnect 8 auto auto 10/100BaseTX
Fa0/2 “Connect to Cicso connected 8 a-full a-100 10/100BaseTX
侧重于vlan和描述性的东西,这里能看到链接速度

nginx php 缓存

这边一直有个php cache的应用,原理是发起一个对自身的请求,保存成静态文件
之前这个应用在apache worker模式跑得很好,换到nginx的fast-cgi 后一直不是很正常

这个问题跟spawn-fcgi的工作原理有关: spawn-fcgi起N个进程,然后FIFO排队处理请求
当有并发>N个PHP CACHE的应用请求过来的时候,php cache的应用会再对自身发起请求,这个请求排在了这些请求的后边,而实际上不会有新的进程来处理这些请求,从而形成死锁,日志中会充斥”upstream timed out” “no live upstreams”

因此,工作模式的排队理论本身决定了这个故障不可避免

解决办法:使用nginx proxy_cache 绕开这个问题,把php cache这个功能交给proxy_cache来完成,nginx的work process遇到阻塞等待的情况,会把这个请求的工作sleep一段时间处理接下来的请求,这个特点明显优于spawn-fcgi的行为

1.建立 /cache/打头的可缓存php location

location ~* ^/cache/(.*\.php)${

}

2. 设置相关的proxy_cache:

1) CACHEZONE:

proxy_cache_path /dev/shm/cache/app.gd.sohu.com levels=1:2 keys_zone=default:100m max_size=4g inactive=20m;

2) CACHE目录:

proxy_read_timeout 5s;
proxy_connect_timeout 5s;
proxy_set_header Host $host;
proxy_cache_use_stale updating;
proxy_cache_key “$host$uri$is_args$args”;
proxy_cache default;

proxy_ignore_headers “Cache-Control”;
proxy_hide_header “Cache-Control”;

proxy_ignore_headers “Expires”;
proxy_hide_header “Expires”;

proxy_hide_header “Set-Cookie”;
proxy_ignore_headers “Set-Cookie”;

add_header Cache-Control max-age=60;

proxy_cache_valid 200 3m;
proxy_cache_valid any 0m;
proxy_temp_path /dev/shm/cache/tmp;

proxy_pass http://serverIP/$1$is_args$args;

3) PURGE设置:

location ~* ^/purge/(.*\.php)$ {
access_log logs/purge_app_access.log sohu;

allow 10.10.0.0/16;
deny all;
set $purge_key “$host/$1$is_args$args”;
proxy_cache_purge default $purge_key;

}

3.需要注意的地方:

1) 影响动态应用能否cache的有几个header:一般是”X-Accel-Redirect”, “X-Accel-Expires”, “Expires” or “Cache-Control” ,跟某些文档提到的cookie是没有关系的,我这里根据自己的应用ignore了 “Expires” 和”Cache-Control” 的header
2) 需要注意,php使用cookie(session也是cookie header实现的一种)来识别用户,如果是私密应用,需要把cookie加入cachekey里边,开放式应用则不必如此
3)设置完毕后可以在访问路径的前边加上/cache/实现php内容的缓存,再加上/purge/就能清除其缓存
4) 需要特别说明,我这边的版本是0.7系列,从测试看1.x系列是会forward cookie的,所以需要抹掉:

proxy_hide_header Set-Cookie;
proxy_ignore_headers Set-Cookie;

2022.07补充

By default, NGINX respects other directives in the Cache-Control header: it does not cache responses when the header includes the PrivateNo-Cache, or No-Store directive. It also doesn’t cache responses with the Set-Cookie header. Further, it only caches responses to GET and HEAD requests. You can override these defaults as described in the answers below.