删除windows上lpt1.asp伪装木马文件(SHR属性),及一次查杀web木马简记

维护的一台windows 2003服务器,跑iis6,其中一个站点需要同时支持asp与php,还得跟站点web用户赋写入权限(因为该站主要是一asp的CMS,文章内容页是生成静态html的)。正因如此,该站比较容易出问题,数次被挂马。

在与该CMS还有入侵者长期的拉锯战里,该站点做了很多针对性的措施,比如,

  • 删除iis里动态脚本映射,只保留.asp, .php, .shtml,其它的像.net的一大堆(,.cs什么什么的),全部删除
  • 改进cms程序的写入文件功能:禁止写asp, php文件,增强上传功能安全性,等
  • 非动态脚本目录(如文件上传目录等),通过iis设置无执行权限
  • 后来更严苛的设置,除了少数几个有必要的目录,其它目录下的.asp, .php全部重写到一个空文件上。通过rewrite实现

不过后来,还是出过问题。

如这一次,根据被挂马文件的写入时间,找之前一天内被修改过(包括写入)的.asp, .php文件,在查iis日志,里查找马儿文件被请求的记录项,找到马夫的ip,当然ip很可能是动态变化的,不过这次好像是全部从一个ip上还的,这就省功夫了。分析该ip的请求记录,专找对.asp, .php url的请求,尤其是 POST请求(因为webshell大马的处理很复杂,一般都是post传参数),仔细检查这些.asp, .php文件的修改时间,最近被修改过的,一定可疑。修改时间是很久以前,也不能吊心轻心,有可能是长期隐蔽马。

按上面的步骤,清理木马不是太难的事情。但就怕遗漏,一个小小马(通常是一句话或其变种),足以让这些工作白费。

不过这次发现了一个名为 lpt1.asp 的文件,而且是“系统 隐藏 只读”的属性SHR,删除时提示找不到文件,有点奇怪了,看文件名,有点奇怪;使用编辑器打开,也提示文件不存在。担心操作系统被植入了什么进程,这就麻烦了。google得知,lpt1这是dos保留字的文件名,要使用一个咒语般的路径地址,很蛋疼。。。

根据搜索结果,该文件位于 E:\www\site_root\images\lpt1.asp 相应的地址是 \\.\E:\www\site_root\images\lpt1.asp ,即

del \\.\E:\www\site_root\images\lpt1.asp

结果是不行,怀疑是SHR的关系,尝试一阵子,通过这样的形式:

attrib -S -R -H path_to_file.ext

清理掉这几个属性;似乎这几个属性要一次性去除,还不能一个一个的去除;好像不是dos的风格,竟然支持一次多个item的操作。。。。

然后可以删除了,当然,我在删除前做了个备份,毕竟又截获了一只马。

下面是一部分操作的记录,帖出来了

E:\www\site_root\images>del E:\www\site_root\images\lpt1.asp
文件名、目录名或卷标语法不正确。

E:\www\site_root\images>attrib \\.\E:\www\site_root\images\lpt1.asp
A  SHR     \\.\E:\www\site_root\images\lpt1.asp

E:\www\site_root\images>del E:\www\site_root\images\lpt1*
找不到 E:\www\site_root\images\lpt1*

E:\www\site_root\images>del E:\www\site_root\images\lp*

E:\www\site_root\images>attrib \\.\E:\www\site_root\images\lpt1.asp
A  SHR     \\.\E:\www\site_root\images\lpt1.asp

E:\www\site_root\images>attrib \\.\E:\www\site_root\images\lpt1.asp
A  SHR     \\.\E:\www\site_root\images\lpt1.asp

E:\www\site_root\images>attrib -H \\.\E:\www\site_root\images\lpt1.asp
未重设系统文件 - \\.\E:\www\site_root\images\lpt1.asp

E:\www\site_root\images>attrib -S -R -H \\.\E:\www\site_root\images\lpt1.asp

E:\www\site_root\images>attrib -H \\.\E:\www\site_root\images\lpt1.asp

