myeclipse 2013 deploy path 修改

文件路径:./.settings/org.eclipse.wst.common.component:

<project-modules id=”moduleCoreId” project-version=”1.5.0″>
<wb-module deploy-name=”web”>
<wb-resource deploy-path=”/” source-path=”/WebRoot” tag=”defaultRootSource”/>
<wb-resource deploy-path=”/WEB-INF/classes” source-path=”/src”/>
<property name=”context-root” value=”web”/>
<property name=”java-output-path” value=”/web/WebRoot/WEB-INF/classes”/>
</wb-module>
</project-modules>

linux sync 木马 .Iptables .Iptablex

现象:linux 主机对外发出高达上G的流量定向攻击互联上的某台主机(1001端口),结果就是,目标挂掉了,你也被云主机封号了(这种攻击会导致云架构共享的网络瘫痪,所有用户无法正常服务,属于致命问题)。

对于站长来说封号就是灭顶之灾,如果数据无法备份,就更悲剧了。

目前木马攻击的注入方式未知,希望有高人研究,根据本人主机的情况,猜测ssh扫描,bug注入的可能性比较高。

防范:

1. 修改ssh默认端口

2. 修改ssh的访问源ip(类似 AWS EC2 的security groups 功能)

同样问题的站长:

http://bbs.chinaunix.net/thread-4118890-1-1.html

http://www.xujiansheng.cn/2014/01/linux-viruses-iptablex-iptables/

可疑样本文件:Iptablex.zip

希望有高人能看到,能发现后门,造福广大站长

经这两天学习和热心网友乌云微博管理员的帮助,初步定位是struct 漏洞:

类似:http://www.beardnote.com/?p=829

 

解决struts2最新s2-016代码执行漏洞–CVE-2013-2251

今天接到外界报告struts2框架存在任意命令执行漏洞,可直接执行任意系统命令。 详细见官方说明:http://struts.apache.org/release/2.3.x/docs/s2-016.html

漏洞版本:
Apache Struts 2.0.0 – Apache Struts 2.3.15

漏洞描述:
CVE-2013-225. Struts2 是第二代基于Model-View-Controller (MVC)模型的java企业级web应用框架。它是WebWork和Struts社区合并后的产物

Apache Struts2的action:、redirect:和redirectAction:前缀参数在实现其功能的过程中使用了Ognl表达式,并将用户通过URL提交的内容拼接入Ognl表达式中,从而造成攻击者可以通过构造恶意URL来执行任意Java代码,进而可执行任意命令

redirect:和redirectAction:此两项前缀为Struts默认开启功能,目前Struts 2.3.15.1以下版本均存在此漏洞

目前Apache Struts2已经在2.3.15.1中修补了这一漏洞。强烈建议Apache Struts2用户检查您是否受此问题影响,并尽快升级到最新版本

< 参考 1. http://struts.apache.org/release/2.3.x/docs/s2-016.html >

测试方法:
@Sebug.net dis 本站提供程序(方法)可能带有攻击性,仅供安全研究与教学之用,风险自负!

由于Apache Struts2 在最新修补版本2.3.15.1中已经禁用了重定向参数,因此只要重定向功能仍然有效,则说明受此漏洞影响:

http://host/struts2-showcase/employee/save.action?redirect:http://www.yahoo.com/

如果页面重定向到www.yahoo.com,则表明当前系统受此漏洞影响。

验证表达式解析和命令执行:

http://host/struts2-showcase/employee/save.action?redirect:%25{3*4}

http://host/struts2-showcase/employee/save.action?redirect:%25{(new+java.lang.ProcessBuilder(new+java.lang.String[]{'command','goes','here'})).start()}`
Sebug安全建议:

厂商状态:
厂商已经发布Apache Struts 2.3.15.1以修复此安全漏洞,建议Struts用户及时升级到最新版本。

厂商安全公告:S2-01. 链接:http://struts.apache.org/release/2.3.x/docs/s2-016.html

软件升级页面:http://struts.apache.org/download.cgi#struts23151

