Archive

Posts Tagged ‘腾讯’

腾讯域名邮箱:鸡肋!

September 22nd, 2009

今天使用绑定的域名邮箱测试注册UCH,没有收到邮件。。
连续重新发送好几次还是没有
然后换个邮箱,立马就收到了
继续测试。。
换上qq邮箱(QQ号@qq.com),也是立马就收到了
难道“运气”差,于是又换回域名邮箱,还是收不到!!

用Gmail给这个域名邮箱发了封信,俩字,很快收到。。

难道是腾讯域名邮箱丢信?或是直接被过滤关键字啦?(可同样的邮件QQ号的数字邮箱就能收到啊)。。

有人说腾讯的域名邮箱还处于测试阶段,那么,一次丢信可以接受,两次丢信也可以接受,三次也可以接受,四次五次也都可以接受。。那要绑个域名邮箱做什么?只是给QQ邮箱绑定个虚名?看着帅还是咋地?

就算是邮箱内有所谓的”非法”关键字,你可以过滤,可以把那些字变成*号,可以把那些信标记为垃圾邮件(我信箱里的阿里系统发的的邮件统统已经被QQ邮箱标记为垃圾邮件,不明真相),但是你直接丢弃就说不过去了吧。。

就啰嗦这么点吧。。今天害我点好几次重新发信验证!

今日一点 ,

搜索华尔兹,人肉搜索的又一利器?

June 11th, 2009

腾讯旗下搜索引擎,搜搜推出一种新型的搜索产品: 搜索华尔兹(名人搜索地图:搜索可以改变世界,你可以影响中国)。

搜索华尔兹的搜索视觉很类似谷歌推出的音乐冒泡搜索。

从搜索的内容看,通过对正常相应关键字在网页搜索中的搜索结果的统计,使用关系网状展现出来。

既然腾讯初步定为为名人搜索地图,也就是给粉丝们用的了。

罗列的结果并不丰富,只是展现的名人关系网倒是很有趣,请看上边的宣传语(他与她之间发生啦什么?)。

有兴趣的可以搜搜自己的名字哦。

搜索华尔兹(名人搜索地图)地址

搜索引擎 , , , ,

今日杂碎:财付通交易详细记录缺失的QQ号

December 21st, 2008

杂碎1:QQ官方支持为其他人充值QB,充值提示成功,之后却无法在财付通的详细交易记录中查询是否充值到正确的QQ号。

这个对腾讯来说不算个难题,只是做得还不够好而已(问题已经提交到官方支持的Q吧)。

不过这问题在(虚拟卡)交易平台上几乎是不会发生的(可以很方便的查看到“财产”从哪里流向哪里),还有腾讯的“在线”客服真是差劲呢,找不到人(或许我就是那万分之一中的碰巧吧)!!

杂碎2:今天真是很冷(0度到负11度)呢。在风中都不敢走,只能跑!

今日一点 ,

瞅下腾讯的几个服务器

July 21st, 2008

首先用nslookup看下qq.com

> set type=any
> qq.com
Server:  UnKnown
Address:  192.168.1.1

————
//发送请求,以及发送的数据包简要描述:长度24
SendRequest(), len 24
HEADER:
opcode = QUERY, id = 5, rcode = NOERROR
header flags:  query, want recursion
questions = 1,  answers = 0,  authority records = 0,  additional = 0

QUESTIONS:
qq.com, type = ANY, class = IN

————
————
//反馈的信息,大小403bytes
Got answer (403 bytes):
HEADER:
opcode = QUERY, id = 5, rcode = NOERROR
header flags:  response, want recursion, recursion avail.
questions = 1,  answers = 6,  authority records = 3,  additional = 0

QUESTIONS:
qq.com, type = ANY, class = IN
ANSWERS:
->  qq.com
type = TXT, class = IN, dlen = 224
text =

“v=spf1 ip4:219.133.40.0/24 ip4:219.133.49.0/24 ip4:58.60.8.0/21 ip4:222
.202.96.0/24 ip4:121.14.73.0/24 ip4:121.14.74.0/24 ip4:121.14.76.0/23 ip4:64.71.
138.0/25 ip4:58.251.60.0/22 ip4:219.133.60.0/24 ip4:59.42.249.0/24  ~all”
ttl = 33260 (9 hours 14 mins 20 secs)
/*
spf(Sender Policy Framework)是为了防范垃圾邮件而提出来的一种DNS记录类型,它是一种TXT类型的记录,它用于登记某个域名拥有的用来外发邮件的所有IP地址。按照SPF的格式在DNS记录中增加一条TXT类型的记录,将提高该域名的信誉度,同时可以防止垃圾邮件伪造该域的发件人发送垃圾邮件。 SPF是跟DNS相关的一项技术,它的内容写在DNS的txt类型的记录里面。mx记录的作用是给寄信者指明某个域名的邮件服务器有哪些。SPF的作用跟 mx相反,它向收信者表明,哪些邮件服务器是经过某个域名认可会发送邮件的。由定义可以看出,SPF的作用主要是反垃圾邮件,主要针对那些发信人伪造域名的垃圾邮件。
*/
->  qq.com
type = A, class = IN, dlen = 4
internet address = 219.133.40.91
ttl = 11500 (3 hours 11 mins 40 secs)
//A记录这个就不用说啦吧(主机名(或域名)对应的IP地址记录)。
->  qq.com
type = MX, class = IN, dlen = 8
MX preference = 10, mail exchanger = mx0.qq.com
ttl = 5001 (1 hour 23 mins 21 secs)
//MX是邮件交换记录,它指向一个邮件服务器,用于电子邮件系统发邮件时根据收信人的地址后缀来定位邮件服务器。
->  qq.com
type = NS, class = IN, dlen = 15
nameserver = dns1.imok.net
ttl = 5001 (1 hour 23 mins 21 secs)
//NS(Name Server)记录是域名服务器记录,用来指定该域名由哪个DNS服务器来进行解析。
->  qq.com
type = NS, class = IN, dlen = 7
nameserver = dns3.imok.net
ttl = 5001 (1 hour 23 mins 21 secs)
->  qq.com
type = NS, class = IN, dlen = 7
nameserver = dns2.imok.net
ttl = 5001 (1 hour 23 mins 21 secs)
AUTHORITY RECORDS:
->  qq.com
type = NS, class = IN, dlen = 2
nameserver = dns3.imok.net
ttl = 5001 (1 hour 23 mins 21 secs)
->  qq.com
type = NS, class = IN, dlen = 2
nameserver = dns1.imok.net
ttl = 5001 (1 hour 23 mins 21 secs)
->  qq.com
type = NS, class = IN, dlen = 2
nameserver = dns2.imok.net
ttl = 5001 (1 hour 23 mins 21 secs)

