关键性技巧

Linux / SHELL / 关键性技巧 / 安全相关 — 3 Comments
2
二 10

查找后门程序

每个进程都会有一个PID，而每一个PID都会在/proc目录下有一个相应的目录，这是Linux（当前内核2.6）系统的实现。

一般后门程序，在ps等进程查看工具里找不到，因为这些常用工具甚至系统库在系统被入侵之后基本上已经被动过手脚（网上流传着大量的rootkit。假如是内核级的木马，那么该方法就无效了）。

因为修改系统内核相对复杂（假如内核被修改过，或者是内核级的木马，就更难发现了），所以在/proc下，基本上还都可以找到木马的痕迹。

思路：
在/proc中存在的进程ID，在 ps 中查看不到（被隐藏），必有问题。

str_pids=`ps -A | awk ‘{print $1}’`
for i in /proc/[0-9]* ; do
        if  echo $str_pids | grep -q `basename $i` ; then
                :
            else
                echo “Rootkit’s PID: `basename $i`”
        fi
done
unset str_pids i

讨论：

检查系统(Linux)是不是被黑，其复杂程度主要取决于入侵者“扫尾工作”是否做得充足。对于一次做足功课的入侵来说，要想剔除干净，将是一件分精密、痛苦的事情，通常这种情况，需要用专业的第三方的工具（有开源的，比如tripwire，比如aide）来做这件事情。

而专业的工具，部署、使用相对比较麻烦，也并非所有的管理员都能熟练使用。

实际上Linux系统本身已经提供了一套“校验”机制，在检查系统上的程序没有被修改。比如rpm包管理系统提供的 -V 功能：

rpm -Va

即可校验系统上所有的包，输出与安装时被修改过的文件及相关信息。但是rpm系统也可能被破坏了，比如被修改过。

Apache / Linux / 关键性技巧 — No Comments
1
二 10

修改Apache的Max open files限制

相信绝大多数人，都是直接对 /etc/security/limits.conf  文件进行的修改，添加类似下面的两行：

*     soft         nofile           10240
*     hard       nofile           10240

这样也能达到效果。但是经验告诉我，能在局部修改，就不要动全局——因为我们不好评估全局会对哪些应用造成影响（就修改nofile参数一事来说，目前还没有发现修改全局对系统的明显影响，但是理论上可以肯定，将全局的限制放宽，意味着使系统容易受到“资源耗尽”类的攻击，然而在我的工作经历中，还没有遇到一例类似事故发生过），所以我建议将这些局部性的修改放到各自的启动脚本里。

在apachectl脚本里，有这样的语句：

#
# Set this variable to a command that increases the maximum
# number of file descriptors allowed per child process. This is
# critical for configurations that use many file descriptors,
# such as mass vhosting, or a multithreaded server.
ULIMIT_MAX_FILES=”ulimit -S -n `ulimit -H -n`”
# ——————–                              ——————–
# ||||||||||||||||||||   END CONFIGURATION SECTION  ||||||||||||||||||||

# Set the maximum number of file descriptors allowed per child process.
if [ "x$ULIMIT_MAX_FILES" != "x" ] ; then
    $ULIMIT_MAX_FILES
fi

所以，我推荐直接修改apachectl，在ULIMIT_MAX_FILES=”ulimit -S -n `ulimit -H -n`” 之前，设定nofile的“硬限制”，如下：

# number of file descriptors allowed per child process. This is
# critical for configurations that use many file descriptors,
# such as mass vhosting, or a multithreaded server.
ulimit -H -n 5000
ULIMIT_MAX_FILES=”ulimit -S -n `ulimit -H -n`”
# ——————–                              ——————–
# ||||||||||||||||||||   END CONFIGURATION SECTION  ||||||||||||||||||||

# Set the maximum number of file descriptors allowed per child process.
if [ "x$ULIMIT_MAX_FILES" != "x" ] ; then
    $ULIMIT_MAX_FILES
fi

这样修改的好处在于，只有Apache的“nofile”受到影响，不影响其它。
原公司的所有应用的管理脚本中（apachectl、nginxctl），都进行了修改，并且使用”isystem”（自己写的一套脚本、小程序的集合）进行统一管理，以至于到后来，我几乎已经忘掉了这些事情，但是系统仍然运行良好，没有再出过 “too many open files” 的问题。

注意：修改过nofile的hard限制以后，需要先stop，再start，httpd进程的限制才能使用新改的参数。

查看当前运行中的进程的limit信息，可以利用/proc（当前Linux内存为2.6），比如apache的一个进程号是10232：

cat /proc/10232/limits

Linux / 关键性技巧 — 2 Comments
2
九 07