目前存在漏洞的公司
乌云上,已经发布了快60个struts的这个漏洞问题,包括腾讯,百度,网易,京东等国内各大互联网公司。(http://www.wooyun.org/bugs/new_submit/) 

解决办法:
升级到Struts 2.3.15.1(强烈建议)
使用ServletFilter来过滤有问题的参数(临时替换方案)
 
参考资料:
http://sebug.net/appdir/Apache%20Struts

这次struts爆出来的漏洞,一大片的网站受的影响,影响最严重的就是电商了. 对于struts的漏洞,曾经也写过struts2代码执行漏洞,struts2自从使用OGNL表达式的方式后,经常就会报出一些可怕的漏洞出来,建议那些还是struts的童鞋们,学习一些其他的框架吧!比如,spring mvc,简单,好用,高效! 这里有篇对struts漏洞分析很透彻的文章,推荐学习学习. http://www.inbreak.net/archives/507

问题解决参考:
http://www.geek521.com/?p=3278

EC2 Instance 重启后ssh无法登陆的问题

创建instance后,第一次都能正常运行,但是重启后大概率(大于80%)创建的instance就ssh连不上了。刚开始以为自己的业务导致服务器僵死,后来发现80端口都是正常的,说明服务器没有问题,只是ssh无法连接。
于是通过其他手段登录到服务器,想手动拉起sshd,系统提示:

Failed to start SSH server :
Starting sshd: /etc/ssh/sshd_config line 157: Bad yes/without-password/forced-commands-only/no argument: without-passwordUseDNS
[FAILED]

根据提示,发现sshd_config的配置中有非法的内容(没有换行),于是手动,修改后sshd正常启动。
进一步定位分析,发现原来 EC2的 instance 的/etc/rc.d/rc.local 中有脚本控制每次开机后向sshd_config 末尾写入:

UseDNS no
PermitRootLogin without-password

当这2行缺少合法的换行时,sshd就开机无法启动了。
解决方法:
1)屏蔽rc.local脚本的相关语句
2)修改sshd_config的属性为只读

EC2 snapshot 默认创建instance无法启动问题

用创建的snapshot创建的 instance 一直显示 initialization,查看log:
EXT3-fs: sda1: couldn’t mount because of unsupported optional features (240).
EXT2-fs: sda1: couldn’t mount because of unsupported optional features (240).
Kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block(8,1)
初步分析,创建都是default 的,恢复也是default的,应该没有问题才对,但看日志,是文件系统不支持,说明内核版本有问题了。于是在恢复时手动选择AKI:
aki-68c06a69 aki-config 注意:此AKI要根据自己的系统以及版本选择合适的,我选择的只针对我自己的系统。
重新选择后,创建多个实例,都启动ok

MTK编译环境问题make: *** [mmi_feature_check] Error 1

今天遇到的问题:同样都是win7 系统,同样的安装路径,编译工具和代码,在新的机器上就是编译不了,提示如下:

make: *** [mmi_feature_check] Error 1

熟悉mtk的同学一看就知道是路径问题.

于是在相关perl脚本中分段加打印,终于定位出原来是新的机器不支持命令行的空格缩写格式,不支持如  c:Progra~1 这样的写法.

具体原因待日后有时间再进一步定位.暂时通过修改工具路径规避此问题.

mysql table crash 自动修复脚本

已验证:eg1:

#!/bin/sh

cd /var/lib/mysql

echo “$(date) start mysql_deamon running…”
sleep 180

while [ 1 ]
do
echo “$(date) mysql_deamon running…”
sleep 30

for i in `cat mysqld.log |grep crash|awk -F “‘” ‘{print $2}’|sort -u|sed -e ‘1d’ `;
do
if [ “$i” != “./xxx/xxx” ]; then
echo ‘not find xxx crash’
else
echo ‘find xxx crash’
echo ‘repair xxx’
mysqlcheck -uxxx -pxxx xxx xxx -r
fi

echo ‘clear the err log’
> mysqld.log
done
done

eg1 中红色部分代码其实可以1句搞定,由于本人不善 shell 提取字符操作,只能做固定判断了

未验证 eg2:

#!/bin/bash

#This script edit by badboy connect leezhenhua17@163.com
#This script used by repair tables
mysql_host=localhost
mysql_user=root
mysql_pass=123456   #密码如果带特殊字符如分号可以这么写  root;2010就可以了
database=test

tables=$(mysql -h$mysql_host -u$mysql_user -p$mysql_pass $database -A -Bse “show tables”)
for arg in $tables
do
check_status=$(mysql -h$mysql_host -u$mysql_user -p$mysql_pass $database -A -Bse “check table $arg” | awk ‘{ print $4 }’)
if [ “$check_status” = “OK” ]
then
echo “$arg is ok”
else
echo $(mysql -h$mysql_host -u$mysql_user -p$mysql_pass $database -A -Bse “repair table $arg”)