————
Non-authoritative answer:
//本机(网关)的DNS cache,如果想清除本机dns cache可以使用ipconfig /flushdns.
qq.com
type = TXT, class = IN, dlen = 224
text =

“v=spf1 ip4:219.133.40.0/24 ip4:219.133.49.0/24 ip4:58.60.8.0/21 ip4:222
.202.96.0/24 ip4:121.14.73.0/24 ip4:121.14.74.0/24 ip4:121.14.76.0/23 ip4:64.71.
138.0/25 ip4:58.251.60.0/22 ip4:219.133.60.0/24 ip4:59.42.249.0/24  ~all”
ttl = 33260 (9 hours 14 mins 20 secs)
qq.com
type = A, class = IN, dlen = 4
internet address = 219.133.40.91
ttl = 11500 (3 hours 11 mins 40 secs)
qq.com
type = MX, class = IN, dlen = 8
MX preference = 10, mail exchanger = mx0.qq.com
ttl = 5001 (1 hour 23 mins 21 secs)
qq.com
type = NS, class = IN, dlen = 15
nameserver = dns1.imok.net
ttl = 5001 (1 hour 23 mins 21 secs)
qq.com
type = NS, class = IN, dlen = 7
nameserver = dns3.imok.net
ttl = 5001 (1 hour 23 mins 21 secs)
qq.com
type = NS, class = IN, dlen = 7
nameserver = dns2.imok.net
ttl = 5001 (1 hour 23 mins 21 secs)

qq.com
type = NS, class = IN, dlen = 2
nameserver = dns3.imok.net
ttl = 5001 (1 hour 23 mins 21 secs)
qq.com
type = NS, class = IN, dlen = 2
nameserver = dns1.imok.net
ttl = 5001 (1 hour 23 mins 21 secs)
qq.com
type = NS, class = IN, dlen = 2
nameserver = dns2.imok.net
ttl = 5001 (1 hour 23 mins 21 secs)
>

//接着看下www.qq.com服务器

D:\nmap>nmap -sVC -O -T4 www.qq.com
//查询服务器开放端口的服务类型以及程序版本,以及脚本类型,系统类型,探测效率T4.
Starting Nmap at 2008-07-21 02:09 中国标准时间
Warning: Hostname www.qq.com resolves to 2 IPs. Using 60.28.234.98.
Interesting ports on 60.28.234.98:
Not shown: 1714 filtered ports
PORT   STATE SERVICE    VERSION
80/tcp open  http-proxy nginx http proxy 0.6.32
Warning: OSScan results may be unreliable because we could not find at least 1 o
pen and 1 closed port
Aggressive OS guesses: Smoothwall firewall (Linux 2.6.16.53) (98%), Linux 2.6.13
- 2.6.20 (98%), Linux 2.6.17 (x86) (97%), Linux 2.6.22 – 2.6.23 (97%), Siemens
Gigaset SE515dsl wireless broadband router (95%), Linux 2.6.9 – 2.6.11 (95%), Li
nux 2.6.9 – 2.6.15 (95%), Linux 2.6.15 – 2.6.20 (94%), Linux 2.6.11 – 2.6.22 (94
%), Linux 2.6.17 – 2.6.18 (94%)
No exact OS matches for host (test conditions non-ideal).
Uptime: 23.417 days (since Fri Jun 27 16:08:35 2008)

OS and Service detection performed
.
Nmap done: 1 IP address (1 host up) scanned in 19.969 seconds

//接着来看下mail.qq.com
D:\nmap>nmap -sVC -O -T4 mail.qq.com

Starting Nmap at 2008-07-21 02:13 中国标准时间
Insufficient responses for TCP sequencing (1), OS detection may be less accurate