关于“打开文件数”限制

　　Linux系统上对每一个用户可使用的系统资源都是有限制的，这是多用户系统必然要采用的一种资源管理手段，试想假如没有这种机制，那么任何一个普通用户写一个死循环程序，用不了多久系统就要“拒绝服务”了。

　　今天我遇到了tomcat日志报的错误信息”too many open files”，第一意识就想到了是ulimit控制的”open files“限制。然而问题来了。我在/etc/profile里加入了 ulimit -n 4096保存之后，普通用户登录的时候均会收到一条错误信息ulimit: open files: cannot modify limit: Operation not permitted。然后普通用户的open files限制还是默认值1024。

　　然后开始在互联网上搜索关于ulimit的信息。互联网果然方便，信息铺天盖地。大家也可以搜一下试一下。其中我了解到两个以前不知道的相关内容。
　　第一个是内核参数　fs.file-max  ，影射为 /proc/sys/fs/file-max
　　第二个是配置文件 /etc/security/limits.conf

　　其中大部分的信息中提到 将 /proc/sys/fs/file-max的值设置为4096和ulimit -n 4096是相同的效果。对此我很怀疑，为什么呢？首先ulimit 是一个普通用户也可以使用的命令，而fs.file-max只有root有权设置。其次，很明显fs.file-max是一个全局的设置，而ulimit是一个局部的设置，很明显的是不相同的。

　　带着疑虑，又在网上搜索了许久，未果（实际上是我搜索的关键字不够准确）。
　　最后终于在内核文档/usr/src/linux/Documentation/sysctl/fs.txt里找到下面一段话：

file-max & file-nr:
The kernel allocates file handles dynamically, but as yet it doesn’t free them again. The value in file-max denotes the maximum number of file-handles that the Linux kernel will allocate. When you get lots of error messages about running out of file handles, you might want to increase this limit.

The three values in file-nr denote the number of allocated file handles, the number of unused file handles and the maximum number of file handles. When the allocated file handles come close to the maximum, but the number of unused file handles is significantly greater than 0, you’ve encountered a peak in your usage of file handles and you don’t need to increase the maximum.

　　这两段话的大致意思是：
　　内核动态地分配和释放“file handles”（句柄）。file-max的值是内核所能分配到的最大句柄数。当你收到大量关于句柄用完的错误信息时，你可以需要增加这个值以打破老的限制。
　　file-nr中的三个值的含意分别是：系统已经分配出去（正在使用）的句柄数，没有用到的句柄数和所有分配到的最大句柄数。当分配出去的句柄数接近最大句柄数，而“无用的句柄数”大于零时，表明你遇到了一个“句柄”使用高峰，这意为着你不需要增加file-max的值。

　　看完这段话，相信大家都明白了。file-max是系统全局的可用句柄数。根据我后来又翻查的信息，以及对多个系统的查看求证，这个参数的默认值是跟内存大小有关系的，增加物理内存以后重启机器，这个值会增大。大约1G内存10万个句柄的线性关系。

　　再回过头来看这两段话，不知道你意识到了没有，文中只提到了file-max的增加，而没有提到了该值的减少。那些在操作ulimit时同时操作了file-max的哥们儿，估计无一例外地将file-max设置成了4096或者2048。但以似乎也没有因此而导致系统无法打开文件或者建议连接。（实际上，我将file-max的值设备成256，然后使用shell编写用vi打开500个文件角本运行，并没有得到任何错误信息，查看file-nr的值，系统当前分配的句柄值已经远超过了后面的最大值。所以我猜想对于file-max的任何减少的操作都是毫无意义的，姑且不去管他。实践中需要减少file-max的时候总是不多见的。 ）实事证明我犯了一个致命的错误。我测试的时候使用的是root用户，而当我再次使用普通用户测试的时候，预料中的错误信息出现了：”Too many open files in system”。可见，file-max的减少对系统也是影响力的。前面的结论“所以我猜想对于file-max的任何减少的操作都是毫无意义的”是错误的。

　　然后便是/etc/security/limits.conf文件，这个文件很简单，一看就能明白。

　　于是我按照注释中描述的格式两个两行：

*　　soft　　nofile　　4096
*　　hard　　nofile　　4096

　　恐怖的是，网上居然有人说改了这个设置是需要重启系统的！实在是让人想不通啊，鼎鼎大名的UNIX系统，怎么可能因为这么小小的一个改动就需要重启系统呢？结果当我再次以普通用户登录的时候，那个”ulimit: open files: cannot modify limit: Operation not permitted”提示没有了，查看ulimit -n，果然已经变成了4096。