fi
echo $(mysql -h$mysql_host -u$mysql_user -p$mysql_pass $database -A -Bse “optimize table $arg”)
done

未验证 eg3:

#!/bin/bash
#author:itnihao
#mail:itnihao@qq.com
#date 2013-02-18
#version v1.0
#function:repair mysql table

User=root
Password=123456
Host=192.168.1.10
Database=$(mysql -u${User} -p${Password} -h${Host} -e ‘show databases’|grep -v ‘Database’)
for DBname in ${Database}
do
table=$(mysql -u${User} -p${Password} -h${Host} ${DBname} -e ‘show tables’|grep -v tables_in_mysql)
for tableName in ${table}
do
mysql -u${User} -p${Password} -h${Host} ${DBname} -e “check table ${tableName}” [ “$?” != 0 ] &&mysql -u${User} -p${Password} -h${Host} ${DBname} -e “repair table ${tableName}”
done
done

‘xxx’is marked as crashed and should be repaired

1、从网上查了下有的说是频繁查询和更表造成的索引错误。

2.还有说法为是MYSQL数据库因为某种原因而受到了损坏,如:数据库服务器突发性的断电、在提在数据库表提供服务时对表的原文件进行某种操作都 有可能导致MYSQL数据库表被损坏而无法读取数据。总之就是因为某些不可测的问题造成表的损坏。

修复:

mysql> REPAIR TABLE int_dev_gps;

服务器shell脚本中用wget/curl模拟客户端调用api接口

目前的生产环境使用的vps的shell监护脚本中,发现有很大的概率reboot命令会僵死,但是web页面面板功能正常。正好网站提供了api接口,所以可以通过api完成可靠的系统复位。

我们可以在shell中用wget 和curl 模拟客户端,来发送指令的url.

curl 常用的 开关:

-o 忽略下载

-s 忽略返回

其他的见 –help

样例:

curl -o /dev/null -s “http://xxxx.com”

wordpress手动升级后由于文件目录权限问题导致无法上传附件

手动升级wordpress 后,发现无法上传附件,于是仔细分析新文件夹和老备份文件的差异,发现是由于cp时改变了upload 文件夹属性导致。wordpress upload文件夹的 归属是 apache:apache  所以在手动更新文件时,要使用 -Rp 参数,保持原文件的属性不变。

mysql java 守护脚本

参考网上资料,为生产环境的mysql 和java 进程增加守护进程,负责进程退出时,自动拉起

#!/bin/sh
##设置mysql进程和jira进程的监控进程名和进程数目;
mysql_process_check=`lsof -i:3306|awk ‘{ print $1 }’|sed -n 2p`
mysql_check=`lsof -i:3306 |wc -l`
jira_process_check=`lsof -i:8080|awk ‘{ print $1 }’|sed -n 2p`
jira_check=`lsof -i:8080 |wc -l`

##设置java运行环境,单独在shell脚本提示符号下面运行是可以不用设置java运行环境(因为加载用户shell脚本环境时已经加载
##了);但是在cron进程下面时则需要设置java运行环境。

#export JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun
#export PATH=$PATH:/usr/lib/jvm/java-1.5.0-sun/bin

while [ 1 ]
do
echo “$(date) jboss_deamon running…”
##先查看3306端口是否有运行进程(注意,这个时候运行在3306脚本上面的不一定是mysql进程mysqld!不过我们第一步是判断
##3306端口上面是否运行了进程)
while [ $mysql_check -eq 0 ]
do
echo “port:3306 have no process running”
sleep 2
#/usr/bin/mysqld_safe -umysql &
service mysql start
##如果8080端口上有进程运行,不管它是jira服务进程java还是其它进程,则一律把8080端口上运行的进程强行终止掉;
##因为jira服务的运行依赖于mysql的正常运行后才运行;如果jira服务进程正常存在系统中,但是mysql进程已经出问题了,
##那么这个时候不管8080端口上运行的是jira服务进程java还是其它进程,一律强行终止掉。
if [ $jira_check -gt 0 ]; then
pkill -9 $jira_process_check
fi
sleep 20
mysql_check=`lsof -i:3306 |wc -l`
done