E:\www\site_root\images>attrib \\.\E:\www\site_root\images\lpt1.asp
A          \\.\E:\www\site_root\images\lpt1.asp


E:\www\site_root\images>attrib \\.\E:\www\site_root\images\lpt1.asp
A          \\.\E:\www\site_root\images\lpt1.asp

E:\www\site_root\images>copy \\.\E:\www\site_root\images\lpt1.asp f:\aa.txt
已复制         1 个文件。

E:\www\site_root\images>del \\.\E:\www\site_root\images\lpt1.asp

本文是以前写的一篇手记,处理后以为问题得解,但稍后两天发现仍被入侵,于是次本文状态改成草稿;被入侵的原因是其他地方仍然有木马,处理后本文丢在这里没有动。这么久都没有继续写,大概以后也不会续写,最近整理博客时就直接发出来算了(2016-10-10 16:20)

linux bash下find命令之-exec参数多次使用{}处理匹配到文件

问题:

使用find命令查询旧文件文件,并删除,但又想在删除前看一下文件名,大致监测一下进度。不过在exec参数里直接使用两次{}会报错,google后,找到方法,使用sh "代理"一下,直接上代码:

find . -atime +150 -exec sh -c 'ls -lh {} ; rm {}' \;

注意加粗着色部分及其单引号。

特殊字符比较多,转载时容易出问题,再截张图,对照参考

bash_find_match_multi_use

参考:http://blog.csdn.net/duanlove/article/details/8261677
该文还介绍了其它可选方案。

后记:前面例子,只为演示功能,事实上只要给rm 带上  -v 参数即可,感谢sdfsaf指正,如下

find . -atime +150 -exec rm -v {} \;

java jdk下载-通过海外vps快速下载jdk的方法及/抓包wget

我朝网络真牛x,连接海外很多站点速度都奇慢。印象中以前从java/oracle下载jdk还不算是太慢。今天下载macintosh os x版的jdk,竟然几乎不会动,要10个小时,这还是30M企业版电信光纤吗!找了几个国内的下载站,竟然没有,难道是oracle不让做镜像下载所致?

有个海外vps,就是本站所在的服务器,平时下载海外的东西,如果太慢,通常就使用百度网盘,或vps上下载,做个中转;有时甚至会两个一起用。

但jkd的下载链接不行,下载链接带授权参数的。

想起live http headers,抓包,看看请求里是什么东西,wget模拟请求,理论上只要参数齐就可以的。wgtet一下,发现是三次请求,通过302转向到一个带AuthParm的get参数的地址上,那就直接在vp上wget它,看行不行;如果不行,再带其它参数,反正wget 有随便加http参数的功能。竟然果然是可以下载的,省事,连其它参数都不用加了!

ok,中转下载成功。

vps速度不稳,也要20多分钟的样子,但总比10个小时强得多了,慢慢等吧,还有10M

继续阅读

yum更新遇到依赖错误的处理经验总结

redhat系列linux系统的yum,有时会出现错误的依赖,用linux早期,遇到该类问题简直是束手无策,无奈之下会在yum的“教唆“下使用“--skip-broken”参数,有时确实可以解决问题,但有时的后果,可以把系统玩儿坏,下次启动无法启动,或出现其它莫名其妙的问题。

列一个典型的错误依赖消息如下:

--> 正在处理依赖关系 /usr/sbin/ldconfig,它被软件包 libva1-1.3.1-11.el7.x86_64 需要
--> 正在处理依赖关系 /usr/sbin/ldconfig,它被软件包 libmad0-0.15.1b-4.el7.x86_64 需要
--> 正在处理依赖关系 /usr/sbin/ldconfig,它被软件包 librtmp0-2.3-1.el7.x86_64 需要
--> 正在处理依赖关系 /usr/sbin/ldconfig,它被软件包 libx264_142-0.142-20_20140406.2245.el7.x86_64 需要
--> 正在处理依赖关系 /usr/sbin/ldconfig,它被软件包 libxvidcore4-1.3.2-15.el7.x86_64 需要
.......
错误:软件包:libmad0-0.15.1b-4.el7.x86_64 (@atrpms)
          需要:/usr/sbin/ldconfig
          正在删除: glibc-2.17-55.el7_0.1.i686 (@updates)
              未找到
          更新,由: glibc-2.17-55.el7_0.3.i686 (updates)
              未找到
