ShangDu

PHP存在哈希表多碰撞拒绝服务漏洞，导致服务器无法提供正常服务解决方法

ZeLL — Mon, 09 Jan 2012 02:34:05 +0000

由于php某些版本存在哈希表多碰撞拒绝服务漏洞，导致服务器CPU资源占用过高，服务器无法提供正常服务。目前受影响及版本有：
PHP <= 5.3.8

解决办法:

给php版本打补丁.

补丁下载地址:https://github.com/laruence/laru … -5.2-max-input-vars
(请选择对应php版本的补丁)# tar -jxf php-5.2.11.tar.bz2
# patch -d php-5.2.11 -p1 < php-5.2.11-max-input-vars.patch
# cd php-5.2.11
# ./configure –prefix=/opt/php \
… …
# make
# make install

密码保护：爸爸日记

ZeLL — Thu, 05 Jan 2012 15:25:23 +0000

2012新年快乐

ZeLL — Sun, 01 Jan 2012 14:32:39 +0000

2012祝大家新年快乐。

学会记录，学会总结，加快成长

ZeLL — Fri, 30 Dec 2011 17:51:56 +0000

学会记录，学会总结，学会成长

shell 脚本批量修改root密码，linux集群管理

ZeLL — Fri, 30 Dec 2011 13:24:12 +0000

passwd有个–stdin 参数能用于在脚本中实现改密

[root@zell root]# echo shangdu.org|passwd –stdin root

Changing password for user root.

passwd: all authentication tokens updated successfully.

shell 脚本修改root密码

对统定期修改密码是一个很重要的安全常识，通常，我们修改用户密码都使用 passwd user 这样的命令来修改密码，但是这样会进入交互模式，即使使用脚本也不能很方便的批量修改，除非使用expect 这样的软件来实现，难道修改一下密码还需要单独安装一个软件包吗? 不，我们其实还有其他很多方法可以让我们避开交互的，下面具体写一下具体的实现方式：

第一种：
echo “123456″ | passwd –stdin root

优点：方便快捷
缺点：如果你输入的指令能被别人通过history或者其他方式捕获，那么这样的方式是很不安全的，更重要的是如果密码同时含有单引号和双引号，那么则无法通过这种方法修改。

说明：
批量修改linux密码 passwd –stdin user 从标准输入中读取密码，所以用户可以在脚本中使用如 echo NewPasswd | passwd –stdin username 这种方式来批量更改密码但在其它的一些发行版（如Debian/Suse）所提供的passwd并不支持–stdin这个参数

第二种：
a. 首先将用户名密码一起写入一个临时文件.
cat chpass.txt
root:123456
zhaohang:123456
b. 使用如下命令对用户口令进行修改：
chpasswd < chpass.txt
c. 可以使用 123456 来登录系统，密码修改完毕.

优点：可以很快速方便的修改多个用户密码
缺点：明文密码写在文件里仍然显得不够安全，但是避免了第一种修改方式不能有特殊字符串密码的情况.

第三种：
a. 用 openssl passwd -1 来生成用户口令，连同用户名一起写入文件.
cat chpass.txt
root:$1$ri2hceVU$WIf.firUBn97JKswK9ExO0
zhaohang:$1$i/Gou7.v$Bh2K6sXmxV6/UCxJz8N7b.
b. 使用如下命令对用户口令进行修改：
chpasswd -e < chpass.txt
c. 可以使用 123456 来登录系统，密码修改完毕.

优点：可以很快速方便的修改多个用户密码
缺点：和上面两种相比大大增强了安全性

附加介绍：
openssl passwd -1 命令可以输出shadow里面的密码，把这个命令生成的秘串更改为你shadow里的密码，那么下次你登录系统就可以用你的生成密码的口令来登录了，使用这个命令，即使口令一样，多次执行生成的密码串也不一样。那个hash值对应的密码是完全随机的基于64位字符编码的28位长，因此要破解它是非常困难的，只要不用那些密码已经公布出来的hash值创建账号，即使这些密码文件被公布也还是比较安全的。使用旧的unix哈希可以去掉 -1 参数。

[root@WEB01 ~]# openssl passwd -1

Password: 123456
Verifying – Password: 123456
$1$ri2hceVU$WIf.firUBn97JKswK9ExO0

也可以直接使用如下命令来直接生成：
[root@WEB01 ~]# openssl passwd -1 123456

[root@WEB01 ~]# openssl passwd -1 -salt “yoctor” 123456

上面命令中的 salt 自己随便输入些东西
因为设置密码的时候密码密文是MD5加密的，在产生哈希值的时候系统回在密文中加如盐从而使密文无法反向破译。
passwd加密的时候系统加的salt是时间

一个小脚本
#!/usr/bin/bash
echo “123456″ | passwd –stdin root

疯狂的成长

ZeLL — Tue, 27 Dec 2011 02:57:16 +0000

疯狂的成长

努力工作

