Loading...

谁亏了1000元?

Filed under: 生活工作 — 江东 @ 2012-05-21 14:55:31 才(18)条评论

来自神奇的网易评论:http://comment.news.163.com/news_shehui7_bbs/8211IEJT00011229.html
很有趣的一个故事!
  这是炎热小镇慵懒的一天。太阳高挂,街道无人,每个人都债台高筑,靠信用度日。
  这时,从外地来了一位有钱的旅客,他进了一家旅馆,拿出一张1000元钞票放在柜台,说 想先看看房间,挑一间合适的过夜。
  就在此人上楼的时候,店主抓了这张1000元钞,跑 到隔壁屠户那里支付了他欠的肉钱。
  屠夫有了1000元,横过马路付清 了猪农的猪本钱。
  猪农拿了1000元,出去付了他欠的饲料款。
  那个卖饲料的老兄,拿到1000元赶忙去付清他召妓的钱(经济不景气,当地的服务业也不得不提供信用服务)。
  有了1000元 ,这名妓 女冲到旅馆付了她所欠的房钱。
  旅馆店主忙把这1000元放到柜台上,以免旅客下楼时起疑。
  此时那人正下楼来,拿起1000元, 声称没一间满意的,他把钱收进口袋,走了……这一天,没有人生产了什么东西,也没有人得到什么东西,可这几个人的债务都清了,大家很开心。
  考考大家的智商,看你是否适合做BOSS。请问这个故事的漏洞在哪里?

php如何判断IP为有效IP地址

Filed under: PHP,网站技术 — 江东 @ 2012-04-18 21:03:20 才(6)条评论

多数人看到这篇日志,第一印象肯定是以为是要讲如何通过正则表达式来判断。

非也,在php5.2.0之后,有专门的函数来做这个判断了。

判断是否是合法IP
if(filter_var($ip, FILTER_VALIDATE_IP)) {
// it’s valid
}
else {
// it’s not valid
}

判断是否是合法的IPv4 IP地址
if(filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_IPV4)) {
// it’s valid
}
else {
// it’s not valid
}

判断是否是合法的公共IPv4地址,192.168.1.1这类的私有IP地址将会排除在外
if(filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_IPV4 | FILTER_FLAG_NO_PRIV_RANGE)) {
// it’s valid
}
else {
// it’s not valid
}

判断是否是合法的IPv6地址
if(filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_RES_RANGE)) {
// it’s valid
}
else {
// it’s not valid
}

判断是否是public IPv4 IP或者是合法的Public IPv6 IP地址
if(filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
// it’s valid
}
else {
// it’s not valid
}

本文来源:http://www.electrictoolbox.com/php-validate-ip-address-filter-var/

共享主机被为啥难以定位被ddos的网站

Filed under: 网站技术 — 江东 @ 2012-04-03 19:30:30 才(7)条评论

最近,有一个用户被ddos,经常导致同IP的其他用户遭殃。

于是有人就说了,你技术太不过关了,不能排查么?不能看日志么?不能根据流量来看么?

好吧,我来通俗的讲解一下ddos为啥难以排查(比喻不是很恰当,懒得去想更恰当的比喻了)。

超市就是一个服务器,超市里面的东西就是用户的网站, 超市里面有暴利的灰色行业的物品,我们暂且假设是成人用品。

正常的时候,外面的人来超市买东西,是很容易的。

由于其他超市也卖这种暴利的成人用品,竞争对手觉得本超市卖便宜了,或者干脆不希望这个超市的成人用品能卖出去,于是就雇佣了一大帮人(肉鸡),去这个超市来逛逛。这些人的衣着打扮和普通购物的一模一样,行为也一样。

于是超市入口的走廊都被堵死了。

保安怎么办?报警?大家都是来买东西的,怎么报警?增大超市门?你增大的速度有人数增加的速度快么?当然,还是有办法的,那就是真的报警,网站被DDoS的时候报警,这个时候警察会抓住一大批人(肉鸡),问是谁派他们来的,找到后面的肉鸡指挥者,从而将发动ddos的人绳之于法,但是你认为我朝警察会管这些么?