错误:软件包:librtmp0-2.3-1.el7.x86_64 (@atrpms)
          需要:/usr/sbin/ldconfig
          正在删除: glibc-2.17-55.el7_0.1.i686 (@updates)
              未找到
          更新,由: glibc-2.17-55.el7_0.3.i686 (updates)
              未找到
 您可以尝试添加 --skip-broken 选项来解决该问题
 您可以尝试执行:rpm -Va --nofiles --nodigest

看到了最后两行了吧,通常别听信它,小心!

为了优雅的处理类似错误依赖的问题,要搞先了解一下该问题的原因。通常是在自己手动安装了一些非官方rpm包,或使用了多个yum源所致。尤其是升级安装了新版本的包。例如,在centos里为了安装某些软件而使用fedora里的包升级了系统自带的包。

个人经验如下:

先移除/etc/yum.repo.d/下非系统官方的源,备份到其它目录里,处理好问题后还移回来继续用。

yum list 查看系统都有哪些源的包,除了@base @anaconda @updates 之外的,都要留意一下,按“靠谱”程度从低到高逐渐移除。这里的“靠谱程度”,要凭一些经验的。 如本文前面列出错误依赖的这个例子,本人用了好多个源的包,@epel @atrpms  @nux-dextop @google-chrome 等这几个第三方源,epel是很高质量的,google-chrome 只有chrome浏览器,其它几个就是不太靠谱的,先移除它们。

检查yum list列出的包名,是否用了fedora,或非本机架构的等的包(如x64系统下686的包),yum erase移除它们。卸载包时,注意着,别把重要的系统包卸载了。千万别这样带-y 参数据 yum erase  {包名}  -y,yum erase 卸载某个包时,系统提示会提示都移除哪些包,如果看着不对劲就按 N

最后,你会找到出问题的那个包名,即提示错误依赖的信息
--> 正在处理依赖关系 /usr/sbin/ldconfig,它被软件包 libbluray1-0.4.0-6.el7.x86_64 需要
--> 解决依赖关系完成
错误:软件包:libbluray1-0.4.0-6.el7.x86_64 (@atrpms)
          需要:/usr/sbin/ldconfig
          正在删除: glibc-2.17-55.el7_0.1.x86_64 (@updates)
              未找到
          更新,由: glibc-2.17-55.el7_0.3.x86_64 (updates)
              未找到
 您可以尝试添加 --skip-broken 选项来解决该问题
 您可以尝试执行:rpm -Va --nofiles --nodigest

会类似上面所示,只是少数一两个包,尝试卸载一下看看

[root@fsc ~]# rpm -e libbluray1-0.4.0-6.el7.x86_64
错误:依赖检测失败:
    libbluray.so.1()(64bit) 被 (已安裝) gvfs-1.16.4-7.el7.x86_64 需要
    libbluray.so.1()(64bit) 被 (已安裝) gvfs-fuse-1.16.4-7.el7.x86_64 需要
    libbluray.so.1()(64bit) 被 (已安裝) gvfs-afc-1.16.4-7.el7.x86_64 需要
    libbluray.so.1()(64bit) 被 (已安裝) gvfs-gphoto2-1.16.4-7.el7.x86_64 需要
    libbluray.so.1()(64bit) 被 (已安裝) gvfs-goa-1.16.4-7.el7.x86_64 需要
    libbluray.so.1()(64bit) 被 (已安裝) gvfs-mtp-1.16.4-7.el7.x86_64 需要
    libbluray.so.1()(64bit) 被 (已安裝) gvfs-smb-1.16.4-7.el7.x86_64 需要
    libbluray.so.1()(64bit) 被 (已安裝) gvfs-afp-1.16.4-7.el7.x86_64 需要
    libbluray.so.1()(64bit) 被 (已安裝) gvfs-archive-1.16.4-7.el7.x86_64 需要
    libbluray.so.1()(64bit) 被 (已安裝) libbluray-0.4.0-6.el7.x86_64 需要
    libbluray1 = 0.4.0-6.el7 被 (已安裝) libbluray-0.4.0-6.el7.x86_64 需要