ZeLL — Fri, 18 Nov 2011 16:41:14 +0000

努力工作

3G下载站

ZeLL — Sun, 23 Jan 2011 13:12:14 +0000

http://www.3gxz.com/

老牌手机下载站，域名已经解封，希望可以尽快收录

3G下载网站正在制作中。。
网站与2007年建站，2009年被封，本站2011年解封，具体封的原因老用户应该都很了解。
杯具已经结束。迎接2011年。
站长：3G下载大大

iphone如何自 iPhone OS 4.1 恢复成 iPhone OS 3.1.3

ZeLL — Tue, 02 Nov 2010 03:01:44 +0000

iOS 4 在iPhone 3G 效能不佳一文当中的影片显示了iPhone 3G iOS 4 的重拖情形，有些人的iPhone 3G iOS 4 使用经验的确不是很愉快，变慢、耗电或弄乱了一些资料，以我个人的经验而言，iPhone 3G 部分动作变慢了(但相机和设定的反应比影片中快)，耗电的变化未察觉(电池一直都不是很有力)，iCal 的资料被弄乱了一些，所幸手动调整回来后没再发生，因此仍继续使用iOS4。

若想将iPhone 3G downgrade (降级、降阶) 回iPhone OS 3.1.3，则需进行下列步骤。

*行前提醒：
由于folder 等新增功能，iOS 4 的iPhone 资料(简讯及app 纪录等) 备份无法restore 至iPhone OS 3.1.3，因此使用iOS 4 愈久，愈不适合downgrade。 UPDATE: 新版本的iTunes 可能导致Restore 时无法选择过去iPhone OS 3.1.3 时进行的备份，仅能回复成新的iPhone
iPhone 3GS 无法透过此法downgrade，请考虑找出重拖的问题并解决之，取代冲动downgrade 的举动
Windows 状况较复杂，不一定适用本方法
iPhone 3G 回复 iPhone OS 3.1.3 准备工作：
取得 iPhone OS 3.1.3
取得 RecBoot (Mac app，目前版本为 1.0.2)
取得 iPhone OS 3.1.3 ipsw
若曾经自旧版本升级至iPhone OS 3.1.3，则当时透过iTunes 下载的ipsw 放在~/Library/iTunes/iPhone Software/，若无，请由此下载。

进入iPhone DFU (Device Firmware Upgrade) 模式
接上 iPod / iPhone 连接线
开启 iTunes
关机
同时按住 lock 键与 home 键不放
10 秒后放开lock 键，确实保持home 键按住不放
10 秒后iTunes 跳出讯息，表示巳进入recovery mode，按OK
在iTunes 里，按住option 同时点击restore 按钮
此时跳出视窗，请指定iPhone OS 3.1.3 ipsw 所在位置，按下OK 开始restore 程序
用 RecBoot 解决 error 1015 状况
Restore 程序跑完之后，iTunes 将显示error 1015 讯息，立即执行RecBoot (1.0.2 版请执行RecBoot Exit Only.app)，按下Exit Recovery Mode 按钮，iPhone 重新开机，完成OS restore，接下来请进行iPhone资料(简讯及app 纪录等) 备份的retore。

如同开头的行前提醒，iTunes 仅允许用户选择升级iOS 4 以前做的备份，因此最新的备份会是升级iOS 4 时的那次，可能与downgrade 前的资料有所差距。

*提醒：
自iOS 4 回复成iPhone OS 3.1.3 的步骤颇复杂，而且restore 整个iPhone 的data (音乐、app 等) 非常耗时，且资料会回复前升级前的状态，因此建议若非逼不得巳，尽量不要downgrade。

nginx中upstream配置方式

ZeLL — Mon, 18 Oct 2010 01:51:13 +0000

1、轮询（默认）

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

2、weight
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
例如：
upstream bakend {
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
}

2、ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
例如：
upstream bakend {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}

3、fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
upstream backend {
server server1;
server server2;
fair;
}

4、url_hash（第三方）

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

例：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法

upstream backend {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}

tips:

upstream bakend{#定义负载均衡设备的Ip及设备状态
ip_hash;
server 127.0.0.1:9090 down;
server 127.0.0.1:8080 weight=2;
server 127.0.0.1:6060;
server 127.0.0.1:7070 backup;
}
在需要使用负载均衡的server中增加
proxy_pass http://bakend/;

每个设备的状态设置为:
1.down 表示单前的server暂时不参与负载
2.weight 默认为1.weight越大，负载的权重就越大。
3.max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误
4.fail_timeout:max_fails次失败后，暂停的时间。
5.backup：其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

nginx支持同时设置多组的负载均衡，用来给不用的server来使用。

client_body_in_file_only 设置为On 可以讲client post过来的数据记录到文件中用来做debug
client_body_temp_path 设置记录文件的目录可以设置最多3层目录

location 对URL进行匹配.可以进行重定向或者进行新的代理负载均衡