排除是什么原因导致超市人流量多,拥堵,你问这些人来干嘛,这些人要么不会告诉你,要么告诉你他是来买东西的,多部分人发现超市走道堵死了,就走了,下一批又来了,而下一批你也无法知道谁是真正买东西的,谁是假的(肉鸡)。

排除产品问题(找哪个网站导致ddos)?发现哪个产品前的人突然增加,比如成人用品?就把成人用品下架?

可是问题是,人太多,都堵在了门口,根本还没有走到产品那边,直接通道就堵死了。

怎么解决,增加询问机制,问来的人是干嘛的(防火墙,比如我们现在购买的防DDoS的服务),如果人太多,这也是不行。

唯一的办法:关门(拔掉网线)

或者竞争对手主动告知,请下架某产品,否则我们会继续攻击?! (攻击方通知我们关闭某个网站,否则继续攻击)

要么猜测是哪个商品导致(我们猜测是哪个共享用户导致)。

所以,在阅读了上面的内容之后,您还继续责怪服务器技术不到家,连谁被ddos都排查不出来,那我无话可说了?

一言蔽之,ddos的时候,都堵在了水管上,要判断好难的。

今后我们只有努力增加IP,让同IP上的用户更少,这样才能更好的排除。

利用rsync在两台服务器之间定期同步数据

Filed under: 网站技术,虚拟主机 — 江东 @ 2012-04-03 11:27:25 才(4)条评论

首先,在两台服务器A和B同时装上rsync。

centos:yum install rsync -y

debian:apt-get install rsync -y

这里我们假设B是备份服务器,A上所有的改动都同步到B上去.

在A上输入 ssh-keygen。命令(一路回车):

ssh-keygen

输入ssh-keygen将会显示如下结果

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
d7:15:ad:ff:37:99:4b:c8:01:20:b2:8b:1a:2b:2d:1f root@030.homezz.com
The key’s randomart image is:
+–[ RSA 2048]—-+
| . . . .. |
| o . . ..|
| . . .. |
| . . …. |
| . . . S . .. . |
| .+ . . o .|
|ooE o .+|
|.o . .+o|
| . .+|
+—————–+

我们将创建好的公钥上传到B服务器,命令如下

scp /root/.ssh/id_rsa.pub root@B的ip:/root/.ssh/_pub

提示的时候输入密码,该文件即上传到了B服务器。

ssh登陆到B服务器,运行命令 cat /root/.ssh/_pub>>/root/.ssh/authorized_keys

在B服务器中,打开ssh配置文件 vim /etc/ssh/sshd_config,删除 #PubkeyAuthentication yes 这行前面的#

重启sshd: service sshd restart

现在,从A服务器 ssh root@Bip 看看是否可以无密码登陆了?如果上面步骤无误的话,是肯定可以无密码登陆了

 

现在在A服务器上开始运行rsync做一次数据同步

/usr/bin/rsync   -rvuog   /www/*  root@B的ip:/www/

这样就会将A /www/  下的所有文件,同步到B服务器的/www/下,第一次运行时间会很久。如果A上有文件不存在了,你同步的时候也需要B服务器上的文件也同时删除掉,那么参数添加一个 –delete

/usr/bin/rsync   -rvuog    –delete  /www/*  root@B的ip:/www/

第一次同步完毕之后,在A服务器上创建一个cronjob,定期执行同步。

命令为crontab -e,

然后输入

0 */12 * * * /usr/bin/rsync   -rvuog  –delete /www/  root@B的ip:/backup/file.homezz.com/ >/dev/null 2>&1

表示12小时同步一次。

注意,若你数据量过大,不建议同步周期太频繁,否则会导致不可预料的错误。个人觉得12小时或者6小时比较合适

如何恢复误删除的lvm

Filed under: 虚拟主机 — 江东 @ 2012-03-31 17:56:14 只有1条评论

先找到备份日志的位置
vgcfgrestore -l /dev/vps/homezz

然后根据显示的内容找到你最后一次操作的备份文件
如 /etc/lvm/archive/VolGroup00_0000009.vg

运行恢复命令 “vgcfgrestore -f /etc/lvm/archive/VolGroup00_0000009.vg /dev/vps”