那查查系统里该包是什么版本吧 rpm -q {包名}

上面例子里,该包是atrpms源的包,比centos源里的包新。回忆时当时为了安装smplayer,装了一系列atrpms的包。而印象中,atrpms源有时会升级centos的包,所以就造成了yum update 升级系统时造成错误依赖。到centos镜像里下载这个rpm包,rpm --force  -Uvh {包文件路径}覆盖安装一下,然后再yum更新试试。

如果没有问题,那就好了。再把yum 源的配置文件移回去,重新yum makecache,然后根据刚才卸载的包的记录,把它们安装上;可参考history 命令的记录.

大概就是这样,写得有点乱。

cygwin下一些包名与命令不一致的包的安装(telnet,dig,netstat等)及ping方案

cygwin下有一些命令,按命令名在setup里搜索不到的,每次安装都要google,汇总记录备忘于此。

telnet, 包名 inetutils ,属于 Net 类

dig, 包名 bind-utils ,属于 Net 类

FreeTDS-devel,替代包名 libsybdb-devel (libraries to connect to MS-SQL and Sybas databases development), 用来安装pymssql时会需要freeTDS开发包的sqlfront.h文件(比如pip install pymssql 时报错 sqlfront.h: No such file or directory ),但cygwin中并没有freetds-devel, 这时安装 libsybdb-devel可通过。事实上,在cygwin里libsybdb 是freetds的依赖包,而libsybdb-devel 并没有随之安装,需要编译时自然是找不到头文件了,这在cygwin官方文档的里有提到的: https://cygwin.com/packages/summary/freetds-src.html

可以使用windows版代替的包

win32默认是ansi/gbk编码,默认输出是乱码,可以使用iconv转换一下

ping,nslookup

中文windows环境下ping乱码方案参看本文后

cygwin里没有,或暂时还没找方案的包

netstat, 好像没有这个工具,使用windows的版本吧....

nslookup

windows版工具输出乱码的解决方案

ping,nslookup等工具只能使用windows版的,但是windows默认是本地化ansi编码,在cygwin下显示为乱码。更麻烦的是,因为乱码内容骗死人不偿命,看下图里的ip地址cygwin_ping 看ip地址被煞有其事的显示成什么样子!

解决方案如下:

新建一个文件 /usr/local/bin/ping

#!/usr/bin/env bash
echo "## this is windows ping, not cygwin/gnu ping"
echo " for help: ping /? "
ping.exe $* |iconv -c -f gbk -t utf-8

创建一个符号链接,并赋执行权限

chmod +x /usr/local/bin/pin

重新打开cygwin的shell

netstat, nslookup等可如法炮治。

#!/usr/bin/env bash
echo "## this is windows netstat, not cygwin/gnu netstat"
echo "    for help:  netstat /? "
netstat.exe $* |iconv -c -f gbk -t utf-8

其他有用软件的包

Scheme解释器(lisp方言Scheme的运行环境):chicken

chicken: A practical and portable scheme system. 在setup中搜索sheme搜不出来中,要搜索chicken.  The CHICKEN Scheme interpreter.

GNU common lisp解释器,直接搜索clisp即可搜索出来。

一系列git设置选项/fetch,push走socks5代理/一份简单的gitignore文件

简述

git的设置一般通过 git config 命令,在本地仓库里的实际配置文件为 .git/config ,全局设置则在操作系统用户目录下 ~/.gitconfig

