V2EX › thekll 的所有回复 › 第 10 页 / 共 13 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 2 3 4 5 6 7 8 9 10 11 ... 13

❮

❯

2014 年 7 月 25 日

回复了 thekll 创建的主题 › 程序员 › openvpn tcp 协议在国际出口被封了吗

今天发现电信接入的tcp、udp都被强了，联通3G(udp)暂时可用.

2014 年 7 月 23 日

回复了 thekll 创建的主题 › 程序员 › openvpn tcp 协议在国际出口被封了吗

@Nin
用这个的话，服务端是不是必须是Cisco ASA设备，或者ocserv？
一些公用的vpn，如openvpn，vpngate不支持anyconnect客户端吧？

2014 年 7 月 23 日

回复了 mengzhuo 创建的主题 › 程序员 › 微软的机器翻译已经逆天了

google翻译结果：
一个“A”记录需要为主机使用的每个IP地址创建。
除了语法顺序的问题，意思上更准确些吧。
另外，Google语音输入翻译也很强大。

2014 年 7 月 20 日

回复了 thekll 创建的主题 › Linux › linux8080 端口被攻击，这是怎么做到的？

@dndx
没有SYN啊

@qiuai
从tcpdump的输出来看，应该是基于P2P的DDoS攻击。
google发现UCLA的这篇论文提供了一种解决思路：由于p2p客户端攻击时要建立tcp连接，在握手数据包中会含有BT协议请求，此时过滤掉它，这样就不能建立完整的tcp链路，然后采用SYN-cookie技术解决由此产生的SYN flood.
http://oak.cs.ucla.edu/~sia/pub/cs239spring06.pdf

正在尝试用这个办法解决。

2014 年 7 月 20 日

回复了 thekll 创建的主题 › Linux › linux8080 端口被攻击，这是怎么做到的？

@ysjdx