##这一次将判断3306端口上面运行的是否为mysql进程mysqld,如果不是则强行终止3306上面的非mysql进程,同时终止完后运行##mysql进程
mysql_process_check=`lsof -i:3306|awk ‘{ print $1 }’|sed -n 2p`
if [ $mysql_process_check != mysqld ]; then
echo ‘mysql_process not run in port 3306,so I will kill process which run in port 3306.’
pkill -9 $mysql_process_check
mysql_check=`lsof -i:3306 |wc -l`
# echo $mysql_check
while [ $mysql_check -eq 0 ]
do
sleep 2
#/usr/bin/mysqld_safe -umysql &
service mysql start
##确认8080端口上面是否运行了进程,如果运行了进程则强行终止掉8080端口上面运行的进程,不管是jira进程还是其它进程。
if [ $jira_check -gt 0 ]; then
pkill -9 $jira_process_check
fi
sleep 20
mysql_check=`lsof -i:3306 |wc -l`
done
echo ‘mysql_process are running in port 3306.’
else echo ‘mysql_process are running in port 3306.’
fi

##确认8080端口上面是否运行了进程(不管8080端口上面运行的是java进程还是其它进程)jira_check=`lsof -i:8080 |wc -l`
while [ $jira_check -eq 0 ]
do
echo “port:8080 have no process running”
sleep 2
#/usr/local/jira/bin/startup.sh
nohup /data/web/jboss-as-7.1.1.Final/bin/standalone.sh >/dev/null 2>&1 &
sleep 30
jira_check=`lsof -i:8080 |wc -l`
done

##检查8080端口上面是否运行着jira服务进程java,如果没有则先强行终止8080端口上面运行的进程;然后在启动jira服务
jira_process_check=`lsof -i:8080|awk ‘{ print $1 }’|sed -n 2p`
if [[ $jira_process_check != java ]]; then
echo ‘jira_process not run in port 8080,so I will kill process which run in port 8080.’
pkill -9 $jira_process_check
jira_check=`lsof -i:8080 |wc -l`
# echo $jira_check
while [ $jira_check -eq 0 ]
do
sleep 2
#/usr/local/jira/bin/startup.sh
/data/web/jboss-as-7.1.1.Final/bin/standalone.sh >/dev/null 2>&1 &
sleep 30
jira_check=`lsof -i:8080 |wc -l`
done
echo ‘jira_process are running in port 8080.’
else echo ‘jira_process are running in port 8080.’
fi
sleep 60
done

使用postfix 实现注册用户邮件通知

之前使用的是企业邮箱,由于有反垃圾邮件和每日发送次数限制,当用户量上来的时候,就苦逼了,后台调用失败,用户注册不了。

所以把邮件服务器换成了postfix。这样就可以摆脱以上的限制,而且postfix也很强大。

目前只实现简单的smtp 功能,实现发送注册邮件功能。

1. 增加DNS解析

为什么需要dns解析?因为显示的发送邮箱是可以软件填写的,所以唯一的好处就是在用代码调用的时候能保证接口稳定(ip主机迁移,只要修改dns解析就可以)。

2. 如果是本机发送,基本默认配置就可以搞定了。如果要支持remote,就需要简单的设置

postfix-config

对应 /etc/postfix/main.cf 中的mynetworks 参数

全部修改参数如下:

myhostname = mail.xxx.com
mydomain = xxx.com
mynetworks = 127.0.0.0/8 xxx.xxx.xxx.xxx
inet_interfaces = all

如果要进行详细的客户端权限管理和虚拟用户帐户管理,可以参见这篇文章:

http://www.centoscn.com/CentosServer/lighttpd/2013/0730/806.html

配置完成后,记得一定要重启

3. telnet 测试。

MAIL FROM: xxx@xxx.com
RCPT TO: xxx@xxx.com
DATA
From: xxx@xxx.com
To: xxx@xxx.com
Subject: test message
test mail
.

注意:Telnet时 ,请用外网ip或者域名否则可能出现:

Postfix 554 5.7.1 Relay Access Denied  的错误

ok,可以替换以前代码中的企业邮箱的参数了。

jboss 的时区问题导致timestamp 错误

最近由于更换云主机,环境进行了搬迁,发现以前正常的设备数据都和实际时间段差了时区值。同时发现jboss的日志时间是UTC时间,所以推断是jboss时间错误导致时间戳错误,数据错乱。

修改jboss 时区:

修改 xxx/bin/xxx.cnf xxx根据服务器类型有变化

在 启动配置中添加jvm 参数,指定时区和jboss 的语言:

export JAVA_OPTS=”-Duser.timezone=Asia/Shanghai -Dfile.encoding=utf-8 -Duser.language=zh -Duser.region=CN”