Interesting ports on reverse.gdsz.cncnet.net (58.251.60.161):
Not shown: 1712 filtered ports
PORT    STATE  SERVICE VERSION
25/tcp  closed smtp
80/tcp  open   sip     JAWS/1.0prebeta (Status: 404 Not Found)
110/tcp closed pop3
1 service unrecognized despite returning data.
SF-Port80-TCP:V=4.68%I=7%D=7/21%Time=4883806B%P=i686-pc-windows-windows%r(
SF:GetRequest,BFF,”HTTP/1\.1\x20200\x20OK\r\nConnection:\x20close\r\nDate:
SF:\x20Sun,\x2020\x20Jul\x202008\x2018:12:28\x20GMT\r\nContent-Type:\x20te
SF:xt/html\r\n\r\n<html>\n<head>\n<meta\x20http-equiv=\”Content-Type\”\x20
SF:content=\”text/html;\x20charset=gb2312\”\x20/>\n<link\x20rel=\”styleshe
SF:et\”\x20type=\”text/css\”\x20href=\”http://res\.mail\.qq\.com/zh_CN/htm
SF:ledition20080709/style/comm\.css\”\x20/>\n<link\x20rel=\”stylesheet\”\x
SF:20type=\”text/css\”\x20href=\”http://res\.mail\.qq\.com/zh_CN/htmlediti
SF:on20080709/style/skin0\.css\”\x20/>\n<!–script\x20language=\”javascrip
SF:t\”\x20src=\”http://res\.mail\.qq\.com/zh_CN/htmledition20080709/js/all
SF:\.js\”></script–>\n<title>QQ\xd3\xca\xcf\xe4</title>\n<style>\n</style
SF:>\n</head>\n<body\x20class=tipbg\x20style=\”text-align:center\”>\n<scri
SF:pt>\nvar\x20flagMsgbox\x20=\x20true;\nvar\x20fsuccesss\x20=\x20\”\”;\x2
SF:0</script>\n<script>\nvar\x20isMainFrameError\x20=\x20!top\.GetMainWin\
SF:x20\|\|\x20top\.GetMainWin\(\)\x20==\x20window\x20\|\|\x20top\x20==\x20
SF:window;\nif\x20\(isMainFrameError\)\n{\n\twindow\.onerror\x20=\x20funct
SF:ion\(msg,\x20url,\x20line\)\x20{return\x20true;};\n\twindow\.onload\x20
SF:=\x20function\(\)\n\t{\n\t\tdocument\.bod”)%r(FourOhFourRequest,10F,”HT
SF:TP/1\.0\x20404\x20Not\x20Found\r\nServer:\x20JAWS/1\.0prebeta\r\nConten
SF:t-type:\x20text/html\r\nContent-length:\x20174\r\n\r\n<html>\n<head><ti
SF:tle>Server\x20error\x20message</title></head>\n<body>\n<h1>Error\x20404
SF::\x20Not\x20Found</h1>\nThe\x20request\x20could\x20not\x20be\x20complet
SF:ed\x20because:\n\x20Document\x20not\x20found!\n</body>\n</html>\n”)%r(S
SF:IPOptions,104,”SIP/2\.0\x20404\x20Not\x20Found\r\nServer:\x20JAWS/1\.0p
SF:rebeta\r\nContent-type:\x20text/html\r\nContent-length:\x20164\r\n\r\n<
SF:html>\n<head><title>Server\x20error\x20message</title></head>\n<body>\n
SF:<h1>Error\x20404:\x20Not\x20Found</h1>\nThe\x20request\x20could\x20not\
SF:x20be\x20completed\x20because:\n\x20Not\x20Found\n</body>\n</html>\n”);
Aggressive OS guesses: Emprex ME1 Multimedia Enclosure media server (Linux 2.6.1
2) (91%), Linux 2.6.17 – 2.6.23 (90%), Linux 2.6.5 – 2.6.19 (90%), Secure Comput
ing SnapGear SG300 firewall (90%), Siemens Gigaset SE515dsl wireless broadband r
outer (90%), Belkin Wireless Pre-N Router (90%), FON La Fonera WAP (OpenWrt, Lin
ux 2.4.32) (88%), D-Link DSL-G624T wireless ADSL router (Linux 2.4.17) or Netgea
r DG834G WAP (firmware 4.01.19) (87%), Toshiba Magnia SG10 server appliance (Lin
ux 2.4.18) (87%), Linux 2.6.22 – 2.6.23 (86%)
No exact OS matches for host (test conditions non-ideal).

OS and Service detection performed
.
Nmap done: 1 IP address (1 host up) scanned in 77.047 seconds

//接着来看下mx0.qq.com(qq邮件服务器)
D:\nmap>nmap -sVC -O -T4 mx0.qq.com

Starting Nmap at 2008-07-21 02:17 中国标准时间
Warning: Hostname mx0.qq.com resolves to 9 IPs. Using 58.251.63.172.
Insufficient responses for TCP sequencing (1), OS detection may be less accurate

Interesting ports on reverse.gdsz.cncnet.net (58.251.63.172):
Not shown: 1712 filtered ports
PORT    STATE  SERVICE VERSION
25/tcp  open   smtp    Postfix smtpd
|_ SMTPcommands: EHLO mx15.qq.com, PIPELINING, SIZE 78643200, VRFY, 250 8BITMIME

80/tcp  closed http
443/tcp closed https
Device type: media device
Running: Emprex Linux 2.6.X
OS details: Emprex ME1 Multimedia Enclosure media server (Linux 2.6.12)

OS and Service detection performed
.
Nmap done: 1 IP address (1 host up) scanned in 25.797 seconds

//接着来看下mx15.qq.com(内部的?只是在mx0.qq.com的回应中看到,很有可能还有mx14.qq.com… :) )
//表面上看这上边的服务要比mx0多呀,ssh,http,1234,…
D:\nmap>nmap -sVC -O -T4 mx15.qq.com

Starting Nmap at 2008-07-21 02:20 中国标准时间
Warning: Giving up on port early because retransmission cap hit.
Insufficient responses for TCP sequencing (2), OS detection may be less accurate

Interesting ports on 202.111.148.132:
Not shown: 1446 closed ports, 263 filtered ports
PORT      STATE SERVICE          VERSION
22/tcp    open  ssh              SunSSH 1.1 (protocol 2.0)
80/tcp    open  http?
|_ HTML title: Site doesn’t have a title.
1234/tcp  open  tcpwrapped
8009/tcp  open  ajp13?
8080/tcp  open  http-proxy?
32776/tcp open  sometimes-rpc15?
Device type: general purpose
Running (JUST GUESSING) : FreeBSD 6.X (87%)
Aggressive OS guesses: FreeBSD 6.2-RELEASE (87%)
No exact OS matches for host (test conditions non-ideal).
Uptime: 157.260 days (since Thu Feb 14 20:12:02 2008)

OS and Service detection performed
.
Nmap done: 1 IP address (1 host up) scanned in 374.172 seconds

//接着看DNS服务器
D:\nmap>nmap -sVC -O -T4 dns1.imok.net

Starting Nmap at 2008-07-21 02:33 中国标准时间
Insufficient responses for TCP sequencing (2), OS detection may be less accurate

Interesting ports on 219.133.40.202:
Not shown: 1461 filtered ports, 253 closed ports
PORT   STATE SERVICE VERSION
53/tcp open  domain
Device type: media device
Running: Emprex Linux 2.6.X
OS details: Emprex ME1 Multimedia Enclosure media server (Linux 2.6.12)
Uptime: 94.202 days (since Thu Apr 17 21:42:39 2008)

OS and Service detection performed
.
Nmap done: 1 IP address (1 host up) scanned in 35.703 seconds

//难道这个是win服务器还把135-139给过滤啦!,此地无银300两,内网中?
D:\nmap>nmap -sVC -O -T4 dns2.imok.net

Starting Nmap at 2008-07-21 02:34 中国标准时间
Interesting ports on 61.152.100.5:
Not shown: 1696 closed ports
PORT     STATE    SERVICE        VERSION
42/tcp   filtered nameserver
53/tcp   open     domain
135/tcp  filtered msrpc
136/tcp  filtered profile
137/tcp  filtered netbios-ns
138/tcp  filtered netbios-dgm
139/tcp  filtered netbios-ssn
445/tcp  filtered microsoft-ds
593/tcp  filtered http-rpc-epmap
1025/tcp filtered NFS-or-IIS
1068/tcp filtered instl_bootc
1433/tcp filtered ms-sql-s
1434/tcp filtered ms-sql-m
3128/tcp filtered squid-http
4444/tcp filtered krb524
5800/tcp filtered vnc-http
5900/tcp filtered vnc
6699/tcp filtered napster
7003/tcp filtered afs3-vlserver
Device type: general purpose
Running: Linux 2.4.X
OS details: Linux 2.4.21 – 2.4.33, Linux 2.4.28 – 2.4.30
Uptime: 278.438 days (since Tue Oct 16 16:04:56 2007)

OS and Service detection performed
.
Nmap done: 1 IP address (1 host up) scanned in 29.375 seconds

D:\nmap>nmap -sVC -O -T4 dns3.imok.net

Starting Nmap at 2008-07-21 02:37 中国标准时间
Interesting ports on 218.30.72.181:
Not shown: 1450 filtered ports, 264 closed ports
PORT   STATE SERVICE VERSION
53/tcp open  domain
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.13 – 2.6.20
Uptime: 123.691 days (since Wed Mar 19 10:02:37 2008)

OS and Service detection performed
.
Nmap done: 1 IP address (1 host up) scanned in 34.391 seconds

//看下顶级域
D:\nmap>nmap -sVC -O -T4 qq.com

Starting Nmap at 2008-07-21 02:40 中国标准时间
Interesting ports on 219.133.40.91:
Not shown: 1714 filtered ports
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd
|_ HTML title: 302 Found
Warning: OSScan results may be unreliable because we could not find at least 1 o
pen and 1 closed port
Device type: WAP
Running: Linux 2.4.X
OS details: Buffalo WHR-HP-G54 WAP or Linksys WRT54GL WAP running DD-WRT Linux 2
.4.20 – 2.4.34
Uptime: 51.594 days (since Fri May 30 12:25:37 2008)

OS and Service detection performed
.
Nmap done: 1 IP address (1 host up) scanned in 16.218 seconds

D:\nmap>

ok,myblog:http://clin003.com/
没有恶意,学习用nslookup和nmap :)

(PS:几个DNS不是标配啊,:-0 )

附:
219.133.40.0 广东省深圳市 电信(宝安区)

219.133.49.0 广东省深圳市 电信(宝安区)

58.60.8.0 广东省深圳市 电信

222.202.96.0 # 查询结果3:广东省深圳市 腾讯公司教育网接口

121.14.73.0 广东省深圳市 电信IDC机房

121.14.74.0 广东省深圳市 电信IDC机房

121.14.76.0 广东省深圳市 电信IDC机房

64.71.138.0 美国 加洲

58.251.60.0 广东省深圳市 网通

219.133.60.0 广东省深圳市宝安区 电信

59.42.249.0 广东省广州市 电信ADSL

今日一点 , ,

web2.O下的广告投放思考

April 6th, 2008

算是读“bbs,分众,百度,媒体,受众,价值,1.0-2.0的一大堆”的读后的一点点感觉吧!

掌握尽可能多的目标对象信息——用户隐私的权重——facebook的广告投放尝试。

挖掘目标对象关注的内容——推送内容相关性广告——google adsense——Gmail右侧广告。

总之web2.O下的广告投放的首要考虑因素从web1.0的量的追求转化为对质量(广告投放所能获得的效益)的追求,至少web2.O提供啦这种追求转变的必要因素——用户信息组成的社会化关系网络。

至于哪家敢不敢狠挖“用户隐私”,而后“投放精准型广告”(不知道能不能理解为一对一的广告投放),也说不定。(腾讯推精准广告投放

可以倡导一种协议:协议的内容就是“服务商”可以获取并利用“得到用户同意的个人信息或者个人爱好”的一些信息作为个性化服务推广(比如但不限于广告精准投放)。

想到百度空间就非常显眼的个人爱好和个人信息公布出来提供交友服务共享,而不提供任何的可以选择避免暴露这些信息资料的措施!!

今日一点 , , , , ,

看到技术文章很稀奇——微软安全服务提供专家方兴:Web2.O安全研究

March 22nd, 2008

时代变啦:

在WEB旧时代好多站点我们告诫用户你只上你信任的站点,不要上人家发给你的站点,上面可能有挂马。这时候用 户只关心站点,或者你用QQ发一个URL他会标注安全的站点,可能普通用户看见打了勾肯定是安全的。普通用户主要依赖于防范病毒的产品保护来自不可信站点 的攻击。但是在新的时代,安全的站点也不能保证你的安全,因为你通过Web2.0的方式,内容是由很多不可信的用户提供的。所以,用户还要要关心站点的安 全和历史安全信誉。虽然是一个正规的大站点,但是如果连续不断地被挂马,对于这样的站点,用户就应该认为它是不可信的。另外在复杂的体系结构中已不能依赖 原先的保护技术,因为很难防御所有入侵和0DAY,防御动态攻击的内容。 

Windows底层和漏洞挖掘方面的专家方兴就现今Web2.0领域的安全问题与解决方法与到场嘉宾进行分享。

以下为方兴发言实录:

方兴:先做个自我介绍,我叫方兴,以前主要关注的领域是操作系统安全漏洞的挖掘,但是现在我给大家做Web2.0的演讲,实际我是抱着学习的态度,因为腾讯公司作为一个网络,在WEB方面的研究应该比我更多一些。首先我们来预览一下今天讲的主要内容。今天WEB时代的安全与发展风险,相对于以前WEB1.0的时代增加了哪些问题。其次我们来看待它的新的安全需求。最后我们来看它的整个安全发展情况。

为什么我这个题目叫新WEB时代而不用 Web2.0呢?因为Web2.0只是一个开始,只是个时代发展的序幕,它最终的目的是要发展成为取代现代客户端计算的模式。以Web2.0为主要的运用成为了一种趋势。WEB运用逐渐向传统的应用领域渗透,比如我们经常去的Google这家网站。它最终的发展目标就是要把INTERNET变成为数据处理和储存的中心,网络取代传统的OS成为应用的中心:网络既计算机。

这里是一些统计数据(图),关于Web2.0目前的发展趋势。80%以上的基于网络的公司都投资在Web2.0当中来进行开发。在2007年,30%的客户都基于商业上的应用技术。预计到2008年,基于服务器服务构架的SOA会逐步朝着这种模式发展。在当前,安全是WEB向这方面发展的主要障碍之一,因为成为数据和存储处理中心,将会带来很大的安全风险。

在新的WEB时代存在一些什么样的主要特征呢?这些特征又会给我们带来什么样的安全风险?首先,它跟传统的我们以前的WEB时代存在的区别:第一、处理和数据控制集中化,因为它最终目的是把所有的网络计算核心从客户端拿到网络端上。而以后客户机只扮演纯粹的浏览界面的角色,所有的核心数据、核心的处理全部都在网络端。第二、它的内容来源控制分散化,这是当前我们在Web2.0当中看到的最大趋势,以前的WEB1.0是以我为主,比如新浪作为一个新闻中心,我发布了,作为受众来说是被动接受,以前 WEB1.0是核心控制的,但是在Web2.0我们发现草根阶级的应用上来了,它的各种内容不再依赖于核心端来发送,而是依赖于用户主动提供,比如你的博客,你个人提供的各种内容取代了以前核心控制端发布的内容。从数据来源上看它是分散化的。第三、应用网络化。网络应用正逐步蚕食掉现在桌面的应用,而用网络的方式来实现。在这一点上面,以前Google在这方面的表现是最具竞争性的,它想取代微软作为IT行业的霸主,因为作为微软来说它核心的 Windows操作系统已经占有了不可动摇的地位,想要动摇它的地位,只有把所有的应用都逐步换成网络模式,用户就不再需要你的OS,不再需要你的操作系统,他就能真正地从微软的手上取代它的霸主地位,这是它的策略。第四、内容聚合化,因为以前是单一的站点,但是随着未来的发展,信息是逐步交叉的,在 Web2.0上更多地要对内容进行聚合,对不同内容信息来丰富页面,提供更强大的功能。这些特征都将带来新的安全风险。

在处理和数据控制集中化,比如我们的 Gmail,随着Gmail,网络硬盘提供的数据越来越多,都是直接存在网络上,你的操作全部都是放在上面,它处理和数据控制形成了集中化。从需求因素来考虑,首先是数据和处理要集中化,成为计算中心。但是这样会导致一些问题,第一是敏感和隐私数据集中存在,比如以前大家上WEB Mail,商务信件都放在本机。但是现在用Gmail都懒得删除,反正用10G的硬盘,但是你会发现越来越多的敏感信息都放在网络,一旦你相关的邮件信息被黑客攻破,他们就会获得你的很敏感的商业信息。第二是应用越来越依赖网络,一旦网络出现故障,比如台海地震,中国很多的靠进出口加以贸易就会出现损失。再就是大量的海量数据会导致WEB服务器端构架复杂化。

从内容来源控制的分散化,它主要表现在博客、维客和播客上,需求性因素是站点要给用户提供个性化的内容、满足用户的表达和传播需求。它会导致用户和内容海量膨胀,比如新浪有几百万的博客,有几千万用户在上面,每天更新的博客文章数据都是海量增长的。但是,因为它开放了这种平台,导致用户可以在受信的平台上面放置恶意的内容,比钓鱼、木马。用户会认为新浪一个很好的公司,他这个平台上的数据都是可信的,肯定不会做这些事情,根本就不会想到它上面依然可能由于用户提交的内容而存在木马等恶意内容。

从应用网络化的表现,主要表现在 WEBOS,WEB OFFICE等。它需求性的因素是因为网络应用要逐步取代传统的桌面,它要有能力提供越来越多的应用以及应用开发接口。网络最后要取代传统的OS,成为计算中心的话,我们去观察一下以前Windows操作系统为什么能程度一代霸主,因为它提供的很多开发接口,海量增长的应用使得OS极大的满足了用户的需求,用户可以去编写自己或许客户定制需要的程序,未来相信网络要逐步取代的话也会出现这种提供开发接口的平台,允许你在网络平台上编写应用,最后再组合起来。这样会导致比如引入新的技术,比如AJAX技术,对会话状态的依赖,以前WEB1.0对会话状态并不是很依赖。但是网络的应用就要求你本身具备这些复杂会话状态的跟踪和管理。

再就是WEB的应用逻辑会越来越复杂化。无论是服务器还是客户端的代码都会复杂化。另外我们看到浏览器的功能越来越复杂,互相嵌入性的操作越来越多。另外是WEB服务器构架也复杂化。因为网络的后台需要包括数据库等相关所依赖的技术来支持,它会变得很复杂。

内容的聚合化表现最多的就是搜索引擎以及 RSS,需求性的因素是网络需要更多的互动,使其关联与互操作。比如搜索引擎会自动搜集网络上的很多内容,RSS则直接嵌入内容。为了保证访问性还采用了一些CACHE方式,这就导致攻击者可以采用内容聚合来推广他的恶意页面,同时使得数据感染性增强。

我们来着重看一下这四点导致的安全风险。数据保密要求增高之后,敏感隐私数据泄露途径增多,以前可能只存在你的机器上,现在存在服务器上,可以在你的通讯途中被窃取,你保存数据的服务器被攻击,或者是其它的各种方式,都可能导致你的数据损失。另外,你无法保证服务的提供商不利用你的敏感和和隐私数据。这当中最常见的就是朋友圈、MSN朋友圈、QQ朋友圈,他要求你提交用户和口令向你的好友发广告,实际上就利用了里的敏感信息来做非法的事情。

数据依赖会导致安全风险放大,可能影响海量用户,比如信用卡的泄露,信用卡一被泄露都是几百万、上千万的客户受到损害。另外就是DOS攻击和意外事件也会导致大量损失,因为越来越依赖网络的时候,它的拒绝服务攻击的厉害程度,包括整个商务、商业上面的应用影响都会增加。

从内容来源控制分散化带来的安全风险主要是内容不可控性增加,因为恶意客户可以方便的借助受信平台发起攻击,而你没办法进行检测。而且众多的用户提交内容检测困难。另外就是用户不可控性增加,虽然在你上面注册的ID,但是对海量用户的存在进行追查是非常困难的。

应用网络化带来的安全风险。因为应用网络本身就会带来数据的集中化,导致互操作性增加,多域应用,外部内容来源增加,比如BASECAMP是帮助企业做调度和任务管理的Web2.0,但是我们就发现它上面存在不过滤上传内容,你直接可以在里面加上脚本代码发起攻击。用户间的互影响性增加,大家都知道使MYSPACE蠕虫,通过一个用户的版本可以瞬间传递给所有的平台上的用户。再就是程序复杂度增加,以前的WEB应用逻辑大家都知道相对简单,但是随着未来的发展,它肯定要增加越来越多的复杂程序逻辑,才能满足把网络中心变成网络及计算的理念。而WEB应用存在的最大问题是:第一,WEB网络应用未得到广泛的安全测试,因为它大多都是小的厂商,相对来说像微软这种巨无霸能一家完全控制得WEB应用提供商目前是不存在的。比如我们以前说微软的安全很差,但是微软很庞大,所有的技术都是用它,一旦它有决心来改正这个问题,它可以用很多资源把安全作的恨号。Vista用了几年时间就把安全级别提到很高,在2007年,黑客发布的能确定影响到vista的攻击代码只有3个,而XP下面的数据则是30多个。但是对于WEB来说不存在这样的情况,WEB应用的厂商太多。再就是它的开发缺乏安全过程,都是小团队开发,做得好一点的也只是用用一点安全编程的规则去检查代码。另外,Web2.0还是在不断发展的技术,它为了满足前面提到的把计算到网络化,它要不断地采用新技术,增加各种动态性应用的技术。这些新技术会带来新的安全弱点。另外,动态性的增加代码,也会引入很多新的困难。包括对攻击代码的检测,利用时间的动态性、应用的动态性。以前的对恶意页面的反病毒检测,都没办法实时动态跟踪检测,利用这些新技术的动态性,会对检测技术提出很大的挑战。

再一个是浏览器的安全模型会越来越复杂,它涉及到众多的插件,像Flash的as脚本,FLASH是支持脚本操作的,但是由于一经被编译,攻击者可以把恶意脚本放在Flash里导致无法检测。还有跨站和域的安全问题,包括特定的像URL欺骗的问题,这都是我们常规的方法难以解决的安全性问题。引进的新的技术带来的复杂度,会增加安全检测的复杂度,大家都知道,AJAX在页面当中是不用刷新页面,通过AJAX通道动态去获得后台的内容。如果攻击者在运行当中通过AJAX获得恶意内容,然后再对你进行攻击。我们现在有的各种检测技术,特征方面的检测方法都很难检测到这种方式。

这是基于Web2.0复杂的架构(图),在这个图中我们可以看到,WEB2.0的体系结构比WEB1.0复杂很多,而且可以预见:未来为了支持更多的网络应用,会更加复杂。

在浏览器端增加了AJAX、RIA、FLASH的支持,在结构的数据传递上,现在可以做出更加复杂的数据进行传递。在结构上面以前是普通的参数传递,现在可以支持各种RPC的调用以及复杂的数据结构。

从内容聚合带来的安全风险,第一、恶意叶面扩散能力增加,可以利用搜索和RSS把恶意内容嵌入到一个非常有名的RSS或者很前的排名,增加它的传播能力。攻击者还可以利用关键字或者一些恶意技术来获得排名提升能力,比如使用“艳照门”照片提升受害者访问量,使得更多的被攻击者受到感染。有些RSS或其他直接聚合内容,使得这个RSS自身就被感染携带了攻击能力,访问这个RSS的用户也会受到攻击。

聚合导致资源来自多个不同域,控制和检测都存在比较大的困难。另外这个对商业站点的影响性也会加大,我们经常在一些搜索引擎的推广上发现有挂马的现象,它对这些搜索引擎的访问推广站点的商业客户影响比较大,而给这些搜索引擎的商业模式会造成影响。还有是它的感染性和隐蔽性变得很强,大家知道搜索引擎和RSS里的CACHE的功能,一个恶意页面被感染 CACHE,即使原始恶意内容页面被拿下后,利用CACHE的页面依然可以攻击很多用户,很多时候大家都会发现页面访问不到,但是感兴趣的时候还是会打开 CACHE。另一个,攻击者或许可以用这个方式来隐藏自己,用一些比较敏感的、比较受欢迎的关键字,被搜索CACHE之后再把自己蔽掉,利用CACHE去发起攻击,就很难抓捕到这种攻击者。

还有一些其它的问题,第一是流氓越来越多,恶意软件越来越基于WEB进行传播,恶意站点,钓鱼站点越来越多。说到钓鱼站点前几天还看了一个新闻就有一个骗子,他就给很多手机上发一条信息我叫王伟,我的帐号是XX,给我汇钱,结果一个月不到还有人给他汇了八十多万,这就说明就有这么傻的人在,这是没有办法解决的。所以利用钓鱼依然能骗到很多这样的用户。基于网络的这种钓鱼方式成本越来越低,并且越来越容易操作,总有上当受骗的。

第二是流氓成本越来越低,收入越来越高,这是没有办法的,道德的水准跟收入水准成反比。再一个,WEB的经济模式带来的流氓同流化非常严重,也就是说我在另一个群里做站点,他们就谈到,现在你要做站点的推广,你不去跟软件进行绑定,做得再好也没办法获得比较高的流量。所以很多站点的推广全部选择了流氓,这也是我们现在整个安全行业里很大的问题。另一个是利用社会工程发起的攻击会越来越多,鉴别这种社会工程的欺骗比较困难。

前面第一章谈到了目前Web2.0的发展和需求上我们面临的很多问题。接下来我们来看一下它的安全需求。分析安全需求之前我们应该对体系与技术的变化进行一些了解,才能从中看到一些变化。

第一,我们在旧的WEB时代和新的WEB时代进行技术体系与技术结构的比较。在协议上的变化,以前只使用HTTP/HTTPS来识别。在新的里面我们增加了SOAP、RPC等等,在未来可能会增加更多的这样的协议。在信息传递的结构上面,以前是靠HTML的FORM来提交的数据。在现在,随着发展,XML及各种新的数据组织结构越来越多。通讯以前都是同步提交,刷新重定向,现在都是异步跨域,实时通讯。会话通讯能力以前是比较弱的,但是现在由于关联性加强,应用要求对会话的依赖越来越高。在信息交互上以前是单点的信息,现在是多点信息聚合,在一个页面上可能存在着很多的信息流、数据流,和服务器进行通讯。

威胁模型变化:威胁模型评估三个要素:进入点、资产以及受信级别。我们来对比新旧WEB时代。在进入点上,攻击者只有通过入口点才能发起攻击,在以前的时代基本上是很简单的入口点,很容易发现。在新的时代下面存在多种分散入口点,因为现在它通过新的技术在线实时通讯去传递数据,一个页面上可能存在六、七个数据通道。由于网络复杂性,依赖度会增加,也就是说它的数据间的相关性增加了,导致入口点和路径会海量增加。另外是退出接口信息泄露的风险在变高,当程序部分状态改变以后,狠可能一些敏感信息还残留在页面上。

从资产的情况来看,对于安全威胁来说,如果不存在资产,哪怕有一百个可以利用漏洞的也没有安全风险,因为上面没有什么东西值得你关心的。攻击者把你的乱七八糟的东西偷走了你还感谢他帮你清理了垃圾。也就是说当你存着有价值的资产的时候安全才是重要的。随着新WEB时代的应用,商业上的应用会越来越多,有价值是的数据在不断增加的,有些甚至是企业的核心价值所在,因此安全的风险也是在增加的。受信级别来说,以前的受信级别是比较简单的,现在复杂的应用自然导致受信级别机制更加复杂。

从安全威胁的变化来看,从进入点上以前是结构数据入口,现在是多种分散入口,用户场景更复杂,涉及到各种各样要考虑的问题,从依赖上面来看,以前的一个WEB的服务器对外部的依赖度、关联度是很有限的,最多是跟数据服务器有关,现在随着新的技术体系的发展与变化,对海量数据海量用户和复杂应用的支持,外部依赖越来越多,再多信息源的、多协议、多技术体系结构、多种外部相关服务的情况下,配置也会越来越复杂,这种越来越复杂会带来对相关的外界的依赖,你本身可以做到很安全,但是你外界的东西不安全的话一样会影响到你的整个安全度。

从漏洞和利用上来看,以前更多在服务器端,而现在既要关心服务器端,还要关心客户端和关心第三方内容的安全。

从漏洞挖掘的方法学的变化,以前的通道是 DNS,现在直接可以用搜索引擎发现你的后台敏感页面。从漏洞发现上面,以前很容易,通过分析提交数据的结构化来构造测试发现安全问题,但是现在通过 AJAX,它是隐藏在多个调用里,发现困难。而且整个数据流非常的多。以前做扫描器扫描这些漏洞结构化是非常简单的事情,但是现在就要分析AJAX,包括内部的各种状态依赖,然后再去自动地扫描和发现,这是非常高成本的。在逆向代码的分析上,以前只关心服务器,现在更关心客户的安全,包括你的跨站可能会对你的访问端带来的攻击。

这里说明了在新的WEB时代是越来越复杂(图),安全性越来越复杂,需要考虑的东西越来越多。我们前面对比了这些发展,我们可以总结出一些服务器端安全需求的变化。在WEB旧时代只关心恶意攻击服务器的安全,很少关心用户的安全以及聚合的第三方的安全。但是在新的时代要关心服务器端,首先要关心恶意攻击,还要关心用户提交的内容是不是安全的,还要关心WEB的应用代码数据整体关联,比如用户是否能提交一个脚本,然后在其它的用户端进行跨段的欺骗。另一个,他要关心自己整个站点的安全和信誉度。也就是说,当电子商务逐步建立起来之后,长期的安全是用户长期使用你的信心保证。出现风险事件会极大降低用户对你的安全信心。也就是要维持历史一贯性的安全和信誉,需要关注和保护用户,因为商业用户越来越多,客户也是你的资产。像淘宝上攻击者如果利用跨域攻击或欺骗另外的用户信息,虽然对商家的直接影响很小,但是它给客户带来重大损失,导致客户的流失。

所以,作为WEB服务器方提供者,不仅要关注自己的安全,还要关注自己用户端的安全,这些是不是会给你的用户带来危害。另外还要关心聚合的第三方,像搜索引擎需要关心引用和CACHE的内容,以及 URL的安全。关心推荐站点和引用站点的安全和信誉度。也就是说,在新的时代不再是你只关心自己安全的时代,而要关心到所有跟你的商务相关的客体安全。

从桌面端我们可以一些需求变化。在WEB旧时代好多站点我们告诫用户你只上你信任的站点,不要上人家发给你的站点,上面可能有挂马。这时候用户只关心站点,或者你用QQ发一个URL他会标注安全的站点,可能普通用户看见打了勾肯定是安全的。普通用户主要依赖于防范病毒的产品保护来自不可信站点的攻击。但是在新的时代,安全的站点也不能保证你的安全,因为你通过Web2.0的方式,内容是由很多不可信的用户提供的。所以,用户还要要关心站点的安全和历史安全信誉。虽然是一个正规的大站点,但是如果连续不断地被挂马,对于这样的站点,用户就应该认为它是不可信的。另外在复杂的体系结构中已不能依赖原先的保护技术,因为很难防御所有入侵和0DAY,防御动态攻击的内容。

在服务器端要动态有效的管理众多的用户提交 WEB内容和用户,保护复杂的WEB应用不危害到站点和用户,另外还要实现站点的信誉度和安全度评估。在客户端还需要有更好地检测和保护技术,还能预防 0DAY以及新的攻击模式,帮助过滤有害的URL,钓鱼站点等恶意攻击。帮助客户获取对站点的信誉度安全度评估的信息。对于搜索引擎和聚合服务体商需要检测判断恶意URL,需要过滤CACHE页面或聚合内容中的恶意内容,需要对广告和推广站点的内容进行动态实时检测。

当前的WEB各种保护技术是否能保证我们前面提到的安全需求。关于WEB服务器端我们前面提到的几个需求,第一,动态实时有效地管理众多的用户提交WEB内容和用户的安全。用户数据提交渠道增多,为了开放个性化的发展,比如很多Blog都提供了包括允许用户写自己的脚本,写自己各种各样的功能在里面,嵌入很多代码。就目前来说,还缺乏有效检测和管理手段,更多是靠人工举报的方式。

在保护复杂的WEB应用不危害到站点和用户的时候,目前很多厂商还是使用陈旧的保护服务器端的技术,对WEB服务器系统的保护,而很少涉及到应用。比如针对OS和HTTP SERVER作漏洞扫描,对于新的逻辑的构架,这种体系,包括外部越来越依赖各种服务和软件的WEB应用缺乏。现有的针对WEB页面安全的检测,也主要是基于提交参数进行检测,但是应用复杂度使得它的提取参数的技术越来越复杂。另一个,这种应用复杂度带来的新技术引入带来的安全风险。另外,对跨站/逻辑 /欺骗也缺乏很有效的检测方法。对于WEB的安全测试也缺乏理论指导,目前只是简单地利用工具来检查一下SQL注射。但在整个会话性和互动性越来越相关和复杂的情况下,这些检测技术越来越困难难以有效果,因为检测要模拟整个状态,包括登录、操作等相关的过程之后,导致检测模式越来越复杂。更缺乏对交互性应用的检测的方法。而站点的信誉度安全度评估缺乏公正且有长期的跟踪和评估依据。

我们再来看一下当前WEB CLIENT端安全保护技术是否能面对现在的安全需求,在CLIENT的保护技术主要是这样几种,一是基于特征的检测。第二是行为检测,比如攻击之后调用的API的调用,来判断是不是异常的信息。还有一种是提供最小特权和权限控制来进行保护。另一个是提供恶意/钓鱼站点过滤名单来检测。但是,这些技术它都存在着对应的逃避和减弱保护的手段。
比如CLIENT端逃避特征检测。它更多是依赖于已经出现的东西来提取特征进行检测。这种方法是很难检测 0day攻击的。攻击者可以使用HTML/脚本动态加密可以有效地逃避特征检测。还可以使用第3方插件脚本,比如Flash的AS,现在这种很难检测,因为Flash已经被编译了。另一个是动态攻击,比如随机后台判定,动态页面。利用AJAX通道,现在很多检测特征是没办法在运行时来进行判断的。还有就是钓鱼或跨站攻击,你很难利用一个特征去检测。

在CLIENT端逃避行为检测的变化,第一是变化行为,我知道你用这个方法来检测我,我就不使用被检测的行为。再就是用其他类似行为替代被检测的行为。再一个功能行为思路改变:比如只窃取信息而不谋取最后木马种植能力。比如很多很多检测都是对创建进程、创建线程时,敏感操作时进行检测。但是我只窃取你IE当中的敏感信息九就可以绕过检测,还可以利用一些受信程序不被重视难以攻击而不被修补的漏洞来实现一些敏感操作行为。还有一种是利用SHELLCODE来进行对抗,因为行为的检查是滞后,SHELLCODE可以解除检测代码,关闭检测机制/程序,模拟或操纵受信模块来完成相关的行为。

在逃避最小特权和权限控制上面,可以使用提权0DAY,还可以欺骗用户获取授权,比如模拟受信BACTIVEX安装,很多缺乏安全意识的用户就选择了接受。再就是用户态攻击,例如URL欺骗,钓鱼。

在整个WEB搜索和聚合服务安全保护技术上,以GOOGLE和微软的HONEYMONKEY为主,但是在效率和 准确性上还是存在着很多问题。

结论:我们现在面临新的WEB新时代发展的安全需求依然准备不足,没办法从根本上保护WEB服务器端和客户端的安全,无法遏制钓鱼和流氓行为。

第三点是自己的一点想法:新的时代,我们需要整体的WEB保护方案,它能够提供对企业外网和WEB应用,内容聚合服务和搜索引擎,企业内网用户和普通用户都提供完整的保护。要提供多向多角度的来源安全保护。

针对WEB服务器的安全保护,要增加复杂的体系架构的检测和保护能力,增加WEB应用检测和保护能力,例如跟踪会话、复杂的结构和逻辑,加强对新的技术引入带来的新的攻击手段核威胁的研究。增加用户来源内容的检测和保护能力,增加对外部聚合内容的检测保护能力。

这里提一下WEB桌面的安全保护发展。必须要提供运行时可信的检测与保护,应对这些动态和新的逃避技术的攻击,应对0DAY的攻击。另外 就是提供多层次的防御体系,VISTA就是缓冲区溢出的入侵路径上设置了多层次的防御体系来极大的提升安全度的。从未来发展来看,WEB桌面的安全保护和发展应该是多层次全方面的保护,层层阻截,降低危害,最终保护安全的底线。

没有一个技术是能完整保护系统不受攻击的,只有多层防护的体系才能将安全风险降低到可接受的低层度。在下面五个层次都要进行保护(图)。

感谢:知道创宇公司在这方面的一些研究成果

现场问答:

问:您刚才提到可以通过动态加密的方式来进行客户端的检测,我的问题是,这种方式是否有比较好的解决方案?除了运行时的检测是否还有其它的方案?

方兴:如果无法开发出动态运行时检测的方法,那么 可以通过 多 层次的保护体系来阻止,通过层层的阻截。以前一百个漏洞攻击者可以利用百分之百的利用,但是你设置了这些层层阻截的时候,一百个当中可能就只有一个能完全利用了。虽然还有一个可应用,但是攻击者的成本变高了,就意味着攻击者应用它获得更大的利益才是合算的,从某种意义上来说一个攻击者不会用这么高成本的东西去攻击普通用户的,针对有加值的商业用户,成功的入侵与攻击也会明显减少。

问:刚才提到MYSPACE的案例,请问国内有没有类似的攻击情况,以及攻击趋势会不会成为新的攻击趋势?

方兴:国内baidu空间上出现过类似问题,这只是其中的一种趋势。

原文地址:http://tech.qq.com/a/20080318/000329.htm

技术分析 , , , , , , , , ,