运行
lvchange -a y /dev/vps/homezz
最后 /dev/vps/mars
搞定。
当然前提是删除lvm之后,没有任何其他磁盘写入操作

今年的攻击特别多

Filed under: 互联网事 — 江东 @ 2012-03-26 10:27:41 才(10)条评论

到现在为止,今年才过去第一个季度,homezz遇到ddos攻击至少超过了10次。其中有2次是针对homezz本身,其余的8次以上是针对用户。

对于ddos攻击,是没法在程序上做防护的,必须用硬件防火墙。那些说通过跳转或者iptables来抗击DDoS的朋友,只能说您还没有享受到真正的流量DDoS,所以无法理解其威力。

今年homezz的主机机制做了很大的改变,就是为了尽量减少攻击带来的宕机率。

最早,我们以为攻击是针对homezz或者homezz的用户,所以甚至很多朋友还说“东哥太高调了”。实在无法理解一个封闭的主机商怎么去高调,没有到任何论坛发帖宣传的主机商怎么能和高调扯上关系。后来,我们发现,其实并不是针对homezz一家,在我们收到攻击的同时,其他主机商家也收到了攻击,而且比我们受到的攻击还要厉害。

昨日,我在twitter上看到一个美国主机商的账号在感叹越来越多的攻击。

今天,我们又收到美国的几个机房的邮件,说为了抵御越来越多的攻击,他们开始上硬件防火墙了。

于是,我总算是明白了:今年的攻击特别多!

 

homezz加速的原理和优点

Filed under: 互联网事 — 江东 @ 2012-03-09 17:02:00 才(18)条评论

大致描述一下homezz加速原理。

下面这幅图是常规的主机构架。

服务器的ip直接和访客相关

下面这幅图是homezz虚拟主机的构架。服务器只对网站维护人员开放。web前端专门用加速服务器来完成。这也是专业的大型网站的最基本的架构。

下面是一张对应表,比较二者之间的优势劣势

项目 常规主机 Homezz主机
自助改变服务器保持IP不变 ×
自助改变前端IP保持服务器不变 ×
随时改变网站前端机房以适应国内网络线路调整 ×
后端前端IP一样 ×
cpanel操作 简单 较简单
可以host DNS 暂不可以
抗攻击能力 一般 √强
防火墙隔离度 一般 √几乎完全对外隔离
域名解析 可以A记录,可以cname,可以直接NS托管 建议cname,更加自由,也可以A记录
扩展性能(如智能加速) ×

解答几个可能的疑问:

  1. 服务器和加速服务器之间传输数据会不稳定么? 不会的,因为都是机房之间传输,全部是专业的高可靠的线路。且如果您选择的加速服务器和您的服务器是同机房的话,这和在一个服务器上没有两样(因为我们的加速服务器和后台服务器都是在欧美和日本而不是中国);
  2. 加速会不会比直接访问慢。不会,如果您选择的加速服务器合适的话,还会让用户访问更快(多数情况是这样),因为服务器和加速前端之间的网络是非常快的。加速延迟计算不是简单的延迟相加。

我们的主战homezz也是采用如此的技术,前端和后端分离,后端存储在amz云端。因此我们遇到n次ddos攻击,都能快速的切换IP。

顺便提一下,今天homezz官方站点也遭遇到强大的DDoS攻击(这次攻击强大前所未有,每秒12万个包,我们购买的初级防护都无法抵挡)。我个人不明白,为啥会有这么多sb自己花钱购买肉鸡来攻击我们,且自己也没有得到一丝好处?你对homezz的攻击,即使减少了homezz的用户,但是人家也未必就去你那边购买,这么简单的账都不会算!

仙人球如何摆放才能防辐射

Filed under: 电子技术 — 江东 @ 2012-02-26 17:13:06 才(25)条评论

实际上,很多非山寨的电子产品的辐射我们都没有必要太在意,因为这和食品威胁相比,不在同一个数量级。

废话少说,有人长期用电脑,害怕辐射,于是就流行了在电脑显示器前摆放一盆仙人球用来防辐射。可是我要告诉你们,你们这种摆放方式如果能防辐射的话,那么电磁波的理论就需要修改了,光也不会沿直线传播 了,为何,下面来三副图片给解释解释:

(read on …)