我觉得还是P2P的DDoS攻击的可能性大一些，所有的包都会出现这样的数据：
每隔约10秒种连续发起几次请求：
01:34:08.375341 IP (tos 0x0, ttl 52, id 11617, offset 0, flags [none], proto: TCP (6), length: 40) 221.11.4.29.8146 > 172.16.201.201.8080: R, cksum 0xe0ed (correct), 68:68(0) ack 1 win 0
0x0000: 4500 0028 2d61 0000 3406 026d dd0b 041d E..(-a..4..m....
0x0010: ac10 c9c9 1fd2 1f90 3b74 3172 470d 848a ........;t1rG...
0x0020: 5014 0000 e0ed 0000 0000 0000 0000 P.............
01:34:08.634566 IP (tos 0x0, ttl 254, id 5929, offset 0, flags [none], proto: TCP (6), length: 40) 221.11.4.29.8259 > 172.16.201.201.8080: S, cksum 0x87cc (correct), 872372089:872372089(0) win 1480
0x0000: 4500 0028 1729 0000 fe06 4ea4 dd0b 041d E..(.)....N.....
0x0010: ac10 c9c9 2043 1f90 33ff 5779 0000 0000 .....C..3.Wy....
0x0020: 5002 05c8 87cc 0000 0000 0000 0000 P.............
01:34:08.634613 IP (tos 0x0, ttl 254, id 5763, offset 0, flags [none], proto: TCP (6), length: 40) 221.11.4.29.8259 > 172.16.201.201.8080: S, cksum 0x87cc (correct), 872372089:872372089(0) win 1480
0x0000: 4500 0028 1683 0000 fe06 4f4a dd0b 041d E..(......OJ....
0x0010: ac10 c9c9 2043 1f90 33ff 5779 0000 0000 .....C..3.Wy....
0x0020: 5002 05c8 87cc 0000 0000 0000 0000 P.............
01:34:08.635147 IP (tos 0x0, ttl 254, id 4579, offset 0, flags [none], proto: TCP (6), length: 40) 221.11.4.29.8259 > 172.16.201.201.8080: ., cksum 0xdb9e (correct), 872372090:872372090(0) ack 1196319952 win 1480
0x0000: 4500 0028 11e3 0000 fe06 53ea dd0b 041d E..(......S.....
0x0010: ac10 c9c9 2043 1f90 33ff 577a 474e 64d0 .....C..3.WzGNd.
0x0020: 5010 05c8 db9e 0000 0000 0000 0000 P.............
01:34:08.659073 IP (tos 0x0, ttl 52, id 11713, offset 0, flags [none], proto: TCP (6), length: 40) 221.11.4.29.8259 > 172.16.201.201.8080: ., cksum 0xe1b1 (correct), 68:68(0) ack 1 win 65392
0x0000: 4500 0028 2dc1 0000 3406 020d dd0b 041d E..(-...4.......
0x0010: ac10 c9c9 2043 1f90 33ff 57be 474e 64d0 .....C..3.W.GNd.
0x0020: 5010 ff70 e1b1 0000 0000 0000 0000 P..p..........
01:34:08.841644 IP (tos 0x0, ttl 52, id 11732, offset 0, flags [none], proto: TCP (6), length: 108) 221.11.4.29.8259 > 172.16.201.201.8080: P, cksum 0xd7aa (correct), 0:68(68) ack 1 win 65392
0x0000: 4500 006c 2dd4 0000 3406 01b6 dd0b 041d E..l-...4.......
0x0010: ac10 c9c9 2043 1f90 33ff 577a 474e 64d0 .....C..3.WzGNd.
0x0020: 5018 ff70 d7aa 0000 1342 6974 546f 7272 P..p.....BitTorr
0x0030: 656e 7420 7072 6f74 6f63 6f6c 0000 0000 ent.protocol....
0x0040: 0018 0005 3014 d66d 104e 0db3 a489 8180 ....0..m.N......
0x0050: 3932 5623 1dd2 072c 2d58 4638 3731 302d 92V#...,-XF8710-
0x0060: 7751 7164 6e34 6370 5076 4963 wQqdn4cpPvIc

对p2p协议不是很了解，不知道这是不是p2p客户端重连机制？

2014 年 7 月 19 日

回复了 thekll 创建的主题 › Linux › linux8080 端口被攻击，这是怎么做到的？

@ultimate010

ip之前已搜索过，没发现什么问题。
8080端口上跑了一个基于glassfish的java企业应用，完全没有任何吸引力的啊，为什么会被这么关照？

2014 年 7 月 19 日

回复了 thekll 创建的主题 › Linux › linux8080 端口被攻击，这是怎么做到的？

@wzxjohn

解析的数据包中含BitTorrent.protocol，这种攻击如何防范呢？

2014 年 7 月 19 日

回复了 thekll 创建的主题 › Linux › linux8080 端口被攻击，这是怎么做到的？

@wzxjohn

tcpdump显示大量不同的源ip，如果这些ip是随机伪造的，应该不可能完成三次握手，为什么通过netstat查看状态有大量ESTABLISHED？
我理解的伪造源ip的攻击主要用于SYN Flood，所以不清楚我目前遇到的属于哪种。

以下是tcpdump加参数-nnX的输出结果：

01:55:04.500822 IP 180.111.189.20.8707 > 172.16.201.201.8080: S 598833600:598833600(0) win 1480
0x0000: 4500 0028 ed6a 0000 fe06 e806 b46f bd14 E..(.j.......o..
0x0010: ac10 c9c9 2203 1f90 23b1 79c0 0000 0000 ...."...#.y.....
0x0020: 5002 05c8 e3b7 0000 0000 0000 0000 P.............
01:55:04.500839 IP 180.111.189.20.8707 > 172.16.201.201.8080: S 598833600:598833600(0) win 1480
0x0000: 4500 0028 eaaf 0000 fe06 eac1 b46f bd14 E..(.........o..
0x0010: ac10 c9c9 2203 1f90 23b1 79c0 0000 0000 ...."...#.y.....
0x0020: 5002 05c8 e3b7 0000 0000 0000 0000 P.............
01:55:04.511716 IP 39.65.237.157.10156 > 172.16.201.201.8080: S 1194565532:1194565532(0) win 1480
0x0000: 4500 0028 e880 0000 fe06 4996 2741 ed9d E..(......I.'A..
0x0010: ac10 c9c9 27ac 1f90 4733 9f9c 0000 0000 ....'...G3......
0x0020: 5002 05c8 f155 0000 0000 0000 0000 P....U........
01:55:04.522350 IP 119.115.113.83.8002 > 172.16.201.201.8080: R 1449166068:1449166068(0) ack 1 win 0
0x0000: 4500 0028 2e47 0000 3406 f9e8 7773 7153 E..(.G..4...wsqS
0x0010: ac10 c9c9 1f42 1f90 5660 84f4 0000 0001 .....B..V`......
0x0020: 5014 0000 3708 0000 0000 0000 0000 P...7.........
01:55:04.546348 IP 27.38.53.206.19385 > 172.16.201.201.8080: S 3372241407:3372241407(0) win 1480
0x0000: 4500 0028 ed04 0000 fe06 08fd 1b26 35ce E..(.........&5.
0x0010: ac10 c9c9 4bb9 1f90 c900 51ff 0000 0000 ....K.....Q.....
0x0020: 5002 05c8 5d03 0000 0000 0000 0000 P...].........
01:55:04.548370 IP 218.59.187.45.30950 > 172.16.201.201.8080: R 2916263863:2916263863(0) ack 1 win 0
0x0000: 4500 0028 68ca 0000 2e06 18c3 da3b bb2d E..(h........;.-
0x0010: ac10 c9c9 78e6 1f90 add2 a7b7 0000 0001 ....x...........
0x0020: 5014 0000 b68b 0000 0000 0000 0000 P.............
01:55:04.569272 IP 220.249.184.116.9025 > 172.16.201.201.8080: S 3974400993:3974400993(0) win 1480
0x0000: 4500 0028 ee98 0000 fe06 c2ee dcf9 b874 E..(...........t
0x0010: ac10 c9c9 2341 1f90 ece4 8be1 0000 0000 ....#A..........
0x0020: 5002 05c8 e33a 0000 0000 0000 0000 P....:...…..

sar命令查看每秒大概100多次攻击，暂时通过iptable封掉了一些ip段，只是缓解了一些服务器的压力，还是没法根本上解决问题。

2014 年 7 月 13 日

回复了 sun1534 创建的主题 › 程序员 › 程序员心中大概都藏着创业梦，那问题就来了。

如果真是抱着这种想法，乘早转行。
互联网的精髓是创新，不是营销。

2014 年 7 月 13 日

回复了 sun1534 创建的主题 › 程序员 › 程序员心中大概都藏着创业梦，那问题就来了。

@sun1534
你确定你明白@vigoss的意思？

2014 年 7 月 11 日

回复了 thekll 创建的主题 › 问与答 › windows azure 下部署 centos，遇到 prelink 异常

@Livid
是不是一周以前的帖子再回复也不会再提前了？
这个提问本来也是我一直在自问自答，不过感觉那个坑有必要让试用微软云的人知道一下，所以把结果贴出来。但是回帖后在前面是看不到，印象中v2ex回帖不是会自动前置么？难道还有其他规则？

2014 年 7 月 11 日

回复了 thekll 创建的主题 › 问与答 › windows azure 下部署 centos，遇到 prelink 异常

世纪互联已确认此问题是centos虚拟机导致的，已升级虚拟机库。建议重新安装虚拟机。
提醒大家，删除、新建虚拟机也会产生存储交易，免费试用订阅的存储交易月限额只有500，这样折腾几次就没了，服务也会被禁止，只能等下个月度再开启了。
这算不算坑？

2014 年 7 月 8 日

回复了 esplendo 创建的主题 › 推广 › 喜获融资 5000 万美元，UCloud 云计算送书啦！ [第一波]

[email protected]
没看懂规则

2014 年 7 月 5 日

回复了 thekll 创建的主题 › 问与答 › windows azure 下部署 centos，遇到 prelink 异常

@serenader
也在用国内版的windows azure吗？能不能测试一下新建一个虚拟机，看会不会出现同样的问题，我用两个帐号测试都会出现这个问题。而5月份创建的centos虚拟机就没有问题，比较发现之前创建的虚拟机和新建的，crond等软件包版本更新了，prelink、PAM等概念了解一些，但是不清楚异常原因。
prelink日志文件只说返回139错误码。

2014 年 6 月 24 日

回复了 thekll 创建的主题 › Linux › 如何用 iptables 实现只允许内网以及外网指定 ip 段的主机访问服务器某个端口？

@jasontse

基本就是按照这种方式先临时处理的，有效。
发现iptables规则是按顺序匹配的，规则顺序一定不能写错。
其他复杂一点的规则不敢写。

2014 年 6 月 21 日

回复了 smileawei 创建的主题 › 问与答 › 国内的 DNS 端口也是在被污染的状态吗

同在Azure的DNS，未出现污染。

2014 年 6 月 21 日

回复了 thekll 创建的主题 › iPhone › Cydia 和 FB 一样也无视 iOS 系统代理设置么

@snachx
我是奇怪Cydia为什么无视系统代理，难道它也使用了SPDY？

FB只是被域名污染，使用不受污染的DNS就可以正常访问；twitter我目前的解决办法是在修改hosts文件，解析api.twitter.com到自己的转发服务器。这应该也是那些只通过设置特殊DNS即可实现翻墙的原理吧

2014 年 6 月 21 日

回复了 thekll 创建的主题 › iPhone › Cydia 和 FB 一样也无视 iOS 系统代理设置么

Cydia首页的FB和Twitter在已设置PAC代理的情况下仍无法打开，浏览器下就可以。

1 ... 2 3 4 5 6 7 8 9 10 11 ... 13

❮

❯