网络代理

连接远端服务器的操作,如fetch, push 等,如果需要走代理的情况,如果 远端仓库是 http 协议,则比较简单,  git config http.proxy=http://127.0.0.1:1080

不过,通常情况下 ssh 协议使用更广泛,这就要借助ssh的设置了(而不是git本身的设置),配置文件是 ~/.ssh/config  ,比如设置 github.com走1080端口的socks5代理,示例如下,注意其中 ProxyCommand  一行

Host github.com
HostName github.com
Port 22
# #User feng
IdentityFile ~/.ssh/id_rsa
ProxyCommand /usr/bin/nc -X 5 -x 127.0.0.1:1080 %h %p

基于ssh的用户认证

鉴于ssh协议使用更方便,这也就需要其配置文件,~/.ssh/config  , 如上节的示例,指定了对应的用户(User)的ssh密钥文件(IdentityFile) ,上面的其实就是ssh默认选项,一般情况下,不需要另外配置,这样写,只是方便参照做修改自定义。当然还有更多选项,可参考ssh的手册。

一份简单的gitignore文件

如下

*.bak
*.swp
.idea/
*.bak
*.~
.DS_Store
nbproject/*
*.swp
*.iml
_git_*
*_bak*
logs/
*.log
data/
uploads/
_build

没了,有需要的时候再往里面加。

主要是个人使用,放这里备忘。

在cygwin里调用windows版git-scm的gitk/git-scm与cygwin协同工作

20161216更新:

如果安装了git-scm的  Git-2.11.0-64-bit.exe,将如下命令加入~/.bashrc,重启cygwin即可(32位版本及以后的新版本应该是类似的)。

alias gitk='/cygdrive/d/Program\ Files/Git/cmd/gitk.exe'
. /cygdrive/d/Program\ Files/Git/mingw64/share/git/completion/git-completion.bash

假设git-scm安装在 D:\Program Files\Git

上面第一行命令是把gitk别名到windows版gitk的程序位置。第二行是执行git-completion以让git支持自动补全,方便使用,注意开头点号后面有个空格。


git-scm windows版的安装选项

以从 git-scm官方下载的Git-2.11.0-64-bit安装为例,典型的windows程序安装流程,可以一路下一步到底;不过有几步强烈建议按下面的选择

安装位置 ,推荐安装到D盘;重装windows后git还可直接使用

windows shelll集成选项。如果平时主要使用cygwin里的命令行版git、windows版只使用gitk看版本历史(推荐),建议全部取消选择。当然这里也可以保持默认选项。(新版本的git-scm在这里增加了几个选项,其中一项为 "Git LFS(Larget File Support)",推荐选中;其它的,自然就没必要。 [update 2019/09/15] 

强烈建议选第一项,只在Git Bash里使用git。强烈反对在windows cmd中使用git。推荐平时使用cygwin里的命令行版git。

强烈建议选第三项,不要让git自作聪明的修改换行风格,以避免被同伴鄙视+痛恨!

保持默认。强烈反对在windows cmd中使用git bash。事实上更推荐使用cygwin里的shell bash


旧文章归档

下面是操作方法适合早期版本,具体截止哪个版本号不明;内容是2014年底所写。

[标题] 在cygwin里调用windows版git-scm的gitk/git-scm与cygwin协同工作

-----------本文前面部分废话比较多,可以直接跳过前五段,阅读下一条分隔线后--------------------

前言

cygwin作为潜伏在windows里的类unix/linux操作系统,堪称神器,几乎可以运行一切unix工具,甚至连gui版的unix软件也可以用cygwin-X模拟。但是这个X实在太丑陋了,使用也不方便。不过,事实上,我们用cygwin主要是使用grep, cut, vim, git 等这些经典的的unix工具,而不是gui;毕竟gui也不是unix/linux的擅长项。

对于使用git的朋友,应该更依赖cygwin下的命令行版git,自由,快捷,随心所欲。然而要查阅版本历史时,还是gui版的git更直观。

而windows版git-scm自带了git gui/gitk工具,可以在git bash里运行gitk调用,这点与unix/linux下的git一致,使用还是比较方便的;但git bash有个硬伤,工具太少,而且shell太傻,完全是windows命令提示符的风格,通过鼠标做选择复制等操作,几乎是脑残得令人无语;比cygwin差了N个星系的距离。

于是:如果能在cygwin直接调用win32下git-scm的gitk,就完美了。

然而,一直没有找到方法,连万能的google也没帮上忙。经过艰苦卓绝的不懈努力,终于找到了办法,并发现多次尝试错误的原因。

----------------- 前面废话多;下面是原理,不想看可跳到下条分隔线(十段之后) ------------

原理简析

假设win32版git-scm装在 D:\Program Files\Git ,那么gitk位于 D:\Program Files\Git\bin\gitk 该文件是一个bash风格的脚本,它是由D:\Program Files\Git\bin\wish.exe 所调用执行的。

在windows开始菜单的git子项里,查看“git gui”的属性,会发现它是一个快捷方式,指向 "D:\Program Files\Git\bin\wish.exe" "d:\Program Files\Git\libexec\git-core\git-gui"  其中的gui-gui同样也是个bash风格的脚本,由wish调用。

因为cygwin本身支持windows原生的win32程序,执行该wish.exe并带上相应的参数,就可以调用这些bash风格脚本。

原理就是如上这些。我们按照cygwin风格重写这些命令。

在cygwin里,windows盘符挂载到/cygwin/下,形式如/cygdrive/c, /cygdrive/d ... 那么,上述wish.exe 在cygwin里,路径即

/cygdrive/d/Program\ Files/Git/bin/wish.exe
路径中的空格,要做转义。

后面要带上参数,这个参数要使用windows风格的路径,因为wish.exe是win32程序,它的参数是win32风格的。gtk的脚本即如下

/cygdrive/d/Program\ Files/Git/bin/wish.exe "D:\Program Files\Git\bin\gitk"

wish的参数加了双引号,这也是win32风格。可以在cygwin下切换到一个git项目目录里,执行上面的命令测试一下。

以cygwin里创建一个命令别名 gitk 到上面的命令上,如下

$ alias gitk='/cygdrive/d/Program\ Files/Git/bin/wish.exe "D:\Program Files\Git\bin\gitk"'

然后执行gitk即可,与git-scm的bash环境里执行gitk一样。不过这只能在本次会话中有效,将其放到 ~/.bashrc 里,后面增加如下一行

alias gitk='/cygdrive/d/Program\ Files/Git/bin/wish.exe "D:\Program Files\Git\bin\gitk"'

大功告成。

如果需要在cygwin里使用git gui的话,方法类似。

-----------------只想看解决方案者,可以直接从这里开始看 --------------------

一句话操作

假设win32版git-scm装在 D:\Program Files\Git  .  在cygwin里修改 ~/.bashrc 文件,追加如下一行:

$ alias gitk='/cygdrive/d/Program\ Files/Git/bin/wish.exe "D:\Program Files\Git\bin\gitk"'

保存后,启动cygwin即可。

如果不明白,建议看前文的原理部分

磁盘空间爆掉时nginx报错 An error occurred

nginx报错了,消息如下错误如下nginx_Error_disk_empty

An error occurred.

Sorry, the page you are looking for is currently unavailable.
Please try again later.

If you are the system administrator of this resource then you should check the error log for details.

Faithfully yours, nginx.

1分钟前还是好的,至少wordpress后台可以正常打开,突然就成这样子了。静态页面还正常,就ssh上,检查php-fpm进程是正常的,没有僵局。算了,杀死,连nginx一起杀死,虽然这是很不优雅的行为,所不齿的行为。然而结果是没用。随手查了下df -h ,分区满了,怪不得,查了下,删除几个备份文件,然后一切恢复正常了。空间不够,还是个问题,要进一步清理了。